测试流程Word格式.doc
《测试流程Word格式.doc》由会员分享，可在线阅读，更多相关《测试流程Word格式.doc（21页珍藏版）》请在冰豆网上搜索。
执行系统测试
产品试用
图1
有关的测试类型的概念如下：
1）单元测试：
验证产品中的模块，测试依据主要为模块详细设计或模块的需求规格。
能使问题及早暴露，也便于问题的定位解决，单元测试属于早期测试，因而错误发现后能明确知道是某一单元产生的，单元测试允许多个被测单元的测试工作同时开展。
根据公司研发流程的实际情况，此测试也可由设计研发人员执行。
2）集成测试是验证模块间接口及匹配关系，测试依据主要为概要设计。
一般采用自底向上或自顶向下的模块集成方法，逐步集成。
在此环节中测试组还负责验收研发人员提供的转测试的材料，如果材料不完备，测试组可以拒绝接收。
3）系统测试是对系统的一系列的整体、有效性、可靠性的测试，测试依据主要为设计规格及产品需求规格。
目的是确认产品与设计规格、需求、行业标准及公司标准的符合性，同时还要确认性能和系统的稳定性，与之前的集成测试应遵循“相同的被测对象不要做两遍相同的测试”的基本原则。
4）除单元测试、集成测试和系统测试之外，还应有“产品确认”环节，即在客户环境中或模拟客户环境测试与验证产品，在有限的试用客户中或模拟客户环境中发现产品问题并加以妥善处理，保证产品质量，提高客户满意度。
确认与实验室内部测试的区别在于：
实验室内部测试要尽可能多做，多发现问题；
确认要在达到质量目标的情况下尽可能少做；
两者要在质量和成本之间权衡、综合考虑。
5）TD：
全称MercuryTestDirector，一种测试管理工具。
6）黑盒测试：
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。
在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。
黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。
3职责
角色名称
相关主要责任
测试主管
l组建测试小组
l协调测试小组内外部的沟通
l组织编制测试大纲（含测试用例）和计划
l组织测试准入检查
l测试过程中的进度控制、风险管理
l测试过程报告
l编写测试报告
l召集测试评审
测试人员
l识别测试需求
l参与编制测试大纲（含测试用例）和计划
l协助测试准入检查
l执行测试用例，测试结果记录
l测试缺陷记录与跟踪
l协助测试评审
支持人员
l为测试工作提供技术支持，比如环境安装、版本布署、测试工具支持等
备注：
该角色可选，可根据项目实际情况设置，一般情况下由研发人员担任。
【注】：
当某个项目仅有一个测试人员时，该测试人员同时也为该项目内的测试主管，需要担负起测试主管的职责。
4测试类型和测试方法
4.1测试类型
测试工作通常分为4个类型，功能测试、联合测试、性能测试及稳定性测试。
测试类型
测试意义
功能测试
l确保功能符合需求定义
l确保所有功能可以正常完成工作
联合测试
l一个新产品或一个产品的新版本发布时，要确保与之相配合的产品可以正常配合使用
性能测试
l在产品有性能要求的部分，进行性能测试和调优，确保产品性能符合需求
稳定性测试
l模拟用户真正的使用情况，设计相应的测试用例，确保产品可以稳定可靠的长时间运行
4.2测试方法
测试方法
功能测试/
l以手工黑盒测试为主，手工执行功能测试用例。
l正规测试和随机测试相结合：
根据需求文档撰写测试方案及测试用例来进行常规测试，考虑到测试用例有可能写的不全面，所以在进行常规测试过程中，可以加入随机测试。
同时，对预测试出来的缺陷，将其执行过程写成一个测试用例，添加到测试用例集合中，以完善测试用例；
l采用测试工具TD进行测试用例的管理和缺陷记录、跟踪。
l性能测试要求满足两种情况：
1）产品在特定工况下可以达到的最高性能（例如：
测试时将日志等影响性能的选项关闭）；
2）模拟用户真正的使用环境（如：
日志功能打开，在一定的用户数量的情况下），
产品真实可以达到的性能；
l稳定性测试要求模拟用户真正的使用情况，设计相应的测试用例，确保产品可以稳定可靠的长时间运行
黑盒测试过程的参考准则：
（1）必须采用边界值分析法；
（2）必要时采用等价类划分法补充测试用例；
（3）采用错误判断法，追加测试用例；
（4）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。
如果没有达到要求的覆盖标准，应当补充更多的测试用例；
（5）测试数据应准备充分，应采用有效数据、无效数据、边界数据分别测试验证；
5工作流程、模式及规范
5.1测试提交文件及裁剪说明
阶段
提交文件
必须提交
模板定义
裁剪条件说明
测试需求分析报告
否
项目组自定义
无特殊需求，可省略
是
各项目组根据测试任务的规模可自定义模板
如果测试大纲或设计开发计划中已包括了测试计划的内容，则本文档可省略
测试大纲计划评审记录
公司模板
各项目酌情选用
测试用例
采用公司统一测试用例模板
测试用例评审记录
测试实施
测试准入检查表
测试记录
测试收尾
测试报告
采用公司统一测试报告模板
测试报告评审记录
测试工作改进报告
测试成果提交
5.2评审点
评审点定义参照《设计开发控制程序》。
5.3敏捷测试模式
5.3.1敏捷测试概念
敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。
5.3.2敏捷增量测试方法
测试是敏捷开发过程重要的环节，自始自终测试贯穿于每个迭代。
整个产品的敏捷开发生命周期可以分为4个阶段，即初始阶段，项目的建设阶段，产品发布阶段和产品的维护阶段，在关键的项目建设阶段中，测试被分成两个部分，验证测试和系统测试。
验证测试：
静态测试和关键的功能测试。
系统测试：
功能测试、联合测试、性能测试、稳定性测试。
5.3.3敏捷测试流程
敏捷测试流程依据业务场景制定测试策略。
在每次敏捷测试的过程中包括验证测试和联合测试。
并且不断的进行迭代测试。
在系统的所有业务场景都经过敏捷测试过后，进入系统测试阶段。
进行所有业务场景的功能测试、联合测试、性能测试、稳定性测试。
根据业务场景制定测试策略流程图
产品
业务场景一
业务场景二
。
业务场景N
模块一
模块二
模块三
模块N
模块四
缺陷管理
业务场景三
TR5
业务场景四
敏捷测试流程图
测试传递项报告
敏捷测试
测试总结
测试通过
进入下一次敏捷迭代
提交测试
N
Y
满足准入条件
系统测试条件
软件测试总结
软件评估
满足发布条件
产品发布
测试案例维护
系统测试和回归测试
测试是否通过
根据缺陷性质来判断更新提交测试的依据：
1）严重级别为Urgent和High的修改后立即更新，要保证更新后不能影响其他功能测试。
2）功能级别为Medium以下的可以等待下一次提交敏捷测试的时候更新。
5.4传统瀑布模式
5.4.1测试需求分析
过程要点
详细说明
启动条件
需求阶段的工作启动
工作内容
由测试主管根据项目任务复杂程度组织或指定测试人员进行测试需求分析，从客户角度考虑软件测试需要达到的验证状态，并确定是否要形成测试需求分析报告
结束条件
需求分析完成
例外
对于简单设计更改、衍生产品等只需例行测试的，可不进行测试需求分析
责任人
项目经理
参与人
5.4.2成立测试小组或确认测试人员
测试任务明确，前期工作启动
l确认项目的测试人员，若整个项目的测试需要若干个测试人员，则需要成立一个测试小组；
l为测试小组任命一名测试主管，若只有一个测试人员，则该测试人员同时也为该测试组的测试主管，同时确定测试小组的其它构成人选；
l小组内进行必要的培训。
测试小组成立
l若以前的测试任务已成立过测试小组，则可以复用以前的组织人员和形式
5.4.3编制测试计划
项目阶段性计划确定
需求规格说明书、详细设计说明书等已评审
测试大纲至少包括以下关键内容：
l测试目标——对本次测试的要求和要达到的目标
l测试范围——需要测试小组测试的范围，和各个测试需求的测试优先级
l工作分工——明确测试小组内部及外部配合方的相关责任和工作关系
l测试策略——整体测试的总体测试策略、环境、方法和工具等
l完成标准——达到何种条件可以认为测试完成
l交付文件——测试完成时应提交的文件，比如测试大纲（含测试用例）、测试报告等等
测试计划至少应包括以下关键内容：
l主要任务——每项任务的时间计划、前置条件及资源
l主要里程碑——关键任务及完成时间点
l在项目研发过程中，要适时的对测试计划进行跟踪，以评估此计划的完整性、可行性，在项目结束时还要最后评估一下测试计划的质量
结束标准
测试计划评审通过或得到相关各方的审批
输出文件
测试计划、测试计划评审记录
l对于多个系统参与的同一个测试任务，可由主项目组或牵头方统一编制测试大纲和计划，不用每个系统单独编制和出具
l测试计划可以在测试大纲中直接详细列明，而不用单独编制
研发总监、项目经理、测试人员
5.4.4编制测试大纲、设计测试用例
在技术规格书评审通过以后，测试小组需要针对项目的测试范围编制测试大纲、设计测试用例。
在实际测试过程中，测试
升级会员 