天天看点

软件评测师-基于风险的测试

一、概述

1.风险:当前未发生而未来有可能会发生并造成一定负面影响的事件

2.软件测试是通过各种测试活动来发现软件或服务中是否存在引起风险的缺陷

3.功能和非功能:最终体现在产品或服务风险上

4.软件开发过程中的各种技术问题、资源问题、管理问题也体现在产品开发过程的风险上

 5.风险相比软件测试和开发的专业知识更容易被各方理解和接受,应该围绕发现风险、缓解风险的目标来建设测试团队的能力

6.测试策略和测试计划的制定本质上与制定 商业计划、做职业计划等工作一样,第一是面对不确定性、第二是面对有限资源,第三是试图做出当前时间点的最佳决策

7.测试计划内容的核心是解决图中所示的4个问题

软件评测师-基于风险的测试

   制定测试计划步骤:

    分析-识别风险、选项、估算、平衡;形成决策

二、风险分析和缓解措施

1.风险识别是基于风险的测试的起始点,目前并没有一个确定机械化的算法来保证找出所有的风险,通常方法:专家访谈、头脑风暴、风险框架或检查表来尽量保证识别完整的风险

  专家访谈:可以得出基础的风险列表或对已有的风险列表进行补充

  头脑风暴:邀请利用相关方参与,列举出利益关心的风险

  风险框和检查表:提供风险识别的历史经验和尽量完整、全局的视角

2.风险来源获取:各种规格说明、实现的细节、销售市场资料、竞争对手的研究、独立评估机构、过去历史项目、个人历史经验

3.风险可能发生影响事件:风险发生的可能性、风险一旦发生可能造成的影响

4.风险计划还应区分该风险是否与软件质量相关,与软件质量无关的则不应纳入测试计划的分析工作

5.软件测试活动究竟在产品风险缓解上能起到什么作用

软件评测师-基于风险的测试

 6.基于风险的测试计划中的风险分析:区分能通过软件测试活动来缓解的风险;从业务出发,估计风险的影响;从业务出发,估计在最终产品中允许的残留风险发生的概率;从产品开发测试出发。了解当前产品中风险的概率

7.风险体现为某种软件的质量的特性的缺陷,则能通过测试活动来发现风险从而得到缓解

8.风险的影响估计,必须控制风险影响估算这个活动本身的复杂度工作量

9.上市后产品中允许残留风险发生概率的估计,其实是设计产品的质量目标

10.与利益相关方沟通,参考竞品来获取对产品质量的总体期望

11.由测试经理从自身的经验出发,或对组织测试团队进行头脑风暴,推算出使用场景中出现失效的受容忍度

12.产品开发测试中遇到风险概率的估计原则:

  当功能还未开发时,其发生的概率时100%;

  当开始测试活动时,则测试结果的通过率可以近似地作为开发测试中遇到风险的概率

  公式:R=(C-R)*I

  

软件评测师-基于风险的测试

 13.通过设计缓解风险的一套办法:

  测试级别的划分,能对应解解决软件开发的复杂性问题;

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

  测试设计方法,在每个测试级别和类型中,都要进行测试设计和执行的工作

  测试执行方法,对每个测试级别和测试类型都应具体地设计安排对应的测试执行手段

14.一般性的缓解措施指南

  系统复杂性非常高,推荐采用区分主测似计划和分级别的测试计划

  一般对测试结拜进行定义和划分,定义各个测试级别所达成的质量目标,主要应对系统的复杂性风险,对各个级别的测试活动所采取的测试类型、测试技术、工具和环境做出初步的指导性说明

15.设计风险环境措施基本步骤

  1)安排测试级别来对应软件系统的复杂度风险

  2)通过特定的测试类型在本级别内对应特定的质量特性风险

  3)考虑采用哪些测试设计方法设计测试用例

  4)根据被测对象的交互方式设计测试执行的方法

16.测试步骤顺序,基于风险原则:

  1)风险导出相关质量特性,而非单纯考虑质量特性

  2)由质量特性得到测试类型,避免安排无意义的测试活动来进行某些特定目标的测试

  3)根据测试类型考虑测试设计方法,更有针对性

  4)更加测试类型和测试级别设计测试执行的方法

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

  单元测试:擅长发现代码级别的缺陷,擅长识别详细设计和编码错误

  集成测试:擅长发现模块间交换的缺陷,擅长识别功能设计或架构设计的错误造成

  系统测试:擅长发现软件需求的缺陷,识别需求的风险,包括各种非功能的风险

  验收测试:擅长发现软件需求的缺陷,重点在于识别软件行为是否符合客户的使用场景

软件评测师-基于风险的测试

 三、测试级别与测试实施

1.选择测试设计技术的通用规则:使用测试条件描述形式最接近功能或质量特性的描述方式的测试设计技术

  等价类划分:测试条件描述形式时数据区间或集合

  边界值:有序的或者有边界的

  分类树:多种复杂的情况和参数取值,互相独立,又没有缺漏的子集

  语法测试:将需求规格描述转化未BNF范式

  组合测试:多个参数取值和不同取值共同作用的需求规格

  判定表测试:在输入参数取值和输出之间规定了从输入取值得到输出的逻辑规则

  因果图测试:本质上与判定表一致

  状态转移测试:某个软件的多个行为,并且这些行为能够被抽象未状态迁移模型

  场景测试:集合适合任何功能

  随机测试:对输入的概率描述或分布描述

  各种基于规格说明书的测试设计方法:控制流图描述

2.测试设计技术的选择直接决定测试工作量投入的大小

3.测试计划中包含对测试执行方法的设计和指导

  测试执行的环境设计、测试执行的方法定义、测试执行和回归策略

4.单元测试设计与实施:依据单元(模块、组件、函数)的详细设计书或代码

  方法为灰盒测试设计,综合运用基于规格说明的测试设计技术盒基于结构的测试设计技术来设计测试用例

5.单元测试设计参考规则:

  以场景测试为主、应用等价类和边界值方法、考虑异步通信带来的固有风险、状态转移测试、语句测试、分支测试

6.集成测试以基于规格说明的测试设计方法为主,基于结构的测试设计技术补充前者

7.集成测试工具具备以下功能:

  获取模块间调用的信息、匹配模块间调用、修改模块间调用、重复模块间调用、丢弃模块间调用、延迟发送模块间调用

8.自动化测试是集成测试的主要执行方法,由集成CI工具触发

9.系统测试设计与实施:主要应用基于规格说明的各种测试技术,手工测试和自动化测试组合

10.验收测试:一是从系统测试用例随机抽取一些基本使用场景,二是从用户实际使用的场景出发,采用场景发来设计测试用例

  验收测试实施:通常以手工测试为主

四、测试估算与平衡决策

1.测试估算方法

  1)宽带德尔斐法(Delphi),专家法,各自独立地对识别风险和风险缓解措施进行头脑风暴估算

  2)基于历史数据法:参考过去项目的历史经验;没有历史数据,抽取一部分措施内容为工作任务,收集工作效率、返工次数等作为基础进行测试估算

  3)根据测试级别、测试类型和测试技术进行测试估算,可以从功能和风险的测试类型设计