软件测试工程师如何做好需求分析(3)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原文转自：http://www.blogjava.net/qileilove/archive/2013/05/20/399492.html