测试现在都是怎么干活的 | 第3期 - 《践行者》

关于“测试”，你还有哪些想要了解的？

2022年11月23日晚，融·软件项目管理推荐实践库（RRPL）旗下直播访谈栏目“践行者”第3期直播圆满结束，同时也迎来了破千人观看的小高峰。在此次直播节目中，我们邀请到了京东前测试架构师陈磊老师来为我们分享“测试”主题。陈老师为我们分享了超多测试实战干货，为我们带来了一场酣畅淋漓的知识盛宴！

此次直播还有哪些精彩瞬间呢？跟着我们回顾一下吧！

一、践行者是什么？

践行者是一档主打实战落地的访谈栏目，旨在通过对研发实践、项目管理实践践行者的访谈，帮助大家了解到项目管理的实践及其实际应用场景；通过践行者本人的心路历程向大家展示更加生动真实的实践落地过程；通过实践过程中的小技巧、小窍门来帮助大家避开实践中的那些坑。

在前几期的直播过程中，我们也收到了许多小伙伴们对“践行者”的支持与鼓励，感谢各位小伙伴的关注与支持~

二、测试现在都是怎么干活的？

关于“测试”，陈磊老师先分享了自己做测试的经验，并从专业的角度对外界的认知误区“做测试是一件很容易的事情”进行了深入剖析。接着，又就“如何从需求阶段介入测试，实现测试左移”这一问题展开了详细的论述。陈老师用实践经验与理论相结合的阐述方式揭开了“测试”的神秘面纱，同时也为测试工程师们指明了未来发展路线：业务专家以及测试开发专家的道路，并提出了“测试”这一角色所具备的自身独特视角与经验。

三、问答实录

“测试”这一话题引发了小伙伴们的强烈共鸣，陈磊老师也对直播间小伙伴们提出的问题进行了详细解答。此次我们也将问答环节的所有问题整理出来了，方便大家查询~

Q1：自动化测试在实际工作中用得多吗？

这个问题还要分团队来讲。自动化测试可以当做最后一道防守来使用，而并非进攻，因为它不是去发现Bug的。比如自动化测试在流水线当中的应用，假设在这次的发布分支是 release 1.0，研发把代码合到 release 1.0的时候，通过流水线就要触发接口自动化测试，然后再触发 UI 自动化的这种关键主流程的检验，最后是人工再进行一些探索测试。在这里你就可以看到自动化的作用了。

再举个例子，比如说小伙伴A修改了A接口，影响了B接口，可能小伙伴A评估的时候不知道会影响B接口，但自动化测试就能找到。所以自动化测试你要用好用对它，它在实际工作中对你来说就会很有帮助。

Q2：请问测试和QA的关系？

我们先从大往小说，从QA、QC、QE和测试这块开始讲。QA 是质量保障，QC是质量控制。QE其实也是一个测试执行，QA是流程的制定和保障。QE和QA这两个是相互合作的。QC现在比较少了，替代的就是测试。那测试是我们去做测试执行，去用测试方法检测测试结果。流程执行不到位的时候，QA会帮你把流程落地，他会用一些方法帮助整个团队贯彻下去，不仅仅停留在测试层面，还有可能包含产品和研发等。

测试要验证两个点，一是验证正确逻辑的正确性，二是验证异常逻辑的正确性。举个例子：做一个登录界面，业务的正确性是指我在输入正确的用户名，输入正确的密码，点击登录按钮能正确地登录系统。那当用户输入正确的用户名、错误的密码，点击用户登录按钮，系统会拒绝登录。这两个都是要验证的。

测试的小伙伴要去验证这两种情况是不是对的，除此还要验证一些异常，比如一些 SQL 注入或者非法验证。这就是一方面面向业务逻辑，一方面面向正确性。

假设你发现了一个问题引起一个很大的资损，它会被定义成故障。这时候QA会拿这件事情帮团队做复盘。

Q3：测试工程师在需求阶段提的优化建议都因成本问题被驳回。

