做测试的这些日子踩的坑

毕业了，然后跳进了测试这个坑（跳）

给这半年工作生活做个小总结吧

1、不好好理解需求和架构的都不是好测试

  虽然总说我司很坑。但是新员工培训的时候真的是有一种豁然开朗感。团队一共五个人，一个安卓开发一枚后端Java开发一枚web前端开发 一枚交互设计师加上我一枚小测试。两周的时间去快速的做一个产品的雏形，也是目前在做的产品的雏形。全体一起一边边的改交互稿，进行需求分析，流程设计，后台接口设计，然后和客户沟通。那些交互稿、UI稿、详细设计文档，产生的时候，很有成就感。

其中最重要的收获是真正理解了是基于怎样的考虑设计的流程。后台是基于怎样的逻辑提供的服务。好处很明显：1、测试的时候知道功能上有没有问题，为什么有问题 2、问题发生时，由于对接口数据库和后台逻辑的良好理解，可以很好的进行定位。

但是很可惜之后的工作中都完全没有参与过需求的讨论、设计的审核会、以及服务端架构的讨论。基本上都是设计交付UE和UI，开发交付app给测试。然后就可以直接测了（啊嘞嘞）满满的都是在找设计为啥要这么设计和找开发是不是你做错了中浪费时间。

2、接口不自动化怎么活

最开始在我司实习的时候是有做这个的。用junit做接口自动化测试，然后两天直接上手干活。嘛，用那么一点点的Java基础外加还可以的学习模仿能力倒是马马虎虎上路了。但是问题来了，作为一个不是很熟悉业务同时也不是那么熟练运用测试理论的测试人员，要先理解一下接口使用在哪的 一般大家怎么用，后台逻辑又是怎样又涉及了哪些数据库，然后设计比较完备的测试用例。。。然后再把他们实现以下。结果我设计测试用例要花小半天，编码再花个小半天，然后再调一调一天就过去了。一天写一个接口的用例这种速度简直不能忍啊。当然那时候也没想这么多，也就听导师的好好写就是了。最后由于投入的时间太多这个项目也终结了。

之后我司就不做这方面的测试了。只有开发们进行自测（或者并没有0 o）

结果就是...在升级的时候经常发生接口A改好了B被改坏了或者A改了但是还是不好使等各种问题。而且各种问题往往还是在进行客户端回归测试的时候才被找出来。

被坑怕了的本宝宝决定自己找找路子。我是觉得至少要保证的是接口正确的几种调用方式不会出错啦，不用像原来那样每个接口写十几个用例。

3、怎样才能方便简洁高效的进行客户端的回归

如果在接口已经有保证的情况下，我觉着客户端的孩子们还是挺靠谱的。但是还是有的时候会出现，嗳这个bug怎么又出来了的情况。

而且在加了新功能的情况下原有功能好不好用真的很难说。

那怎样才能方便高效的至少把关键流程回归一遍呢。本宝宝想到了UI自动化测试。然后跳进了appium的坑里（噗通）。

以上是工作半年踩的坑和思考【歪头