• API研发实现规范化管理的价值


    随着公司业务的增长、项目需求的不断变化,运维的成本越来越高,开发人员996也越来越常态化,而在大部分公司实行前后端分离的当下,研发团队用在沟通、测试、管理API中的时间和用在开发项目代码上的时间也越来越相差无几。
    以下和API相关的问题广泛出现:
    API 文档不清晰而不知道怎么对接和测试,需要反复和后端沟通,甚至要看代码;
    前端和测试需要等待API开发完成才能继续进行工作,测试用例无法复用;
    API变更了没有及时跟进,不知道哪里改动;
    接口文档和测试是两套系统,来回切换并且无法同步数据;
    自动化测试需要写脚本,学习成本、时间成本、维护成本高;

    不着急说解决方案,我们先来理一下API开发的驱动方式。

    在API开发的过程中,基本可以分为文档驱动和测试驱动。前者是指开发前先写好接口文档,用标准文档代替口头约定和笔记文档;后者是指在开发前先写好测试用例,快速用测试结果推动开发进度。

    那么这两种驱动方式是割裂的吗?答案我会说不是。
    传统接口文档的缺陷在于三点:自然语言的描述容易产生歧义;不能自动化地验证;不能保证文档与开发同步。由此,延伸出了与之对应的测试驱动。
    那么换个思路,如果有个工具,能自动生成文档、还可以满足大部分的接口测试功能,不就可以了?
    我们公司最近由于国产化需求,开始找新的API管理工具,后面找到了一个还不错的,叫Eolinker,能满足我们研发团队的API开发管理需求,还能直接导入原来的Postman和Swagger上的API项目和接口文档。
    放两张使用的图,有用过的可以一起交流一下~
    场景1:前端开发已经对接完API,将当前API状态改为待测试,并且通知相关测试人员进行测试。

    场景2:后端已经开发完成API,自行使用测试人员写好的测试用例对API进行批量测试,排查错误。

    使用地址:www.eolinker.com

  • 相关阅读:
    First duplicate value
    SQL学习笔记day1
    Find closest value in BST
    BST construction
    Closest sum_pair
    滑动窗口 sliding window
    设计模式(3)观察者模式
    设计模式(1)装饰模式总结
    深刻探讨public class=new class();
    与时间赛跑,我的2012
  • 原文地址:https://www.cnblogs.com/dc20181010/p/14212548.html
Copyright © 2020-2023  润新知