测试用例Passed和Failed有效性问题
上一篇关于测试用例设计的博文《设计测试用例的四条原则》中,介绍了设计测试用例的四条原则。本篇结合最近工作遇到的一个小插曲,介绍一下测试用例本身Passed和Failed的有效性问题。
我所在的团队上个 Sprint有一项很重要的工作,就是进行Stress 测试,需要编写自动化用例测试模拟程序长时间的执行,并观察其内存消耗是否呈现合理的增长趋势,以及有没有内存的泄漏等问题。同事很快编写好了测试用例, 并执行了个把个小时,得出了初步的数据。数据显示程序的表现相当完美,不仅内存没有陡峭的突变,甚至连大斜率的线性增长也木有,基本呈现为一条略有波动的 水平直线。非常让人振奋,这样的表现打消团队之前的担心,完成这项工作所需的时间也将大大小于之前的预估。
我对这项测试也非常感兴趣, 并和同事进行了一些交流,想深入了解一些更详细的情况,比如测试数据规模、执行的时间长短、测试数据分布等,随着交流的深入同事突然意识到似乎测试代码似 乎有些不大合乎常理的表现,进一步调试发现代码中一段生成数据的代码并没有正确生成数据,虽然测试仍在执行但输入的数据没有,测试只是在空转,并没有真正 执行被测程序的逻辑,所以整个曲线才呈现为一条水平线。
这件事本身是个小问题,但其背后隐藏着一个值得我们深究的问题:当你的测试用例Passed的时候,被测产品果真是正确的吗?仔细想想这个问题,可以得到一些对我们的测试工作有意的思考:
1. 自动化测试需要有详细的日志输出,以便于诊断测试的确切执行情况。
自动化测试用例的执行过程对我们来说是一个黑盒过程,我们一般只是看到它的结果是Passed或者Failed。如果这个黑盒过程本身就是错误的,如本 文一开始所给出的例子,结果是Passed就没有任何意义了。而且这样的Passed只会是给问题雪上加霜,减少了发现问题的可能性。
2. 测试人员特别是自动化测试工程师,应该对那些看似完美的东东多些疑问,多些探究精神,在经过客观途径验证之前时刻保持谨慎的乐观。
从某个角度讲,经常Failed测试用例并不值得你太担心,而那些从来都是Passed的用例,应该是值得你抽时间检查的对象。
3. 测试用例要么Passed要么 Failed,看似简单的结果,但其中还是有些值得深究的内容的。
任何一个测试用例实际上是肩负着双重责任: 其一,保证在被测功能正确的情况下,测试用例应该是Passed;其二,则是在被测功能异常的情况下,测试返回Failed。一般的情况下,我们只是验证 了第一种情况后就算完成,并将用例提交到用例管理库或者代码库中。很少真正有人去验证一下在被测试功能异常的情况下,测试用例确实Failed。这样的用 例验证可以总结为如下的模式:
Passed –> Passed –> Passed –> …-> Passed? or Failed? |
之所以会有这样的情况,首先,是因为从意识上讲,大多数人都认为测试中对被测功能行为的判断以足够强壮,但其实这种没有客观佐证的判断并不可靠;其次, 很多用例的实现和执行多是在被测功能实现之后才开始,这时的被测功能刚实现出来,并经过开发人员反复调试修改,绝大多数情况下都是正确的,由于产品代码已 经提交,此时很难再有简单的途径模拟出错误的功能行为,以验证测试用例Failed的情况。
解决的办法有两种:一、尽可能寻找途径去模拟被测功能的异常;二、再就是合理选择实现测试用例的时间。很多情况我们的用例是为了覆盖已有的Bug而添加的,以避免回归缺陷。这样的测试用例最好是在Bug修复之前就实现,那么它一定是Failed,这个机会就可以验证出Failed情况。
扩展一下这个话题,从用例Failed/Passed路径这角度上看,测试驱动开发(Test Driven Development,TDD)的模型更为合理和自然。因为,TDD强调先有测试用例,再实现产品功能代码,先实现的测试用例必然是经过一系列的Failed之后,最终达到Passed,其模型可以总结如下:
Failed –> Failed –> Failed –> …–> Passed |
TDD的原理保证了测试用例一定是由Failed开始,到Passed结束,所以不用费心去模拟功能异常以得到Failed结果,同时保证了用例对Failed和Passed都一定进行了验证。
4. 产品的质量有测试来监控,那么谁来监控测试本身的质量呢?人、过程和工具。
人-测试人员需要更有责任心,保持对任何问题的谨慎乐观和探究精神;过程-测试计划和用例的交叉评审,测试代码也要进行review,同时选择合理的时机实现测试;工具 – 利用代码覆盖来探究测试用例有效性。
总之,我们在编写和实现测试用例的时候,除了实现基本功能之外,还要多留意的用例(特别是自动化用例)Passed和Failed有效性,经常容易被忽略地是Failed有效性,所以要尽可的寻找途径来验证其有效性。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页:http://qaseven.github.io/
测试用例Passed和Failed有效性问题相关推荐
- 便携式激励vs形式化vsUVM验证方法在IP块的整个生命周期中的比较分析
摘要-验证技术和方法不断发展,以应对日益严峻的验证挑战.当今行业的最新技术是基于UVM和基于形式化(Formal)的验证流程.事实证明,这两种技术都可以显著提高验证质量,但缺点是测试用例或激励不能&q ...
- fixture详细介绍-作为参数传入,error和failed区别
前言 fixture是pytest的核心功能,也是亮点功能,熟练掌握fixture的使用方法,pytest用起来才会得心应手! fixture简介 fixture的目的是提供一个固定基线,在该基线上测 ...
- matlab isa函数,使用函数编写简单测试用例
创建 quadraticSolver.m 函数 此 MATLAB 函数求二次方程的解.在您的 MATLAB 路径上的文件夹中创建此函数. function roots = quadraticSolve ...
- 怎样才算是一个好的测试用例
今日花了数小时的时间仔细的阅读了一下Cem Kaner教授的<What Is a Good Test Case?>一文.起初看到文章的标题原以为是一篇讲述编写测试用例所应该采用的步骤和注意 ...
- 基于缺陷驱动的测试过程有效性评价方法研究
1. 引言 开发过程的质量决定了软件的质量,软件测试过程的质量同样决定了软件测试的质量和有效性.[1]软件测试在软件质量的保证环节起着至关重要的作用[2],在文献[3]中定义了软件评价过程模型,这是 ...
- 基于缺陷的测试过程有效性评价方法研究
开发过程的质量决定了软件的质量,软件测试过程的质量同样决定了软件测试的质量和有效性.软件测试在软件质量的保证环节起着至关重要的作用,在文献中定义了软件评价过程模型,这是国际上共同遵守的软件评测过程标准 ...
- 自动化软件测试 -- 测试用例
一.测试用例的概念 测试用例又叫test case,是为某个特殊目标而编制的一组测试输入.执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求. 测试用例的特性: 有效性:测试用例能够 ...
- 测试用例的特性以及编写测试用例的方法
测试用例的特性以及编写测试用例的方法 测试用例的定义: 什么是测试用例? 测试用例的特征: 编写测试用例的好处: 测试用例的作用: 测试用例的4个特性 测试用例通常包括以下几个组成元素: 编写测试用例 ...
- TestDirector用户手册
文章出处:www.51testing.com 作者:江永刚 发布时间:2005-10-19 [摘 要]TestDirector是Mercury Interactive公司推出的基于WEB的测试管理 ...
- 软件测试复习与几道常见题型
第一章 1.1 软件测试定义 1.软件测试的理解: 软件测试的正向理解 : 验证软件是否符合用户需求,给用户以信心. 软件测试就是为程序或系统能够按预期设想运行而建立信心的过程. 软件测试是一系列活动 ...
最新文章
- 北京智源人工智能研究院2020年博士后招收简章
- rest-framework 视图
- 后台开发经典书籍--深入理解Nginx模块开发与架构
- sqlserver 微信昵称_sql server用户名和登录名的区别和联系
- linux db2 权限管理,DB2五种管理权限
- Android笔记 网络源代码浏览器demo
- onenote快捷键_onenote链接系列:链接笔记如何产生?与插入链接的区别
- UINT_MAX输出后为什么是-1
- HarmonyOS DevEco Studio 配置本地模拟器
- PhoenixFramework自动化测试平台部署初始化说明
- ORM框架 Dapper
- Pascal调用与C调用
- pdf英文转换成html网页,Pdf转HTML转换工具
- Verilog常用语法
- python 爬虫 美女_使用Python爬虫爬取网络美女图片
- 【名单回顾】2019/2020年第11届蓝桥杯大赛青少年组(北京赛区)选拔赛C++初级组一二等奖获奖名单
- 一篇关于校园的爱情故事:伤感
- B细胞介导的体液免疫
- (int*)、(int *)和(int **)的区别
- 2021-10-29 2021年资料员-通用基础(资料员)考试题及资料员-通用基础(资料员)免费试题