Scrum模型的项目中，如何管理测试用例？
公司新开始一个项目，第一次使用scrum模型。 如果像以往一样详细编写测试用例在执行，时间来不及，测试就成了“不敏捷”的拖累。 只写测试项，不写详细用例，又怕测试失控。哪位高人可以指点一下：
1，Scrum 或者一般的敏捷模型中，测试用例的颗粒度应该怎样的？
2，测试用的记录，管理方式。如何使测试用例全面而又不消耗太多时间去编写和维护，能与开发保持相同的节奏？ 1、测试用例的粒度是项目自己控制的，没有具体的粒度划分，只要适合项目就可以啦
2、scrum中每个迭代前期测试人员可以编写测试用例，迭代中后期执行，补充修改测试用例，并且设计测试用例时可以发现需求和测试点，千万不能因为项目紧急测试用例就抛弃，后期会带来很多问题的 与敏捷开发配合的，应该有另一个概念，叫“测试驱动”。就是测试在前期介入，开发未完成的时候就根据需求写测试用例，开发人员根据测试需求、测试设计、测试用例进行代码设计等。这样就要求测试人员对需求理解比较深入，这样的话由于是前期就开始写测试用例，那一定是写出测试需求，测试设计，不太会深入写到非常详细的测试用例。敏捷开发的话，测试用例可以放在需求小组讨论之后进行，先写出测试要点，测试设计，页面操作等细致的用例要看需求是否足够详细了。 楼上说的对，“scrum中每个迭代前期测试人员可以编写测试用例，迭代中后期执行，补充修改测试用例，并且设计测试用例时可以发现需求和测试点，千万不能因为项目紧急测试用例就抛弃，后期会带来很多问题的”
每一个模型都有自己的特点，不能因为敏捷了就放弃测试应该有的步骤，测试用例的设计和执行是每一个模型中都必须包括的 几个问题，可能楼主还没想透。
1. test case用来干嘛？为什么要有test case？ 这个基于你的团队人员构成，知识水平，和人员流动性。如果测试团队相对稳定，技术水平高，那么你的测试用例可以写的越简单越好，本身用例就是一种测试人员和项目成员的沟通媒介。极端点来说，如果大家配合默契，就算用符号也能是测试用例。
2. test case？既然楼主提到了是test case，不是check list，那么就应该想到测试和检查的区别。
3. 至于控制，通过简单的审核测试用例来控制其实成本会很高，楼主不妨设计几个有效指标，通过其来控制质量。比方说测试工时和发现bug的数量。 几个问题，可能楼主还没想透。
1. test case用来干嘛？为什么要有test case？ 这个基于你的团队人员构成， ...
marsyu 发表于 2012-10-9 15:02 http://bbs.51testing.com/images/common/back.gif
有个疑问，请教下，如果不进行用例审核，如何确认是用例问题，还是测试人员疏忽引起的，。再者，在这么短的时间内出了问题，即使在发布前发现修改起来也会影响发布时间,更不要说发布后发现。这个问题有什么比较好的解决方式吗？
您说到可以通过指标来控制质量，能否说的更细点？ 本帖最后由 marsyu 于 2012-10-11 10:41 编辑
有个疑问，请教下，如果不进行用例审核，如何确认是用例问题，还是测试人员疏忽引起的，。再者，在这么 ...
kingylq 发表于 2012-10-9 16:15 http://bbs.51testing.com/images/common/back.gif
事后的review不如事前的头脑风暴，根据我的经验test case很少有人会认认真真的review，因为review其实就是执行一遍。 与其如此，不如将测试团队或者邀请开发，BA，PM一起坐下来，让tester将自己的测试设计的思路告诉大家。比方说对这个requirement，会怎么设计用例，如果做到覆盖。
关于你说的问题的定位，我不太明白，无论是用例还是测试的疏忽，其实都是归根结底都是团队的问题。
另外你可以google一下test metric，http://www.mindlance.com/documents/test_management/testing_metrics.pdf。 本帖最后由 kingylq 于 2012-10-11 16:58 编辑
回复 7# marsyu
我主要是想表达，如何追踪问题的根源、解决问题，如何提高质量、降低产生问题后的成本。
在2-3周为一个周期内，人员安排很极限，只要周期开始，每个人都要重复领任务\完成任务的循环，直至任务结束，这个情况下，头脑风暴是否有可行性呢？
我一直沿用审查用例的模式，因为我认为这是最能节省时间、提高质量的一种方式，且更容易在前期寻找出测试遗漏的地方。但是也是一直困扰着我，虽然这种模式可以节省部分人的时间，但是工作量却集中在某小些人的身上。在审查过程中，会占用这些人很多时间，直至用例通过。这点非常不好。
团队一直存在的人员问题，可能这是没办法解决的。所以也像楼主一样，想寻找更适合的方式。
呵呵，能力有限，那份英文文档看的很吃力，还没看完。感谢您提供的文档。 1.粒度的大小应该根据业务价值去决定，如果一个功能很重要，用例的粒度就要很细，如果这功能业务价值不高，那么用例的粒度就可以粗一点。
2.使用Testlink对测试用例进行管理，可以自动生成测试报告，清晰的看到每一个测试用例。
给你个建议，手工维护测试用例长远看并不是办法，尽早实现自动化回归测试，那么每一个逻辑就是测试用例，而且测试覆盖率也能大大提高；另外Scrum里面提倡测试提前，在Scrum团队中每一个开发人员都应该是测试人员，他们也可以维护测试用例，记着测试用例不是一定要由测试人员来写的 回复 6# kingylq
测试用例的质量可以通过交叉执行测试用例来保证，testA 写的测试用例testB来执行测试，testB的测试用例testA来执行。test case 完成后最好是测试人员内部先评审通过然后交给需求评审，现实情况中需求对test case 只看大概，不注重覆盖面和test case 质量，建议先inner test group 先评审test case，后交叉执行测试用例
页:
[1]
