测试流程及规范.doc

目的
侧重测试工作流程及规的控制，明确产品研发的各阶段测试组应完成的工作。测试技术和策略等问题不在本文档描述围。
本规作为所有测试组成员工作前必须掌握的工作规，也供应其它部门其它组查阅参考，以便于组间的协调沟通，更好的合作完成产品的研发试出来的缺陷，将其执行过程写成一个测试用例，添加到测试用例集合中，以完善测试用例；
采用测试工具TD进展测试用例的管理和缺陷记录、跟踪。
性能测试
性能测试要求满足两种情况：
1〕产品在特定工况下可以到达的最高性能〔例如：测试时将日志等影响性能的选项关闭〕；
2〕模拟用户真正的使用环境〔如：日志功能翻开，在一定的用户数量的情况下〕，
产品真实可以到达的性能；
稳定性测试
稳定性测试要求模拟用户真正的使用情况，设计相应的测试用例，确保产品可以稳定可靠的长时间运行
【注】：黑盒测试过程的参考准则：
〔1〕必须采用边界值分析法；
〔2〕必要时采用等价类划分法补充测试用例；
〔3〕采用错误判断法，追加测试用例；
〔4〕对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有到达要求的覆盖标准，应当补充更多的测试用例；
〔5〕测试数据应准备充分，应采用有效数据、无效数据、边界数据分别测试验证；
工作流程、模式及规
测试提交文件及裁剪说明
阶段
提交文件
必须提交
模板定义
裁剪条件说明
测试需求
测试需求分析报告
否
工程组自定义
无特殊需求，可省略
测试方案
测试大纲
是
工程组自定义
各工程组根据测试任务的规模可自定义模板
测试方案
否
工程组自定义
如果测试大纲或设计开发方案中已包括了测试方案的容，则本文档可省略
测试大纲方案评审记录
否
公司模板
各工程酌情选用
测试用例
是
公司模板
采用公司统一测试用例模板
测试用例评审记录
否
公司模板
各工程酌情选用
测试实施
测试准入检查表
否
公司模板
各工程酌情选用
测试记录
是
工程组自定义
各工程组根据测试任务的规模可自定义模板
测试收尾
测试报告
是
公司模板
采用公司统一测试报告模板
测试报告评审记录
否
公司模板
各工程酌情选用
测试工作改良报告
否
工程组自定义
各工程酌情选用
测试成果提交
否
工程组自定义
各工程酌情选用
评审点
评审点定义参照"设计开发控制程序"。
敏捷测试模式
敏捷测试概念
敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个生产的过程平安的、及时的发布最终产品。
敏捷增量测试方法
测试是敏捷开发过程重要的环节，自始自终测试贯穿于每个迭代。整个产品的敏捷开发生命周期可以分为 4 个阶段，即初始阶段，工程的建立阶段，产品发布阶段和产品的维护阶段，在关键的工程建立阶段中，测试被分成两个局部，验证测试和系统测试。
验证测试：静态测试和关键的功能测试。
系统测试：功能测试、联合测试、性能测试、稳定性测试。
敏捷测试流程
敏捷测试流程依据业务场景制定测试策略。在每次敏捷测试的过程中包括验证测试和联合测试。并且不断的进展迭代测试。在系统的所有业务场景都经过敏捷测试过后，进入系统测试阶段。进展所有业务场景的功能测试、联合测试、性能测试、稳定性测试。
根据业务场景制定测试策略流程图
产品
业务场景一
业务场景二
。。。。。。
业务场景N
模块一
模块二
模块三
三
。。。。。。
模块N
模块四
三
业务场景一
缺陷管理
缺陷管理
业务场景三
TR5
业务场景二
TR5
业务场景N
TR5
业务场景四
TR5
敏捷测试流程图
测试传递项报告
敏捷测试
测试总结
测试通过
进入下一次敏捷迭代
测试方案
提交测试
N
Y
Y
N
满足准入条件
系统测试条件
Y
软件测试总结
软件评估
满足发布条件
产品发布
测试案例维护
系统测试和回归测试
测试是否通过
Y
Y
根据缺陷性质来判断更新提交测试的依据：
严重级别为Urgent和High的修改后立即更新，要保证更新后不能影响其他功能测试。
功能级别为Medium以下的可以等待下一次提交敏捷测试的时候更新。
传统瀑布模式
测试需求分析
过程要点
详细说明
启动条件
需求阶段的工作启动
工作容
由测试主管根据工程任务复杂程度组织或指定测试人员进展测试需求分析，从客户角度考虑软件测试需要到达的验证状态，并确定是否要形成测试需求分析报告
完毕条件
需求分析完成
例外
对于简单设计更改