需求不足或很少时的测试

　　项目没有明确定义的（或任何）需求规格说明书就开始实施，这很常见，特别是在小公司里面。即使是在大型企业，在他们认为不需要规范领域，也可能存在项目缺少需求规格说明书的情况。在这种情况下如何进行测试是一个常见的问题。

　　在项目缺少需求规格说明书的情况，并不存在一个做好测试简单快捷的方法，因为需求规格说明书对功能性测试的效力有很大的推动作用。其中关键的一点是要注意保持对需求来源进行追踪，和从这些需求源头上可衍生出哪些需求。这将大大简化对需求合法性的验证。以下是在以往测试成功过的几种策略：

　　把用户手册当作需求规格说明书使用，这种方法是有效的和符合要求的。如果用户手册提供了足够的细节信息并且被信息组织编排得很有条理，使用它和使用需求规格说明书的效果几乎是一样的。关键是学会在用户手册上系统化地查找需求，确认和追踪这些需求。另外，经常需要从其它的来源获取需求信息来对用户手册进行补充，因为用户手册很少会包含压力和响应时间方面等精确数目信息。

　　把设计文档当作需求规格说明书使用，大部分的开发人员至少会在某处的文件上记录或保存系统的一些相关信息。查找出这些设计文档后，它可作为需求的一个源头，特别是对于那些在用户手册上无法找到的硬性指标需求。关键是要小心选择可用作需求的信息，要注意避免把设计信息当作需求。销售文档同样也可以这样用。

　　与人交谈。小项目的一个常见问题是“两只腿的需求”，这是指长驻客户公司的应用软件技术支持人员，他们围绕描述软件的用途与客户反复沟通。通常这些技术支持人员都会写下一些信息，这些信息可用作需求，但多半时候这些信息用处不大，这需要和他们坐下来谈论一下这个系统要实现哪些功能。另外，走出去和开发人员，系统的实际用户，甚至购买产品的客户等交谈。在每次会谈中，及时作笔记，然后把这些笔记作为进行测试的基础资料。使用常识。使用常识这个方法应该是所有其它方法都失败后的最后选择。虽然使用常识可能会发现问题，但使用这种方法会引发所发现故障的重要性和关联性的争论，甚至这个缺陷实际上是不是缺陷也可能需要论证。

　　测试准备不足情况下的测试

　　一个关键的考虑因素可能是根本上这个软件是否可测，如果没有足够的时间去为一个全新的产品作测试做准备，唯一可行的办法是向项目管理人员报告这个软件达不到测试的条件，让其决定如何处理这个问题。如何项目管理人员做出的决定是宣布这个产品达不到测试的条件，测试人员需提供详细的信息以解释为什么这个软件达不到测试的条件和需要作哪些改进使它达到测试的条件。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/11379785/viewspace-675897/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/11379785/viewspace-675897/