2012年是移动互联网年，我学习了Object C的开发，开发了较多的功能和内容，对于开发的过程和开发后的质量，以及开发自测有了新的认识。此前一直站在测试的角度去思考开发如何做测试，如何自测，如何共同保证测试。当时觉得不是很有难度，应该可以这样做，应该可以做到什么程度。现在对这个问题有了一些新的看法，作为个人的体会和感受，希望与各位讨论。

　　若隐若现

　　记得毕业后，我和隔壁班同学一起分到了HW公司的某产品部门，我在测试部门，他在开发部门。刚开始的半年，我学习了业务、数据库、操作系统、测试工具、测试流程和管理。半年后，我继续学习测试相关的资料，感到了一些迷茫，在HW是封闭式的环境，接触不到外面的世界，我觉得测试学得差不多了，看到同学每天写代码到很晚才下班，貌似学到了很多东西，成就感明显大于我。

　　于是，我开始偷偷地拿出来自己带的C++教科书，慢慢学习C++代码，当时我没有自己的电脑，使用公司的电脑学习C++，为的是不让自己忘记C/C++的语法和基本代码，没有完整的学习规划，再加上HW公司的确工作忙，只能慢慢地学习，效果非常不好，基本上自学的代码量不超过百行。开发能力和刚毕业时有了较大的下降，但是也没有太多的危机意识，觉得自己学到了很多测试方面和OS和DB的知识，在外面能有用武之地。

　　顺藤摸瓜

　　在HW工作一年后，我去了A公司。相对来说，A公司的工作压力要小很多，也接触到了外面的世界，除了学习更多测试相关的知识以外，仍然没有放弃学习和编写代码。由于接触的产品是C#编写的，需要重新学习C#的语法和基础代码。由于时间较充裕，加上和开发人员关系和谐，自己可以动手编写测试工具和相关的工具。清楚的记得自己为了锻炼编写C#的代码，写一个计算器程序，代码量上千行，对于自己开发的计算器程序有种莫名其妙的成就感，体会到了一些编写代码的乐趣；后来乘胜追击编写了一个简单的写代码的Edit工具，有点类似于UltraEdit。

　　也就是那个时候，发现自己编写的代码越多，隐藏的bug越多；发现修复了一个bug外，还产生了好几个bug。也许是自己的编写代码能力有限，清楚地理解了编程不是那么简单的事情。做出来的工具得到了开发以及开发主管的认可，感觉自己有编程方面的潜力，感觉不错，有些许的成就感，也曾想转岗做开发吧，但是一直没有下定决心。

　　我的开发能力得到了展现，希望尽量应用到测试工作上，当时我在SE Team，专门为产品上线后提供后续服务，对于技术支持人员报告的bug，我负责重现和 验证，时间上较宽松。在重现bug后，我都要调试代码，查看问题出现在哪里，有时候找到出现错误的原因，并给出简单的修改建议，开发人员在修复bug时，大致了解我对于该bug修复的注释。

　　随着时间和实践的增多，后来我不仅通过调试代码找到引起bug的根本原因，还会给出详细的修改缺陷的解决办法或变通方法，给出详细的原代码和新代码，同样也会验证结果。得到了开发的极大认可，我的成就感有了很大的提高，但是仍感觉和开发人员相比比较，我调试代码的能力较弱，投入调试的时间有限。从结果上来看，自己不仅仅保持了一定的代码编程能力，还可以将开发和测试的关系以及应用过程了解得更深入，相应地持续提高编码能力。当时也编写了基本的自动化测试代码，由于测试框架封装的较好，测试代码基本上没有太多含金量，这些工作不仅仅是了解这个代码规范，还详细了解了测试框架的架构以及基本实现方式，为后续接触不同的测试框架打下了基础。

　　东山再起

　　来到淘宝，我对测试能力保持充分信心。当时淘宝还是页面自动化的初始阶段，我结合以前对测试框架的架构的理解进行内部交流，为淘宝的测试框架的改进带来了一些新的架构思路，比如Page Model和DB Model。此时的编程语言变成了Ruby，只好尽快学习Ruby编写自动化测试代码，接着为了编写接口测试代码，马上学习Java，2010上半年我的开发能力还停留在自动化测试代码阶段。后来部门实施技术产品化的策略，将测试技术转换到产品中来，必须学会开发产品，所以当时参与了Web应用开发，开发公共用例中心（CTC），从而了解到了更多开发方面的知识。中间件、Spring、iBatis等等，在Java开发方面有了更多的进步，但个人认为还是皮毛阶段。

　　2011部门开始提倡测试具有定位bug的能力，在几个项目测试过程中，在时间充裕的情况下也会调试代码，从而找到引起bug的根本原因。但这个要求在互联网的项目流程中实施起来较难，因为测试阶段本身的时间非常有限，还要花费较多时间调试代码，有些得不偿失。开发人员和项目经理（PM）也未必真正认可，因为在测试阶段会给项目带来进度上的风险。但是这个过程，对于测试人员提高前端开发和Java开发方面的技术知识有较大的帮助。

　　我的个人体会是，测试人员不是一直处在编写代码的时间轴上，测试人员的开发能力随着时间的推移，下降很快，重新捡起来，需要花费较长时间。当时我在编写前端代码和Web service的Java代码时，投入了很多精力，咨询了很多同事，总算搞定了。但是3个月后（期间未做任何开发相关的工作），重新开发类似的工具或功能，还是需要花费较多的精力，感觉非常痛苦，真想转做开发岗位了。

　　知己知彼

　　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，但是对产品的质量提供了充分的信心。

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

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

　　六道轮回

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

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

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