引言

实在不好意思，此次写序列三距离二已经是六七个月的时间了，期间一直有考虑，只是各种事情太多，所以出来较晚，请谅解。这次说说互联网环境下的测试：

互联网环境下的测试

说道互联网网很多人想到的是快，忙，加班多，而当问到缺少的各种说明，需求，设计，文档，大家都会说要敏捷嘛！

我们先来说说敏捷的产生，为何要敏捷，是为了快，为了紧追市场，那怎么快？我们开发需要的是快速迭代，测试需要的是快速测试，ok 这些都没问题，可大家有没有发现，我们互联网的工作生活除了省了很多工，快了很多事，是不是也出现了更忙的状况，忙着修复 bug，忙着修改上期漏洞，忙着找已离职人员的代码或者用例，忙着执行那迭代了一遍又一遍的 case，甚者，当某人有事来不了的时候，你会发现整个团队就成了无头苍蝇。我们打着敏捷的口号省工，结果是图了快，而忘记了质，忘记了积累，忘记了如何能更好的快。

我理解中的敏捷是快速，轻巧，高质。任何一本敏捷的书上都未曾说道可以省去白盒测试，单元测试，接口测试，也未有一本书上可以说省去分析设计；他们说的是快，但并没有忘记早期介入，他们说的快，是头脑风暴，是白板追踪，脑图记录，关键信息纪要，而没有忘记同步代码的跟进，测试和开发的合作；而我们的实际结果是只是省略很多步骤，测试没有早期介入，省去了分析设计，直接上手执行，上手写代码，等提测了，上线了，发现一切都从源头没有沟通好。但从测试来说，大家想想，其实测试自身质量的保证是哪个环节，是分析设计还是执行？执行？一个毕业生，是不是也可以操作？可是不考虑业务复杂度，不考虑测试的分析方法，不考虑场景和逻辑关系，这样出来的测试结果，你们心里会有低吗？可能会有人说那懂业务的就可以呀，ok，那产品经理应该是最懂的，可他懂测试分析设计方法吗？他有时间或者懂得按照测试的思维去吗。如果可以做到，那是不是要产品经理就可以了，测试的竞争力在哪？

sorry，比较混乱啊，我拉回来说，现在很多人打着敏捷的口号，干着最没技术含量的工作 -- 执行，重复着同样的事情，只能是忙。丢掉了敏捷的本质，那让我们停下来想想：如何改变忙的状态，让敏捷生效？我的建议是：

1. 不忘初心，还是要早期介入，从早期就了解到项目概况，从产品文档中就能发现设计不合理处，用户体验不好的地方；
2. 开发 coding 阶段，进行测试分析设计，任何形式都行，你觉得好使就是最好使的。当前很多人会用脑图，其实也不错；
3. 如果你想让别人顺利加入你的项目，那请把脑图里面的测点描述再详细点，而不是你脑子里记住就行，这样谁都可以随时过来帮你忙；
4. 自动化你的测试用例，半自动化也可以，这样对于复现 bug，回归测试都有好处；
5. 针对接口测试：当你有了一定的冒烟的脚本之后，下次开发再说忙没时间单元的时候，请把你的冒烟 case 扔给他，说执行完了通过了再提测；
6. 针对界面测试：当开发连主功能都不能保证的时候，还让你白非工，那请把你认为重要的冒烟的 case 扔给他，让他通过了再提测 -- 此时有个要求，就是你的 case 首先要质量高，无用功做过一两次之后开发也就不好意思了，你给他他还会不用？

如果我们去自动化重复部分，细化分析设计，让刚入门的去执行 case（这也是个了解业务的过程，不比专门培训的效果差吧），那是不是会有更多时间去学习代码，提升速度；学习业务，发现漏洞，成为业务大拿？

有人会说自动化的投入比较大，我这里不是说让你做高大上的自动化，你只需要去自动化你能自动的部分，等你吃到第一口蜜的时候，你就想吃第二口了，然后自己项目的自动化不用别人说，你自己就做起来了，等开发说你复测下，开发话音还没落，你就说 ok 了，没问题，这时看着开发一脸的惊讶，你会不会很开心。（其实，这是我的心里路程啊。我现在见到高度重复的工作就想把他自动化了

其实互联网的东西更像是传统行业中说的产品，他会迭代会变，但是总有不变的部分，等不变的部分都交给了代码交给了工具，我们互联网忙，死忙的状态会不会好点？所以有人说互联网和传统不同，我想只是要求更快了，而不是要求质量更次了，我们应该是想在保证质量的情况下去变得快捷的，那 ok，就抛弃那些繁琐的无用的文档 -- 我也不喜欢有的文档写了好几十页，废话就占了一大半，我们敏捷只需记录关键的信息，那些漂亮的话自由广告和推广的人去做。

ps：后续考虑前两篇大家提到的一些细则的事情，在此先做个提醒记录。