开源软件测试模型(4)

　　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. 可评审的结果，探索式测试是一个结果导向的过程，应确保测试结果可被评审以资证明。

原文转自：http://www.uml.org.cn/Test/201106012.asp