敏捷项目的软件测试
我们的项目实行敏捷已经近两年了，关于敏捷我相信大家已经比较熟悉了，我今天就先谈谈在敏捷的项目里如何实行测试的工作。
敏捷的项目对测试的影响
文档少，因此难以只是依赖文档来设计测试。
短迭代，需要更短的时间完成测试的工作。
频繁的变化，需要测试更具有探索性和适应性。
敏捷项目的正确测试观念
项目是以结果为导向的，所以测试同样是结果导向。
不以发现缺陷多少为目标。
以不断提高软件质量为目标。
测试人员的作用是帮助开发人员不断提高软件的质量，是协助性的。
测试人员不是批判性的。
测试人员能够尽可能的做能够做的工作，尽可能的早工作。
“等待”在敏捷开发、敏捷测试范畴里已是一种错误概念。
敏捷测试的管理
敏捷项目的测试没有严格的角色。人人都是测试。
以测试任务为导向。测试任务即可以是开发来做，也可以是测试人员来做。
相同的质量目标。开发和测试有着同一个质量目标，因此也承担着同样的责任。
关注质量的提升，测试周期与开发同步。
要有全局观，不只是专注于发现缺陷。
为回滚做准备，本次迭代发布失败，可安全回滚至旧版本。
分享测试知识。
建立缺陷库，指导开发人员避免再次发生同样缺陷。
敏捷测试的执行
关注和推动单元测试。
持续改进自动化测试（因为软件的变化，已经对产品的深入了解）
短文档（测试用例可以不写，测试计划列测试点，测试类型，质量标准即可）。
对新增的或者引起变化的地方（可询问开发人员协助）采取探索性测试。
对稳定的部分添加自动化测试。
我们的项目之前的测试开发比例是1比5，质量基本达到客户的要求，为什么1比5可以，因为我说过，开发人员
是可以做测试的工作的。现在觉得唯一有不足的地方是对稳定的地方进行自动化的回归测试。还有，我希望在
自动化的探索性测试上有所进步。
最后，我还说一点是，我看到很多项目靠加班，不会休息的团队是不健康的团队。其实，项目往往不是短期行
为，通常一个产品的至少需要半年努力和投入，长
时间的超负荷运转会使得工作效率低，身体透支等严重后果。项目中后期往往强度会比前期更大，这个时候，
人员倒下和效率低不是一件好事情。所以，如果你的项目还要长期发展，应该帮助团队认识到轻松的团队氛
围，张弛有度的工作安排是项目成功的最好方式。
棒 深有同感 很赞同楼主地说法，目前所在地项目是在做迭代开发，测试根本没有时间写完整的用例，只能边挖掘测试点边测，探索性测试比较多
页:
[1]