对于团队来说，测试起到的是提示风险的作用，将风险提前暴露到团队中。而团队中其他的角色会通过自己角色的特定视角，比如通过运营角度来进行一些考量，如果在做了这些考量之后，团队整体觉得这些点并不是风险，那这个结果会是整个团队通过综合考量做出的决定。

Q4：公司UI自动化落地难且需求变更频繁，前端逻辑做限制，后端接口不限制。

这个问题我们还是可以先将它抛出来，然后记录到缺陷系统里。UI自动化测试对测试的小伙伴是有好处的。UI自动化只是验证你的用户角色的验收测试，做黄金业务流的这种覆盖，能给测试工程师省事。

在团队中，有些问题不是测试一己之力能解决的，所以我们把问题抛出来。虽然我们倾向于把这些问题也解决掉，假设团队觉得不是问题，你也应该把风险暴露出来，哪怕对公司来说，没有那么优先或者重要。但它在测试或者质量视角下，确实是个问题，你都要将它暴露出来。所以，做好自己就好。

Q5：如何看有些人认为先做接口测试，最后才做UI测试？

我认为没有先后。你擅长哪个可以先做哪个。我们常说接口测试，其实也叫接口自动化、API自动化。自动化就是人偷懒，让机器去一遍遍反复执行命令，这是一个提效的过程，所以你会写哪个就先做哪个。

Q6：瀑布项目和敏捷项目下，测试同学的职责有什么区别？测试类型、介入时间、关注的重点有什么区别或者注意的地方?

我只讲测试的活动吧。瀑布模型里，大家都知道测试是在研发交接棒后才投入的。测试同学应该要考虑比较多的点，比如测试计划、测试方案，之后要测试执行过程、测试环境准备过程、测试环境验收表、测试环境评审会、测试用例评审会、测试报告、测试报告评审会等一系列工作，当所有文档都留痕之后才上线。

在敏捷中，在测试之前的需求阶段，要推行开卡验卡。在过程中我们推崇先通过流水线去触发接口自动化、UI自动化，然后再进入人工测试。在整个项目的回顾会时，测试小伙伴要考虑在这个迭代里有没有存在哪些质量的问题、有没有改进点等。然后在下一次迭代中设立新的行动，通过方法或者其他人的配合去改进掉。

所以，无论是瀑布还是敏捷，这两种都会有不同的考察点，但最终的目的都是为了质量。所以大家都是站在质量的角度去考虑问题。

Q7：希望介绍下卡脖子设备类似“光刻机”等测控类软件测试的特异性、基本方法、重点等。

我接触过一个设备的测试叫双聚焦型离子质谱仪，它也是一个高精密的设备，号称只有法国能生产。这些设备有硬有软，之前我们主要测试该设备的软件部分。有点像之前做嵌入式的上位机下位机的思路，下位机跟上位机之间其实是模拟器。在面对整个操控软件时，还是要以它的特性为主。功能性上是找的专业人士给讲解的输入输出和计算过程。兼容性方面我们用的兼容矩阵，因为它在不同的机器上会装上相同的版本，从而去支持我在我的电脑上可以去控制下载机。

除此之外，我们还会在一些交互性上做测试，不过这个会更倾向于站在整个验收角度。

Q8：达成全自动化，一般需要多少基建投资？

其实这个是衡量不了价钱的，因为我们的平台化是基于容器做起来的。整个部门的基础设施的硬件资源的成本是统一计算的。所以不能准确地知道他建起来需要的硬件资源是多少。但如果说全自建的话，整个的硬件上或者资源上成本并不高。

但要是说从技术能力投入上来计算，投资有可能会比较大。比如我曾经所在的一个能源企业，当时测试开发团队有六个人，都是高级的测试开发工程师，还有一些资深的架构师，人员成本就比较高。但因为技术上采用全自建，所以投入相对来说会少一些，并且我们没有购置的费用。所以这个没办法准确衡量，就投入来看，我觉得纯硬件资源的投资其实并不大，这个可以不用太纠结。

Q9：测试的KPI如何制定，有哪几项关键指标？

首先我们站在个人能力的角度出发，你的KPI 第一个指标就是基本工作能力，能够按时完成工作，简单说就是需要测试的你都测完了，并且不能缺陷遗漏。但是我们都知道测试的万能原则之一，就是我们测不到所有的缺陷，测试系统里面肯定有一些遗留缺陷。

