接口用例之好用例和坏用例

  自动化测试的重要性显而易见,但自动化测试又无法解决所有问题,所以说完全依赖自动化是不可能的,但完全没有自动化是万万不能。在软件开发项目中,重度依赖人力进行持续回归是一件非常枯燥的重复工作。企业需要花费大量的时间和金钱来维持这样一支队伍以保证产品质量,而队伍中的同学在每天重复劳动的工作之下,也丝毫得不到成长,看不到方向。
  尽管自动化测试不能解决所有问题,但是却拥有一个优势:“Once” Written, Run Anytime as Desired(一旦写好,即可随意重复执行)。所以,自动化测试通常都会跟持续集成系统(比如Jenkins)配合使用,就像“良辰美景”要配上“月光杯”才算的上是极致。这样我们可以避免在软件上线或交付的最后一刻,还深陷软件问题的泥潭中。当然,这也是敏捷开发的关键所在,把问题消灭在过程中,只需持续关注增量内容。另外,在持续集成中,可以根据自己的需求来确定自动化测试的触发频次和时间,比如“代码提交”、“定时触发”等。
  万物皆有阴阳两面,自动化测试有这么多优势,当然也有它的劣势。所以,至今仍然有很多公司自动化水平不高。我们分析一下这些劣势,主要有以下几方面:
对测试人员要求相对较高。
  测试用例需要根据版本迭代进行更新,有一定维护成本。
  测试结果不一定可靠,测试用例也分“好”、“坏”。

  前面两点也是大家公知的问题,每个公司各有自己的情况判断,今天也不做赘述。今天我主要讨论第三个问题,也就是:怎么保证我们花了时间和精力去做的自动化测试,其结果是有效的、是能够反映被测代码质量的?

一、 测试用例也分好坏

  对于标题,你可能会有疑问,测试用例竟然也有好坏?的确,测试用例也有好坏之分,那么什么是坏用例?什么是好用例?那要先从测试用例的特征说起:
自动化测试或者测试用例的根本目的就是judge(判断)被测系统是否有问题,是以衡量被测产品的“标尺”存在的。所以,它具备一个重要的特征:在测试脚本和被测代码都保持不变的情况下,测试结果应该是稳定的、不变的。
根据这个原则,“坏用例”并不是指测试不通过的用例,更不是测试通过的用例,而是指那些在相同条件下,偶尔通过、偶尔不通过的测试用例。反之,“好用例”则是表现稳定的用例。
  为什么说“坏用例”破坏性大?因为如果用例本身不具备稳定的结果输出,就无法准确的衡量被测产品是代码的问题还是用例本身的问题。如果每次测试结果都不能直接说明问题,需要进行反复分析,将直接导致大家对测试用例失去信心。也就是说,测试同学和开发同学会把测试用例的不通过,当成“Warning”而非“Error”,这样的最终效果就是自动化测试慢慢被抛弃。

二、 测试用例的生命周期

  有了“好用例”、“坏用例”的区分,测试用例就是“鲜活”的了。事实上,我们也可以规划处一个测试用例从生到死的生命周期。

  一般情况下,我们可以以测试用例通过率或通过次数来为其划分“好/坏”。随着执行次数的增多,测试用例可以切换“好/坏”状态,当“坏用例”持续一段时间之后,我们可以把它标记为“垃圾用例”,并从自动化执行的序列中剔除。“坏用例”和“垃圾用例”可以被开发或者测试同学修复,然后进入“未知状态”。“未知状态”中的应用随着执行次数的增加,不断的在这个生命周期里循环往复。

三、 如何消灭坏用例

  至此,我们明白了测试用例的“好/坏”之分,也了解了测试用例的生命周期。那么,我们如何保证用例质量,“消灭坏用例”呢?

  1,通过“CI”(Continuous Integration持续集成)发现“坏用例”
  “坏用例”指的是偶尔不通过、偶尔通过的用例。所以,你会发现在本地运行的时候很难发现“坏用例”,因为“坏用例”需要被执行很多次才能被检测出来。执行很多次的过程可以非常好地通过CI系统来帮助实现,所以,如果你还没有使用CI系统,也依然建议使用持续集成工具进行多次的执行用例,即便你的工程量很小。另外一点,CI系统可以在一天不同的时刻执行用例,而时间也是一个“坏用例”产生的可能属性。
