【软考软件评测师】基于风险的测试技术

【软考软件评测师】基于风险的测试技术

一. 基于风险的测试概述

1）范围确立

在项目实践中制定测试计划阶段的主要任务是确定要测试什么，不要测试什么，将测试的内容目标以及要达到的质量要求尽量明确，并且让所有利益相关方都能理解，并达成共识。

2）如何测试

明确要测试什么以后，还要解决如何测试的问题。而如何测试又可以分为如何设计测试和如何执行测试。
设计测试需要明确测试目标，执行测试明确采用的测试工具，如何操作被测试对象来进行输入，获取和检查输出。确定测试执行的测试环境；确定测试轮次，每个测试轮次是否进行回归测试，是否进行增量测试等内容。

3）测试资源

确定了要测试什么和如何测试以后，还需要安排测试实施所需要的各种资源，包括人力资源，设备资源和硬件资源，工具和费用资源。
在基于风险的项目实践中，测试计划制定阶段，依据不同的信息来源，可能会导致出现测试偏差。

4）测试风险

能体现测试本质并容易被其他利益相关方所理解的概念只有一个，那就是风险的概念。风险是当前没有发生而将来有可能会发生的并造成一定的负面影响的事件。
软件测试是通过各种测试活动来发现软件或者服务中是否存在引起风险的缺陷，并反馈风险信息给开发团队，由开发团队来修复缺陷，从而降低风险的活动。
功能和非功能的质量特征最终体现在产品或服务的风险之上。
软件开发当中的各种技术问题，资源问题，管理问题，也体现在产品开发过程的风险之上。

5）风险与团队建设

风险相比于软件测试和软件开发的专业知识，更容易被各方理解和接受。应该围绕发现风险，缓解风险的目标来建设测试团队的能力，而非反过来由测试团队的能力来决定要处理哪些产品风险。
最后需要强调的一点是测试策略和测试计划的制定本质上与制定商业计划做职业计划等工作一样，第一是面对不确定性，第二是面对有限资源，第三都是作出当前时间点上的最佳决策。

二.制定测试计划的三个步骤

基于风险的测试通常应用于商业产品，非安全攸关的产品或者服务。
测试计划内容的核心是解决：测试策略，测试时间表，测试资源，风险和缓解措施来开展的。

1）分析—识别风险

将风险进一步分解，确定优先级，排序。然后通过质量特征为桥梁，将仅与业务相关的风险与软件特征联系起来。

2）选项，估算，平衡

此阶段实际上是一个循环改进的过程。对测试阶段进行合理安排，确定每个测试阶段对应的测试范围和测试类型，设计技术和测试执行方法。

3）形成决策

此阶段通常是与各个利益相关方进行沟通，形成决策。从最重要的利益相关方进行沟通，形成最终的测试计划，同时获得利益相关方的认可。

三.风险识别

1）概念定义

风险识别是基于风险测试的起始点。后续的所有分析和决策都依赖于此项工作的成果。
目前并没有一个稳定的机械化的算法来保证找出所有的风险，通常的做法是通过专家访谈，头脑风暴和采用风险框架或检查表的方式来尽量保证识别出完整的风险和客观的评估其优先级。

2）专家判断

专家访谈可以得出基础的风险列表或者对已有的风险进行补充；头脑风暴可以邀请主要的利益相关方进行参与，花费两个小时左右的时间，列举出关键的利益相关者关心的风险；风险框架或者检查表能提供风险识别的历史经验和尽量完整全局的视角。

3）风险检查表

一般对于商业产品（包括各种消费电子，互联网，嵌入式系统）可以采用通用风险识别框架，还可以根据需要进一步分解更多层。
通用的风险分析检查表是在项目中可用并扩展的检查表。一般测试组织可以从这个通用的检查表出发，基于实践的经验教训，
不断的扩展和维护，从而形成能涵盖组织产品或服务的完整的风险识别检查表。

4）其他途径

风险识别除了以上描述的方法之外，还可以从以下的来源来获取风险：
各种规格说明；
实现的细节；
销售，市场资料；
竞争对手的研究；
独立评估机构；
个人的历史经验；

四.风险分析

1）风险两大要素

