在51Testing论坛的每周一问活动中看到这样一道题目：测试用例应该依照需求文档来开发，但是我们的项目根本就没有需求文档？那测试用例该如何开发呢？
我也常常碰到这样的问题，我的经验是跟系统开发人员多沟通以便了解到他们的开发流程、思路、注意细节等等，用笔记下来（俗话说“好记性不如烂笔头”嘛），理顺思路，然后再运用设计测试用例的等价类划分、边界值分析等方法对照系统各模块进行设计！
没有文档对于单元测试来说也是一个难题，弄不好会使测试毫无意义。前段时间，我收到用户反馈说，单元测试的效果不好，经了解，情形是这样的：没有详细设计文档，由测试部门做单元测试，由于没有文档，测试员只好读代码来判断程序功能，预期输出是读代码后自已算出来的，结果效果不好。
例如：
int func(int a, int b){return a-b;};
本来是计算两个数的和的，结果程序员将加号写成了减号。
测试时，如果有文档，哪怕是很简单的写一句：返回两个数的和，那么，测试员就可以这样设计用例：输入两个1,判断返回值是不是2，马上就能发现错误，但由于没有文档，测试员不知道代码的设计功能，根据代码，自己算出一个输出：0，这种测试基本上就没有意义了。
我们推荐的解决办法有：
办法一：由开发部门补充文档，可以不要求太正规，只要让测试员想得清楚：什么输入应该产生什么输出就OK了。
办法二：测试员只是设定用例的输入，输出全部设为FALSE，然后由开发部门设定输出。
办法三：由开发部门做基本功能测试，测试部门补充用例。由于已有基本用例，测试员根据现有用例就可以判断程序功能。
办法四：程序员编码时，边开发边测试代码的基本功能，测试部门只是补充用例。与办法三的区别是：办法三是事后测试，办法四是测试驱动开发。
越是排在后面的办法，推荐指数越高。如果这些全部做不到，那我的最后建议是：重新考虑测试是否值得。1、要求项目组提供测试特性；
2、如果项目组由于各种因素不能提供，则要测试人员自己写测试特性。
3、组织评审，要求对模块熟悉的人员（项目经理、需求、开发）参加。
4、根据测试特性，写测试点，再组织评审。
……
总之，开始一项工作之前，一定要问清楚是什么，完成标准是什么。测试工作的血泪史告诉我们：如果这时讲义气，后面就要遭殃了。
这应该是一个非常普遍的问题，目前很多公司的现状就是这样！
没有需求文档，最头疼的问题就是不知道开发的产品应该是个什么样，要完成哪些功能，达到什么指标。
下面几个步骤应该可以帮助你明确目标：
1、首先可以查找其他相关文档。比如产品策划书、Feature List，不可能什么文档都没有吧。我们可以收集一切相关的文档来帮助理解所要测试的产品需要完成的目标。
2、尽量多参加该项目组内的会议。比如需求讨论、设计讨论、计划讨论等会议，尽管没有白纸黑字的文档，但讨论过程中也能让你加深对产品的理解。
3、咨询相关人员。经过以上两个过程，应该对产品有了一个初步的理解，花点时间自己把大致的功能点整理一下，遇到不明确的、有疑问的，可以咨询项目负责人或者相关市场人员，他们应该对整个产品心中有数，否则这个产品真的就没法做下去了。这里有一个前提是，在对产品有了初步了解后，才有针对性的去咨询，否则在什么都不知道的情况下，第一，对方没有耐心和时间向你介绍整个产品；第二，对于对方的讲解，估计最多也只能了解个大概，不能很好理解。
4、使用旧版本。如果当前开发的产品是以前做过产品的升级版，或者和以前某个项目类似，这样就最好了，有个实实在在的“demo”给你用，当然理解也更深入了。
5、召集相关人员，对你整理的结果进行讨论。整理以上几步得出的结论，总结成文档，发给相关人员，包括项目负责人、市场部代表、开发人员等，让他们帮助评审check，根据意见对文档不断进行补充完善。当最后通过评审后，这个文档就可以当作依据来设计你的测试用例了。
相关阅读：
