测试过程Word下载.docx

测试过程Word下载.docx

《测试过程Word下载.docx》由会员分享，可在线阅读，更多相关《测试过程Word下载.docx（15页珍藏版）》请在冰点文库上搜索。

测试过程共包括：

“确定测试需求”，“制定测试计划”，“测试计划评审”，“功能测试设计”，“性能测试设计”，“其他测试设计”，“测试设计评审”，“测试实施”，“建立、维护测试基线”，“编写测试阶段报告”，“测试总结”。

其中，“建立、维护测试基线”，“编写测试阶段报告”这两个活动是贯穿于“测试实施”活动中。

活动

标准

输出

说明

确定测试需求

当系统测试需求数量较少时，可不形成单独的测试需求文档，将系统测试需求写入系统测试计划

功能测试点：

制定测试计划

不可裁剪

总体计划：

详细计划：

测试计划评审

参与人员：

参与时机：

功能测试设计

测试用例

性能测试设计

当无性能测试需求时，可裁剪此活动。

测试场景：

性能指标：

测试方案：

测试设计评审

不可剪裁

测试实施

建立、维护测试基线

可剪裁

编写测试阶段报告

测试总结

2.2过程结构描述

图1测试过程结构图

3过程元素描述

3.1确定测试需求

概述

测试需求是测试计划的基础。

测试人员根据项目需求确定本次测试的内容和范围，以便确定测试的规模、复杂程度与可能存在的风险。

相关人员起协助确认作用。

参与人员及职责

✓测试负责人：

收集、分析和确定测试需求

✓产品经理：

协助测试人员确认系统测试需求范围

✓开发负责人：

协助测试人员确认系统设计影响范围

入口准则

●存在能够支持测试人员制定测试需求的指导文档：

需求文档，原型demo等；

●存在指导测试人员了解系统实现的设计文档：

设计说明书，数据结构，流程图等

说明：

形式不限，但是要能指导测试确认测试范围，提供测试执行过程中的测试依据。

输入

需求：

需求说明书，原型demo，需求流程图等一切可以描述系统实现的资料

设计：

设计文档，实现流程图，数据结构图，接口协议等等

以上输入形式不限，但是至少能够描述当前任务的实现内容，可以作为测试人员测试功能的依据。

任务/步骤

●接口测试：

1.确定接口：

与外部系统关联的接口，非系统内部模块间的调用接口。

2.收集和分析接口测试需求。

测试人员从以下方面收集和分析接口测试需求：

1）确定接口类型：

主动接口或被动接口；

2）确定接口协议类型；

3）确定接口测试范围和粒度；

4）根据接口类型选用接口测试工具；

5）分析接口所用的业务需求。

开发人员提供相关的文档，并给予必要的培训和支持。

3.确定接口测试需求列表。

测试人员根据分析结果，整理出一个测试需求列表，并确定各测试需求项的优先级、覆盖程度等。

开发人员和产品经理对测试需求予以确认。

●系统测试：

4.收集系统测试需求。

测试人员以测试的观点根据软件需求整理出一个测试需求列表，作为测试该软件的主要工作内容。

测试需求主要通过以下途径来收集：

✓与待测软件相关的各种文档资料。

如软件需求规格、Usecase、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。

✓正式与非正式的需求沟通会，设计沟通会。

产品经理提供相关的文档，并给予必要的培训和支持。

5.分析系统测试需求。

测试人员从待测软件的特性，测试的焦点两个层面上进行分析，需确定以下类别的系统测试需求：

1）功能测试需求（如常用的或规定的业务流程，各业务流程分支的遍历，明确规定不可使用的业务流程，没有明确规定但是应该不可以执行的业务流程，其他异常或不符合规定的操作等）

2）兼容性测试需求（如用户使用的操作系统，浏览器等）

3）安全性测试需求（如系统保护机制，不同级别用户的访问控制等）

4）性能测试需求（如系统响应时间，系统吞吐量，CPU使用情况，内存使用情况等）

5）压力测试需求（如最大的活动终端数量等）

6）容量测试需求（如数据的最大容量，记录的长度限制等）

6.确定系统测试需求

测试人员根据分析结果，确定测试需求项，以及它们的优先级、覆盖程度等，编写测试需求文档。

产品经理和开发人员予以确认。

出口准则

