感觉软件测试很简单,但为何这么多劝退的?

上一个说软件测试简单的,已经被面试官问死了。。。

现在已经过了 ”不会但我会学“ 就能感动面试官的时代,随着供需关系的变化,不论是对于面试官还是面试者,面试的成本越来越高。为了筛选到更优秀的程序员,面试官们可谓是绞尽了脑汁,”面试造火箭,工作拧螺丝“ 的传言也不是空穴来风。

那些面试官最喜欢的就是你在简历上写“精通”或者“熟练掌握”几个字。。。

我以前也以为自己学明白了,后来经历的面试越多越觉得自己没学明白。

哦不,不是没学明白,是没学清楚!

腾讯的面试官就贼喜欢问软件测试基础部分,字节的还好…所以在我以前通过校招上岸字节跳动后,将我自己的秋招找工作认真总结,并且开源在github上了。

这份笔记包括软件测试基础、Linux、Python、计算机网络、常见软件测试工具(LR、Jmeter)、数据库(MySQL为主)、常见逻辑题、以及软件测试面试中需要注意的问题。

后来我将这份笔记制作成了PDF,现在免费分享给学习学妹们,赶快白嫖走起~

包括行业分析、薪资和技术匹配分析、职业规划、基本工作流程、简历编写、面试流程等。

进阶资料:Java自动化测试、Python自动化测试、性能测试、测试开发工具包:appuim安装包、fiddler安装包(也有配套视频教程)、eclipse、git、jmeter、loadrunner、monkey、postman、soapul、Xmind等等

项目实战资料:电商项目实战、linux实战、接口自动化测试实战、app测试项目实战、web项目实战

其他经典资料:软件测试经典面试题(基础到高手都能用到)、2000套软件测试简历模板、软件测试电子书、软件测试最全测试报告模板无偿赠送噢

软件测试核心笔记

不说了,进来学习!!!!

1.测试结束的标准是什么?

1.用例全部执行。2.覆盖率达到标准。3.缺陷率达到标准。4.其他指标达到质量标准

2.测试过程

1) 制定系统测试计划

2) 编写系统测试用例

3) 执行系统测试用例

4) 跟踪管理缺陷

5) 总结测试

3.查看日志常用什么命令,主要查看什么内容

1 查看日志常用less命令或者view命令。

2 主要查看程序运行的记录,比如支付失败,后台就有报错信息打印到.log日志文件中,就可以通过分析日志信息来初步定为问题。(补充:同时也去查询数据库,分析订单数据,查看支付状态等等)

PS:日志就是.log的文本文件,和.txt一样属于文本文件。vi或者vim编辑器属于记事本软件,一般不会用来查看日志。

4.Mysql 数据库中怎么实现分页?

select * from table limit (start-1)*limit,limit;

其中 start 是页码,limit 是每页显示的条数。

5.Web 兼容性测试

l首先开展人工测试,测试工程师测试主流浏览器和常用操作系统测试主流程和主界面,看看主流程和主界面是否有问题,如果存在问题,那么记录下 bug 情况,以及浏览器型号和版本,以及操作系统,准确定位bug 产生的原因,提交 bug,告知开发人员修改。所有的主流设备都需要进行测试, 只关注主流程和主界面,毕竟每个系统主流程和主界面不是很多,所以这个工作量还是可以承受的。

其次借助第三方测试工具,目前我觉得比较好用的第三方 Web 测试工具有 IEtester(离线)、SuperPreview(离线)和 Browsershots:browsershots.org(在线),一款可以测试 IE 的兼容, 一款可以测试主流浏览器的兼容,包括谷歌、火狐、Opera 等等。借助第三方测试工具,找到 bug 产生的位置,分析测试结果,告知程序员调整。

6. 如何设计自动化测试用例:

l编写测试脚本之前要编写测试用例,而且测试用例不能直接使用手工测试的用例。

l自动化的测试用例是一个完整的场景。用户登录系统到用户退出。

l用例之验证一个功能点。不用试图登陆后验证所有的功能在退出

l测试用例尽量只做正向的逻辑验证。

l用例之间不要产生关联,相互独立,也要高内聚,低耦合

l测试用例关注的是功能逻辑的实现,字段无关

