TA的每日心情 | 无聊 前天 09:05 |
---|
签到天数: 1050 天 连续签到: 1 天 [LV.10]测试总司令
|
软件测试用例质量的评估,可以考虑下面3个方面的因素:
第一,根据测试用例的形式评估其质量,主要包括:
1)测试用例与需求规格说明中需求条目的可追溯性,例如:我们要求每个需求条目至少有1个测试用例与之对应。目的是为了评估测试的需求覆盖率,以及分析需求发生变更的时候,对测试修改工作的影响程度;
2)测试用例有无明确的期望结果。通常来说,测试用例的每个执行步骤,都应该明确描述期望的结果,以保证测试人员可以与测试实际结果进行比较,并分析是否需要提交缺陷报告,或者修改测试用例。
3)是否满足公司内部定义的测试用例模板。例如:每个公司都可能定义了测试用例模板,比如定义了“测试类型”,要求每个测试用例和测试类型进行关联,并要求每个功能的测试用例需要覆盖所有的测试类型,例如:可移植性、互操作性、稳定性等。
第二,根据测试用例覆盖率评估其质量,主要包括:
1)需求的覆盖率,例如:我们主要负责系统测试级别,因此测试用例的需求覆盖率要求必须达到100%。
2)质量特性的覆盖率,例如:我们在测试用例模板中采用测试类型的概念,要求每个功能的测试用例,必须100%覆盖所有的测试类型。而测试类型的定义,参考了ISO 9126质量模型,以前缺陷的分析,需求条目的分析等。
3)测试平台的覆盖率,例如:针对我们目前的通信产品,每个功能都需要在不同平台上运行,例如:不同的网元类型、接口类型、业务类型等。测试用例的对这些平台的覆盖率,也要求达到100%。
第三,根据测试用例的有效性评估其质量,主要包括:
1)测试用例的缺陷发现率,我们采用的计算方法是“系统测试发现的缺陷数目除以执行的测试用例数目,而得到的百分比”。
2)脚本化测试的缺陷发现率,我们采用的计算方法是“根据测试用例步骤发现的缺陷数目/总发现的缺陷数目,得到的百分比”。假如这个百分比很低,说明设计的测试用例有效性方面比较差,而通过探索性测试发现的缺陷比例更高。
3)遗漏到用户现场的缺陷率,我们采用的计算方法是“6个月内用户现场反馈的缺陷数目,除以系统测试级别发现的缺陷数目与6个月内用户现场反馈的缺陷数目之后,得到的百分比”。
每个公司和测试团队在评估测试用例质量方面会存在不同的度量指标,基本的要求是这些度量指标简单容易收集,并且有利于改进测试过程和测试团队的测试能力,但切记不会针对测试人员个人的能力与绩效的评估。
|
|