测试团队技术转型实践方法

Posted 2022-09-22 CrissChan

1 概述

随着DevOps广泛落地，持续集成、持续交付和持续部署已经在各类团队中有了各自特色的实践方式，大大缩短了从需求提出到交付客户的时间周期。但是在高效的交付过程中，质量保证过程却变成了快速交付的掣肘。传统的手工测试已经无法满足快速交付的要求了，那么要解决耗时较长的手工测试和快速交付之间的矛盾，利用测试技术提升测试效率是目前最为有效的方法。

这里面所说的测试技术包含了自动化测试、测试平台以及智能化测试，那么这些测试技术和测试团队又如何应用才能达到一个有效的提高质量效能的作用呢？这还是要结合测试团队当前的实际情况来选择的。

2团队的形态

各个团队也是各有各的不同，总结下来大概有如下三种类型的团队：传统质量保证的团队、模式敏捷的团队以及敏捷团队。

2.1 传统质量保障的团队

传统的质量保障的团队是完全按照瀑布模式交付的，需求收集、代码开发、测试保障、上线运维四大工作模块有明显的工作交接界限，如图1所示：

这种传统质量保障的团队角色分工明确，角色间交集相对较少，项目交付主要是以“面向测试的开发”完成的项目交付，团队交付的最终质量全部仰仗于集成测试阶段测试工程师对系统的理解，以及对系统的了解程度。当有一些需求发生变更的时候，绝大多数情况都是产品经理直接和开发面对面确定，测试工程师往往都是在测试过程中发现不一致才知道需求发生过变更。整个团队以及在修复测试提出的BUG、修复生产的BUG、修复生产事故、hotfix发布版本等一系列的工作中循环，这类团队交付物质量差是最典型的特征。

2.2 模式敏捷的团队

模式敏捷的团队是指学习了一些敏捷方法了，团队中有一些对敏捷的理解，往往这种团队更多的是学习到了敏捷的样子，这些样子例如每天的站会、迭代计划会、迭代总结会、需求条目化等等。这种团队在外人看来是一个敏捷团队，当深入团队迭代中后会发现，这些团队站会就是面向Scrum Master的汇报会，迭代计划会和迭代总结会的内容是面向业务的汇报会和邀功会，条目化需求就是一句话需求的代名词，这其实是套了敏捷外壳的传统交付团队。

这种团队最典型的特点是开发不断的压榨测试团队时间，每个两周迭代周期有大于8个工作日都是在开发需求，测试是不是能完成迭代任务并不会被研发团队所在意，每两周的迭代只会让没有交付给用户的需求源源不断的堆积在测试工程师手中，从而导致测试工程师用远远小于一个迭代的质量保障时间完成至少一个迭代的测试任务。迭代中有明显提测环节。在交付系统频繁发生线上故障的时候开发工程师又疲于修复各种问题，这也就影响了固定两周的开发交付进度，因此又形成另外一种开发赶工的恶性循环。

2.3 敏捷的团队

这是一种正式的敏捷交付团队，项目需求条目化拆分合理，所有的需求都有清晰的验证条件。开发工程师会为每一个开发的功能代码段撰写单元测试，每次提交的代码都没有引入新的技术债；测试工程师在开发工程师编写代码的时候，测试工程师已经准备好了对应需求的测试用例，开发工程师完成开发后，持续交付流水线就可以将对应变更交付到测试环境，测试工程师依据已经完成的测试用例就可以开始测试了，当测试工程师完成测试后，持续部署流水线会自动的将其部署到集成测试环境，开始进入探索测试阶段。当一个可交付需求全部测试通过后，持续部署流水线将变更交付给客户。

3 不同的测试技术也是代表了不同的成熟度

测试技术最近几年也得到了快速的发展，从QTP类的商业化的工具发展成Selenium类开源的框架，这种成本的急速下降促使自动化测试技术广泛推广。自动化测试对人员素质的要求高和自动化大面积推广又变成了不可调和的矛盾，这就促使了测试平台化的发展，通过测试平台将自动化的测试能力赋能给更偏重业务的测试工程师，从而可以提升团队的质量效能，同时测试平台化也为测试智能化的发展奠定了坚实的中心化基础，测试平台化将测试能力集中到测试平台，那么让测试平台变得更加智能、让测试交付效率更加高效就成了主要矛盾，测试智能化就因此应运而生。

3.1 自动化测试

自动化测试主要是将一些手动测试任务通过测试脚本的形式留存下来，然后通过测试脚本回放的方式来完成测试回归部分的工作，那么在很多团队中的自动化测试如下图2所示方式运行的。

在每次项目提测后，手工测试工程师先按照提交测试的系统以及需求撰写测试用例，下一步就是完成测试，当测试通过后测试开发工程师再按照业务测试用例编写测试脚本。这个过程中，自动化测试最重要的就是在回归测试的时候能够快速回放，节省回归测试成本。

这里的自动化测试所指的是API自动化测试或者是UI自动化测试，那么在自动化测试角度其实是包含了单元测试、API测试和UI测试的，如下图3所示。

金字塔分层自动化测试模型中单元测试站的面积最大，也就意味投入最多，因为在单元测试阶段发现问题并解决问题需要的成本最小，其次是接口测试，最差的是界面测试。但是在工程实践中，由于接口测试逐渐的增加了揉入比例，通过单接口测试覆盖了一部分单元测试，通过多接口的业务场景测试覆盖了一些界面测试，因此分层自动化测试模型逐渐的演变成了如下图4的橄榄球模型。

