首页 >> 知识库 >> 软件测试 >> 正文

软件质量该如何做?

发布时间:[2012-9-6]     来源:51testing     作者:     点击:

  程序员可能都认为质量很重要,但是很多项目质量都不是很高,原因可能是

  ● 程序员是乐观的,觉得自己写的程序没什么问题。

  ● 程序员不愿意做测试,做测试没有成就感。

  ● 程序员没有时间做测试。

  我觉得提高质量,最重要的是提高质量意识,只要你肯花时间,零BUG也是很容易实现的,我所在的团队就成功实现了几次零BUG的项目,零线上故障,冒烟测试都是一次性通过。我们一个迭代的周期是两周,通过几个流程来保证质量:

  需求评审(半小时)-设计评审(1小时)-单元测试(1天)-晨会(每日)-代码审查(1天)-冒烟测试(半天)-项目总结(半天)。

  1、Code Review(代码审查)

  在一次迭代中会进行四种Code Review:

  1)自我Code Review,自己写完代码,在自测前进行一次Code Review。

  2)结对Code Review,结对(本文所描述的结对是指两个人一起设计,分开实现代码)的同学使用Tala工具(由我们团队开发的阿里巴巴内部Code Review工具)搜索出你在这个项目中修改的所有文件,然后一个一个审查。

  3)专家Code Review,可能结对的同学Review存在一定的局限性,所以项目经理会对一些核心功能进行Review。

  4)主动Review,团队中有的同学提前完成功能,主动去Review其他同学的代码,这也是团队合作的一种表现。

  代码审查的时间,按照情况有三个时间:每日(有时间的话),提测前2天(主要是这个时间)和提测后(如果项目比较紧,这个很少会出现,有些问题即时测试了也发现不了,必须通过Code Review)。

  2、单元测试

  大家都知道单元测试是非常花时间的,所以我们把单元测试的时间主要花在测试业务逻辑上(Service)。在单元测试的过程中,根据不同的情况我们采用了以下四种方式:

  1)结对单元测试,由结对的人帮助你写单元测试。

  2)边实现边写单元测试,项目时间比较充裕的时候,自己在实现的过程中写单元测试。

  3)测试驱动。业务逻辑比较复杂的时候。

  4)补写单元测试,这出现在项目比较紧的时候,或者因单元测试没有覆盖的流程所引起的BUG。

  我们追求的是单元测试的行覆盖率达到70%,目的是希望单元测试能覆盖大部分业务逻辑。

  3、团队合作

  很多时候质量低下,源于没有时间,比如团队中有的同学实现某个功能发生了延迟,那么他肯定没时间开写单元测试,帮别人做CodeReview,那么这个问题就应该在晨会的时候知会团队成员,由其他团队成员帮助你去完成这些事项,因为我们是一个团队。

  4、冒烟测试

  提测前我们会进行一次冒烟测试,目的是测试核心流程是否正常,因为我们要求冒烟测试必须一次性通过,所以在冒烟测试前,程序员必须按照测试的check List做最后一次检查,这样可以调动大家重视质量的积极性。

关键字: