本文探讨了在软件开发过程中，如何有效地运用自动化测试，特别是'表征测试'和'脂肪测试'，以确保系统的稳定性和功能正确性。文章强调了在持续集成环境中运行大规模自动化测试的重要性，以及如何平衡单元测试和功能测试，以实现全面的测试覆盖。
如何更好地做好压力测试
像大多数初创公司一样，我们尝试了许多不同的想法时，建立了许多原型，并编写并抛出了很多代码。
因为无论如何我们都丢掉了代码，所以我们不必费心编写测试-为什么还要编写也会丢掉的测试？
但是，随着我们加强团队以将原型构建到工作系统中的过程中，我们很早就遇到了麻烦。
我们一直在努力推动小型测试团队努力跟上变化和新功能，同时仍在确保核心系统正常运行。
我们需要快速获得良好的自动化测试能力。
最快的方法是编写迈克尔·费瑟斯（Michael Feathers）所说的“ 表征测试 ”：自动化测试–在现有代码库的拐点处编写–捕获系统各部分的行为，以便您知道自己是否受到影响更改或修复某些东西时的现有行为。
在检查了这些测试以确保系统正在执行的工作实际上是应该执行的操作之后，这些测试将成为有效的回归工具。
我们编写的用于实现此目的的测试比单元测试更大，更广泛–它们是面向开发人员的繁重测试，它们在UI下运行，并验证涉及一个或多个系统组件或子系统的业务功能或业务规则。
与面向客户的功能测试不同，它们不需要手动设置或验证。
这些测试中的大多数都是肯定的，愉快的路径测试，可确保系统中的重要功能正常运行以及测试验证功能。
连续交付书中介绍了使用繁琐的测试作为自动化测试的起点。
这个想法是要自动化高价值的高风险测试方案，这些方案可以覆盖少量测试，从而尽可能覆盖系统的重要部分。
这为您提供了一个“烟雾测试”以开始，并且是测试套件的核心。
今天，我们在持续集成环境中运行着成千上万的自动化测试。
开发人员编写小型单元测试，尤其是在代码的新部分以及我们需要在其中通过许多不同的逻辑路径和变体进行快速测试的地方。
但是，我们的自动化测试中很大一部分仍然是胖的，或者至少是胖乎乎的功能组件测试和链接集成测试，它们探索系统主要部分的不同路径。
我们使用代码覆盖率分析来识别薄弱环节，这些薄弱环节是我们需要添加更多自动化测试或进行更多手动测试的区域。
结合使用单元测试和组件测试，我们在应用程序的核心部分中获得了较高的测试覆盖率（90％+），并且我们定期对系统的许多常规管道进行测试。
使用通用模式以这种方式测试服务器端服务很容易：在数据库或内存中设置初始状态，使用消息或API调用执行某些操作，验证预期结果（包括消息和数据库更改以及内存中）状态），然后回滚状态并为下一个测试做准备。
我们还有数百个更大，更胖的集成和验收测试，它们可以测试客户端UI函数和客户端API函数，直到服务器。
这些“非常繁琐”的测试涉及更多的设置工作，更多的活动部件，更难编写且需要更多维护以及运行时间更长。
它们也更脆弱，需要更频繁地进行更改。
但是他们测试了真实的端到端方案，这些方案可以捕获诸如间歇性系统竞争条件以及回归之类的实际问题。
脂肪检测有什么好处和坏处？
依靠脂肪测试有优点也有缺点。
首先，更大的测试具有更多的依赖性。
与单元测试相比，他们需要更多的设置工作和更多的测试基础结构，更多的步骤以及运行时间更长。
您需要花一些时间来设计测试方法，并创建模板和实用程序，以使其易于编写和维护更大的测试。
您最终将获得更多的浪费和重叠：就像在现实世界中一样，一遍又一遍地练习通用代码。
您将必须安装更好的硬件来运行测试和测试管道，以便以后进行更昂贵的测试（例如真正的集成测试和验收测试），而无需那么频繁。
当测试失败时，来自大型测试的反馈并不那么快捷。
杰拉德·梅萨罗斯（Gerard Meszaros）指出，测试越大，就越难理解真正的失败原因-您知道这是一个真正的问题，但是您需要进行更多的挖掘以找出问题所在。
对开发人员的反馈并不那么即时 ：大型测试的运行速度比小型测试慢，并且您还有更多的调试工作要做。
当测试失败时，我们已经做了很多工作来提供上下文信息，以便程序员可以更快地找出问题所在。
从回归测试的角度来看，通常很明显，破坏系统的就是您刚刚更改的东西，所以……。
当您在大型系统上进行更多工作时，获取有关您刚刚进行的更改的即时和本地反馈就变得不那么重要，而确保您没有破坏其他地方的其他事情，确保您没有做出错误的假设或违反某种合同，或产生副作用。
大型组件测试和交互测试有助于更快地发现重要问题。
他们会告诉您更多有关系统状态，运行状况的信息。
您可以通过许多小单元测试，但是这些测试不能像少量脂肪测试那样使您有足够的信心，脂肪测试可以告诉您系统的核心功能正常工作。
更大的测试还会告诉您有关系统功能和工作方式的更多信息。
我不认为测试可以为系统提供良好的文档编制这一想法-至少单元测试没有。
期望开发人员通过查看数百或数千个单元测试来了解系统的工作原理是不现实的。
但是加入团队的新人们可以查看功能测试，以了解系统的重要功能以及系统规则。
测试人员，甚至是非技术性的手动测试人员，也可以阅读测试并了解涵盖哪些测试方案，哪些没有，并以此来指导自己的测试和审查工作。
Meszaros还解释说，良好的自动化开发人员测试，即使是在类或方法级别的测试，也应始终是黑盒测试，因此，如果您需要在重构或优化中更改实现，则可以在不破坏大量测试的情况下进行操作。
严格测试使这些黑匣子变大了，使其达到了组件或服务水平。
这使更改实施细节变得更加容易，而无需修复测试-只要您不更改公共接口和公共行为 （无论如何都要进行危险的更改），测试仍然可以正常运行。
但是，这也意味着您可能会在实现中犯一些错误，这些错误不会被功能测试所捕获-框外的行为没有改变，但是框内的某些东西可能仍然是错误的，不会使您绊倒的错误到后来。
严格测试不会发现这些类型的错误，也不会捕获其他详细的错误，例如缺少某些验证。
用这种方式编写否定测试和测试错误处理代码会更加困难，因为内部异常路径通常在更高级别被阻止。
您将需要其他类型的测试，包括单元测试，手动探索性测试和破坏性测试，以检查边缘情况并发现异常处理中的问题。
我们会再次这样做吗？
我想认为，如果我们再次开始做一些全新的事情，我们将以更严格的方式开始，首先进行测试，然后进行所有测试。
但是我不能保证。
当您试图尽快找到正确的想法时，任何妨碍您思考和反馈的事情都会被抛在一边。
一旦获得了接近正确和接近正常工作的东西，并且您需要确保它继续工作，就必须进行测试。
您需要小型单元测试和胖功能测试，以及一些大型集成和端到端测试，才能正确执行自动化测试。
这不是一个非此即彼的论点 。
但是编写胖的，功能的和交互的测试将在短期内更快地收回投资，因为您可以用更少的测试更快地覆盖更多重要场景。
他们会随着时间的流逝而逐步回归，因为您始终知道并没有破坏任何重要的事情，并且您知道自己正在行使客户现在或将来将要使用的路径和方案–应该对所有这些进行测试的路径和方案时间。
对于自动化测试，多余的脂肪是一件好事。
翻译自: https://www.javacodegeeks.com/2012/08/whats-better-big-fat-tests-or-little.html
如何更好地做好压力测试
扫一扫
333
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