l测试用例的上下文必须有一定的顺序性,前置条件清晰

l检查点的设置要侧重,全面,灵活

l测试用例对数据的操作要进行还原

l测试用例必须是可回归的

l用例选择遵循成本始终,构建场景,目的冒烟回归,繁琐功能,主体流程

l用例转型遵循前置配置,抛异常,步骤验证,高内聚,关门归原

7 服务端性能分析都从哪些角度来进行?

从维度上划分,性能指标主要分为两大类,分别是业务性能指标和系统资源性能指标。业务性能指标可以直观地反映被测系统的实际性能状况,常用的指标项有:

1.并发用户数

2.事务吞吐率(TPS/RPS)

3.事务平均响应时间

4.事务成功率

系统资源性能指标,主要是反映整个系统环境的硬件资源使用情况,常用的指标包括:

1.服务器:CPU 利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘 IO 状态、网卡带宽使用情况等;

2.数据库:数据库连接数、数据库读写响应时长、数据库读写吞吐量等;

3.网络:网络吞吐量、网络带宽、网络缓冲池大小;

4.缓存(Redis):静态资源缓存命中率、动态数据缓存命中率、缓存吞吐量等;

5.测试设备(压力发生器):CPU 利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘 IO 状态、网卡带宽使用情况等。

8 如何理解压力测试,负载测试以及性能测试?

性能测试(Performance Test):通常收集所有和测试有关的所有性能,被不同人在不同场合下进行使用。

压力测试 stress test:是在一定的『负荷条件』下,长时间连续运行系统给系统性能造成的影响。负载测试 Load test:在一定的『工作负荷』下,给系统造成的负荷及系统响应的时间。

5.编写一个http 接口性能测试方案,测试过程的关注点有哪些,流程等?

一、准备工作

1、系统基础功能验证

性能测试在什么阶段适合实施?切入点很重要!一般而言,只有在系统基础功能测试验证完成、系统趋于稳定的情况下,才会进行性能测试,否则性能测试是无意义的。

2、测试团队组建

根据该项目的具体情况,组建一个几人的性能测试 team,其中 DBA 是必不可少的,然后需要一至几名系统开发人员(对应前端、后台等),还有性能测试设计和分析人员、脚本开发和执行人员;在正式开始工作之前,应该对脚本开发和执行人员进行一些培训,或者应该由具有相关经验的人员担任。

3、工具的选择

综合系统设计、工具成本、测试团队的技能来考虑,选择合适的测试工具,最起码应该满足一下几点: 支持对 web(这里以 web 系统为例)系统的性能测试,支持 http 和 https 协议;工具运行在 Windows 平台上; 支持对 webserver、前端、数据库的性能计数器进行监控;

4、预先的业务场景分析

为了对系统性能建立直观上的认识和分析,应对系统较重要和常用的业务场景模块进行分析,针对性的进行分析,以对接下来的测试计划设计进行准备。

二、测试计划

测试计划阶段最重要的是分析用户场景,确定系统性能目标。

1、性能测试领域分析

根据对项目背景,业务的了解,确定本次性能测试要解决的问题点;是测试系统能否满足实际运行时的需要,还是目前的系统在哪些方面制约系统性能的表现,或者,哪些系统因素导致系统无法跟上业务发展?

确定测试领域,然后具体问题具体分析。

2、用户场景剖析和业务建模

根据对系统业务、用户活跃时间、访问频率、场景交互等各方面的分析,整理一个业务场景表,当然其中最好对用户操作场景、步骤进行详细的描述,为测试脚本开发提供依据。

3、确定性能目标

前面已经确定了本次性能测试的应用领域,接下来就是针对具体的领域关注点,确定性能目标(指标); 其中需要和其他业务部门进行沟通协商,以及结合当前系统的响应时间等数据,确定最终我们需要达到的响应时间和系统资源使用率等目标;比如:登录请求到登录成功的页面响应时间不能超过 2 秒;报表审核提交的页面响应时间不能超过 5 秒;文件的上传、下载页面响应时间不超过 8 秒;服务器的 CPU 平均使用率小于70%,内存使用率小于 75%;各个业务系统的响应时间和服务器资源使用情况在不同测试环境下,各指标随负载变化的情况等;

