自动化测试思考

自动化测试中存在的问题

编写维护自动化测试脚本成本太高了
天天在跑自动化测试，发现的缺陷数量怎么就那么少
自动化测试为什么就没有节约人力成本
自动化测试为什么就你们几个能用，那么多手工测试人员就不能用起来吗？
这些问题，其实本身不是自动化测试的问题，而是把自动化测试本身放错了位置。

正确认识自动化测试

自动化测试一般都是需要编写脚本，通过脚本的执行来达到测试的目的，自动化测试应抓住重点核心业务进行回归测试。这样可以减少开发维护工作量，还能尽量保证重点业务的测试质量，测试性价比是最高的。

自动化核心价值是保证主要功能完整可用，而不是发现多少缺陷。
自动化测试并不能减少测试的人力成本，而是为了加快测试反馈，提升测试质量。我建议自动化测试可以跟自动化部署工具绑定，在每日构建的时候，自动化执行，
自动化测试收效最高的方式：分层测试。

大家都明白，如果在项目临近发布才开始测试并发现缺陷，这样修复缺陷的成本就会很高，项目的进度也会很不确定。所以，就开发阶段来说，如果测试分层，在不同的开发阶段都进行测试，能很大程度上缓解这些问题。 

测试金字塔
测试分层的优势：
- 测试的成本
从经验不能看出，单元测试的开发成本要远低于用户界面的测试；如果在用户界面的测试中发现缺陷，修复缺陷的成本也是远远高于通过单元测试和的成本。这里说所的成本并不单纯只是开发人员修复缺陷所需的资源和时间，还包括了修复缺陷后测试人员进行回归测试所需要的资源和时间，以及项目延期等其他的项目成本。
- 测试的效率
用户界面测试需要准备数据和相关的系统，还需要在客户端/app中进行渲染，很可能还需要预先执行一些诸如登陆账户之类的操作，才能对测试用例进行验证，所以花费的时间比较长，得到的执行结果也比较慢，反馈周期长。
而单元测试能很快地验证很小的功能或者方法是否运行正确。而且单元测试运行时间段，反馈也及时。
- 缺陷定位的难易
显然，单元测试如果失败了，测试人员很容易知道被测试的特定功能或者方法不正确；而如果是用户界面的缺陷，测试人员就需要花费更多的时间来进行排查，确定出现问题的功能模块，最后再进一步地发现需要修复的功能和方法。
基于以上三条，或许会认为底层的测试，例如单元测试比用户界面测试要好，其实不然，单元测试固然有自己的优势，但是不代表只要有单元测试就可以了，因为其他层级的测试也有不同的用途。
- 反映真实的业务需求
通过单元测试如法从全局观的角度了解系统模块之间的交互，也无法通过方法的组合帮助用户完成业务目的；而由于用户界面的测试描述的是从用户角度出发的用户使用场景，因此可以更容易地阐述用户的行为和业务需求。
- 更加接近业务
由于用户界面测试描述测试的阶层更高，所以也就更接近业务；而单元测试描述测试你的层级更具体，也就更接近与实现。从测试金字塔的5层分布来看，不同层级的测试都很有必要，而我们也需要根据不同的测试所处的层级及其特点进行测试设计。

相比于传统的自动化测试，会有几个改变：

• 将开发拉入测试：其实测试工作也是开发一个很重要的工作内容，传统的开发测试分的很细的方式，不利于分层测试，像单元测试，还是需要开发多多投入。
• 将测试引入开发：分层的测试，需要对被测系统的开发结构有认识，至少你要知道你覆盖了多少了吧，甚至开发大致怎么实现的，不然UI前面对那些接口也不知道那很难评估测试结果的。
• 最好跟持续集成配合使用：重复利用自动化测试的执行成本低的效率，在工程集成完毕前后，更加自动地执行测试，及时的反馈测试结果，从而更好地提高测试效率。
• 使用Mock来实现分层测试，因为是分层那么就可能有隔离一些模块或者外系统，那么就可以用Mock来模拟这些隔离的模块，进行测试。
• 需要合理的评估测试覆盖，不同层次的测试程度都需要合理的评估，这个范围的控制是保证分层测试测试质量的最核心的规划，这个才是成功关键。

综上所述，分层自动化测试是追求覆盖的传统自动化测试的一种修正，充分利用自动化测试的优点，尽量规避自动化测试的缺点。当然分层测试也有些要注意的问题：

• 测试重复：分层可能对测试是重复的，在上层测过了，下层还继续测。从测试角度上说是重复测试，但是从整个流程看测试的话，不同层次的测试，属于过程的不同阶段，比方说单元测试，可以在编译后进行测试，在集成前就可以发现问题，而UI的自动化测试则更加滞后一点，功能不同效果不同，测试的重复还是可以忍受的。
• 测试遗漏：这个就很需要对测试覆盖的规划能力，而且这里要说明的一点，自动化测试不能或者很难做到全覆盖测试。手工测试还是不能放下的，而手工做到全覆盖是有必要的。
• 测试复杂度，分层测试需要工具比较多，人员能力比较强，要控制那么多工具进行测试，还要对业务，甚至开发有了解，还要开发人员参与进来，投入也不小。