项目软件测试流程及规范Word格式文档下载.docx

项目软件测试流程及规范Word格式文档下载.docx

《项目软件测试流程及规范Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《项目软件测试流程及规范Word格式文档下载.docx（17页珍藏版）》请在冰豆网上搜索。

十六、验收测试；

2、测试人员工作范围

一、理解业务需求；

二、编写相关业务文档；

三、编写相关测试文档；

四、参与项目会议并整理会议记录；

五、参与项目设计；

六、制定测试计划与测试方案；

七、编写测试用例；

八、执行测试；

九、验证项目问题

十、提交测试报告

十一、版本推广；

十二、版本后续维护

3、相关名词解释

业务需求说明书：

依据项目需求为蓝本，将项目需求整理成册，为项目其他文档母本，为编码工作的业务指导文档

系统规格书：

依据业务需求说明书，规定需求实现的逻辑与流程，以及涉及的表结构、字段类型，囊括模块流程图、模块之间的关系、业务流程说明、实现过程、数据表等关键要素。

软件需求说明书：

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

模测问题：

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

生产问题：

生产环境中业务人员发现的项目软件缺陷或者功能没有实现等问题

静态问题：

项目文档中，错误或者不规范的流程图、不合理、错误或者的描述等体现在文档中的问题。

有效问题：

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

二、业务需求阶段

1、考核指标

业务需求理解处于项目立项阶段，需求理解的程度将直接影响后续阶段。

本阶段考核指标将体现在后续阶段中：

编写项目相关文档的质量、测试的执行力、程序派错率、遗漏的问题数等。

2、本阶段工作流程

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

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

3．各研发部从XXX领取项目任务

4．框架构建人员与编码人员理解业务需求，可通过调研、会议、邮件、涵的方式。

3、本阶段具体做法

参与需求研讨会，理解业务需求

4、参考经验

业务部门提出的需求共有两种：

对现有系统功能的改造；

提出新的业务功能要求。

对于现有功能的改造需求理解：

在熟悉现有业务功能的基础上，针对改造的内容，预估涉及改造的功能模块；

系统现有框架或实现方式不会做大的改动，从会议讨论中可以发现本次改造的重点与难点；

区分出重点与难点之后，其他功能完全可以自我理解。

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

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

对于新的业务需求：

需求理解研讨会上仔细做笔记，搞清每一个功能模块的输入与输出，以达到对业务流程以及实现过程的精确把握；

对于不理解或无把握之处提出自己的有效问题或者建议，恰恰体现出认真思考的工作态度。

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

三、业务需求与验收测试设计

系统软件的质量：

体现业务需求理解的程度，也体现在验收测试设计中。

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

风险程度：

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

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

参与需求研讨会，间接参与验收测试设计，预估项目风险

1．参与需求研讨会：

对于业务部门提出的需求，逐字逐句理解并把握，否定无效需求。

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

3．预估项目风险

同上。

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

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

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

3．预估项目风险：

积极参与项目的组织结构、平时注意业务经验与技能的积累，并保持长期性与稳定性；

对项目进度的不合理安排提出自己的建议。

四、业务需求分析与系统设计

1．业务需求理解程度：

2．系统设计合理性、可行性：

合理性、可行性程度将直接影响项目后续阶段。

3．静态问题：

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

1．参与项目需求的理解。

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

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

1．参与项目需求的理解：

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

依据项目需求，整理并归纳业务需求。

3．项目系统规格书：

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

2．参与业务需求理解：

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

3．系统规格书编写与修改：

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

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

理解业务流程与业务逻辑可以向框架人员或者编码人员进行沟通，也可以根据自己的理解或者会议讨论结果、纪要进行；

涉及的表结构、字段可向项目编码人员所取，对于新建表、更新表等操作，要要根据业务功能注意表之间的关联。

五、需求理解、系统设计与确认、系统测试设计

系统设计：

系统设计对业务需求功能覆盖率、合理程度、界面友好、操作便利性等。

集成测试人员偶尔参与系统设计

1．对于修改现有功能的业务需求类，可以向编码人员展示现有功能的实现过程、逻辑复杂性、参数设计合理性、GUI资源等。

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

1．修改现有功能的业务需求类：

