初次接触自动化测试：基本架构设计的能力

作为新员工时，做的自动化测试是捕捉系统的窗口句柄然后往里面发送字符串，连测试结果都不能自动检查，还要自己去看日志或者截屏。尽管那时的自动化做得非常粗糙，但也极大地鼓励了自己。每天跑着这样的脚本，想象着这些脚本接下来一定会变得很强，于是乐此不疲。

开始主动向公司的自动化测试前辈（本部门、外部门）学习。满怀信心，利用加班时间来学习脚本语言和工具的使用。但很快就发现，自动化测试并不像我想象中那么美：

·一个非常简单的功能，写好再调通，花费的时间并不少。很多时候手工测试5分钟就能做好的事情，调好脚本要花1个小时。

·脚本执行时一旦发现问题，排查起来花费的时间也不少。一旦脚本报错，会再反复跑几次，先确认是不是真的有问题，再在脚本中加各种打印或者等待来定位问题。

由于测试的产品定制多、版本分支也很多，我发现如何把这些脚本管理起来，以便在不同的版本中运行也是个问题。

这些问题让我有些沮丧——大家都说自动化测试可以提高效率，怎么到我这里就不灵了呢？

我开始意识到，自动化测试不是有了工具，有一腔热情，然后通过加班就可以完成的事情。这需要有基本的架构设计能力，能有手段和方法检查脚本的运行结果，并能有效管理这些脚本。每一件事情背后都工程方法，需要有策略有规划，一步步来完成。

第二次自动化测试：自动化的意义

认为第一次自动化测试失败的问题，主要出在缺乏规划和设计上。既然找到了问题，我决定和我的小伙伴一起，再来做一次自动化。

既然是要做规划，第一步肯定是定目标。由于团队也是第一次做自动化，那从简单内容入手是比较靠谱的；另外回归测试中有大量重复测试工作，测试的内容也比较基础，很适合使用自动化。这样我们团队的自动化目标就变成了从简单的内容开始，将自动化脚本用于回归测试，达到100%自动化回归测试。

这个目标看起来没毛病，但实际执行起来却变了味。在“简单的内容先自动化”的思想下，大家心照不宣地做了很多非常简单的测试界面配置的边界值脚本。

由于希望把自动化脚本用于回归测试，这些测试配置的极简脚本就顺理成章地成为回归测试用例集。

但这样的回归测试自动化，大家打心底都不认同，觉得这些脚本的测试内容执行起来没有任何意义，就是说出去好听而已（我们实现了100%回归自动化测试）。运行几次之后，大家就很自然地不想再继续了。

这次经历让我对自动化测试有了新的思考——自动化测试要从解决烦琐工作入手，而不是从简单工作入手，要让团队看到自动化测试切实的效果。只有这样，自动化才能真正被团队接受，而不是变成劳民伤财的花架子。

第三次自动化测试：自动化脚本的误判

认真总结第二次自动化测试的经验教训后，准备再发起一次自动化测试实践活动。

为了保证自动化测试的有效性，我专门组织大家，从手工测试中选出那些需要反复执行的测试用例，作为自动化测试用例，然后从当前自动化测试技术的角度，对这些测试用例是否具备自动化的条件仔细梳理了一遍。我们对自动化测试平台底层技术进行讨论，并做了一些优化，还讨论制定了团队的自动化开发规程，讨论了脚本的组织和管理形式。领导也开始更加关心自动化测试，大家的激情都被重新点燃，干劲十足。

就当一切都在向着好的方向发展的时候，新的问题又出现了：自动化脚本出现了误判！换句话说，我们无法相信自动化测试的结果，自动化脚本运行结果是失败的测试用例，可能仅是自动化环境的问题；自动化脚本运行结果是通过的测试用例，实际功能却可能有问题。

我们想了很多办法去解决问题，比如每一轮自动化测试，同一个脚本都反复执行几次（如执行5次），然后设置一个脚本执行失败的容错值（比如设置容错值为2，即执行5次这个脚本，脚本失败只要不超过2次就算通过）；想办法保存所有的测试执行记录，然后再手工抽验测试记录，确认是否有脚本判断漏掉的异常。

其实这些问题，归根到底还是脚本的检查部分，或者说断言写得有问题。

让自动化脚本按照测试者的意愿执行测试操作其实并不难，难的是让自动化脚本可以像测试者那样检查预期。比如，对预期内的结果，自动化脚本要保证效率，要避免误判，除此之外，还要注意捕捉预期外的各种异常。

