目录
2、测试类型的设计和安排,将测试类型安排在最合适对应的测试级别中来识别和缓解产品风险
3、测试设计方法,在每个测试级别和类型中,都需要进行测试设计和执行的工作
4、测试执行方法,对每个测试级别和测试类型都具体的设计安排对应的测试执行手段
一、风险分析和缓解措施设计
1、风险识别
-
风险识别是基于风险的测试的起始点,目前并没有一个确定机械化的算法来保证找出所有的风险,通常方法:专家访谈、头脑风暴、风险框架或检查表来尽量保证识别完整的风险
2、风险定性分析
-
风险影响和发生概率评估
-
风险优先级
3、风险定量风险
4、风险与缓解措施
二、风险识别
1、风险识别的方法
-
专家访谈
-
可以得出基础的风险列表或对已有的风险列表进行补充
-
-
头脑风暴
-
邀请利用相关方参与,列举出利益关心的风险
-
-
采用风险框架、检查表
-
提供风险识别的历史经验和尽量完整、全局的视角
-
2、其他获取风险的来源
-
各种规格说明
-
实现的细节
-
销售、市场资料
-
竞争对手的研究
-
独立评估机构
-
过去历史项目
-
个人的历史经验
3、通用的风险识别检查表
![](https://i-blog.csdnimg.cn/blog_migrate/3f97f5e7f59f9a4681740666357a4804.png)
三、风险影响和发生概率评估
1、风险的影响
-
风险发生的可能性、风险一旦发生可能造成的影响
-
风险的影响是产品固有的特性,并不受测试活动本身并没有关系
-
风险影响的大小与产品的使用场景有关
2、风险发生概率和影响分析的基本框架
![](https://i-blog.csdnimg.cn/blog_migrate/f6ac90ca2c10523a858442de759b38b5.png)
3、实际上基于风险的测试计划中的风险分析
(1)区分能通过软件测试活动来缓解的风险
(2)从业务出发,估计风险的影响
(3)从业务出发,估计在最终产品允许的残留风险发生的概率
-
上市后产品中允许的残留风险发生概率估计--设计质量目标
-
企业组织的质量政策中有相关的规定
-
对于没有相关规定的组织或项目
-
与利益相关方沟通,参考竞品来获取对产品质量的总体期望
-
对于全新的产品或无法从利益相关方处获取信息的,则从测试经理的经验/测试团队的头脑风暴/产品的使用场景的列举,推算使用场景中出现失效的受容忍程度。
-
-
(4)从产品开发测试出发,了解当前产品中风险发生的概率
-
对产品开发测试中遇到风险发生概率的处理原则
-
当功能还未开发时(或完成度很低时),其发生概率100%
-
当开始测试活动时,测试结果的通过率可以近似的作为开发测试中遇到风险的概率
-
四、风险的优先级
1、基于风险的测试的基本思想
-
把软件发布之后会面临的风险分解到对应的软件质量特性上面去,根据对应的质量特性,再决定应该采用什么样的措施、什么样的策略来进行测试。
2、风险优先级
(1)R=P*I
-
如果风险发生的概率确定,则风险造成的负面影响越大,一旦发生所造成的损失也越大,也应该优先处理。
-
所以风险优先级(R)、发生概率(P)和影响(I)的关系,可以初步总结以下公式:R=P*I
(2)R=(C-P)*I
-
测试活动解决的是当前的开发测试活动中遇到风险的概率(C)与期望产品上市后发生风险的可能性(P)之间的差距。所以对于软件测试计划,其要对应的风险的优先级, 应该修正为如下公式:R=(C-P)*I
五、风险与缓解措施:测试策略
![](https://i-blog.csdnimg.cn/blog_migrate/f8f9e1b093639b2cd9e95e0adc9fe077.png)
1、测试级别的划分,能对应解决软件开发的复杂性问题
2、测试类型的设计和安排,将测试类型安排在最合适对应的测试级别中来识别和缓解产品风险
-
单元测试:擅长发现代码级别的缺陷,擅长识别详细设计和编码错误
-
集成测试:擅长发现模块间交换的缺陷,擅长识别功能设计或架构设计的错误造成
-
系统测试:擅长发现软件需求的缺陷,识别需求的风险,包括各种非功能的风险
-
验收测试:擅长发现软件需求的缺陷,重点在于识别软件行为是否符合客户的使用场景
3、测试设计方法,在每个测试级别和类型中,都需要进行测试设计和执行的工作
-
白盒测试技术
-
黑盒测试技术
4、测试执行方法,对每个测试级别和测试类型都具体的设计安排对应的测试执行手段
-
自动化测试
-
是集成测试的主要执行方法,由集成CI工具触发
-
-
手动测试
六、一般性的缓解措施指南
系统复杂性非常高,推荐生成多级测试计划,推荐采用区分主测似计划和分级别的测试计划
1、主测试计划
-
对测试级别进行定义和划分
-
定义各个测试级别所应达成的质量目标
-
可以对各个级别的测试活动所应采取的测试类型、测试技术、工具和环境做出初步的指导性说明,并对测试活动所需要的预算进行一个框架性定义
-
系统的复杂性风险是大型软件系统的核心风险之一
2、分级别的测试计划
-
各团队指定的测试负责人来分别制订各自测试级别的测试计划
七、设计风险缓解措施的基本步骤
1、安排测试级别来对应软件系统的复杂度风险
2、根据各个测试级别的特点和资源情况安排,通过特定的测试类型在本级别内对应特定的质量特性风险
3、在安排测试类型后,考虑采用哪些测试设计方法设计测试用例
4、根据被测试对象的交互方式、可能的测试环境、测试工具的情况来设计测试执行的方法
八、测试级别与测试实施
1、测试设计和实施的一般性指南
选择测试设计技术的通用规则:使用测试条件描述形式最接近功能或质量特性的描述方式的测试设计技术
(1)各测试设计技术对应的测试条件描述
-
等价类划分:测试条件描述形式时数据区间或集合
-
边界值:有序的或者有边界的
-
分类树:多种复杂的情况和参数取值,互相独立,又没有缺漏的子集
-
语法测试:将需求规格描述转化未BNF范式
-
组合测试:多个参数取值和不同取值共同作用的需求规格
-
判定表测试:在输入参数取值和输出之间规定了从输入取值得到输出的逻辑规则
-
因果图测试:本质上与判定表一致
-
状态转移测试:某个软件的多个行为,并且这些行为能够被抽象未状态迁移模型
-
场景测试:集合适合任何功能
-
随机测试:对输入的概率描述或分布描述
-
各种基于规格说明书的测试设计方法:控制流图描述
(2)测试执行方法的设计和指导的内容
-
测试执行的环境设计
-
测试执行的方法定义
-
测试执行的周期和回归策略
2、单元测试设计与实施
依据单元(模块、组件、函数)的详细设计书或代码。
方法为灰盒测试设计,综合运用基于规格说明的测试设计技术和基于结构的测试设计技术来设计测试用例
-
对单元的明确功能选择基于规格说明的测试设计技术
-
对于单元输入的各项参数可以采用等价类划分、边界值、组合测试技术
-
对于有着明确的状态和转移定义的模块,应采用状态转移测试进行覆盖
-
对于有着明确逻辑判定的规格要求的,应采用判定表技术
-
通过代码覆盖度量工具可对执行以上测试用例时达到基于结构的测试设计技术覆盖进行度量;未能达到覆盖目标的部分代码,通过基于结构的测试设计技术来补充测试用例进行覆盖
3、集成测试
以基于规格说明的测试设计方法为主,基于结构的测试设计技术补充前者
(1)设计与实施
-
以场景测试为主要测试设计技术
-
为了在场景中找出异常或极端的情况,可对通信消息的内容参数或调用的接口参数及返回值,应用等价类和边界值的方法
-
对于通过异步通信来进行的模块间交互协调,还应考虑异步通信带来的固有风险
-
对于状态转移的模块间交互协调,可采用状态转移测试,测试多个状态机间同步的情况
-
语句测试,设计测试用例覆盖序列图、活动图、流程图的每个交互和处理
-
分支测试、判定测试等可用于设计测试用例来覆盖序列图、活动图、流程图里的条件判定
(2)集成测试工具应具备的功能
-
获取模块间调用的信息
-
根据测试要求匹配模块间调用(响应)
-
根据测试要求修改模块间调用(响应),包括修改调用的方法和参数内容
-
根据测试要求重复模块间调用(响应)
-
根据测试要求丢弃模块间调用(响应)
-
根据测试要求延迟发生模块间调用(响应)
4、系统测试设计与实施
主要应用基于规格说明的各种测试技术,手工测试和自动化测试组合
-
主要应用基于规格说明的各种测试技术
5、验收测试设计与实施
一是从系统测试用例随机抽取一些基本使用场景,二是从用户实际使用的场景出发,采用场景发来设计测试用例
-
从系统测试用例中随机抽取一些基本使用场景
-
从用户实际的使用环境中,能够正常使用功能,没有基本功能的异常
-
通常以手工测试为主
九、测试估算与平衡策略
1、测试估算的方法指南
(1)宽带德尔菲法(专家法)
-
专家法,各自独立地对识别风险和风险缓解措施进行头脑风暴估算
(2)基于历史数据法
-
参考过去项目的历史经验;没有历史数据,抽取一部分措施内容为工作任务,收集工作效率、返工次数等作为基础进行测试估算
(3)根据测试级别、测试类型和测试技术进行测试估算
-
可以从功能和风险的测试类型设计
2、测试估算步骤
-
测试设计、测试执行、测试报告
3、测试策略的综合和平衡
- 没有统一的策略,因为在不同的环境下利益相关方的要求不一样