书接上文：自动化新手要避免的坑（上）
H：维护测试设计
测试设计是将测试目标转换为实际测试用例和条件的过程。
作为一个初学者，我不了解测试设计的重要性，这可能是我作为自动化测试员的最大错误。随时进行任何测试都是荒谬的想法。为了有效地进行测试，测试人员需要设计测试，然后对它们进行编码。设计测试有助于创建有意义的测试，并使整个测试过程非常有效。
I：避免误报
当测试结果错误地表明测试通过但实际上没有通过时，就会出现误报。反之亦然。在测试人员中盲目相信测试报告是一个非常普遍的错误。例如，假设您正在使用使用不同测试用例编写的测试脚本来测试登录页面。测试报告表明登录已通过。在这种情况下，您需要验证登录是否成功。作为自动化测试人员，请不要因总是误报和误报而陷入错误。可以通过增加验证方法和重复测试来找出那些测试用例容易误报，建立误报后的确认机制。还有在编写测出用例的时候也要把测试用例的稳定性考虑进去。
J：专注于代码可重用性
一个测试用例不是它所应用的代码所独有的。在一个项目中，会出现许多相似的组件，它们需要相似的测试设计和测试套件。例如，在使用Selenium进行跨浏览器测试，我们发现网页的四个元素都是输入字段，并且需要类似的测试用例。在这里，您可以通过仅针对第一个元素编写测试来复制粘贴代码。尽管这将提供预期的结果，但问题在于，将来开发人员可能会以某种方式更改元素。现在，要更改测试用例，您需要更改您编写的每个测试套件中的代码。全部时间都浪费在查找和修改这些测试代码上。我犯了这个错误，我可以看出，测试时这变得非常难看。
为避免这种情况，您应始终专注于代码的可重用性。而不是一遍又一遍地粘贴代码，您应该构造一个带有适当参数的函数，并在每个元素上调用此函数。这样，如果将来有任何更改，您只需要修改功能就可以了。
K：不要相信 100％自动化
不要迷恋这个理想的指标，因为这将是一个自动化测试员的严重错误。作为测试自动化领域的新手，我很高兴为项目带来自动化。这导致我犯了一个错误，认为自动化测试可以完全替代手动测试过程。随着时间的推移，我知道这是不可能的。用自动化测试完全替代手动测试（100％）是一个神话。它永远不可能实现。作为该领域的初学者，请勿尝试实现此目标。仅在必要时自动化，并且仅在那些需要自动化的事物上自动化。
L：大局观
在测试时，您会遇到不同类型的问题。您将需要设定目标并对这些问题进行分类。全面的方法意味着使用较小的模块而不是较大的模块开始自动化测试。
作为自动化测试工程师，最大的错误之一就是要使用更大，更复杂的模块开始自动化。不要那样做！您缺乏对每个用户交互中涉及的入站和出站流程的了解。您甚至可能不具备处理棘手的测试用例的能力，并且最终可能会浪费大量时间而无所适从。因此，从小处着手，并从根本上增加自动化测试的覆盖范围。
M：参与探索性测试
作为自动化测试人员，常见的错误之一就是不将探索性测试纳入您的每周例行程序。探索性测试是一次必要的冒险，它有助于寻找新的测试用例。当我们进入自动化阶段时，探索性测试至关重要。仅使用测试脚本可能会忽略自动化测试中一些意外的重要测试用例。作为一个初学者，我们只想依靠脚本和预先编写的测试，应该避免这种情况。花一些时间进行探索性测试。您可能永远都不知道在野外测试时可能会捕获哪些错误。
N：UI 测试考虑变化
在较早的版本中，软件的用户界面发生了很大变化。自动化测试可以帮助我们重复执行测试，如果没有实现，那就没有意义了。在早期阶段，测试人员会像自动化测试人员一样忽略这些类型的错误，我也这样做。
用户界面的更改迫使我们更改测试脚本。有时，某个元素在将来的版本中会更改其位置，而脚本会利用该位置进行进一步测试。由于位置更改是测试所依赖的，因此完整的测试执行失败。例如，在自动浏览器测试中，如果某个图像的位置发生更改，则Selenium自动化测试脚本将无法找到该位置。这将使整个测试失败。这些依赖于用户界面的测试应尽可能少地编写。
- 郑重声明：文章首发于公众号 “FunTester”，禁止第三方（腾讯云除外）转载、发表。
技术类文章精选
- Linux 性能监控软件 netdata 中文汉化版
- 性能测试框架第三版
- 如何在 Linux 命令行界面愉快进行性能测试
- 图解 HTTP 脑图
- 将 swagger 文档自动变成测试代码
- Selenium Python 使用技巧（一）
- Selenium Python 使用技巧（二）
- Selenium Python 使用技巧（三）