当然,成熟的CI系统(比如Jenkins)都可以满足绝大部分人的业务需求

  2,防微杜渐
  可能大家都听过“破窗理论”:当房子上的一扇窗户的玻璃被打破,如果不及时修复,将会有破坏者破坏更多的窗户。“坏用例”现象也是一样的,当出现一个“坏用例”时,如果不抓紧修复,整个测试用例集甚至自动化测试结果的可信度都将快速下滑。
对“坏用例”采取零容忍的态度,有助于整体自动化水平和质量的提升。可以建立测试或开发人员“坏用例”档案,并自动追踪每一个“坏用例”的来源,督促负责人跟进解决。

  3,避免执行环境差异
  例如,保证本地用例执行时的环境与CI执行用例环境是一致的。

  4,使用异步等待
  通常,一个测试用例多个测试步骤组合而成,每一个测试步骤都需要特定的执行时间,所以,大家写测试用例一般的做法就是等待特定的时长,比如5秒。但是相同的测试步骤在每次用例执行过程中的时长并不相同,并且有时差异还会很大。这往往会导致上一步还未完成,下一步就开始执行,导致“坏用例”的产生。
另外,即便是步骤执行没有超时,但依然可能造成时间上的浪费,比如一个步骤等待5s,但实际执行只用了2s,就有3s的时间浪费。
理论上,解决这个问题有两种方式:回调、轮询。回调是指,上一步执行完成后,通知执行测试用例的进程/线程继续下一步。但这种方式在实际中并不采用,因为它需要紧耦合被测系统,可能为被测系统带来新的问题和维护成本。所以,实际中,更多的采用的是以“观察者”身份存在的轮询。比如说,以很小的时间间隔来不断查询是否到达下一步执行的状态。这样就能够避免一定程度的“坏用例”的产生。

  5,解决并行执行的问题
  如果测试用例存在并行执行的情况,请确保多个测试用例之间不会因为相互对被测系统的影响导致冲突,从而使用例变成“坏用例”。比如,在所有测试用例执行过程中,数据库相关操作都采取事务的方式,用例执行完成后,就立即进行回滚。

  6,避免测试用例互相依赖
  如果一个用例集中的测试用例时相互依赖的,那如果其中有一个“坏用例”出现,将会导致整个用例集不稳定。所以,尽量保证用例集中的每一个用例没有相互依赖关系,每一个都可以独立执行验证。

  7,避免测试脚本太长
毫无疑问,一个测试用例的步骤越多,可能变成“坏用例”的概率越高,所以,一般情况下,一个App的测试用例不超过在30步最好。

  8,提高测试用例代码水平
一个“好用例”除了结果足够稳定之外,还需要具备良好的结构设计,以及良好的可读性、可维护性。这一点对测试用例编写人员要求较高,当然,通过多读、多思、多写,能够很快的提高自己的自动化用例编写能力。

本文转自:https://testerhome.com/topics/5921,作者:vividly

时间: 2024-10-08 21:59:44

接口用例之好用例和坏用例的相关文章

python接口自动化(二十六)--批量执行用例 discover(详解)

简介 我们在写用例的时候,单个脚本的用例好执行,那么多个脚本的时候,如何批量执行呢?这时候就需要用到 unittest 里面的 discover 方法来加载用例了.加载用例后,用 unittest 里面的 TextTestRunner 这里类的 run 方法去一次执行多个脚 本的用例.那么前边介绍那么多都是半道开始,半道出家,这篇就带大家从头到尾,一步一步给小伙伴们详细介绍一下. 新建测试项目 1.pycharm 左上角 File>New Projetc>Pure Python,在 locat

关于用例需要多少文档以及业务用例等等

整理者:张克强 缘起 @jackyrong 发了如下一条微博 敏捷中的文档该写多少合适,一直是永恒的话题,每个用例故事的设计简要卡片,用例图,序列图,类图,数据字典,简要原型图,算法补充说明,应该是必要的吧,大家可以继续探讨 @袁斌_AgileDo @竹十一 @敏捷广州联盟 @火球_Fireball | 转发(58)| 收藏| 评论(35) 5月16日 张克强-敏捷307:这些都写了,那不就是RUP了? (5月18日 17:37) jackyrong:回复@张克强-敏捷307:那倒不一定,看的是

