前言 ：浏览51testing的每周一问时，看到没有需求文档该如何设计测 试用例这个话题，是以前的问答，根据自己的测试经验，也给自己回答以下，算做一个工作小结吧，写之前没有看其他人的回答，因为看了其他人的后，可能会不自觉的对自己的思路有影响，所以先自己写完后又去看了下论坛里面其他人的回答，觉得zhuzx的回答更全面一些，学习之。

=======================华丽的分割线，步入正题==================

　　当项目比较紧张的时候，很多时候需求文档这个重要的步骤就会被省略或者延后，从流程上来说是绝对不规范的，但是没有办法呀，对于一些没有形成系统测试 规范的公司，且国内测试现状也大概如此，缺胳膊少腿的现象是很正常的，我们测试人员只能灵活应对才是王道撒。根据个人经验，发表点意见：

　　1、没有需求文档，找别的文档。

　　需求文档可能由于时间原因暂时无法获取，那就尽量的去获取其他的文档吧，比如开发的一些设计文档---概要设计、功能设计、详细设计等等。如果开发连这些文档都没有，那么可以去网上查询同类产品的一些规格说明书，幸运的话，也许能down 到别人类似产品的一些需求说明。这些材料虽然不是自己产品的需求说明，但是因为是同类产品，功能方面也总会有8、9分类似，所以研究别人的产品，自然也就会对自己产品有了几分把握。

　　2、模块定位和划分

　　如果开发有详细的设计文档，那么就按照开发的设计，将产品按照功能模块迅速简捷的先进行模块划分。如果没有开发文档，那就要跟开发沟通，让他们简单介绍一下产品的功能模块并自己试用后对产品进行模块划分。模块划分后，组内分工合作，进行探索性测试同时不断完善测试计划和测试需求，因为前期概要的了解产品绝对不可能一次到位的对各个模块划分准确的。

　　3、测试方法

　　如果没有需求文档，测试用例的编写肯定没有参照。所以测试过程中测试用例的设计不可能非常详细，在有了1、2的调研、研究产品的基础后，可以设计一些简单的场景测试、流程测试用例，按照这些用例测试的过程中，必然会发现各种各样的问题，同时对产品也会不断熟悉。测试用例的编写可以放在一个轮次的测试完成后进行补充编写，然后在以后的测试过程中不断完善。

　　由于没有需求文档的情况下，想要先详细的设计出测试用例再进行测试是不太现实的，只能简单的进行用例设计后，确定大概的测试方向，然后在测试过程中不断完善测试用例才行。

　　注意注意： 这种先测试后完善测试用例的方式必须是针对一个周期较长且需要做回归测试的项目，如果一个项目周期很短，且完成后不需要进行回归，那么这种方法并不是太理想，因为用例完成了却利用率不高，只能作为后期参考，以及对后来新人的一个培训和积累公共测试用例的途径（呀，看来用处还蛮多的嘛，呵呵，不过对于项目本身来说，用处不太大咯），从公司和项目角度来说，实际投入成本是增大了而这些投入的产出又比较小。

　　个人绘制了一个简单的进度图。