ACTS:首屈一指的软件测试策略是什么?
RBT就是一种基于风险概率的软件测试策略,即根据软件的复杂性和耦合性、业务的关联性、功能的使用频率、应用场景、可能存在缺陷等来评估风险,并基于风险的严重性来设置/确定测试的优先级,从而根据测试优先级来安排测试资源(人力、时间等)、测试任务的先后次序。这里说的风险,主要指产品的质量风险或产品某些方面存在缺陷的风险,即对产品质量产生不良影响的概率事件,或者说,用户使用软件应用的特征和功能时可能受到的影响,如可能碰到无法使用、服务中断、操作困难或出错等问题。
2. RBT分析方法
风险越高的测试项越要优先进行测试设计和执行,越需要安排专业能力强、经验丰富的研发/测试人员来完成该测试项的设计。基于设计和执行的结果分析,包括对缺陷自身的分析和回溯性分析(回溯到测试用例、回溯到业务/功能/非功能性需求等),反过来可以进一步完善风险checklist和风险评估矩阵。基于风险的测试可用于任何层次的测试,如组件、集成、系统和验收测试,也适用于手工测试和自动化测试,以及探索式测试方式等。
3. RBT分析的价值
举一个简单的例子来说明RBT分析的价值。
假如有一个测试任务,根据测试工作量的评估需要5天才能完成测试,但现在因为业务紧急需求,需要提前三天交付,测试的时间只有2天。如果按部就班进行测试(不考虑加班),测试的覆盖率只有2/5=40%(相对测试计划,假定测试计划的覆盖率是good enough),40%太低,无法达到交付的要求。如果采用RBT策略进行分析,虽然第一天也只执行了20%的测试用例,按照理想的情况(80/20原则),但可以覆盖80%的质量风险(缺陷)。在对剩余的80%测试用例进行分析,第2天执行其中的20%测试用例,可以覆盖剩余的20%质量风险的80%,即再覆盖16%的质量风险(缺陷),这样最理想情况下可以达到96%的风险覆盖率,即使不能达到理想状态,也远远高于40%,在时间特别有限的情况下,基本达到产品发布的要求。
4. RBT分析在持续测试中的应用与价值