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