这里我们需要注意几点：

第一：站在常规角度，测试遗漏率或者测试逃逸率，需要控制在一定的范围之内。我建议大家对这些方面做一些简单的约束。并且也不要刻意地将自己的KPI在制定为一个月或一个季度内，一个测试的线上事故都没有，因为这是不可能的。

第二：站在个人的业务角度去设立一个KPI，这个KPI其实没有统一的设定标准。对于测试工作者来说，我更推崇的还是测试自动化，我建议大家在测试自动化角度做一些 KPI的制定。比如测试的接口覆盖率啊，UI自动化的黄金业务流的覆盖比例。

测试制定KPI可以考虑的点在于减少缺陷、如何提效，这里说的提效我就要引入自动化。这时就可以去制定KPI。比如你做了多少自动化、研发暴露的问题，你的KPI 是不是都覆盖了？比如业务测试，你可以对业务覆盖度还有整个用例评审的最后的结论指标做一个约束。

Q10：公司开发绩效，根据问题缺陷等级高低和数量评定，测试的绩效根据提的问题质量和无效缺陷、错误缺陷数等评定。导致开发和测试喜欢私下解决问题，结果数据统计时不准确，这个问题怎么解决呢？

首先，这个现象真的不好；第二，这个现象又经常会出现。我们团队曾拿缺陷数量来衡量评价研发个人的开发质量。每一个考察或者考核都会有投机取巧的方法，这会导致那些不容易出现Bug的先被抢了，基本就是那些好实现、需要你写的代码比较少。这样其实对团队不好，大家都去拿简单的，核心功能反而没人认领。这对公司来说就是损伤，所以我不推荐根据这种评定标准，这会导致测试和研发双方都受伤害。

如果非要这么做，最好是要有判谎的指标。比如你的缺陷数，要跟你提交的代码行数、功能的优先程度和重要程度进行换算。要让敢承担的人有犯错的机会，不然整个团队就没人去承担了。

Q11：测试如何解决覆盖率和测试穷尽的问题？

测试覆盖率，我们要说的就是测试有效性。去评价测试有效性可以考虑几个事情，比如单元测试。单元测试其实就是白盒测试，但我们现在去评价单测用的是测试用例设计方法。单测也是有有效性评价的，就是编译测试、PIT。如果PIT结果是好的，那它是有效的，那它覆盖率又高，它就是好。

所以有效性是要放第一位的，自动化测试的覆盖率、测试穷尽其实都是有效性的问题。你如果想知道测试有效性的话，有技术能力的，在接口和UI上更推荐精准测试。

覆盖率的话还是要分行业赛道的，比如在物联网，覆盖率到50%就已经很高了。但如果是一些航天领域，那就要100%了。

Q12：测试会看测试覆盖率吗？这个测试这覆盖率怎么算呢？执行通过率代表什么？可以反映开发的质量吗？

单元测试我们在Q11已经讲过，接口测试需要看到开发开放出来的接口覆盖。有些接口没有被测试到，就是没有覆盖。大部分我们的分母是与开发开放出来的接口文档上面的数量为主。测试分子是测试用例是否覆盖了这个接口。做自动化测试，需要一个脚本，脚本里面的参数是最重要的。所以我们提倡参数应该尽最大可能的覆盖。

从参数上讲，如果是单接口测试，我们更推崇用边界值或者是正交实验的一些生成器来做入参。我们在接口测试比较推荐的实践是先做单接口测试，再做一些接口的串联的这种业务逻辑模拟的测试。在单接口测试时，比较推崇把接口入参的所有可能情况都覆盖掉。保证单接口是稳定可靠的，而且它的兼容性都设计得非常完善。

在做业务逻辑时，我们面向一些业务流程会做接口层的串联。这个时候面向的跟纯业务测试的角度是一样的，那我们面临的就是业务正确性和业务异常性的测试。单接口测试我们就要考察接口是不是都覆盖了，业务逻辑测试主要是看代码的变更是否都覆盖到了。

