知己知彼

　　2012年，部门开始强调开发自测，很多部门开始进行直接的开发测试比的考核和价值考察。我对这种做法一直持保守态度，可能和个人的经历有关，也可能和被测产品有关。对于互联网产品来说，需要做很多测试工作，完善被测产品的质量和用户体验。

　　刚开始我的策略较为简单，将测试设计共享和传承到开发人员，开发人员能接受多少，就可以一定程度上避免某些bug，从而在进度和提交测试质量上保持良好的平衡。开发人员还是比较喜欢这种方式的，但是开发人员很少真正将异常测试场景自测下去。经过几个项目的试点，发现效果较差，原因肯定有多个，大家也会猜到一些。

　　接下来强化单元测试，一方面开发人员提高单元测试的覆盖率，另一方面测试协助单元测试，但是这其中有很多瓜葛，特别对于上层Web应用来说，开发人员的压力较大，提测（开发人员完成开发和自测后，进行提交给测试团队的时间点）压力也较大，从而一定程度上影响单元测试的覆盖率和持续集成，再加上测试人员的Java理解代码能力不高，短时间内也无法做到较好的单元测试。只能测试人员慢慢地提高Java代码理解能力，导致测试进度缓慢，很多事情开发和测试都是心有余而力不足。当然，开发自测还有很多其他的策略和方式，不是本文讨论的重点。

　　2012年，开始无线移动开发和测试，我希望把握工作机会，开始了iOS开发之旅，重新学习Object C语言，重新学习新的开发方式，坚持了一段时间后，自己对于iOS开发有了一些感觉。总体上来说，iOS开发比其他的开发更有成就感，因为开发出来的APP看得见摸得着，容易看到成果。刚开始加入产品的开发团队时，将测试设计的大部分时间用来开发产品的某个功能，感觉比较痛苦，我花了3天才开发出来的功能页面，一个刚毕业不久的开发人员只花了一天就搞定了。我当时的痛苦只能自我感受，必须持续坚持下去。为了尽快熟悉iOS开发技术，我多此请教开发人员。后来开发了tBug，从使用Storyboard到丢弃它，写了更多的代码，看着自己开发的APP，成就感真的比发现bug要强烈多了。

　　通过在iOS上积累开发经验，这让我更多地理解了开发人员，更多亲自感受开发人员的心态和对于测试的态度，大致包括几个方面。

　　（1）使用快速迭代时，对于某个功能需求，开发人员编写代码时绝大部分考虑正常流程，较少考虑到异常流程，很多精力是放在如何实现功能，而不是思考用户会在多种场景下，如何使用这个功能（此任务需要测试人员投入很多时间思考）。

　　（2）开发人员在修复一个bug后，存在一定的思维惯性，只能验证这个bug是否修复，没有较多的时间测试相关的功能流程，而测试人员会发现该bug修复后引出的新的bug。我针对Bug调试代码后，很快找到引起bug的原因，很快的修改了bug，较少思考修复的方案是否会带来新的bug。在修复一个bug时，开发人员往往有多种方案去解决这个bug，但是不同的方案会带来不同的结果，有些方案会引发一些新的bug，有些不会。所以我也经常建议测试人员不仅仅要验证bug，更要思考bug的解决方案，思考这个方案会带来什么影响，从而探索式的使用更多的测试场景去测试它。

　　（3）开发过程中，考虑如何去测试它，难度不小。有人会说，使用“测试驱动开发（TDD）”方式，开发之前，先把测试用例写好。这个方式的确很好，但是对于测试经验较多的人而言，可以这么去做，但是开发人员还是需要耗费较多时间思考如何实现，而不是如何测试它（这就是测试人员与开啊人员思维的差别）。所以测试人员强迫自己写完代码后，多去测试它以及周围相关的功能。真正体会持续集成的作用，虽然没有发现bug，但是对产品的质量提供了充分的信心。