概率：风险发生的可能性
损失：风险一旦发生可能发生造成的影响
在制定基于风险的测试计划时，对识别的风险还应该区分该风险是否与质量相关。
在制订基于风险的测试计划的时候，对于识别的风险还应该区分该风险是否与软件质量有关，与软件质量无关的则不应该纳入测试计划的分析当中。
如果非软件手段的缓解措施能够缓解软件风险（或决定由非软件手段的缓解措施来缓解风险），则这样的风险可以认为是：非软件质量相关的风险。

2）基于风险测试计划中的风险分析需要

1）区分能通过软件测试活动来缓解的风险；
2）从业务出发，估计风险的影响
3）从业务出发，估计在最终产品中允许的残留风险发生的概率；
4）从产品开发测试出发，了解当前产品中风险发生的概率。
一般而言，如果某个风险体现为某种软件的质量特征的缺陷，则应该能通过测试活动来发现风险从而得到缓解。
需要特别注意的是，风险的影响估计的目的是后续对测试活动的分配形成指导，所以必须控制风险影响估算这个活动本身的复杂度和工作量。

3）设置质量目标

对上市后产品允许的残留风险发生的概率的估计，其实就是设置产品的质量目标。通常很多企业组织在组织质量政策会议中都会有相关的规定。对于没有规定的相关组织或者项目，则可以采用以下的方法：
1）与利益相关方沟通，参考竞品来获取对产品质量的总体期望（以允许的某些失效风险为例），然后以此希望作为底线，对产品的关键功能，适当做一定程度的提高（即流出一定的缓冲），对产品的次要功能，直接采用该期望，而对无关紧要的功能，适当降低。
2）对于全新的产品或者无法从利益相关方获取信息的，则可以由测试经理从自身的经验出发，或组织测试团队进行头脑风暴，或对产品的使用场景进行举例，并推算使用场景中出现失效的能够容忍的程度。

五.风险缓解措施

在已经有了清晰的风险列表依据风险优先级的信息之后，就需要集中注意力来设计缓解风险的一套方法。

1）测试级别的划分

能对应解决软件开发的复杂性问题。将一个大规模复杂性的系统进行分解，从小的模块开始（单元测试），逐步放大到整个系统的级别。

2）测试类型的设计和安排

将测试类型安排在最适合对应的测试级别中来识别和缓解产品风险。

3）测试设计方法

在每个测试级别和类型中，都需要进行测试设计和执行的工作。

4）测试执行方法

在每个测试级别和测试类型都应具体的设计安排对应的测试执行手段。

5）一般性的缓解措施

通常对于一个完整的产品测试计划，由于整个产品系统的复杂度相当的高，单个团队无法单独处理，需要多人多个团队分工进行，对于这样的情况，推荐采用区分主测试计划和分级别测试计划的做法。

6）主测试计划

在主测试计划当中一般对测试级别进行定义与划分，定义各个测试级别所应达成的质量目标。即在主计划之中主要应对系统复杂性的风险，因为这个风险是大型复杂软件系统中的核心风险之一。
同时可以在主计划当中对各个级别的测试活动所应采取的测试类型,测试技术，工具与环境作出初步的指导性说明，并对测试活动所需要的预算进行一个框架性的定义，然后由负责各测试级别的团队指定测试负责人来分别制定各自级别的测试计划。

7）基本步骤

设计风险缓解措施可以采用以下的基本步骤：
1）首先安排测试级别来对应软件系统的复杂度风险
2）根据各个级别的特点和资源安排情况，通过特定的测试类型在本级别内对应的特定的质量特征风险
3）在安排测试类型之后，考虑采用哪些测试设计方法设计测试用例。
4）根据与被测试对象的交互方式（如何进行输入，如何获取输出，如何进行结果比较），可能的测试环境测试工具的情况来设计测试执行的方法。

8）基于风险的原则

1）由风险导出相关的质量特征，而非单纯考虑质量特征，避免扩大某些不必要的质量特征的测试，忽略应该覆盖到的质量特征的测试
2）由质量特征得到测试类型，避免了安排无意义的测试活动来进行某些特定的目标的测试。保证安排的测试类型都是为了对应某项风险。
3）根据测试类型考虑测试设计方法，更有针对性
4）根据测试类型和测试级别设计测试执行的方法，而非相反。

