其实三个月前就发了一篇《提前的年度总结》,不过当时只是贴了张思维导图,今天有时间,用文字的方式写细一点吧,也做个年终的记录。
先简单介绍一下我们的团队: 我们是负责某家大型企业某系统的 web 端和 mobile 端测试的团队。所负责的项目都是基于这个大型产品某些功能的迭代开发,每个项目新加的功能不多,但是由于系统的业务复杂性,每个项目都需要充分考虑到对应的影响面和测试覆盖度,以及每个季度版本和月度版本都需要做的版本回归测试。每个季度版本中会涉及几十个项目。
为了增强团队成员应对每一个项目上对质量管理的一致性,我们首先组织团队内部的资深测试专家和同事对我们的测试流程进行进一步的标准化制定和整理:
为了提升测试准备、测试执行各方面的效率,团队在今年开发和引进了以下的工具:
团队在设计测试点的阶段,会使用 xMind 编写思维导图格式的测试点组织,方便思路整理和评审; 但在评审完成后,仍需要转化为对应的测试用例,上传到 jira 中进行管理和执行。 按原来的方法,等于是把所有的测试点重新用文字写一遍,影响效率。
基于 xMind 库,我们用 python 开发了一个将 xMind 转化为 excel 文件的工具,基于 Jira 用例上传模版作为基础,结合 xmind 中约定的一些规则,可以快速转换为可直接将用例批量导入到 jira 中,节省了很大一部分手工再编写一遍用例的时间。
在之前的做法中,在回归测试阶段,负责自动化测试执行的同事需要根据每天 Jenkins 上面执行的自动化用例结果,逐条地更新到 jira 对应的 cycle 中(团队要求使用 jira 进行用例执行监控和管理),导致虽然自动化覆盖率不断提高,仍然需要一定的手工操作的现象,自动化变成了半自动化。 基于这一点,我们基于 jira 的 api ,直接在 pipeline 中在自动化测试结果中读取每条 case 对应的结果, 通过 jira api 批量地更新到对应的 jira cycle 中,从而真正打通自动化结果更新到 jira 的最后一环。 这样在回归测试阶段,同事在每天上班后可以马上看到 jira 中所有回归测试用例被自动化测试跑通过的情况,彻底降低这部份的人力; 同时也更促进了同事参与、维护自动化测试用例的积极性。
多语言测试这部份,已经独立在另一篇中介绍,这里不做赘述: https://testerhome.com/articles/34758
在平时的测试执行当中,我们会需要一些内部的小工具去查询对应的测试用户信息、去数据库获取验证码等。这些小工具在之前是以不同的脚本存在的,需要每个同事在本地分别去安装和维护,使用体验不高。 今年我们通过内部搭建了一个简单的测试工具平台,把对应的小工具都集成到了这个平台上面,这样每位同事可以直接通过访问这个平台就拿到对应的信息,不需要本地去安装、更新配置,快速直接; 同时也将这个平台推广给开发同事使用,提升了开发调试的效率。
针对团队的自动化测试,做了以下的一些优化和提升:
在之前每个 team 都一个是通过 Jenkins 触发每天的自动化 job 执行,结果通过邮件发送到每个对应的团队。这种方式不利于我们想快速查看自动化通过率的变化情况,以及对比前后几天的自动化结果。
通过团队里小伙伴的努力,我们在每个 job 的最后,把对应的结果和测试报告的地址通过接口发送到对应的收集平台中并保存到对应的数据库;然后整合到平台前端进行展示。这样小伙伴就可以完全摆脱邮件,直接从统一的平台上面看到过去一周的结果(出于对存储空间的考虑,只保留最多一周的结果)。
这一点在上面也提到,这里不再赘述。反正效果就是可以把自动化结果直接反映在用例层面,小伙伴只需要对少量执行未通过的用例进行手工执行验证即可,把更多的精力放在拓展性测试上面。
原始的自动化测试框架并未考虑并发执行,当自动化测试用例不断积累提升之后,执行效率变成了一个急迫需要解决的问题:
-- 1. 在 suite 层级,如果两个 suite 直接没有测试账户的依赖,则拆分到不同的队列和线程里面执行。使用的是 python 的 multiple treading 模块。
-- 2. API 测试:在用例级别,基于 pytest xdist 插件,做到同一个 suite 里面,只需要登录一次,复用对应的登录 session 、cookie,对后续的用例进行并发执行。
在 locust 中直接调用 pytest 中的部分代码,对接口进行性能测试,帮助开发快速发现接口相关的性能问题。 这样可以减轻为了做性能测试,专门编写相关代码的时间成本。