• 1、对调用如参数组合进行覆盖,观察数据表读写是都正常(功能验收)
    2、尝试输入错误入参数,注入异常,观察数据的一致性和事务的是否正常(异常验收)
    3、尝试高频调用,观察 DB 测内存 CPU 开销,及早发现定位性能瓶颈,这样可以为上层调用推荐合理的并发和隔离策略(性能验收)

  • 以我的经验一个自动化测试平台的定位很重要,尤其是你需要 “破局” 的时候。首先,不要大而全,找准自己的定位,然后切进去,比如接口自动化平台最大的收益在于回归、监控、巡检,相比传统的 coding,可维护性高、传承性好,劣势也很明显:编写用例、迁移成本高。其次,明确劣势了就要最大可能的消除这种门槛提供一种平滑的过度,要立标杆看价值。

    一个平台有多 NB 不是功能有多么厉害多么全,而是说平台本身的包容性、无缝对接的能力能让用户真正的 “爽”。

  • 很艰难的 2019! at 2020年01月22日

    加油~ 2020 共勉

  • 回首自己 3年 的救赎之路 at 2020年01月22日

    工作四年有余,经历或多或少和楼主有些相似,有时候也喜欢瞎折腾,回过头来我会思考一个问题:我们搭了很多框架、实践来很多主流的模式,但是否就是最贴合业务的呢?我思索的答案是:不是!很多东西打心底里想来都是为了上手实践一把,太离散了,最终能形成体系才是一个长期的目标,相信这样也能减少几分迷茫~

  • 以我之经验,接口自动化的稳定性和全面性需要做一个折衷,往往校验的越精确,稳定性也会相应地有所下降(环境、数据、场景不同而定)在项目中我则遵循以下的一些规则

    1、多系统依赖的核心接口需要校验返回结构,值范围区间、核心值等,在持续回归中,可以接口变更可以第一时间知晓
    2、功能测试阶段应尝试覆盖更多的场景,不仅需要对返回结果进行校验,还要对涉及的资源进行校验(db/cache)等
    3、回归测试阶段则从功能用例 case 抽取核心逻辑、业务组成执行集可保证很好的收益