学习、应用敏捷开发一年多，也写了一些笔记，想结识朋友一块交流，解决办法

2012-03-19

学习、应用敏捷开发一年多，也写了一些笔记，想结识朋友一块交流，我把自己的在学习和应用中的一些心得写到博

学习、应用敏捷开发一年多，也写了一些笔记，想结识朋友一块交流，
我把自己的在学习和应用中的一些心得写到博客里了，希望感兴趣的朋友看看我写的东西，向我开炮，评论下，交流下。我的博客是：http://blog.csdn.net/jianfengqu

我现在学习没有人一块交流，好可怜啊！

[解决办法]
勤写读书笔记是个好习惯，
[解决办法]
以前在学校看过uncle bob的那本经典敏捷书籍.
写过一篇关于敏捷的文章, LZ给点评价
http://blog.csdn.net/pony_maggie/archive/2010/01/29/5270506.aspx
[解决办法]
大家一起交流好，建议LZ抛出一个或几个问题，在帖子里讨论才有针对性。
否则帖子变成了博客广告了
[解决办法]
好呀，共同学习了，呵呵
[解决办法]
一直沒有機會實踐，不過頂下
[解决办法]
共同学习，我们现在的项目就是采用敏捷开发模式，如敏捷下的测试如何开展，大家有没有什么好的建议？
[解决办法]
测试用例太详细确实太费时间，这个要把握一个度。但这个度却要视团队的开发水平而定。
其实敏捷开发非常依赖程序员的个人素质，如果团队的素质不高，敏捷开发最终比瀑布模型更混乱。
[解决办法]

探讨
我们团队中有专门的测试人员，在敏捷开发过程，我建议他们不要写太详细的测试用例。可以只根据系统功能写基本的测试条目（主要是正常流程），而其他细节，包括异常的测试只需要根据测试人员的经验测试就行了（需求上有特殊要求时另当别论），把测试出的问题记录在td上，或直接告诉开发人员，或写清楚重现步骤通知开发人员去修改。因为我知道，就光一个登录窗口的测试用例要写全了，就得写上几十条，这太浪费时间了，里面很多东西其实测试人员根据经验一测就可以了，完全没有必要写成文档。举例：用户名输入框测试，可以写很多条用例：1、为空时系统的反应是什么 2、中文时系统的反应是什么 3、长度大于100时胸膛那个的反应是什么 4、有特殊字符时系统的反应是什么 5、输入正常的字符，如admin时系统的反应是什么。你看，这有必要写出来吗（我见过详细的用例这些内容都会包含），但像前面4个，有经验的测试人员都知道要测，就不需要写出来了。

如果在迭代开发过程中就把使用说明书写完了，那么该文档就可以作为测试人员测试的依据。如果使用说明书没有写，也没有详细的需求（敏捷不建议写详细的需求文档），那么，要求测试人员和需求人员经常沟通，明白需求。
要注意一点：一个迭代里所开发的任务必需在迭代过程中测试完毕，也就是测试人员的工作在迭代中一直进行着，这样的好处是：开发人员刚编写完的程序现在很熟悉，改起来快，尽量不要放在后面的迭代中去。

开发人员自己的单元测试要做，但是，也必需有专门的测试人员来测试，因为人们总是认为自己做的东西没有问题。

[解决办法]
学习中..............
[解决办法]
看来是要做一些分享了啊.
[解决办法]
学习一下，工程实践啊~

热点排行

软件开发

学习、应用敏捷开发一年多，也写了一些笔记，想结识朋友一块交流，解决办法