如果您有一家中等规模的公司，那么几个开发人员--但REST中的零测试--您会从哪里开始呢？

Question

我想找一个基准来射击，并想出一个不错的游戏计划，在部署新代码之前将测试引入到我们的系统中。

只是一些背景故事

我的雇主不是一家科技公司，我们的终端用户都在公司内部，我们只是一个部门，有2-4个开发人员支持一个中型公司--但是，当我们在多个系统上推出大型软件更新时，时不时地真正感受到痛苦。缺乏测试通常会让我们解决发布后几天后出现的小问题，有时还会让我们看起来很糟糕(人们依赖于休息的旧特性)，在大获全胜(人们喜欢的新特性被引入之后)。

我的公司使用一个微服务架构，每个后端服务都是一个无状态REST，我们有大约(12)个后端服务。我们有(3)面向用户的网站用几种不同的语言编写，我们公司内部使用这些语言来做大量的工作。我们发展得越多，人们对我们产品的依赖就越多，我们的服务必须继续向前发展。

在我看来，如果我们停止所有正在做的事情，只写测试，直到我感到“安全”，并且我对我们所有的基础设施都进行了足够的测试，我们将需要最多两年的时间来编写它们。这不是我们能说服我们的同事和高管们等待的事情。

--

如果你站在我们的立场上，你会开始写什么样的测试？你会从端到端的测试开始吗？就像在每个应用程序中一样，编写测试以确保应用程序能够查询或更新与其通信的其他应用程序？

您会在像Postman这样的东西中编写测试，然后访问每个API端点来查看它是否还活着吗？

或者你会为每个应用程序内部启动吗？为每个函数编写单元测试，或者编写每个REST端点，以确保每个端点按预期工作？

有那么多地方需要做工作，要想出一个起点，让人觉得我们正在取得进展，这是令人畏惧的。

Answer 1

实际上我也遇到过这种情况。当你说花两年时间编写测试时，我想你指的是单元测试。那不是我要开始的地方。

我(或者我的团队)在这方面所做的就是创建一个表征试验系统(谢谢文森特·萨沃德)。也就是说，创建一组输入，将它们输入到系统中，并捕获所有的输出。然后，您接受代码的任何修改版本，并运行这些相同的输入，并比较结果。这样做的主要好处是在回归的情况下，您不会对应用程序进行任何功能更改，比如重构。在这种情况下，您可以预期(有几个注意事项)，对于相同的输入，输出将是相同的，这些输入可以用标准的diff工具确定。

您也可以对功能更改进行这种测试。这对于自动化来说更具有挑战性，但是如果你看到事情在你没有预料到的领域发生变化，你可以专注于这一点。

如前所述，有几个注意事项:时间戳、UUID等并不相同。您的比较必须能够处理这些和不更改。忽略这些领域可能是一个不错的第一步，但这确实增加了风险。理想情况下，您应该验证它们是否存在，并至少符合正确的格式。这可以作为一个单独的步骤来完成。另一个可能出现的问题是格式和顺序。例如，有些语言会随机对应用程序的每个启动进行散列。如果您使用哈希表中的默认顺序，那么您可以得到假阳性。为了解决这个问题，我实现了排序和格式化算法，作为比较的一部分。

重要的是要理解，当我说“输入”时，我指的是所有的输入，包括所有可能影响结果的状态，比如数据库。理想情况下，您可以创建“黄金”数据集，可以在测试开始时(甚至在测试期间)恢复到确切的状态。

一旦你准备好了，你就需要生成测试套件。随机选择生产请求通常是一个很好的起点，但您需要一个适合所有角落情况的示例。我认为我没有做过的一件事可能会有帮助，那就是使用代码覆盖率工具来查看您的输入集如何很好地操作代码的所有分支。更成熟的方法将对测试数据进行一些管理，以确保它涵盖所有受支持的场景。您也应该考虑错误场景。

有了这个位置和良好的覆盖率，您现在可以自信地重构。作为重构的一部分，您可以开始引入单元测试。就我个人而言，我认为单元测试被高估了一些，如果您这样做，我想您会发现单元测试实际上是最适合您的基础/可重用组件的，并且这些回归套件对于其他一切都要有效得多。

