随着VUCA（易变性、不确定性、复杂性、模糊性）时代的到来与互联网的高速发展，质量保障人员面临着前所未有的挑战。

测试岗位的职责越来越细化，测试人员的工作边界也越来越模糊，研发、测试和运维角色都在推动 DevOps 和 TestOps 的发展。

在和测试同行交流的过程中 , 我们发现很多人非常焦虑，找不清发展的方向，尤其是工作四五年之后一直还在做系统测试的人，就更为焦虑。

2017 年年末，作者所在的京东质量团队在进行年终总结时欣喜地发现，自团队从测试到测试开发转型这一年来，整体测试水平得到了大幅度提升 , 测试人员在研发团队中的影响力也进一步扩大。

从系统测试工程师逐渐转型升级为测试开发工程师，转型过程中的艰辛不言而喻，在转型中除了技能的提高之外，更多的是获得了一种自信。

本书不仅展示京东质量团队从测试到测试开发的心路历程，更是整个过程中从思想准备到实践努力再到成功推进的思考和总结。

本书适合有一定工作经验的测试人员阅读，对从测试转型测试开发的人员具有指导意义。本书同样适合测试经理、测试总监和测试架构师阅读。书中的例子和故事均为团队转型中遇到的真实案例。我们历经各种辛酸才能走出一条路，希望本书能给读者一些启发和帮助。

软件测试

首先要明确一个概念，“质量”是整个团队的责任而不是仅仅靠团队测试人员就能够明显改善的。测试的目的是什么？测试不是要证明系统或者软件没有问题，恰恰相反，而是要证明其存在问题。

通过测试可以发现缺陷，但不能保证软件或者系统的缺陷全部被找到。在有限的时间和资源条件下，想要进行完全的测试，找出软件或者系统所有的缺陷，使之达到完美，是不可能的。

此外，测试也是有成本的，越到测试后期，，为发现缺陷所付出的代价就会越大，因此要根据测试错误的概率及软件的可靠性要求， 确定停止测试的最佳时间，不能无限地测试下去。除此之外，所有的测试都应追溯到用户需求，这是因为软件或者系统的最终目的是满足用户需求。

1.1.1 什么是软件测试

1983 年，Bill Hetzel 在《软件测试完全指南》一书中指出：“测试是以评价一个程序或者系统属性为目标的任何一种活动， 测试是对软件质量的度量。”Bill Hetzel 的定义至今仍被引用。

1991 年，软件产品质量评价国际标准 ISO 9126 定义的“软件质量”是：软件满足规定或潜在用户需求特性的总和。

1999 年，软件产品评价国际标准ISO 14598 对“软件质量”的定义是： 软件特性的总和，软件满足规定或潜在用户需求的能力。

2001 年，软件产品质量国际标准ISO 9126 定义的“软件质量”包括内部质量、外部质量和使用质量 3 个部分， 也就是说，“软件满足规定或潜在用户需求的能力”要根据软件在内部、外部和使用中的表现来衡量。

《软件评测师教程》（柳纯录主编，清华大学出版社）这本软件评测师考试辅导书对软件测试和质量保证做了详细的区分和描述：测试工程师的一项重要任务是提高软件质量，但不等于说测试工程师就是软件质量保证人员，因为测试只是质量保证工作中的一个环节。

测试工程师并不生产质量，质量的生产者还是开发工程师。质量保证和软件测试是软件质量工程中两个不同层面的工作。

质量保证：质量保证的主要工作是通过预防、检查与改进来保证软件质量。

QA 基于“全面质量管理”和“过程改进”原理开展质量保证工作。虽然在 QA 的活动中也有一些测试活动，但其所关注的是软件质量的检查与测量。QA 的工作是对软件生命周期的管理，以及验证软件是否满足规定质量和用户需求的过程，因此主要着眼于软件开发活动中的过程、步骤和产物，而不是对软件进行剖析以找出问题或评估。

虽然测试与开发过程紧密相关，但软件测试关心的不是过程的活动，重点要对过程的产物及开发出的软件进行剖析。测试人员要“执行”软件，对过程的产物— 开发文档和源代码进行走查，运行软件，以找出问题，提升质量。

