自动化测试：解释其业务价值

要开始我不认为这是一个重复的其他问题上的单元测试。我正在寻求帮助的是将其价值表达给程序员，分析师，经理和测试人员团队。通过自动化测试，我认为不需要区分单元测试（例如JUnit），BDD（例如JBehave，Fitness）和UI（Selenium，W​​atir），因为我认为它们都提供相似的价值（但您可以随意写一个不同意的答案:)）

以下是我已确定的列表，正在寻找有助于扩展或完善的答案：

1. 节省时间/成本：编写自动化测试比编写测试案例要花费更多时间。但是，考虑到测试要运行多次，执行自动化测试的边际工作（即成本/时间）要少几个数量级。自动化测试运行便宜，这有助于随着时间的推移更改系统。
2. 文档：没有比测试更真实的方法知道系统如何工作了。其他任何文档通常在撰写时就已过时，但是测试（至少是通过的测试）揭示了事情的实际运行方式。最终用户和API文档均是如此。
3. 代码质量：测试写作迫使您：
   • 考虑客户，因为测试是客户
   • 打破使代码可测试的依赖关系，这通常意味着弄清楚如何使代码不需要其他大型系统可用

我的一些想法：

1. 老实说，编写自动化测试将花费更多时间。如果您正在执行单元级别的TDD（如果您打算投资自动化测试，我建议您以此为起点），则可以预期大约需要30％的时间来编写功能代码。这里的关键是要说明这30％的额外投入（这可能比您的团队学习如何编写良好的测试开始时高出30％）是一项旨在节省时间成本的投资。至少对于单元级TDD，系统的设计是松散耦合的，并且具有很高的凝聚力，这使您的系统适应随时间变化的情况。新要求和意外错误始终需要更改系统，
2. 鉴于编写这些测试所花费的时间，运行它们所需的时间以及需要多少维护，关于验收级别和UI级别测试的价值存在很多争论。我建议阅读James Shore的这篇文章。
3. 在自动化测试的世界中，有好办法，也有坏办法。如果您要向您的管理人员介绍自动化测试，那么我将与您一起介绍如何计划让您的团队受过良好的测试培训。Roy Osherove的单元测试技术，Michael Feathers的Legacy Code有效地工作以及James Shore的敏捷开发艺术都是直接或间接涉及这些主题的好书。您还应该研究某种教练或正规培训。这是一个很大的变化。
4. 在业务价值方面，您在上述第二点和第三点实际上是为您的第一点服务的，因此我将重点放在第一点，并讨论第二和第三点如何为更大的点服务。文档使您的系统更易于理解，从而使您的团队工作更快。代码质量使您的系统适应变更，从而使您的团队工作更快。对于商务人士而言，这一切都是为了最大程度地提高从构思想法到将想法作为工作软件交付之时的价值流。

确定价值的一件事是自动化测试可以连续运行；例如每小时进行一次重建或类似的工作。这样做会迫使程序员在处理有问题的代码后的数小时或数天之内将所有错误或回归迅速地公开出去，这使上下文切换变得更加容易。连续测试的第二个好处是，它迫使您将测试保持在工作状态。没有什么比花一个测试周期的第一周来修复所有过时的测试乏味了。如果您可以自动化它们，则可以随时运行它们，并且通过定期运行它们，可以快速捕获测试或代码中的错误。

测试费用

一旦编写了自动测试，就可以由计算机运行，而只需花费几焦耳。等效的手动测试要求工资单上的人员仔细阅读说明列表。

测试可靠性

可以信任计算机每次都忠实地执行相同的测试过程。人类容易犯错误并变得懒惰。

计算机的测试失败模式也更加明显-崩溃（测试报告停止出现），有一点错误导致错误的测试结果（再次运行确定性测试，结果有所不同）。如果一个人错过了一步，并勾选了“ OK”，我们怎么知道？

测试耐久性

为了运行，自动化测试必须是具体的工件（例如一段代码），并且自然包含在其他软件开发工件（源存储库）中。手动测试可能会由测试人员在便条纸上进行开发，而从未正式化。企业更有可能需要适当的流程来确保不会发生这种情况。

测试值

可以对计算机进行编程，以一致，易于分析的形式输出测试结果。该人员正在输入数据以生成相同的数据，或者正在记录需要分析师，开发人员或经理进行摘要的自由格式笔记。

大多数情况下（取决于您的测试覆盖范围）无错误的代码，我想说的最大的论据之一是，当您向经理说可以为发现的错误编写测试时，确保将来始终知道该错误回来了:)

我的观点是，单元/集成测试是最重要的，而如果您应用诸如MVC之类的UI模式，则对于大多数项目来说就足够了。我通常会测试控制器/演示者上的所有操作，并将数据绑定留给视图。

当然，自动测试不能替代旧的好方法，并在您的应用程序周围单击冒险，试图找出用户可以做的最疯狂的事情。

还有一点就是持续集成。

还有一件事-必须努力使代码质量导致产品质量，业务价值和可维护性-否则这样做毫无意义。

我认为您应该以“降低成本”和“更多功能/单位时间” /更短的周期时间为神奇。