如果没有自动化测试，主要使用人工测试，那大部分我们还是靠主观的评审会评价测试是不是都覆盖了。这需要团队设一个有专家经验的角色。如果团队有一个业务专家或者是对系统非常了解的资深业务测试工程师，将由他来主导评价，这个带有专家经验的角色，会从自身的角度出发给出一套评价标准。整个过程中测试更加依赖专家经验，测试结果没有办法给出客观数据，这种评价是无法完全被度量的。

Q13：项目集的测试计划怎么做？分开还是做整体计划？

我理解的项目集其实就是一个项目，它有很多个微服务。在这个背景下，第一还是要先做我们的单个服务的测试。其实每一个服务的测试都是有外部依赖的，推荐大家用解耦的方式。如果大家用过一些公开的mock，那就继续用自己熟悉的工具就可以了。同时也给大家推荐两个工具：

第一个是Moco，它对测试工程师很友好，用JSON 写代码，且HTTP和Socket都支持。第二个是可以用HoverFly这类服务虚拟化的工具。通过这类工具做解耦，把每一个服务都测试完全，再集成起来跑一遍全流程。跑全流程的时候，也应把主流程的正确流程全部都跑一遍，异常流程可以挑串联服务边界的进行测试。

像测试会分层，分单元测试、接口自动化和 UI 自动化，还有金字塔模型、橄榄球模型等。在金字塔模型中，单元测试为什么占那么大的面积？因为单元测试投入产出比最高，所以我们单元测试做得最多，它在金字塔模型中占的面积也比较大。如果说单元测试投入产出比高，我们为什么不能都做单元测试？或者不做UI自动化，不要接口自动化不就可以了？其实不是的，他是需要弥补间隙的，因为单测只测我们的被测函数。那它里面有外部函数，调用外部数据库的时候，我们提倡把它用stop去解耦。之后，这个时候接口就会测试一个接口，下面它会调一些函数，调一些Web数据，调一些Redis，调一些其他的函数。那对这个函数去测试了，它会覆盖原来接口单元测试没测试到的边界。所以，应该先保证每一个单个的服务质量都是好的，把它串联到一起，再把联调或者集成这些边界业务逻辑重点做测试，这样才能保证最终的项目集交付是一个质量好的项目。

如果将项目集定位为由多个项目组成的大项目集，项目集之间还是一个服务级的依赖。当它不是一个代码级的依赖，其实方法是一样的。如果是代码级依赖的话，我们有可能是要通过一些插桩的方式去采做一些局部的解耦，但执行思路还是一样。我们对单个项目要保证测试的完全性，再把它们集成到一起。这两种方式可能在解耦的技术上会有些区别。

Q14：如何看待Google、Meta没有专职的测试人员这个问题？

之前听Meta以及Google的老师说过是有专职的测试人员的。没有专职测试人员这种说法好像是从《Google软件测试之道》一书中提及的，有可能Google的部分团队是没有专职测试人员的，书籍作者经历的可能是一小部分团队，但实际上其他的Google团队是有专职测试人员的。也有可能测试人员是作为外包出现的，虽然有这个角色工种，但可能不归属在公司里。

Q15：非功能需求方面的测试怎么做？

非功能需求涵盖的内容是比较广泛的，其中有兼容性、有性能、有稳定性、安全性、可扩展性等等。但现在安全性已经越来越专属，成为一个独立的领域了，我们就不算在内了。

性能方面：
非功能需求涵盖的内容中性能是最普遍，也是最简单的。单点的性能，首先需要找一个你最熟悉的工具，比如：GMV、Lo Loader、One Loader、以及我常用的Lokas等等。然后我们就需要利用工具去设计测试场景，设计测试场景最常用的就是并发量，并发量的设计有很多种方法，在此就不赘述了，大家感兴趣的话可以去我的CSDN博客搜索。

标准方面：
标准常规的情况下我们会以资源特性（资源特性包括CPO，服务器的CPO内存网络的IO，还有磁盘的吞吐等等），以及一些业务的并发量，有可能是QPS、TPS，这些其实没有一个通用的办法，只能靠团队对整个业务的掌控能力、分析能力、预判能力。若没有的话，建议去做一个基础值。

