测试驱动需求分析--需求文档评审实例

 

相关文章链接如下：

微软过桥问题与测试人员素养 等价类分法 新解 测试用例设计中的NP难题 C/C++代码检视实例 90％程序员写不出无BUG的二分查找程序？

      

          需求文档评审实例

软件的开发文档质量一般只能通过评审来进行保证，如何有效发现文档中的问题，是一个令许多人头疼的问题。先看一段关于日志文件的需求描述如下：

“软件要将所有的访问者都要记录下来，对每次访问要记录访问开始时间、访问结束时间、访问者的 IP地址这三个信息作为一条日志记录。要求以天为单位每天生成一个访问记录日志文件。”

在这段需求描述中，要发现问题的话，首先要想象自己是日志模块的开发者，根据这段需求描述，是否能够开发出日志模块来呢？日志文件要记录的信息内容上面都提到了：访问开始时间、结束时间、IP地址。初一看好像可以根据这个需求描述进行开发。

如果用用元素分析法来分析一下这段需求的话，就会发现并不是想象的那样乐观。先找出需求中涉及的三个显性元素：

n         访问者

n         访问记录

n         日志文件

首先对访问者和访问记录这两个元素进行分析，先看访问者有那些属性，除了描述中提及的访问时间和IP地址外，访问者还有那些属性呢？显然访问者的访问内容是最重要的属性，仅记录访问时间和访问者的IP地址是否足够呢，从日志能分析出什么有用的信息呢？从时间信息上最多只能看出那段时间访问的人数较多，得到用户的时间分布规律，很难对用户的行为有深入的分析，只有知道访问者在访问那些内容才能得到更有价值的信息。象Web服务器软件要记录下访问的URL信息以便知道访问者访问的内容，所以访问记录中遗漏了关于访问内容的信息。

从访问记录这个元素来分析，访问记录主要属性是记录格式，每条记录是以什么格式来记录呢？没有描述出来。有经验的开发者就知道日志记录格式是一个很重要的问题，因为日志记录的分析一般是需要使用专门的分析软件或者写专门的分析程序来分析的。如何设计合理的记录格式来利用已有的日志分析软件来进行分析是首要考虑的问题。

再对日志文件这个元素进行分析，先看看日志文件有那些属性，首先日志文件具有文件名，还有存放位置，文件格式，文件内容、文件创建时间、文件大小、文件权限等属性。

需求描述中提到了每天要生成一个日志文件，从文件创建时间属性来看，每天有24小时，到底从什么时候开始创建文件，从0点开始还是从几点开始，没有描述出来。

从文件名属性来看，如何命名日志文件，需求中也没有提及。从存放位置属性来看，日志文件存放在什么地方也没有说明。是不是所有的日志文件都存放在应用程序同一子目录下？

从文件格式属性来看，首先日志文件是以文本方式存储还是以二进制格式存储？再者，文件的内容是以何种格式记录，每条访问记录间如何分隔，是以回车换行作为分隔还是以其他字符作为分隔？都没有描述。

从文件内容属性来分析，除了存放上述描述的内容外，是否还可以保存其他内容，如果不能保存其他内容的话，需求描述中应该加上一句“日志文件中只能存储访问记录信息，不得储存其他记录信息”。

从文件大小属性来分析，日志文件的大小有没有限制？如果某天处于访问高峰期，访问特别多，是否需要将日志文件分拆成多个是一个需要考虑的问题。

从文件权限属性来分析，日志文件是否机器上的所有用户都可以访问还是只有特定的用户可以访问？文件是否需要设置权限是一个需要考虑的问题。

所以通过元素分析法对上述需求描述进行分析后，你会发现需求描述中有很多的问题没有描述清楚。也许有人会有疑问，如果将所有上面说到的问题都描述出来的话会不会工作量太大了？仅从需求分析的角度来讲，需求规格描述得较细的话确实会增大很多工作量，但从整个开发过程来看，需求描述完整的话，后续阶段的开发产生歧义和遗漏的可能性就很小，实际上后续阶段节约的时间会大大超过需求所多花的时间。

实际上不仅检视需求时需要使用测试用例设计方法，还应该采取测试用例设计来驱动需求分析，即在需求设计的过程中就设计测试用例，通过测试用例设计来驱动需求分析，完善需求分析的内容。