如何知道现有的一组自动化测试是否有效？

#1 楼

了解如何将产品用作最终用户。熟悉所有功能，错误页面和工作流程。
然后研究测试。观察他们的运行和/或查看他们的代码，然后问自己：


UI中是否存在您看不到UI测试的功能？
是否存在自动化的UI测试？针对您在UI中无法执行的操作？
功能测试是否涵盖快乐，悲伤和可选的工作流程？
是否对支持ui的后端功能进行了单元测试和集成测试？
安全性测试是否经过安全性测试？

#2 楼

确定（源代码的）覆盖范围，并添加尚未涵盖的测试练习部分
找到通过系统的最常用“路径”，不同类型的用户将使用它。检查是否涵盖了最常见的内容。

“最佳”方式取决于您要涵盖的内容。关键是什么。企业认为最重要的事情。有很多测量方法。

#3 楼

如何确定测试是否有效？最好的方法是什么？


这是一个新产品，因此历史测试结果很少可以比较，但是可以吗查找相似产品，该相似产品如何测试？可以对这种类似产品进行有效测试吗？与相似产品的测试用例相比，您的测试用例如何？
随着时间的推移，会出现bug。您的测试用例能否捕捉到这些错误？如果容易捕获的错误设法进入生产环境，则意味着您的测试用例需要改进。
定义给定产品“有效性”的最佳方法是根据其自身的历史产品质量进行衡量。

#4 楼

用于测试和产品代码的版本控制系统应该能够快速回答以下问题：


由于测试发现问题，代码是否有任何更改？
是否发现了测试未发现的问题？
是否引入了针对此类问题的测试，并且在修复之前在代码上运行会导致测试失败？
当前是否存在测试失败？

您还可以查看代码和规范的测试范围，规范和测试之间的可追溯性将很好地说明这一点。

#5 楼

如何知道现有的一组自动化测试是否有效？


很难评估有效的测试。自动化测试的问题在于，随着时间的推移，它们发现的错误更少。

话虽如此，我发现Karen Johnson提出的回归测试助记符RCRCRC在评估现有测试时很有用。尽管是专门为回归测试而设计的，但我仍然认为它们运行良好。



最近。测试是最近的吗？它们涵盖新功能，新领域或新变化吗？还是主要是旧测试？

核心。这些测试涵盖哪些功能？它们是关键功能还是必不可少的功能？

Risky。哪些功能比其他功能更具风险？哪些功能更可能被破坏？

配置敏感。哪些代码取决于环境设置？根据不同的环境（登台，生产等），此更改可能如何？

已修复。哪些功能或代码最近已修复或修复，并且可能仍存在更多错误？

慢性。似乎总是崩溃或有问题的功能或代码。

#6 楼

如今，计算机已经足够快以自动化突变测试。

您运行所有测试，确保它们是绿色的/成功的。然后引入一个突变，然后再次运行所有测试，并期望它会变成红色/失败。

任何未被测试捕获的突变都意味着您没有测试。


变异检验基于两个假设。首先是称职的程序员假设。该假设指出，由经验丰富的程序员引入的大多数
软件故障是由于小的
语法错误引起的。第二种假设称为耦合效应。
耦合效应断言简单故障可以级联或耦合
以形成其他紧急故障。


一般代码覆盖范围可以覆盖率测试和突变测试相结合也将大大有助于证明您的测试套件可以有效地捕获意外更改或小缺陷。