项目上线出Bug!为什么我没有测试出来?故障复盘剖析

文章讨论了在数据库查询业务中,当客户现场出现长时间未返回结果的查询问题时,测试人员如何进行故障复盘和测试用例的反思。问题可能源于缺少对应测试用例或测试环境与客户现场环境的差异。文章强调了从日志中复制和放大用户行为来改进测试用例的重要性,以提高测试覆盖率和接近真实用户使用情况。
摘要由CSDN通过智能技术生成

材料收集

你服务于一个数据库查询业务,某次客户现场反馈查询某个语句长时间未返回结果,耗时已经远远超过项目对外提供的性能报告承诺给用户最长查询时间。

问题和相关日志已经传递回来,开发人员进行原因分析和故障修复,测试人员进行故障复盘和测试改进。

这一切看起来都在正常的进行下去,但是作为测试人员的你是不是会不自主地冒出这么一句:为什么我没有测试出来呢?

那么,为什么会没有测试出来呢?

故障复盘

“没有测试出来”剖析最根本的原因无非可能有两点:

1、缺少对应的测试用例;

2、具有相应的测试用例,但测试环境与客户现场相差太大。

那么,你可能还会继续问自己:为什么会缺少对应的测试用例呢?

缺少对应的测试用例

至于测试用例的缺失,从客户需求——>需求方案设计——>开发方案设计——>开发实现——>需求测试——>需求交付。

整个流程来看:缺失相应使用场景的客户需求,或者需求方案设计有误,或者开发方案设计有误,或者开发实现偏差等等都可能导致测试人员在设计测试用例时,缺少相应用例的设计和测试执行,从而未能发现类似故障。

除此之外呢,有相应测试测试用例,还是因为测试环境与客户现场环境相差太大而未能发现类似故障。

测试环境与客户现场相差太大

为什么会存在测试环境与客户现场环境相差太大?

就数据库查询业务而言。测试环境的数据存储量有可能遥遥不及真实用户环境,也可能测试环境的测试数据与真实数据不一样(比如某个存储字段的长度设置;比如存储的字段内容解析后包含特殊字符、乱码等等)……这些都是测试环境与客户现场不一致的可能情况。

梳理完测试缺漏后,下一步理所当然的是进入用例补充和模拟客户环境稳定性测试。

可是,除了补充当前故障对应的测试用例之外,我们还能延展些什么呢?!

放大或复制用户行为

不管是开发人员或测试人员,我们都应该珍惜接触现场日志的机会(当然首要的是需要保密不外传),因为我们可以从日志中窥探到用户使用习惯或产品使用方式,从而将这些行为或习惯复制到我们的测试用例中,亦或者在测试中放大用户行为或习惯。

复制用户行为

什么是复制用户行为?如何复制用户行为?

复制用户行为在这里指的是,直接将获取到的用户使用产品方式在内部测试环境重现。比如:复现用户的某个数据库查询行为,select * from xx where ……

但是值得注意的是:

1)测试环境数据和真实用户环境可能存在较大的差异(比如:测试环境的数据库不存在某个字段abc,而真实用户行为查询却使用到了该字段abc),我们需要根据自己的测试环境进行适当的调整。

就数据库查询业务为例,这类调整包括但不限于:删除不存在的字段查询,修改对应的字段值为测试环境的值查询……

2)获取到的用户行为有限,无法支撑大量的查询比对(比如性能查询,统计数据库某类查询行为的耗时均值)。

这个问题应该是可以预见的,毕竟我们能够接触到的用户日志或采集到的用户行为是有限的。

尤其是针对第2)个问题,放大用户行为就成了我们的可选项。

放大用户行为

放大用户行为在这里指的是,将获取到的用户行为作为样本,复制多份或在用户行为中增删其他行为。

比如:将select * from index where id=’123’的用户行为复制100份,替换其中的id值为测试环境中不同的值;或以select * from index where id=’123’为基础样本,增加行为数据如select * from index where id=’123’ or id=’456’等。

复制或放大用户行为,对我们的测试有什么意义呢?!——可以让我们更接近用户的使用方式,产生更多的测试用例,扩大测试覆盖率。

再来一点思考

以上所说想必大多测试人员在工作中也是这样做的,但是可能缺少部分的思考和总结。现场反馈的问题和收集的资料对补充我们的测试用例、完善我们的测试工作具有很大的帮助,希望每一位测试人员都能好好利用能够接近“真实”的机会。

最后:

可以到我的个人号:atstudy-js,可以免费领取一份10G软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享!其中包括了有基础知识、Linux必备、Mysql数据库、抓包工具、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试等。

这些测试资料,对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
通过对提交的Bug数据统计分析,我们可以得以下结论: 1. Bug发现的时间分布:我们可以得Bug发现的时间分布,从而可以分析测试人员的工作效率和项目开发的进度。如果Bug发现的时间点集中在项目发布之后,说明测试人员在测试环节中存在问题,需要进一步完善测试流程,提升测试效率。如果Bug发现的时间点分布比较均匀,说明测试人员工作效率比较高。 2. Bug数量和严重性分布:我们可以得Bug数量和严重性的分布情况,从而可以根据Bug的数量和严重性来确定Bug解决的优先级。如果Bug数量较多且严重性较高,说明项目存在较为严重的问题,需要尽快解决。 3. Bug解决的时间分布:我们可以得Bug解决的时间分布,从而可以分析开发人员的工作效率和项目开发的进度。如果Bug解决的时间点集中在项目发布之后,说明开发人员在开发环节中存在问题,需要进一步完善开发流程,提升开发效率。如果Bug解决的时间点分布比较均匀,说明开发人员工作效率比较高。 4. Bug现的频率和原因分析:我们可以得Bug现的频率和原因分析,从而可以确定Bug现的原因,进而制定相应的解决方案。如果同一类Bug现频率较高,说明项目在此方面存在较大的问题,需要尽快解决。 5. 项目测试覆盖率分析:通过统计Bug数量和测试用例数量,可以得项目测试覆盖率,从而可以评估测试用例的充分性和准确性,进一步完善测试用例,提高测试质量。 综上所述,通过对提交的Bug数据统计分析,我们可以得一些重要的结论,从而帮助我们进一步完善项目开发和测试流程,提高项目的质量和效率。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值