20101020课上PPT.pptVIP

提出这个测试思想的是Rational公司 现在的软件基本都是用事件触发来控制流程的 事件触发时的情景便形成了场景 而同一事件的不同的触发顺序和处理结果就形成了事件流 分析软件的应用场景，从用户角度出发来设计TC 其主旨是关心用户可以做什么，而不关心软件可以做什么 找出所有会影响结果的环境因素 找出场景中可能发生的事件系列 将环境因素和事件系列进行组合，并分析推导，得到不同的场景（一个确定的环境+确定的事件就构成一个场景） 每个缺陷都可以对应一个场景，每个可测试数据也可以对应一个场景，场景可能像缺陷空间或测试空间一样大，因此它也是不可穷尽的，需简化 场景可以分为显性场景和隐性场景 显性场景：可以在软件需求规格说明中找到，或者能容易地从软件需求规格说明中推导出来 例：WINDOWS系统中的GUI外观设置、颜色搭配 隐性场景：反之 例：色盲用户 用例场景——用来描述流经TC的路径 从用例开始到结束，遍历这条路径上的所有基本流和备选流 基本流：经过TC的最简单路径 即最顺利的操作流程，完全顺利，毫无意外 森林中，有树，树上有鸟，猎人带枪进入树林（枪内有足够的子弹） 我们来构造尽可能多的场景 最简：猎人开枪，打中的鸟坠落，余下的惊飞 继续…… 打中的鸟一定失去飞行能力，无法逃走 打中的鸟一定掉下来，而不会挂在树上 猎人瞄准时可能有鸟自然飞走 猎人使用的是无声手枪 猎人不可能一枪打中一只鸟 猎人也可能打不中 鸟中有失去听力的 鸟中有老弱病残，危险时也未必能马上飞走 四人在晚上过一座桥，过桥须用手电照明，现只有一支手电，每次最多两人过桥（多了会塌）四人的过桥速度分别是1、2、5、10（分钟），两人过桥时以慢的人速度为共同速度，问：最少用多少分钟，四人才能全部过桥？ 我们来构造尽可能多的场景 先假设： A、B先用手电同过，共用2分钟 A携带手电返回，用1分钟 C、D使用手电同过，共用10分钟 B携带手电返回，用2分钟 A、B再次使用手电过桥，共用2分钟 2+1+10+2+2=17分钟 本题其实是图论问题：求图的最短路径 可以现根据过桥的状态建立一张有向图，其最短路径就是最少的过桥时间。 ATM基本业务模型 测试原则之1：完全测试是不可能的 测试新手可能认为，在拿到软件后进行完全的测试，找出所有缺陷即可确保软件完美无缺——这实际上是根本不可能的，即使是面对最简单的程序也不可能。主要原因在于： 输入量太大 输出结果太多 软件的执行路径太多 不能采用逻辑来证明程序的正确性 假设我们先从加法入手开始测试： 测试加法功能是否正常，并非随意寻找两个数字相加，所得结果与实际相符合就算通过，而是要把两个参与运算的数字的各种可能全部取到，一一测试成功后，才算加法功能经过了完全测试 具体来说，得从1+0、1+1、……一直走到无限远。同时由于计算机可以处理32位的数字，所以必须测试所有的可能性，即测试过1+9……9（共32个9）之后，还要继续输入2+0、2+1……、2+9……9（32个）等，直至9……9+9……9为止。这才完成了整数加中正数相加的一小部分 接着是测试小数部分：1.0+0.1、1.0+0.2、……依次类推，这才完成了小数加中正数相加的一小部分 验证完正常的数字相加均正确无误后，还要测试非法输入是否能得到正确的处理：不仅可以单击界面上的数字键进行运算，还可以按动键盘上的任意键来查看会引发何种反应 我们发现，好的测试数据，如同好的密码一样，越是不可猜测的组合越能够保证效果。当然这些组合的可能性非常多，全都是合法而优秀的测试数据，但我们不可能一一选用 另外，输入数据的编辑修改也必须进行测试 如在计算器程序中已声明允许使用退格键和删除键去掉错误的输入，那么就需要测试退格和删除键是否能起到正常的作用，如：1退格2+2，结果是否等于4？ 成立以后，还需要把之前所有做过的测试再逐个引入退格键来重新测试一遍，看它们在引入退格键后是否还是正确的（尤其在多个数相加的过程中，退格键参与的用例将有更多可能的组合） 以上是两个操作数的加法…… 还需验证三、四、五……等多个数的相加，如此下去，完成加法的测试也要数十年以上 以上是针对加法的部分测试（还没有算上操作数含负数的情况），完成它们之后，还有-、*、/、%、开方、求倒数等的测试需要做 看完以上这些，还有人坚持选择完全测试吗？ 计算器程序还只是一个功能极简单的小型程序，很多真正的大型软件，其中一个极微小的子功能，都要比计算器程序复杂得多 可见，完全测试是不可能的。如果觉得某些测试条件是重复、无必要的，或为了节省时间、空间而将其剔除，那么采用的就只是不完全测试 等价类法的引入 创建测试用例是测试员的基本工作 测试用例的存在意义，是揭示软件缺陷 但测试用例往往数量巨大（因而不能做到彻底执行测试） “能否揭示软件缺陷”