软件测试工具Mercury“最佳功能测试实践”（二）

软件测试工具Mercury“最佳功能测试实践”（二）

1.1测试策略和计划

        在制定测试策略时，要基于被测软件的质量目标。质量目标就是测试的需求。它们决定了测试的阶段和质量的目标。要想最优化测试的活动并制定一个切实可行的测试计划，需要将被测软件分解成为一个一个的业务功能。在进行业务功能分解时，要以黑盒的方法来看待被测软件的功能，即独立于软件的实现方法。若想计算测试的效果并且保证测试的活动适合于特定业务的需要，则需要引入风险评估的手段。

        1.1.1   需求

        测试的必要条件是要确定预期结果或者需求。为了能更好的了解需求，将需求进行分类是非常有帮助的。以我们的观点，可以将需求分为功能性需求和质量需求（非功能性需求）。功能性需求描述了在业务上期望如何使用新的软件系统，且该系统中应该包括哪些功能。质量需求包括的是软件系统的通用特性，且独立于功能。

        1.1.1.1      功能性需求

        功能性需求以业务设计图的方式记录于文档中。为了在TestDirector中将需求作为测试的基础，需要将需求导入到TestDirector中。相应的业务设计图作为需求的附件存在，并作为将来测试活动的依据。

        1.1.1.2         质量需求

        质量需求由两部分构成，一部分是为整个产品或者项目定义的质量目标，另一部分是每个业务功能的质量需求，这些业务功能的质量需求取决于风险评估的结果。

        1.1.1.2.1       质量目标

        1）适应性

        组件被修改以适应新需求的难易程度。

        2）完整性

        组件实现所有需要的能力的程度。

        3）正确性

        a)        组件在规格分析、设计和实现过程中无错误的程度
        b)        组件满足需求或者用户需要与期望的程度
        c)        基于给定输入产生相应输出的能力，并且这个过程符合或者满足需求

        4）有效性

        当组件完成指定任务时，能最少使用所需资源的程度。

        5）可维护性

        组件被修改以纠正错误，提高性能或其他属性，或者适应被改变了的环境的难易程度

        6）模块性

        软件系统由离散的组件组成的程度，即改变一个组件时能将对其他组件的影响降至最低。

        7）可移植性

        软件系统或组件能被转移到其他硬件平台或者软件平台上的难易程度。

        8）可靠性

        组件在一定的时间内、一定的条件下执行所需完成功能的能力。

        9）可用性

        用户对软件组件的理解和操作的难易程度。

        1.1.1.2.2       业务功能的质量需求

        业务功能的质量需求是依据业务的风险进行定义的。业务风险和技术复杂度的信息存储在测试的需求中。这两个参数决定了测试的程序和测试的工作量。另外，针对业务功能分配测试员，并且将测试活动的当前状态落实到纸面上。只有这样做才能在针对业务功能的整个测试过程中监控测试的状态。

原文转自：http://www.ltesting.net