详情
本书主要介绍Android自动化测试的相关内容：首先介绍自动化测试的市场情况和行业前景；接着介绍Android的相关知识，包括系统概览、环境搭建等，为读者学习后面的知识打下基础；最后介绍自动化测试的相关内容，包括元素识别与定位、等待机制、测试框架等，通过实战案例帮助读者快速掌握自动化测试技术。全书语言通俗易懂，讲解透彻，案例丰富。
本书适合计算机相关专业的学生和测试行业的从业人员阅读。
书名：Android自动化测试实战：Python+Appium+unittest
ISBN：978-7-115-62313-3
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 Storm 梁培峰
责任编辑 张天怡
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
本书主要介绍Android自动化测试的相关内容：首先介绍自动化测试的市场情况和行业前景；接着介绍Android的相关知识，包括系统概览、环境搭建等，为读者学习后面的知识打下基础；最后介绍自动化测试的相关内容，包括元素识别与定位、等待机制、测试框架等，通过实战案例帮助读者快速掌握自动化测试技术。全书语言通俗易懂，讲解透彻，案例丰富。
本书适合计算机相关专业的学生和测试行业的从业人员阅读。
在与李鲲程老师、边宇明老师一起完成的《Python实现Web UI自动化测试实战：Selenium 3/4+unittest/Pytest+GitLab+Jenkins》（以下简称《Python实现Web UI自动化测试实战》）一书出版后，不断有读者私信问我是否能编写一本关于移动端自动化测试的图书，在和张天怡老师进行初步沟通后，我通过简单调研了解到：目前为止，市面上移动端自动化测试实战类的图书很少，但移动端自动化测试在项目中的应用场景却是比较丰富的。基于以上情况，再加上每当我回顾上一本书时，对全书的编写思路和文字表达还是有些许遗憾，又由于外部条件成熟，内部自驱力足够，我和张天怡老师打算再次合作，编写并出版两本图书，分别是关于Android自动化测试实战和iOS自动化测试实战的，以实现Web、Android、iOS端到端的全覆盖。
在开始学习本书内容之前，建议读者掌握一些基本的Python知识。为了保证内容的紧凑性，本书不再包含该部分内容。读者可参考《Python实现Web UI自动化测试实战》一书，也可通过其他方式学习。
为了保证图书前后内容的逻辑性，本书会在前面的章节中讲解一些与Android系统相关的知识点，作为读者后续学习自动化测试的知识铺垫，如果读者对Android的知识体系有一定了解，则可跳过第2～4章的内容，直接学习后续章节内容。另外，请多动手，即便是非常简单的脚本，也建议读者亲自练习，因为看懂和会写真的是两回事儿。最后，请将学习到的知识应用到工作中，我始终认为“用学习支撑日常工作，用工作检验学习成果”是一种非常好的提升方式。
书中涉及的源码文件和学习资料会上传至QQ群：282939420。读者可以在QQ群中交流学习心得，我也会不定期在线答疑。
感谢人民邮电出版社，感谢张天怡老师，这是我们的第三次合作，每一次合作都很愉快；感谢领导李继军的大力支持；感谢我的家人，他们分担了家庭中所有的琐碎事务，让我有更多的时间编写本书；最后，感谢音乐，让我在深夜保持专注。
Storm（杜子龙）
2023年12月于北京
本书提供如下资源：
● 本书思维导图；
● 异步社区7天VIP会员。
要获得以上资源，您可以扫描下方二维码，根据指引领取。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区（https://www.epubit.com/），按书名搜索，进入本书页面，点击“发表勘误”，输入勘误信息，点击“提交勘误”按钮即可（见下图）。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们。
如果您所在的学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”(www.epubit.com)是由人民邮电出版社创办的IT专业图书社区，于2015年8月上线运营，致力于优质内容的出版和分享，为读者提供高品质的学习内容，为作译者提供专业的出版服务，实现作者与读者在线交流互动，以及传统出版与数字出版的融合发展。
“异步图书”是异步社区策划出版的精品IT图书的品牌，依托于人民邮电出版社在计算机图书领域30余年的发展与积淀。异步图书面向IT行业以及各行业使用IT技术的用户。
随着移动互联网的高速发展，智能移动终端得到快速普及，而作为终端智能化体现的移动应用（App）也快速地进入大众视野，而且已经渗透到我们生活的方方面面，比如出行方面的滴滴、饮食方面的饿了么、社交方面的微信等。
由于App同质化趋向明显，因此大众对App的质量和用户体验提出了更高的要求，促使App开发者想方设法提升移动端产品的质量和用户体验。另外，App产品讲究快速迭代、持续更新，无论是敏捷还是DevOps的实践，都对测试工作的覆盖率和时效性要求越来越高，这又导致测试人员的工作量越来越大。其中，每个迭代版本的回归验收测试都会消耗测试人员大量的工时。因此自动化测试迎来迅速发展的契机。通过自动化测试的工具或平台来辅助测试人员完成一些单一、重复、烦琐的测试任务，例如快速进行冒烟测试、重点功能验证测试、缺陷回归等，是自动化测试发展的意义。
图1-1 自动化测试相关招聘职位
智能移动终端对自动化测试的需求毋庸置疑，那当前各互联网公司对自动化测试人员的需求情况是怎样的呢？笔者通过某招聘网站，搜索“自动化测试”关键词，可以看到与自动化测试相关的职位情况，如图1-1所示。
通过查看招聘详情，笔者简单总结了从事自动化测试工作应掌握或具备的能力，具体如下：
● 熟悉Python、Java等至少一种编程语言；
● 配合团队利用自动化测试工具搭建测试框架和平台的建设工作；
● 参与自动化测试用例设计、构建测试环境、执行持续集成（Continuous Integration, CI）自动化完成测试任务。
在这里也提醒各位读者，通过查看“大厂职位”的招聘详情，可以了解当前行业的发展现状及对测试人员的要求，从而进行有针对性的学习。
本节我们先大致了解一下近几年在软件产品行业中出现的重要概念——DevOps、微服务架构和自动化测试。三者都是目前软件开发中的最佳实践方法论，旨在提升项目或产品的交付效率和交付质量，并最终提升产品竞争力。
（1）DevOps
DevOps（Development & Operations，开发和运营维护）是一套实践方法论，提倡打破原有组织和限制，目前职能团队已经开始接受DevOps所倡导的高度协同，研发、测试、运维及交付一体化的思维。随着DevOps和敏捷热度的不断提升，无论是互联网企业还是传统软件企业都开始拥抱敏捷，实践DevOps。持续集成、持续交付（Continuous Delivery，CD）作为DevOps的最佳实践，越来越受到重视。图1-2所示为DevOps的流程。
图1-2 DevOps的流程
（2）微服务架构
微服务架构（Microservice Architecture）起源于DevOps的意识形态和工程实践，采用的是软件架构风格。使用微服务架构有一系列好处，例如能够简化可部署性、提高可靠性和可用性等。虽然原则上可以使用任何架构来实践DevOps，但微服务架构正在成为构建持续部署（Continuous Deployment，CD）系统的标准架构风格。使用微服务架构的项目，会将需求拆分成微小的服务去逐一实现。由于每项服务的规模都很小，因此微服务架构允许通过连续重构来实现单个服务的功能模块，从而降低对大型项目前期设计的需求，实现尽早发布软件并且持续交付。微服务和DevOps是天然的共同体，两者共同推进软件开发行业的变革。
微服务架构在解决了应用大小、应用开发规模等方面存在的问题之后也带来了一些新的问题，比较突出的有微服务数量增多、服务间调用关系复杂等。复杂的关系导致即使是项目资深开发人员也很难全面梳理出所有服务之间的关系。
微服务和传统的单体应用相比，在测试策略上会有一些不太相同的地方。简单来说，在微服务架构中，测试的层次变得更多，需要测试的服务和应用也呈指数级增长。手动执行所有的测试是低效的，无法满足互联网快速迭代的要求。这时必须引入自动化测试来减轻测试团队的压力，提高测试效率和测试质量。
（3）自动化测试
随着敏捷和微服务架构的引入，持续集成和持续交付成为构建和部署的标准，即使在没有采用微服务架构的项目中也是如此。为了保证已定义的流程和事务按照预期进行，测试必不可少。而在应对现代软件产品频繁的更新和发布上，传统的手动测试方式在人员和效率上都存在严重不足，因此自动化测试已经成为现代软件研发过程中一个关键的组成部分。自动化测试是打通持续集成和持续交付的核心环节，没有有效的自动化测试作为保障，持续集成和持续交付就变成“没有灵魂的躯壳”。
测试按照不同的维度可以进行多种分类。例如按照测试手段分类，测试可划分为自动化测试和手动测试；按照测试目的分类，测试可划分为功能测试、性能测试、安全测试等。本节我们来看一看马丁·福勒（Martin Fowler）按照层级对测试进行的分类，也就是大家常见的金字塔模型，如图1-3所示。
图1-3 金字塔模型
金字塔模型将测试分为单元（Unit）、服务（Service）和用户界面（User Interface，UI）这3个层级。在测试发展的历程中，也出现了一些重新定义金字塔层级的测试模型，尽管对分层的具体描述各不相同（有人将这3个层级分别定义为单元、接口、集成测试，也有人将整个金字塔划分为4～5个层级），但金字塔自底向上的结构是大家公认和遵循的。
（1）单元测试
单元测试是针对代码单元（通常是类或方法）的测试，单元测试的价值在于能提供快速的反馈，在开发过程中就可以对逻辑单元进行验证。好的单元测试可以帮助改善既有设计，在团队掌握测试驱动开发（Test Driven Development，TDD）的前提下，单元测试能辅助重构，帮助提升代码整洁度。
（2）服务测试
这里所说的服务测试，是针对业务接口进行的测试，主要测试内部接口功能实现是否完整，比如内部逻辑是否正常、异常处理是否正确等。接口测试的主要价值在于接口定义相对稳定，不像界面或底层代码那样会经常发生变化，所以接口测试脚本的变动频率和维护成本较低，在接口层面开展测试的性价比相对较高。但接口测试的开展需要一份完整的、准确的、及时更新的接口测试文档作为前置条件，也就是说测试团队的工作进展情况需要依赖于外部团队的工作质量。如果在项目团队中，接口测试文档“可望而不可及”，那对测试人员来说，开展接口测试工作将事倍功半。
（3）UI测试
UI测试是从用户的角度验证产品功能的正确性，测试的是端到端的流程，并且加入用户场景和数据，验证整个过程是否正确、流畅。UI测试的业务价值高，但由于它验证的是完整的流程，因此在环境部署、用例准备及实施等方面成本较高，要完成高质量的UI测试其实并不容易。
基于金字塔模型，自动化测试领域也逐步细分，即分为单元自动化测试、接口自动化测试和UI自动化测试。本节我们来看看这3种自动化测试的概念。
（1）单元自动化测试
单元自动化测试指对软件中最小的可测试单元进行检查和验证，调用被测服务的类或方法，根据类或方法的参数，传入相应的数据，得到返回结果，最终断言返回的结果是否符合预期，如果符合则测试成功，如果不符合则测试失败。所以单元自动化测试关注的是代码的实现与逻辑。单元自动化测试是最基本的测试之一，也是测试中的最小单元，它的对象是函数，可以包含输入输出，针对的是函数功能或者函数内部的代码逻辑，并不包含业务逻辑。该类测试一般由研发人员完成，需要借助单元测试框架，如Java的JUnit、TestNG，Python的unittest、Pytest，等等。
（2）接口自动化测试
接口自动化测试主要验证模块间的调用返回，以及不同系统、服务间的数据交换。接口自动化测试一般在业务逻辑层进行。该测试根据接口文档是RESTful调用（一种基于REST架构风格的远程调用方式）还是远程过程调用（Remote Procedure Call，RPC）被测试的接口，构造相应的请求数据，得到返回值，从而判断测试成功还是失败。不管向接口输入的参数是怎样的，我们都将得到一个结果，最终断言返回的结果是否符合预期，如果符合则测试成功，如果不符合则测试失败。所以，接口测试关注的是数据。常见的接口测试工具有Postman、JMeter、LoadRunner等。
（3）UI自动化测试
UI层是用户使用产品的入口，产品的所有功能通过这一层提供给用户，目前测试工作大多集中在这一层，这种测试更贴近用户的行为，如模拟用户单击某个按钮或在文本框里输入某些字符等。比如用户在登录界面输入用户名和密码后单击确认按钮，有时可能用户看到登录成功了，但UI自动化测试脚本并不知道刚才的单击有没有生效。如果要找“证据”，登录成功后页面右上角显示的“欢迎，×××”，就是登录成功的有力“证据”。当UI自动化测试脚本测试到登录成功后，就会去获取测试数据进行断言，断言返回的结果是否符合预期，如果符合则测试成功，如果不符合则测试失败。所以，UI自动化测试的关注点是用户操作行为，以及UI上各种组件是否可用。常见的UI测试工具有UFT、Selenium、Appium等。
知识扩展：自动化测试分层占比。
每种自动化测试都有自己的侧重和优劣势，如果要在团队或项目中推进自动化测试工作，我们应该如何制定相对合理的自动化测试策略呢？让我们来看一看图1-4。
图1-4 自动化测试分层
图1-4透露了以下信息。
● 层级越往上，测试执行速度越慢（乌龟表示慢）；层级越往下，测试执行速度越快（兔子表示快）。
● 层级越往上，测试成本越高（需要更多的执行时间，且在用例执行失败时，获得的信息越模糊，越难跟踪）；层级越往下，测试成本越低。
● 层级越往上，越接近质量保证（Quality Assurance，QA）要求、产品人员、最终用户；层级越往下，越接近开发人员（Developer，DEV）。
● 层级越往上，业务属性越强；层级越往下，技术属性越强。
按照金字塔模型和投入产出比，我们得知层级越往下回报率越高，所以成熟的团队应该大量使用单元测试和接口测试来覆盖产品提供的基本逻辑和功能，使用少量的UI自动化测试来进行前端界面的功能验证。
都说业内最佳实践看Google，据了解，Google的自动化测试分层投入占比是单元测试占70%，接口测试占20%，UI自动化测试占10%。
虽然UI自动化测试不应该过多投入，但限于企业发展现状、项目类型、测试人员技能储备等各种因素，UI自动化测试是众多项目组最先开展，也是见效最快的一种选择。另外，UI自动化测试还具备单元和接口自动化测试所不具备的优势，比如单元测试验证代码处理的正确性，接口测试验证数据返回的正确性，但是前端（Web端或App端）结果展示是否正确，只能依靠UI自动化测试来验证。所以单元自动化测试、接口自动化测试和UI自动化测试不是“非此即彼”的关系，它们有各自擅长的领域，千万别被某些所谓的“大咖”忽悠，形成低层优于高层的错误观念。
关于自动化测试开展原则，笔者整理了“附录A”供大家参考。
在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）编码
编码，顾名思义，就是编写代码。在自动化测试用例脚本编写初期，相关人员应多开展代码评审，及时纠正错误，让每个人养成良好的编码习惯，待习惯养成后，则可降低评审频率。
一旦项目组确定要开展自动化测试，或者已经在开展自动化测试，我们就会遇到一个“灵魂拷问”，即自动化测试实施后，产品质量是否提升了？
在回答这个问题前，我们先来看几个概念。
（1）产品质量和测试质量
产品质量和测试质量是两个不同的概念，前者指的是产品本身的质量，后者指的是测试工作本身的质量。
产品质量的好坏取决于产品整个生命周期中各个环节的质量，遵循“木桶原理”（又称短板理论），即产品质量的好坏并不取决于做得最好的那个环节，而取决于做得最差的那个环节。因此，想通过提升测试这一个环节的质量来提升产品的质量是不科学的。
测试质量的好坏取决于测试工作的整个链条的完成度，例如需求理解是否完整、准确，用例设计是否科学，用例评审是否有效，测试执行是否准确，测试覆盖率是否达标，等等。可以看出测试质量是产品质量的子集。产品质量应通过多个环节和多种手段来保障，测试质量对产品质量的好坏起到了至关重要的作用。
（2）测试度量和自动化测试评估
测试工作的度量是一个难度非常高的课题，在实际工作中，管理者应注意：
● 不要使用单一的指标，比如测试用例对需求的覆盖率、用例执行通过率、代码覆盖率，去评估测试的质量；
● 在测试度量指标成熟前，不要轻易将其用于考核。
需要说明的是，测试工作如何度量不是本书重点介绍的内容。管理者可以从如下角度评估自动化测试开展前后的效果：
● 对比完成某项工作，采用人工测试所需的工时和采用自动化测试所需的工时；
● 自动化测试能够覆盖的测试范围，可以通过多层面反映出来，比如，自动化测试用例对需求的覆盖率、功能点覆盖率、代码覆盖率等。
提醒：测试人员在开展自动化测试的时候，应该注意统计（或提前埋点，方便后续统计）实施自动化测试带来的改进数据，以便支撑后续的总结和改进，为领导做出最终决策提供必要的数据支撑，而不是“感觉如何，应该怎样”。
基于以上内容，我们来回答本节开头的问题：“产品质量受限于整个产品生命周期的各个环节。测试质量的提升是产品质量提升的关键环节，产品质量有独立的评价体系。自动化测试的实施，在冒烟测试、回归测试、重点功能测试等环节提升了测试工作的覆盖率，降低了工时投入，提升了测试效率。”
（3）自动化测试面临的挑战
引入自动化测试可以为团队带来诸多好处，不过自动化测试也面临诸多挑战。其中，挑战之一是面临产品的变化，因为页面元素的改变或业务流程的调整可能会导致测试用例运行失败，这时候，测试人员就需要不断修改自动化测试脚本以匹配变化的产品页面或功能。降低脚本维护成本是对自动化测试工具和人员能力提出的巨大挑战。
值得注意的是，自动化测试不能完全代替人工测试，一定的人工测试是必不可少的。