六.主测试计划风险缓解

在制订主测试计划时，应根据每个测试级别所能缓解的风险，安排适合的测试级别并将风险处理分配到各个级别的测试。

1）单元测试

擅长发现代码级别的缺陷，擅长识别功能设计或架构设计的错误造成的风险。
不擅长识别功能设计和软件需求错误造成的风险

2）集成测试

擅长发现模块之间交互的缺陷，擅长识别功能设计或架构设计的错误造成的风险。
不擅长发现代码级别的错误。

3）系统测试

擅长发现软件需求的缺陷。所以它擅长识别需求的风险。包括各种非功能的风险，不擅长识别代码级别和设计级别的风险。

4）验收测试

重点在于识别软件行为是否符合需求规格说明以及客户的使用场景，是否易用等质量特征。

5）特定类型的测试与测试级别安排原则

功能性测试：通常在各个级别中都应安排功能测试；
可靠性测试：通常在各个级别中也都安排；
性能测试：通常安排在集成测试及之后的测试环节当中
信息安全测试：通常安排在系统测试级别；
易用性测试：通常安排在系统测试级别和验收测试级别中；
维护性测试：通常安排在系统测试级别
兼容性测试：通常安排在系统测试的级别中
可移植性测试：通常安排在系统测试级别中；

七.测试技术的选择原则

各种基于规格说明的测试方法，如语句覆盖分支覆盖等基于控制流来进行测试设计，当某个需求规约的描述形式可以自然方便的通过控制流图来描述时适用。
在实践过程中，需要注意选取适合被测对象需求规格描述的测试技术，而测试设计技术的选择直接决定了测试工作量的大小。
利用测试设计技术设计的测试用例，需要在测试环境中执行，才能真正的识别软件产品中可能存在的风险。所以测试计划中还应该包含对测试执行方法的设计和指导。
选择使用测试条件描述形式最接近的功能或质量特征的描述方式的测试设计技术。各测试设计技术对应的测试条件描述形式如下：

1）等价类划分

该测试技术的测试条件描述形式是数据区间或者是集合。

2）边界值

该测试技术的测试条件描述形式是基于等价类划分的，所以只要功能描述的内容是有顺序的或者有边界的，就可以采用此测试技术

3）分类树

当功能描述过程中包含多种复杂的情况和参数取值，而这些情况和参数取值能被划分为多个相互独立，又没有缺漏的子集的时候，这样的功能描述可以用树的形式来描述。

4）语法测试

该测试技术的测试条件描述形式是将需求规格转化为巴克斯范式，所以如果产品的某段需求描述适合采用BNF范式来描述，则其应当选择采用这种方法。

5）组合测试

涉及多个参数取值和不同的取值共同作用的需求规格描述适合采用组合测试的技术。

6）判定表测试

当需求规格描述多个输入参数和规格取值，多个输出并在输入参数取值和输出之间规定了从输入取值得到输出的逻辑规则。

7）因果图测试

因果图分析的语义本质上与判定表一致，只是采用了不同的模型描述，所以适合用判定表测试技术进行的测试设计的功能同样也适合用因果图测试，区别在于不同的模型描述。

8）状态迁移测试

当需求规约描述的是某个软件的多个行为，并且这些行为能够被抽象为状态迁移模型，则适合采用此测试设计方法

9）场景测试

该方法几乎适合任何功能，只要功能描述的信息是不同系统模块之间的交互，互动行为的都可以采用此技术

10）随机测试

需求描述中出现对输入的概率描述或分布描述，则可以考虑使用本测试设计方法。

八.单元测试的设计与实施

在单元测试级别，设计测试用例的依据是单元（模块，组件，函数）的详细设计书和代码。
单元测试的测试用例通常是代码的形式，即用编程语言来描述测试用例。
单元测试的测试环境通常与开发编程环境是相同的，由集成开发环境，编译器，版本管理系统等组成。

单元测试设计方法

对单元的明确功能，采用前面描述的方法来选择基于规格说明的测试设计技术。
对于单元测试输入的各项参数，可以采用等价类划分，边界值组合测试等技术
对于有着明确的状态和转移定义的模块，应该采用状态迁移测试进行覆盖。

九.集成测试设计与实施

