测试准备
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 对于新版本，所有的操作都是新的操作。 每个操作的分配比率可以设定为他们的 出现的概率。 • 对于后继版本，每个新操作的出现概率 除以所有的新操作的总出现概率，就是 这个操作的分配比率。
处理新的不经常出现的操作
• 对于每个不经常出现的新操作，至少应该分配 一个操作。
– 否则会使得实际测试的时候和实际的使用方式不一 样。 – 操作的分配比率和实际测试的时候执行操作的比率 并不相同。 – 如果操作的出现概率低于0.5处以总的案例数量，那 么按照通常方式它不可能分配到案例。此时应该至 少分配一个案例。 – 有些很少出现的操作已经别合并或者清除掉了。
Screening = yes
• Process Fax Call Operation of Fone Follower
概念：测试案例
• 测试案例通过直接输入变量及其赋值， 部分地描述了运行。 • 一个测试案例可以在不同的间接变量下 运行（比如不同的操作模式）。不同的 运行可能产生不同的失效行为。
间接变量 操作模式 数据库状 态 资源状态
输入变量的例子
直接 Originator=201 908 5577 Forwardee=908 555 1212 Billing type = per call Dialing type = std 间接 Op Mode = prime hours Database state: Resource state:
– 2M*10%/250 = 800
• 因此共计划设计700个用例。
估计新版本所需要的案例数量 （2）
• 根据系统地规模以及FIO，确定案例数量是否 合理
– 新的案例一般需要多于已经测定的新操作数。一般 要为每一个操作至少分配一个测试案例。 – 可以使用原先的经验来指导测试案例指标，比如每 千行需要的测试案例。
• 同样数量的测试案例，可以通过案例的选择得 到更加好的测试效果。 • 提高单位时间或者单位成本所得到的测试案例， 可以有效地提高测试的效率。
在系统之间分配新的测试案例
• 以测试案例的数量为基础，根据系统被 使用的程度，相关操作的数量来分配测 试案例。 • 对于采办组件一般只在第一次使用的时 候进行测试，所以只在第一次的时候分 配测试案例。
– 但是其可能性不如不同的操作可能引起的失 效几率大。
测试案例的例子
Originator=201 908 5577 Forwardee=908 555 1212 Billing type = per call Dialing type = std Screening = yes
• Fone follower 的测试案例
功能测试/回归测试/负载测试
• 在功能测试以及回归测试中，应该控制 间接输入变量，避免操作之间互相影响。 • 但是，负载测试中，需要考虑间接输入 变量的影响。
– 使用测试过程来设置环境条件并在随机时刻 随机地调用测试案例来完成负载测试。
操作模式/操作/运行
运行Xa1 测试 案例 操作X Xa 操作模式1
• 成本约束：
– 总开发预算*分配给测试案例准备的比例/每个设计 案例的成本。
• 需要从上面两个数字中取比较小的一个。
例子
• 假设共有600h的时间，3.5个测试人员， 每个test caseBiblioteka Baidu要3个小时
– 600*3.5/3 = 700个
• 整个预算2M，10%用于测试用例准备， 平均每个测试用例准备时间为250。
测试准备
赵建华 南京大学计算机系
主要任务
• 应用已经开发的操作剖面来为高效测试 作计划：
– 测试案例准备 – 测试过程准备
• 测试的类型包括：
– 功能测试 – 负载测试 – 回归测试
概念（1）
• 运行
– 运行是操作的一个特定实例。 – 运行可以通过操作，输入状态（或全部输入 变量以及他们的值）来刻画。
– 例如：对于Fone follower系统，其操作系统 将会被分配到200个test case。
在新操作之间分配测试案例数量
• 分为5个步骤
– 如果使用图形表示方法，计算出每个操作的 概率。 – 识别很少出现的关键新操作，确定这些操作 需要分配多少个案例。 – 确定其他新操作的分配概率。 – 对每个新的不经常出现的其他新操作分配至 少一个测试案例。 – 根据分配概率分配测试案例数量。
分配其它操作的测试案例
• 按照计算得到的测试案例的数量，分配 测试案例数量。
例子：Fone Follower
• 硬件失效恢复是很少发生的关键操作，预 先分配两个案例。 • 对于其他的操作，分配概率就是出现概率。 • 增加订户和删除订户是不经常发生的操作 （出现概率小于0.5/500），各分配一个 案例。 • 剩余的496个案例，分配给其他的操作。
运行Xa2
测试 案例 操作X Xa 操作模式2
• 操作模式，操作，测试案例，运行空间
过程
• 测试案例准备
– – – – – 估计新版本所需要的新的测试案例的数量 在要测试的系统之间分配新测试案例的数量 在每个系统的新操作之间分配新测试案例的数量 指定测试案例 将新测试案例增加到以前版本的测试案例上
• 输入空间
– 输入空间是所有可能的输入状态的集合。
概念（2）
• 输入变量：在操作外 部且可能影响操作运 行的变量。 直接变量 源发者 – 直接输入变量：直接控 制操作运行的变量，比 被转发者
如：参数，菜单项目等。 – 间接输入变量：不直接 记账类型 控制，而是间接影响某 … 个操作。比如：工作负 载，已运行时间等。
• 测试过程准备：为每个操作模式准备一个测试 过程，功能包括：设置环境条件和驱动测试。
估计新版本所需要的案例数量 （1）
• 首先考虑时间和成本来确定所能够设计的案例 数量。然后检查这个数量对当前设定的FIO， 以及系统规模来说是否足够多。 • 根据时间约束:
– 计划使用的时间*设计案例的人数/设计每个案例所 需要的人时。
为很少发生的操作分配案例数量
• 关键操作是指：操作的成功执行可以很 大地增加系统的附加值，而操作失败可 能带来很大的损害。 • 对于很少发生的关键操作，我们需要单 独确定需要多少个测试案例才可以比较 完整地测试其可靠性。
– 对于经常发生的关键操作，我们的分配方法 会自然地为它分配足够的测试案例。
确定新操作的分配比率
处理新的不经常出现的操作
• 对于每个不经常出现的新操作，至少应该分配 一个操作。
– 否则会使得实际测试的时候和实际的使用方式不一 样。 – 操作的分配比率和实际测试的时候执行操作的比率 并不相同。 – 如果操作的出现概率低于0.5处以总的案例数量，那 么按照通常方式它不可能分配到案例。此时应该至 少分配一个案例。 – 有些很少出现的操作已经别合并或者清除掉了。
Screening = yes
• Process Fax Call Operation of Fone Follower
概念：测试案例
• 测试案例通过直接输入变量及其赋值， 部分地描述了运行。 • 一个测试案例可以在不同的间接变量下 运行（比如不同的操作模式）。不同的 运行可能产生不同的失效行为。
间接变量 操作模式 数据库状 态 资源状态
输入变量的例子
直接 Originator=201 908 5577 Forwardee=908 555 1212 Billing type = per call Dialing type = std 间接 Op Mode = prime hours Database state: Resource state:
– 2M*10%/250 = 800
• 因此共计划设计700个用例。
估计新版本所需要的案例数量 （2）
• 根据系统地规模以及FIO，确定案例数量是否 合理
– 新的案例一般需要多于已经测定的新操作数。一般 要为每一个操作至少分配一个测试案例。 – 可以使用原先的经验来指导测试案例指标，比如每 千行需要的测试案例。
• 同样数量的测试案例，可以通过案例的选择得 到更加好的测试效果。 • 提高单位时间或者单位成本所得到的测试案例， 可以有效地提高测试的效率。
在系统之间分配新的测试案例
• 以测试案例的数量为基础，根据系统被 使用的程度，相关操作的数量来分配测 试案例。 • 对于采办组件一般只在第一次使用的时 候进行测试，所以只在第一次的时候分 配测试案例。
– 但是其可能性不如不同的操作可能引起的失 效几率大。
测试案例的例子
Originator=201 908 5577 Forwardee=908 555 1212 Billing type = per call Dialing type = std Screening = yes
• Fone follower 的测试案例
功能测试/回归测试/负载测试
• 在功能测试以及回归测试中，应该控制 间接输入变量，避免操作之间互相影响。 • 但是，负载测试中，需要考虑间接输入 变量的影响。
– 使用测试过程来设置环境条件并在随机时刻 随机地调用测试案例来完成负载测试。
操作模式/操作/运行
运行Xa1 测试 案例 操作X Xa 操作模式1
• 成本约束：
– 总开发预算*分配给测试案例准备的比例/每个设计 案例的成本。
• 需要从上面两个数字中取比较小的一个。
例子
• 假设共有600h的时间，3.5个测试人员， 每个test caseBiblioteka Baidu要3个小时
– 600*3.5/3 = 700个
• 整个预算2M，10%用于测试用例准备， 平均每个测试用例准备时间为250。
测试准备
赵建华 南京大学计算机系
主要任务
• 应用已经开发的操作剖面来为高效测试 作计划：
– 测试案例准备 – 测试过程准备
• 测试的类型包括：
– 功能测试 – 负载测试 – 回归测试
概念（1）
• 运行
– 运行是操作的一个特定实例。 – 运行可以通过操作，输入状态（或全部输入 变量以及他们的值）来刻画。
– 例如：对于Fone follower系统，其操作系统 将会被分配到200个test case。
在新操作之间分配测试案例数量
• 分为5个步骤
– 如果使用图形表示方法，计算出每个操作的 概率。 – 识别很少出现的关键新操作，确定这些操作 需要分配多少个案例。 – 确定其他新操作的分配概率。 – 对每个新的不经常出现的其他新操作分配至 少一个测试案例。 – 根据分配概率分配测试案例数量。
分配其它操作的测试案例
• 按照计算得到的测试案例的数量，分配 测试案例数量。
例子：Fone Follower
• 硬件失效恢复是很少发生的关键操作，预 先分配两个案例。 • 对于其他的操作，分配概率就是出现概率。 • 增加订户和删除订户是不经常发生的操作 （出现概率小于0.5/500），各分配一个 案例。 • 剩余的496个案例，分配给其他的操作。
运行Xa2
测试 案例 操作X Xa 操作模式2
• 操作模式，操作，测试案例，运行空间
过程
• 测试案例准备
– – – – – 估计新版本所需要的新的测试案例的数量 在要测试的系统之间分配新测试案例的数量 在每个系统的新操作之间分配新测试案例的数量 指定测试案例 将新测试案例增加到以前版本的测试案例上
• 输入空间
– 输入空间是所有可能的输入状态的集合。
概念（2）
• 输入变量：在操作外 部且可能影响操作运 行的变量。 直接变量 源发者 – 直接输入变量：直接控 制操作运行的变量，比 被转发者
如：参数，菜单项目等。 – 间接输入变量：不直接 记账类型 控制，而是间接影响某 … 个操作。比如：工作负 载，已运行时间等。
• 测试过程准备：为每个操作模式准备一个测试 过程，功能包括：设置环境条件和驱动测试。
估计新版本所需要的案例数量 （1）
• 首先考虑时间和成本来确定所能够设计的案例 数量。然后检查这个数量对当前设定的FIO， 以及系统规模来说是否足够多。 • 根据时间约束:
– 计划使用的时间*设计案例的人数/设计每个案例所 需要的人时。
为很少发生的操作分配案例数量
• 关键操作是指：操作的成功执行可以很 大地增加系统的附加值，而操作失败可 能带来很大的损害。 • 对于很少发生的关键操作，我们需要单 独确定需要多少个测试案例才可以比较 完整地测试其可靠性。
– 对于经常发生的关键操作，我们的分配方法 会自然地为它分配足够的测试案例。
确定新操作的分配比率