漫谈自动化测试

测试与自动化测试 首先,我们先来澄清一下一个对于我们测试的工作究竟是为了啥而干些啥 “软件测试” 的经典定义是:

在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。


漫谈自动化测试
文章图片
房子找Bug---测试(炸弹就是bug) 这种定义,我们刚看的时候,估计看得晕乎乎的,对于我来说,我打个现实而简单的身边例子来简单描述这样的一个过程:
【漫谈自动化测试】 建(装修)房子过程的监工和验收过程。
过程中开发类似是房子设计师和工程师,测试类似是监工和验收工。
所谓测试就是整过建房子的过程中通过各种方法发现房子的各种问题,衡量房子质量,保证房子能建成并满足目标的人群购置使用
。如图,炸弹比喻成可能出现在房子任意地方的Bug.
为什么要强调一下测试的定义呢,因为这关乎到我们将要说到的关键: “自动化测试的定义”,说到自动化测试,大家可能比较快速地反应到这样的定义: 自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程,即模拟手工测试步骤通过执行程序语言编制的测试脚本自动地测试软件。这句课本的定义,我们一句简单地定义是这样的:
狭义自动化: 把手工测的,搞成让机器用代码测


漫谈自动化测试
文章图片
机器人找Bug---狭义自动化 而我们今天,要重申广义自动化:
广义自动化: 包括一切通过工具(程序)的方式来代替或辅助手工测试的行为都可以看做自动化
重新回到我们上面的例子类比,狭义自动化:找个机器人来按人定义好的方法来发现房子的问题和衡量质量。广义自动化就是:包括用机器人和用其他工具来发现房子的问题和衡量质量


漫谈自动化测试
文章图片
用各种工具协助发现bug --- 广义自动化 测试的价值和难题 自动化测试的价值不可避免地涉及到测试的价值,测试的价值:
用一定资源(时间、人力)的代价,发现软件Bug,保证与评估软件的质量(正确性、可维护性、完整性和可用性).
这里,说到测试,类比上面所说的房子施工队验收,我们假设看到的整个房子是我们整个软件所可能的所有客户场景,客户使用房子,就跟客户使用软件一样,变动任何一个位置,就是一种变化的客户场景,想保证整个房子一点毛病没有,其实唯一的办法就是挖地三尺,地毯式扫描,对整个房子的所有区域,每一毫米都扫描过,才能保证一点毛病没有,但是测试本身就是一个成本折衷的事情,扫描完整个房子任务庞大性是的它是个几乎不可能完成任务。所以我们才有所谓bvt用例,多种等级(1~N)用例。
漫谈自动化测试
文章图片
测试分析与测试过程中难题 测试的难题: 整个测试设计所能覆盖的区域是有限的,很多地方因为测试执行的难度,也会变成测试不可达的地方,还有一些人类分析能力不能达到的区域(如经验不足)所引起的覆盖不到。并且因为开发是一个持续的过程,开发者(房子建筑工程师)对于软件(房子)会持续地修改调整,同时持续地对产品产出Bug(就像一个随处走并且持续埋雷的人)。这些都是测试过程中,很不好解决的难题。这些测试的难题,持续地存在,实际上不可能完全地解决。
所以整个测试过程,核心价值就只有两个矛盾:1. 难以增长的测试资源(时间、人力、技术)。2. 有限的测试覆盖范围。

这两个正是鱼与熊掌不可兼得的矛盾,任何测试方面的努力,都是围绕着怎么在这两者尽量取的“鱼与熊掌兼得”的效果。
自动化的价值 狭义自动化的价值
狭义自动化,就是把人工执行的测试转化为用代码命令机器去做执行。它主要是指功能自动化。显而易见地这种做法,所有的好处都是由“机器”这个执行主体带来的:
1. 不会疲劳或分心
2. 可以反复重现、回归
3. 可以利用数据进行一定范围的地毯式覆盖
所以其对于产品的价值也仅限于一种“守成者”的效果:
1. 降低因反复执行老用例而带来的工作量。
2. 守护已经测试过的逻辑,防护改动引发的问题。
3. 减少反复类似的用例执行带来的工作量。
而且它依赖于测试分析设计,对于质量的保证效果,依赖于测试分析的效果。它对于质量的作用,其实是没有太多“加强”的作用,更多的是守成,保护已测过了的后续没有问题(改动引发)


广义自动化的价值

广义自动化,包括一切通过工具(程序)的方式来代替或辅助手工测试的行为都可以看做自动化。 它涵盖的就比较广,包括我们的测试工具辅助(性能)测试,接口测试,单元测试,代码扫描等,都属于此含义内(把单测看着利用单测工具对软件进行测试,代码扫描看做利用代码扫描工具对软件进行测试)。这些测试的对于产品的价值,都是由于使用了某种形式的工具来实现的:

1. 工具提供的便利降低了测试的工作量
2. 工具的功能增加了测试的覆盖度,测到了人手工测不到的
3. 工具的快速,增加了快速迭代的效率


自动化的代价


所有的自动化都有共同的代价,这里就不区分狭义自动化和广义自动化了。
创造代价
创造代价,意思是一项自动化从无到有的整个过程的代价,其中就包括创造实现它的代价(狭义自动化框架设计,相关用例实现成本,相关引入测试工具的学习成本,相关自主实现的工具的实现成本和学习成本)。
维护代价
所有的自动化,都有维护自动化的代价,因为无论任意形式的自动化,都需要维护它的代价,不同形式的自动化,有其不同的维护代价。维护代价一般包括:用例维护代价,测试工具测试方式(方法)维护代价,这些维护代价,源头都是由于软件的日益变化,代价的大小,都跟软件变化大小,自动化的适应能力有关系。
运行代价
所有的自动化,都有其运行代价,这个运行代价就包括执行一次测试,所需要的人力和时间,也包括这次运行的结论得出所需要的人力和时间。具体就类似狭义自动化(功能自动化)以及单测还有接口测试的用例执行时间和用例分析时间,以及这两者需要占用人力的工作量,类似工具辅助测试的执行时间和执行成本。


自动化的评价 什么才是最好的自动化? 用一句话表达就是:
用最低的代价,实现最大的软件覆盖度的自动化,就是最好的自动化。
详细而言,就是创造代价和维护代价以及运行代价都很低,然而覆盖度却涵盖软件的方方面面,能扫到整个房子的每个角落。但是,细细想这个评价标准,本质上,是存在一定的矛盾的,这个矛盾主要就是增大覆盖度自然而然会带来代价,低代价和高覆盖,就像测试本身的两个矛盾,是一个变通的求最优解的过程。
具体地,对于我们公司的自动化评价也是一样跟随这个原则:
狭义自动化(功能自动化): 更高的覆盖度,更容易更快速地编写一个自动化用例,更快速地运行用例,更高的自动化用例稳定性,更容易快速地完成测试运行分析,就是一个更好的自动化。
广义自动化: 能增加更多的覆盖度,更低的创造代价和维护代价以及运行代价,就是更好的广义自动化。

    推荐阅读