我们都知道，软件测试是一门依赖性很强的综合技术，软件测试工程师在施行自己的工作时，总是要依赖其他团队的产出。

　　比如，我们要依赖着需求团队给出的需求分析说明书来确定测试的方向，又要依赖开发团队产出的实际代码产品才能真正开展测试的执行。一个测试团队，通常而言是不能独立于其他团队而存在的。

　　所以，软件测试基础理论中，我们提出了一个概念，叫做‘测试依据（test basis）’。从字面意义上理解，测试依据就是就是我们测试可以依据它来进行测试分析，以及用例编写的文档或者信息；他被用来指导我们的测试，我们可以从中提炼出‘测什么’‘怎么测’这样测试根本性问题的答案。没有了测试依据，测试工作就将无从下手。

　　说到测试依据，我们最直接会想到的就是需求文档了，根据项目特性的不同，他有可能呈现为不同的格式：比如需求规格说明书式，又比如原型图式等等。而根据需求文档内容分解和描述形式的区别，他又有可能呈现为用户故事型（User Story）或者产品需求文档型（PRD）。

　　说起这些需求文档，相信很多测试工程师都会叫苦不迭。由于国内IT行业内需求分析力量的普遍薄弱，又或者是甲方用户时常胡搅蛮缠的态度，被我们测试工程师视为生命线和指南针的需求文档在交付到我们手里的时候往往是不堪所用的状况。不但功能描述不清，歧义性，二义性，含糊其词，甚至有可能压根儿就没有某方面的需求。而在我们后期执行测试提出缺陷时，相关方又很喜欢用需求来搪塞测试提出的合理问题（“需求就是这么定义的”，“这不是bug。。。”）。

　　基于这样的现状，各种测试的理论中总是不断的强调需求对于我们测试工程的重要性。

　　然而理论很丰满，现实很骨感，测试人员的呐喊，有时候未必能得到项目的重视。在需求文档始终得不到补完和修正的情况下，我们该做些什么才能最大程度的弥补需求文档缺失所带来的质量风险呢。

　　这里就要回归到文章开头提到的‘测试依据’的概念了。

　　我们始终要明白一件重要的事情是，测试依据，其实指的并不仅仅只是需求文档。从本质上说，他应该包括所有可以指导我们测试的信息。下面我们就来一一探讨一下，都有哪些信息我们可以拿来用作测试依据，以及怎么来使用它们。

　　首先第一个是开发部门的设计文档，包括我们在软件生命周期中提到的架构设计，详细设计阶段的产出。

　　开发部门在进行上述设计工作的时候，有可能会产出比需求阶段更丰富的文档，比如架构设计图，算法设计图，模块的详细设计说明书，接口定义文档，数据库设计说明书，界面设计线图等等等等。

　　实际工作中，你会发现，开发部门产出的设计文档往往会包含对产品更详尽，丰富的定义信息。基于这些文档提供的信息，我们就可以更进一步，深层次的确定我们测试所需要覆盖的范围和内容。

　　当然，理论上而言，这些设计文档只是开发部门为了实现需求而做出的分析性产出，他并不一定完全匹配最初的产品需求甚至用户需求。我们使用这些设计文档的前提判断是：开发部门与需求部门有足够的沟通，他们的产品设计是符合需求的。为了确认这一事实，我们测试人员可能需要来回往返于开发团队和需求团队（或用户）之间来寻求肯定的答复（一个典型的状况是，需求团队对于用户需求的解读并不够细致详尽，事实上他可能根本没有思考到相应深刻的程度，而对于开发通过主观判断给出的设计，他也许并提不出什么意见，只能表示认可）。

　　还有一种状况是，对于某些细节性的处理，也许连设计文档都不曾包括，而是在开发团队与需求人员（或直接客户）的口头，会议交流中确定了某些做法。这些约定，一旦没有知会到我们测试团队，那么我们的测试就会走弯路甚至出错误。所以作为测试团队，我们应该尽可能要求参加进项目调研分析阶段的各项讨论活动和会议，并且要把这些口头约定的内容用文字记下来（比如用邮件，发给各与会方），从而形成我们的测试依据文档。相信我，在项目收尾阶段，我们去交付自己的测试成果时，有这些记录在案的约定处理会让你更有底气。

　　极端情况下，开发也有可能将需求中没有涉及到，但是产品又不可能缺少的部分，直接按照自己的开发惯例实现了，连设计文档都没有。比如，在用户定制一个电子商务交易平台时，他可能根本没有去关注用户模块；开发也就顺势用他所最熟知的用户模块的开发形式，完成了该模块的创作。这种情况下，我们测试人员能依赖的依据就更不足了，通常我们只能默认开发人员的开发方式没有问题，只能最大程度的去确保他按照自己想法开发出来的模块没有明显的问题和漏洞。其次，我们还能使用接下来要提到的这些作为依据：

　　第二个是行业标准和惯例。

　　行业标准说起来是个很玄乎的话题，我们这个产品的行业里到底有哪些标准啊？

　　这就要求我们对于对口行业有着深刻的理解了。说起来很难，但这其实是我们作为测试工程师所必须具备的能力之一。

　　在一个财会处理类系统中，我们去核算某只债券的收益情况。按照行业标准和惯例，系统应当提供选择，将该只债券最终的利息收入均摊到计息期间的每一天中，即所谓‘计提利息’-这样才能达到财务核算平滑度的目的。这就是财会核算领域内的一个行业标准和惯例，如果我们的系统不设计这样的功能，那么即使需求没有明确提出，我们也可以理所当然的将他做为问题甚至缺陷抛出来。

