写作质量测试

时间:2008-10-12 19:02:21

标签: testing

我们知道在评估测试代码的质量时,代码覆盖率是一个很差的指标。我们也知道测试语言/框架是浪费时间。

另一方面,我们可以使用哪些指标来确定质量测试?您是否有任何最佳实践或规则可以帮助您识别和编写更高质量的测试?

7 个答案:

答案 0 :(得分:15)

  1. 确保您的测试彼此独立。测试不应取决于其他测试的执行或结果。
  2. 确保每个测试都有明确定义的输入标准,测试步骤和退出标准。
  3. 设置需求验证可跟踪性矩阵(RVTM)。每项测试都应验证一项或多项要求。此外,每项要求都应至少通过一次测试来验证。
  4. 确保您的测试可识别。建立一个简单的命名或标签约定并坚持下去。记录缺陷时引用测试标识符。
  5. 像处理代码一样对待您的测试。拥有一个反映软件开发过程的测试软件开发过程。测试应该有同行评审,受版本控制,有变更控制程序等。
  6. 对您的测试进行分类和整理。根据需要,可以轻松找到并运行测试或测试套件。
  7. 让您的测试尽可能简洁。这使它们更容易运行和自动化。最好是进行大量的小测试,而不是一次大型测试。
  8. 当测试失败时,可以轻松查看为什么测试失败。

答案 1 :(得分:5)

确保编写测试简单快捷。然后写下很多。

我发现很难提前预测哪些测试最终会失败,或者很长一段路要走。我倾向于采用分散枪的方法,如果我能想到它们,就试图攻击角落。

另外,不要害怕编写更大的测试来测试一堆东西。当然,如果测试失败,可能需要更长的时间来弄清楚出了什么问题,但是一旦你开始将事情粘在一起,通常只会出现问题。

答案 2 :(得分:2)

编写测试,验证基本功能和软件意图的个别用例。然后编写测试来检查边缘情况并验证预期的异常。

换句话说,从客户的角度编写好的单元测试,并忘记测试代码的指标。没有指标可以告诉您测试代码是否良好,只有正常运行的软件会告诉您测试代码何时良好。

答案 3 :(得分:2)

我认为用例对于获得最佳测试覆盖率非常有用。如果您在用例方面具有功能,则可以轻松转换为不同的测试方案,以涵盖正面,负面和异常。用例还说明了先决条件和数据准备(如果有的话)在编写测试用例时证明非常方便。

答案 4 :(得分:1)

我的经验法则:

  1. 在测试计划中覆盖更简单的测试用例(不要冒险保留最常用的功能未经测试)
  2. 跟踪每个测试用例附近的相应要求
  3. 正如Joel所说,有一个单独的团队进行测试

答案 5 :(得分:1)

我不同意代码覆盖率不是一个有用的指标。如果您没有100%的代码覆盖率,那至少表示需要更多测试的区域。

一般而言,一旦你获得足够的语句覆盖率,下一个合理的地方就是编写测试,这些测试旨在直接验证代码编写要满足的要求,或者旨在强调边缘-cases。这些都不会自然地落在你可以直接测量的任何东西上。

答案 6 :(得分:1)

验证测试质量有两种好方法

1。 Code review

通过代码审查可以验证@Patrick Cuff在他的回答https://stackoverflow.com/a/197332/516167

中定义的重要步骤
  

代码审查是计算机源代码的系统检查(通常称为同行评审)。它旨在找到并修复在初始开发阶段忽略的错误,改善 软件的整体质量和开发人员的技能。

2。 Mutation testing

第二种更便宜 - 这是衡量测试质量的自动化工作。

  

突变测试(或突变分析或程序突变)用于设计新的软件测试,评估现有软件测试的质量

相关问题