自动化测试在测试部门的策略

【就本公司的一篇论述，每个公司不同情况也不同】

先说软件测试工作的本质意义是什么？保证软件质量？肯定不是！测试不能保证软件质量，开发才是。软件测试的目的是展示软件质量状况.

自动化测试的概念：

计算机软件，替代人类简单记录、识别、分析结果的工具，在软件过程中，为了保障软件的可靠性、可用性、健壮性以及高性能，便出现了“测试自动化”这个概念

似乎自动化测试是个趋势，把人为驱动的测试行为转换为以机器驱动为主，由测试人员根据测试用例规程一步步的执行动作验证结果，同时，还能节省时间和测试效率。但是，自动化测试的收益并不是看上去的那么美，以笔者这些年的自动化测试经验和结合大公司的同事朋友交流的来看

自动化的弊端：

• 人员
  • 较高的学习成本，同时核心人员的流失会导致整个自动化测试项目的工作停滞
• 需求
  • 频繁的需求变更以及UI变化给测试脚步的维护成本带来直线上升，目前android测试国内大都基于UI测试方向，这是显而易见的弊端
• 成本
  • 收费的工具可能好用点，但是也需要学习，且市场上的人员大都来自开源软件，免费的则需要二次开发
  • 录制回放的工具最不靠谱
  • 首次运行的脚步最费成本，后期由于需求以及UI改动的成本是最关键的部分，即开发和维护成本都很高
• 时间
  • 短期项目，自动化收益会远远大于成本
• 不是所有测试case都能自动化
• 自动化不是所有测试阶段都适合
• 自动化也需要专业的设备支撑，比如功耗测试，温度等硬件相关的
• 发现的问题会非常少，大部分在运行一次就发现了（稳定性测试除外）

自动化的优点：

• 速度：跑的比人工快，速度优势
• 重复性：跑的比人工测试多，覆盖的与人工不同，多在重复性
• 长时间：24小时可以执行，人不能不睡觉
• 可能会省钱
  
  

自动化测试其实就是一种测试手段而已，测试手段部分初级中级或高级，也不是那么高大上，完全不需要仰视或附和，手工测试也是行之有效的测试手段，跟自动化测试本质上无区别。虽然说自动化测试并不是看上去的那么高大上，但是有个好处，就是帮助测试人员有机会深入了解软件。

测试讲究的是测试全面性，所以自动化测试的考虑要从它的适用性来考虑，不能搞自动化而上马

自动化的适用范围：

回归测试，兼容性测试，稳定性测试，压力测试，性能测试，接口测试，端到端测试

回归测试： buildcheck/smoke测试等需要做build检查结果，快速给个反馈，强调的是反馈及时，不是覆盖全面，是非常basic的功能

兼容性：代表的是Android CTS，这里的兼容性除了CTS之外，还要检查国内的TOP100应用和游戏测试

稳定性：长时间反复24小时不间断执行，可以发现应用或系统在长时间运行后的累积问题，诸如内存泄露等

压力测试：针对接口或应用的某一关键动作进行的大批量或快速的动作序列，android上用monkey随机性测试有效发现弥补人工发现不了的空指针或其他异常情况。

性能测试：主要是服务器接口性能的测试，通常使用loadrunner/jmeter等工具模拟高并发测试服务器性能能够承受到多少，终端的有CPU，内存的检测

接口测试：主要用于RESTFUL API接口测试，对端到端应用比较适合，对后台管理系统等也比较适合的测试类型，脱离了UI是非常好的测试。

端到端的测试：是结合接口测试以及终端测试的特点，让两者有机的结合起来

自动化测试的趋势：

自动化测试要结合自动化持续集成，让测试持续进行

测试用例设计：要根据项目情况，哪些适合提出来做自动化，不能让自动化成本比人工更高

代码走查（静态检查）：

开源的有CheckStyle，PMD，FindBugs，静态的商业大名鼎鼎的Coverity，还有Fortify等

接口测试：

通常需要接口文档，常用与端到端的测试过程中

用户界面：

这个通常最难，并不是难写，是难于维护，变化太快，成本太高

所以目前很多公司为了降低成本引入了“遍历测试” 即遍历菜单树的方式，比monkey压力要小，并且只点击有意义的控件，一般用于兼容性和稳定性检查。

 

目前终端自动化测试的有：

build check/smoke等回归测试，应用兼容性测试，压力monkey测试，MTBF稳定性测试，应用压力测试

半自动化（依赖工具和人工运行和检查）的有：

功耗测试，续航测试，性能测试