但是，在提起诉讼之前，建议您对您的情况进行反思。您的问题使我写了一篇有关自动化测试潜在弊端的博客文章。

重构的容易性是一个很大的因素。通过良好的READABLE（!!!）单元测试具有良好的覆盖率，您可以重构系统，而不必担心会损害现有功能。

您必须出售这个概念–您需要避免告诉他们它将改善代码。如果他们对代码有任何投资，将立即使他们无法通过您/自动测试。如果他们有什么好处，他们也将了解GIGO，因此也将不明白为什么您认为它不适用。

我也不会把它作为文档方面出售，例如Fitnesse可以做得很好，但是直到他们体验到它可能很难形象化。

我认为在某些地区可能会很幸运地出售它

1. 单元测试可以代替许多开发人员工具–在这里，您创建应用程序只是为了进行调试/测试而无需经历所有登录/菜单。

2. 通过测试，您可以设置并轻松地重复出现问题的情况–无需花费大量时间来设置测试数据（尤其是使用像样的模拟系统）

3. 建立BDD和UI测试套件时–如果有简单的休息，您得到的响应会比等待测试人员下次查看时更快。

4. BDD和UI测试可以避免您反复按下按钮来检查可能受更改影响的所有方面，并且省去了记住每个方面的麻烦。

5. 当有人忘记签入代码时，自动构建通常会突出显示

6. 测试可以帮助您避免错误再次出现。

7. 单元测试和体面的模拟将意味着更少的互连代码，并且更易于解决

请记住，您是在试图出售它，而不是将其转变为一种宗教-因此，请接受小步骤，并尽量不要使它们反抗您。他们还需要一些时间来调整和学习编写好的测试。

在接受针对该问题的建议解决方案之前，必须相信某个问题。

自动化测试可以节省错误修复成本，因此，如果您的同事不相信错误修复成本可观或过高，将很难令人信服。如果这些成本高昂或过高，但人们不相信这些成本，那么您可能首先必须获得一些令人信服的有关这些成本的数据。

企业所钟爱的是增加价值和降低成本。您必须解释一下自动测试如何增加价值，因为它确实增加了额外的成本。

如果您的代码是模块化的，则可以重新使用它。这意味着测试不必重新编写，您可以在现有代码之上工作。

如果存在遗留项目，则自动测试将使重构变得更加容易。必须在某个时候偿还技术债务。

您提供的文档参数不是很好。保持测试最新与文档更新之间的区别只是习惯。

“我正在寻求帮助的是将其价值表达给一组程序员，分析师，经理和测试人员。通过自动化测试，我认为不需要区分单元测试（例如JUnit），BDD（例如JBehave，Fitness）和UI（Selenium，W​​atir），因为我认为它们都具有相似的价值（但您可以写一个不同意的答案：））”

好吧，我会接受挑战；）

我主要与程序员和QA一起工作，我的工具是ruby，rails，testunit，rspec，茉莉花和硒。

rspec和testunit的BDD / TDD工具是编程的一部分。您不会将它们分解出来并单独与管理层讨论，也不会因为时间不足而推迟它们，而是将它们包括在所有时间估算中。如果真的被问到，人们有多少时间向您解释计算机科学和编程。我不会在前端使用这些测试

GUI / UI /茉莉花/硒。这些是不同的。我是由具有程序员背景的质量检查人员来完成这些工作的。我们确保编写的测试尽可能健壮，并且基于内容而非布局。其（可能是新的）成本应解释为转移成本。现在，您无需支付任何损坏的软件，丢失的客户和昂贵的修复费用，而只需几个简单的实践即可（相对）减少很多费用。

我认为关键是要谈论要创建的特定测试类别，而不是整个“自动化测试”。后者可能有点模糊和令人担忧，并且想出在哪里浪费时间的示例太容易了。

我总是建议将您的测试分为4组（此处有更多详细信息）。坚持在这里，我将立即了解这如何帮助您将测试卖给其他人。

1. 测试您的核心功能。即，对于网站监视工具，这将是对警报的测试，应针对您正在监视的网站触发警报。这些测试确保了这些东西永不中断。
2. 整个应用程序的烟雾测试。例如，使用Selenium浏览Web应用程序中的所有链接/按钮，并确保服务器没有错误。这些测试可以避免您因为明显的构建版本而浪费测试人员的时间。
3. 测试任何易碎的代码。即，对于那个旧模块而言，没有人想要触摸，或者似乎其中总是包含错误的复杂代码段。
4. 开发人员要编写支持他们工作的测试。因为有时候在写东西时测试是有用的，但是不要属于上述类别。

通过将测试分为这些类别，您现在可以进行不同的讨论。拿前三组（无论如何，第四组由个人决定），问人们是否认为对这些代码段进行测试是否值得？如果您无法达成协议，也许您暂时不包括这些测试。如果可以，即如果人们同意围绕每次提交执行的核心功能的测试很有用，则开始添加这些功能。

另一组可能有用的测试是手动进行的困难或耗时的测试。就节省手动测试时间或对由于时间不足而被跳过的事情进行测试而言，这里的好处应该很容易解释。