有效测试的 50 条建议 - 编制测试计划（7）

第 7 条：考虑风险

在指定测试策略之前，必须理解测试计划中的假定、先决条件和风险，考虑手头任务的各种限制（见第 6 条），测试策略最好通过缩小测试任务的方式来确定，如下：
1，理解系统架构
2，确定使用 GUI 测试、后端测试还是二者同时使用。
测试人员应牢记：服务层测试的整体复杂程度和所需的技术等级远高于 GUI 测试。服务层的测试可能更需要熟悉对应开发语言的测试人员，紧随开发人员的脚步；GUI 测试则需要 GUI 测试工具和一般的编程技巧及行业背景，同时 GUI 测试脚本应该不间断的测试 GUI；
3，选择测试技术
缩小使用测试技术类型的范围，有助于减少大量的输入组合和变化。
4，选择测试工具
可以是现有的，也可以是根据需要自己开发。
5，开发内部自制的测试工具或脚本
6，确定测试需要的人员和专门的技术
7，确定测试覆盖率
包括：功能需求的覆盖、代码的覆盖率，以及在一些情况下，根据给定的资源、时间表、工具、手头任务的安排、忽略测试带来的风险，来确定测试的覆盖率。
应当把测试覆盖内容和测试不覆盖的内容写入文档。
8，建立发行标准
发行标准即什么时候可以认为测试完成了。
9，设置测行时间表
测试策略必须根据分配给测试的工作时间进行裁剪。
10，考虑测试阶段
不同测试阶段用不同的测试策略
例如：功能测试阶段是为了确定功能是否满足需求
性能测试结算是为了保证系统满足性能需求
..............
将测试内容按照功能路径、场景或流程进行分组测试也是非常有益的，可参考如下原则：
1，风险等级
为测试需求评定优先级，并作风险评估。
2，操作特性
对频繁使用的功能和对用户缺乏了解的部分分配高优先级，对技术资源或内部用户和不常使用的功能分配低优先级。
3，用户需求
考虑用户的接受程度，有些需求对用户接授程度是致命的，如金额、合同等。
4，可用的资源

排列测试优先级时，要考虑资源的可用性。

大多风险是由以下几个因素造成的：
1，短时间面市
2，新的设计过程
3，新技术
新技术能否如我们预期的那样运转，是否被错误的理解或实现，是否需要补丁。
4，复杂度
哪个功能最容易出错、错误会对系统造成重大影响。
5，使用频率
最常使用功能，即核心功能。
6，不可测试的需求
包括功能性的和非功能性的。

一个有助于降低风险的测试策略，就是把测试工作的重点放在系统中可能会引起绝大多数问题的那部分。
对于一个版本中风险较小的部分，我们只需要执行为了特定发行的版本所必须的测试工作。
TIPS：风险低的任务还能为缺乏经验的新手提供积累经验的机会，并且这种做法风险也是最低的。

本文章援引《Effective software testing》一书内容，为个人读后笔记，特此声明