· 项目开发人员将定义单元测试需求和单元测试的场景/用例。在集成和系统测试之前，开发人员同时也负责执行单元测试用例。
· 在开发人员和客户的协助下，测试小组将开发集成和系统测试的测试场景、用例。验收测试用例将由客户在项目和测试小组的帮助下开发。
· 通过使用测试脚本执行测试场景。脚本将定义用于执行一个和多个测试场景的一系列步骤。测试脚本通常描绘在一般的系统操作中会出现的事务或过程。测试脚本包括用于测试过程或事务的特定数据。测试脚本将覆盖多个测试场景并且包括运行/执行/周期信息。测试脚本映射需求和用于保证任何测试都是在范围内的追溯矩阵。
· 在测试之前，捕捉并且基线化测试数据。这些数据将作为单元和系统测试的基础和在可控的环境下执行系统功能。为了以后的对照，一些输出的数据也被基线化。在回归测试时，基线化的数据用于支持以后的系统维护。
· 为评定应用程序的就绪情况、环境和被测试的数据，应召开测试准备会议。为了指出发本版本的入口标准状态，应创建测试就绪文档。
三、执行测试
输入：
· 已批准的测试文档（测试计划、用例、程序）
· 如果适用测试工具，自动化测试软件和编写好的脚本
· 设计的变更（变更请求）
· 测试数据
· 测试和项目组的可用性（项目人员，测试小组）
· 概要和详细设计文档（需求，软件设计）
· 通过配置/构建人员能够完全转移到测试环境（单元测试过的代码）的开发环境 · 测试就绪文档
· 修订文档
输出：
· 代码的变更（测试修复项）
· 作为一种测试的结果（测试文档问题），测试文档没有说明的问题 [Page]
· 设计时发现的问题，反馈给开发人员和客户（需求，设计，代码问题）
· 测试事故的正式记录（问题跟踪）
· 为向下一级别转移而准备的基线化包（已测试的源代码和对象代码）
· 测试结果的日志和总结
· 已批准和带有修订测试交付项的签署文档（已更新的交付项）
过程：
· 在执行阶段中应召开Checkpoint 会议。(如果由需要，)每天应召开Checkpoint 会议处理和讨论测试中的问题，状态和活动。
· 通过采用系统的手段跟进测试文档来完成测试的执行。当执行测试程序的每一个包时，为了记录程序的执行和测试程序找出的任何缺陷，应该将问题记录到测试执行日志中。测试程序执行后的输出当作测试结果。
· 为了确定是否可以得到预期的结果，测试结果应该由适当的项目组员评估（，适合于测试的所有级别）。记录并和软件开发经理/程序员讨论所有差异/异常，为了以后的调查和解决应该将它文档化（每个客户可能有不同的记录日志和报告bug/defect的过程，通过Configuration Management (CM)小组校验这些过程）。通过/失败的准则用来确定问题的严重级别，结果记录到测试总结报告中。
· 根据客户的风险评估来定义在系统测试中发现的问题严重级别并记录到他们选择的跟踪工具中。
· 基于问题的严重级别有目的的修复并提交到测试环境中。被修改的问题应进行回归测试并将没有问题的修复项转移到新的基线中。在测试完成后，测试组的成员应准备一份总结报告。总结报告要由项目经理，客户，SQA和/或测试组长复审。
· 在证实达到一个指定的测试级别后，配置经理应根据配置管理计划中的要求整理发布的软件组件并转移到下一个测试级别。软件只有在客户正式验收之后才可以转移到生产环境中。
· 测试小组在复审测试和更新的文档中发现的测试文档的问题。有些问题可能是由于技术性和功能性之间的不一致或修改所造成的。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
