你的问题为什么总是难以复现?

上一篇 / 下一篇  2016-12-09 08:59:27 / 个人分类:测试总结

问题1: 复现不了的问题
a. 昨天必现的问题、今天复现不了;
b. 生产环境必现的问题、测试环境复现不了;
c. 测试人员必现的问题、开发人员复现不了;
d. 一套环境必现的问题、另一套环境复现不了;

问题2: 自己的问题复现不了
A:发现的问题很多,也很严重,最终复现不了需要攻关解决、降级处理的也不少
B : 提交问题比A可能稍少也可能多,大部分问题在提交之前就分析的很透彻,甚至点出了问题的原因、出现的条件和场景,最终问题全部高效、及时的得到了解决。

出现以上问题的原因是什么?如何解决?下面一步一步说。

一、出现上述问题的原因

经过这些年工作的积累,以及与各领域测试同行的交流,问题复现不了的原因不外乎下面几个:

  1. 绩效导向,提单量影响绩效考核
  2. 问题是伴随出现的,不知道何时出现、如何出现的
  3. 你觉得你知道了根本原因,实际上你不知道
  4. 系统日志记录不完善、或者根本没有打开
  5. 测试过程全程无记录
  6. 问题单缺乏关键信息
  7. 高并发、多线程、异步调用复现概率低的问题
  8. 黑天鹅问题

二、解决问题的思路

1. 绩效导向问题

很多公司,问题单提单量是绩效考核的很大一部分,甚至占到了90%或更高,这就导致了比较奇葩的现象:问题单提单量高,解决率却很低。这么说有点诛心的味道,实际工作中怀揣这种想法的人其实非常少,这种结果是特定的考核机制下自然形成的,很多身处其中的人可能并没有意识到。

跟我们平常说的上有政策、下有对策是一致的,比如二套房,大家排队离婚。

姿势: 高大上的价值观引导,绩效考核方式是落实测试价值观的手段
a. 提交问题的目的,是为了解决问题,提升用户的使用体验。这样测试人员不仅会从技术角度分析产品的实现,还会从易用性等各个角度去衡量产品。
b. 测试的乐趣在于发现问题、定位问题的过程。一般喜欢打探小道消息、对问题刨根究底的人,测试都做的特别好。

现在很多公司已经调整了绩效考核的指标,比如阿里同学,重点考核的是上线发布后产品的质量、测试的效率、个人的成长。虽然最后一点有点虚,但是从现在阿里系出版的技术作品看,价值观引导确实做得好。

问题数量可以作为产品质量评价的一个数据,去衡量产品的质量,但前提是有代码缺陷密度等基线数据作为支撑,而不能拍脑袋。

2. 伴随出现的问题

执行测试时都有明确的目的性,这个用例测试的目的是什么,怀疑会出现什么样的现象。出现计划内的问题,是很容易复现和定位的。但伴随出现的问题,你一般不能第一时间抓住它,直到它产生了破坏作用,才能感知到问题的存在。它是在何时因为什么操作出现、什么事件触发的,不知道。这类问题就比较容易演化为难复现问题。

姿势:

  1. 保持冷静,不要激动,保持现状
  2. 思考一下:你对它做了什么?为什么这样? 他们两个什么关系(可能没关系)? 可能在什么地方、什么操作、什么事件触发的?
  3. 想明白了吗?想不明白叫别人一起想。
  4. 不管是否想明白,把操作记录、组网、数据、配置、状态全部记录下来
  5. 在不破坏环境的情况下,尝试验证想法;如果问题比较严重,考虑另搭环境验证;
  6. 想法得到验证后,简化环境验证问题,找到问题触发条件
3. 几个自作孽的问题

下面这几个问题,只要做事严谨是可以避免的:

  1. 你觉得你知道了问题原因,实际上你不知道
  2. 系统日志没开
  3. 系统日志记录不完善
  4. 测试环境、配置文件、环境数据无保留
  5. 操作过程无记录
  6. 问题单缺乏关键信息

以上这些原因都可能导致问题无法复现。发现问题后,分析问题的正确姿势:

  1. 先别着急提问题
  2. 回想可能是什么事件、什么操作、还是环境变化触发了这个问题。 如果你有记忆宫殿就好了。
  3. 查阅相关日志、操作记录进行验证
  4. 依据问题重要性,保存关键的信息
  5. 在现有环境中验证
  6. 找到稳定复现的条件
  7. 持续简化环境和复现条件
  8. 找到问题的确切触发条件和最简环境
  9. 提交问题,要附带所有必要信息

对于热爱测试的工程师来讲,这个过程是充满乐趣的,但是要有严密的逻辑思维能力和对被测试系统运行机制的深刻理解。找到原因后,你可能会得出这样的结论:开发为什么会犯如此低级的错误;开发对协议的理解有误;开发对此类数据的处理有问题等等。然后你可以跟开发说,你哪里的代码处理这个数据有问题、你哪里哪里理解错误,虚荣心会得到小小的满足。

大家有没有感觉到,在定位复杂问题时,日志系统里缺少的总是关键信息,而有的信息总是不太重要的, 软件可维护性任重道远。
另外,有些公司的crash问题是不用复现的呦,信息已经足够了。 你的公司能做到吗?

4. 高并发、多线程、异步调用复现概率低的问题

此类问题即使有日志信息,因为大容量、高并发,再加上异步处理打乱了原有的惯性逻辑思维,是很难用通用的方法定位出来的。
比如系统记录明确指针异常的问题,也有堆栈的信息,并且知道哪个指针为空,但是不知道如何导致的,经排查初始化完全没有问题。这种情况下就不能简单的通过返回NULL来解决,这样有可能用户得到的数据就是空的,虽然概率很低,但是会影响用户的体验。 特别是在初创公司,在激烈的市场竞争中,差的用户体验,无异于自掘坟墓。

姿势:此类问题测试同事是不太可能单独搞定的,一定要伙同资深开发同事一起分析(一般你不叫他他也会过来,这类问题是很有吸引力的)。主体思想是先提高复现概率、一步步缩小问题范围,最终定位出问题。具体思路怎么变态怎么来,客户端加大访问量、服务端减少资源、怀疑是网络的问题可以使用traffic control模拟报文错误或异常。说随如此说,碰到具体问题还是要具体分析,根据问题现象,进行有针对性的验证。

性能测试工程师在互联网/移动互联网行业是至关重要的

5. 黑天鹅问题

为了避免碰到此类问题你可以多拜拜观音菩萨, 如果真碰到了就去买彩票

测试人要有正确的价值观引导,做事严谨,并且要有一定的技术实力做支撑。


TAG: 软件测试 软件测试管理 测试 测试管理

18311060186的个人空间 引用 删除 18311060186   /   2017-02-06 15:45:26
5
Fighting-ing的个人空间 引用 删除 Fighting-ing   /   2017-01-11 14:40:35
测试需谨慎啊
Fighting-ing的个人空间 引用 删除 Fighting-ing   /   2017-01-11 14:39:47
5
 

评分:0

我来说两句

我的栏目

日历

« 2024-03-28  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

我的存档

数据统计

  • 访问量: 10530
  • 日志数: 4
  • 建立时间: 2016-12-08
  • 更新时间: 2016-12-09

RSS订阅

Open Toolbar