注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

网易杭州 QA Team

务实 专注 分享 做有态度的QA

 
 
 
 
 

日志

 
 

TDD项目实践小分享  

来自zhaiyao   2013-06-09 11:35:48|  分类: 默认分类 |举报 |字号 订阅

  下载LOFTER 我的照片书  |
之前经历过一个自己觉得挺有意思的项目,对一直从事枯燥技术活的测试同学来说,一瞬间还是被点燃起激情了,大致描述下在这个项目中是如何运用TDD思路来尝试的。 
TDD其实都不陌生了,关于它的介绍也很多,不同角度出发,每个人理解也不尽相同。自己比较认同《测试驱动开发的艺术》中对TDD的6字总结:测试-编码-重构。
实践证明,我们的操作方式也就是先写测试用例,然后为了让用例跑通去写实现代码。用例全部pass后,再根据时间和资源情况逐步优化代码。

一、项目背景

项目之所以能实践TDD,也算天时地利人和了。
1.当时部门业务方向待定,时间和资源相对宽松,有实践机会。
2.开发团队质量意识和配合度很高。开发和测试想法一致都想创新玩一次。
3.项目类型比较适合TDD。小步快跑常迭代的敏捷型项目,TDD可以带来诸多好处。

项目主要功能点:
Ps.系统的名称和代码就隐掉不具体列出了。。
1.在一个后台xx管理系统中,完成对某种类型产品的管理,包括商品录入,编辑,查询,删除,上下架等基本功能。
2.监控功能。监控产品的售卖过程中的不正当定价;监控产品xxx情况;记录并进行处理等。。。

二.项目过程中TDD实践

TDD前期依赖:
TDD实践需依附前期设计阶段一个重要的产出文档——接口描述文档。包含接口名、类名、方法名等内容描述。

这个需加到项目流程中,也需开发同学的配合。这个文档的输出,其实也是利于开发工作效率提升的,因为基于接口层面的描述和定义是最清晰的。换位思考下,到了编码实现阶段,我做为一名开发,让我提供一个新增xx产品的接口,应该会比完成新增xx产品这个功能的XX部分来得更明确和清晰。所以,作为QA需和开发同学沟通一致,大家一起维护这份文档,保持信息的对称。那么后续阶段里,项目共涉及多少个接口,完成多少个,待完成多少个,也一目了然了。

接下来,测试同学就基于这个文档编写测试case桩,践行TDD了

TDD第一步:编写测试代码

测试设计测试用例,开发设计框架和接口,完成后,在工程中添加测试桩。针对app层+service层+dao层大家分工添加。
这时添加的测试桩都是空方法,先让它失败,
ps.以添加商品举例,根据方法命名可以大概清楚用例涉及的场景
eg.
public void testAddProductSuc_WithPrice(){
    want.fail();
}
添加商品测试场景有以下这些:
size,spuId,productId,shopId为必填项,price未非必填项,

那么添加完的测试桩实际就对应一个个测试用例:
成功场景:
testAddProductSuc_All();  
testAddProductSuc_NoPrice();
异常场景:
testAddProductFail_NoSize();
testAddProductFail_NoSpuId();
testAddProductFail_NoProductId();
testAddProductFail_NoShopId();
测试用例全面地覆盖TC中的测试点,有了这层保障,开发可以放心地去编码了,测试同学同时把want.fail()方法改成具体的校验点。

TDD第二步:让测试用例跑通

比如针对testAddProductFail_NoProductId()方法,写具体的测试代码和校验点,
对ProductDo的其它字段set相应正确值,ProductId设置为空,调用相应service的AddProduct方法,对返回结果做判断。
测试同学一一完善各个测试用例。。。

在这一步骤中,由于测试点校验部分需基于接口内部实现定义ok,所以测试可能仍会滞后开发,但项目中接口数肯定是有很多的,所以每开发完一个接口,测试就可以立马写几个测试用例,并行度依然较高,这一点也充分体现了测试向前,把可以做的都提前做掉了

在hudson中每天运行持续集成,观察test的成功个数曲线,正常的趋势是:先一路上升,后逐渐平坦,最后稳中有升。

TDD第三步:开发优化代码

当所有的测试用例都pass,那么产品方提出的业务需求基本满足了,自动化测试case的基本保障也已经建立了。这个阶段,测试同学去做后续各种工作了,那么开发同学的时间资源也宽裕了,回头审视优化自己的代码,有自动化回归保障,重构也没那么可怕了,测试的工作也真的发挥了持久价值而不是一次性劳动。后续测试过程中保险起见还是会做一个简单的手工测试回归,但遇到的问题真的非常少了 

三步走完,项目也over了。测试-编码-重构,这个过程做起来并没有想得那么难推进那么痛苦,反而项目组氛围融洽了,大家每天都会为新增的用例数和上升的覆盖率开心,也会为谁提交的代码导致了失败而互相调侃,测试也不用婆婆妈妈跟在后面催了。。

三.心得

TDD模式下自己的几点体会
1.测试向前,参与度更高。传统方式下,测试在项目前期完成tc设计评审后,只能空置等开发完成代码,部署环境后才能开始测试。更深入来说,不了解开发进度,不了解具体实现,更无从谈起指导开发过程。TDD则让测试全程参与到项目过程中,也能通过接口数和覆盖率变化去量化了解度量项目进度;

2.对需求变更的响应度更高。当有需求变更,需要增加或者变更接口时,修改了代码只要保证测试用例通过,就可以提交了,而不一定要启动环境去验证。

3.持续集成和TDD是绝配。看着hundson上的测试用例渐渐变绿,直到某一刻整个工程都变蓝,再看着代码覆盖率由30%到50%到。。正能量和成就感会持续递增。。

如果再集成上次web组周会上傅雷同学分享的eXtreme Feedback Panel 插件,弄个大的液晶面板显示到项目组成员的眼前,那每天的工作就更有奔头了^_^
  评论这张
 
阅读(597)| 评论(5)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2016