测试人员必须假设软件存在潜在的问题，测试中所进行的操作是为了找出更多的问题，而不仅仅是为了验证每一件事是正确的。对测试中发现的问题进行分析、追踪与回归测试也是软件测试的重要工作，因此软件测试是保证软件质量的一个重要环节。

在 20 世纪 90 年代，随着测试工具的盛行，测试工程师逐渐意识到通过强化工具来解决问题的重要性，工具思维在测试工程师的心里已经变成了思考问题的重要方式，但是这里的工具思维是指使用工具的思维，还没有出现创造工具的思维。

软件测试是一项旨在保障软件质量的服务，软件测试只能证明一个软件存在缺陷，却不能证明一个软件没有缺陷。

随着生命周期成熟度的提升，以及持续集成乃至开发运维的变迁，软件测试不仅旨在保证软件的质量，保证软件质量、提高交付频率变成了相辅相成的目标。保证软件的质量是基础目的，提高交付频率是根本目的。

软件测试是为了寻找软件的缺陷和错误，提高软件的质量和交付频率，因此所有软件测试都应该可以溯源到用户需求，无论是用户明确的显性需求，还是一些系统安全、系统兼容、性能等的隐性需求。

1.1.2 业务测试

如今，人们通过网络可以方便地购买各种各样的物品，除了实物之外，还有各种虚拟物品，如飞机票、火车票和电影票等。与此同时，人们还可以很方便通过网络缴纳生活中所需要的各种费用，如手机充值，缴纳电费和水费等。

从物品的查找，到用户支付成功，最后到用户收到物品（或者充值面值的筛选， 充值成功），这一系列流程都属于电子商务的一个具体业务，那么如何进行业务测试呢？笔者所在团队主要从事电商网站的虚拟业务的功能测试，下面就笔者所在团队的工作内容展开详细介绍。

业务测试的侧重点在业务流程上，在基本功能点都已合格的基础上，准备并组合多种测试数据，驱动或辅助在各种约束条件下的业务流程测试，确定最终输出的结果是否符合预期。

业务测试多数要结合实际业务逻辑，黑盒、白盒、灰盒这些测试方法都可以用来辅助测试。业务测试并不能单单满足于功能实现，更要站在真实用户使用的角度提出问题、给出建议，从而优化程序。

如何开展业务测试呢？测试前置在行业内越来越多地被提及，在功能测试中， 测试也应做到前置，不能等到系统全部提测了再介入测试。

1．需求测试

越早发现缺陷，修复缺陷的成本就越低，那么缺陷最早能在什么时候被发现呢？ 毫无疑问，在需求最早提出的时候。当一个需求被提出时，测试人员不能认为提出的需求是完全正确、没有问题的，需要对需求设计的正确性、合理性及实施性进行测试，尽早发现需求中的问题并跟进解决。

在需求阶段发现问题的修复成本很低，也是在源头保证质量的有效手段。需求测试如图 1-1 所示。

图 1-1需求测试图

2．设计测试

需求测试结束，问题得到解决，需求被确定下来后，就进入了设计阶段。此阶段分成两部分：一是开发人员进入设计阶段，二是测试人员进入设计阶段。

开发人员的设计阶段不在此处讨论。除包含常规的测试计划、测试用例和测试准备等工作外，测试人员的设计应同时包含对系统的设计。

介绍到这里，肯定有读者会有疑问：开发人员已经在进行系统设计，测试人员再进行系统设计是不是多此一举？测试人员的设计会不会得到认同？

其实， 测试人员的设计要求不同于开发人员的设计要求，不对具体形式做要求，此处测试人员进行系统设计的意义在于让测试人员对即将被测的系统有一个自己独立的思考过程，只有测试人员自己也对需求进行相应的独立的系统设计，才能找到开发人员设计的问题，将测试工作前置，降低缺陷修复的成本。

设计测试应注重检查系统设计的 3 个特性，如图 1-2 所示。

必要性：每处设计要有目的，要为满足需求而设计，不能存在无谓的设计。

正确性：检查每处设计是否正确、合理，是否能够实现想要实现的功能。

最优性：检查每处设计是否为相对简单、高效的设计。

图 1-2 设计测试图

3．过程测试

过程测试是功能测试的重点，也是集中发现缺陷的阶段。在系统测试开始之前， 测试人员需要完成测试数据的准备，以及测试计划、测试用例的设计，并经过项目组成员评审通过。评审过程有两个目的：一是弥补测试设计中遗漏的地方，二是项目组成员达成共识，认可测试设计以避免后期不必要的麻烦。