如果想要团队中所有人员都可以完成自动化测试脚本的开发，那么就需要所有人都有编码的能力，这个要求对很多团队都会是一个难于逾越的鸿沟。

3.2 测试平台化

测试平台化是近些年发展出来的新方向，通过测试平台将测试能力提供给所有测试工程师，测试平台化有如下优越性：

1. 业务测试工程师专职于业务测试
2. 测试平台开发工程师更加关注于测试平台的设计以及开发
3. 测试项目还是有自动化测试资产保障系统质量、提高质量效能

测试平台方面既有开源的解决方案也有一些团队自建方案，那么无论哪种技术选型都是依托于团队的基础来选择的，具体要视自己团队的技术能力而言。

3.3 测试智能化

测试智能化是测试平台化发展的一个必然趋势，当测试平台广泛的赋能测试团队的时候，测试的效率和准确性的要求会更加的强烈，那么运用一些智能化的方式提升效率，就更变成了团队所面临的主要矛盾了。

智能化测试目前有一些商业化的公司在做，例如Test.ai，Eggplant、Testim等，这说明当前的智能化测试技术也并不是停留研究阶段，那么开源的智能化测试项目也有一些，例如智能化单元测试框架EvoSuite，智能化的Web框架recheck-web等等。

4 正确的团队选择合适的技术

在团队中并不是选择最先进的技术就是最好的技术，团队中选择最合适的测试技术才会让你的团队事半功倍。

传统的质量保障团队，如果团队业务交付压力不大，也有提升质量效能的责任，更加推荐采用最原始的自动化测试的方式，从内部人员培养到公司级别的框架封装都在团队中落实下去。这是因为绝大部分传统的质量保障团队都面临一个传统的被测项目，项目特点如下：

1. 被测系统建设时间已经很久了，技术老旧
2. 代码仓库里面留下很多开发工程师的辛苦劳作，如果说想按开发工程师人数纪录都不如用第几批团队更准确
3. 新需求每次都从入口层新作一条逻辑到数据层，项目中已有逻辑几乎没有办法再次使用，最重要的是看不懂，理不清，尝试理解历史遗留代码，不如新代码逻辑更快速
4. 仰仗于人工集成测试发现问题，按照菜单和页面布局写的测试用例一样的不再可靠，测试工程师自身对系统的熟知程度是上线后是否稳定的基石

而这种项目往往还伴随着系统逻辑复杂，重构成本高的一些共性问题，因此利用编写代码的自动化测试更加容易提升测试的效率。

模式敏捷的团队在质量效能提升的选择上有可能更加的困难，这是因为在学习了敏捷的交付模式却没有真正敏捷起来的项目，往往又不会给项目中的测试成员一些成长的时间，所以最好的方式还是利用测试平台化的方式提升测试效率。笔者在一个传统行业的公司负责质量相关的工作，面临过类似问题，就采用了自建平台的方式解决了该类问题。该平台包含了接口管理平台，通过监控被测试代码的变更生成对应的OpenAPI文件，然后在于历史OpenAPI文件进行diff，发生变更通知的接口将会重新生成测试代码，如图5所示。

接口测试模块提供将OpenAPI文件、Jmeter文件、Postman导出文件等自动生成自动化测试脚本代码，并提供自动化执行、数据驱动等功能完成自动化测试，可以和jenkins完成按需、定时的调取自动化测试脚本。然后可以将全部自动化测试结果上报到报告系统中，展示测试报告，如下图6所示。

如果模式敏捷的测试团队没有一个很好的质量效能团队的支持，就会陷入自动化测试没时间学习，测试平台没有人维护的两难境地，就会陷入无质量、无效率的两难境界。

敏捷的测试团队由于已经开始推行了持续集成、持续交付因此已经有了很好的基础，所以在这样的团队中更好的推动测试平台化，引入一些开源的智能化测试框架或者自建一些智能化工具是更好的选择。笔者在京东工作期间有幸参与了京东的智能化测试框架的设计和开发，核心是设计了自动化测试脚本生成算法，算法中设计了一种数据结构，如下图7所示

系统采用一个类二叉树的结构存储函数以及其入参的嵌套关系，一个树节点中包含了名字、类型、左孩子指针，右孩子指针和父亲指针。下面用一个例子来详细介绍一下这个二叉树是如何产生的，以如下代码段为例：

public String setPersion\\(Stirng sName,Integer iAge,HouseHold household\\);

	其中户口类HouseHold的字段（类成员）部分如下：

	Public class HouseHold\\

		public String sAddress；//户口地址

		public String sType;//户口属性（农业，非农业）

……

\\

其中被测接口是setPersion，入参有一个复杂参数household是户口类HouseHold。通过自动生成算法就会形成如下的一棵树，如图8所示。

其中根节点存储的是被测接口的信息，根节点的做左孩子指向第一个基本类型变量节点sName，被测接口的第二个入参还是一个基本类型节点，因此sName节点的左孩子指向iAge节点。

接下来处理被测接口的入参是一个复杂参数，因此根节点的右孩子指向一个household节点，然后可以看到HouseHold类包含了两个基本类型，因此household节点左孩子指向HouseHold类的第一个基本类型节点是sAddress，sAddress节点左孩子指向HouseHold类的第二个基本类型节点sType。然后我们通过深度优先遍历，按照接口测试编码规范生成了基于TestNG的测试脚本，如图9所示

5 总结

测试团队的技术转型是当前研发效能实践中重要环节，要用技术来提升质量效能，通过质量效能的提升来赋能研发，实现质效合一的目标，从而为团队实现持续测试打下坚实的基础。