理解需求说明书续

 

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

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

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