下载掌阅APP，畅读海量书库
立即打开
在1.3节中，我们了解了开展UI自动化测试的必要性。本节我们来谈谈如何开展UI自动化测试，或者说，如果领导安排开展自动化测试工作，我们该如何组织呢？
（1）需求分析
如果领导的需求明确且细致，我们按照领导的思路去执行即可。不过更多时候，领导的需求并不明确，领导提出这些需求也许是为了进行工作探索，也许只是心血来潮，还有可能是期望减少测试人员投入，节省测试工时。这里提醒大家，一定要避免盲目开展自动化测试，避免出现“自动化测试脚本始终跟不上UI页面的调整速度，自动化测试脚本无法成功执行、名存实亡”的情况。在开展自动化测试时，我们的第一步一定是评估并确定哪些场景或哪些模块相对稳定，适合开展自动化测试，或者说一定要明白某个场景或者系统模块实现自动化测试后，能给我们带来什么好处。
当需求不明确时，贸然开展工作，大多只有一个后果，就是“经理费心，组员费力，领导不满”。为了避免“下课风波”，我们一定要在开展工作前，深入了解客户（领导）需求（痛点），纠正领导不恰当的预期，在开展工作前，和领导达成一致目标。接下来，我将描述几个场景，大家可以看看自己是否曾有过如此“不堪”的境遇，如果你所处的项目团队恰好也是如此，那么就让自动化测试“生根发芽”，并期待它能长成“参天大树”吧。
● 场景一：团队中开发人员提交的版本质量很差，甚至经常出现业务主流程无法“跑通”的情况；开发人员频繁提交、部署测试版本，测试人员一遍遍地重复冒烟测试（准入测试），测试人员成了“糟糕版本质量的买单人”。
● 场景二：每个版本上线前，项目团队会安排一轮验收测试（终验），在进行验收测试时，除了要重点验证新版本的功能外，还需要对历史功能进行必要的验证；可是领导往往只会留出新功能验证的测试时长，不会考虑历史功能的回归测试时长；常见的抱怨就是：“这么点新功能，怎么需要那么长时间测试？”
● 场景三：虽然开发人员经慎重评估后一再表示新功能的开发或者缺陷的修复不会影响其他功能或模块的使用，可每次你“偷懒”的时候，总会出现令人懊恼不已的“逃逸”缺陷，而在此时，“锅只能由测试人员来背”。
● 场景四：在1.0版本中，测试人员手动测试发现的缺陷已被开发人员修复，并且回归测试成功，在x.y版本中，测试人员又发现了该问题，于是，在每个待发布版本的验收测试时，我们又增加了工作——对历史缺陷进行回归测试，而历史缺陷越来越多，会“压得测试人员喘不过气”。
● 场景五：项目团队采用快速迭代、敏捷或者DevOps开发模式，因此项目负责人要求测试人员必须具备对线上版本进行快速验证的能力。否则会出现类似“为什么总是测试人员在拖后腿”的言论。
● 场景六：在1.0版本中，系统上线了×功能，该功能是系统的核心功能，后续版本的扩展模块和此功能多有交互，或者相互调用，于是在每个版本上线的时候，为了保证新功能的引入不会影响×功能的正确性，测试人员“不得不对其进行频繁的回归测试”。
想必各位或多或少都遇到过与上文所述类似的场景。自动化测试是应对类似场景的一种途径、一个重要发展方向，是测试体系中颇为重要的一环，也是测试组织技术成熟度的一种体现。自动化测试具有快速、高效、可复用、一致等特点，在一定程度上可以替代部分手动测试的工作，提升测试效率，特别是在回归测试阶段。自动化测试有序、规范进行，是提高测试效率、保障产品质量的重要手段。
（2）方案选择
为了保证自动化测试有序进行，保证自动化测试的覆盖率，自动化测试的落地方案应考虑以下方面（这里以Android自动化测试为例）。
● 自动化测试的层级。优先开展Android的UI自动化测试，根据项目成熟度、人员技能储备等情况适时开展接口自动化测试。
● 自动化测试的对象。优先覆盖Android端和移动Web端，后续覆盖iOS端。
● 自动化测试的场景。需要覆盖冒烟测试、重点功能回归测试和缺陷回归测试。
● 自动化测试的工具。结合公司实际情况，自研测试工具。
● 自动化测试的脚本语言。结合测试团队人员的技术栈，选择脚本开发语言。
● 自动化测试的框架。考虑到用例重试场景、分级分类等需求，选择单元测试框架。
● 自动化测试用例的分层。考虑到测试用例的健壮性及后期维护成本，自动化测试用例必须分层设计。
● 自动化测试用例的分级。考虑到针对不同场景执行不同用例的需求，自动化测试用例必须分级。
● 自动化测试用例的执行策略。自动化测试支持3种用例执行策略，分别是开发人员每次提交代码自动触发，以一定频率自动执行（如每周晚上），手动触发执行。
● App运行载体。就Android自动化测试而言，其支持真机（特定机型）和模拟器（如逍遥模拟器）载体。
● 自动化测试的工作模式。由多位同事负责，如同事A负责重点功能用例开发，同事B负责缺陷回归测试用例开发等。
● 自动化测试脚本存储。自动化测试脚本需要本地运行通过，内部评审通过，上传GitLab存储。
● 持续集成。考虑到UI自动化测试有持续集成的需求，因此项目团队的集成工具（Jenkins或Travis CI）应保持一致。
● 自动化测试赋能。自动化测试工具前期为内部使用，后期要提供给上下游团队使用，即赋能产品及业务团队。（需要考虑自动化测试本身的受众是谁，是否只给测试人员使用，还是要提供给研发人员等其他人员使用。）
● 自动化测试的执行环境。如果我们期望未来将自动化测试工具作为一个公共的执行平台，则需要单独准备一台计算机，用于自动化测试的执行，该机器的环境需要和本地环境保持一致。
（3）环境准备
在确定UI自动化测试落地方案后，即可根据方案准备所需环境。
● 本地环境。
本地环境包括测试人员的计算机、开发语言环境、Appium工具、代码编辑器、自动化测试设备等，其中开发语言环境版本、Appium工具版本、自动化测试设备类型等需要尽可能保持一致。
● 代码执行环境。
需要单独准备一台计算机，用于自动化测试的执行，该机器中的环境（测试工具、Python版本等）需要和脚本开发环境保持一致。
● 配置管理环境。
如果是多人协作编写自动化测试用例，则脚本就会涉及集成的需求，这里我们需要提前确定代码、测试数据、测试文件、测试驱动等资源的管理工具是使用SVN还是GitLab。
● 持续集成环境。
因为自动化测试有持续集成的需求，所以我们需要提前确定持续集成工具，当前比较流行的有Jenkins、Travis CI等。
（4）系统设计
就像工程建设需要经过严格的方案设计，然后根据设计的方案进行施工一样，UI自动化测试框架也需要事先进行合理的设计，以增加其稳定性、可维护性、可扩展性。简单来说，我们需要考虑整个框架的目录结构，比如各个公共模块的封装，测试文件的管理，配置数据、测试数据和代码的分离，日志的管理等。
当然，框架的确立并不能一蹴而就，而是一个持续演进的过程。这个阶段的重点是把大体框架搭建出来，然后在实际工作中慢慢优化迭代。但是框架如果完全没有设计，后续就可能会推倒重来，费时费力。本书的第12章将会介绍一个UI自动化测试框架供大家参考。
（5）确定编码规范
为了保证自动化测试脚本的质量，在编写脚本时需要遵循既定规范。尤其是多人配合、“团队作战”的时候，自动化测试脚本的规范是用例持续更新、脚本高效交付的关键因素，也只有规范的自动化测试脚本才能真正提质增效。
测试团队应该确定一些编码规范，以保证代码的通用性、可读性、可维护性，使代码易集成、少冗余、能高效对接，避免重复“造轮子”。以下是笔者所在测试团队制定的编码规范，供大家参考。
● 使用Python作为编码语言，文件、类、方法、函数、变量的定义应遵循以下规则。
❏ 测试文件名使用test_开头。
❏ 类名使用Test_开头。
❏ 方法或函数名使用test_开头。
❏ 变量使用有意义、易区分的字符命名。
● 元素定位方法的选择技巧如下（参考第7章）。
❏ Web端元素优先使用id定位；当无id时，再选用其他定位方法。
❏ Android端优先使用resource-id定位；当无resource-id或该值不唯一时，再选用其他定位方法。
● 配置项应该抽离为配置文件单独保存。
❏ IP地址、域名、端口等应该抽离为配置项保存。
❏ 公共文件的路径信息应该放到配置文件。
❏ 配置项保存格式为YAML。
❏ 配置项文件为测试根目录下的config/xxx.yml。
● 测试数据应该抽离为数据文件单独保存。
❏ 项目的账号、密码等数据信息应该抽离为数据文件保存。
❏ 测试用例参数化数据应保存到测试数据文件中。
❏ 测试数据文件格式为XLSX（也可以选择JSON、YAML、XML等格式）。
❏ 测试数据文件为测试根目录下的data/xxx.xlsx。
● 脚本中强制等待、显式等待、隐式等待的使用规则如下。
❏ 不可使用强制等待，如必须使用，需评审通过后方可提交代码。
❏ 一般情况下使用隐式等待即可。
❏ 在需要判断“×××不存在”时，则需要使用显式等待。
● 用例验证（脚本断言）应该明确、有效。
❏ 正向用例：查询类，验证期望查询结果数、重要字段值；写入类，验证写入目标位置的关键字段值；业务类，逻辑分支验证（原则上需要能够代替回归测试）。
❏ 异常用例：特殊字符验证，包含但不限于null字符、空字符、中英文特殊字符；必选参数、可选参数验证；参数类型验证；参数边界验证；异常逻辑分支验证。
● 确定单元测试框架。
❏ 使用Pytest框架。
❏ Pytest框架使用类结构。
● 定义测试用例类型。
测试用例类型分为3类：
❏ 冒烟测试用例，标识为“smoking”；
❏ 回归测试用例，标识为“regression”；
❏ 重点功能测试用例，标识为“function-×××”。
● 定义测试用例等级。
每条测试用例都必须标记明确的等级。
level-1，表示主业务流程正向用例；level-2，表示重点功能测试用例；level-3，表示其他用例。
一般来说，level-1用例占整体用例的5%，level-2用例占整体用例的30%，level-3用例占整体用例的65%。
● 测试用例执行前需要准备测试数据。
测试数据准备参照本书第16章内容。
❏ 事先创建：例如测试账号、人员信息等固定信息，适合提前创建。
❏ 实时创建：以unittest单元测试框架为例，针对删除类用例，在“setup”方法中创建数据，在测试用例中删除数据。
● 多界面跳转的实现选择如下。
❏ 若Web端涉及多界面跳转，直接通过get(‘目标url’)方法实现。
❏ 若Android端涉及多界面跳转，直接通过activity实现。
● 其他注意事项如下。
❏ 一般情况下，如果数据创建后无法删除，则不建议采用自动化的方式频繁创建数据。如果确实要验证，则需要同步考虑数据的清理动作，例如通过SQL连接数据库进行删除。
❏ 针对创建类操作，不仅要验证页面提示信息，还应该验证数据是否真正写入数据库。
（6）编码
编码，顾名思义，就是编写代码。在自动化测试用例脚本编写初期，相关人员应多开展代码评审，及时纠正错误，让每个人养成良好的编码习惯，待习惯养成后，则可降低评审频率。