imageview设置在最顶层_最重要的自动化测试概念-断言讨论

最重要的自动化测试概念-断言讨论

1， 断言

测试任何一个功能，包含3个步骤：

1， 提供被测功能的输入

2， 等待被测功能执行

3， 对结果进行判断(断言)。

其中步骤1和步骤3如果需要人工干预，则称其为手工测试，如果不需要，则可以称其为自动化的测试。

从测试的金字塔模型来看，越是往顶层的测试越是直接代表用户需求，价值越大，但是自动化的可能性越小，越往底层，工作量越大，好处是自动化的可能性越来越大。自动化的好处在于，可以将任务交给计算机来执行，而不需要消耗人的宝贵精力，而这正是软件开发的最大的成本。自动化的程度越高，人的精力才能集中在靠近顶层的用户。

自动化的测试一大关键要素就是要求断言的自动化，习惯了命令式(过程式)编程或者思考方式的人，对于需要进行判断结果是否正确的情况，第一时间想到的肯定就是用编程语言里的if语句来进行判断。这种处理方式在需要人工干预的测试场景下，可能还有一席用武之地，但是对于一个自动化的测试场景来说，是行不通的，原因如下：

1， 通过if语句进行的判断没有持久化(存储到硬盘)

测试执行完毕以后，没有留下判断的痕迹。所有的自动化的测试工具，都是依赖断言来进行结果判断的。通过断言来进行判断的好处就在于断言的结果是持久化的，可以在运行完毕以后随时查看，统计。

2， 通过if来进行的判断很难有一个标准的模式

如果希望通过测试运行后留下的测试数据来进行判断测试的结果通过与否，希望在测试失败的了的情况下了解到在什么情况下失败了(当时输入的值是什么？预期的输出是什么？实际的输出是什么)，这些能力都需要一个一致有效的判断机制，这就是断言的标准行为。

ETest里的断言包含了上述的3个要输，先看一下使用python的if进行结果判断的大该方法以及输出信息。

输出信息在IO中心，一旦数据被挤出去或者关闭了进程，就无法追溯到测试过程了。

下面看使用ETest提供的断言API来进行判断的效果：

右边的界面内容是从历史数据里查看到的，可以追溯任何一次测试的结果，这一点尤其在回归测试的时候更加重要，无法追溯的化，就无法做回归测试。

这是断言的最典型的使用方式，但是这种断言的方式基于严格的比较，得出通过与否的结论，比如假如期望值是3，而实际值是3.0001，那么断言就会判断其未通过，即使实际上被测系统允许有一定的误差也不行，从下图的效果看：

这种情况下就需要通过脚本来干预断言的最终结果了，如下图：

为什么说测试脚本里不应该包含更多的if，for之类的语句呢，主要有以下原因：

1， 一个测试用例是一条确定的路径，测试的执行者不存在还需要做决策判断的需求。这一点理解起来并不容易，暂时可以先当成一个原则来实践，多实践几次就理解了。

2， 假如测试代码里还包含了复杂的程序结构(if for之类的)，假如测试失败了，那么测试的执行者如何确定是测试代码的出错还是待测系统的出错？

3， 测试执行者(人工或者自动话的测试脚本)要做而且仅做3件事，输入数据，等待待测系统执行，获取待测系统的结果进行断言，这三件事情里没有一件是需要进行决策的(除了在最后断言下结论的时候需要参考一下实际的误差范围)。

2，组合测试模型

1， 示例背景

假设客户需要配置一批用于各种环境下的电脑，需要对软硬件配置的兼容性进行测试，需要测试各项指标如下：

PLATFORM: x86, ia64, amd64

CPUS: Single, Dual, Quad

RAM: 128MB, 1GB, 4GB, 64GB

HDD: SCSI, IDE

OS: NT4, Win2K, WinXP, Win2K3

IE: 4.0, 5.0, 5.5, 6.0

APP: SQLServer, Exchange, Office

如果使用简单粗暴的正交组合方式来测试各种配置下的兼容性，那么就会有3*3*4*2*4*4*3=3456种配置需要测试，在软硬件都需要进行配置的情况下工作量近乎无法完成。

这种情况下可以使用组合测试工具进行合理的组合，用尽可能少的测试用例覆盖尽可能多的路径。

