需求不明确在很多状况、很多公司都会出现，而且需求经常会随市场的需要而随时更改。它通常发生在一个项目的初期或者项目为某个成熟项目的子项目，相 关部门认为不需要定义明确的需求可以更改立项的时候。无论那种情况，既然是产品，当产品进入测试部门进行测试的时候，我们总要有一个标准来衡量软件的质 量，每次测试的时候总要有一个结论，那么我们怎样来保证测试质量呢？个人认为，无外乎从下面几个方面着手来进行：

　　借。这里说的借，无非是借鉴的意思。目前我们设计的产品，在功能上来说，或多或少我们在市面上都能找到类似的产品，对于这些产品来说，都是被成千上万的 用户所使用的，并且功能都比较熟悉，因此，我们可以参照这些产品来确定我们设计的产品的软件质量。对于同一类型的功能，我们可以借鉴它的长处，并把这些长 处当成我们的软件质量目标，我们的低要求是让我们的质量标准能达到已经被人们证明可用的已经存在的这些功能上；当然，我们不仅仅要满足这个低要求， 我们更应该尝试可用超越市面上已经存在的这些功能，使之更贴切用户的使用习惯，甚至超越，让它更方便。对于同一类型的功能的短处，当然我们要想方设法的 避免，总不至于明知道那种方式不被用户接受，我们还要照搬吧，那样的产品如果上市那么结果我们是可想而知的。

　　问。询问、沟通的意思。在绝大多数公司，测试人员与开发人员、市场、PM等相关部门的同仁都是在一起办公的，即使分布在不同的地域，至少我们都有电话、 Email等沟通方式吧。当市场等部门提出一个概念时，即使没有明白的说明意思或者无法得到更加详细的信息，但是当开发人员接到相应的任务时，他要实现这 个功能，心里总有自己的一些预计吧（如果没有自己的预计与想法，他的代码能编制出来吗？），这个时候，测试人员与这些同仁的沟通显得尤其重要。我们通过 沟通知悉开发人员的开发意图后，当然可以发表自己的看法与意见，并且能对开发人员开发出来的软件有针对性的测试了。

　　思。毫无疑问是思考的意思了。需求不明确，当测试人员在拿到需要测试的软件时，你总要把这个软件运行起来吧。在软件运行的时候，即使你对这个功能不熟 悉，你总要去揣摩这个功能想干什么事情，并去证明它干的是对还是错吧。这个时候我们首先可以从正面一步一步的去操作，检查它的功能点、人机界面等是否正 常，并找到一部分显而易见的Bug了。随着你操作的进行，你对功能也越来越熟悉了，这个时候，可以设计一些反面的、异常的测试用例来进行测试。上面的任 务完成后，也没有问题了，那么至少我们可以保证正在测试的功能没有毛病了，这个时候你应该能感觉到那些地方使用不便，那些地方缺失了什么功能，用户使用可 能会投诉等，你可以站在用户的角度来提问题并要求改善，功能也能进一步的完善。等功能完善后，你对这个系统也都非常了解了，我们可以采用更多的手段来 进行测试，并开始着手进行系统测试了，而且测试案例也可以进一步的得到补充。

　　分。分阶段、揣摩意图。对于刚才说的需求不明确的两种情形，我们可以尝试从以下几方面来保证产品的质量需求：

　　1，任何一个项目开始，其主要功能必须是明确的。相对于其它产品或要求，任何一个产品都有它自身的特点和侧重点，只有差异性才能引起客户的兴趣。因此对于 主要功能，我们必须保证功能实现并稳定。那么在需求不明确的时候，测试部门必须从市场/项目经理/开发经理等相关人员处详细了解该产品的主要特点 是什么，并针对该特点进行详细的测试。

　　2，对于任何一件产品来说，既然是产品，需要系统运行起来必须稳定，因此，即使需求不明确，我们也必须保证已经开发出来的功能不存在重大的问题，比如系 统死机/系统重起等。此时我们必须严格管理好产品的各种版本，保证需求在变化前的版本一定是经过详细测试，并且没有任何严重问题。这样可以防止需求变更过 快时，影响之前的产品。做成不同的版本，还可以适应不同的需求。

　　3，对于某一产品的延伸产品来说，那么绝大多数功能都是已经明确的并且差不多是成熟的，我们重点需要关注的是新增或者更新的功能是否对系统有影响，对这一部分进行重点的研究。

　　总之，需求明确当然会为我们工作的开展提供不少的方便，会让我们的工作有章可循，但是需求不明确的时候，并不代表我们的测试质量没有保证，在问题面前，我 们不回避，但是我们可以根据不同的情况下来调整我们的测试策略、测试技巧来防范问题，使得我们的测试质量有所保证，稳步提高。