　　再比如在一个Web项目当中，我们可以对站内所有的链接地址进行筛查，防止出现‘孤岛链接’的存在（即这个链接在站内没有任何其他页面可以导向他）。同样这也是现今网页项目的一个行业标准。

　　事实上，在当今的软件测试体系工程内，有一些领域大部分情况是没有需求支持，我们通常都会用现存的成熟标准来实现测试-一个典型的例子就是安全性测试。在我们去做安全性测试的时候，大部分情况下都不会有详尽需求来给我们指引，但是我们在这个领域内有着非常成熟的一套测试标准，比如说我们会测试Web项目的cookies安全性，防御XSS攻击的能力，数据库信息加密存储等等等等。

　　其实行业惯例的体现还可以类似“在这个行业内，一般都是这样做的--如果我们的产品没有足够的理由不这样做，就要遵循惯例“。这次举个非常简单的栗子，在系统中，我们设计了如下对话框：

　　这个对话框符合行业的惯例吗？其实他是有问题的，因为在界面设计惯例中，出于人体工程学考虑，确认按钮一般都放在对话框的右下角，这样才方便用户操作（除非你的用户全都是左撇子并且左手持鼠标）。像这样的对话框按钮设计，完全可以报出一个易用性类别的缺陷，其依据就是”行业惯例“（当然如果你够自信，也可以援引人体工程学的理论作为你的论据）。

　　当然在我们引用行业标准和惯例的时候，是需要我们测试人员有足够的经验的。如果你对行业标准和惯例没有足够的了解，就要多关注这方面的知识，多思考，多积累。相信我们对于行业和市场的学习，不但会帮助到我们的日常测试工作，甚至有可能让我们成为对手行业的专家呢。

　　从另一个角度而言，一个经验足够丰富的测试工程师，很多时候是可以反过来指导需求和开发工作的开展的。

　　第三个是政策法规和政治要素。

　　是不是听起来更玄乎了，怎么我们测试人员不但要懂测试，还要懂行业，现在又要懂法律法规了！？

　　事实上不必惊讶，一个资深的测试人员确实从知识面的广度上而言是要超出其他岗位的，这是由我们的工作性质和状态决定。质量是我们测试人员的生命线，从某种意义上来说，没有人比我们更关心一个产品的质量和水准，所以我们天然的会对这个产品能涉及到的方方面面性状去进行了解和学习。

　　我们还是用栗子来说话。例如，我们现在要开发一个药品零售网站，为消费者提供在线购买医药用品的服务。那么结合着国内的法律法规，我们可以知道，药品的销售可否是受到法规限制的，那么我们的系统就要有违禁药物筛选功能；再比如，处方药是需要得到医生处方才可以被销售的，那么就意味着我们的系统可能要有处方上传功能。

　　如果这个系统在需求和设计开发阶段，没有从其他方面限制药品的录入，又没有实现我们上面提到的违禁药筛选和处方上传功能，我们就可以认为这是一个系统风险。在一些情况下，我们完全可以将这样问题作为缺陷上报。

　　那政治要素又怎么说？

　　同样我们举个栗子：在前些年，大名鼎鼎的PC游戏《足球经理(Football Manager)》某一版本发布时，就在政治上犯了错误。他在制定足球运动员的国籍一项属性中，将‘加泰罗尼亚’作为一个国籍赫然列在选项当中，这就引起了大量西班牙用户的不满，以致遭到了抵制甚至政府出面的封杀（加泰罗尼亚和西班牙的问题自行百度哦）。事实上，如果测试人员在这款产品制作的过程中意识到这个问题，完全是有可能预防这样严重的后果的。

　　

　　除了我们以上说的这些，能作为我们测试依据的我们还能找出一些来。比如用户手册--手册里阐述的内容当然应该与产品的功能保持一致；又甚至是”自然规律“--比如一个手机APP，即使需求和设计里不做任何规定，我们也知道他应该适配现在市场上的所有主流手机型号（这个栗子也许也能用行业标准来判断）；等等等等。

　　在许多软件测试的理论中，也有另外一个名词被经常提到，那就是”隐性需求“。这个概念跟本文所提到的这些额外的我们可用的测试依据既有相互重叠的部分，也有相互补充的部分，我们在采集测试依据的时候，可以把这两方面都包含进来，从而形成一个更加完备的测试覆盖面积。

　　

　　结语：测海无涯苦作舟。我们当然希望我们的需求是完美的，我们的开发是成熟干练和蔼可亲的，然而理想和现实却往往是有差距的。但是换一个角度思考，问题越存在，在解决问题后，才越能彰显我们自身的实力。作为一个测试人员，如何在需求不完备的情况下，利用自己的知识，技能，储备和经验，应用各方面的条件来实现更完备的测试，无疑是我们的挑战，但同样也是证明我们自己的机遇。

　　我们可能还会疑虑，如果我基于这些没有得到需求文档支撑的依据报了bug，开发和管理人员会承认吗？笔者认为，你大可不必担心，我们这样报出的缺陷是肯定没有问题，而且是对团队有益的。你完全可以去据理力争，相信经过你们团队的磨合，随着各利益相关方对我们测试水平的逐渐认可，这些问题迟早会得到项目的重视。而你作为一个测试人员的口碑也一定会得到提升。

　　以后再遇到需求不足，不明确的情况下，除了苦苦追着需求人员要答复，试着应用这些依据来开展你的测试吧。