在过程测试的实施过程中，笔者所在团队采用了分层测试、外部解耦、流程仿真等手段保证系统质量，如图 1-3 所示。

图 1-3 过程测试图

（1）分层测试

分层测试强调测试的层次感。读者可能有过这种感觉，有层次感的面包比一般的面包口感更好。笔者所在部门基于分层测试的思想将整个被测系统按照数据层、API 层、UI 层进行分割，这样做的优势是什么呢？

测试提前介入是所有项目都提倡的，目的是把问题拦截在前期，降低问题修复成本。

分层测试不依赖于完整系统，可以通过直接调用底层接口进行测试，这样就不需要等到整个系统开发完成才能测试。

其实，分层测试的思想和自底向上的系统开发模式是不谋而合的。

分层测试同时能够体现出精准性：我们都知道，离问题产生的地方越近，就越容易触发问题。

分层测试的切入点就是层与层之间的接口，从机制上更接近出问题的地方， 因此更容易命中目标，也能直接或间接地降低修复成本。

分层测试如图 1-4 所示。

图 1-4分层测试

数据层测试：数据层测试首先对数据库中的原始数据及聚合数据的准确性进行验证，如精度、数量、存储有无丢失等，在保证这一层质量后进入下一层测试。

API 层测试：首先需要强调，API 层测试也是功能测试的一部分。通过接口调用验证服务器返回的数据是否准确，服务器端可能会将数据进行运算并返回。通过 API 层验证保证数据传输的准确性，保证接口层通过测试后进入下一层测试。

UI 层测试：通过覆盖系统所有逻辑路径保证数据展示层的正确。

（2）外部解耦

外部依赖有时是阻碍测试进度的一个主要原因，但是一个系统的运行往往离不开外部系统的依赖，如网络环境、消息依赖和数据依赖等。

测试过程中如何降低系统间的耦合度是高效进行测试的关键。

作者所在部门通过 MQ（消息队列）消息自动发送组件模拟外部依赖消息，可以解决消息依赖问题，降低耦合度。

该工具适用于笔者所在部门的整个业务，如利用该工具模拟机票业务出退票消息， 成功摆脱消息依赖，使测试效率及准确性大大提升。

（3）流程仿真

在系统测试过程中，往往有些极端情景或流程很难模拟，或者由于测试环境、数据量不足等原因导致无法进行模拟的情况。然而，这些情景或流程有时又非常重要， 这就造成测试覆盖不全的情况发生。

笔者所在部门从穿线测试理论得到灵感，对流程主信息进行标记追踪，根据不同情况将流程引导至设定的极端情况中，覆盖极端情况，验证系统处理能力，很好地解决了这一难题。

4．用户体验

在保证系统逻辑功能正确的基础上，还要对用户体验进行测试。由于电商网站的特点，用户体验非常重要，因此笔者所在公司对用户体验非常重视。

好的使用体验不仅可以留住用户，而且能够提升购物转换率，为公司带来实际的效益。在实际项目中，用户体验可以从以下几方面考虑。

（1）应用性

应用性要考虑是否符合用户的实际应用场景，这就要求针对受众用户群体，考虑他们的年龄、学历、技能和职业等因素，要具备通用性。

（2）易用性

易用性要检查是否容易理解、是否容易学习、是否容易操作。例如，用词一定要简单和易理解，不能专业性太强，降低用户的理解难度；操作要简洁，不要过于烦琐， 减少用户的抵触情绪，最好做到不需要用户过多思考就可以直接操作。

（3）少选择

给用户的选择要尽量少，即界面的菜单、按钮、选择项越少越好，减少用户的困惑。除此之外，还要在流程、规范上保证系统质量。

例如，测试固有流程规范保证每个环节结果真实，有据可依；异常流程紧急处理规范使工作高效进行；自动化代码编写、执行规范使代码自动化、易维护、易运行；功能测试执行规范且严格执行， 做到对线上环境零影响，使项目合规率达到 100%。

5．界面测试

界面是电商网站与用户交互最直接的层面。

界面的好坏决定了用户对网站的第一印象。设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。界面如同人的面孔，具有吸引用户的直接优势。

