第一次在只有需求文档的情况下写测试方案

现在公司在搞项目管理的规范化，分我配一个新开始的项目开始跟踪。通过项目开发计划，发现需要写一个测试方案，可是目前除了项目的一个总体描述、页面规范、代码规范和需求说明文档外没有任何东西了。这样写东西感觉有些别扭，因为对于系统的功能，只有通过需求文档的描述，对于系统的功能只能完全靠想像了。

一开始我想着是将全篇的需求文档全部看完，然后再分析功能，写出相应的测试点，看了几个模块后，发现这样效果并不好，因为对于整个系统的功能除了文档外没有任何其他可参照的内容，而且是电子文档不像纸制文件可以一边看一边用笔划着帮助增强记忆。至于看到后面的时候，再看以前已经看过的功能，感觉仍然像是看一个完全新的功能。于是改变了看的方法。按照下面的步骤对测试方案进行整理。

1.看单个模块的总体介绍

   在看的过程中，通过总体介绍对于模块功能有一个大体上的了解，根据功能的了解在纸上写出大概的功能点，这点感觉很重要，因为这样在看模块功能的具体介绍的过程时，可以看一出与自己理解功能之间的偏差，并进行记录，提交给开发人员对描述进行调整

2.看单个模块的具体功能的介绍

   看具体功能的时候，需要逐字的查看，如果遇到存在歧义的内容时，使用WORD的审阅功能进行标识，如有必要可对纸制中记录的内容进行修改。

   3.整理单个模块的测试点

   测试点的整理就是根据了解对功能点的整理， 这里对功能点进行了标号，是想对于下一步的测试用例可有一个参照，这样方便用例与功能点的对应，方便查找问题的功能点信息

4.对于与当前整理相关的已经整理模块的测试进行调整

   如果遇到与已经整理过的模块相关的模块功能整理，内容之间不完善或者存在理解错误时，对以前的功能点进行调整，或者由项目经理人解答后再进行调整。

 

我在看需求文档时，由于开发人员处于封闭状态，与我没有在同一办公地点，沟通上不上很方便。因此我并不是遇到问题就立即向项目经理询问，这样也很影响他们的工作，毕竟他们工作时也是有思路的，总打断不好。而是进行很详细的记录，在看完一遍文档后，统一进行整理，询问项目经理的程序功能具体情况，这是用邮件的方式来进行的。他们会在文档中写出解答意见，我在需求文档当中再将答复意见一同记录，以便以后查询。

 

目前就是这些心得了，如果有了新的再补充吧。就到这里啦。