这是在测试工作中最需要明确的，也是非常多的项目忽略的工作。在做测试工作之前，一定要非常明确准备对那些内容进行测试，预计达到的质量标准是什么，尤其是对那些不进行测试。

　　我遇到过的很多的测试经理都抱怨说：“我们不可能在前期把这些事情都弄清楚，开发人员都不知道产品将来是什么样子，我们怎么知道需要测试那些内容？”咋一听，感觉很有道理，但是情况是否真像大家说的那样？作为公司，或者项目经理都希望能将项目做好，能生产出一件令用户满意的产品，如果这个假设成立的话，这也就是我们能够改变现状的动力。

　　首先，原先的那种做法已经多次证明是行不通的，所以只有改变我们的做法才有可能成功，前期先弄明白我们打算做什么并不是一个过分的要求。

　　其次，开发人员实际上并不是完全不知道他们打算生产什么样的产品，而是就一些细节考虑的不够，或者不周全。作为测试人员，一定要知道如何对一件产品的功能和性能怎么验证，这实际上在帮助开发人员从使用者的角度上重新的审视一遍需求，也许这时候开发人员也说不清楚，那如果你和开发人员都非常清楚那些是明确的、那些是需要后面再补充的，也已经达到了我们的目的。

　　被测系统有无明确的性能指标？

　　对性能要求比较高的系统，需要在前期明确具体指标到底是多少？用何种手段进行确认？用户是否认可这个指标的描述以及确认的方法。

    性能指标一般从需求中对一些敏感的数字的描述中来，如：必须保证能处理30个在线用户同时操作，主要业务系统响应时间不能大于1.5秒等。

    针对这些数据，测试人员一定要细化数据背后的含义，使这些数据变得可验证。如在规划这些性能指标的验证方式时，首先需要明确软硬件的环境是什么？在此基础上，还需知道什么叫30个在线用户同时操作？都操作什么？这个场景应该怎么模拟？只有和这个指标相关的所有验证方法都可行，而且得到了认可，在后续的测试活动中我们才能相信这条性能指标能够进行测试。

　　测试工作有无明确的阶段划分（如单元、集成、系统、验收等）？各阶段是否有明确的交付确认条件？

　　实际过程中，我们都会将测试工作按照阶段进行划分，上面描述的是一个通常的划分方式。在做监控工作时，还需要明确一点：这些阶段的划分是不是只有时间点的描述，而没有各个阶段之间可量化、可衡量的交付确认条件？

　　如果只有时间点的划分，那我已经可以断定，这个项目势必会延期，原因是在整个生产活动过程中没有明确的阶段点交付的检验标准，问题肯定会沿着整个开发过程逐步的传递下去，终归会在某一点爆发，最不幸的爆发点是在客户处。

　　如果想尽量的避免上述的风险，就需要在开发过程中明确各个阶段点之间的交付、确认条件。而且这些条件必须可量化、可衡量，决不能是含糊的，不易操作的，否则在实际操作过程中还是会将大量的问题推入下一个阶段。