设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉。

相反，设计失败的界面让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中“付诸东流”。

既然界面的好坏如此重要，那么在测试过程中界面测试就变得不可或缺。在具体的工作中，界面测试应该关注哪些点呢？

界面测试如图 1-5 所示。

图 1-5界面测试图

（1）导航测试

导航一般位于页面顶部或侧边区域。导航的作用是链接站点内的各个页面。导航测试可以从以下 4 个方面进行。

① 导航是否直观？是否易于导航？

② 导航、链接、页面的结构和风格是否一致？

③ 导航文字是否用词准确？意义表达是否简单和准确？

④ 链接的页面是否准确？

（2）图片测试

图片测试包含图片、动画、边框、颜色、字体、背景和按钮等。图片的测试可以从以下 3 个方面进行。

① 需要保证图片有明确的用途，如广告宣传作用，不能存在没有意义的图片。

② 所有页面中的字体和颜色及页面的设计格式要保持一致。

③ 图片的质量与大小也是需要关注的方面。

（3）内容测试

内容测试用于检验页面信息的准确性、正确性与相关性。内容测试可以从以下两个方面进行。

① 验证传输的信息是可靠的。

② 验证传输的信息的语法和拼写是否正确。

（4）展示测试

展示测试用于检验页面展示的所有内容是否正确，大小是否合适，是否符合普适性行为习惯。展示测试可以从以下 4 个方面进行。

① 验证提示语是否合理、正确。

② 验证窗口调整大小后展示的内容是否正确。

③ 验证本地化是否正确。

④ 验证标题及检查错别字。

（5）合理性测试

合理性测试可以从以下 3 个方面进行。

① 验证页面布局是否合理。

② 验证各控件是否合理、是否可编辑。

③ 验证提示页面是否合理。

6．浏览器兼容性测试

浏览器兼容性是衡量一个系统是否成熟稳定的重要指标。某个功能在某一浏览器上的显示和操作均正常，但是在另一个浏览器上的显示就乱糟糟的，严重的可能导致功能异常。

作者所在团队的业务面向的几乎都是大众用户群体。同时，用户使用的浏览器多种多样，如果出现兼容性问题，那么用户对业务的好感度就会降低， 这样会造成用户流失，进而损失公司的利益，因此，浏览器兼容性测试是需要我们加大力度关注的，那么如何才能充分测试浏览器兼容性呢？

首先，要了解什么是兼容性问题。浏览器兼容性问题又称为网页兼容性问题或网站兼容性问题，是指网页在各种浏览器上的显示效果可能不一致而产生浏览器和网页间的兼容问题。

那么为什么会出现浏览器兼容性问题？

因为不同浏览器使用的内核及所支持的 HTML（标准通用标记语言下的一个应用）等网页语言标准不同， 并且用户客户端的环境不同（如分辨率不同），因而显示效果不理想。

其次，要了解当前哪些浏览器是主流的，要覆盖主要的浏览器内核。作者所在团队对目前主流的 14 款浏览器进行了兼容性测试，并对浏览器的不同版本进行了测试。

在测试过程中，需要对以下界面功能进行兼容性测试。

1）业务与功能结合的异步交互。

2）功能按钮（增加、删除、修改、查询、导入、导出、超链接和清空）等。

3）日期和时间控件、搜索控件。

4）有特殊功能的图标。

1.1.3 自动化测试和测试开发

随着被测系统越来越复杂，规模越来越庞大，测试的工作量也越来越大，这必然会暴露出人和测试生命周期的冲突。为了更加快速、有效、可靠地对软件进行测试， 提高被测系统的质量，测试工具和工具思维就必然会被引入测试工作中，自动化测试也自然而然地被提上日程。

随着IT 从业领域的不断深入和复杂化， 职位细分也越来越复杂，一开始集开发、测试、运维、DBA 等一系列工作于一身的软件“英雄”，现在已经细分到开发工程师、测试工程师、运维工程师、测试开发工程师、开发运维工程师和测试运维工程师等职位， 如图 1-6 所示。

图 1-6职位细分趋势

软件工程师是从事软件开发相关工作人员的统称。它是一个广义的概念，包括软件设计人员、软件架构人员、软件工程管理人员、程序员等一系列岗位，工作内容都与软件开发生产相关。软件工程师的技术要求是比较全面的，除了基础的编程语言、数据库技术等，还有诸如 JavaScript、AJAX、Hibernate、Spring 等前沿技术。

