测试准备 赵建华 南京大学计算机系
主要任务 应用已经开发的操作剖面来为高效测试作计划: 测试案例准备 测试过程准备 测试的类型包括: 功能测试 负载测试 回归测试
概念(1) 运行 输入空间 运行是操作的一个特定实例。 运行可以通过操作,输入状态(或全部输入变量以及他们的值)来刻画。 输入空间是所有可能的输入状态的集合。
概念(2) 输入变量:在操作外部且可能影响操作运行的变量。 直接变量 间接变量 源发者 操作模式 被转发者 数据库状态 记账类型 资源状态 直接输入变量:直接控制操作运行的变量,比如:参数,菜单项目等。 间接输入变量:不直接控制,而是间接影响某个操作。比如:工作负载,已运行时间等。 直接变量 间接变量 源发者 操作模式 被转发者 数据库状态 记账类型 资源状态 …
输入变量的例子 直接 间接 Originator=201 908 5577 Op Mode = prime hours Forwardee=908 555 1212 Database state: Billing type = per call Resource state: Dialing type = std Screening = yes Process Fax Call Operation of Fone Follower
概念:测试案例 测试案例通过直接输入变量及其赋值,部分地描述了运行。 一个测试案例可以在不同的间接变量下运行(比如不同的操作模式)。不同的运行可能产生不同的失效行为。 但是其可能性不如不同的操作可能引起的失效几率大。
测试案例的例子 Originator=201 908 5577 Forwardee=908 555 1212 Billing type = per call Dialing type = std Screening = yes Fone follower 的测试案例
功能测试/回归测试/负载测试 在功能测试以及回归测试中,应该控制间接输入变量,避免操作之间互相影响。 但是,负载测试中,需要考虑间接输入变量的影响。 使用测试过程来设置环境条件并在随机时刻随机地调用测试案例来完成负载测试。
操作模式/操作/运行 操作模式,操作,测试案例,运行空间 运行Xa1 测试案例 操作X Xa 操作模式1 运行Xa2 测试案例 操作X Xa 操作模式2 操作模式,操作,测试案例,运行空间
过程 测试案例准备 测试过程准备:为每个操作模式准备一个测试过程,功能包括:设置环境条件和驱动测试。 估计新版本所需要的新的测试案例的数量 在要测试的系统之间分配新测试案例的数量 在每个系统的新操作之间分配新测试案例的数量 指定测试案例 将新测试案例增加到以前版本的测试案例上 测试过程准备:为每个操作模式准备一个测试过程,功能包括:设置环境条件和驱动测试。
估计新版本所需要的案例数量(1) 首先考虑时间和成本来确定所能够设计的案例数量。然后检查这个数量对当前设定的FIO,以及系统规模来说是否足够多。 根据时间约束: 计划使用的时间*设计案例的人数/设计每个案例所需要的人时。 成本约束: 总开发预算*分配给测试案例准备的比例/每个设计案例的成本。 需要从上面两个数字中取比较小的一个。
例子 假设共有600h的时间,3.5个测试人员,每个test case需要3个小时 600*3.5/3 = 700个 整个预算2M,10%用于测试用例准备,平均每个测试用例准备时间为250。 2M*10%/250 = 800 因此共计划设计700个用例。
估计新版本所需要的案例数量(2) 根据系统地规模以及FIO,确定案例数量是否合理 新的案例一般需要多于已经测定的新操作数。一般要为每一个操作至少分配一个测试案例。 可以使用原先的经验来指导测试案例指标,比如每千行需要的测试案例。 同样数量的测试案例,可以通过案例的选择得到更加好的测试效果。 提高单位时间或者单位成本所得到的测试案例,可以有效地提高测试的效率。
在系统之间分配新的测试案例 以测试案例的数量为基础,根据系统被使用的程度,相关操作的数量来分配测试案例。 对于采办组件一般只在第一次使用的时候进行测试,所以只在第一次的时候分配测试案例。 例如:对于Fone follower系统,其操作系统将会被分配到200个test case。
在新操作之间分配测试案例数量 分为5个步骤 如果使用图形表示方法,计算出每个操作的概率。 识别很少出现的关键新操作,确定这些操作需要分配多少个案例。 确定其他新操作的分配概率。 对每个新的不经常出现的其他新操作分配至少一个测试案例。 根据分配概率分配测试案例数量。
为很少发生的操作分配案例数量 关键操作是指:操作的成功执行可以很大地增加系统的附加值,而操作失败可能带来很大的损害。 对于很少发生的关键操作,我们需要单独确定需要多少个测试案例才可以比较完整地测试其可靠性。 对于经常发生的关键操作,我们的分配方法会自然地为它分配足够的测试案例。
确定新操作的分配比率 对于新版本,所有的操作都是新的操作。每个操作的分配比率可以设定为他们的出现的概率。 对于后继版本,每个新操作的出现概率除以所有的新操作的总出现概率,就是这个操作的分配比率。
处理新的不经常出现的操作 对于每个不经常出现的新操作,至少应该分配一个操作。 否则会使得实际测试的时候和实际的使用方式不一样。 操作的分配比率和实际测试的时候执行操作的比率并不相同。 如果操作的出现概率低于0.5处以总的案例数量,那么按照通常方式它不可能分配到案例。此时应该至少分配一个案例。 有些很少出现的操作已经别合并或者清除掉了。
分配其它操作的测试案例 按照计算得到的测试案例的数量,分配测试案例数量。
例子:Fone Follower 硬件失效恢复是很少发生的关键操作,预先分配两个案例。 对于其他的操作,分配概率就是出现概率。 增加订户和删除订户是不经常发生的操作(出现概率小于0.5/500),各分配一个案例。 剩余的496个案例,分配给其他的操作。
例子:Fone Follower 0.18 89 0.17 84 处理传真呼叫 0.15 74 0.12 59 0.10 50 话音呼叫,无寻呼,有应答 0.18 89 语音呼叫,无寻呼,无应答 0.17 84 语音呼叫,有寻呼,有应答 处理传真呼叫 0.15 74 处理话音呼叫,有寻呼有对寻呼的应答 0.12 59 处理话音呼叫,有寻呼无对寻呼的应答 0.10 50 电话号码的输入 电话号码数据库审计 0.009 4 增加订户 0.0005 1 删除订户 硬件失效恢复 0.0000001 2
例子:Fone Follower 2 假设:增加了操作A,B,并且他们的出现概率都是0.1,而重用的操作的出现概率总共是0.8。总共分配200个测试案例。 无关键操作。 新操作的总出现概率是0.2,因此A和B操作分配比率都是0.1。 因此A和B各分配到100个测试案例。
指定测试案例 首先将每个直接输入变量的取值范围划分成为几个层次(level),使得每个层次中的各个值具有等价性:很可能会引起同样的失效。 对于一个操作,从每个直接输入变量的不同的层次中选择一个层次中的值,组合得到一个测试案例。 以相同的比率来选择不同的层次。 选择了测试案例之后,可以为测试准备脚本。此时可以利用各种自动化工具进行辅助。
测试过程准备(1) 需要为每个操作模式准备一个测试过程。测试过程的任务包括: 指定测试过操作剖面和操作出现率。 现场使用的数据库清理以及处理过程。 可以生成任何必要的其他非常重要的环境条件。 对于系统的第一个版本,或者后继版本,确定的测试过程操作剖面的方法有所不同。
测试过程准备(2) 对于系统的第一个版本 从每个操作模式的操作剖面开始,设计测试操作剖面。 需要处理很少发生的关键操作的问题。一般将它的测试发生概率设置为它所分配得到的案例/总的新案例个数。 此时,对于关键操作的可靠性测试具有所谓的acceleration factor。 做出上述设置后,总的测试出现概率将不等于1,因此需要做出相应的调整。
测试过程准备的例子 话音呼叫,无寻呼,有应答 0.22 0.22 0.219 语音呼叫,无寻呼,无应答 0.18 0.18 0.179 语音呼叫,有寻呼,有应答 0.18 0.18 0.179 处理传真呼叫 0.14 0.14 0.139 处理话音呼叫,有寻呼有对寻呼的应答 0.12 0.12 0.120 处理话音呼叫,有寻呼无对寻呼的应答 0.10 0.10 0.100 电话号码的输入 0.06 0.06 0.060 硬件失效恢复 0.00001 0.004 1.000
准备测试过程(3) 处理后继版本 测试的重点是该版本中的新操作(或者修改过的操作)。 对于老操作不需要象第一个版本一样充分测试。但是也不能不运行老操作。可以使用交互因子的方式来降低老版本的操作出现概率。
后继版本操作过程例子 交互因子为0.2. A 0.1 0.25 B 0.1 0.25 话音呼叫,无寻呼,有应答 0.219 0.0438 0.1095 语音呼叫,无寻呼,无应答 0.179 0.0358 0.0895 语音呼叫,有寻呼,有应答 0.179 0.0358 0.0895 处理传真呼叫 0.139 0.0278 0.0695 处理话音呼叫,有寻呼有对寻呼的应答 0.120 0.0240 0.06 处理话音呼叫,有寻呼无对寻呼的应答 0.100 0.0200 0.05 电话号码的输入 0.060 0.0120 0.03 硬件失效恢复 0.004 0.0008 0.002 1 0.4 1
和测试自动化的关系 SRE提供了确定进行怎么样的测试的方法。而测试自动化提供了如何进行更加快速测试的方式。 有两大测试自动化领域应该考虑 测试管理:设置和激发运行,记录运行过程和输出,环境清理等 失效识别:在运行的时候,自动地识别失效运行。在某些情况下有效,而有些情况下比较困难。