敏捷开发过程中测试经验总结3

ningzi0315

3 控制中间版本
　　为更好地保证软件质量，规避风险，必须加强对中间版本的控制。例如，项目要求或者计划周五要提交版本，则周三一定要提交一个中间过程的版本进行测试，也就是控制中间版本，避免所有的工作都压到后期最紧急的时候去完成。以前的项目中出现过项目前期很轻松，到后期bug越来越多，开发人员和测试人员都异常忙碌，经常加班的情况。为减少后期工作量，规避风险，开发进行Daliy Build，或者按照完成一个特性就进行一次build，针对这个特性进行测试，这样就可以有效避免后期bug越来越多的状况发生，后期工作量也就会相应减少，项目的质量也会更有保证。这一点在我们的项目中己经做得很好了，在正式出版本之前出一个验证版本来进行测试。
3.1发布版本前编写发布记录
在每次发布版本之前，测试人员要根据待发布的版本情况编写发布记录，使客户对发布的版本情况一目了然。发布记录主要包括三方面的内容：当前特性，新特性，存在的问题。其中，当前特性部分写明此版本修复了上个版本中存在的的哪些比较大的bug；新特性部分写明此版本新增加了哪些功能；存在的问题部分写明此版本尚存在哪些比较大的问题，有待下个版本改善；或者列出需求不太明确的地方，有待客户给出明确答复意见，在下个版本中完成。
　4. 项目开发末期开展“bug大扫除”
　　在项目开发的末期，可以开展“bug大扫除”活动。划出一个专门的时间段，在这期间所有参与项目的人员，集中全部精力，搜寻项目的Bug。注意以下要点：
（1）尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益；
（2）要鼓 励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug；
（3）为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评 出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。
（4）可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。

敏捷开发思想在项目中的运用
1、
每日站立会。每天早上九点钟准时开晨会，每个人员有大概3分钟时间来说明一下，昨天做了什么，存在什么问题，今天要做什么。每天的晨会控制在20分钟以内。如有存在争议的问题都是会后单独留下来与项目经理、架构师来进行沟通。
2、
TDD（测试驱动开发）在未做整个项目未编码前也就是在有了详细设计以后，就可以先写好测试用例，再写代码。这样做的好处是：开发人员写出来的代码都是可以工作的。为什么这么说呢？在写好代码后，可以马上用开始写的测试用例来进行，代码的干炼测试才可通过。在这里有引用自动化测试，目的就是在于在以后开发的多个版本都可以用上。这样就节省了不少人力。

woza

原帖由 ningzi0315 于 2009-7-30 16:28 发表
3 控制中间版本
　　为更好地保证软件质量，规避风险，必须加强对中间版本的控制。例如，项目要求或者计划周五要提交版本，则周三一定要提交一个中间过程的版本进行测试，也就是控制中间版本，避免所有的工作都压到 ...

有可能的话，只要开发完成一个功能，就开始测试这个功能，未必要等到周三。
对于已知的bug，最好不要等到开发都完成了，再去修复。我们的做法是，每个team在开发过程中发现的bug，一概自己修掉。不然的话Story不能算done。如果是team外的人发现的问题，Product Owner,QA mgr,Dev mgr会一起review。严重的bug会直接分配到team里，并把优先级设到最高。team必须先修bug，如何才能开发新功能。

所谓持续集成的目的就是要尽快发现问题，如果发现了问题却不立刻修复，那就失去持续集成的价值了。而且会使done definition的作用大大缩水。

ningzi0315

楼上的高见，有条件我们会改进的。。。

随风飘

学习了～～

beryl_lin

原帖由 woza 于 2009-7-31 21:52 发表


有可能的话，只要开发完成一个功能，就开始测试这个功能，未必要等到周三。
对于已知的bug，最好不要等到开发都完成了，再去修复。我们的做法是，每个team在开发过程中发现的bug，一概自己修掉。不然的话Story不 ...

嗯，敏捷嘛，就是要什么都敏捷，测试要尽早，bug修复要尽快，不然失去敏捷的意义了。

Camael

去了解下BDD吧，那样你会收获更多。

xmy942002

楼主是微软的吧

hust208

好东西就要共享,谢谢~~!

yxf287877978

学习