兼容性方面：
建议大家用兼容矩阵，兼容矩阵就是用2X2的矩阵做一个碰撞，保证所有的版本在所有的操作系统上的所有的浏览器都能执行，或者说在所有的手机端都能执行。

稳定性和可靠性方面：
现在比较推崇的是混沌工程测试，我们可以更好地把这些工具利用起来，如果想尝试开源工具，推荐阿里巴巴的Cross Blade，它相对来说比较容易。

除了以上这些主流的测试方法，还有一些不是很主流的测试，比如说容量规划等等，其实那就是链路测试和性能测试的一个变种。如果有需求，可以有去进行专门的学习。如果没有需求，我们知道它是用什么来做的就可以了。

Q16：自动化和手动测试怎么配比，可以将测试的效率和质量达到最优？

自动化测试和手动测试其实没有比例，是着重点不一样。API自动化关注单接口测试的正确性、容错性、健壮性；业务接口测试业务逻辑的正确性；UI自动化验证黄金业务流的正确性；人工更推崇探索测试，发挥人的主观能动性找问题。

Q17：未来的主流是自动化测试吗？为什么公司招人要求自动化测试，实际压根不使用。

DevOps应该是主流，所以测试还是在最后环节就会变成研发效能的阻碍。在DevOps之下，持续测试是最好的测试实践，持续测试推崇自动化先行的实践。所以，自动化未来会逐渐走到手工测试之前，提高质量和效能。很多公司招聘要自动化其实有些是为了储备，有些是为了自然淘汰一些应聘者。但是公司有可能还用不到自动化技能，而且有可能短时间内也没有实践的计划。

Q18：UI自动化的价值高吗？

UI自动化测试应用到自动化验收测试中，在验收测试环境做黄金主流程的验证是可见收益最高的阶段了，也是最大价值的发挥。

Q19：从0到1搭建测试体系，重点要关注哪些方面？

找一个适合公司的质量模型，在模型之上搭建规范和流程，在流程之下设计工具、平台，这样就可以了。

Q20：开发过程中，需求的颗粒度大概可以分为哪几个层级？应细化到何种程度再撰写测试用例？

我们比较推崇一个故事卡在2-3天内完成，通过实例化描述需求内容。每个公司对故事卡的交付周期要求不一样，可根据完成时间来约束需求的范围和大小，这件事情需要Scrum Master支持，约束故事卡的大小也就可以实现到测试需要的输入颗粒度了。

Q21：有人说自动化测试占比理想情况85%，哪些情况使用自动测试，哪些情况使用手工测试？

部分可以参考Q17的回答，具体占比并没有一个好坏的黄金比例，还是要看团队、被测试系统。因此是多做自动化测试、还是多做手工测试，都是依据团队、被测试系统、被测试业务等选择的。其实全部流程都可以做自动化测试，有些有可能投入成本高，着眼于当前环境下，这样的投入并不划算。

Q22：质量度量指标，比如缺陷修复率等定到一个什么样的值比较合理？

质量度量不建议选择一个指标，更建议选择一组指标，缺陷修复率更建议按照等级统计缺陷遗留数，这个缺失没有一个更优秀的指标告诉你留几个是对是错，这个指标是让团队知道我们有多少个缺陷没有解决，它在系统中有多大引起资损造成故障的可能。遗留数不要太多，越少越好。

Q23：对于做功能测试的人，如果线上出了故障，怎么去给测试定责？

线上故障，不推崇定责。交付团队是一个团队，故障找到原因是什么部分没有做、没考虑到等造成风险外溢，因此找到问题，建立技术改进故事卡，后续在制品流中完成，而不要责备某一个人。

Q24：To B交付，怎么保证测试质量以及环境（开发环境、集成环境、线上环境、客户旧环境）兼容问题？

To B比较推崇的是测试服务化，将测试也变成可以同系统一样交付的服务，自动化测试可快速在交付环境做冒烟，并且一定要有一个在交付环境的UAT，通过自动化测试完成。

测试现在都是怎么干活的 | 第3期