直接上干货,码字不易,点个赞再走呗?
软件测试工程师需要掌握的知识:
Linux是测试人员的基础功,不需要掌握太难或者很不常见的Linux命令,正常能做到查看日志,定位问题就可以了。
1、基本命令
常用的Linux基本命令,面试经常会问的,或者给出一种场景,问你用什么命令。
2、查看日志
初级测试人员在工作时经常遇到,发现bug,开发不承认或者不愿意解决的情况,测试人员怎么摆脱这样的问题呢?
那就是根据发现的bug根据日志级别,来查看日志,定位问题。
具体的日志级别分为四级:
一般不符合需求的bug在 debug中,程序本身报错的bug在 error中。
1、数据库的本质
常见数据库主要是MAYSQL、ORECAL、Redis
其中Mysql数据库是典型的关系型数据库
2、数据库操作
(1) 数据库和表操作
(2)表数据操作
(3)复杂sql查询
测试用例必须包含的内容:
用例编号、用例名称、测试背景、前置条件、优先级、重要级、测试数据、测试步骤、预期结果、实际结果、备注。
1、测试用例的编写流程
需求分析->提取测试点->测试用例编写->测试用例评审
2、编写测试用例的思路
(1)根据产品的RPD,提取测试点。
(2)根据数据流的走向。
(3)根据的架构部署。
(4)编写测试用例的常用方法:等价类划分法、边界值分析法、流程图法等。
(5)覆盖弱网测试、接口测试、安全测试、性能测试等。
(6)常用测试工具有:Postman、 Charles、 Fiddler 、Jemter、Loadrunner等。
3、编写测试用例注意事项
(1)根据项目的实际情况设计测试用例表格
(2)用例格式不要生搬硬套
(3)根据具体情况编写
(4)学会质疑需求,不要完全按照需求来写测试用例,要从客户和产品的角度来理解需求,看到需求之外的功能和体验
面试经常关于Http协议的下面几个问题
业务熟悉后,会知道很多常识,知道下面的常识之后,你就可以尝试进阶,学习做自动化测试、接口测试、性能测试
比如说,5000张优惠券,大概有多少人抢,在多长时间内抢完。
做功能测试,还有个很重要的工作就是bug管理,一个优秀的的测试人员,线上bug非常多,多于和你一起工作的其他同事,但是线上bug非常少,少于其他同事。
1、 bug定义
(1)不符合需求的
(2)程序本身报错
(3)不符合用户的使用习惯
2、bug生命周期
当我们测试人员提交一个bug的时候,自始bug就有它的生命周期,从开始到结束。
3、测试报告
把测试的过程和结果写成文档,对发现的问题和缺陷进行分析,为纠正软件的存在的质量问题提供依据,同时为软件验收和交付打下基础测试报告和测试计划一样,一般由测试leader编写,测试人员需要了解一下测试报告中都有哪些内容。
1、抓包作用:测试一个app搜索功能,抓包,抓到一个搜索接口,突然发现抓到了两个请求接口 -> 当访问量上来了,服务的压力上升两倍
2、数据流走向 :测试时候发现页面上数据只有一条,但是数据库里面多了一条 -> 1、数据量变大,查询变慢 2、脏数据太多,瞬间爆满,程序崩溃了
3、弱网测试:app项目一定要有弱网络测试(模拟2g、3g、4g,wifi网络状态以及丢包情况);网络切换测试(网络断开后重连、3g切换到4g/wifi 等
由于市场大批量流入这些不合格的自认优秀的测试员,使得多数公司不得不降低了期望,但是真正有实力的,基本没有受到什么影响,要跳槽还是很容易的。如果对现在的工作不满意,又没有足够的经验,不妨先静下心来进修一番。
软件测试所有方向的技术点做的整理,形成各个领域的知识点汇总,它的用处就在于,你可以按照上面的知识点去找对应的学习资源,保证自己学得较为全面。
温馨提示:篇幅有限,已打包文件夹,获取方式在:私信关键词“资料”
当我学到一定基础,有自己的理解能力的时候,会去阅读一些前辈整理的书籍或者手写的笔记资料,这些笔记详细记载了他们对一些技术点的理解,这些理解是比较独到,可以学到不一样的思路
观看零基础学习视频,看视频学习是最快捷也是最有效果的方式,跟着视频中老师的思路,从基础到深入,还是很容易入门的。
光学理论是没用的,要动手实操,才能将自己的所学运用到实际当中去,这时候可以搞点实战项目来学习。
三个月足够,不裸辞也够,除非你现在工作忙到每天回家倒头就睡。
问题不在于三个月够不够,而是你能不能坚持。
裸辞的好处是干扰更小,坏处是压力更大,看你是哪种类型的性格,再决定是背水一战还是骑驴找马。
有的人可以边工作边做别的事,但不是所有人都能做到。
同样,没有工作也不是所有人能接受的状态。
最后就是,别定太高目标。既然决心转行,就做好从零开始的准备
所有上述系统资料都可以私信我关键词“资料”获取
以上,祝好。