(整理)每月积累一点测试知识(201805)

版权声明:如需转载请声明与告知本人,谢谢。 https://blog.csdn.net/Yorkie_Lin/article/details/79970141

软件上线前所有提交的bug都要解决完吗?为什么?

不一定需要解决所有的bug,第一完全的测试是不可能的,也就说明没有bug的软件是不可能的,只要满足客户要求的就是好软件, 第二:版本上线是有时间截点的,在规定的时间内优先解决对客户影响大的bug。
bug遗留一般是下面几种情况: 1、bug没有好的解决方案,且影响可控的 2、优化类的bug 、转成需求来修改, 3、时间太紧张,对客户影响小遗漏到不紧张的版本修复。

测试用例评审的目的:
1、让产品、开发、测试三方对需求理解达成一致,减少开发过程中由于理解不一致产生的bug,提升效率
2、尽早发现需求设计中存在的问题,尽早修改,降低修复成本

如果测试A人员提单给开发B,A和B关系还不错,B说提单会影响他的绩效考核,这个时候怎么处理?
以我自己的经验
场景1: 面试的时候如何回答, 面试的时候尽量回答 发现bug就提单, 测试要有测试的原则性,不能因为影响谁而不提单,影响到产品的质量
场景2 ,实际工作中, 如果是测试还有几轮才结束, 且bug问题影响不大,可以让开发私下偷偷修改, 在下一个版本转测试后,一定要去验证开发偷偷修改的地方, 如果影响比较严重,还是要坚持提单,不让问题给遗漏了 ,好好和开发沟通,开发会理解你的, 可以运用一些技巧,这些你们自己去想。

* 做测试用例设计时,先进行等价类划分还是先进行边界值分析?*
先使用等价类划分。为什么说只有先分好了等价类,才能找边界值, 这个大家练习一个例子就明白了, 一个输入框,只允许输入字母、数字, 长度是6-10位。

在你测试的时候发现一个功能有点慢,但是功能是正常的,这个时候怎么处理?
分几种情况来讨论:
1、由于客户端的电脑配置引起的系统慢,如果客户也使用相同配置的电脑,这个慢需要提单解决
2、由于客户端网络慢导致的系统反应慢,这个不用解决
3、由于系统架构设计不合理导致的系统慢(数据库设计不合理、程序运行流程不合理、计算方法不合理等),提交bug单解决
在我们提交bug单前,需要和产品沟通下,这种慢是否需要更改,需要才提交bug。

软件测试完后,还有BUG,是测试人员的问题吗?
bug也要分情况:
1、需求里面有明确说明或者测试应该测试到的点,如果还有bug,那就是测试的责任
2、如果还有优化类的bug不能算测试的责任
3、如果还有不符合用户要求但是需求设计就错了的,不算测试的bug
为了测试不背锅, 所有关于bug沟通的记录都要有记录,方便以后不背黑锅
1、测试发现这个问题,但是不修改的, 这个也要有问题单记录
2、测试发现这个问题, 但是开发说没有这个场景的, 这个也要有沟通记录
3、测试发现这个问题,但是开发说不能复现,不修改的, 这个也要问题单记录
4、测试发现这个问题,但是说这个问题不重要,不修改的, 这个也要有沟通记录

一个系统上线之后经常会有线上问题,这个时候要求测试去复现网上问题,一般我们怎么样去入手分析呢?
(1)收集网上问题发生时的记录,一般包括如下几个方面
1、抓取出现问题的日志,还原操作过程
2、询问当时操作员执行了哪些操作,尽可能多的了解事发经过
3、了解当时的网络情况

(2)分析发生问题的原因?
通过查看日志,分析发生问题时做了哪些操作,每一步操作的数据是否都正确,如果找到问题发生的节点, 分析为什么会在这个节点出现这个问题
大部分有如下原因:
1、用户错误使用,但是没有对应错误限制
2、全局变量初始化错误,各种场景重复操作就会出现
3、数据量太大,但是没有限制
4、网络不好,重复请求(点击)
5、多人同时操作同一个数据,导致数据错乱
6、数据的同步异步请求传输
7、浏览器兼容性
8、接口数据返回异常

(3)我们可以通过哪些工具来帮助我们复现问题
1、Linux抓包工具 tcpdump
2、fiddler接口测试工具
3、clumsy制造网络延迟
4、设置Linux网络延迟

展开阅读全文

没有更多推荐了,返回首页