软件测试流程及规范V1.1.docxVIP

软件测试流程及规范 V1.1 软件测试流程及规范 一、软件生命周期中测试工作流程 测试工作流程 业务部 软件部 测试组 段 阶 析 提交最终版 SRS 编写《测试计划》、《测试方案》 分 求 需 段 阶 计 设 要 概 设计测试用例，编写测试用例 段 阶 计 设 细 详 单元测试方案、用例评审 执行单元测试 编辑单元测试方案、用例 记录缺陷 分析、修改缺陷 回归测试 段 阶 码 编 段 阶 试 测 统 系 段 阶 试 测 收 验  提交系统测试报告 系统测试方案、用例评审 编辑单元测试方案、用例 冒烟测试 分析缺陷 执行系统测试 修改缺陷 记录缺陷 回归测试 提交系统测试报告 根据 SRS,评审验收测试方案、用例 执行验收测试 分析缺陷 记录缺陷 修改缺陷 回归测试 提交验收测试报告 编写验收相关文档 二、各阶段具体流程 需求分析阶段 立项 需求调研 编写 / 修改 SRS 提交 SRS SRS审核 审核是否通过 达到要求 依据 SRS，项目整体计划， 提交最终版 SRS 设计、编写《测试计划》 和《测试设计》 评审测试计划 和测试设计 优化测试计划、 审核是否通过 测试设计 审核通过 进入概要设计阶段  《测试计划》 根据 SRS定义相应的测试需求报 告，即制订测试的标准，以后所 有的测试工作都将围绕着测试需 求来进行，符合测试需求的应用 程序即是合格的，反之即是不合 格的；同时，还要适当选择测试 内容，合理安排测试人员、测试 时间及测试资源等。 《测试设计》 将测试计划阶段制订的测试需求 分解、细化为若干个可执行的测 试过程，并为每个测试过程选择 适当的测试用例。 1.1 步骤说明 1、需求定义基本完成， SRS编写完成。 2、开评审会，由需求调研人员、开发组、 设计组、测试组等人员对需求中不清楚、 不完整、 存在疑义的地方提出问题，相关人员解答并确 认。 3、当评审未通过，直接打回，重新修改 SRS，问题解决后，重新提交评审。 4、当评审通过后，依据 SRS，项目整体计划，设计、编写《测试计划》和《测试设计》 ，具体模板见附件。 5、开评审会，由开发组、设计组、测试组等人员对计划和设计中不清楚、 不完整、存在疑义的地方提出问题。 6、当审批未通过，直接打回，优化测试计 划、测试设计，问题解决后，重新提交评审。 7、审核通过后，进入下一阶段。 1.2 测试通过打回标准 1.3 、阶段的输出 输入：最新 SRS、项目计划 输出：测试计划、测试设计 2、单元及集成测试流程 测试设计文档 编写 / 修改单元测 试方案 单元测试方案评审 审核是否通过 编写 / 修改测试用例 测试用例审核 提交 BUG报告 审核是否通过 编写 / 修改测试代码 编码审核 审核是否通过 执行单元测试  依据需求和设计描述作为指南，对重要的 控制路径进行测试以发现模块内的错误。 测试过程中优先考虑耦合度比较高的模块 功能，重点测试。 如果是集成测试，依据需求和设计描述作 为指南，在单元测试的基础上，将所有模 块按照设计要求组装成为子系统或系统 , 检查其接口是否存在问题 ,以及组装后的 整体功能、性能表现，进行测试。 使用缺陷管理工具 （如 QC），对软件的 缺陷进行管理。 修改代码 回归测试， 是否达到要求 提交单元测试报告 在BUG出现的曲线图逐 渐收敛并且得到控制的 进入下一阶段 情况下进入下一阶段。 2.1 步骤说明： 1、理解需求和设计 理解设计是很重要的， 特别是要搞清楚被测试模块在整个软件中所处的位置， 这对测试的内容将会有很大的影响。需要记住的一个原则就是：好的设计，各模块只负责完成自己的事情，层次与分工是很明确的。 在单元测试的时候， 可以不用测试不属于被测试模块所负责的功能， 以减少测试用例的冗余， 集成测试的时候会有机会 测试到的。 所以，单元测试主要是关注本单元的内部逻辑，而不用关注整个业务的逻辑， 因为会有别的模块去完成相关的功能。 2、概览源代码 浏览一下源代码，主要任务： 1）初步检查源代码的编码风格与规范。 2）大致估算测试工作量，比如：需要多少 的测试用例、需要写多少的驱动模块和装模块等。 3）确定模块的复杂程度，初步制定测试的 优先级等。 3、精读源代码 认真阅读和分析代码，主要任务： 1）理解代码的业务逻辑。 2）检查代码与设计是否相符，如果详细设 计没有该模块的流程图的话，先去画出流程图。 3）仔细研究逻辑复杂的模块。 4）可以采用一些检查列表来检查程序可能 会出现的问题。 4、设计测试用例 综合运用白盒测试方法 （和结合黑盒测试方 法）来设计测试用例，包括功能测试、性能测试等，要达到一定的测试覆盖率。 在设计测试用例的过程中，流程图或控制流图是分析的好帮手。 5、搭建单元测试环境 使用工具或自己