-测试设计和开发新编.ppt

* 3.4 评审测试用例 复查测试用例时应该考虑的一些问题： 测试或测试组件完全针对的是需求中列出的功能吗？ 测试组件是否覆盖了所有需求？ 有冗余的测试吗？ 每一个测试步骤都有清楚描述的预期结果吗？ 测试用例是否考虑了有效和无效的输入情况？ * 测试用例的优先级 定义测试用例优先级主要考虑：必须测试什么功能？如果一些功能没被测试会出现什么后果？ 优先级1：这个测试必须执行 优先级2：如果时间允许，执行这个测试 优先级3：即使不执行这个测试，也不会导致大的质量问题 * 边界值分析是：考虑边界条件而选取测试用例的一种功能测试方法。 边界值分析关注：输入空间的边界，以标识测试用例，因为错误更可能出现在输入变量的极值附近 离点、上点、内点是我们利用边界值设计用例的关键；也是我们的一个理论依据 * * * 四、设计测试用例： * * 3、错误推测法 凭经验或直觉推测可能的错误，列出程序中可能有的错误和容易发生错误的特殊情况，选择测试用例。 把输入条件视为“因”，把输出条件视为“果”，将黑盒看成是从因到果的网络图，采用逻辑图的形式来表达功能说明书中输入条件的各种组合与输出的关系。根据这种关系可选择高效的测试用例。 因果图是一种形式化语言，是一种组合逻辑 网络图。 4、因果图法 * 一、因果图方法概述 4、因果图法 一种黑盒测试方法 方法的依据：需求规格说明中的因果关系 * 二、因果图符号 恒等 c1=1 e1=1 c1=0 e1=0 非 c1 c2 c3 c1 e1 c1 e1 e1 ∨ c1 c2 e1 ∧ c1=1 e1=0 c1=0 e1=1 c1=1 或c２=1 或c３=1 e1=１ e1=0 否则 c1=1 且c２=1 e1=１ e1=0 否则 或 与 * a 输入条件的约束 b E a c I b a b O E约束（互斥）：a,b中至多有一个可能为1即a和b不能同时为１ Ｉ约束（包含）：a,b和c中至少有一个必须是1,即a、b和c不能同时为0 O约束（唯一）：a和b中必须有一个 且仅有一个为１ * a b R R约束（要求）：a是１时，b必须是１ 　即不可能a是１时b为０ 输出条件的约束 a b M M约束（强制）：若结果a是１时， 　则结果b强制为０ * 分析规范，即将问题分为若干可工作的步骤。 标识出规范中的原因与结果。 原因—输入条件 结果—输出或系统变换 分析规范语义、内容，转换为因果图。 将因果图转换为判定表。 将判定表的每一列，转换为一个测试用例。 三、因果图法的步骤 * 四、因果图方法举例 某程序要求： 　　第一列字符必须是Ａ或Ｂ，第二列字符必须是 　一个数字，在此情况下对文件进行修改。但第一 　列字符不正确，则给出信息Ｌ；若第二列字符不 　是一个数字，则给出信息Ｍ。 分析 原因 　１——第一列字符是Ａ 　２——第一列字符是Ｂ 　３——第二列字符是一个数字 结果 　21——修改文件 　22——给出信息Ｌ 　23——给出信息Ｍ * 因果图 21 ２ ３ 22 23 １ 11 ∨ ∧ E 转换成判定表 条件桩。列出了问题的所有条件 动作桩。列出了问题规定可能采取的操作 条件项。列出针对左列条件的取值 动作项。列出在条件项的各种取值情况下应该采取的动作 * 判定表的建立步骤 确定规则的个数 列出所有条件桩和动作桩 填入条件项 填入动作项，得到初始判定表 简化、合并相似规则 * * 解 判定表和测试用例 1 2 3 4 5 6 7 8 1 1 1 1 ０ ０ ０ ０ 1 1 0 0 1 1 0 0 1 0 1 0 1 0 1 0 1 1 1 1 0 0 0 0 0 0 1 1 1 0 1 0 0 0 0 1 0 1 0 １ 测试用例 A3 A8 AB A? B5 B4 BN B! C2 X6 SDP$ 条件（原因） 动作（结果） １ ２ ３ 11 22 21 23 判定表法 判定表法经常和因果图法一起使用，先进行因果图分析，再结合判定表，最后完成测试用例。 条件和动作之间的逻辑关系是明确的，可以直接使用判定表法；如果条件和动作关系不明确，则要先使用因果图法。 * 条件桩 条件项 动作桩 动作项 判定表 举例： 订购单的检查。如果金额超过500元，又未过期，则发出批准单和提货单；如果金额超过500元，但过期了，则不发批准单；如果金额低于500元，则不论是否过期都发出批准单和提货单。在过期的情况下还需要发出通知单。将这段需求进行判定表分析。 * * 金额 500 500 =500 =500 状态 未过期 已过期 未过期 已过期 发出批准单 √ √ √ 发出提货单 √ √ √ 发出通知单 √ 订购单的检查 * 金额 500 =500 状态 未过期 已过期 已