测试同学在很多时候都是在沟通问题，复现问题和定位问题。

记得多年前刚入行的时候，我一直对复现问题不够重视，觉得自己是测试人员，主营业务应该是测试，复现问题应该是解决问题的人做的事情。后来尽管岗位分工越来越细，但是测试同学做的事情并没有越来越聚焦，反而整体的工作范围更加的宽泛，其实说白了就是专业性上有提升，但是专注度上的改善其实并不明显。

复现问题其实很多时候是测试人员的痛点，比如我们在测试过程中发现了一个问题，并发给了开发同学，然而，你可能会有下面的经历

• 开发人员表示在自己的环境上是好的呀，这个不讨论，各种梗太多了
• 开发人员表示看不懂bug上的描述，这点可以用截图和录屏来解决
• 开发人员表示你帮我复现一下吧，这时候就比较痛苦了，因为复现本质上就是重复

测试的时候一再的重复自己是痛苦且低效的，如果问题是用户上报的，那么除去重复之外，还要加上阅读理解的过程，阅读用户的操作过程，理解他们做了些什么，以及猜测系统或者产品的表现。稍微归纳一下，发现复现基本上都是在做下面的一些事情

1. 创建数据，可以是从app上，也可以是从网页上，甚至可以在admin后台去创建
2. 收集或查询一些周边数据，比如数据库或者是被测的系统和产品上
3. 结合数据和实际表现去判断产品或者系统的表现是不是正常

所以除了第3步之外，前2步都是非常适合用自动化脚本的方式去实现的。我就用python写了很多的辅助脚本去帮助我重现问题，下面是我的一些经验

用直接调用api的方式去创建/查询数据

因为现在大部分产品的管理端都是前后端分离的，所以管理端是可能有纯后台的api的；以及移动端app都是有api的，调用api创建各种测试数据其实是可以实现的，只要做好鉴权工作，调api去创建和查询的实现成本和维护成本都是可控的。

之前我是用直连数据库的方案去做查询和创建，不过后面逐渐废弃了这种做法，这是因为

• 数据库表结构可能会发生变化，从而导致脚本执行失败，从而降低了脚本执行的稳定性以及提高了维护成本
• 脚本需要去关注分库分表的实现，增加了实现难度，降低了长期的可维护性
• 因为安全审计的关系，数据库的连接和密码会周期性的发生变化，增加了维护成本
• 我们生产环境的数据库只有生产环境的机器才能访问，本地办公网没有办法访问，所以做线上问题复现的时候，直接连数据库就会显得有心无力了
• 直接写数据库可能会绕过后端的数据校验，可能会写入脏数据

所以在做自动化工具的时候一般不推荐直接连数据库进行数据的生成和查询

用爬虫的方式去查询周边数据

很多时候我们需要获取一些周边团队的数据，有时候我们可以通过api调用来获取，但也会有获取不到的情况；另外有些祖传的系统可能前后端不分离，后端并没有提供api接口，这种情况下我一般用爬虫来做数据的收集。

爬虫的方式有很多好处，但对于一些系统来说可能存在开发难度高，运行效率低的情况，所以如果有更好的方式可以方便的拿到数据的话，爬虫的优先级可以低一点。

用缓存去提高执行效率

收集数据，特别是收集多个页面或者是多个系统的数据往往是比较慢的，这时候可以用redis等缓存数据库来保存一下结果，这样可以加速代码的执行。这里不推荐用数据去做，因为收集数据是一项相对来说比较高频且随意的工作，数据结构一般不会特别稳定，如果表结构频繁变更的话，那么开发和维护的成本都非常高。我一般是把数据直接序列化成json字符串，然后丢到redis的sting对象里，简单方便。

另外我的测试数据创建过程一半也是用爬虫加api的方式，缓存下来的数据可以帮助我进行更加复杂的测试数据创建工作。

编写cli工具，让测试过程更加工程化

有一段时间我积累了相当多的python脚本，在实际工作中调用脚本就成了一门学问，一些脚本要这样调，另一些可能要在其他脚本调用后才能调用，记忆的成本很高，文档化的价值又基本没有，后来我发现使用cli工具去整合脚本调用，写好每个命令的help message，这样文档和调用编排都有了。

比如我们一个需要经常复现的场景是用户在某个地址搜索关键词(keyword)，没有办法搜到预期结果，这时候我会使用如下的cli进行复现

python reproduce_cli.py search -l=1.23456,6.54321 -k=somthing 

这里-l传入的是经纬度信息。最后把返回的结果直接扔给开发就可以说明清楚问题了。

如果不用命令行工具的话，那么复现的过程就会相对比较复杂

• 打开app，设置经纬度
• 打开搜索页面，搜索keyword
• 截屏或者录屏，再把描述发给开发

可以看到命令行工具对复现问题的效率提升还是很有帮助的。对了，我一半用python的click库去写cli应用，非常好用，墙裂推荐了。

最后

命令行工具除了提升复现问题效率之外还可以提升整体的测试效率，我是非常反对大家一上来就建立平台，发明需求，努力推广应用的。先把工具做好，大家觉得好用了，再把工具平台化，一上来就憋大招，风险其实还是比较高的。