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

ningzi0315 · 发表于 2009-7-30 16:28:07

当前项目采用的敏捷开发模式，下面是我对的敏捷测试理解和建议：

　　1. 验证需求和设计

　　在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试，不要等待到功能完全做好才开始。

　2. 测试计划，测试用例

　　2.1 编写计划、测试用例

　　在敏捷开发的过程中由于是根据每个user story来估算时间的。开发人员将对本次迭代所需要的完成的user story进行评估。测试人员可以驱动开发人员来写story，来确定每个user story的优先级。不过这中间存在一点，开发人员常会估算时间过少，引起版本无法按时发布须进行加班才能进行发布。主要原因是由于版本更新很快，任务的时间都是以小时来进行估算的。开发人员一般会忽略掉开发以外的时间，比如开发中遇到问题的时间，开会，给其他成员提供帮助的时间，等等。所以非常建议大家在估算时间上能充分的考虑到以外的因素，　　测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例。测试的这两个需求和设计也要被项目经理和开发人员审核。

　　2.2 测试用例的审核
　为使开发人员能参与到Test Case的评论中来，以保证Test Case的质量和可行性，确保测试工作的顺利进行，让开发人员迅速地了解测试的重点并给出相应的意见和建议，测试人员在出 Test Case的同时，应出一份相关的说明书，其中注明Test Case已覆盖了哪些特性，具体每个特性对应的Test Case的编号，这样在测试经理和PM对Test Case进行评论的时候，能够对Test Case的覆盖率一目了然，对覆盖率不足的地方能够及时给出意见。
　　在迭代后期测试要抽时间更新测试用例。
　　2.3 测试用例的维护
　　在执行测试阶段中，测试人员需要对已有的测试用例进行及时的维护。通常以下两种情况下要新增一些测试用例：一是对于当初测试设计不周全的领域，二是对于外部的Bug，没有被现有测试用例所覆盖。当产品的功能设计出现更改时（敏捷项目中功能设计的更改频繁），所涉及的测试用例也要相应地修改，使测试用例保持和现有的功能需求同步。
　　

li373935562 · 发表于 2011-6-14 16:18:30

本人以前的公司也是使用敏捷模式，最大的问题第一在于我们的项目如何进行验收，换句话说，我们欢迎客户变更需求，但是变更到什么程度或者软件做到什么程度算完成了。第二在于人员的变动，版本的更新设计文档没有跟上，加上人员的离职某种程度上造成项目的拖延。

ningzi0315 · 发表于 2011-3-27 17:46:01

Macromedia Dreamweaver MX 2004 注册码：
( 1) WPD700-51105-36894-18582
( 2) WPD700-50006-04894-82816
( 3) WPD700-54808-85794-70521
( 4) WPD700-51701-14294-38025
( 5) WPD700-51109-38394-17786
( 6) WSD700-54620-41863-18076
( 7) WSD700-59769-11800-18076
( 8) WPD700-52406-21894-18076
( 9) WPD700-58068-81856-18076

Macromedia Dreamweaver MX 2004 V7.01 注册码
注册码 : DWD700-57951-74400-97886

Macromedia Dreamweaver 2.0
注册码 : DWW200-09785-18274-81630

Macromedia Dreamweaver 3.0
注册码 : DWW300-08610-27280-95766,

Macromedia Dreamweaver 4.0简体中文版
注册码 : DWW400-00470-47289-60450

Macromedia Dreamweaver 4.03 简体中文正式版
注册码 : SNWW400-00470-47289-60450

xiaoka · 发表于 2011-2-14 14:00:07

人气不足啊。。。。。

xiaoka · 发表于 2011-2-13 17:00:54

我们公司也在用敏捷测试，但是测试的过程和以前的没什么区别，只是将case放在相应的iteration里面了。敏捷方法对开发的挑战应该更高。个人观点，欢迎怕转。

ruirui。 · 发表于 2011-1-12 14:50:17

落后了

beryl_lin · 发表于 2009-8-21 18:02:23

原帖由 unholyalliance 于 2009-8-12 15:46 发表
LZ公司还在招人么？好想尝试一下敏捷测试是什么感觉的。

感兴趣的话，不妨试试ThoughtWorks，专门做敏捷的公司，http://www.thoughtworks.com.cn

可以直接联系我哦

woza · 发表于 2009-8-17 09:34:44

我意思是，手工测试的test case可以不写。

TDD做法是，在coding前，先设计测试。一般都是用automation实现的。这种测试尽可能不依赖于界面，因为界面不稳定，而且执行效率慢。所以设计出来的测试，都是以输入输出数据为主。当然，你也可以把这个理解成test case。

xu_coco · 发表于 2009-8-17 09:19:13

原帖由 woza 于 2009-7-31 21:44 发表
不知道LZ是不是用Scrum的方法。如果TDD做到好的话，可以不写test case。TDD的输入输出本身就是一个非常好的功能说明书。对于外部bug，也写一个automation test就行。
当然，实践起来可能有些困难。仅供参考。

不知道这位同学说的TDD的输入输出是指什么？为什么可以不用写Test Case？麻烦给解释一下吧。
目前我们刚开始使用敏捷开发，还处于摸索阶段。请多指教。

ningzi0315 · 发表于 2009-8-14 13:17:23

楼上的，招人的事我就不清楚了，不过现在国内比较大的公司都在用敏捷。你可以去试一下。。。。

unholyalliance · 发表于 2009-8-12 15:46:46

LZ公司还在招人么？好想尝试一下敏捷测试是什么感觉的。

随风飘 · 发表于 2009-8-12 15:33:39

我们用敏捷后就从来没加过班～～敏捷真好用！

ningzi0315 · 发表于 2009-8-4 15:21:47

楼上的说得很好，我们的己经慢慢的把敏捷思想惯穿到项目内的每一个成员。在以后的项目中相信会做得更好。

woza · 发表于 2009-8-2 15:05:39

用XP一样可以做TDD。
还有估算story point的时候，应该是整个Team一起估计的。不是开发人员说了算的。
如果一开始估计的不准，那么做Retrospective的时候，应该提出来，下一次估的时候就要考虑额外的情况。我们一开始也估不准，过几个Iteration就好了。
加班肯定是不加的。需要加班的话就失去了敏捷的意义。
如果测试来不及完成，那程序员也应该帮助测试。因为team里面所有的任务都应该是大家合作完成的。

ningzi0315 · 发表于 2009-8-2 00:45:39

我们用的是XP的方法，Ｓcrum这个暂时还没有用到，需要时间，还需要经验的积累。

woza · 发表于 2009-7-31 21:44:49

不知道LZ是不是用Scrum的方法。如果TDD做到好的话，可以不写test case。TDD的输入输出本身就是一个非常好的功能说明书。对于外部bug，也写一个automation test就行。
当然，实践起来可能有些困难。仅供参考。

		自动登录	找回密码
密码			(注-册)加入51Testing

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

相关帖子

回复 9# 的帖子

站长推荐 /1