1.3 采用自动化还是手工测试

在求职网站上搜索软件测试的职位，同一个业务领域，同样的从业年限，自动化测试的薪酬普遍会比手工测试高。不少求职者在面试的时候告诉笔者，他的职业规划是做一两年手工测试，之后转做自动化测试；又或者，面试者会告诉笔者，他不想做手工测试，只想做自动化测试。

以上种种，看起来貌似自动化测试比手工测试有前景。那么，自动化测试真的比手工测试“高大上”吗？

手工测试完全依赖人工，由人去做一系列的输入、点击操作；而自动化测试则是通过测试脚本，由代码逻辑控制测试步骤。自动化测试和手工测试本质上是测试用例在执行过程中两种不同的类型。既然它们的核心都是基于业务的测试用例，或者说测试场景，那么测试人员在编写用例的过程中就不应该受到“这是自动化还是手工”之类的束缚。

前文提到“测试脚本把你从手动执行的烦琐工作中解脱出来”，但我们并不能把“自动化测试”的效果完全等同于“手动测试的自动化执行”。因为在手动测试过程中，测试人员往往会突然冒出灵感，想出一些新的用例，也可能留意到之前没有注意到的细节问题。而自动化测试的检查点是固定的，这种局限性意味着相同的用例，手工执行发现的Bugs往往比测试脚本发现的Bugs多。换而言之，对于稳定的功能场景，由于测试步骤和检查点都已经固化了，我们可以考虑自动化。这样一来，如果程序改动影响了之前的功能逻辑，就可以在自动化脚本的运行结果中直接反映出来；而对于不稳定的、仍在迭代过程中的功能，我们通过手工的方式，利用探索性测试的思维，可以快速展开测试活动，这会比准备测试脚本更为高效。

无论是手工还是自动化，都需要结合业务场景来制定相应的测试策略。对自动化和手工测试的误解容易造成两种极端。一种极端是认为自动化的时间成本和学习成本太高，迟迟不启动自动化。另一种极端是盲目追求自动化测试覆盖率，强求100%的自动化。这两种极端都会给测试人员造成极大的痛苦。

诚然，自动化测试比手工测试在前期花费的时间要多得多，没有捷径可言。但在测试工具和技术高速发展的今天，如果团队由于时间和学习成本而放弃自动化，这种团队应该远离。因为它没有考虑测试人员的成长曲线，多半也会在开发延期的情况下，为了保证按时上线而压缩测试时间，最后把上线压力都抛给测试人员。这也正好解释了不少同行离职的原因，是想尝试自动化实践，而团队没有成长空间。