第四次自动化测试：规模化自动化

慢慢地，我们团队有了较多的脚本，但这些脚本都是基于用户接口设计的脚本，执行一个脚本需要做不少配置，我们的产品部署都很复杂，有时候需要多个产品才能完成一个功能。为了避免不同脚本之间配置干扰，每执行一个脚本我们就要初始化一遍，以清除掉当前的配置，恢复环境。尽管我们实现了并行化，但是自动化脚本的执行效率依然很低。当自动化率到10%左右的时候，团队好多同学都认为我们的自动化已经到头了，因为我们维护这些脚本已经很难了，再继续下去，自动化测试的复杂度会超过手工测试。自动化测试进程再次进入僵局，徘徊不前。

这再次刺痛了我，我发现我做了这么久的自动化，并没有真正感受到过自动化的便捷，相反它成为一个负担，我不知道接下来该怎么走。

这时又出现一个转机，公司的高层开始非常重视自动化，成立专门的自动化测试小组。高层领导直接定了一个很高的自动化目标，自动化率要达到80%。我们觉得这是不可能完成的任务。但是自动化测试小组的负责人却在领导的支持下，做了一系列的改革：

1）要求开发人员进行单元测试。

2）增加接口自动化测试。

3）对用户层面的自动化测试，在需求确定后，就要求开发人员确定用户层面的输入输出，且一经确定不能随意修改，然后自动化测试团队开始封装关键字。我们可以在测试用例设计完成后直接使用封装好的关键字编写测试脚本。这样我们真的做到了可以用自动化来做新功能的测试。

对那些自动化中的困难点，例如前面提到的每个脚本要恢复配置，自动化测试团队基于此给产品开发团队提交了自动化可测试性需求。我们通过脚本执行起来费时费力的操作，产品开发团队通过内部设计很容易就搞好了。

由于这个自动化测试团队是一个拉通了所有产品的资源部门，他们还将脚本按照场景做成了测试套，供不同产品团队在有类似需求时选用，大大加强了脚本的复用率，促进了自动化测试规模化发展，也让我第一次切实感到了自动化测试的威力。

这次自动化的经历给了我很大的启发。我感到自动化测试，并不是测试人员单方面能够搞定的事情，要想做好自动化，需要领导的支持，需要产品、架构、开发等全流程的支持。

自动化建设同样需要分层，可分为单元测试和接口测试，这样用户层面的测试就可以减少，版本质量也会更好，自动化测试的效率会更高。

从自动化测试技术的角度来说，第三次和第四次并没有本质区别，差别在于流程中各个角色的配合方式，也就是工程方法。我们需要全局看整个产品的状况，制定合适的自动化策略，以此来推动自动化测试发展。

讲完故事，我们再回过头来讨论一些与自动化测试相关的观点。聊了那么多，我认为自动化测试最基本的要求其实就是两点：

1）测试者能够充分信任自动化的结果。

2）自动化脚本可稳定连续运行，可维护，可移植。

自动化测试是值得每个测试者去探索和实践的，但我们也需要知道自动化测试的真相。

真相1：自动化测试并不廉价，其实自动化很贵。

自动化测试是用一段程序去测试另外一段程序，这中间需要花费的成本并不少。

真相2：自动化测试的意义首先在于固化能力，其次才是提升效率。

自动化测试的意义，首先在于固化能力——把原来测试人员的能力，通过脚本执行固化下来，形成标准的组织资产；其次是效率提升。从另一个角度来说，效率提升是反复执行带来的，是能力固化后的副产物。

理解了这一点后，我们可以更加理性地看待自动化，认识自动化的价值。我们应该本着固化能力的原则去设计自动化架构，发展自动化。通过脚本自动执行相关步骤只是自动化进程中的第一步，可靠的检查点设计、脚本的稳定性、脚本的组合和连跑、脚本的可维护性和可移植性，才是自动化架构需要不断打磨精进的内容。

真相3：自动化测试不是单靠测试人员就能搞定的。

自动化测试听起来像仅是测试人员的事情，但是想要真正做好自动化测试，达到规模化自动化的效果，并不是测试人员单方面就能搞定的。

摘取自刘琛梅老师的《测试架构师修炼之道：从测试工程师到测试架构师 第2版》