软件质量该如何做？
上一篇 / 下一篇 2012-05-04 09:25:55 / 个人分类：杂谈
● 程序员是乐观的，觉得自己写的程序没什么问题。
● 程序员没有时间做测试。
我觉得提高质量，最重要的是提高质量意识，只要你肯花时间，零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）。
大家都知道单元测试是非常花时间的，所以我们把单元测试的时间主要花在测试业务逻辑上（Service）。在单元测试的过程中，根据不同的情况我们采用了以下四种方式：
1）结对单元测试，由结对的人帮助你写单元测试。
2）边实现边写单元测试，项目时间比较充裕的时候，自己在实现的过程中写单元测试。
3）测试驱动。业务逻辑比较复杂的时候。
4）补写单元测试，这出现在项目比较紧的时候，或者因单元测试没有覆盖的流程所引起的BUG。
我们追求的是单元测试的行覆盖率达到70%，目的是希望单元测试能覆盖大部分业务逻辑。
3、团队合作
很多时候质量低下，源于没有时间，比如团队中有的同学实现某个功能发生了延迟，那么他肯定没时间开写单元测试，帮别人做CodeReview，那么这个问题就应该在晨会的时候知会团队成员，由其他团队成员帮助你去完成这些事项，因为我们是一个团队。
4、冒烟测试
提测前我们会进行一次冒烟测试，目的是测试核心流程是否正常，因为我们要求冒烟测试必须一次性通过，所以在冒烟测试前，程序员必须按照测试的check List做最后一次检查，这样可以调动大家重视质量的积极性。
5、项目总结
在项目总结的时候，针对于BUG我们会做如下分析
● 如果项目BUG比较多，那么大家一起分析原因。一般前端功能比较多的，BUG会多。后端功能，BUG会比较少。有的时候项目比较紧，以上有些流程没有完全走到，会引起很多BUG。
● 如果某个成员BUG比较多，那么由他自己先分析下BUG产生的原因，然后加到下次Code Review和自测的check List里。
● 重复BUG的分析，出现重复BUG是比较严重的问题，这一般都是由于重构引起的。
● 单元测试可避免的BUG分析。
我们使用一套闭环的方式来保证项目质量：
审查（按照checkList进行需求，设计和代码的审查）- 测试（自动化，冒烟和功能测试）-总结（总结出checkList）
那么再回答下开篇的几个问题
● 问：程序员是乐观的，觉得自己写的程序没什么问题。
答：通过以上这些流程提高质量意识。
● 问：程序员不愿意做测试，做测试没有成就感。
答：通过写自动化测试脚本来增加程序员的成就感。
● 问：程序员没有时间做测试。
答：通过团队合作来弥补某些成员没时间做测试的问题。
TAG:
我的栏目
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | |||||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 | |||
| 9 | 10 | 11 | 12 | 13 | 14 | 15 | |||
| 16 | 17 | 18 | 19 | 20 | 21 | 22 | |||
| 23 | 24 | 25 | 26 | 27 | 28 | 29 | |||
| 30 | |||||||||
我的存档
数据统计
- 访问量: 3278957
- 日志数: 1640
- 建立时间: 2011-12-07
- 更新时间: 2019-12-24