2， 参数信息

打开【组合测试模型编辑器】界面，新建测试模型，建立与上面一致的参数描述信息

参数的取值点击按钮【…】，可以参数的取值进行添加删除修改等操作

参数的取值的【反向测试】【权重】属性，见【PICT用户手册】的对应章节。【映射值】属性可以帮助用户将参数的取值映射到一个与执行语言兼容的数据值上，是可选项，可以忽略。

【添加取值策略】按钮可以辅助用户对参数进行换份取值

假如参数的定义类似上面提供的模式，则可以点击该模式进行辅助添加，如果都不类似可以选择【我要手工输入】

3,子模型

组合算法默认对所有的参数都是平等对待，但是现实中可能更加关心其中的部分参数，希望对这部分参数的测试路径加大覆盖率，则可以定义子模型。

假如希望对提高下面4个参数的覆盖率：PLATFORM, CPUS, RAM, HDD，则可以点击【添加子模型】，然后添加4个参数，分别设置为对应的参数名，将阶数修改为3(默认为2)，代价是会在最终的测试结果中增加测试用例的数量。

4,约束

理想情况下参数之间各自独立，但是实际上参数之间会有一些关联，比如IE6不能安装在NT4的操作系统上，则可以在约束面板上点击【添加约束】。

点击【配置】，在【如果】面板里点击【添加】，设置参数如下：

在【那么】面板里点击【添加】，设置参数如下：

那么这个约束代表的意思就是：假如操作系统是NT4，那么IE的版本就不能是IE6。

约束编辑器提供了分组的功能，可以生成复杂的约束条件，如下约束：

假如[PLATFORM] = "ia64" AND ([CPUS] = "Quad" OR [RAM] < "1GB")

那么THEN [OS] = "NT4"

则可以按如下操作设置：

其他更复杂的约束，可以以此类推，通过约束，能明显减少测试用例的数量。

5,种子

组合测试算法默认视每条测试路径的价值都是相等的，但是现实中可能有部分的测试路径更加关键，那么可以将这部分路径作为种子路径看待，保证组合测试用例的时候总是包含这些种子路径，而且不会明显增加测试用例的数量。

假如没有建立过种子，则点击【重新生成】可以生成空的种子模板，【添加】【删除】可以增加或删除设置好的种子。单元格编辑通过下拉选择完成，可以为空。为空的情况下，组合算法会自动为您填充合适的值。

6，选项

选项用来控制组合算法的内部参数。

组合阶数默认为2，假如有5个参数，其值设置为5，则测试用例的数量最大，等价于正交组合的数量。

随机化生成可以使每次生成的测试用例都不一样。

7，导出脚本

导出脚本可以将当前模型导出到指定的目录，包括模型文件model.txt,种子文件(假如设置了种子的化)SeedRows.txt,一个生成脚本文件make.bat。内容如下：

运行make.bat,可以生成如下结果：

Message.txt文件保存生成过程产生的消息，警告或错误信息

TestCase.Xml文件保存测试用例表，类似如下格式：

8，生成测试用例

点击【生成测试用例】将根据当前的组合模型，生成测试用例，如果发生错误则在错误栏里提示错误信息，否则在测试用例栏里显示测试用例表的内容,如下：

3， 表格数据

可以通过excel编写一个表格文件，然后导入到系统中来，表格的每一行是一个测试用例(测试用例指一组输入，ETest里讲测试用例的概念混淆于测试脚本了，这一点在后续的版本里将慢慢纠正过来，测试脚本仅仅只是测试用例的一种形式的执行者而已)。一个表格就代表了一组测试，可以通过一个脚本执行这一组测试。

还是测试前面模拟的待测系统，假如最终的测试用例表格如下，中间有两行数据有问题(测试最终的结果依赖于实际和预期是否一致，从效果上来看，用例错了和待测系统错了效果是一样的，都是失败，这里是为了交流故意将用例弄错，毕竟那么简单的一个被测函数想弄错还不容易)

采用表格驱动测试的方式写的脚本及执行效果如下：

可以从历史数据里看出对应的两个测试失败了。

从脚本来看，用来执行用例的脚本部分和之前的测试脚本没有什么区别

组合测试的最终结果也是一个表格，所以从测试脚本的API里来看，和表格的API是雷同的。