Answer 2

关于优先级的五点思考

1. 自信是自动化测试的主要目的:为了使您不害怕更改和频繁的deployments.，为您所担心的代码中的区域编写测试。
2. 缺陷历史记录:您不确定您应该担心什么?查看您的版本控制系统中最近两年的缺陷修复。如果你经常看到任何模块参与，那就是你应该担心的地方。
3. 单元测试对于具有高耦合性的简单逻辑来说是浪费时间的，这对于大多数普通的web application.来说是典型的，但是很少(！)这样的应用程序中的点将具有复杂的逻辑。为此编写一些单元测试。
4. 相反，烟雾测试是必须的:在代码库中覆盖大量的测试数量相当少。坚持使用愉快路径测试(没有错误情况)来保持简单，但是试着调用每个oft使用的功能once. --这些测试如果失败了，就很难进行调试，但至少你知道你已经弄坏了什么。在你找到它之后，你会很有动力在下一次增加一个更小的测试。
5. 基于UI的测试也是一种痛苦，因为它们总是破坏无关的reasons.，因此，如果可能的话，尝试将您的大型粒度测试保持在UI级别以下的一个级别上。REST是实现这一目标的良好基础。

如果你严格遵循这些优先顺序，你完全可以把其他的事情留给你有时间的时候(也就是从来没有)。

Answer 3

这个故事从结束的地方开始:测试金字塔：

来源：https://www.ministryoftesting.com/dojo/lessons/the-mobile-test-pyramid

你不希望你的第一步妥协到你需要的地方。单元测试应该包含大多数测试。这可能需要不同的编程技术或重构，这现在是禁止的，因为它可能带来比它修复的更多的问题。相反，首先要关注金字塔的顶端。

您的初始测试集应该涵盖最关键的用例。这些端到端测试可以使用任何你喜欢的工具。重要的是，这些测试应该完全与应用程序的用户界面交互。关注少数几个最关键的验收测试。请咨询您所支持的每个应用程序的领域专家，以帮助确定这些用例。例如，在创建博客文章时，编写一个测试，捕捉一个典型的情况:用户输入一个合理的标题、合理的正文文本，并添加几个标记来对新帖子进行分类。首先构建金字塔的顶端，然后停止为旧代码编写新的端到端测试。

理想情况下，e2e测试应该是可以针对任何应用程序环境执行的测试。如果生产由于个人可识别的信息或金融事务而足够敏感，那么目标是在本地环境开发和测试中执行这些e2e测试。每当代码合并到主版本控制分支中时，设置持续集成以运行这些测试。

端到端测试是脆弱的，有无数失败的理由。当它们失败时，根本原因并不明显，但这是一种妥协，因此在将代码部署到生产之前就会遇到故障。

同时，所有新特性都应该附带新的自动验收测试。所有新的bug修复都应该由e2e测试来覆盖，但足以覆盖这个bug。这些新的测试应该包含在您的持续集成构建中。现在是为新代码引入单元测试的好时机，这可能包括在特定区域引入依赖项注入之类的东西，在这些领域中，这将是容易的和低风险的。

一旦您的团队完成了这一任务，请关注金字塔中的下一层:集成测试。

在这里，领域专家为每个应用程序确定的关键用例应该确定哪些组件首先获得集成测试。这些也应该包含在您的持续集成构建中。集成测试应该首先运行，然后运行e2e测试。

同时，所有新特性都应该随集成测试和自动验收测试一起提供。如果可能的话，所有新的bug修复都应该随集成测试一起提供。当然，要继续用e2e测试来覆盖bug。继续尝试增加新特性的单元测试覆盖率。预算一些时间，有选择地为旧代码添加单元测试，这是容易的和低风险的。

此时，编写这些测试的额外工作应该被减少的bug压缩时间所抵消。现在，您可以专注于重构代码，以使单元测试更容易。这个阶段包括更大、更高风险的重构工作，因此您的测试金字塔看起来是正确的。在这段时间内，单元测试覆盖范围应该大大加快，然后努力保持这种状态。