项目软件测试流程与规范

项目软件流程与测试规范XXXX测试组XXX目录一、项目软件流程与测试人员工作范围 (5)1、项目软件流程阶段 (5)2、测试人员工作范围 (5)3、相关名词解释 (6)二、业务需求阶段 (6)1、考核指标 (6)2、本阶段工作流程 (6)3、本阶段具体做法 (7)4、参考经验 (7)三、业务需求与验收测试设计 (7)1、考核指标 (7)2、本阶段工作流程 (8)3、本阶段具体做法 (8)4、参考经验 (8)四、业务需求分析与系统设计 (8)1、考核指标 (8)2、本阶段工作流程 (8)3、本阶段具体做法 (9)4、参考经验 (9)五、需求理解、系统设计与确认、系统测试设计 (9)1、考核指标 (9)2、本阶段工作流程 (9)3、本阶段具体做法 (10)4、参考经验 (10)六、概要设计 (10)1、考核指标 (10)2、本阶段工作流程 (10)3、本阶段具体做法 (11)4、参考经验 (11)七、概要设计与集成测试设计 (11)1、考核指标 (11)2、本阶段工作流程 (12)3、本阶段具体做法 (12)4、参考经验 (12)八、详细设计阶段 (14)1、考核指标 (14)2、本阶段工作流程 (14)3、本阶段具体做法 (14)4、参考经验 (14)九、详细设计与单元测试设计 (15)1、考核指标 (15)2、本阶段工作流程 (15)3、本阶段具体做法 (15)4、参考经验 (15)十、单元测试 (15)1、考核指标 (15)2、本阶段工作流程 (15)3、本阶段具体做法 (15)4、参考经验 (16)十一、集成 (16)1、考核指标 (16)2、本阶段工作流程 (16)3、本阶段具体做法 (16)4、参考经验 (16)十二、集成测试 (17)1、考核指标 (17)2、本阶段工作流程 (17)3、本阶段具体做法 (18)4、参考经验 (18)十三、实施阶段 (21)1、考核指标 (21)2、本阶段工作流程 (21)3、本阶段具体做法 (21)4、参考经验 (21)十四、确认测试与系统测试 (22)1、考核指标 (22)2、本阶段工作流程 (22)3、本阶段具体做法 (22)4、参考经验 (22)十五、交付 (23)1、考核指标 (23)2、本阶段工作流程 (23)3、本阶段具体做法 (23)4、参考经验 (23)十六、验收测试阶段 (24)1、考核指标 (24)2、本阶段工作流程 (24)3、本阶段具体做法 (24)4、参考经验 (24)一、项目软件流程与测试人员工作范围1、项目软件流程阶段XXX项目，目前采用的项目流程，主要有以下阶段一、理解业务需求阶段(立项)；二、业务需求与验收测试设计阶段；三、需求分析与系统设计；四、需求分析、系统设计与确认、系统测试设计；五、概要设计；六、概要设计与基础测试设计；七、详细设计八、详细设计与单元测试设计；九、编码；十、单元测试；十一、集成；十二、集成测试；十三、实施；十四、确认测试与系统测试；十五、交付；十六、验收测试；2、测试人员工作范围一、理解业务需求；二、编写相关业务文档；三、编写相关测试文档；四、参与项目会议并整理会议记录；五、参与项目设计；六、制定测试计划与测试方案；七、编写测试用例；八、执行测试；九、验证项目问题十、提交测试报告十一、版本推广；十二、版本后续维护3、相关名词解释业务需求说明书：依据项目需求为蓝本，将项目需求整理成册，为项目其他文档母本，为编码工作的业务指导文档系统规格书：依据业务需求说明书，规定需求实现的逻辑与流程，以及涉及的表结构、字段类型，囊括模块流程图、模块之间的关系、业务流程说明、实现过程、数据表等关键要素。

