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