今天在论坛上的每周一问中看了这么一个问题讨论："没有需求文档的时候如何来设计测试用例？（08-06-20）"
很多测试达人发表了自己想法，并贡献出自己大量的经验，感触颇深啊。在我看来，没有需求文档就来设计测试用例，实则不得已而为之的做法，也是测试人员的一种无奈。
作为测试人员都知道，测试的实际结果要与期望结果相一致。因此对期望结果的描述必须能准确的表达，这种表达要反映出产品是符合设计的。那么要如何得知产品是符合需要的呢，依靠，经验？感觉？或与一大堆人沟通后记录下来的文档？如果真是这样做的话，那么软件工程也就没什么用了。
个人坚定的认为， 清晰的需求才是开发和测试的根本，需求文档作为需求的载体理所当然成为测试的最主要的依据。
因为需求文档往往是多方沟通和评审后的共同想法的载体，即使需求文档可能还存在错误，但它已经是最接近于当前客户以及相关设计人员想法的文档说明，因此对于项目来说它就可以是产品的标准，它就可以是软件开发和测试的基本指导。而测试人员在做测试的时候也能有一个标准依据，知道什么是期望的结果，什么样的问题才是bug。
看到有达人说，开发测试用例的时候，如无需求文档，可以凭经验，凭感觉，凭与开发人员交流后的得到的信息作为依据时，甚至认为这样才是真正的测试用例开发的方法。那么试问，经验，感觉以及看似可靠的信息是否真的是依据，这些信息是否通过相关人员评审过呢，你的经验，你的感觉是相关人员认同的吗，是否每次在与开发人员交流后需要他们签字来证明这是开发时的设计依据呢？的确需求文档不可能将所有的细节包含进去，但它包含了产品最核心的，最值得关注的地方，没有需求，你无法保证，依靠经验，感觉所开发的测试用例真正的覆盖到了所需要覆盖的地方，产品的质量无标准可以衡量和判定。
盖房子要有设计草图，软件设计当然必须有需求文档，需求是软件设计和测试的根本，开发和测试过程都需要以需求文档作为指导。
需求文档是沟通的桥梁，如果有它，测试人员就没必要花那么多的时间和精力去找开发部门，市场部门了解这个功能是否是需要的，这个模块输入的值是否应该如此，更没有必要去想方设法地去寻找可作为依据的依据了，因为得到最广泛认可的想法都写在了需求文档上了。
其实没有需求的测试，说白了，就是项目前期，有些人该做的事情没有做，把需求像垃圾一样丢放在不同的地方，最后由测试人员充当清洁工，将垃圾回收整理起来。而测试人员还要想尽一切办法，总结出了很多经验来如何高效地收集它们。实际上测试人员做这样的事情已经本末倒置了。
无奈的是，国内的环境就是如此，由于资金，时间等条件的制约，导致项目管理过程中的急功近利，人的惰性也被迫放大，大部分人都希望最后接手的人来收拾残局，该写需求的时候不写，想着没需求也可以开始工作，省了这一步，节约了时间，节约了资金，多省事啊。而开发的人员在没有需求的条件下想当然的开发出代码，开发完的代码自己都不想看第二遍，最后都推到了测试人员身上，怎么办，什么都没有，但工作又必须得做。幸好中国的测试达人们相应了毛主席的号召“自己动手，丰衣足食”，没有依据也要想方设法的找到依据。最后，很多大拿们通过多次的摸索总结出了大量经验，并拿出来与他人分享，真的很尊敬这样测试人员，不仅要出色的完成自己的工作，还要出色的完成别人的工作！却拿着与这份责任不符的薪水，真是太辛苦，太无奈了！
如果开发企业在项目初期，耐心的把需求写完并评审通过，那么测试人员开发用例的时候也有了目的性，也就不会出现这些所谓的收集测试依据的高明方法，也不会有这样一个问题讨论了。
真希望国内的开发企业能够重视需求的编写，因为写需求所节约的资源也许远远小于测试人员为了寻找需求说花费的资源，有了详细清晰的需求，测试人员可以更专注于测试本身，开发人员也能更专注于开发，这样所带来的好处和对产品质量的影响，这里就不用说了。
有希望才能有前进的动力，相信中国的软件企业最终会走向正规，对测试的重视也会越来越高。那时测试人员就再也不用为这样的事情浪费时间和精力了。最后，希望所有正在承担这样痛苦的测试工作者们，你们要有足够的理由自信自己的能力，因为在困境中都能出色完成任务的人就是强者！
无他法，继续练，期待质变的那一天。