自动化测试的痛点
说到功能自动化测试，我们可能首先会想到QTP、Selenium等诸多的自动化测试工具和解决方案，如何使脚本开发变得简单、如何使脚本维护变得容易、如何提高脚本开发的效率等话题，一直以来都是自动化测试领域关注的焦点问题。
然而无论是哪种工具哪种解决方案，都离不开测试脚本的开发，有过脚本开发经历的人应该有体会，虽然设计良好的自动化测试架构可以简化脚本开发，但是面对成百上千上万的功能，开发和维护脚本始终不是一件容易的事，其复杂度绝不亚于一个开发项目。
脚本开发和维护工作量会与被测系统的复杂程度和变更有关，下面是一些举例：
页面输入项越多，脚本编写工作量越大；
页面输入项名称的改变，脚本也需要调整修改，例如将“移动电话”改成了“手机号码”；
页面必填输入项的增减，会使得脚本不得不跟着调整；
页面输入项的类型改变，脚本也必然要做修改，例如“学历字段”原来是文本输入框，后来改成了下拉选择框；
菜单名称修改，测试菜单的脚本需要调整。
自动化测试之所以实施起来困难重重，究其根源还是测试脚本导致，那么有没有一种自动化测试是不需要编写一个个测试脚本的呢？
做过安全测试的应该知道AppSan这个工具，只要告诉AppSan要检测的系统地址，进行一些简单的用户登录的配置，AppScan就可以自动对被测系统进行检测，找出可能的安全性问题并生成报告，不需要去写任何的测试用例和测试脚本(手动探测还是需要录制脚本的)。
如果在做功能自动化测试时，也有一个像AppScan之类的工具，不需要写那些繁琐的测试用例和测试脚本，只要扫描一下，就能测试出系统的功能性问题，那将是多么令人兴奋的事情！
然而，市场上并没有也不可能有这样的通用工具，毕竟功能测试与非功能测试不同，是与被测试系统紧密相关的，即使有这样一个工具也一定是专门针对某一个被测系统的。
幸运的是，笔者的被测系统是典型的信息处理类的web系统，模块多、菜单多、功能点多、页面风格及交互方式统一规范，正是由于这些特点，使得这种无脚本自动化测试成为可能。
下面就来介绍一下这种扫描式的自动化测试是如何进行的。
扫描式自动化测试
针对被测系统的特点，采用的自动化测试策略是：只针对基本的增删改查功能进行自动化测试。
按照粗略的统计，被测系统中功能模块近30个，菜单近800个，按照平均一个菜单内有5个功能点计算，总的功能个数将达到4000个(实际功能数应该远高于此)，假设在这4000个功能中，基本的增删改查功能占到25%，将会有1000个功能需要进行自动化测试。
如果每个功能对应一个测试脚本，将会有至少1000个测试脚本需要开发和维护。
针对以上需求和特点，结合过往自动化测试的实践经历，笔者提出了“扫描式自动化测试”的方案。
其核心思想就是将操作步骤类似的测试用例或者测试脚本，抽取出通用的测试规则，针对测试规则去编写扫描测试程序，只要是符合测试规则的功能，都可以自动被扫描发现并被自动测试，无需编写一个一个的测试脚本。
扫描测试程序的大概流程如下：
下面是测试用例和测试规则的举例：
新建用户、新建管理员、新建用户角色、新建管理员角色4个测试用例，正常是要写4个测试脚本，现在都不需要了，只需要运行一下扫描程序，就可以自动被发现和测试。
下面是对扫描式自动化测试的定义和特点总结。
能够对被测系统的功能进行搜索并自动进行测试的过程。
适合基本功能的测试，如增删改查等，不适合业务流程场景的测试。
无需编写特定功能的测试脚本，只有一个扫描程序即可完成所有增删改查的测试。
无脚本维护工作，例如页面增加了必填输入项，输入项名称变了，类型变了等，都不需要调整扫描程序，只有页面元素的定位属性变了，才需做相应调整。
测试的范围不固定，扫描到10个新建功能，就测试10个，扫描到100个，就测试100个，如果新开发了100个新建功能，只要是符合测试规则的，都可以被测试到，无需额外编写脚本。
测试数据不固定，系统中有什么数据就用什么数据，不会特意准备测试数据。比如修改功能的测试，默认选择列表中第一条数据，然后修改保存。随着系统的不断运行，扫描测试所使用的数据也会发生变化，可能会发现更多的问题。
覆盖度高。针对一个个功能的测试脚本，通常会选择重要度高、使用频繁的功能来做脚本(毕竟是要投入脚本开发成本的)，覆盖度有限，采用扫描测试后，所有功能都会测试到，覆盖度大幅提升。
与常规自动化测试的对比：
下面是运行测试的过程：
下面是扫描结果示例：
扫描式自动化的实现
具体实现不依赖于某种工具，qtp、Selenium、RobotFramework等都可以实现，笔者用qtp和RobotFramework均做了实现，实现过程大同小异，一些关键点总结如下：
1.与常规自动化测试相同，页面对象同样需要做封装，菜单、文本输入框、下拉框、日期选择框、列表选择、树型选择、新建类按钮、编辑类按钮、保存类按钮等等。
2.菜单遍历逻辑实现，扫描程序中最核心的循环是菜单遍历，登录系统后，根据菜单的元素定位属性，找到所有菜单对象，然后循环点击，每点一个菜单后，对当前页面做增删改查测试，然后进入下一个菜单继续测试。要根据具体被测系统的菜单导航方式来实现。
3.页面自动输入实现，当新建页面打开后，要能完成所有输入项(至少是必填项)的自动数据录入，例如文本框输入唯一字符串，下拉框选择第一条记录，日期框输入当前日期等等，如有特殊业务需求再做特殊处理。
4.批量定位元素的应用，扫描程序中大量使用了批量元素定位，例如找到一批菜单，循环点菜单，页面中找到多个文本输入框、多个下拉框，循环自动赋值。
5.错误检查处理程序，当点击某个菜单、某个新建、某个保存时，需要做断言检查，成功则继续，失败则跳过，扫描程序不会因为断言失败而结束。
小结
从事自动化测试已有多个年头，从最早的QTP录制脚本到QTP描述性编程、Selenium再到RobotFramework，都有做过尝试。但大多都因为投入少，时断时续，见效慢，耗时耗力而无功而返，可谓是此起彼伏，一波三折，最终还是采用了这种扫描式的自动化测试方案，一直沿用至今。
还是那句话：只有适合的才是最好的，希望通过本文，可以给大家在自动化测试领域多一些启示。
