在软件测试领域，测试自动化非常容易成为一个金块。考虑一个测试人员的情况，该测试人员进行了多次的手动测试，这些测试耗费了我大量的时间，我想要花时间专注于应用程序的其他模块。使用测试自动化就是一个完美的解决该问题的方案，对吧？
虽然自动化测试执行确实可以节省宝贵的时间，但它并不像听起来那么简单。
关于自动化测试的真相
很容易陷入陷阱，认为只要你设置一次自动化测试，然后让它自己运行。然而，事实是自动化测试并不是和我们想的那样“只要设置了就不用再管它”。
实际上，我们需要定期维护所有自动化测试脚本的源代码，包括更新代码和应用程序更新。没有维护源代码可能导致错误的测试结果。
关于自动化测试的另一个常见误解是它完全基于工具。虽然该工具很重要，但自动化仍然与人有关。这是因为测试自动化工具不会为我们完成所有工作，我们仍然需要具备自动化知识的测试人员来操作该工具，开发脚本并维护源代码。使用非技术资源只是“录制和回放”的这种方法永远无法维护。
平衡自动和手动测试
除了这些误解之外，其实你拥有自动化测试的能力在软件测试领域是非常有价值的，这个是毋庸置疑的。那么我们有多少测试可以用到自动化呢？全部？
事实是，我们根本无法自动化一切。假设我们可以自动化所有内容，假设我们可以测试每个代码块，每个细节，其实这是我们无法做到的。从测试覆盖的角度来看，100%覆盖率是一个梦想。这是不可能的。
即使你可以自动化所有内容，这也不是最好的方法。也不会将所有的测试都进行自动化。这有两个原因：
维护
你自动化的测试越多，你需要维护的源代码就越多，这就像是老鼠窝一样。反过来，如果你没有或忘记维护，可能会导致错误报告等问题，而你并不知道这些问题。相比之下，手动测试人员就能够识别测试和用户体验差异的问题，可以纠正可能导致错误报告的不匹配设置。
人员方面
一般来说，自动化从测试中没有了非常重要的人为因素。除了上面提到的问题之外，手动测试还可以比自动化测试更准确地测试真实场景，比如应用程序新引入的功能可能以不可预见的方式与现有功能进行交互。测试自动化不够先进，无法捕捉所有这些无法预料的情况。所以人的视角我们是不能丢弃的。
引入自动化测试的重点领域
如果我们不能将所有内容都进行自动化，那么我们应该将哪些内容进行自动化测试呢？
通常情况下，你会希望将应用程序中更复杂的部分留给手动测试人员，因为这部分可能出bug的地方更多。例如，如果你尝试在多个应用程序和不同技术堆栈之间实现整个端到端流程的自动化，则脚本更有可能中断。这就好比有一个人握着方向盘可以更容易识别出那些错误的转弯。
除此之外，这里有三种方法来决定是否可以自动化：
基于风险的方法
识别应用程序的高风险区域并自动进行冒烟测试，这是一项具有高影响力的简单测试。例如，如果90%的用户拥有相同类型的用户配置文件，你可能希望自动执行使用该类型配置文件登录的测试，因为任何问题都会影响90%的用户。其余10%的登录失败风险不足以保证自动化测试。
以对话为主导的方法
大多数上下文驱动的手动测试人员都是主题（模块）专家，他们对自己的领域非常熟悉，他们了解内部和外部测试的系统。让这些测试人员咨询自动化工程师以确定自动化测试的区域，例如冒烟测试或针对其他应用程序的测试，对于了解自动化可以在哪些方面增加价值（或在哪些方面没有价值）大有帮助。
探索性测试方法
探索性测试通常可以提供有关自动化的对话。那是因为在探索性测试期间，你会收集并记录信息和问题。然后，你可以使用这些信息来决定自动化测试在哪里有意义。
衡量自动化测试的价值
最后但同样重要的是，当我们自动化测试时，我们需要衡量该自动化的价值，以确保它提供我们想要的结果，并返回一个比手动测试所提供的更大的价值。
例如，如果你运行一个自动化测试100次，并且每次都通过测试，那么该测试是否确实提供了任何价值？如果结果确实准确，那么测试可能不是一个有价值的阶段，除非它是一个高风险的场景。但是，如果手动测试发现更多bug，我们必须询问什么更有价值：自动化测试所节省的时间，还是通过运行手动测试发现实际bug所节省时间？
这并不是说自动化测试没有价值，因为它肯定是有价值的；但这不是一个通用的解决方案。相反，这是一种我们需要从策略上采取并定期回顾的方法。
