理解需求说明书

上一篇 / 下一篇  2007-09-13 19:24:05 / 个人分类:测试经验

说明:本文是关于测试基础知识的一些拓展。

摘要:很多时候,我们没有完全理解需求说明书就匆忙开始了我们的测试工作,本文主要说明了如果对需求说明书不理解会导致的严重后果,以及如何有效的理解需求说明书。

 

现在你开始进入一个项目进行你的测试工作了,你参加了需求评审会议,知道了些项目的背景,得到了项目的需求说明书,从需求说明书开始你的测试工作。

或许你觉得你手上的需求说明书很差,你不想去看,你觉得你可以在系统真正出来以后,根据系统,你可以很容易的设计出测试用例,或者,你可以不用测试用例就能进行测试。如果你这么想,那么你肯定不会去设法理解需求说明书,也不会对你将要测试的需求说明书描述的系统有完整的,清晰的认识,或许你依旧可以根据模板做出测试计划,设计出测试用例,你的这些测试准备工作,可能也会通过评审,因为公司的评审并不严格或者其他的原因。好了,你这样做了,你知道这样做会有什么后果吗?

你也知道的,需求说明书是产生bug的主要原因,很多缺陷都可以追踪到需求说明书的不完整,不正确,变动多上面,那么你对需求说明书没有认真的检查,你肯定会遗漏很多的缺陷,你大概也知道如果在项目后期修改bug的费用比修改在需求说明书中的缺陷要高多少吧。

你没有理解需求说明书,对程序很多功能都没有详细的考虑,你能保证你看着系统就可以完全理解整个系统,大概不能吧,很多细节的内容,你还是需要对照需求说明书去理解,可是,你在检查需求说明书的时候都不去认真看它,现在,要测试了,测试任务可能很紧,你还会去看它吗,你看它的时候能够理解吗?肯定不能,那么你就要有人来明确告诉你系统是怎么回事。

好了,这个时候,你可能会求助产品经理,可能会求助项目经理,可能会求助程序员,但是,你要知道,如果你有很多的问题去问,你没有这么多时间,他们也没有这么多时间,你的问题能全部解决么?就算你的问题不多,可是你在这个时候去问他们关于需求的问题,你觉得他们会乐意解答吗?他们会认为,你没有做好你本来应该做好的事情,他们会对你敷衍,因为这不是他们这个是要的工作,他们这个时候的工作是编码或者是解决bug或者是其他,但绝对不是回答你关于需求的问题。

你的问题很大程度上不会被完整,准确的解决,可是你还是要测试,因为这是你的工作。因为你对整个系统的理解存在问题,你肯定会遗漏很多的测试点,你也会报告很多的无效bug,你还会无法判断你测试到的现象是系统特色还是bug,你知道这个时候你会有哪些问题么?

你遗漏了bug,会导致系统的不稳定,或许严重的,会导致整个系统的崩溃,你的工作没有做好,领导会找你的责任。你报告了许多无效的bug,开发人员对你的能力开始怀疑,对你的信任开始降低,你报告的bug他们不再关注,你会有很多未解决的bug等着你去跟踪。你无法判断你测试到的现象是系统特色还是bug同样会导致前面的两个问题。现在,你知道你的问题的严重性了吧。

以上所有的问题,仅仅是你在本来应该做事情的时候想当然的认为在以后可以解决而没有做,测试没有任何的假设,该你做什么你就应该做什么。

那么,如果你对需求说明书不了解,或者说明书不够详细,或者你认为需求说明书很差,你该做什么。

首先,不要假设说明书上的所有内容都是正确的,也不要等到程序发布以后再根据程序去理解需求说明书,然后去设计测试。你手上有需求说明书,你就要努力的去理解他,因为这是你这个时候的工作,如果你在理解需求说明书的时候有困难,你可以寻找相关的人来帮助你,可能是需求说明书的作者,也可能是项目经理,或者是相关的程序员,只要你在这个时候寻求帮助,他们肯定会乐意帮助你的。在这个时候,你就要首先弄明白需求说明书的内容,因为,你后面的测试工作的展开,比如测试需求,测试用例,测试计划都是依照需求说明书的,如果你不理解测试用例,你就不能准确估算你的测试工作量,你也不能详细的设计你的测试策略,还有你的测试用例。

其次,努力获得和你要测试的项目相似的已经成型的系统,然后认真去研究它。(待续)


TAG: 需求 需求说明书 测试 测试经验

 

评分:0

我来说两句

Open Toolbar