测试需求列表已经过产品经理和开发人员确认无误

输出（工作产品）

测试需求列表

裁剪指南

裁剪内容

裁剪准则

可不形成单独的测试需求文档，将系统测试需求以功能模块的形式记录在pms中

当系统测试需求数量较少时，模块划分比较明确时

3.2制定测试计划

根据项目总体安排，每个月的月初会指定本月的总体测试计划，每个项目的测试人员，负责在每个任务执行前一周，在pms详细计划下周的测试计划

●测试经理：

进行月初的总体计划，并组织组内评审

●测试人员：

制定每周的详细计划

●产品经理和开发人员：

对测试计划的制定予以支持

●项目的开发计划已确定，需求基本明确

●开发任务排期

●测试依据

1．测试计划的制定应保持与项目计划一致；

2．总体计划在月初有测试经理负责制定，并组织组内评审；

3．详细计划，由测试人员根据总体测试计划，进行拆分详细计划；

4．测试计划中重点描述：

✓测试资源：

（软硬件资源，人力资源等）

✓测试进度：

细分任务，至少包括需求整理，用例设计，用例评审，测试执行，测试总结等任务。

测试执行的任务要细分到功能模块的计划排期

✓工作量估计：

以人日为单位估计工作量

✓版本发布：

定义清楚测试过程中，计划版本的发布时机。

5．月初测试计划的组内评审

测试计划编写完成后，由测试人员进行组内评审，检查内容不当之处，完成组内的承诺。

6．月初计划跟产品经理和开发人员确认通过，识别为最终确认版；

7．详细计划均在pms系统中，由具体测试人员自行拆分，但需要在任务执行上一周完成下周的任务拆分，也可以一次性完成全项目的任务拆分。

●总体测试计划：

产品经理和开发人员确认无误后完成

●详细计划：

每周例会确认完成后，完成。

●测试计划

3.3测试计划评审

依据《评审过程》的要求，测试负责人组织相关人员，对测试计划进行评审。

测试负责人根据评审意见进行修改。

●测试负责人：

组织测试计划的评审，并根据评审意见进行修改

参与测试计划的评审

●项目经理：

●相关人员（可能是系统架构师，系统设计师，需求工程师等）：

●测试计划制定完毕

1.测试负责人组织相关人员进行测试计划的评审。

2.测试负责人根据评审意见对测试计划进行修改。

具体参考《评审过程》。

●测试计划评审完毕

●评审后的测试计划

无

3.4测试设计

依据功能测试需求和测试计划，测试负责人组织测试人员进行功能测试的设计，明确功能测试方案，设计测试用例，构造测试数据，开发必要的测试程序和测试脚本，并建立测试目标和测试用例的对应关系。

设计功能测试方案

设计功能测试用例，测试数据，测试程序，测试脚本等

●测试计划通过评审

●功能测试需求已确定

●测试计划、功能测试需求

1.测试负责人根据功能测试需求设计功能测试方案，确定各功能测试需求项的开始测试准则，结束测试准则，测试覆盖要求，测试重点，测试方法，测试工具，测试环境，以及对测试用例设计、脚本设计、测试程序设计和测试执行的要求等，参考《软件测试方案模板》进行编写。

2.测试人员依据功能测试方案从下面几个角度设计测试用例：

●单元测试：

✓系统运行的测试用例（系统最简单最有可能执行被测单元的方法）

✓正向测试用例（针对每个功能测试需求项，验证功能是否正确实现）

✓逆向测试用例（针对每个功能需求项，验证被测单元有没有做它不应该做的事情）

●集成测试：

✓系统运行的测试用例（基本功能的测试用例，验证集成各模块的接口是否可用）

✓正向测试用例（验证各接口需求和集成后的模块功能需求正确无误地被实现）

✓逆向测试用例（验证被测接口是否实现需求中未要求的功能，是否出现接口数据异常和数据顺序错误等）

✓系统运行的测试用例（验证常用的或规定的业务流程是否正确实现）

✓正向测试用例（验证各业务流程分支的遍历是否正确实现）

✓逆向测试用例（验证系统是否实现了明确规定不可使用的业务流程，没有明确规定但是应该不可以执行的业务流程，其他异常或不符合规定的操作等）

3.测试人员编写测试用例文档。

测试用例的描述至少应包含测试索引，测试环境，测试输入，测试操作，预期结果等。

