测试流程

测试流程培训
2007/12/17
简介
测试计划
编写 评审 更新 确认
测试需求分析（业务培训、用户需求理解与学习并根据相关用户需求提取测试需求） 测试需求分析（业务培训、用户需求理解与学习并根据相关用户需求提取测试需求） 测试方案
设计 评审 更新 确认
测试用例
设计 评审 更新 确认
SDV测试执行 测试执行
5
SDV执行准备（BSSP_D900）
1、熟悉环境搭建过程，向开发询问环境搭建的问题，请开发人员作详细解答（例如：此配置项为什么要这样配置）， 预先提醒开发，准备SDV执行时详细的环境搭建指导书； 2、环境搭建成功后，能够执行一些基本正常的流程； 3、在SDV执行时，让开发人员给测试人员一点测试建议； 4、测试数据准备； 5、（时间充足）测试人员进行代码走读（充分的熟悉业务流程）； 6、预测试用例准备（抽取不超过总用例数的10%，且此用例都是基本用例，级别为Level 1）； 7、综上：测试人员对自己写的用例进行检查，如果发现用例存在问题、遗漏了场景或业务流程等地方，需要在TD 中提单，（让CMO赋予相关人员权限）同时修改SDV测试方案和SDV测试用例；
2、用例评审 、
– – – – 评审前要自己所负责模块的方案进行自检，避免低级错误的出现； 组织者发出评审通知，开始评审； 评审达到出口准则； 评审记录文档、预评审表单、Summary表单要命名规范；Summary表单中不允许有接受的疑问出现；
3、用例更新 、
– 根据评审意见修改，要拒绝的问题需要和评审相关人员达成一致，在评审人员允许的情况下才可以关闭问题，修拒绝修改； – 所有接受的问题要在Summary表单中做缺陷分析；
4、用例确认 、
– 查看修改人员是否按照评审意见修改，如果不符合要求，填写“否”，让修改人员重新修改； – SDV测试用例确认完后，CMO要打基线，收回权限；
用例结束，开发人员与向测试人员提出业务流程方面的问题，测试人员作解答（进一步保证对需求的了解程度） 用例结束，开发人员与向测试人员提出业务流程方面的问题，测试人员作解答（进一步保证对需求的了解程度）
2、测试方案评审 、
– 评审前要自己所负责模块的方案进行自检，避免低级错误的出现； – 组织者发出评审通知，开始评审； – 评审达到出口准则； – 评审记录文档、预评审表单、Summary表单要命名规范；Summary表单中不允许有接受的疑问出现；
3、测试方案更新 、
– 根据评审意见修改，要拒绝的问题需要和评审相关人员达成一致，在评审人员允许的情况下才可以关闭问题，拒绝修改； – 所有接受的问题要在Summary表单中做缺陷分析；
2、SDV2执行 、 执行
从归档库中取最新版本进行安装； 先回归第一轮的问题单，如果有不通过的版本打回； 执行在第一轮抽取的预测试用例，如果有不通过的版本打回； SDV2结束后（开发归档），重新抽取SDV3的预测试用例（第二轮的问题单同时也是预测试用例中的一部分），并根据缺陷单分析 结果，准备第三轮的测试用例（较多的基本用例）； – 编写SDV第二轮测试报告； – – – –
4
Sห้องสมุดไป่ตู้V测试用例设计
1、用例设计 、
– 根据SDV测试方案来设计SDV测试用例； – 在设计SDV测试用例时，如果发现SDV测试方案中存在问题或有遗漏的场景分析，则要在TD中提缺陷单，然后让CMO给相关修改 人赋予修改测试方案的权限； – 测试用例名称（TestCase Name）要能明确表达被测用例的意图，预置条件要完整，操作步骤要能清楚的指导用例的执行，预期输 出要覆盖所有的检查点；
SDV1_Build SDV2_Build SDV3_Build
验收测试
1
测试计划
1、测试计划写作 、
Data of Test 测试数据 Requirement of Training 培训需求 Process Criteria 过程条件 – 开发版本符合转测试条件，具体包括：
SRS、接口文档（含数据库表结构说明）和测试用例基线化； 单元测试结束，提交单元测试报告； 提交系统测试报告且缺陷达标； 通过Findbugs代码检查，提交Findbugs检查报告； 开发人员的预测试全部通过，并且提交预测试报告； 归档包、安装指导书、配置项说明和测试建议提交； 测试部接受的预测试全部通过；
3、SDV3执行 、 执行
7
缺陷单（提问题单）简要规范
缺陷标题要能够简要概括缺陷现象 正确填写缺陷等级（可以参见缺陷等级定义） 正确选择缺陷所属模块或功能点 正确选择缺陷项目阶段（可以通过TD写脚本设置默认的项目阶段） 是否可再现缺陷 缺陷描述包括：
预置条件（导致产生该问题必须符合的条件） 测试步骤（操作步骤） 输入（实际输入的数据或触发点） 预期结果（预期输出） 实际结果（系统真实返回的信息） 初步定位（导致该问题的原因）
6
SDV测试执行
1、SDV1执行 、 执行
– 检查开发人员转测的版本是否符合SDV测试计划中的转测试条件，如有不满足版本打回； – 从归档库中取最新版本进行安装； – 按照开发人员提供的环境搭建指导书，进行环境搭建安装； – 环境安装完毕，执行预测试用例，预测试用例必须全部OK，才能进行SDV第一轮测试开始，如果有NG的，立刻打回版本，开人员 修改后重新归档验证； – 第一轮执行或结束后，如果有用例存在问题或用例遗漏，需要在TD中提单，并补足用例，新增的用例需要以红色字体与原来用例区 分开来，CMO重新基线化管理； – 重新抽取SDV2的预测试用例（第一轮的问题同时也是预测试用例中的一部分），并根据缺陷单分析结果，准备第二轮的测试用例； – 编写SDV第一轮测试报告，结合第一轮、第二轮做缺陷漏测分析；
4、测试方案确认 、
– 查看修改人员是否按照评审意见修改，如果不符合要求，填写“否”，让修改人员重新修改； – SDV测试方案确认完后，CMO要打基线，收回权限；
在写方案时可能要参与开发人员SRS的评审和确认； 的评审和确认； 在写方案时可能要参与开发人员 的评审和确认 测试方案写作完后，为了保证对需求的理解程度，向开发人员讲解业务流程； 测试方案写作完后，为了保证对需求的理解程度，向开发人员讲解业务流程；
9
8
– – – – – –
从归档库中取最新版本进行安装； 先回归第一轮的问题单，如有不通过的版本打回； 执行在第二轮抽取的预测试用例，如有不通过的版本打回； SDV3结束后（开发转验收归档），根据缺陷目标，看是否有必要加测一轮； 编写SDV第三轮测试报告； 测试总结；
验收测试
– 回归客户方的问题单，并做漏测分析；
2、测试计划评审 、
– 组织者发出评审通知； – 参与的评审人员；
3、测试计划更新 、 4、测试计划确认（要填写修订记录） 、测试计划确认（要填写修订记录）
3
测试方案
1、测试方案设计 、
– 测试需求（需求跟踪矩阵表，对应到AR的设计规格点或者如果以SRS为输入则要对应到需求编号）； – 内部实现分析（不允许拷贝开发人员SRS中的处理部分，要用自己的语句来表达是怎样实现的）；
Suspend Criteria 挂起条件 Resume Criteria 恢复条件 Rules of Defect Closed 缺陷关闭准则
2
– 缺陷提交人员从CMO处取得归档后的测试版本进行回归测试，确认缺陷修改状况。如果回归测试不通过，则将 缺陷单置为重新打开状态（reopen）并提交至PM；如果回归测试发现该缺陷的修改引发了其他缺陷的产生，则 针对新缺陷新起缺陷单；如果回归测试通过，则关闭缺陷(close) ； Schedule 进度 – （在评审前每个测试人员都应该查看进度，并对进度给出合理的意见）；