前言
软件测试的度量,Bug数量是重要的指标,但是不能简单的用Bug数目来衡量,因为优秀的软件本身的Bug数目就很少,这不是软件测试人员的失败,有些质量很差的软件Bug极多,也不能简单证明测试人员的成功。
套用《Google软件测试之道》3.3 章节,Google Docs测试工程师Lindsay
Webster负责组织包括SET在内的整个团队的测试策略。
他的观念:“测试的退出标准应该是:你有足够的信息,剩下的bug都是属于那些使用率较低,出问题之后对用户影响也较低的模块。”
优秀的测试应该是完成之后得到的数据足够支撑对产品质量的认识。
下面是软件测试度量的理解:
1. 测试度量的含义
我们不能直接从产品质量来推出测试的效果,而应该考虑软件测试的产出物和过程,并进行科学的度量。
产出物有三,可以用来推测测试人员的工作质量:
1.1 测试用例
1.1.1 全面性和完整性
评估测试用例是否涵盖了需求和功能的所有方面。检查用例是否覆盖了各种场景、边界值和异常情况,以确保测试的全面性和完整性。
1.1.2 可读性和可理解性
测试用例应该具有明确的描述和步骤,以便测试人员能够轻松理解并执行测试。
1.1.3 一致性
测试用例应该遵循一致的格式、命名规范和约定,以便于管理和执行。
1.1.4 可重复性
测试用例应该能够在不同的环境和条件下重复执行,并产生相同的结果。
1.1.5 独立性
测试用例应该相互独立,不依赖于其他测试用例的执行结果。
1.1.5 其余
评估测试用例的效率、强壮性、可维护性等
1.2 ISSUE & Bug
需要考虑 ISSUE & Bug 是否清晰完整的描述了 Bug 发生的前提、环境、Bug 的现象、是否课重复出现等。
1.3 测试报告
测试报告通常需要包括以下的内容,并要求清晰完整和语言简练。
- 测试目标和范围
- 测试环境和工具
- 测试策略和方法
- 测试用例和执行结果
- 缺陷报告和修复情况
- 测试总结和建议
2. 测试度量的目的
测试度量的目的是为了项目质量服务,让测试活动更加规范和科学,创造更多的测试价值。
3. 测试度量的原则
- 制定明确的度量目标:如测试用例的覆盖率需要达到90%,用例的执行率需要达到100%等。
- 度量标准的定义具有一致性、客观性:如覆盖率是指功能覆盖率,还是代码覆盖率等。
- 度量方法尽可能简单、可计算
- 度量数据的收集应该尽可能自动化:应该在测试过程中随时征集,而不是等待考核时候再查数据或者推导数据。
4. 测试度量的方法和应用
4.1 加权法
加权法的前提是制定缺陷级别评估规范 ,需要考虑 Bug级别、Bug类型 、Bug及时性 、Bug重现率。
4.2 定性评估
定性评估需要考虑 Bug类型的分布 、Bug重现率、Bug录入的清晰程度、简明程度等、新颖性。
4.3 Bug 综合评价模型
Bug 综合评价模型需要结合加权法和定性评估 。
4.4 测试覆盖率统计
测试覆盖统计需要考虑代码覆盖、功能模块覆盖、需求覆盖。
4.5 测试用例文档产出率和测试用例产出率
4.6 硬指标
硬指标包括缺陷逃逸率、测试效率等。
4.7 软指标
软指标包括团队建设、知识共享、流程遵守等。