定义测试预期： 测试预期是用于判定一个测试通过与否的策略，测试的主要任务之一是根据产品真实需求来确定测试预期，受到测试目标的影响。

　　定制测试模型： 根据项目特点构造一个测试模型——描述将采用何种测试方法，以及该方法相配合的测试“覆盖”内容。比如：采用基于风险的测试方法时，同时应制定相应的风险领域列表。在后面罗列一些 通用测试技术 以供选择使用。

　　选择覆盖范围： 确定产品的哪些部分必须被测试，哪些可暂不考虑。

　　配置系统： 为测试工作准备产品和平台，确保系统处于开始测试的正确状态。

　　操作系统 : 为系统提供必需的输入和控制以执行测试，对于某些测试类型可能需要特殊工具支持。

　　观察系统： 监控系统操作过程中的输出或任何其他相关结果。对于哪些隐含变量或微妙结果的观察可能需要特殊工具支持。

　　评估结果： 利用测试预期来评估测试结果，需要时执行附加的测试以验证评估。及时反馈评估结果给开发人员，必要 时应调整测试计划。

　　附录：通用测试技术
　　每种测试技术是一种创建测试的方式，其种类难以胜数。以下给出一些简单、实用的通用测试技术，每种技术既可以通过所谓“快速但不洁（ quick and dirty ）”的方式执行，也可以更为正式地执行，还可以相互结合（比如基于风险的回归测试等）。

　　域测试 —— 依据等价类和边界值对产品不同域测试

　　1. 确定要测试的域；

　　2. 分析每个域的限制和特性；

　　3. 确定要测试的域组合；

　　4. 应用所选择的测试策略。

　　例如，穷尽值，典型值，边界值，随机值，非法值。

　　容量测试 —— 在“超负荷”状态下使用系统

　　1. 选择要“超负荷”测试的条目和功能；

　　2. 确定与其相关的数据和平台元素；

　　3. 选择或生成用来运行测试的具有挑战性的数据和平台配置。

　　例如，很大或复杂的数据结构，高负载，长时间运行，大量测试用例，低内存条件

　　线索测试 —— 按照某种逻辑顺序对系统进行测试

　　1. 定义测试程序或高层测试用例，将多个测试按照一个接一个的方式结合在一起；

　　2. 不要在测试之间重置系统；

　　3. 将时间因素考虑进来；

　　4. 与其它技术结合。

　　例如，用户线索，容量线索，基于风险的线索。典型情况下，线索测试通过“场景”来定义。所谓“场景”，是一步一步的详细指令序列，它描述了哪些数据要输入哪些字段，以及要按下什么按钮等。一般应包含：（ 1 ）该场景使用的数据描述（ 2 ）描述该场景的前提：那些动作必须在之前执行；（ 3 ）动作序列描述：如，按下“确认”按钮，在用户号字段内输入 456 等；（ 4 ）预期结果描述；（ 5 ）与某功能有关的场景可能要跨越“几天”时间：数据进入系统后可能后结果才有效，后续动作也才能执行。“场景”应当覆盖系统所有应完成的功能。

　　用户测试 —— 模拟真实用户的操作方式、数据

　　1. 确定用户分类；

　　2. 确定每一类用户要做什么、如何做以及怎样评价；

　　3. 获得真实的用户数据，或让真实用户进行测试；

　　4. 否则，系统化地模拟真实用户的行为（注意：不要误以为自己是真实用户）。

　　回归测试 —— 对于变更及影响部分的重复测试

　　1. 确定哪些产品元素发生变更；

　　2. 确定哪些元素受到这些变更的影响；

　　3. 选择测试内容，比如近修复的错误，以前修复的错误，新代码，敏感代码，或所有代码。

　　基于风险的测试 —— 依据产品潜在风险的高低确定测试重点，首先发现重大错误

　　1. 分析测试环境、产品元素和质量准则以确定各种风险源；

　　2. 将测试集中在具有潜在高风险的领域；

　　3. 利用测试结果来精练风险分析结果；

　　4. 注意不要完全忽视低风险领域——因为风险分析结果可能是错误的。

　　声明测试 ——验证每一个与产品有关的声明

　　1. 确定那些包括产品声明（显式的和隐式的）的参考资料；

　　2. 分析每一个声明，澄清模糊的声明；

　　3. 验证每个声明；

　　4. 如果是利用显式的规格说明进行测试，保证它与产品本身保持一致。

　　探索式测试 —— 在不断探索的过程中（迭代和并发行为）进行测试设计和执行

　　1. 产品探索，发现和记录产品目标、功能、处理的数据类型和潜在不稳定域；

　　2. 测试设计，确定产品操作、观察和评估的策略；

　　3. 测试执行，操作产品，观察结果，并使用这些信息形成产品应如何工作的假设；

　　4. 启发式规则，利用各种指导性原则帮助决定应做什么；

　　5. 可评审的结果，探索式测试是一个结果导向的过程，应确保测试结果可被评审以资证明。