simple · 回帖 · TesterHome

自动生成 case 在 SDK 项目的 mock 测试中的应用 (理论篇) at 2016年10月19日

#7 楼 @ycwdaaaa 首先非常感谢那么认真的回复，写了那么多字呀！
我一个字一个字的看完的，就是希望跟坛友如此的探讨可行性。
我逐个答复一下上面的一些疑问哈，为了避免讨论变成各种 challenge，因为文章字实在太多，可能大家看的时候会有些跳跃。

工具值不值得投入
其实，我个人从这个课题的投入成本来看（1.5 个人，两周时间，即锻炼了新人，又给项目带来了一定的收益），是值得的。
我在社区里面贴出方案，其实是想听听不同的声音，顺便抛个砖看看能不能引出更好的、已经成熟的解决方案的 “玉” 来。并不是越做越迷茫，来求答案的，所以大家不要误会。

当前项目的问题优先级
其实做这件事的时候，我是有两方面考虑的。一方面是同事说每次发版一会感觉测试覆盖的场景不够，除了 case review 以外，对于字段的校验需要更多的检查（可能也是因为广告返回的字段太多让人产生了不踏实的感觉），因此我们需要更多的覆盖范围，而这个范围是可靠、可控的。另外一方面考虑的因素是，这种产品形态非常的时候做自动化，为什么不尝试着解决一个现有的问题呢？还能锻炼成员，做一些有挑战性的事情。

关于技术人的情怀
其实就是 “我有一个锤子，想找个钉子” 的工程师思维，对吧？实际上我们解决问题的过程是这样的：团队开会列出最棘手的问题 -> 找出最短时间能解决的问题 -> 调研解决方案 -> 落地解决方案 -> 观察效果。

前三条问题
这个我们已经有流程上不错的方案了，只不过文章已经提到了，不属于技术讨论的范畴，流程的话可以单独拎出来说一下。RAP 我也有去看，之前调研的时候看了很多方案，在社区里翻了底朝天，但是这个产品太重，不太适合我们 SDK 的方案，所以没有去用。

环境问题
这个是历史原因，非常复杂，跨公司跨部门跨团队，而且领导层关注点不在这里，属于那种大家明知道有问题，却搞不定的困局，其中沟通的困难一时半会儿也讲不清楚的。

字段穷举
讲真的，如果真要是字段值的穷举法，我觉得我写那么一大坨也是白忙活了。今天有个朋友跟我说，我们的方案是从值的角度去设计 case，而不是业务角度去设计 case。怪我文章没讲清楚。我们在源头的模版定义的时候，会控制每个字段的取值范围，包括正常取值 [0,1,2,3,4] 这种有业务含义的取值，还有一种负面测试字段~[a,-1,null,@!#$] 类似这样的。而不是穷举一个字段所有的笛卡尔积再进行拼装。。。

运行时间
如文中所说，我们不到 3500 条 case 大概需要 75 分钟，因为手机分布式运行，数量还可以扩充。所以时间现在已经不是大问题了。另外我们不是穷举。。。

文件读写、数据库操作等
对的，接口很多是需要各种前置条件，修改 config，重启 service，清空缓存等等，如果这样的话，case 执行不知猴年马月了，而且还会带来很多不稳定因素。庆幸的是我们的 SDK 项目只需要校验前后字段的值，以及后期广告展示的效果（基于 UI 的），还有下载、跳转、打点等。