艰难的应用程序自动化历程

              最近，完成了Framework自动升级的设计和构建，虽然有很多不尽人意的地方，但是也算是应用项目自动化测试的一个起步了。

              从我进入公司开始，就一直在研究自动测试，但是复杂的应用程序流程，多变的客户需求，以及自动测试工具的种种局限，当然还有个人技术水平的影响，都无法让应用产品的自动化程度达到一个令人满意的程度。虽然写了无数个自动测试的脚本函数，虽然完成了很多个项目的自动测试Project，但是始终都只是停留在“自动化手工操作”这样一个层次。我深知自动测试的概念远比我们已经做到的要更加的深刻，却也无能为力。完成的自动测试脚本永远不能覆盖全部的应用程序测试点，为什么呢？总结一下，原因有以下两个方面：

              1：没有选择正确的自动测试的切入点：应用项目和产品不同，其中的环节有很多相关的联系，而我们在进行自动测试脚本的设计的时候，往往只是停留在用户操作的基础上进行，而忽略了内部这些互相影响的环节。也就是说，自动测试开始进行的切入点不正确，没有将要测试的内容模块化。这一点是造成现在的测试脚本不能完全发现问题的主要原因。如果能完成一定数量的单元测试脚本，自动测试就不会总是停留在“冒烟测试”“回归测试”这些方面，而是能真正的起到发现Bug的作用了。

              2：没有选择正确的测试自动化内容：这一点是在完成了Framework的自动升级测试脚本后，我才感受到的。以前做自动测试，基本上是把我会进行手动操作的地方全部用自动测试脚本实现一遍，而实际上因为缺少一些数据的验证，功能点的检查。即使有了错误也无法发现。而实际上对这些操作的验证，可能完成自动脚本的时间远比手动操作要费时费力。而对于某些操作，自动测试能够最大程度的提高效率和发现问题。比如smartdownload，如果让测试人员自己去设定一些service，运行客户端成后，检查客户端下载的文件和服务端的文件版本，日期是否正确，如果不借助工具完成，会是一件非常费力的事情。但是如果是由自动测试完成这些工作，不但提高测试效率，而测试结果真实可靠。再比如LeyserUpdater的运行，先撇开升级后的环境是否正确，单单执行这个操作，如果是从一个stage环境升级，需要大概30分钟，如果是虚机运行或者有多个产品同时升级，可能时间更长。而每天完成了Build后，测试人员往往是早上到达公司才开始升级测试环境，如果还要包括stage环境的恢复等操作，可能时间更长，而实际上这部分操作主要是Copy虚机，Copy文件，执行Leyserupdater这些操作，那么它的可自动化程度就很高。相信现在已经搭建好的每日Build后自动升级的环境，应该能带给Framework测试人员一些益处。所以说，选择一个正确的自动测试内容，也是自动化测试成功的一个基础。

              自动化测试的历程是艰辛的，因为有很多我们不清楚地地方需要继续的发掘，但是在经历了多次的失败后，能总结出一些有益的东西就是成功的。还有很多我们不了解的地方，也许还在走弯路，但是我相信只要善于总结，善于探索，这条艰难的道路总有一天会变得简单…