实施平衡的测试金字塔的资源

#1 楼

最近几年，我一直在想同样的事情。在我的组织中，我们已经开始使用BDD样式测试来解决我们的金字塔问题。目前，我们大约有800个自动验收测试，3000个手动测试，1500个集成/服务测试和1000个单元测试。显然不是理想的选择。

我已经意识到，可以通过集成或什至是单元测试来更有效地测试许多手动或手动测试，无论自动化与否，但是我们的质量保证分析师不知道这些较低的标准是什么。水平测试正在做。使用BDD来描述所测试的行为正在帮助QA分析人员，SDET，开发人员等将所测试的内容放在同一页面上。在大多数情况下，对任何人来说，特定测试的实现并不重要，只是某些行为是否按预期起作用。

对于您的特定问题，我认为这有助于我们避免＃ 1和＃2才是问题。关于测试重复，诸如输入验证之类的某些事情是多个级别（服务，Web）的需求，我们更愿意在可能的情况下使用单元测试在两个级别上进行验证。

对于＃3，当测试人员发现缺陷时，他可以为其编写BDD测试，该测试将在开发人员或SDET确定的正确级别上实施（请参见下面的“测试深度”链接） 。

以下是我已经阅读过的有关此主题的两件事：

测试深度

自动化测试和测试金字塔
/>

#2 楼

如何确保不要在不同级别上重复测试用例？

首先，对每个级别上要测试的内容设定期望。例如。可以在单元级别测试验证，而可以在组件级别（服务，控制器）和系统级别（JavaScript，HTML）测试应用验证的事实。请参阅有关如何为单页应用程序构建测试金字塔的示例：构建测试金字塔以优化自动化测试

此外，所有测试级别都需要由同一个人编写/维护/查看。可以通过多种方法进行：


摆脱专门的AQA工程师。开发人员可以自己编写所有测试。需要提供手动质量检查或BA的咨询，以涵盖哪些案例。
通过介绍非常擅长测试但不进行测试的老师，让他们从质量保证的质量保证过渡到质量帮助的质量保证开发人员如何进行测试。
赋予AQA特权，以审查/更新/拒绝所有级别的测试-包括开发人员编写的单元测试。

如何识别冗余测试用例

通过查看先前编写的代码，可以有效地检测到这一点。我们可以不时地回顾一下测试，看看它们是否相互重复以及覆盖范围是否足够。您可能需要在这些评论中包括“手动质量检查”。

您需要确保测试的可读性和测试用例易于实现-这将有助于发现漏洞和重复项，并且不会造成太大的负担。

如果在UI级别上发现可以在单元级别进行测试的案例，我们是否会将其添加到单元测试套件中？

绝对。尽管其他人可以执行此操作-如果存在这些人，则可以使用AQA，也可以使用Devs。


我知道这个领域很广，因此我对实践经验和教训比银弹解决方案更感兴趣。


尽管给予了所有关注，但测试金字塔仍未广泛传播。因此，即使是来自权威来源，您也应该一筹莫展。目前，关于金字塔的大多数喧嚣都集中在质量检查圈子中。但是这些需要扩展到包括开发人员，因为没有能够编写可维护代码的人员，就不可能实现可靠的金字塔。

#3 楼

我发现这是一些组织的一个碰触和敏感的症结所在。我经常看到质量检查测试人员对进行UI测试感到兴奋，只是被“我们已经有该单元测试”对话打断了。

我现在采用这种方法：

UI测试可以重复单元测试，没关系。

单元测试一旦成为主流，就可以了。期望80-100％的代码具有单元测试已经很正常了。因此，当我编写更高级别的UI自动化测试时，我期望我正在练习的大多数事情都将具有较低级别的单元测试。没关系。我确保所有这些部分都可以协同工作，并且为了做到这一点，我必须创建，操作和使用相同的对象和代码。但是，我现在更感兴趣的是，当所有接口都频繁地放在一起时，它们会如何工作，以防发生意外情况。

我在实践中发现，要获得一个平衡的金字塔，您应该做一个一点规划。现在，在我当前的组织中，我已经创建了20个顶级UI测试（使用硒），我们使用rspec-capybara进行了100个集成功能测试，并在rspec中进行了大约1000个单元测试。为了保持这一进展，我们在冲刺修饰期间检查票证，并确定是否应使用票证进行新的/更改的自动UI测试。