Mercury“最佳功能测试实践”

lsekfe

1 概诉 本测试过程作为功能测试的最佳实践，用于实施不同机构的功能测试工作。它可以作为测试计划工作的基础，应用于每个软件开发的项目。在这个测试过程中描述的活动既可以用于新开发的组件，亦可以用于改进现有的回归测试。 2 测试管理 为了能顺利地获得测试的结果，将测试作为独立管理的过程是非常必要的。测试管理可以分为下面四个领域。 1）测试计划 2）测试执行 3）测试控制 4）测试过程改进 用于支持测试管理各个领域的工具可以采用TestDirector。 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 业务功能的质量需求 　业务功能的质量需求是依据业务的风险进行定义的。业务风险和技术复杂度的信息存储在测试的需求中。这两个参数决定了测试的程序和测试的工作量。另外，针对业务功能分配测试员，并且将测试活动的当前状态落实到纸面上。只有这样做才能在针对业务功能的整个测试过程中监控测试的状态。 　1.1.2 测试阶段的定义 　依据已经定义的质量目标，我们需要将测试阶段进行合理的划分。 　通常情况有以下几个阶段： 1）开发员自测试阶段（不在我们的考虑范围之内） 　2）业务功能测试（单元测试） 　3）业务流程测试（应用级的集成测试） 　4）业务集成测试（端到端的集成测试） 　5）性能测试 　6）系统集成测试 下面的表中描述了每个测试阶段需要达到的质量目标： 　业务功能测试和业务流程测试是在软件项目开发过程中完成的。而业务集成测试和系统集成测试则组合成回归测试，用于软件系统上线前或者发布为产品前来检验软件的质量。 1.1.3 质量门 　测试是在不同的阶段中完成的。划分不同阶段的原因就是将不同的质量目标分配到不同的阶段中，从而能将测试的执行尽可能的提前。所以，在相邻的测试阶段中设置一个质量门就成为保障成功的关键要素。 下面的图中展示了每两个相邻阶段的质量门是如何设定的： 　下面是对质量门的一种详细定义： 1）在业务功能测试之后 业务功能测试的测试用例执行了80%以上 业务功能测试的测试用例（A级风险）执行了100% 少于5个服务器端错误 少于30个中级错误 无致命性缺陷 2）在业务流程测试之后 业务功能测试通过 业务流程执行了100% 无业务流程完全失效，所有的错误都可以被修复 无致命性缺陷 3）在业务集成测试之后 业务流程测试通过 业务集成流程执行了100% 无致命性缺陷 1.1.4 功能分解 　在计划测试活动之前，功能分解应该作为第一个要完成的活动。进行功能分解时，应该邀请业务方面和需求分析方面的代表共同参加。通常情况下，要遵从下面的原则： 1) 每个用户情形都是一个业务功能 2) 如果一组用户情形非常相似，那它们应该组合在一起形成一个业务功能 3) 如果一个用户情形非常大或者非常复杂，则应该将其分解为两个或者更多的业务功能进行功能分解的思路体现在“将测试的单元确定为包含少量功能点的单位”，这样，每个测试单元的测试用例的数量就会被限制在一定的范围之内。我们可以将分解的目标设定为每个业务功能只有最多30-40个测试用例。 　1.1.5 风险评估 　既然质量保证的基本思路是降低缺陷破坏业务的风险，同时为了确保质量保证的资源得到充分的利用，我们需要对每个业务功能进行风险的评估。还要考虑到的是，我们也要对技术影响进行分析。这样我们能对完成每个业务功能的测试活动所需的工作量进行估算。 1.1.5.1 业务风险分析 　业务风险评估需要针对被测软件的所有业务功能。评估的标准应该在整个业务的范围内是唯一的，才能在企业范围内使不同的评估结果具有可比性。 结果标准 A 高级风险 A 高级风险 C 低级风险 流程的类型 计算/验证 数据的改变 显示 业务影响 合法性 错误信息 无 使用频度 非常频繁 经常 极少 受影响客户的数量 大量/非常重要的 空间 　1.1 测试准备 　测试的准备是一个独立的、分离的阶段，测试员在这个阶段中基于需求文档准备测试（业务设计图）。测试的准备要依据标准的方法，并应基于本阶段的工作生成标准化的文档。 　1.1.1 业务功能测试 　基于风险评估，针对每个业务功能的不同风险级别都应有一个对应的测试过程和方法组合： 　1）A级风险　利用等价类和组合进行系统性的测试完全自动化 2） B级风险　利用等价类进行系统性的测试完全自动化 3） C级风险　随意性测试手工执行，在TestDirector中提供文档化的执行过程 对于每个测试过程和方法组合，要提供一个标准的文档进行方法论级的阐述和规定，每个测试人员依据这些标准的测试过程和方法组合进行测试。 在TestDirector中要将测试用例的准备结果作为业务功能的附件。 1.1.2 业务流程测试 　业务流程测试是将所有的业务功能组合在一起，使用同一组数据进行工作。测试员的任务就是要确定每个业务功能的组合是否能连贯的执行。判断的结果使用矩阵来表示，例如下图：注：yes（+）；no（-） 业务流程矩阵 　从上面的表中我们能获得三个业务流程测试案例： 　1) 1，2，2，3，2，4，1，1 　2) 1，5，4 　3) 1，2，3，4 1.1.3 业务集成测试 　使用现有的回归测试案例进行业务集成测试。 　在第一个阶段，测试案例仅被自动化，而不考虑测试的覆盖率。 　在第二阶段，测试案例将被改进，以提高测试的覆盖率。 　对于所有的新项目，回归测试应该在业务功能测试阶段和业务流程测试阶段的测试结果的基础上进行建设。 　依据业务流程矩阵创建测试案例集，这个测试案例集应该能覆盖被测系统的所有外部接口。 　假定我们的被测系统是Mercury的机票预定系统，它的架构图如下： 　业务流程矩阵的设计如下图：

datoucai

好文章，赞

fhhh_eyou

感谢您的分享与分析实践