需求频繁变更的情况下,如何做测试
TAG:
- 引用 删除 ccc11yyy / 2007-02-01 09:00:26
-
对于这段话有同感。" 2、微软的测试就是分成2个大的阶段的:当需求不稳定时,测试目的是尽量发现大的bug,帮助需求尽快稳定下来;等需求稳定了之后,再进行充分的测试。"
在需求变更频繁的时候,可以先进行使需求先稳定下来的测试,然后再进行充分的测试。对于已经稳定的部分也可以延后再做充分测试,先保证主要的功能可用即可。做之前先跟测试经理、项目经理分析清楚利弊即可,一般都会同意的(我的经验)。这样可以给测试争取更多的时间,来进行充分的测试,也避免了压力带来的负面效应和返工(需求变更后重测)造成的浪费。
- 引用 删除 笨笨熊 / 2007-01-18 19:08:52
-
楼主说的真好,有时我们为了公司对于测试重视度不够而导致项目改变上的忽视而恼怒,其实想想愤怒先放到一边,最重要的还是想到解决问题的方法。
楼主这句话说的很对“公司没有,不代表我们自己没有”,对于测试新手来说,除了运用需求跟踪矩阵来规范自己的测试工作以外,还不要一味的追求太过正规的形式,这样反而会让自己更累,只要能做到够用、有效就好
- 引用 删除 tails82 / 2007-01-17 21:19:01
-
测试经理安排任务不合理,那是常有的事情。任务安排是一项高要求的工作。对计划的制定者,不仅要求是个技术专家,更要有丰富的项目经验。但是这样的人,还是比较少的。尤其在测试行业。
项目经历也许对测试的了解也比较有限,往往认为测试应该比开发来得快。我们要做的,就是反映客观事实。我觉得没什么不好说的,只要你有能证明客观事实的数据,那么完全可以和测试经理或者项目经理谈一下。
下面给出一些参考数据:
1.平均每条用例的执行时间
2.每提交一个缺陷所要花费的时间
3.每个版本需要直径的用例数量
4.由于开发提交版本的延误,造成了你多少等待时间
5.由于需求的变化,造成了你多少个用例需要修改。
总之,一切你觉得会消耗你时间的因素都可以列出来。数据一定要是具体的,是多少就是多少,而不是“很多”,“大部分”。
这样虽然会耗费点精力,但是客观事实的说服力,还是很吸引人的。