在页面展示上类似于增加字段，后台数据表增加对应字段类型等改造。

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

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

2．全新的业务需求类：

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

六、概要设计

1．静态测试问题：

体现在软件需求说明书中的文档问题。

2、项目需求与产品双向追溯：

产品功能点与项目软需契合程度。

1．业务需求的讨论。

2．非业务需求的讨论。

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

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

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

2．非业务需求讨论：

与本次项目需求相关但无须本次项目中实现的需求、本次项目关联的其他业务需求，对相关的业务类型进行列举，并讨论有效解决方案。

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

依据系统规格书进行。

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

5．项目需求与产品双向追溯表：

实现项目需求与产品功能的对照关系。

2．非业务需求的讨论：

可以列举本次业务实现过程中对其他业务类型所产生的影响，比如下游系统的数据需求、数据移行、接口参数等；

其他相关联的业务实现；

此项需要较丰富的业务知识。

总之一点：

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

3．软件需求说明书。

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

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

基本要素为：

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

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

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

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

4．设置需求实现优先级：

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

有利于提高测试效率，同时也能有效把握测试进度。

检测产品功能列表是否全部体现出项目需求，可以有效控制项目需求的遗漏和冗余，高于项目需求或者低于项目需求都有可能存在缺陷。

七、概要设计与集成测试设计

1．项目测试列表：

测试列表中所涉及的功能模块的覆盖率直接影响测试案例的覆盖率，进而影响软件测试质量。

2．项目测试计划：

体现测试工作量、测试时间与测试进度控制，进而影响测试质量。

3．项目测试方案：

体现测试工具、测试顺序与测试伦次，进而影响测试效率。

4．项目测试案例：

测试执行的依据，直接体现了功能模块的测试覆盖率。

1．编写项目测试列表。

2．编写项目测试计划。

3．编写项目测试方案。

4．编写项目测试案例。

包含要素：

模块名称、变更类型、接口、测试案例分支、模块重要性、计划编写案例数、实际编写案例数、测试人员、测试结论等。

项目简介、测试目标、测试环境、工作量、人力资源要素、测试时间与进度、风险等。

环境、参数、数据准备、测试工具、测试列表、测试顺序与伦次等。

模块名称、模块功能描述、测试案例分支、测试用例、预期结果、测试人员、用例预期执行时间、用例测试通过时间、问题数、问题号等。

以软件需求说明书为蓝本，此文档作用基本为列出本次项目所实现的功能点，编写此文档时，可以拷贝软件需求说明书中的业务功能详述部分，进行修改，加入模块或者是字段之间的约束关系，整合在一起，即：

编写项目测试列表即要体现所有的功能点，也要体现模块与模块、字段与字段之间的约束关系。

可以提供模板供参考格式，并注意整个文档的排版与可读性。

，

对项目进行简单介绍、说明测试工作应该达到的预期目标（问题或缺陷闭环率100%），体现测试工作所处的软硬件环境、预期的工作量、测试参与人员与QA、一定时间段内的应达的测试进度、测试风险。

其中：

测试进度依据测试时间来制定并严格执行，否则，规定的时间内完不成测试任务；

测试风险考虑参与测试的人员的技术成熟度、稳定性、积极性、编码人员修改问题的实效性、配合力度，或者其他相关部门、个人对提供直接数据的依赖程度。

风险一般是客观存在的风险。

体现测试工执行中的测试工作、测试顺序和伦次等测试策略。

测试环境体现了软件版本安装路径、访问地址、测试列表、所需的软硬件要求等；

参数部分体现了软硬件参数、环境参数、数据交互接口、DSR配置以及参数失效的错误码等；

测试工具，目前主要采用黑盒手工测试，自动化测试工具很少使用，辅助测试工具主要有：

Rational缺陷管理工具、数据库管理工具、抓图工具、归并冲突管理工具等；

测试列表同上；

顺序与伦次，按照业务流程与关键路径对功能模块进行排序，确定测试顺序，一般的做法是抓住主要的业务流程，其他模块可以放在后面进行细测，比如参数设置的模块。

测试伦次原则上是至少两轮，第一论对项目中的所有模块进行细致的测试，第二论主要是对第一论测试中缺