天道酬勤

（转）理解需求说明书

上一篇 / 下一篇 2007-11-28 09:33:25 / 个人分类：理解需求

出处：四叶草的测试梦园

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

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

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

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

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

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

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

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

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

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

其次，努力获得和你要测试的项目相似的已经成型的系统，然后认真去研究它。可能你的项目没有详细的需求规格说明书，但是这个项目可能是以前系统的升级，或者只是做了很好的改动，或者，这个项目是根据现有市场上的已有产品的优化，无论怎么样，都可能会找到和现有系统类似的项目或者产品，这些可能项目经理可能会准备好，那么询问项目经理，得到它们然后，仔细研究它们。

当你得到了和你将要测试的系统类似的已经成熟的产品，就对她进行详细的检查，不是说让你去测试它，而是检查已有系统，然后确定你的产品会以一个什么样的形式组织，会怎样设计整个框架，彼此会有哪些联系。通过检查熟悉后，你进可以确定你将要测试的系统有哪些功能，以此来正确估算你测试需要花费的时间。同时，通过检查熟悉，你可以通过对比，确定你现有的关于你产品的信息是否对测试是足够的，如果缺少，怎么去获取，以次来确定你测试需要的资源。通过检查，你也可以确定产品质量相关的内容，确定哪些质量问题是测试的重点，哪些是bug高发区，以次来确定测试重点。检查还有利于你组织测试用例，针对系统的特点设计有效的，高覆盖率的测试用例。

收藏举报

TAG: 理解需求

查看全部评论