随着测试左移思想的引入,API(应用程序编程接口)经济的飞速增长,导致对 API 管理平台的需求相应增加。越来越多的企业注重并关注接口测试。单纯的做接口测试或者做好接口测试的本质工作其实并不复杂,我们可以借助接口测试工具辅助我们的工作,或者自己编写代码维护核心接口自动化脚本。单一地来看要做到这些其实并不难,难的是想要把整个过程流程化、规范化。这需要我们花费一定的时间去梳理和制订,下面是我们在测试过程中经常会遇到的一些问题和建议,我把这些整理出来,希望可以对大家起到建议性的帮助和正确的引导。
统一的 API 文档有助于减少项目维护和沟通成本,无论什么项目、什么人编写什么 API ,系统都可以保证 API 文档的可读性,方便后续维护和团队协作。如果有一款 API 文档管理工具能够方便管理、查阅 API 文档,就可以提高日常代码(CV)效率,并且大大提高工作效率和高质量交付工作。
a.无法随时清晰的了解当前进度的状态
manager 无法从代码层面清晰的看到开发进度、需求排期的情况、是否已经到达提测阶段、是否已经对接和发布都缺少一个平台展示。
b.发现问题总是滞后
让开发团队编写进度说明比编写开发文档更难,由于缺乏了解问题的渠道,只能通过开会的方式,口头了解问题。但是当问题被说出来时,其实早已滞后了。
以上两个问题不难发现:项目进度管理工具并不完全适用于研发工作,如何规范开发行为、判断开发质量、帮助团队沟通的协作......这些日常问题依然得要人力介入,效果并不好。
管理缺乏工具,针对研发工作需要有深入参与研发的管理工具才行。
通过 API 变更通知、API 评论、API 版本管理等功能促进团队高效协作,构建敏捷团队。
主要体现在以下方面:
a. 前端开发进度受制于后端
单纯 API 文档缺乏 Mock API,前端需要等待后端开发完成才能拿到测试数据,自己构造测试数据费时费力。
b. 反复沟通浪费时间
由于文档滞后于代码,而开发经常在开发最后才完善文档,导致前后端对接需要反复沟通确认。
c.缺少统一沟通平台
如果 API 出现了什么问题,只能在内部通讯工具交流,既没有存档,也不便于多人协作。
d.文档变更不通知
后端开发改了代码和接口习惯于口头沟通,而不是通过文档明确地指出修改的内容,导致后期沟通成本高昂。
e.文档阅读体验差
文档不标准、内容不清晰、平台不统一等问题导致最终文档效果也不好,体验越差越不维护,导致破窗效应。
f.接口测试不方便
需要看着接口文档再另外使用工具进行测试,如果接口发生了变化,写好的测试也作废了,增加了重复工作量。
帮助团队内部进行协作,共享劳动成果:
团队之间没有参与任何沟通协作的内容,缺乏 API 定义、测试、协作的主动权。
a.测试工作重复
需要看着接口文档再另外使用工具进行测试,如果接口发生了变化,写好的测试也作废了,增加了重复工作。
b.工作成果无法分享
每个测试人员都用单机测试工具编写测试脚本,但却没法共享和协作。
c.测试工作不自动化
一直希望促进自动化测试,但是没有真正运作起来,每天“点点点”依然消耗大量测试团队的精力。
d.测试效果无法量化
无法准确了解测试效果,没人可以说清今天、昨天、上周、这个月的测试情况如何,和之前比有何改进。
e.测试工作被动
测试总是排在最后进行,无法参与项目讨论,无法进行快速大范围回归测试,甚至无法按时完成测试任务,导致项目延期或带着忐忑上线。
将文档和测试关联起来有助于减少 API 测试和维护测试用例的时间,不再需要一边对照 API 文档,一边打开其他的工具来测试,提高了测试人员的工作效率,所有 API 测试数据、用例、报告都在平台中统一管理,减少测试团队的重复工作,让团队成员可以共享工作成果。
API 自动化测试经常受到测试人员编码水平等因素的影响,难以大范围和高效实施。Eolink 提供的 API 自动化测试可以不编写代码,测试人员进行简单的培训后即可编写复杂的测试用例,通过自动化取代手工来进行重复的 API 测试,帮助测试团队提高测试效率和测试覆盖率。
以上的问题你在工作中遇到过吗?请问是怎么处理和优化过程的呢?
欢迎在留言区分享你的经验和心得,一起交流。