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

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

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

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

哦不，不是没学明白，是没学清楚！

腾讯的面试官就贼喜欢问软件测试基础部分，字节的还好…所以在我以前通过校招上岸字节跳动后，将我自己的秋招找工作认真总结，并且开源在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、其他影响因素分析

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

4、测试中发现的问题

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

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

软件测试核心笔记