举例说明如何进行测试需求分析

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

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

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

　　1、访问者

　　2、访问记录

　　3、日志文件

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

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

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

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

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

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

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

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

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

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

　　测试人员在需求阶段应做哪些工作

　　1)首先，测试用例和测试工作本身是不断完善的，在开发过程的初期，可以认为是需求阶段，或者没有规范需求工作的设计阶段。如果有一个比较明确的需求文档，可以在这个阶段检查完了需求文档以后开始设计测试用例。这里，对于需求文档的检查主要是两个方面：

　　---检查需求文档描述的正确性，测试人员要对于真实的系统所涉及的业务非常熟悉，比如一个简单的财务软件，那么测试人员本身要对会计工作熟悉，财务制度熟悉，在检查需求文档的时候不要迷信所谓的”都是用户真实的需求“，这里存在两个问题，一是用户是否真的能正确地描述自己的需求，二是需求人员是否真的能正确地理解需求。另外，还有一个用户的需求是否符合行业规范的问题，如果不符合，那么是否要确认--这里存在一个隐患，用户可能会在开发的后期突然要求他们自己要走行业规范，让你的需求变动，所以要事先明确好。

　　---检查需求文档描述的准确性。主要是考虑文档中是否存在描述的模糊的地方，对于自己不清楚的问题一定要明确。这个时候是要保证需求的可测试性--我的意思是说保证需求是可以完全为测试工作服务的。

　　2)那么在检查完了需求之后，可以开始设计测试用例了，在这个阶段因为没有开始设计工作，所以对于测试用例的考虑不能仅仅从界面出发，而应该从业务角度出发，从实际业务出发来设计测试用例。

　　当然，这个阶段所设计的测试用例是不够完善的，只能涵盖某些内容，但是我认为这些用例不仅仅全部都是功能测试用例，而且在整个项目中都将有效。 。

　　3)不过，当缺少需求文档时，那要发挥测试人员自己的能动性了，要主动的工作，而不是被动的等待。要自己尝试着去熟悉实际业务，要尽量通过自己所能想到的方法来开展工作。