《软件测试策略》——工具与自动化的基本问题（五）

京东购买链接：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 章中，我们将讨论如何构建易于调试、结构清晰、维护方便，甚至能作为文档辅助的端到端测试项目。本节的重点是探讨如何克服其他弱项。
诚然，我们很容易耸耸肩就说，仅依靠工具对软件开展测试，得到的软件质量将会非常糟糕，故就此罢手，不再涉及自动化测试。业界也有一些同行持有类似的观点，有人将他们称为“反自动化阵营”。读到此处，你应该意识到，在某些具体情境下，关于自动化测试优劣的辩论的确具有价值。
关于自动化测试优劣的辩论也能促使我们探寻一些基本问题的解决方法，这些方法如下所示。
● 视觉测试：视觉测试（Visual Testing）是一种比较流行的测试方式，它通过对比屏幕部分区域的截图，并辅以简单的操作（如点击 A 标记 bug，点击 B标记非 bug，并将当前屏幕设为新的标准），从而实现快速识别界面问题。
● 众包测试：众包测试（Crowdsourced Testing）是一种利用大量人员解决大规模组合问题的测试方式。例如，开始测试后，将任务分配给 100 位测试者，他们在 1 小时内完成测试并给出测试结果，这其实与自动化测试的效果相差无几。
● 无代码自动化测试：无代码自动化测试（Codeless Test Automation）起初是通过录制 / 回放工具被人们所知，如今随着 API 新标准的发展，这项技术有望迎来真正的成熟时期。
● 多独立部署点：多独立部署点（Multiple Independent Deploy Points）的引入消除了组件间的不必要耦合，使得大规模回归测试成为过去式。
● 浏览器兼容性测试：浏览器兼容性测试（Browser Compatibility Tests）允许软件在多种不同的浏览器和模拟设备上运行，测试人员可以在短时间内轻松查看大量屏幕截图，从而快速识别并定位渲染问题。
● 网格化测试：网格化测试（Grid-Based Testing）也称分布式测试，允许同时运行多个测试用例。为了实现这一目标，测试用例需要具备独立运行的特性。这一点我们将在第 4 章详细讨论。
● 插桩测试：插桩测试（Test Instrumentation）技术可以将代码与其相关的测试关联起来。当代码发生更改时，只需运行受影响的少量测试即可。
上述提到的不同测试方法都能在各自的方面解决自动化测试中的一些基本问题。然而，即便最大的测试团队，也很难同时实施所有的测试方法，主要是因为在自动化测试工具 / 项目开发的过程中，开发人员会识别所面临的问题，并及时调整，使之与团队现状和需求相匹配。
迈克 · 科恩（Mike Cohn）是敏捷开发 Scrum 理念的早期主要倡导者之一，被广泛认为提出了自动化测试金字塔模型。该金字塔模型是一个三角形结构，底部是大量的单元测试（底层测试），中间层是较少的集成测试，顶部是非常少的端到端测试。该模型的两边没有固定的倾斜角度，也没有给出量化测量的标准，更多的是用来强调一个观点：端到端测试执行速度慢、脚本脆弱、编写成本高且存在较多问题，而开发人员编写的单元测试则相对容易编写和维护。
近年来，自动化测试金字塔模型受到了一些质疑，人们开始寻找更精确的测试策略模型。诺亚 · 苏斯曼（Noah Sussman）是 Etsy 的 DevOps、CI 和测试自动化的早期实践者之一，提出了测试漏斗的概念。图 2-10 便是诺亚对该概念的解释。
诺亚的观点与本书第 1 章探讨的组合测试不谋而合。开发人员编写的单元测试和集成测试旨在验证软件是否按照开发人员的预期运行。而端到端测试，通常由团队共同定义，用于展示和界定需求。因此，通过自动化测试未发现，而由人工测试发现的问题，往往是未定义的、意外的、罕见的、未曾考虑到的等情况。
测试漏斗思想是最理想的状态，许多团队都有不同层次的实现，有的团队实现的漏斗模型底部存在一个巨大的漏洞，导致很多问题（bug）从这个漏洞中溜走。而我们的工作就是堵住漏洞，即通过加强和完善各个层级的测试，确保软件质量得到充分的验证和保障。

 
2.9 本章回顾
本章并未详细探讨如何进行测试工具化和自动化，而是讨论了新入门的自动化测试人员，在最初几年的工作中可能会遇到的问题—至少是笔者希望他们能够发现的一些问题。俗话说：“十年的经验和一年的经验重复十次是有区别的。”这些问题包括自动化测试的深度（我们往往只是自动化部分工作量）以及 bug 的独特性（意味着重复的回归测试只能提供有限价值）。此外，我们还讨论了测试维护作为一项隐性成本以及测试工具可能误报或漏报 bug 的现象。
最后，我们介绍了几种模式，即便未能完全解决问题，但至少能减轻这些问题所带来的困扰。本章主要介绍从较高层面检验软件，而下一章我们将从底层细节开始，并逐步向上推进。我们将这种从开发人员视角出发，关注程序内部细节及底层结构的测试方法称为面向开发人员测试或开发人员视角的测试。
 

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！