• 接口自动化本身定位就偏向用于回归测试吧,功能测试过程中单接口测试才是重点,在开发环境通过接口自动化来验收本身就是一个成本不低的做法,个人看法。

  • 测试需要有独立的测试环境,跟开发共用很明显的一个问题就是资源竞争,这是个很明显且项目经理能很容易感知到问题,测试需要测试时,开发需要占用,直接降低了双方的效率呀,这个理由还不够么

  • 用例定制哪里可以直接搞解析器把协议数据解析成可视化结构就好了,就不用对着 wireshark 去一条条转结构了

  • 返回的条数在于你需要验证哪些数据吧,在解析器增加协议筛选就好了,根据用例获取用例指定的协议数据做校验

  • 同楼上,我多开一个线程专用于发心跳包,相当于同时存在两个线程:一个用来发测试协议 一个专用发心跳 但是会存在一个情况就是如果测试协议大量在发送的情况下,心跳包很难抢到时机发送,会出现无法定时发送心跳,这种情况怎么解决?还是说在有协议通信的前提下,心跳包可有可无?

  • 嗯嗯 感谢大佬! 一开始是我自己想岔了,解包的时候按照类似 int 这种去解了,然后陷入误区了,后面找服务端对格式 说前面有 2 个字节是表示字符串长度的 。😔

  • 膜拜大佬,顺便问下 struct.unpack(">i",packet[:4]) 类似这种 如果服务端返还的内容是不定长的字符串该怎么去解包?比如现在返回的格式是 int str int str ,第一个 str 怎么确定它的结尾?

  • 仅楼主可见
  • 关于测试用例的一些迷茫 at 2020年05月13日

    测试用例必要性个人觉得有几点可以作为参考:1、方便整理测试思路,并不是所有的需求要点都会体现到需求文档上面,所以有很多要点是需要做需求分析的时候去进行功能补充,还有就是有些设计可能是似是而非的,还得设想程序端逻辑实现,进行相关测试验证和环境相关的准备 2、方便后期版本维护和回归 ,特别是需求改动多的模块,没有老版本对比很伤 3、方便他人接手,节省二次需求分析时间。测试用例反馈出来的不就是测试流程覆盖的过程么,小体量的功能模块 ,可以通过经验临时去覆盖测试,但是对于大体量的功能,没有用例做参考,或许回过头来 你都不知道自己测试执行到哪一步了