自动化测试思考

一、如何理解自动化测试？
　　每个面试自动化测试的，80%会被问到这个。不用太宽泛，可以从下面几点考虑，聊聊自动化测试给你的工作带来的好处：
　　1、用具体的举例，讲述自己在操作过程中是如何提高效率的。比如从回归测试开始讲起，重复冗余的操作步骤，你是否该想想可否能用自动化工具（QTP，TestWriter等等）实现，达到目的；
　　2、性能测试的时候，遇到的一些突发状况。人工制造场景总是有瓶颈，那么可以利用性能测试工具，进行自动化测试的；
　　还有很多从回归角度出发，会用到自动化测试的回答，大家可以考虑。
　二、用过的自动化测试工具有哪些？任意讲其中一个来谈谈对自动化测试的感受。
　　QTP、selenium、TestWriter等，这些这几年比较流行的自动化测试工具都可以来聊一下。比如：自动化测试工具TestWriter，说说这款工具优缺点，以及结合自身经历，讲讲在进行用例测试的时候是否遇到问题？作为一款测功能性、测回归、测兼容性的自动化测试工具，TestWriter是否在操作界面、功能是否完善，都可以作为一个阐述的点。这里不做多说，感兴趣的可以搜索TestWriter或者自动化测试工具，进行了解。
　三、自动化测试框架都有哪些？
　　1.模块化框架(test script modularity)
　　2.函数库结构框架(test library architecture)
　　3.关键字驱动测试框架(keyword-driven/table-driven testing)
　　4.数据驱动测试框架(data-driven testing)
　　5.混合型框架(hybrid test automation)
　　四、测试用例的设计可以自动化吗？
用例设计属于重复次数少的智能活动，不太适合自动化。但也有一些场合可以进行一定程度的自动化，提高设计效率，但不能指望能完全取代智力的测试活动。实现这种目的的工具有时称为测试输入生成工具。
自动化过程中遇到的问题
　　我们经常遇到的问题是：有一些控件是通过API找不到的，比如一些状态栏上的控件，还有一些WEBVIEW，无法有效地从WEBVIEW中选择到控件，API基本上达不到预期的效果。
　　从我们的角度理解，有很多这样的操作是没有办法完成自动化，或没有办法按照我们预期的成本去实现自动化的。有一些解决方案不是最优却更合理，比如一些控件，其实我们的目的只是检查它到底存不存在（从可见性上讲），虽然我们可能拿不到控件，但是我们可以用预期的图像与当前做对比，这样也能达到测试的目的。
我们当然没有办法把所有用例都实现自动化，比如多设备之间的交互和验证码的问题。验证码有办法实现，但成本比较高。对于这方面的问题，我们认为既然有些东西没办法实现自动化，那就干脆不要做自动化。自动化要尽量保持简洁、稳定、高效，做了大量的工作去实现而稳定性却不好，这样的尝试是得不偿失的。
具体到一些复杂的多设备交互场景，自动化可能难以低成本的去实现。

UI自动化的理解
　　UI自动化无法替代人工，受限于现有的技术和测试复杂度，很多地方没有办法用UI自动化。它的容错性也差，辛辛苦苦写了UI自动化脚本又要根据开发的变化时时维护。另外，除了回归验证以外，收益不高，UI自动化的介入基本上在大量的人工测试之后，能发现的问题并没有想象的那么多。很多人对UI自动化的期望是：UI自动化能代替人工作，就不用人工去做了，只要写一个自动化脚本就可以了。这是不可能的，它发现的问题并不是很多，不能期望UI自动化帮你做太多事情。
　　让“自动化”自动化，意思是在实现整体的自动化之后，我们希望自动化可以为上游的固件产出提供测试接口，把整个流程连接起来，为下游报告提供一系列的统计分析结果，为产品质量提供有说服力的数据。
　　很多公司可能在自动化上还要人工做一些干预，比如一些测试的预置条件需要人工干预。自动化如果不能完全自动起来，需要人工干预，需要人来执行，那就不是成功的自动化。一个理想的自动化就像一个黑盒子，数据从这里流入流出，为我们提供一些信息和质量数据。
　　UI或专项测试做完之后，我们现在的方向是通过底层的东西了解系统的问题。安卓发展到今天，应用质量趋向于稳定，很少有线上APP崩溃的体验了，但是不崩溃并不代表它已经做到足够优秀的程度了。我们希望通过调用栈的信息去获悉耗时和卡顿的具体原因，或对流畅度、资源占用做分析

作者：51Testing   来源：51Testing软件测试网原创