测试结果居然还能这么用?!

科技   2024-08-14 17:30   上海  

出品 | 51Testing软件测试圈


随着开发的逐渐深入,从节省时间、资源和提高测试效率的角度来说,自动化用例必然会成为一个大众型选择。并且,几乎大大小小的软件公司,都在朝着测试自动化的脚步迈进。


那么,我们应该如何有效地利用自动化测试结果挖掘问题,或者说如何通过自动化测试结果分析出一些问题呢?当然,这里的问题不全指代码故障,也可能包括测试脚本问题。


首先,让我们来看看,软件公司常用的将自动化测试嵌入开发流程方法。提及此,不得不提到DevOps(开发运营一体化)。


传统DevOps流程包括:设计——>开发——>测试——>部署,如下图所示。


构建DevOps流程需要一个持续化集成工具,如Jenkins,被多数公司青睐。


那么,我们如何使用Jenkins工具将自动化测试嵌入DevOps流程呢?


简单讲述下,Jenkins配置自动化测试嵌入DevOps流程的几个关键点和常见问题。


配置参数


你需要配置测试所需的、外部控制的一些参数,比如:测试环境地址。


通过Jenkins的“This project is parameterized”配置项设定,配置完成后可改变该测试项目的启动参数,样例如下图所示:


设定定时或触发机制


你需要设定一个定时或触发自动化测试的机制,在DevOps流程中,测试在开发环节之后。


而持续集成实践中,往往设计开发代码变动就触发回归测试或定时进行自动化测试,因此可通过Jenkins设置自动化测试触发机制为Jenkins项目触发(通过Build after other projects are built设置)或定时触发(通过Build periodically设置)。


样例如下图所示:


启动测试用例


你需要设置启动测试用例的脚本或命令,启动测试用例是DevOps测试环节的关键步骤,在Jenkins工具里。


可通过Command配置项进行设定,样例如下图所示:


如此这般关键配置完成后,你就可以触发Jenkins测试项目运行,坐等测试结果了。


接着,让我们来分析一下自动化测试结果吧。


分析结果


从执行结果来说,测试用例运行结果无非两种情况:通过或失败。


作为测试人员来说,往往更关注的是失败的测试用例。因为,失败的测试用例往往隐藏着一些不可知的问题。


那么,这些问题都可能有什么呢?我们把测试用例失败的问题大致分为两类:开发代码问题或非开发代码问题:

  • 开发代码问题指的是程序功能与预期不一致导致的问题,即通常所说的代码bug;


  • 非开发代码问题又可分为运行环境问题和测试代码问题(如下图所示)。


让我们来看看,如何利用自动化测试结果分析测试中发现的问题(开发代码问题、环境问题和测试代码问题)。


问题分析


作为测试人员,当我们不好判断是不是属于开发代码问题的时候,我们可以从我们熟悉的领域入手,先判断是不是属于环境问题和测试代码问题。如果都不属于这两类的时候,我们就可以收集证据,将问题提交给开发人员分析。


测试代码问题分析


测试代码问题细分来说有:测试流程设计问题,测试脚本错误。


测试设计不合理问题主要有测试脚本中测试步骤设计不合理的问题和测试用例互相依赖的问题。


如:测试某个应用删除接口,期望删除a服务成功。


但是在脚本测试步骤设计过时,缺少对待删除a服务已存在的校验,导致直接使用删除接口删除a服务报错a服务不存在的问题。


测试脚本错误主要在于测试人员开发测试代码时引入的错误,如:缺少参数、传参错误、函数引用错误、断言错误等等。


环境问题分析


通过测试用例执行结果报告,有的问题属于环境问题可以一目了然,如:环境资源告警、缺少测试用例需要的python或jdk环境配置等。


但也有的属于需要进一步分析的问题,如:被测程序网络抖动,内存释放不及导致的内存越界等等。


对于第二种情况,常见的特征是:用例并非稳定失败,可能在其他时间段运行时用例结果为通过。


开发代码问题


排除了测试代码问题和环境问题,我们就可以来分析失败的测试执行结果是否是由于开发代码问题引入的。


通常情况下,当测试人员在对被测功能很了解、测试用例设计无误的情况下,能够很自信地判断失败的用例是否是代码问题引入的。


如:同样是某个应用删除服务接口,前置条件是待删除服务存在,执行接口删除操作,期望服务删除成功。但结果是接口响应删除成功,但查询时显示服务残留了(不是被新注册的)。


由此,你可以很自信地向开发人员提交Bug。


但是,当测试人员无法确定失败的用例是由开发代码引入时(对于并发测试尤其常见),这个时候需要测试人员收集足够的信息,提交给开发人员分析。


这些信息可以且应该包括:测试环境、测试方法、错误现象、复现频率以及相应的开发代码日志(如果可以获得的话)。


最后,让我们来拓展下针对测试代码问题和环境问题进行测试用例层面的修正或规避方法,问题列表和处理建议如下表所示:


通过对自动化测试用例执行结果的分析,能够帮我们梳理错误的类别和定位错误的原因,帮助测试人员优化测试脚本、提高测试脚本。


更多的是能够过滤非开发代码问题,节省开发人员甄别错误的时间消耗。此外,对提高测试人员专业性也有助益。


End



声明:本文为51Testing软件测试网刘晓佳Rachel用户投稿内容,该用户投稿时已经承诺独立承担涉及知识产权的相关法律责任,并且已经向51Testing承诺此文并无抄袭内容。发布本文的用途仅仅为学习交流,不做任何商用,未经授权请勿转载,否则作者和51Testing有权追究责任。如果您发现本公众号中有涉嫌抄袭的内容,欢迎发送邮件至:editor@51testing.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。


点分享
点收藏
点在看
点点赞
51Testing软件测试圈
博为峰20周年,青春正当燃,一起向未来! 博为峰51Testing软件测试圈——坚持以专业技术为核心,关注软件测试领域最前沿技术和管理思想,凝聚行业力量,共同分享软件测试理论与实践经验,是一个测试人的生活与技术圈。
 最新文章