软件需求说明书：以简练、准确、无歧义描述语言，描述软件需求，是软件测试的关键文档，也是编写测试列表、测试案例的基础文档。

模测问题：模拟生产环境测试过程中所发现的项目软件缺陷或者功能没有实现等问题。

生产问题：生产环境中业务人员发现的项目软件缺陷或者功能没有实现等问题静态问题：项目文档中，错误或者不规范的流程图、不合理、错误或者的描述等体现在文档中的问题。

有效问题：测试问题提出后，经过编码人员修改，最终被修改验证通过的问题。

二、业务需求阶段1、考核指标业务需求理解处于项目立项阶段，需求理解的程度将直接影响后续阶段。

本阶段考核指标将体现在后续阶段中：编写项目相关文档的质量、测试的执行力、程序派错率、遗漏的问题数等。

2、本阶段工作流程1．业务部门在生产过程中面向XX客户提出的使用需求，整理成书面文档，汇总后将需求提交至XXX，同时提出软件功能需求。

2．XXX从全国各业务部门(含海外地区)上报的需求，下发XXX所属的各研发部。

3．各研发部从XXX领取项目任务4．框架构建人员与编码人员理解业务需求，可通过调研、会议、邮件、涵的方式。

3、本阶段具体做法参与需求研讨会，理解业务需求4、参考经验业务部门提出的需求共有两种：对现有系统功能的改造；提出新的业务功能要求。

对于现有功能的改造需求理解：在熟悉现有业务功能的基础上，针对改造的内容，预估涉及改造的功能模块；系统现有框架或实现方式不会做大的改动，从会议讨论中可以发现本次改造的重点与难点；区分出重点与难点之后，其他功能完全可以自我理解。

对于现有功能改造的需求理解，建立在对现有系统的理解的基础上。

新进人员对系统的熟悉程度可以向项目组其他成员请教。

对于新的业务需求：需求理解研讨会上仔细做笔记，搞清每一个功能模块的输入与输出，以达到对业务流程以及实现过程的精确把握；对于不理解或无把握之处提出自己的有效问题或者建议，恰恰体现出认真思考的工作态度。

整理需求研讨会议纪要，可以试着自己设计业务功能的框架与实现过程，比较架构办的预案，缩小差距，提高自身需求理解的程度。

三、业务需求与验收测试设计1、考核指标系统软件的质量：体现业务需求理解的程度，也体现在验收测试设计中。

验收结果达不到预期值将从根本上决定考核指标。

风险程度：项目参与人员的技术成熟度、稳定性、沟通能力、工时额度、人员或部门的配合度。

验收测试对业务需求的覆盖率。

2、本阶段工作流程参与需求研讨会，间接参与验收测试设计，预估项目风险3、本阶段具体做法1．参与需求研讨会：对于业务部门提出的需求，逐字逐句理解并把握，否定无效需求。

2．间接参与验收测试设计3．预估项目风险4、参考经验1．参与需求研讨会：同上。

2．间接参与验收测试设计。

集成测试与系统测试阶段不体现项目软件验收工作，但是集成测试与系统测试范围必须涵盖业务需求范围，包含直接划定的业务范围与相关联的业务范围。

本阶段可以参考集成测试阶段。

3．预估项目风险：积极参与项目的组织结构、平时注意业务经验与技能的积累，并保持长期性与稳定性；对项目进度的不合理安排提出自己的建议。

四、业务需求分析与系统设计1、考核指标1．业务需求理解程度：同上。

2．系统设计合理性、可行性：合理性、可行性程度将直接影响项目后续阶段。

3．静态问题：体现在系统规格书文档中静态测试问题个数。

2、本阶段工作流程1．参与项目需求的理解。

2．参与业务需求的理解。

3．参与项目系统规格书的编写与修改。

3、本阶段具体做法1．参与项目需求的理解：同上。

2．参与业务需求的理解：依据项目需求，整理并归纳业务需求。

