开发和测试的六道轮回

2014-01-08   出处: 新浪博客

作者:@季哥_岁月无声

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

接下来强化单元测试,一方面开发人员提高单元测试的覆盖率,另一方面测试协助单元测试,但是这其中有很多瓜葛,特别对于上层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、不得不设法提高代码的质量,从而提高整个项目的流程和进度,同样也是减轻自己的痛苦(其实你就是在做开发)。

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




声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
313° /3136 人阅读/0 条评论 发表评论

登录 后发表评论
最新文章