📝 面试求职： 「面试试题小程序」 ，内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）
📝 职场经验干货：
没有人否认软件质量的重要性，但是把软件质量建设好的难度超过很多人的想象。
因为软件质量保障的主要手段，软件测试，是繁琐的、重复性高的、人力消耗巨大的工作。
客观上，需要测试的场景是无法穷尽的，而测试资源包括研发自测资源永远是不够的。要想在有限时间内完成尽可能多的测试，我们需要提升测试效率，让测试更简单。
测试平台是一种利用平台化技术让测试更简单的方法。其基本框架如下图所示，包括：
-
UI层：前端，用户交互入口，主要提供用例编排功能，以及用例执行入口和报告查看入口。
-
Service层：后端管理服务，负责用例管理包括增删改查、持久化存储，以及执行agent的管理与调度。
-
Agent层：后端执行服务，负责用例实际执行并产出测试报告与日志。
基于这个框架，测试平台承担了用例管理、用例执行与测试报告职责，而用户(例如研发、QA)只需聚焦测试场景设计与测试用例编排，理论上可以极大提高测试效率。
然而在实践中，并不是所有测试平台都能实质提升测试效率。相反，有些测试平台不仅不能提效，反而降低了测试效率。这些测试平台有一个共同点：UI设计得非常复杂。
如下图所示，用例页面的用例编辑区包含许多子区块(例如用例步骤、用例数据、用例配置)，每个子区块又包含许多输入框(例如步骤名、输入参数、输出参数)和许多操作按钮(例如新增、修改、删除、复制、移动)。
为了完成用例编排，用户需要与大量的输入框和按钮进行交互。一些更复杂的测试步骤，甚至需要打开2跳或3跳页面才能完成编排。
我把这种测试平台称之为重UI测试平台，它的问题是：
-
易用性差：对用户来说，页面上有太多的输入框和按钮，操作很麻烦。而且用例内容割裂，分散在不同页面和输入框，无法一览用例全貌，用例不好维护。
-
迭代速度慢：对平台来说，由于用例编排逻辑与UI页面深度耦合，如果想要改动或扩展编排逻辑，通常需要升级UI、Service、Agent每一层服务，迭代缓慢。对于测试平台这样内部日常使用的平台工具，如果不能做到快速迭代，就容易拖累项目进度。
在我看来，重UI测试平台是有违让测试更简单初心的。那么，怎么办呢？
针对这类需要复杂UI操作才能完成编排的场景，我们可以采用一种轻UI的设计方式，如下图所示：
对于轻UI测试平台，用例编辑区包括2个子区块：
-
用例编辑区：负责用例编辑，支持用户基于可读性好的、配置化的语言(例如YAML)编排测试用例。
-
帮助区：提供语法说明，指导用户进行编排。
轻UI的优势是：用例所有内容管理在一个编辑框内，一目了然，便于查看与修改。
但要注意的是，轻UI测试平台不是唾手可得的，它取决于我们能否设计一套支撑用例编排的语法，而这需要洞察力与抽象能力。并且，对于任何业务场景的测试平台来说，这种语法往往没有先例可参考，只能根据业务场景针对性设计。
作为demo，我们为API性能测试这一场景设计了类似下图所示的用例语法。基于这个语法，用户可以用简单的几十行YAML编排任意HTTP API性能测试用例。
轻UI的另一个优势是：如果需要扩展测试平台能力以支持更复杂用例的编排，通常只需增加语法规则，而增加语法规则只需升级agent层，UI层和Service层无需改动，测试平台迭代速度大幅提升。
另外，使用基于配置语言的方式描述测试用例，也有利于运用AI大模型技术辅助我们生成用例。
当然，以上重UI与轻UI的划分只是表面现象，背后本质是测试平台与测试脚本的职责划分。因为不管哪种形式的测试平台，最后终归要生成可执行的测试脚本。
测试平台的出发点是让用户通过UI页面简单配置用例，后台自动生成测试脚本，大幅提升效率。
但是，如果测试用例的复杂非常高，以至于我们的抽象能力无法支撑对它进行简单化、模板化，因而无法通过轻量级UI实现测试平台化，那么就应该退一步，将测试用例编排逻辑全部下沉到测试脚本中，测试平台仅作为执行入口，甚至直接去平台化。
在实践中，我们需要灵活调整测试平台建设策略。无论如何，我们不能忘记建设测试平台的初心是让测试更简单，而不是更复杂。
最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
