技术开发 频道

软件测试过程模型

    三、执行测试

    输入:

    · 已批准的测试文档(测试计划、用例、程序)

    · 如果适用测试工具,自动化测试软件和编写好的脚本

    · 设计的变更(变更请求)

    · 测试数据

    · 测试和项目组的可用性(项目人员,测试小组)

    · 概要和详细设计文档(需求,软件设计)

    · 通过配置/构建人员能够完全转移到测试环境(单元测试过的代码)的开发环境

    · 测试就绪文档

    · 修订文档

    输出:

    · 代码的变更(测试修复项)

    · 作为一种测试的结果(测试文档问题),测试文档没有说明的问题

    · 设计时发现的问题,反馈给开发人员和客户(需求,设计,代码问题)

    · 测试事故的正式记录(问题跟踪)

    · 为向下一级别转移而准备的基线化包(已测试的源代码和对象代码)

    · 测试结果的日志和总结

    · 已批准和带有修订测试交付项的签署文档(已更新的交付项)

    过程:

    · 在执行阶段中应召开Checkpoint 会议。(如果由需要,)每天应召开Checkpoint 会议处理和讨论测试中的问题,状态和活动。

    · 通过采用系统的手段跟进测试文档来完成测试的执行。当执行测试程序的每一个包时,为了记录程序的执行和测试程序找出的任何缺陷,应该将问题记录到测试执行日志中。测试程序执行后的输出当作测试结果。

    · 为了确定是否可以得到预期的结果,测试结果应该由适当的项目组员评估(,适合于测试的所有级别)。记录并和软件开发经理/程序员讨论所有差异/异常,为了以后的调查和解决应该将它文档化(每个客户可能有不同的记录日志和报告bug/defect的过程,通过Configuration Management (CM)小组校验这些过程)。通过/失败的准则用来确定问题的严重级别,结果记录到测试总结报告中。

    · 根据客户的风险评估来定义在系统测试中发现的问题严重级别并记录到他们选择的跟踪工具中。

    · 基于问题的严重级别有目的的修复并提交到测试环境中。被修改的问题应进行回归测试并将没有问题的修复项转移到新的基线中。在测试完成后,测试组的成员应准备一份总结报告。总结报告要由项目经理,客户,SQA和/或测试组长复审。

    · 在证实达到一个指定的测试级别后,配置经理应根据配置管理计划中的要求整理发布的软件组件并转移到下一个测试级别。软件只有在客户正式验收之后才可以转移到生产环境中。

    · 测试小组在复审测试和更新的文档中发现的测试文档的问题。有些问题可能是由于技术性和功能性之间的不一致或修改所造成的。

0
相关文章