开发和测试的六道轮回

　　开发和测试的六道轮回

　　2012年是移动互联网年，我学习了O-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，从而在进度和提交测试质量上保持良好的平衡。开发人员还是比较喜欢这种方式的，但是开发人员很少真正将异常测试场景自测下去。经过几个项目的试点，发现效果较差，原因肯定有多个，大家也会猜到一些。

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