需求经常变更的初创团队，测试应该如何开展
目前在一个创业团队担任测试，做的项目经常需求大改，有的时候测试用例刚写完不久或者正在写的时候需求就进行变更了，导致之前写的都没用了，想请问一下老司机们在这种情况下，测试该如何有效率的开展？ 一般这种情况出现在小公司的内部业务或小公司外包其他公司的业务会经常出现的情况。若是公司内部的业务经常出现这种情况，建议向项目经理或上层领导说明这种经常需求大变更的弊端，或制定相关需求变更的版本控制的规章制度来制约。。
若是小公司外包其他公司的业务出现需求大变更的情况，一种是已经签了明确的合同说明需求不允许大变更或不允许变更，若变更则合同作废或收取相关的变更费用（这个就是公司其他人去谈了，可以跟上层说一下这种方法）
当然，上一种方法很多时候是走不通的，因为基于客户就是上帝的原则，那么若一个项目经常出现这种大变更的情况，在设计用例的时候，可以提前识别哪些功能会变更的可能性最小，这个变更可能性最小的需求可以进行设计测试用例。
在设计用例的时候可以只写个测试要点，而不用写的特别清晰，也就是测试用例的颗粒度放大，尽可能的减少人员在测试用例设计上的人力资源。同理，在执行用例的过程中，也尽量捡那些变更可能性最小的需求去执行，防止意外嘛。
所以，最后同理了，需求的经常性大变更，最主要的还是客户方或需求方不清楚自已需要的是什么，作为测试，有经验的测试，在熟悉需求的时候，最好能尽可能的吃透用户的需求，把不明确的需求给澄清化，尽量的减少损失！
**********************************
以上是个人的一些小见解，其他看官有不同意见的，请轻拍。 开始不要写用例，先列下测试点，确定后在写 {:3_68:}兄弟，我也是这种情况，我很明白你的痛。 神仙也考试 发表于 2017-8-10 15:25
一般这种情况出现在小公司的内部业务或小公司外包其他公司的业务会经常出现的情况。
若是公司内部的业务 ...
感谢分享，很有收获:lol 哎呦呵呵 发表于 2017-8-11 11:11
兄弟，我也是这种情况，我很明白你的痛。
:handshake jingzizx 发表于 2017-8-10 16:31
开始不要写用例，先列下测试点，确定后在写
好滴
页:
[1]
