问题1: 复现不了的问题
a. 昨天必现的问题、今天复现不了;
b. 生产环境必现的问题、测试环境复现不了;
c. 测试人员必现的问题、开发人员复现不了;
d. 一套环境必现的问题、另一套环境复现不了;
问题2: 自己的问题复现不了
A:发现的问题很多,也很严重,最终复现不了需要攻关解决、降级处理的也不少
B : 提交问题比A可能稍少也可能多,大部分问题在提交之前就分析的很透彻,甚至点出了问题的原因、出现的条件和场景,最终问题全部高效、及时的得到了解决。
出现以上问题的原因是什么?如何解决?下面一步一步说。
经过这些年工作的积累,以及与各领域测试同行的交流,问题复现不了的原因不外乎下面几个:
很多公司,问题单提单量是绩效考核的很大一部分,甚至占到了90%或更高,这就导致了比较奇葩的现象:问题单提单量高,解决率却很低。这么说有点诛心的味道,实际工作中怀揣这种想法的人其实非常少,这种结果是特定的考核机制下自然形成的,很多身处其中的人可能并没有意识到。
跟我们平常说的上有政策、下有对策是一致的,比如二套房,大家排队离婚。
姿势: 高大上的价值观引导,绩效考核方式是落实测试价值观的手段
a. 提交问题的目的,是为了解决问题,提升用户的使用体验。这样测试人员不仅会从技术角度分析产品的实现,还会从易用性等各个角度去衡量产品。
b. 测试的乐趣在于发现问题、定位问题的过程。一般喜欢打探小道消息、对问题刨根究底的人,测试都做的特别好。
现在很多公司已经调整了绩效考核的指标,比如阿里同学,重点考核的是上线发布后产品的质量、测试的效率、个人的成长。虽然最后一点有点虚,但是从现在阿里系出版的技术作品看,价值观引导确实做得好。
问题数量可以作为产品质量评价的一个数据,去衡量产品的质量,但前提是有代码缺陷密度等基线数据作为支撑,而不能拍脑袋。
执行测试时都有明确的目的性,这个用例测试的目的是什么,怀疑会出现什么样的现象。出现计划内的问题,是很容易复现和定位的。但伴随出现的问题,你一般不能第一时间抓住它,直到它产生了破坏作用,才能感知到问题的存在。它是在何时因为什么操作出现、什么事件触发的,不知道。这类问题就比较容易演化为难复现问题。
姿势:
下面这几个问题,只要做事严谨是可以避免的:
以上这些原因都可能导致问题无法复现。发现问题后,分析问题的正确姿势:
原文转自:http://www.jianshu.com/p/380e347f301a