有bug ，提还是不提？这是一个问题

　　记得刚进淘宝的时候，有一位开发同学一直就把“测试是开发的敌人”这句话挂在嘴边，一直希望他所对应的测试少提bug或者是不提bug。虽然轮岗开发的时间不长，但是开发对bug的态度也有了些了解，不愿看到测试提bug的开发同学还是占多数。当然可能bug的数量和开发同学的绩效挂钩，开发同学关注的多也可以理解。但是，对于测试来说，bug仅仅表示在产品交付前和使用中出现的非正常情况，从一个侧面反映了产品缺陷程度，但是却不能负相关的代表着产品的质量，是一个对缺陷的记录。因此在bug 是否需要提这一点上要和自己对应的开发沟通好之外，测试一定要做好的一件事情就是即使bug不提，bug所反映的问题也必须在产品交付之前进行修正。因为测试的责任是保证所交付使用产品的质量，其余方面均不是所要优先考虑的。

　　距离产生美，独立可存真

　　我认为在测试执行阶段要保持测试工程师足够的独立性，这里所提到的独立性并非是说要测试和开发完全分开，其实完全分开这在实际工作中也是不现实的。打个比方，接口测试的配置文件和接口所实现的逻辑还是要依赖测试与开发的共同交流才能够顺利的完成。性能测试中，测试虽然能够列出部分的性能点，但是每个性能点背后所对应的性能测试接口和脚本还是需要开发同学的帮忙才能完成的。

　　这里的所说的测试工程师的独立性是指，在测试阶段，对开发给出的关于出现的bug或者缺陷的解释保持独立判断的心态。从开发的角度来看，都不希望自己的代码出现问题，同时也希望测试能够发现其代码的问题给予订正。但是当一个bug不稳定出现或者对某一模块十分有把握时，又会对自己的代码极度的信任。造成了给予测试bug的反馈是不正确的。拿同事的一个例子来说，他所负责的系统中，在调用MC接口时一直返回时空，这个bug已经提给开发了，开发给出的解释是由于MC的系统所暴露出来的服务有问题导致了这个原因，会继续跟进。在进行验证时，此问题还是存在的，开发所给出的解释还是一样，需要MC的开发来排查错误。这是该同事直接找到MC的开发，帮忙查看日志，是否有收到调用请求，结果没有成功调用，原因是开发所调接口传入参数中有一个为null，所以一直会调用成功。问题还是出在该开发同学身上，与外部系统并没有关系。

　　也正是因为该测试同事保持了应有的独立性，对开发同学给出的解释进行了进一步的跟踪，而不是轻易的相信，才使这个bug能够及时的解决也不会对后续的测试工作造成影响。

　　同时在测试的人数超过一个的时候，测试人员在任务分工上也应该保持相对的独立，涉及到模块间的互相调用时，尽量将有关系的模块分配给单独的测试人员，避免由于业务逻辑的重叠而造成测试任务的划分和执行的模糊。

　　也谈培养开发质量意识

　　还有一点我也认为非常重要就是被大家经常谈起的培养开发的质量意识，当然不是说现在的开发同学没有质量意识，而是说开发虽然意识到了质量是要保证，只是这种意识的程度还没有到达一定的高度。拿接口测试来说，虽然现在的接口测试已经提到了action和screen层，但是正像是地基打不好，上面盖得楼歪了也不好修正一样。虽然测试的层次已经提上去了，表面上看来代码维护量降低了，维护成本降低了，但实际上由于将dao和service层剥离出来交给开发，就意味着离真正容易排查出bug的代码远了。如果开发没有将这部分的测试代码写好，出现问题的排查成本将会十分高昂。将底层的单元测试交由开发完成并不意味着dao和service层的测试就不管了，前段时间也有咨询过我所轮岗产品线的开发，开发写单元测试的意愿是有的，但是接连不断的日常很有可能会是推延编写的最好借口。对这部分单元测试代码的完成度监控也应该是测试日常工作中的一部分。

　　当然，表面上的话谁都会说，但是到真正执行的时候难免会遇到很大的麻烦。开发不愿意写测试代码一方面可能是对测试代码的意义没有真正的领会到，另一方面可能是因为推脱不乐意写，另外一种可能就是时间太紧，没有时间来写。针对与前两种可以试试“回归”。比如，一个日常涉及到的代码改动量不大，仅仅是在底层做了部分重构，但是需要做回归测试。在没有底层的测试代码做覆盖的时候，可以和开发算一笔账，虽然测试和开发的时间比是1：3 但是考虑到回归功能所占用的时间，测试和开发的时间可能会达到3：1，因为在没有测试代码覆盖的情况下，不能够确定这样小的更改是否会引起其他连带的问题。因为需求方都是有时间要求的，相信这样的时间成本算在里面的话，对开发有意识的去编写底层的单元测试代码会有一定的帮助。当然只是让开发完成测试代码并不是我们的最终目的，培养起开发的质量意识，维持整个产品的稳定才是最重要的。

　　针对第三种情况，虽然现在不是很提倡测试完成单元测试代码，但是我个人认为，在测试时间宽裕的情况下，可以要求开发完成每个底层接口的smoke ，剩余的测试代码可以由测试来完成，这样一方面可以保证对功能了解的完整性，也可以防止开发在单元测试代码上的放水现象。

　　当然质量意识不仅仅是指单元测试的代码，还有编码的规范，比如方法和类需要添加注释，多于废弃代码的删除，类似于“system.out.println”之类的调试代码的清理等都在质量意识的范畴之内，当然虽然好的代码质量不一定意味着好的项目，但是一个好的项目一定需要好的代码质量来支撑，这也需要测试和开发的共同努力。

　　自测想来多风险，绝知此事要躬亲

　　这并不是想表达对开发自测的不信任，也不是说本该开发自测的任务，测试也要横插一脚，对所有的测试任务来个大包干，虽然开发自测，但是测试也应该进行参与，至少要对自测的内容和结果进行跟踪。不得不说开发自测有很大的潜在危险，有不少的日常开发为了节省时间，或因为改动不大，开发大多乐意选择自测的方式，但是测试不能因为是开发自测而直接划清界限，抱着如果出了问题责任不在我的想法。话说回来，开发自测真的可靠吗？小的改动真的没有问题吗？拿前段时间的一个例子来说，开发在IMS管理系统中系统消息管理中将profile标签的实现进行了修改，因为只是做了小的修改，所以没有提测试。但是在IMS消息管理系统中的营销消息管理部分同样会调用这个接口，如果没有及时发现这种关联影响，没有及时回归营销消息部分，就可能会导致上线后系统出问题。

　　另外开发自测也可能对测试环境造成破坏，为今后的测试造成不便。在没有测试人员参与的情况下，开发的在测试环境中的测试可能是破坏性的。比如还是IMS营销消息部分，由于使用shine框架造成提交脚本等操作全部需要在shine的服务器上发布，还需要shine的开发协助，不能够及时部署应用一直是个很头疼的问题。因此在一次开发自测的日常中没有按照流程，直接将本地通过的脚本预发之后上线，造成了线上环境和日常环境不同步的情况。这给后面的一次回归造成了障碍，当然这与我没有做好监控有很大关系。

　　这样就引出了另外一个问题，在和开发达成约束的基础上，建立项目完整的测试体系的重要性。如果每个产品能够根据实际情况将自动化测试，接口测试和单元测试选择性或者全部覆盖的话，并持续回归就可以尽可能早的发现开发对项目的改动，对项目质量的把控就会更加的容易，同时效率也会更高。当然这肯定少不了开发的帮忙。测试也只有在测试和开发共同的努力下才可以做得更好。