项目上线出Bug!为什么你作为测试没测出来?

材料收集

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

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

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

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

故障复盘

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

       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’等。

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

再来一点思考

作为测试人员,由于项目的复杂性和时间的限制,可能会出现无法覆盖所有情况的情况,导致一些Bug被忽略或没有被发现。以下是我对于项目上线出现Bug的总结和反思:

  1. 测试用例不充分:在测试过程中,我们可能会漏掉某些测试用例,依赖于自己的经验和直觉来进行测试,从而无法发现潜在的问题。

  2. 不够细心:测试的时候,我们可能会因为疏忽而错过一些重要的细节,这些细节可能是关键的点或异常情况,所以我们需要更加专注和细心地进行测试。

  3. 系统环境不同:有时候,在测试环节中我们使用的软件、硬件环境与真实环境不同,有时甚至版本不同,从而导致无法完全模拟真实环境,因此应该尽可能逼近真实环境进行测试。

  4. 时间不足:在开发周期较短的情况下,测试时间也会很紧张,可能无法达到完整测试的目的,这时候我们可以采取优化测试用例的方法,将主要的测试场景放在前面进行测试。

  5. 沟通不畅:测试人员与开发人员之间的沟通不畅可能会导致一些问题被忽略或测试的方向不正确。所以,我们需要与开发人员随时保持有效的沟通,及时反馈问题和解决方案。

  6. 人为因素:有时候,测试人员的个人情绪或疲劳等因素也可能影响到测试效果,这时我们应该注意自己的心态,保持高效的工作状态。

总之,项目上线出现Bug是一件很正常的事情,我们需要从中吸取经验教训,不断完善测试方法和流程,提高测试质量和效率,确保项目成功上线。

最后:【可能给你带来帮助的教程】项目上线出Bug!为什么你作为测试没测出来?_第1张图片

项目上线出Bug!为什么你作为测试没测出来?_第2张图片

 因此我建立了一个软件测试开发自学团,正在学习测试的小伙伴可以通过点击下面的小卡片

你可能感兴趣的:(软件测试,测试用例,软件测试项目,自动化测试,性能测试)