一般使用灰盒测试的方法来实施，其具体的方法是综合运用基于规格说明的测试设计技术（黑盒测试）和基于结构的测试设计技术（白盒测试）来设计测试用例。
以场景为主要测试设计技术。
为了在场景中找出异常或者极端的情况，可以对通信消息内容的参数或者调用的接口参数及返回值，应用等价类和边界值方法。
对于通过异步通信来进行的模块之间交互协同，还应考虑异步通信带来的固有风险：消息丢失，内容错误，重复，超时，响应延迟与请求的重发，消息流程的交叉等。
对于有状态迁移的模块之间的交互协同，可采用状态迁移测试，测试多个状态机之间同步的状况，还可以应用基于结构的测试设计技术。
语句测试：设计测试用例覆盖序列图，活动图，流程图的每个交互和处理。
分支测试，判定测试等可用于设计测试用例来覆盖序列图，活动图，流程图里的判断条件。
集成测试通常以基于规格的测试设计方法为主，通过基于结构的测试设计技术补充前者的测试用例未能覆盖的部分。

集成测试工具应具备的功能

获取模块之间调用的信息，通常的技术是采用hook技术。
根据测试要求匹配模块之间的调用（响应）
根据测试要求修改模块之间的调用（响应），包括修改调用的方法和参数内容
根据测试要求重复模块之间的调用（响应）
根据测试要求丢弃模块之间的调用（响应）
根据测试要求延迟发送模块之间的调用（响应）
通常集成测试的测试用例的输入与输出和检查是系统软件运行时内部的行为，这样的行为都是在非常短时间内完成的，所以测试基本无法手工完成，自动化测试是集成测试的主要执行方法。
由持续集成工具来触发集成测试的执行，也是一种良好的测试实践。

十.系统测试设计与实施

系统测试当中主要运用基于规格说明的各种测试技术。通常系统测试采用手动测试和自动化测试相结合的方式来实施。由测试人员根据测试用例和用户手册等资料，对系统进行输入，观察其输出等外部行为。目前越来越多的系统测试引入了自动化测试，持续集成工具在系统测试引入自动化测试技术以后也能得到应用，能够定期出发系统的自动化测试。

十一.验收测试设计与实施

验收测试的测试用例一般有两个来源，一个是从系统测试用例中随机抽取一些基本使用场景，第二从用户实际使用的场景出发，采用场景法来设计测试用例。
验收测试的实施通常以手工测试为主，易用性测试还可能通过调查问卷，观察用户的使用行为来寻找需求或者业务逻辑当中隐晦不明，不容易理解和操作不便的问题。

十二.测试估算与平衡决策

1）专家德尔菲方法

召集多位产品领域，开发领域和测试领域的专家，最好能包括产品的利益相关方，各自独立的对风险和风险缓解措施进行头脑风暴的方式进行估算。或者通过访谈来收集有经验的工程师的看法。逐项列举各种测试措施和技术所需要的人力和工期。

2）基于历史数据的方法

即当软件产品在组织内有过类似的经验时，可参考过去项目的历史经验，比如在一系列产品线中某个特定的产品的测试。
采用这个方法的前提是组织内对软件项目有完整的度量数据收集方法。
如果在面对新的产品或者项目时，没有历史数据可以借鉴，则可以选取计划中若干可以典型的测试活动，从中划分很小的一部分测试内容作为工作任务，然后在测试团队中安排若干名平均水平的工程师来完成这项任务，在完成工作期间，收集工作效率，返工次数等度量数据，将收集到的数据作为基础，来进行测试估算。

3）根据测试级别测试技术和测试类型来进行测试估算

可以从测试功能与风险对应的测试类型和测试设计技术出发，逐个的根据功能和测试设计技术来估算可能的测试用例数量。然后根据测试用例的数量，可以估计出测试设计和测试执行一轮的工时。
由于功能描述是确定的，测试设计技术是确定的，而由功能描述分许而获得的测试分析模型也就是确定的，从分析模型中能获得多少测试覆盖项和测试用例也能够基本确定，采用这个方法对功能和风险逐一分析，可以获得覆盖每一个功能，风险和质量特征所需要的测试用例数量。然后以此为核心按公式便可以计算得到。