如何降低测试设计的风险

肾虚道长

基于风险的测试
　　在基于风险的测试中，风险识别、风险分析、及风险缓解活动的制定奠定了定义测试方法的基础[ 4 ] 。每个风险项目相关的风险级别决定每个风险相关的测试工作（即减缓行动）所需要的精力。某些安全相关的标准规定了：要用的测试方法和要达到的基于风险度（见下文）的覆盖率。
　　测试是一种减轻产品风险的方法。如果发现了缺陷，测试人员通过缺陷意识和机会意识在发布前处理缺陷来降低风险。如果测试员没有发现缺陷，测试员通过确保系统在一定条件（例如，测试条件）下正常运行以降低风险。
　　测试设计技术
　　降低产品风险的一个选择是使用测试设计技术。
　　风险的级别和类型应是一个：通过使用不同测试设计技术改变测试强度的主要参数。如：对高风险的测试项目使用决策图表技术（decision table technique），对低风险测试项目使用“唯一”等价类划分方法，或对高风险测试项目使用完整决策图表技术，对低风险测试项目使用崩溃决策图表技术（collapsed decision tables），等等。
　　风险（风险的级别和类型都）应该是一个：选择测试设计技术及其变体的主要推动力。测试方法应基于风险！风险越大，就越需要进行更彻底更激烈及更正式的测试。例如，用边界值分析法选择使用两个边界或三个边界应该是一个基于风险的决策。有三个边界的测试是更彻底（更激烈）的 ，但这需要更多精力，降低更高等级的风险是判断付出的精力是否值得的唯一标准。
　　发布一个产品时的商业风险或许会受到质量问题（因此更正式的测试设计技术才合适），或上市时间问题的影响（因此探索性测试将是一个更合适的选择） 。
　　当然，选择要用的测试设计技术的时候，风险不是唯一因素（尽管是非常重要的一个）。
决策将基于多个因素，包括内部的和外部的，例如[2]：
　　内部因素
　　使用模型
　　测试员的知识及经验
　　预期缺陷类型
　　可用文档
　　生命周期模型
　　生命周期阶段，例如新开发或维护
　　外部因素（除了风险的级别和类型）
　　客户/合同要求
　　系统类型
　　监管要求
　　时间和预算
　　基于风险的测试方法

图1.系统测试的不同的基于风险的测试方法的例子
为了解释基于风险的测试方法意味着什么，下面提供了简化的系统测试实例。基于产品风险矩阵的系统测试方法[4] ，如图1所示。这个例子表明，最关键的项，第II象限，使用用例（包括备选流）及决策表的全面测试设计技术来进行测试。
　　该方法按比例缩小为第二最高风险级别就是第IV象限。 （请记住，系统测试主要关注商业风险）。用例（包括备选流）仍适用于第IV象限，但决策表，现在不再适用了。
　　相反，等价类划分被用作一项通常比决策表技术定义更少测试用例的测试设计技术。用例仍然用于第I象限，但只执行主流，等价类划分再次被用作测试设计技术。对于第III象限，只测试测试用例主流。根据风险等级和风险类型变换测试设计技术的另一个有用的例子可以在IEC 61508中找到[ 3 ] 。对展示了其如何根据软件完整性等级（SIL ）（风险等级的另一术语表达）来区分测试技术的标准的一段引用，见下表：
　　1.该标准覆盖了静态和动态测试技术，并具有各种测试等级的和用于维护测试的特定表格。

表1.IEC61508软件完整性等级（R：推荐，HR:强烈推荐）
　　另一个例子来自于DO-178B[1]。 此标准还采用了方法——将进行的强度测试应源于风险等级。
　　这些标准规定的测试方法，应用于每个安全级别，以及恰当的完成标准（见表2中的示例）。 专业测试应意识到：有用的标准是可获得的，如在IEC61508[3]和DO-178B[1]中，两者可以在使用测试设计技术定义不同的基于风险的测试方法时提供支持和灵感。

表2. 测试组件基于风险的方法 [1]
　　专注产品风险
　　详细解释所有提到的测试设计技术、它们如何与测试强度相关、它们如何相互关联、以及他们如何在内部变化，都超出了本文的范围。但是很明显，为定义一个完整的测试方法，对测试设计技术有详细了解是必须的。
　　许多测试员都是技术型的，有时往往会在测试设计技术的技术性中迷失自己。他们很可能设计和编写出很棒的测试用例，但这些测试用例真的有必要和正确吗？
　　本文的主题是：产品风险应是选择是否测试设计技术是必要的，哪些是需要的，及他们该如何应用的主要驱动力。
　　经常去想想你为什么要申请测试设计技术及目标是什么。测试设计技术绝不是目标，他们只是达到目标的手段。专注对开发一个好产品很重要的事物。我相信这就是敏捷宣言所声明的“全面文档层面的工作软件”的意思。
　　使用测试设计技术肯定不是一件坏事（相反这是件好事），但要在他们有重要意义的，有附加价值的地方使用它们。用敏捷的，有效率的和以风险为本的方式使用他们。