资料来自网络（黑夜小怪）

 

自动化测试概念

 

现在越来越多的人在关注使用自动化测试。似乎自动化测试已经成了一个“高级"。但是其实很多人对自动化测试本身有很多误解，自动化测试不是银弹，不是瑞士×××。自动化测试并不能代替测试本身。很多领导或者客户了解到自动化测试，就都会有用自动化测试覆盖测试的冲动。在这种冲动下，投入大量的人力财力，经常是无功而返的。自动化测试到底怎么了？

 

 

自动化测试的原则

 

原则1: 针对重点业务，进行回归的自动化测试

 

自动化测试一般都是需要编写脚本，通过脚本的执行来达到测试的目的，一般被测系统稳定的话，那么脚本是不需要怎么维护的，反之的话，就比较恐怖了。所以要进行自动化测试，就需要下工夫去开发维护脚本，而且工作量不小。由于他有这种特性，所以自动化测试，尤其是针对业务的功能测试中，最好不要去拼命地覆盖全业务，覆盖所有案例，而且抓住重点核心业务进行回归测试。这样可以减少开发维护工作量，还能尽量保证重点业务的测试质量，测试性价比是最高的。

 

 

 

原则2：针对稳定的业务（或接口），在环境比较稳定的情况，前期投入脚本开发，有利于减少后期维护成本

 

另外，尽量针对较为稳定的业务，或者较为稳定的测试方式进行自动化测试，这样人力的投入主要集中的初期脚本的编写，而之后由于较为稳定，那么脚本的维护工作量也不会太大。当然，这种投入不是越早越好，很多项目经理都觉得自动化测试及早投入，这样我们在项目研发中就可以及早用，及早的享受到自动化测试带来的便利。其实自动化测试，一般要做环境比较稳定的情况再投入开发，这样可以减少维护的成本，另外对于不稳定的环境，执行自动化测试也没有太好的效果，经常跑出的脚本一堆问题，分析半天其实就是不能用，这样测试的意义就不大了。

 

原则3：自动化测试主要是为了保证主要功能完整可用，而不是为了多发现缺陷

还有很多自动化测试，几乎每天都在跑，老是发现脚本错误，怎么就没有真正的缺陷呢，出缺陷的概率这么多，就盲目地增加校验点，结果还是一样。其实不用为了发现不了缺陷而烦恼，自动化一般都是保证主要功能完整可用，这些是他的核心价值，而不是发现多少缺陷。

 

原则4：自动化测试并不能减少测试的人力成本，而是为了加快测试反馈，提升测试质量

 

当然，还有些人，做自动化就是为了节约手工测试人员的人力成本，做着做着，发现做了那么长时间自动化测试，为什么人力成本没有减少。不减少我为什么做自动化测试啊？这也是一个误区，自动化测试并不能减少测试的人力成本，而是为了加快测试反馈，提升测试质量。我建议自动化测试可以跟自动化部署工具绑定，在每日构建的时候，自动化执行，可以更早的发现产品的问题，自动地反馈开发人员，从而提升开发修复缺陷的效率。

 

原则5：不要对录制回放抱有幻想了，可视化也不是一个好的想法

 

还有一个问题，这个问题在初期开始做自动化测试的人，会比较容易走上的误区----录制回放最好了。其实录制回放，并不好，录制的脚本很多时候是不能直接使用，而且业务或者系统发生变化，很有可能很难修改脚本需要重新录制恢复，这样的工作量也不小。而且还有很多人，自动化测试脚本应该跟业务能挂钩起来，让人一目了然我自动化测试脚本都做了些什么，脚本最好能做到"可视化"。其实这些看似的方便，都给脚本维护带来很多困难，业务和系统是在变化的，脚本是要不断维护，可视化和录制回放其实并不能提升效率，反而是为脚本维护增加工作量。建议如果有能力的话，对脚本本身进行管理即可，编写脚本不用录制回放，使用一些辅助工具，或者设计一些框架，编写脚本会更好。

 

原则6:开发参与自动化测试，让开发和测试融合在一起

 

很多人认为自动化测试执行这么方便，是否手工测试人员可以进行自动化测试啊？可以吗？很多人持不同观点，有的人认为测试其实要成为开发测试，有开发能力，去写自动化测试脚本；还有的人，觉得测试和自动化测试要分开，两个团队管理；还有的人任务，测试执行，测试数据编写等可以让手工人员参与。其实我觉得这都不是最好的想法。真正应该参与自动化测试的应该是开发。


题外话：自动化测试用例编写


  1. 测试用例名同测试用例的编号，例如用例名统一以case+编号的形式开头； 

  2. 每个测试用例粒度必须尽可能小，短小简单的测试用例易于调试。如果测试用例不得不长而复杂，则把它分成两个或更多的私有方法，并单独调用这些方法。尽量把重复任务放入一个方法中，这样它可以被多个测试用例调用；

  3. 所有的测试用例必须作为一个独立的测试用例运行，每个独立的测试用例负责自己的初始化和清理任务；

  4. 测试用例需要记录操作步骤；

  5. 测试用例执行出错要截图，从日志查看错误能一目了然；

  6. 测试用例要有合适的验证点，符合测试用例的期待结果；

  7. 测试用例要尽量处理所有的异常以健壮；

  8. 测试用例要能无人值守运行，尽可能完善CTS集成的测试计划；

  9. 初始条件用例执行失败，结束后面所有依赖用例。