运维工程师负责维护并确保整个服务的高可用性，同时通过不断优化系统架构、提升部署效率、优化资源利用率、提高整体的 ROI（Return On Investment）。运维工程师面对的最大挑战之一是大规模集群的管理问题，既要管理好几十万台服务器上的服务，又要保证服务的高可用性。

质量保障（QA）工程师不仅要理解产品的功能要求，还负责对其进行测试，检 查软件有没有缺陷，测试软件是否满足稳定性、安全性和易操作性要求，以及写出相应的测试规范和测试用例。

简而言之，质量保障工程师在一家软件企业中担当的是“质量管理”角色，他负责及时发现软件问题并及时督促更正，确保产品的正常运作。

随着细分领域的不断发展，出现了同时承担开发和测试工作的角色—测试开发工程师，同时承担开发和运维交叉工作的角色—开发运维工程师，同时承担测试和运维工作的角色—测试运维工程师。由于 3 个角色交叉的工作在现在的大型项目中不太容易出现，因此，如果有这部分工作，那么只需要一个“超人”一样的角色来完成。

分层自动化测试这个概念最近曝光度比较高。传统的自动化测试更关注产品 UI 层的自动化测试，而分层自动化测试倡导产品的不同层次（阶段）都需要自动化测试， 如图 1-7 所示。​

​图 1-7分层自动化测试的示意图

相信测试人员对图1-7 所示的“金字塔”结构并不陌生，这也是产品开发不同层次所对应的测试。我们需要规范地进行单元测试，同样需要相应的单元测试框架，如Java 的 JUnit、TestNG，C# 的 NUnit，Python 的 unittest、pytest 等，绝大多数主流语言都有其对应的单元测试框架。

接口测试对于测试新手来说不太容易理解。单元测试关注代码的实现逻辑，如一个if 分支或一个for 循环的实现，而集成、接口测试关注的是一个函数、类（方法） 所提供的接口是否可靠。

例如，如果要定义一个 add() 函数，用于计算两个参数的和并返回结果，那么需要调用 add() 方法并传参，而后比较返回值是否为两个参数相加之和。当然，接口测试也可以以 URL 的形式进行传递。

例如，通过 get 方式向服务器发送请求，那么发送的内容作为 URL 的一部分传递到服务器端。但是，如果 WebService 技术对外提供一个公共接口，那么需要通过 SoapUI 等工具对其进行测试。关于 UI 层的自动化测试，有些读者可能非常熟悉，因为测试人员的大部分工作都是对 UI 层的功能进行测试。

例如，如果需要不断重复对表单提交、结果查询等功能进行测试，那么可以通过相应的自动化测试工具来模拟这些操作，从而避免重复的操作。UI 层的自动化测试工具非常多，目前比较主流的是 QTP、Watir 和Selenium 等。

为什么要设计成一个金字塔结构，而不是长方形或倒三角形结构呢？

这是为了表示不同阶段所投入自动化测试的比例。如果一个产品从来没有进行单元测试与接口测试，只进行了 UI 层的自动化测试，那么这是不科学的，很难从本质上保证产品的质量。

如果用户企图实现全面的 UI 层的自动化测试，那么不但浪费了大量的人力和物力，而且最终获得的收益可能会远远低于所支付的成本。因为越往上层，其维护成本越高，尤其是 UI 层的元素会时常发生改变。

所以，应该把更多的自动化测试放在单元测试与接口测试阶段进行。

既然 UI 层的自动化测试这样“劳民伤财”，那么是否可以只进行单元测试与接口测试？

不可以。因为无论什么样的产品，最终呈现给用户的是 UI 层，所以测试人员应该将更多的精力放在 UI 层上。

也正是因为测试人员需要在 UI 层投入大量的精力，所以才有必要通过自动化的方式帮助测试人员“部分解放”重复的劳动。

在自动化测试中，测试人员最怕的是变化，因为变化的直接结果是测试用例的运行失败，这时就需要对自动化脚本进行维护。减少失败次数，以及降低维护成本， 对自动化测试的成败至关重要。换个角度讲，一个永远都成功运行的自动化测试用例是没有价值的。

