开发和测试的六道轮回(2)

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

　　2012年，开始无线移动开发和测试，我希望把握工作机会，开始了iOS开发之旅，重新学习O-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，但是对产品的质量提供了充分的信心。

　　(4)开发人员可以发现很多测试人员都发现不了的bug，然后"悄悄地"修复bug。2011年我经常和开发人员沟通，开发人员说他们发现了好多个bug，已经修复了，测试人员是不会发现的。我当时无法理解这个事情，现在我总算能明白一些了，开发人员在修复bug时或编写相关功能的代码时，会发现某些问题，然后修复掉，而测试人员完全不知道，很多时候也不会去测试这些场景。举个例子，APP登陆分为第一次登陆和后续登陆的逻辑区分和判断(包括读写cache和客户端数据库)，假设第一次登陆出现错误的结果，测试人员报告bug。开发人员修复bug时修改了相关的代码，从而引发该业务逻辑的错误，测试人员的大部分测试都不是第一次登陆看到的结果，测试人员很难想象第一次初始化会出现问题。假设测试人员想到这个场景，需要重新登陆、甚至需要重新安装APP、重新初始化，这些过程都是很麻烦的过程，测试人员不一定有坚定的信念完成这些操作。如果他知道如何实现功能的代码，调试相关if else代码，进行逻辑的修改，从而可以在白盒层面测试到自己需要测试的部分。

　　(5)开发人员需要了解的知识面远大于测试人员。完成一个任务，开发需要实现这个功能，需要付出很多精力。对于测试来说，完善的测试设计和测试执行，可能需要了解业务逻辑层面，而不是技术层面(如果在白盒层面进行更多的测试，情况会不一样)。总体时间是固定的，开发人员将在实现功能上耗费更多精力，响应减弱在自测上的投入。而测试人员刚好相反，测试人员会投入更多的精力去分析功能的异常逻辑是什么、用户的正常使用路径和异常使用路径是什么、用户体验上是否有改善的地方、开发会如何设计这个功能、会存在什么样的风险和问题等等。希望开发也会用一些时间思考测试人员如何测试程序，这样或许能帮助提高自测的质量。

　　六道轮回

　　上面讨论了个人做开发期间的一些感受，希望真正的站在开发的角度去理解测试，从而更好的从测试角度去测试产品、提高开发的质量。我需要解释这篇文章标题的含义了。我在2009年问过一位在微软总部工作的测试开发工程师，微软的测试最大的核心价值观是什么。他毫不犹豫的告诉我：开发就是测试、测试就是开发。

　　我一直没有很好的理解这个。现在明白了一点点了，表面上不同的岗位，不同的职责，大家的目的和目标是一致的。开发的过程中，开发人员思考如何测试产品，就是更好的开发产品。测试人员更好的思考如何开发产品，也就是更好的测试产品。开发久了，不得不思考测试的重要性，不得不提高代码的质量(其实你就是在做测试)。测试久了，不得不思考开发的重要性，不得不去发现更多更好的bug、不得不设法提高代码的质量，从而提高整个项目的流程和进度，同样也是减轻自己的痛苦(其实你就是在做开发)。

　　开发和测试，都有脱离不掉的责任和目标，为此，开发和测试人员都需要换位思考自己、思考对方。我相信未来开发和测试会有更好的机制理解对方、制约对方、依赖对方、完善对方、改变对方。开发人员不再看不起测试人烟、测试人员不再自我感到彷徨，大家在六道中享受轮回带来的乐趣和成长。

原文转自：http://blog.sina.com.cn/s/blog_6cf812be0101cent.html