自动化测试最佳实践（一）

自动化测试的误区

自动化测试 != 写脚本

写脚本只是测试工程师的副业，顺手就搞定

自动化测试范围

自动化测试的范围：包括自动化测试的重点和难点、测试深度和广度：

自动化测试的重点：根据被测对象的价值，设计合理的UT/IT/ST自动化分层策略，明确整体测试重点及每一层测试重点

自动化测试难点：从测试技术角度来说，根据产品的类型及团队的能力，分析自动化品测试实施的难易程度，选择合适的自动化测试技术及工具

自动化测试深度从测试方法（场景，边界值，错误输入，单运行，多运行等）角度描述自动化测试的目标

自动化测试的广度从覆盖的角度描述测试，包括功能，性能，安全，兼容性等测试的自动化

按照优先级实施自动化测试

自动化实施时间较长，实施自动化时可区分优先顺序：

对稳定的功能优先做自动化

对已经通过的测试用例做自动化

对冒烟测试用例优先做自动化

高价值高风险对象优先做自动化

对流程类似，数据驱动的组合类测试(接口测试，压力测试，安全测试)优先实施自动化测试

兼容性测试(跨浏览器，跨设备)优先使用自动化

对自动化测试的难点要事先准备

被测对象涉及多种技术: 随着移动互联网时代到来，前端用户接口日益融合，后端架构微服务化，接口/安全/兼容性等测试越来越重要，软件系统日趋复杂，对自动化测试带来的挑战也越来越多。在选择自动化测试技术及工具时，必考虑所选技术路线对未来是否有影响，能否满足未来的自动化测试需求

动态内容的处理：软件中常见的动态内容有id、验证码等

测试环境的影响：在自动化测试执行时，由于测试环境的不稳定（比如数据库，网络，服务器性能）造成的执行失败的问题非常常见，自动化测试脚本中需要对这些问题提供必要的等待策略

复杂流程的处理：在一些比较复杂的流程中，涉及的步骤比较多，步骤间会有顺序，参数可能比较多，不同的参数可能会产生有细微不同的流程，对于这种测试场景，采用组合测试，以及模块化/数据驱动的方式较好

有些测试用例无需自动化

自动化实施成本很高，实施自动化测试必须考虑ROI，某些场景的测试用例可以不实施、或者暂缓实施自动化：

只使用1次的测试用例

性价比不高的测试用例

某些异常场景的测试用例

结果不可知的测试用例

不稳定的测试用例

提高自动化测试的可维护性

自动化测试的成本主要由两部分组成：脚本的开发成本及脚本的维护成本，提高脚本的可维护性，可以降低自动化测试的维护成本，可以采用的策略包括：

自动化测试框架必须支持模块化/数据驱动，支持测试环境分层管理，制定并完善测试脚本的编码规范

测试用例按照测试环境分组

测试脚本要尽可能简单，步骤保持在10~20步之间，流程控制要尽量少

使用测试用例的ID作为自动化测试脚本的ID，避免拿title做脚本或case的名字，ID应有意义，比如ST_ORDER_FUNC_0010

测试用例中的步骤要尽量直观，尽可能使用望而知义的locator

不要使用绝对路径的xpath，减少UI变化对脚本稳定性的影响

测试脚本需要不断的模块化/关键字化/数据驱动工作，应该建立相应的流程和制度，并由专人负责，以提高测试脚本的重用性

脚本的结构可以模板化，采用自动化工具生成大致框架

脚本的变更需要和测试用例同步，并使用自动化工具完成，将测试用例作为脚本的文档，对脚本、用例以及测试数据做变更管理

自动化测试元数据的管理：自动化测试的元数据包括测试时间、测试结果等，都需要妥善管理，为测试框架的优化提供数据支撑

推行组合测试

与研发工具链集成

源代码控制：包括SVN,GIT等变更管理工具

持续集成：如Jenkins，Bamboo等工具

缺陷管理平台：比如JIRA等

提高自动化测试的执行效率

减少不必要的等待，禁止使用强制等待：

使用Selenium Grid或者Jenkins，将测试用例拆分到多个环境上做分布式执行

考虑能否用集成测试或者单元测试代替耗时的系统测试用例

使用分布式或者增量式编译减少build时间

控制测试套的大小，可以将测试用例分级分类，不用每次都执行所有的测试脚本

定期检视从没有失败过的脚本，考虑其功能是否已经被别的脚本覆盖，精简冗余的脚本

自动化测试的基本原则

越早执行越好

执行的越快越快

执行的越多越好

越容易执行越好

自动化所有能自动化的