测试平台的价值？

初识测试平台

在初识测试平台的时候，由于刚从使用 pytest+UIAutomatic2 框架进行自动化测试转为使用测试平台，而公司平台自动化模块功能的不足，我对其持有较为负面的看法。

UI 模块 ：用起来不如稍微 PO 封装的 Python 写 Selenium 脚本方便，更别说封装得比较好的 UI 框架了。填写 UI 元素需要通过界面点击按钮新增，维护元素名称、xpath 路径等信息，这一维护流程非常繁琐且耗时长，单用例调试速度很慢，定时任务用例批量执行的时候没有留下报错截图。

接口模块：没法任意生成各种随机数，很多场景难以造出可变参数。断言不支持提取前置变量，只能写死。接口出问题了报告也很难查看，难以通知到每一个人。当接口依赖严重的时候，前后接口用例关联较困难。

测试平台的优点

深入使用测试平台后，我发现测试平台具有以下优点

1. 打通禅道实现bug跟踪和用例关联

• 方便进行 Bug 的跟踪管理，并统计和分析不同版本的 Bug 情况。

• 用例可以与禅道对应需求关联，并集成思维导图进行用例线上管理，提供通用用例复用功能。

2. 实现各种定制化需求，如企微文档推进测试进度和生成测试报告

• 在测试平台上可以实现各种定制化需求，例如与企微测试驱动文档集成，以推进测试进度并及时发送每日提测项和逾期项提醒给相关人员。

• 生成测试报告，自动从禅道、UI 自动化、接口自动化和性能测试等模块获取数据，生成每个版本基础的测试报告。

3. 提供强隔离的数据和代码框架，维护和拓展性强

• 测试平台对数据和代码框架进行了强隔离，确保在维护和拓展过程中具有很强的可维护性和可扩展性。即使在更换框架或语言时，数据仍然可以继续复用。

4. 学习成本低，适用于业务壁垒高的公司

• 对于业务壁垒较高的公司而言，测试中的业务专家通常不愿意花时间去学习技术方面的知识，重新招聘或从同类型公司中招聘一名技术业务都达到要求的测试所需要的成本非常高。

5. 统一的技术栈，减少团队间的技术交接难度

• 在许多大型公司中，每个团队往往使用自己独立的技术框架，导致跨团队协作困难。就像经常会听到朋友吐槽别的团队写框架很糟糕，一个 py 文件几千行的用例根本没法接手维护。测试平台提供了统一的技术栈，减少了团队间技术交接的难度。

测试平台暴露出来的缺点

然而，测试平台也存在以下缺点，不及时解决则会演变出其他问题

平台后续维护成本高

由于测试平台通常只能由开发人员编写，往往选择与公司业务相同的 Java 语言进行构建（这样可以方便地重用工具包和架构等），导致平台变得很重（庞大且复杂），进而增加了维护成本。

平台技术更新跟不上

不同模块的技术更新速度很快，当集成的平台无法对相应的技术进行升级时，反而会导致效率降低。

UI 自动化大部分团队会选择使用 Selenium 5，甚至小部分换成了 playwright。接口模块也存在多种热门选择，有使用 Requests 的，也有使用 Java 语言的 REST Assured 的。这些框架有较多的社区人数和平台支持，可以集成各种工具，如 Allure、Jenkins 等，但公司平台使用的为 Selenium 2 封装的UI自动化和 JMeter 与定时任务实现的接口自动化。

随着工具组件迭代更新，带来的问题也会日益明显，平台如果无法跟上工具组件迭代的步伐（资源不足），导致技术债务越来越重，需要投入的资源缺口就会越来越大。但实现的功能效果相较于新的工具/框架却显得并不好用。相比之下，平台的缺陷也开始逐步显现出来，大家开始对自动化测试产生质疑。

对自动化测试/工具信心下降

久而久之，工具的不好用会导致团队对自动化测试的信心下降，认为使用工具时认为投入产出比太低，导致不愿意去学习和使用自动化测试或其他平台功能，开始形成恶性循环。在上周宣布要在考核指标中增加一项 Jacoco 测试覆盖率的要求后，开会时同事表示不太愿意过早将其引入到考核中。主要问题在于对于该功能没有信心，“大家希望工作能有实际产出，但是究竟是为了指标去做这件事情，还是真的能提高测试质量？”。但实际 Jacoco 的工具如果用得好的话，是能对质量做出一定的效果，如：

• 可以在 Jacoco 的报告中查看到版本增量代码中没有执行过的部分，也能找出自己业务用例中遗漏了的部分

• 能发现开发未通知增加的优化或改动以及过期、不执行的冗余代码

• 能作为反向约束研发MR（Merge Request）过程中的准出规则

思考总结

测试平台并非没有作用，而是在于不同的公司特性决定是否需要测试平台的

业务背景

• 业务方需求是什么？例如，版本的按时交付，质量保证（0bug 上线，无中高级别）

• 重交付 or 重质量，钱 -> 交付速度 -> 质量，会形成三角形，根据业务侧重点决定最优实践

团队背景

• 公司资源层面，是否有协调运维和研发资源一同推进自动化测试平台的能力，项目是否由测试驱动

• 测试团队层面，业务专家和技术专家的比例，人员能力侧重点是什么，技术栈侧重方向

如果是新项目则先保证交付，交付稳定再考虑自动化，最后再考虑自动化平台。

没有最好的方案，只有最适合的方案

但当前行业市场环境差，基本没有太多的资源去做测试平台开发，测试开发方向的人才也很少，导致招聘困难，大部分公司没法让测试平台体现出其价值。相较于测试平台较低的投入产出比，目前市场上大部分的公司还是喜欢使用轻量级的工具“小快灵”。这些单独的框架工具能快速得到产出且效果明显，能让测试人员自身接收到较好的正反馈，也有着非常活跃的开源社区去保证了软件和框架技术的不断更新迭代。

第三方测试平台的兴起

由于大部分中小型公司很难承担起独立开发测试平台的升级和维护成本，市场上出现了非常多的第三方测试平台定制的业务，以及开源测试平台等。

行动吧，在路上总比一直观望的要好，未来的你肯定会感谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入群： 786229024，里面有各种测试开发资料和技术可以一起交流哦。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。