关于用例须要多少文档以及业务用例等等

整理者:张克强 缘起 @jackyrong 发了例如以下一条微博 敏捷中的文档该写多少合适,一直是永恒的话题,每一个用例故事的设计简要卡片,用例图,序列图,类图,数据字典,简要原型图,算法补充说明,应该是必要的吧,大家能够继续探讨 @袁斌_AgileDo @竹十一 @敏捷广州联盟 @火球_Fireball | 转发(58)| 收藏| 评论(35) 5月16日 张克强-敏捷307:这些都写了,那不就是RUP了? (5月18日 17:37) jackyrong:回复@张克强-敏捷307:那倒不一定,

PHPCMS中GET标签概述、 get 标签语法、get 标签创建工具、get 调用本系统演示样例、get 调用其它系统演示样例

一.get 标签概述 通俗来讲,get 标签是Phpcms定义的能直接调用数据库里面内容的简单化.友好化代码,她可调用本系统和外部数据,仅仅有你对SQL有一定的了解,她就是你的绝世好剑!也就是适合熟悉SQL语句的人使用.有了她,我们打造个性化的站点,能很方便的调用出数据库里面指定的内容.通过条件限制,我们能够调用出不同条件下的不同数据. 二.get标签样式 {get dbsource=" " sql=" "} {/get} 三.get 标签语法 1.get标签属性值

简单示例用例(Simple Example Use Cases)--hive GettingStarted用例翻译

1.MovieLens User Ratings First, create a table with tab-delimited text file format: 首先,创建一个通过tab分隔的表: CREATE TABLE u_data ( userid INT, movieid INT, rating INT, unixtime STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' STORED AS TEXTFILE; Then,

接口测试执行工具Postman:模拟请求、用例执行、断言、批量运行用例、简单持续集成

一.接口测试-postman-模拟HTTP Requests 二.接口测试-postman-权限Authorization 三.接口测试-postman-断言Writting Test 四.接口测试-postman-测试集合.简单持续集成等

自动化接口用例从 1 到 1000 过程中的实践和思考

引言 当一个新人刚加入公司的时候,我们通常告诉新人怎么去写一个自动化用例:从工程配置到如何添加接口.如何使用断言,最后到如何将一个用例运行起来. 而在实际工作和业务场景中,我们常常面临着需要编写和组织一堆用例的情况:我们需要编写一个业务下的一系列的自动化接口用例,再把用例放到持续集成中不断运行.面临的问题比单纯让一个用例运行起来复杂的多. 本人加入公司不到一年,从写下第 1 个 case 开始,持续编写和运行了 1000 多个 case ,在这过程中有了一些思考.在本文中,和大家探论下如何编写大

Python Api接口自动化测试框架 代码写用例

公司新来两个妹子一直吐槽这个接口测试用例用excel维护起来十分费脑费事,而且比较low(内心十分赞同但是不能推翻自己),妹子说excel本来就很麻烦的工具,于是偷偷的进行了二次改版. 变更内容如下: 1.代码结构 image.png 2.新增测试报告网页版和版本管理 3.新增用例代码化 一.封装一个获取用例的模块 image.png 用例的写法可以按照yml文件的写法,后缀的文件都可为.conf..config..ini.[]中的是测试用例场景,下面的参数内容对应接口用例参数. 简单介绍下py

dubbo接口自动化用例性能优化

前言 去年换了一个新部门,看了下当前的自动化用例的情况,发现存在三类性能问题: 本地调试运行时等待时间较长,就算是一个简单的case,执行时间都需要1分钟以上 单用例执行时间比较长,部分用例执行时间超过2分钟 集成到CI中运行时,执行时间较长 对于上述三个问题花时间进行了一定程度的优化,总结如下 优化本地调试时间 通过调试可以发现,一个需要执行660ms的case,在执行前的初始化工作就需要消耗约1分半钟,那么就需要思考下能否减少这部分初始化时间了. 公司用的自动化框架是基于AbstractTe