详情
本书主要介绍iOS自动化测试的相关内容。本书首先介绍iOS基础知识；接着介绍测试环境部署、Appium基本操作和Appium终端操作，为读者学习后面的知识打下基础；然后介绍Appium中的元素定位、元素操作、高级操作、等待机制；最后讲述Pytest测试框架、项目实战、项目代码优化、自动化测试框架开发等。
本书适合测试人员和开发人员阅读。
书名：iOS自动化测试实战：基于Appium、Python与Pytest
ISBN：978-7-115-64257-8
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
编 著 Storm 程立
责任编辑 谢晓芳
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
本书主要介绍iOS自动化测试的相关内容。本书首先介绍iOS基础知识；接着介绍测试环境部署、Appium基本操作和Appium终端操作，为读者学习后面的知识打下基础；然后介绍Appium中的元素定位、元素操作、高级操作、等待机制；最后讲述Pytest测试框架、项目实战、项目代码优化、自动化测试框架开发等。
本书适合测试人员和开发人员阅读。
当我翻开本书时，内心不禁涌起一股激动与自豪之情。本书不仅是我的学生杜子龙（笔名Storm）的测试经验结晶，还是他多年来在技术领域孜孜不倦探索的见证。回想起那个对技术充满热情的青年，看着他一步步成长为今天的行业佼佼者，我由衷地为他感到骄傲。
杜子龙在中南民族大学完成了信息管理与信息系统专业的本科学业，之后在北京科技大学获得了工商管理硕士（Master of Business Administration，MBA）学位。在本科期间，杜子龙展现了对技术的深刻洞察力和扎实的专业基础。他勤奋刻苦，思维敏捷，总能迅速掌握前沿知识，并将其灵活应用于实际操作中。在本书中，他凭借丰富的经验和独到的见解，详细剖析了iOS自动化测试的很多方面。从基础概念到高级技巧，从测试框架的构建到实际项目的应用，每一章都体现了他对技术的深刻理解和精湛掌握。
本书不仅是一本技术指南，还是一部融合了实践经验的著作。它涵盖了iOS自动化测试的相关知识，为读者提供了一条清晰而系统的学习路径。在软件开发领域，自动化测试的重要性日益凸显。随着软件功能的不断复杂化，如何确保软件质量和用户体验成为我们共同面临的挑战。而自动化测试正是解决这一难题的关键所在，它不仅能显著提升测试效率，还能在持续集成与交付过程中发挥至关重要的作用。
值得一提的是，本书还详细介绍了Pytest测试框架的应用，以及如何基于Appium和Pytest开发自定义测试框架。对于希望进一步提升自动化测试水平的读者来说，这无疑是一份宝贵的财富。结合真实案例，读者能够亲身感受iOS自动化测试的全过程。此外，本书还揭示了如何编写高质量、易于维护的自动化测试代码，这对测试工程师具有极高的实用价值。
本书的出版让我看到了青年一代技术人员的担当与追求，我为有这样优秀的学生而感到自豪。2023年，中南民族大学信息管理与信息系统专业获评国家级一流专业建设点，多年来所培养的毕业生的就业率和升学率在学校各专业中名列前茅。这一切成绩的背后都离不开众多像杜子龙一样优秀的学子的辛勤耕耘和开拓进取。
我相信本书将为那些渴望深入了解iOS自动化测试的读者提供参考。在这个信息繁杂的时代，能够找到一本真正有价值的技术图书实属不易，而本书正是这样一部作品。我衷心希望每一位读者都能从本书中汲取智慧、获得成长，并在自动化测试领域取得卓越的成就。
愿每一位热爱技术的人都能在本书中找到自己的定位和发展方向。
张劲松
中南民族大学教授、博士生导师
在完成《Python实现Web UI自动化测试实战：Selenium 3/4 + unittest/Pytest + GitLab + Jenkins》（下文简称《Python实现Web UI自动化测试实战》）一书后，不断有读者发私信问我是否能编写一本有关移动端自动化测试的图书。在和责任编辑进行初步沟通后，我做了简单的调研，得出以下结论。
第一，目前市面上有关移动端自动化测试实战的图书较少。
第二，移动端自动化测试在项目中的应用场景比较丰富。
基于以上情况，加上每当我回顾《Python实现Web UI自动化测试实战》一书时，对全书的编写思路和文字表达还有些许遗憾。外部条件成熟，内部自驱力足够，于是我决定编写本书，以讲述iOS测试的技术。
阅读本书要求读者具备一些基本的Python知识。为了保持本书内容的紧凑性，本书不包含该部分内容。读者可通过《Python实现Web UI自动化测试实战》一书中的相关内容进行学习，也可通过其他渠道学习。
为了保证前后内容的逻辑性，本书第2章会讲解一些与iOS系统相关的基础知识，作为后续介绍自动化测试知识的铺垫。读者如果对iOS知识体系有一定了解，则可跳过第2章，直接学习后续章节。在学习本书时，请多动手，即使是非常简单的自动化测试脚本，也要动手编写，因为看懂和会写真的是两回事。同时，请将学习到的知识应用到工作中，“用学习支撑日常工作，用工作检验学习成果”是一种非常好的自我提升方式。
为了便于读者理解本书内容，这里对书中经常出现的名词进行约定。
● 移动终端/移动设备：手机、iPad等智能移动设备。
● Terminal：macOS中的终端，类似于Windows操作系统的DOS命令行窗口。
● 模拟器：由Xcode运行的模拟器。
感谢人民邮电出版社的编辑在本书的写作和出版过程中提供的建议；感谢公司部门领导的大力支持；感谢我的家人分担了家庭中几乎所有的琐碎事务，让我有更多的时间编写本书。
Storm（杜子龙）
在当今的大环境下，作为人与移动终端之间的桥梁，App发挥着至关重要的作用。随着软件工程实践的发展，“质效合一”被奉为圭臬，人们总在追求用更少的人力、物力、财力，达到使工作质量更高的目的，于是提升工作效率变得至关重要。在软件开发生命周期中，不同角色承担不同任务，但只有使它们实现极致的融合，方能突破局限，不断提升工作效率。在软件开发过程中，测试人员需要承担越来越繁重的工作，扮演越来越重要的角色。
身处软件开发行业的人们或多或少都听说过DevOps、微服务架构和自动化测试。这三者旨在提升项目或产品的交付效率，最终提升产品的竞争力。
DevOps是一套实践方法论，它提倡打破原有组织和限制，让职能团队拥抱和接受DevOps所倡导的高度协同，以及开发、测试、运维与交付一体化的思维。随着DevOps和敏捷的热度不断提升，无论是互联网企业还是传统企业都开始拥抱敏捷，实践DevOps。作为DevOps的最佳实践，持续集成（Continuous Integration，CI）、持续交付（Continuous Delivery，CD）越来越受到重视。图1-1所示为DevOps的流程。
图1-1 DevOps的流程
微服务架构（microservice architecture）起源于DevOps意识形态和工程实践。微服务架构带来了一系列好处，例如可部署性的简化、可靠性和可用性的提升等。虽然原则上可以使用任何架构来实践DevOps，但是微服务架构正在成为构建持续部署系统的标准软件架构。由于每项服务的规模都很小，因此微服务架构不仅允许通过连续重构来形成单个服务的体系结构，从而降低对大型项目前期设计的要求，还允许尽早发布软件并且实现持续交付。微服务架构和DevOps是天然的共同体，两者共同推进了软件开发行业的变革。
微服务架构在解决软件大小、软件开发规模等问题的同时也带来了一些新的问题，如微服务数量增多、服务间调用关系复杂等。复杂的依赖导致即使是项目资深开发人员也很难全面梳理出所有服务之间的关系。微服务和传统的单体应用在测试策略上有一些不太相同的地方。简单来说，在微服务架构中，测试的层次变得更多，需要测试的服务和应用的数量也会呈指数级增长。手动执行所有的测试是低效的，无法满足互联网快速迭代的要求。这时就需要引入自动化测试来减轻测试团队的压力，提高测试效率和测试质量。
随着敏捷和微服务架构的引入，持续集成和持续交付成为构建和部署项目的标准，即使在没有采用微服务架构的项目中也是如此。为了保证已定义的流程和事务按照预期运行，测试必不可少。而在应对现代软件产品频繁的变化和发布时，传统的手动测试方式在人力和效率上都存在严重不足，因此自动化测试就成为现代软件开发过程中的一个关键环节。自动化测试是打通持续集成和持续交付的核心环节，没有有效的自动化测试作为保障，持续集成和持续交付就变成了空壳。
自动化测试是用程序代替人的手动操作，完成一系列测试的过程。使用自动化测试工具能自动打开目标程序，自动执行测试用例，自动比较实际结果与预期结果是否一致。
在手动测试有一定实用性的情况下，为何要开展自动化测试呢？客观来讲，原因在于以下两点。
● 懒，不想重复做。
● 难，手动做不了。
而映射到实际的测试工作中，具体表现如下。
● 手动测试工作量巨大。
● 手动测试包含大量重复的操作。
● 手动测试的某些环节包含一些不具有智力创造性的活动。
● 手动测试无法确保多次执行的一致性。
● 人需要休息，而理论上，机器可不停运作。
自动化测试的优点大致可以总结为以下几点。
● 自动化测试能执行更多、更频繁的测试。
● 自动化测试能执行一些手动测试难以完成的测试。
● 自动化测试能更好地利用资源，例如，在晚上或周末利用空闲的设备执行自动化测试。
● 自动化测试让测试人员在测试用例设计上投入更多的精力，从而提高测试的准确性。
● 自动化测试具有一致性的特点，能够保证测试更客观，从而提高软件的信任度。
测试按照不同的维度可以进行多种分类，例如，按测试是否采用手动方式执行，可划分为手动测试和自动化测试；按照质量特性，可划分为功能测试、性能测试、安全测试等。这里展示了马丁·福勒（Martin Fowler）按照层级方式对测试进行的分类，即常见的测试金字塔模型，如图1-2所示。
图1-2 马丁·福勒的测试
金字塔模型
马丁·福勒的测试金字塔模型将测试分为单元测试、服务测试和UI（User Interface，用户界面）测试3个层级。在测试行业的发展历程中，也出现了一些重新定义金字塔分层的测试模型，尽管大家对此的具体描述不尽相同（有人将3个层级分别定义为单元测试、接口测试、集成测试，也有人将整个金字塔划分为4或5个层级），但金字塔自下向上的结构是大家公认的。
这里简单介绍3个层级测试的概念。
单元测试指对软件中最小的可测试单元进行检查和验证，调用被测服务的类或方法，根据类或方法的参数，传入相应的数据，返回一个结果，最终断言返回的结果是否符合预期：如果符合预期，则测试通过；如果不符合预期，则测试失败。所以，单元测试关注的是代码的实现与逻辑。单元测试是最基本的测试，也是测试中的最小单元；它的对象是函数，它可以包含输入/输出，针对的是函数的功能或者函数内部的代码逻辑，并不包含业务逻辑。该类测试一般由开发人员完成，需要借助单元测试框架，如Java的JUnit、TestNG，Python的unittest、Pytest等。
接口测试主要用于验证模块间的调用和返回，以及不同系统、服务间的数据交换。接口测试一般在业务逻辑层进行。它根据接口文档是REST（Representational State Transfer，描述性状态迁移）风格还是RPC（Remote Procedure Call，远程过程调用）风格来选择调用被测试的接口，构造相应的请求数据，发送请求，得到返回结果，判断测试是否通过。不管输入的参数是怎样的，我们都将得到一个结果，最终断言返回的结果是否等于预期结果：如果等于预期结果，则测试通过；如果不等于预期结果，则测试失败。所以，接口测试关注的是数据。只要数据正确了，接口的功能就实现了一大半，剩下的就是如何把这些数据展示在页面上。常见的接口测试工具有Postman、JMeter、Python Requests等。
UI层是用户使用产品的入口，所有功能都通过这一层提供给用户，目前测试工作大多集中在这一层。UI测试更贴近用户的行为。测试人员通过模拟用户单击某个按钮或在文本框里输入某些字符来验证功能实现的完整性、正确性。
基于测试金字塔模型，自动化测试逐步细分为单元自动化测试、接口自动化测试和UI自动化测试。既然自动化测试可以在不同层级开展，那么应该选择使用哪种自动化测试呢？
每种自动化测试都有自己的侧重和优劣势，很难说哪种自动化测试具有绝对的优势，各种自动化测试的占比也很难一概而论。如果要在团队或项目中推进自动化测试工作，我们应该如何制定相对合理的自动化测试策略呢？让我们看一看图1-3。
图1-3 自动化测试分层
图1-3透露了以下信息。
● 越往上（UI自动化测试），测试执行速度越慢；越往下（单元自动化测试），测试执行速度越快。
● 越往上，测试成本越高（需要更多的执行时间，且在测试用例执行失败时，获得的信息越模糊，越难跟踪）；越往下，测试成本越低。
● 越往上，越接近质量保证人员、产品人员、最终用户；越往下，越接近开发人员。
● 越往上，业务属性越强；越往下，技术属性越强。
由测试金字塔模型和投资收益率（Return on Investment，ROI）我们得知，层级越靠下，投资收益率越高。所以，一个成熟的团队应该大量使用单元自动化测试和接口自动化测试来覆盖产品提供的基本逻辑和功能的验证，使用少量的UI自动化测试来进行前端界面的功能验证。
虽然在UI自动化测试上不应该过多投入，但是限于企业发展现状、项目类型、测试人员技能储备等因素，UI自动化测试是众多项目团队最先开展且见效最快的一种测试。另外，UI自动化测试还具备单元自动化测试和接口自动化测试不具备的优势。例如，单元自动化测试能验证代码处理的正确性，接口自动化测试能验证数据返回的正确性，但是前端（Web端或App端）结果展示是否正确只能依靠UI自动化测试来验证。所以，单元自动化测试、接口自动化测试和UI自动化测试不是非此即彼的关系，它们有各自擅长的领域，切勿形成下层优于上层的错误观念。
在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，结构查询语言）进行删除。
❏ 针对创建类的操作，不仅要验证页面提示信息，还应该验证数据是否真正写入数据库。
编码，顾名思义，就是编写代码。建议相关人员在自动化测试用例编码初期，多开展代码评审，及时纠正偏差，让团队中的每个人养成良好的编码习惯。
一旦项目团队确定要开展自动化测试，或者正在开展自动化测试，就要深入思考自动化测试实施后，产品质量是否提升了。
在回答这个问题前，我们先看两个概念。
产品质量和测试质量是两个不同的概念，前者指的是产品本身的质量，后者指的是测试工作本身的质量。
产品质量的好坏取决于产品的整个生命周期中各个环节质量的好坏，遵循“木桶原理”，即产品质量的好坏并不取决于做得最好的那个环节，而取决于做得最差的那个环节。因此，想通过提升测试某一个环节的质量来提升产品质量是不科学的。
测试质量的好坏取决于测试工作整个链条的完成度的高低。例如，需求理解是否准确，测试用例设计是否科学，测试用例评审是否有效，测试覆盖率是否达标，等等。可以看出，测试质量是产品质量的一个子集。产品质量应通过多个环节和采取多种手段来保障，测试质量的好坏对产品质量的度量起到了至关重要的作用。
测试工作的度量是一个难度非常高的课题，在实际工作中，管理者应注意以下几点。
● 不要使用单一的指标（如测试用例对需求的覆盖率、测试用例执行通过率、代码覆盖率等）去评估测试的质量。
● 在度量指标成熟前，不要轻易将它用于考核。
测试工作如何度量不是本书重点介绍的内容。下面我们看看自动化测试如何度量。
管理者可以从如下角度了解自动化测试开展前后的效果。
● 通过对比完成某项工作所需的手动测试工时与自动化测试工时，评估自动化测试的投入产出比。
● 自动化测试能够覆盖的范围可以通过多个层面（例如需求覆盖率、功能点覆盖率、测试用例覆盖率、代码覆盖率等）反映。
测试人员在开展自动化测试的时候，应该统计实施自动化测试带来的改进数据，以便支撑后续的总结和改进，为最终决策提供必要的数据支撑，而不是“感觉如何，应该怎样”。
在冒烟测试、重点功能验证、缺陷回归测试等环节，自动化测试的实施提升了测试工作的覆盖率，减少了工时投入，提升了测试效率，可以说自动化测试是提升测试质量的有效手段。但产品质量受限于产品的整个生命周期中的各个环节，需要上下游通力配合，共同提升。
引入自动化测试可以给团队带来诸多好处，不过自动化测试也面临诸多挑战。其中一大挑战就是面对产品的变化，页面元素的改变或业务流程的调整可能导致测试用例执行失败。这时，测试人员就需要不断修改测试脚本以匹配变化的产品页面或功能。此外，要降低测试脚本的维护成本，对自动化测试工具和测试人员有更高的要求。值得注意的是，自动化测试不能完全代替手动测试，一定的手动探索与测试是必不可少的。