到了这里，读者对自动化测试应该有了一定的了解。但是，可能有些读者依然不知道如何下手和提高技术能力。

因此，现在开始介绍如何提高技术能力。从软件测试入门，学习各种技术，然后晋升到一个比较好的职位，功能测试是这样一个过程， 自动化测试同样也是这样的。

图 1-8 给出了一个学习成长路线，也许不完全适合你， 但是希望对你有所帮助。​

​图 1-8成长路线

测试开发的主要工作内容是完成和维护自动化测试相关的工作。自动化测试就是通过使用或者开发测试工具、测试框架、测试系统和测试平台，按照测试工程业务测试的流程、计划及预期对被测系统进行测试的过程。

自动化测试是软件测试的一个重要组成部分，自动化测试和业务测试既不能相互完全替代，也不能完全相互分离。正确、合理地利用自动化测试手段，结合业务测试流程和执行，能够提高测试效率和测试覆盖率，从而保证软件的质量，缩短开发周期，提高交付频率，节省工期和人力成本。

自动化测试涉及测试流程、测试体系、测试规范、测试方案、自动化的执行测试、自动化的测试环境治理等方面，既有技术的问题，又不仅仅有技术问题。自动化测试需要长期投入，涉及专门团队建立、维护，以及发展自动化的流程、体系等内容。

自动化测试的优点如下。

（1）模拟人工测试流程，减少重复、机械的测试工作，让机器执行固有流程， 提高可靠性。

（2）提高测试的精准度，提高测试执行范围，针对海量参数进行测试，机器的执行效率会更高。

（3）更好地利用测试资源，将复杂、烦琐的测试流程交由机器执行，可以让测试人员有更多的精力去关注质量保证方面的问题。

（4）具有可重复性和测试一致性。

（5）提高测试用例的复用性。

另外，自动化测试不是测试效率提升的关键，它也存在不可避免的劣势和局限性。在如下场景中自动化测试并不适用。

（1）永远不会再重复的测试流程。由于维护一套自动化测试脚本或者流程需要投入很大的精力和成本，因此仅仅测试一次永远不会再次出现的测试流程并不适合采用自动化测试。

（2）项目工期非常短的需求。由于准备一个新流程的测试脚本的时间会远远大于业务测试执行时间，因此在工期并不充分的情况下，采用业务测试手段保障测试质量更直接、更迅速。

（3）UI 的易用性等测试并不适合自动化测试，因为 UI 设计的美化、交互是否符合人的固有习惯目前是机器无法评价的，还是需要业务测试人员直接参与。

（4）实际软硬件结合场景。例如，需要无人机配送的测试，并不适合自动完成全部流程。

（5）任何技术都有局限性，上面并没有完全覆盖自动化测试不适用的所有场景。测试开发工程师是一个交叉工作的角色。

与开发工程师相比，测试开发工程师除了要具备写代码的能力，还需要掌握操作系统、数据库、网络、软件测试等相关领域的知识；与业务测试工程师相比，测试开发工程师拥有编写测试脚本、设计测试框架、搭建测试平台、维护测试环境等技能，但是可能没有业务测试工程师那种专业的业务知识背景。

测试开发工作，本质就是为了保证测试能够正确且顺利进行而做的工作。测试开发要服务于业务测试，测试开发不是脱离业务而单独存在的。在软件系统生命周期过程中，业务测试工程师和测试开发工程师是并存的，并不会彼此替代。虚拟平台质量管理组也是由于工作需要，才逐渐地走上了转型这条路。那么，你为转型做好准备了吗？​

《京东质量团队转型实践》

京东研发虚拟平台 著

每天，上亿级别用户访问的互联网系统，各种应用在持续不断地被测试和发布，怎么能够保证这些系统可以安全、快速、大并发地被用户使用是个极高的挑战。本书结合京东质量团队的日常实践，以第一视角剖析了京东质量测试过程中成功应对的各种“坑”以及填“坑”的方式和技术，值得从业者很好地学习和借鉴。

本书揭示了大量的奇巧妙计，绝对100%实用且扩展性强，涉及测试流程、测试工具、测试用例、自动化测试框架、测试管理、持续集成等方面。使用这些技术，你可以把测试工作由瓶颈变成一个加速器，使得整个团队都更加富有效率。