自动化测试，应该从哪里开始

「认识到测试是一种心态」，对编写自动化测试至关重要。如果你没有意识到「测试首先是一种心态」，那么测试方法、工具、框架等就都无关紧要了。

软件开发团队和测试团队之所以分开，是因为这两个团队对应用程序的看法完全不同。开发人员负责构建软件，而 QA 专业人员负责破坏软件。如果开发人员想要编写测试，他们需要学会像测试专业人员那样思考，然后将这种思考方式转化为自动化测试。

如果你接受这种说活，我们就可以讨论这种心态在软件开发的日常工作中是如何发挥作用的了。

随着新功能需要或Bug的出现，你应该首先考虑如何测试与这些变更相关的应用程序代码。关于这些变更的讨论不应独自进行，而应始终包括开发人员和测试人员。

即使你的测试团队只进行手动测试，他们的意见也非常有价值。他们可以帮助提供他们希望针对此新功能运行的测试用例，然后开发人员可以将这些测试用例转换为自动化测试。

假如你们没有专职测试团队，开发团队自己也应该讨论需要进行哪些类型的测试，以确保此新功能正常运行。

一个简单的方法是从最终目标开始，然后倒退。即：这个新功能需要做什么？

一旦你理解了这一点，你就可以将问题分解成小的增量步骤，并将这些步骤转化为测试。这样，你就有了一条实现目标的清晰路径，以及一套可以确认一切正常的测试。

如果你使用敏捷开发方法，可以在用户故事的粒度上捕获测试用例，并作为该用户故事的验收标准。

刚开始学习如何编写测试时，最困难的挑战之一是了解你应该测试什么。

假如在你的生产环境上，已经运行了一个庞大的系统，并且没有任何自动化测试，你会如何开始为它编写测试呢？

虽然每个应用程序都是独特的，具有自己的一组特性、功能、技术债等，但还是有一些方法可以帮助你确定要测试的内容。

1、用户旅程

如果你正在尝试测试一个已经存在的应用程序，建议你先为应用程序最“关键”的部分编写测试。

“关键任务”是指应用程序中不会出现故障或损坏的任何部分。例如，登录/身份验证、购买产品、处理信用卡、注册表单等。你的第一个测试套件应该针对应用程序的这些部分，并且它们应该是端到端测试。

既然已经确定了应用程序中最重要的区域，那么你究竟应该如何编写自动化测试呢？建议按“用户旅程”编写测试。用户旅程是指用户所采用的最基本（正常不出错）的路径。

假设你有一个电商网站。用户首先会搜索产品，将其添加到购物车，填写发货信息，输入付款信息，最后购买。

用户从最初找到产品到最终购买产品的整个流程就是用户旅程。整个用户旅程应该用一个测试来测试。

它应该是单个测试而不是单独测试其中的每个步骤的多个测试。原因在于，你可以确保该程序中的所有部分基本都能正常工作。测试用户旅程还会测试你的技术堆栈中的所有层。你正在测试前端和后端、数据库层、网络/API 层等。

通过这个测试，你将测试应用程序中最关键的部分，这最终将使你确信应用程序正在按其应有的方式运行。

2、新功能

当你实现一个新功能时，要为该功能编写测试，一种有效方式是先考虑最终目标。

• 这个功能到底需要做什么？

• 它解决了什么问题？

一旦你理解了这一点，就可以将功能分解成多个小的增量步骤，所有这些步骤都可以转化为一个个的自动化测试用例。

现在你对每个步骤都有一套测试，你可以编写使每个步骤通过所需的代码。

这么做之后，你以后可以轻松地重构此代码，因为你将从测试中确信你在重构期间没有破坏任何东西。如果破坏了，你的测试将失败。

3、bug

强烈建议你对程序中发现的任何一个Bug编写自动化测试。

修改Bug的一个好办法是：在修复之前，先编写一个自动化测试用例，让它能捕获这个Bug。一旦修复了这个Bug，你的测试用例就会通过，这就验证了你的新代码已经消灭了它。

这样，你的测试将有助于确保此Bug在未来永远不会出现。

1、手动测试

手动测试涉及某人（通常是 QA）与应用程序进行物理交互。手动测试通常非常耗时，因为它需要有人一遍又一遍地重复相同的任务，而计算机非常擅长这一点。

有些软件开发团队，每天会多次将代码部署到生产环境中。假如你只是手动测试，这几乎是不可能的。

随着持续集成 (CI) 和持续部署 (CD) 的进步，现代软件开发团队正在尽可能地实现自动化，包括测试，使他们能够自信地每天多次推向生产。

2、自动化测试

随着越来越多的团队采用 CI/CD 系统并希望每天多次推送到生产环境，自动化测试是满足此类需求的唯一方法。

目前在软件开发中有一种称为“测试左移”的运动。左移本质上意味着开发人员越来越多地参与测试。

过去，测试是由 QA 团队在开发过程的最后阶段执行的。现在，该工作正在“左移”，测试的责任越来越多地落在了开发人员的肩上。因此，测试不是事后才想到的，而是从一开始就集成到整个软件开发生命周期中。

测试自动化正迅速成为大多数软件工程团队的“常态”，其流行度和实用性只会随着时间的推移而增加。

最终，测试是每个人的责任。

在现实世界中，现代软件公司基本上存在三种团队结构。

1. 专门的开发和 QA 团队。

拥有专职开发和 QA 团队的公司通常将软件开发留给开发人员，将测试工作留给 QA 团队。

2. Designer, Developer, QA等

一些公司会有由开发人员、设计师、QA 工程师等组成的小团队，所有人都在一个项目或功能上一起工作。在这种情况下，开发人员通常负责编码，QA 通常负责测试。

3. 全栈独立开发者

一些公司，如早期初创公司，没有专门的 QA 团队，所有测试责任交给开发人员。开发人员负责编写代码并确保其按预期工作。

虽然许多公司和团队都有专门的 QA 工程师，但每个人都有责任确保应用程序按预期运行。

为了交付可靠、高质量的软件，测试应该是每个人的责任，并且应该在项目开始时，就在整个团队的思考过程中。

所有的缺陷都是开发人员写进软件中的。软件开发人员对于软件质量负有不可推卸的责任，完全可以作为软件开发人员产出质量的参考指标之一。

乔梁老师开课啦~视频课程《持续部署训练营（Python版）》， 限时特价！

你的软件开发效率够高吗？质量够好吗？你的团队多长时间才能向用户实时推送一个生产变更？你的软件在发布时，你是否因担心软件交付质量而感到压力倍增？你是否遇到过部署失败，甚至导致停机的情况？持续部署可以帮助你消除软件交付的痛苦，让你能专注于为客户高价值的需求，而不会因为这些交付执行类问题而花太多精力。本课程通过学练结合，理论结合实战，让你体验如何使用构建-测试-部署管道，进行持续部署。并练习如何在有效监控部署的同时，逐步发布功能特性，并作数据库结构变化。

（扫码订阅）