谁负责执行软件测试中的自动化测试任务？

京东购买链接：https://item.jd.com/10205955087769.html 2.7 谁来做自动化测试？ 你可以让开发人员编写自动化测试项目的基础版本，有了正确的测试框架和符合项目的用例开发思路，这通常是一个好的开端。在我们见到过的成功案例中，团队会采用与产品代码相同的语言编写测试脚本，版本迭代也会与产品代码版本保持一致，在版本控制系统中的某个具体版本下，会同时看到产品代码和测试代码。不同的版本在构建时，会运行对应版本的自动化测试用例，当所有的测试用例都通过后，再进行人工探索性测试。 自动化测试谁来做，其实是要根据项目实际情况进行权衡的。正如第 1 章回文问题的介绍，许多开发人员表现得并不是很理想，我们认为其主要原因是建设性思维（如何做？）与批判性思维（可能出现什么问题？）之间的差异所致。我们也相信，通过适当的培训可以使开发人员同时具备这两种思维方式，笔者也希望读者通过阅读本书在此方面有所收获。 遗憾的是，并非所有团队都愿意或能够接受让开发人员去创建自动化测试。首先，会影响开发人员正常的开发进度，有些管理人员可能不会考虑这一点；其次，也有一些开发人员对此并不感兴趣；最后，在某些情况，编程语言和构建过程也未必支持我们上述所说的自动化测试开发和构建流程。至此，我们也不难想象管理人员会说：“你还没弄清楚，我们需要自动化测试是因为人工测试效率低、耗时长，严重影响了交付进度。你所提出的解决方案会影响开发人员的进度，这样肯定是不行的。”这是我们之前听到过的一句话。 为了不影响测试和开发进度，你便雇用其他团队来完成自动化测试脚本的开发，如此产品代码就可以在没有（那么多）人工探索的情况下尽早发布。这些人一般是开发人员 / 测试人员，我们也称为软件测试开发工程师（SDET），测试开发工程师编写代码的能力通常不足以胜任软件开发工作，因此常常作为合同工被聘用。一般情况下，他们入职初期，进度会稍微放缓，然后花费 3 ～ 6 个月时间构建一套自动化测试工具，最后完成冒烟测试用例。冒烟测试用例会覆盖重要的业务流程和主要的功能模块，并发现一些明显的 bug。Matthew 曾经合作过的一家公司就采取了这样的方式，经过 9 个月的努力，最常见的问题是诸如“测试环境无法访问”“数据库服务器宕机”这类任何人在几秒内都能发现的基本问题。 2.7.1 何时能看到结果？ 经过一年的努力，管理层才可能看到构建 / 测试 / 部署过程用时显著减少，然而年底成本统计后，开发成本上升了 20%，测试成本上涨了 50%。曾经要求团队实现自动化测试，并为此争取资金的高管问道：“如果我们当初只花一半的钱，多招几个测试人员，会怎么样呢？”这还是一个相对乐观的情况。若遇到更糟糕的局面，一年后高管看不到显著成效，便转去别处宣扬自动化新理念，而接任的开发副总裁则为了节省开支，决定裁掉软件测试开发工程师，并声称可以为公司每年节省一百万美元。几周后，自动化测试逐渐无人维护，最终被遗弃、遗忘。 其实事情大可不必发展到如此境地。通过上述讨论，读者可以清楚地看到可能出现的种种挑战。本书剩余内容将帮助读者规避这些雷区。 2.7.2 不被理解的自动化测试 在任何场景下，自动化测试都会创建大量的测试代码，这些测试代码不仅仅是简单的查找元素 / 点击 / 查找文本操作，而是涉及许多算法的实现。例如，一本书预计在 4 个工作日内交付，测试工具不仅要查找系统时间 +4 的日期，还要考虑排除周末和节假日的情况，找出实际 4 个工作日后的日期。最终需要考虑的条件会非常多，以至于必须借助编程来实现。编程的实现就需要思考条件语句、循环语句、日期、周末、节假日、新账户创建、服务器名称、变量和税款等所有隐含的内容。 当测试发现错误时，我们还需要找出根本原因以及具体的复现步骤，原本直截了当的线性测试流程，现在也需要调试。突然间，你会意识到测试脚本也需要被测试。对此，一种普遍观点认为自动化测试应该简洁明了，遵循“步骤—步骤—步骤—检查”的线性方式，不断重复这个过程。 2.8 自动化测试思想 本章示例大多以端到端测试的方式展现，即把所有组件作为一个整体进行测试。在第 4 章中，我们将讨论如何构建易于调试、结构清晰、维护方便，甚至能作为文档辅助的端到端测试项目。本节的重点是探讨如何克服其他弱项。 诚然，我们很容易耸耸肩就说，仅依靠工具对软件开展测试，得到的软件质量将会非常糟糕，故就此罢手，不再涉及自动化测试。业界也有一些同行持有类似的观点，有人将他们称为“反自动化阵营”。读到此处，你应该意识到，在某些具体情境下，关于自动化测试优劣的辩论的确具有价值。 关于自动化测试优劣的辩论也能促使我们探寻一些基本问题的解决方法，这些方法如下所示。