51Testing软件测试论坛

标题: Scrum模型的项目中,如何管理测试用例? [打印本页]

作者: meetingh2000    时间: 2012-10-8 09:43
标题: Scrum模型的项目中,如何管理测试用例?
公司新开始一个项目,第一次使用scrum模型。 如果像以往一样详细编写测试用例在执行,时间来不及,测试就成了“不敏捷”的拖累。 只写测试项,不写详细用例,又怕测试失控。
哪位高人可以指点一下:
1,Scrum 或者一般的敏捷模型中,测试用例的颗粒度应该怎样的?
2,测试用的记录,管理方式。如何使测试用例全面而又不消耗太多时间去编写和维护,能与开发保持相同的节奏?
作者: MS苏某某    时间: 2012-10-8 16:38
1、测试用例的粒度是项目自己控制的,没有具体的粒度划分,只要适合项目就可以啦
2、scrum中每个迭代前期测试人员可以编写测试用例,迭代中后期执行,补充修改测试用例,并且设计测试用例时可以发现需求和测试点,千万不能因为项目紧急测试用例就抛弃,后期会带来很多问题的
作者: 柳叶    时间: 2012-10-9 09:43
与敏捷开发配合的,应该有另一个概念,叫“测试驱动”。就是测试在前期介入,开发未完成的时候就根据需求写测试用例,开发人员根据测试需求、测试设计、测试用例进行代码设计等。这样就要求测试人员对需求理解比较深入,这样的话由于是前期就开始写测试用例,那一定是写出测试需求,测试设计,不太会深入写到非常详细的测试用例。敏捷开发的话,测试用例可以放在需求小组讨论之后进行,先写出测试要点,测试设计,页面操作等细致的用例要看需求是否足够详细了。
作者: wuliangye    时间: 2012-10-9 10:13
楼上说的对,“scrum中每个迭代前期测试人员可以编写测试用例,迭代中后期执行,补充修改测试用例,并且设计测试用例时可以发现需求和测试点,千万不能因为项目紧急测试用例就抛弃,后期会带来很多问题的”
每一个模型都有自己的特点,不能因为敏捷了就放弃测试应该有的步骤,测试用例的设计和执行是每一个模型中都必须包括的
作者: marsyu    时间: 2012-10-9 15:02
几个问题,可能楼主还没想透。
1. test case用来干嘛?为什么要有test case? 这个基于你的团队人员构成,知识水平,和人员流动性。如果测试团队相对稳定,技术水平高,那么你的测试用例可以写的越简单越好,本身用例就是一种测试人员和项目成员的沟通媒介。极端点来说,如果大家配合默契,就算用符号也能是测试用例。
2. test case?既然楼主提到了是test case,不是check list,那么就应该想到测试和检查的区别。
3. 至于控制,通过简单的审核测试用例来控制其实成本会很高,楼主不妨设计几个有效指标,通过其来控制质量。比方说测试工时和发现bug的数量。
作者: kingylq    时间: 2012-10-9 16:15
几个问题,可能楼主还没想透。
1. test case用来干嘛?为什么要有test case? 这个基于你的团队人员构成, ...
marsyu 发表于 2012-10-9 15:02


有个疑问,请教下,如果不进行用例审核,如何确认是用例问题,还是测试人员疏忽引起的,。再者,在这么短的时间内出了问题,即使在发布前发现修改起来也会影响发布时间,更不要说发布后发现。这个问题有什么比较好的解决方式吗?
您说到可以通过指标来控制质量,能否说的更细点?
作者: marsyu    时间: 2012-10-11 09:59
本帖最后由 marsyu 于 2012-10-11 10:41 编辑
有个疑问,请教下,如果不进行用例审核,如何确认是用例问题,还是测试人员疏忽引起的,。再者,在这么 ...
kingylq 发表于 2012-10-9 16:15


事后的review不如事前的头脑风暴,根据我的经验test case很少有人会认认真真的review,因为review其实就是执行一遍。 与其如此,不如将测试团队或者邀请开发,BA,PM一起坐下来,让tester将自己的测试设计的思路告诉大家。比方说对这个requirement,会怎么设计用例,如果做到覆盖。

关于你说的问题的定位,我不太明白,无论是用例还是测试的疏忽,其实都是归根结底都是团队的问题。
另外你可以google一下test metric,http://www.mindlance.com/documen ... testing_metrics.pdf
作者: kingylq    时间: 2012-10-11 16:43
本帖最后由 kingylq 于 2012-10-11 16:58 编辑

回复 7# marsyu

我主要是想表达,如何追踪问题的根源、解决问题,如何提高质量、降低产生问题后的成本。

在2-3周为一个周期内,人员安排很极限,只要周期开始,每个人都要重复领任务\完成任务的循环,直至任务结束,这个情况下,头脑风暴是否有可行性呢?

我一直沿用审查用例的模式,因为我认为这是最能节省时间、提高质量的一种方式,且更容易在前期寻找出测试遗漏的地方。但是也是一直困扰着我,虽然这种模式可以节省部分人的时间,但是工作量却集中在某小些人的身上。在审查过程中,会占用这些人很多时间,直至用例通过。这点非常不好。

团队一直存在的人员问题,可能这是没办法解决的。所以也像楼主一样,想寻找更适合的方式。

呵呵,能力有限,那份英文文档看的很吃力,还没看完。感谢您提供的文档。
作者: crxwat    时间: 2012-10-17 17:56
1.粒度的大小应该根据业务价值去决定,如果一个功能很重要,用例的粒度就要很细,如果这功能业务价值不高,那么用例的粒度就可以粗一点。
2.使用Testlink对测试用例进行管理,可以自动生成测试报告,清晰的看到每一个测试用例。

给你个建议,手工维护测试用例长远看并不是办法,尽早实现自动化回归测试,那么每一个逻辑就是测试用例,而且测试覆盖率也能大大提高;另外Scrum里面提倡测试提前,在Scrum团队中每一个开发人员都应该是测试人员,他们也可以维护测试用例,记着测试用例不是一定要由测试人员来写的
作者: MS苏某某    时间: 2012-10-25 12:56
回复 6# kingylq


    测试用例的质量可以通过交叉执行测试用例来保证,testA 写的测试用例testB来执行测试,testB的测试用例testA来执行。test case 完成后最好是测试人员内部先评审通过然后交给需求评审,现实情况中需求对test case 只看大概,不注重覆盖面和test case 质量,建议先inner test group 先评审test case,后交叉执行测试用例




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2