4、制定测试计划的实施时间

预设本次性能测试各子模块的起止时间,产出,参与人员等等。

三、测试脚本设计与开发

性能测试中,测试脚本设计与开发占据了很大的时间比重。

1、测试环境设计

本次性能测试的目标是需要验证系统在实际运行环境中的性能外,还需要考虑到不同的硬件配置是否会是制约系统性能的重要因素!因此在测试环境中,需要部署多个不同的测试环境,在不同的硬件配置上检查应用系统的性能,并对不同配置下系统的测试结果进行分析,得出最优结果(最适合当前系统的配置)。

这里所说的配置大概是如下几类:数据库服务器;应用服务器;负载模拟器;软件运行环境,平台。

测试环境测试数据,可以根据系统的运行预期来确定,比如需要测试的业务场景,数据多久执行一次备份转移,该业务场景涉及哪些表,每次操作数据怎样写入,写入几条,需要多少的测试数据来使得测试环境的数据保持一致性等等。可以在首次测试数据生成时,将其导出到本地保存,在每次测试开始前导入数据, 保持一致性。

2、测试场景设计

通过和业务部门沟通以及以往用户操作习惯,确定用户操作习惯模式,以及不同的场景用户数量,操作次数,确定测试指标,以及性能监控等。

3、测试用例设计

确认测试场景后,在系统已有的操作描述上,进一步完善为可映射为脚本的测试用例描述,用例大概内容如下:

用例编号:查询表单_xxx_x1(命名以业务操作场景为主,简洁易懂即可) 用例条件:用户已登录、具有对应权限等

操作步骤:系统业务场景描述

4、脚本和辅助工具的开发及使用

按照用例描述,可利用工具进行录制,然后在录制的脚本中进行修改;比如参数化、关联、检查点等等, 最后的结果使得测试脚本可用,能达到测试要求即可;建议尽量自己写脚本来实现业务操作场景,这样对个人技能提升较大;一句话:能写就绝不录制!!!

四、测试执行与管理

在这个阶段,只需要按照之前已经设计好的业务场景、环境和测试用例脚本,部署环境,执行测试并记录结果即可。

1、建立测试环境

按照之前已经设计好的测试环境,部署对应的环境,由运维或开发人员进行部署,检查,并仔细调整, 同时保持测试环境的干净和稳定,不受外来因素影响。

2、执行测试脚本

这一点比较简单,在已部署好的测试环境中,按照业务场景和编号,按顺序执行我们已经设计好的测试脚本。

3、测试结果记录

根据测试采用的工具不同,结果的记录也有不同的形式;现在大多的性能测试工具都提供比较完整的界面图形化的测试结果,当然,对于服务器的资源使用等情况,可以利用一些计数器或第三方监控工具来对其进行记录,执行完测试后,对结果进行整理分析。

五、测试分析

1、测试环境的系统性能分析

根据我们之前记录得到的测试结果(图表、曲线等),经过计算,与预定的性能指标进行对比,确定是否达到了我们需要的结果;如未达到,查看具体的瓶颈点,然后根据瓶颈点的具体数据,进行具体情况具体分析(影响性能的因素很多,这一点,可以根据经验和数据表现来判断分析)。

2、硬件设备对系统性能表现的影响分析

由于之前设计了几个不同的测试环境,故可以根据不同测试环境的硬件资源使用状况图进行分析,确定瓶颈是在数据库服务器、应用服务器抑或其他方面,然后针对性的进行优化等操作。

3、其他影响因素分析

影响系统性能的因素很多,可以从用户能感受到的场景分析,哪里比较慢,哪里速度尚可,这里可以根据 258 原则对其进行分析;至于其他诸如网络带宽、操作动作、存储池、线程实现、服务器处理机制等一系列的影响因素,具体问题具体分析,这里就不一一表述了。

4、测试中发现的问题

在性能测试执行过程中,可能会发现某些功能上的不足或存在的缺陷,以及需要优化的地方,这也是执行多次测试的优点。

鉴于篇幅所限,无法全部展示这份软件测试核心笔记,需要的朋友点击下面链接自取。

软件测试核心笔记

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇

)">
下一篇>>