3．项目系统规格书：以业务需求为依据，按照一定的格式编写或者修改系统规格数。

4、参考经验2．参与业务需求理解：根据历次会议讨论结果和会议纪要，拆分或整合项目需求，整理完毕的业务需求说明书必须包含项目需求的所有内容和隐含内容，为系统规格数编写或者修改的依据。

3．系统规格书编写与修改：熟练使用相关的流程图工具，如VISO等，在理解业务流程、业务逻辑、涉及的表结构、字段等基础上进行规格书的编写与修改。

系统规格书有固定的格式，有模板共参考。

理解业务流程与业务逻辑可以向框架人员或者编码人员进行沟通，也可以根据自己的理解或者会议讨论结果、纪要进行；涉及的表结构、字段可向项目编码人员所取，对于新建表、更新表等操作，要要根据业务功能注意表之间的关联。

五、需求理解、系统设计与确认、系统测试设计1、考核指标系统设计：系统设计对业务需求功能覆盖率、合理程度、界面友好、操作便利性等。

2、本阶段工作流程集成测试人员偶尔参与系统设计3、本阶段具体做法1．对于修改现有功能的业务需求类，可以向编码人员展示现有功能的实现过程、逻辑复杂性、参数设计合理性、GUI资源等。

2．对于全新的业务需求类，可以向编码人员建议类似的业务实现过程。

4、参考经验1．修改现有功能的业务需求类：在页面展示上类似于增加字段，后台数据表增加对应字段类型等改造。

业务流程基本不会发生质的改变。

测试人员可以先熟悉现有功能模块的菜单位置、图形界面，以数据驱动、业务驱动或者后台数据查看的方式掌握现有的业务功能。

2．全新的业务需求类：XX现有的业务实现过程基本为申请－签批－台帐，这是业务的主要流程，针对不同的业务类型只是表现为菜单位置不同，实现过程大同小异，测试人员可以从大体流程上把握新需求的实现过程，不至于茫然而无从下手。

六、概要设计1、考核指标1．静态测试问题：体现在软件需求说明书中的文档问题。

2、项目需求与产品双向追溯：产品功能点与项目软需契合程度。

2、本阶段工作流程1．业务需求的讨论。

2．非业务需求的讨论。

3．编写或修改软件需求说明书。

4．评审需求要点并参与设置需求实现优先级。

5．制定项目需求与产品双向追溯表。

3、本阶段具体做法2．非业务需求讨论：与本次项目需求相关但无须本次项目中实现的需求、本次项目关联的其他业务需求，对相关的业务类型进行列举，并讨论有效解决方案。

3．编写或修改软件需求说明书：依据系统规格书进行。

4．依据模块重要性、关键路径对其他模块影响程度设置需求实现优先级。

5．项目需求与产品双向追溯表：实现项目需求与产品功能的对照关系。

4、参考经验2．非业务需求的讨论：可以列举本次业务实现过程中对其他业务类型所产生的影响，比如下游系统的数据需求、数据移行、接口参数等；其他相关联的业务实现；此项需要较丰富的业务知识。

总之一点：和本次项目相关的，都可以纳入到讨论的范围。

3．软件需求说明书。

严格按照系统规格书进行编写。

与系统规格书格式不一致，提供模板。

基本要素为：模块编号、模块名称、功能概括、角色、运行条件、输入字段、输出字段、约束关系、页面截图、业务功能详述等，并注意文档排版与美观。

其中业务功能为重点，详细阐述本功能模块实现的功能点，描述无别字、错字，表述要清晰、准确、无冗余，否则属于静态测试问题。

软件需求说明书与系统规格书在表述内容上要严格保持一致。

软件需求说明书修改要根据相关会议讨论结果，并确认有修改必要后再行修改。

4．设置需求实现优先级：测试人员参与此项工作有助于了解模块的关键程度，实施测试时可以先测试高优先级模块。