51Testing软件测试论坛

标题: 理解需求说明书 [打印本页]

作者: 小刀 时间: 2007-9-14 09:52
标题: 理解需求说明书
现在你开始进入一个项目进行你的测试工作了，你参加了需求评审会议，知道了些项目的背景，得到了项目的需求说明书，从需求说明书开始你的测试工作。

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

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

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

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

你的问题很大程度上不会被完整，准确的解决，可是你还是要测试，因为这是你的工作。因为你对整个系统的理解存在问题，你肯定会遗漏很多的测试点，你也会报告很多的无效bug，你还会无法判断你测试到的现象是系统特色还是bug，你知道这个时候你会有哪些问题么？
你遗漏了bug，会导致系统的不稳定，或许严重的，会导致整个系统的崩溃，你的工作没有做好，领导会找你的责任。你报告了许多无效的bug，开发人员对你的能力开始怀疑，对你的信任开始降低，你报告的bug他们不再关注，你会有很多未解决的bug等着你去跟踪。你无法判断你测试到的现象是系统特色还是bug同样会导致前面的两个问题。现在，你知道你的问题的严重性了吧。

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

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

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

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

作者: ycxlove11 时间: 2007-9-14 10:19
需求说明书看来真的很重要啊

作者: wuyuzimu 时间: 2007-9-14 10:26
嗯有很深的体会特别是照着需求文档写测试用例的时候

作者: sony3631 时间: 2007-9-18 16:33
等待下文 sdlkfj2

作者: 小刀 时间: 2007-9-18 17:20
下文我写在了博客，请在这里查看：http://www.51testing.com/spacecp.php?action=spacefiles

作者: lhjtc8257 时间: 2007-10-9 20:18
需求有时候,真的很难看下去啊

作者: lhjtc8257 时间: 2007-10-9 20:26
进不去空间

作者: swallow81120 时间: 2007-10-24 11:35
对啊，进去了我自己的空间了

作者: scarlett 时间: 2007-10-25 15:10
还没有碰到过这样的情况。不过我觉得。理解需求说明是很重要的一环。这个时候应该要尽可能的站在客户的立场去考虑吧。可能常说的bug的预防，也是从需求的测试入手的。但是具体要怎么去做，我还没有做过。希望能有机会让我实践一下。

作者: julyjin_1 时间: 2007-10-31 17:09
标题: 不错
写的不错哦！值得学习

作者: xhshi 时间: 2008-5-16 09:22
我是刚开始做测试的，现在跟着一个新项目，做到了需求测试
觉得很枯燥无味，又不理解

作者: caixing801929 时间: 2008-5-23 18:19
我们公司刚开始对需求就不重视，导致很多无谓的沟通，产生很多的矛盾。
现在已经开始将需求规范化。测试和开发都不会太累了。

作者: 兰兰 时间: 2008-6-20 11:00
现在项目组正在做需求，看了楼主的共享，真的很受用，以前一直觉得需求很重要，可是在实际的开发过程中，需求的变更太多了，所谓的需求文档也只是初期的需求文档，等整个项目开发完成后，实际的项目还是跟最初的需求还是有一些出入，有些甚至出入很大，但是对最初的需求文档项目组一直没有更新过。这次我准备及时的了解需求，需求变更后，及时对测试用例进行维护。做一次尝试。

作者: 淡淡绿茶 时间: 2008-6-21 21:56
总结得很好..
可是空间打不开哦

作者: bestfeng 时间: 2008-7-4 13:22
好文章.....认真理解需求文档真的很重要..

作者: 天气 时间: 2012-2-20 19:18

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)