可参考《（通用）测试用例模板》。

web类项目可参考《Web类软件测试用例模板》，其他类型的项目可参考《（通用）测试用例模板》）

4.测试负责人组织相关人员对功能测试方案和功能测试用例进行评审。

（遵循《评审过程》）

5.根据评审后的功能测试方案和测试用例，编写必要的测试程序、测试脚本、驱动模块和桩模块，构造测试数据。

6.建立测试目标和测试用例的对应，将这种对应关系体现在需求跟踪矩阵中。

7.如果测试需求发生变更，则需及时更新相关的测试方案和测试用例。

●功能测试设计完成

●功能测试方案、测试用例、测试脚本、测试数据

●功能测试目标和测试用例对应的跟踪矩阵

系统测试：

3.5测试设计评审

依据《评审过程》，测试负责人组织相关人员对测试设计进行评审，并根据评审意见修改相应的测试设计。

组织测试设计的评审，并根据评审意见进行修改

参与测试设计的评审

●测试设计已完成

●测试方案，测试用例，测试脚本，测试程序，测试数据等

1.测试负责人组织相关人员对测试设计进行评审。

参与评审的测试设计包括功能测试设计、性能测试设计和其他测试设计。

2.测试负责人根据评审意见组织相关人员进行修改。

具体参考《评审过程》

●测试设计评审完毕

●评审后的测试设计

3.6测试实施

建立测试环境；

执行测试，记录测试中发现的缺陷，跟踪缺陷至解决；

在测试实施过程中，根据进度情况编写软件测试阶段报告。

确定测试终止时机，组织测试，编写测试阶段报告

建立功能测试环境、依据测试用例和测试方案进行测试，进行缺陷处理

●开发人员：

进行缺陷处理

●测试用例，测试脚本和测试数据等经过评审

●被测目标已达到测试开始标准

●已满足测试开始标准的build

1.测试负责人组织测试活动。

2.测试人员建立测试环境。

3.测试人员从配置库中取出已满足测试开始标准的build，建立测试基线。

（参考《测试过程》中“建立、维护测试基线”活动）

4.测试人员依据测试方案和测试用例执行测试，记录测试用例的通过情况。

5.测试人员运行测试脚本，记录并分析脚本运行结果。

6.测试人员记录测试执行中发现的缺陷，并跟踪缺陷至解决。

开发人员解决测试中发现的缺陷。

（在使用平台时，缺陷填写在平台的bug报告中；

如果项目组采用经过允许的缺陷跟踪工具，可以将缺陷填写在相应的工具中）（参考《问题缺陷处理规程》）

7.重新制作build，进行回归测试，确保新增加或者修改的代码没有引入错误。

8.如果已经达到测试计划中确定的测试终止准则（如达到测试用例执行率、测试用例通过率、缺陷率等指标），则终止功能测试执行；

如果没有达到，则继续执行测试。

9.在测试实施时，根据进度情况，依据《软件测试状态报告模板》编写测试阶段报告。

（在使用平台时，软件测试状态报告填写在平台测试报告中）（参考《测试过程》中“编写测试阶段报告”活动）

●测试执行终止

●测试阶段报告

●bug报告

3.7测试总结

测试负责人对测试缺陷进行汇总和分析，并根据结果对被测目标进行评价，提交测试的总结报告。

对缺陷进行汇总和分析，撰写总结报告

协助项目测试负责人进行分析

●测试已终止

●软件测试阶段报告

1．分析测试用例覆盖率，执行率及通过率

2．分析出现的缺陷及缺陷趋势分布

3．对测试项进行评价

4．分析遗留问题的潜在风险

5．分析资源使用情况和进度情况

6．形成测试结论

7．测试负责人依据《软件测试总结报告模版》编写测试总结报告。

（性能测试总结报告，Web类提供了《Web类软件性能测试总结报告模板》，其他类的可参考《软件测试总结报告模版》）。

●测试计划中定义的测试活动全部结束，测试总结报告已形成

●测试总结报告

资源和能力要求

●资源：

提供撰写测试总结报告所需的资源，《软件测试总结报告模板》，《Web类软件性能测试总结报告模板》

●能力：

相关人员应接受过相应方法的培训。

度量

度量元

采集点

撰写产品测试报告的工作量

周报表

单元测试：

集成测试：