①首先，需求分析阶段，分析需求点，需求确定以后进入测试计划阶段，参考需求规格说明书进行测试计划编写

②接着，进入测试设计阶段，依据需求文档及原型图编写测试用例，并进行用例评审

③进入测试执行阶段，需要搭建测试环境，执行冒烟测试之后进入正式测试，并且将测试缺陷进行提交及跟踪，经过多轮回归测试，直到测试版本结束

④最后，进入测试评估阶段，对软件版本质量进行评估，输出测试报告，确认是否上线。

 （1）单元测试

（2）集成测试

（3）确认测试

（4）系统测试

（5）验收测试

 （1）首先，评估项目的测试范围盒周期，是否能够单独完成

（2）做好测试策略和计划安排，保证每个环节按时完成

（3）在上手测试前，树立大致的测试点，先做冒烟测试

（4）测试中，尽量通过一些技术手段提升测试效率

（5）项目中，如果碰到解决不了的问题，要及时寻求解决方案

（6）及时对bug进行追踪，推动开发尽快解决bug

（7）把控发布标准，测试报告中标明上线风险

（1）测试计划是偏管理性质的文档（通俗来说就是解决【谁来做？】【做什么？】的问题），测试方案是偏技术类型的文档（解决【怎么做？】的问题）

（2）测试计划主要包含测试的目的与范围，角色与职责，资源及安排，风险与乐队，测试标准等信息；测试方案主要包含测试方法，测试环境与测试工具等内容

 （1）测试目的（Why）

（2）测试范围（What）

（3）测试时间安排（When）

（4）人员任务分配（Who）

（5）测试环境（Where）

（6）测试方法和策略（How）

（1）测试项目、用例编号、测试标题、优先级、预置条件、操作步骤、测试数据、预期结果

（2）黑盒测试，常用等价类，边界值，错误推测法

（3）等价类划分有效和无效等价类，测试某等价类的代表值就等于对这一类的其他值的测试，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的数据取得较好的测试结果

（4）边界值是对等价类划分方法的补充，针对各种边界情况来设计测试用例，可以查出更多的错误，使用边界值分析方法设计测试用例的话，首先应该确定边界情况，选取刚刚大于或者小于编址的值作为测试谁

（5）对于错误推测法，是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的去设计测试用例的方法

（1）熟悉并分析项目业务需求

（2）依据功能模块划分，使用等价类、边界值等黑盒测试方法进行用例设计，先整理功能正常的用例，再进行每一个操作的异常用例的覆盖，补充业务约束，功能交互项，数据验证项等

（3）每个功能模块分别写完用例以后，从项目的业务流程考虑，是否都进行了用例的覆盖

（4）编写完成后，提交评审

（1）白盒测试是基于代码的测试

（2）方法：语句覆盖，判定覆盖，条件覆盖，条件判定覆盖，条件组合覆盖，路径覆盖

 （1）GET：获取数据和资源

（2）POST：发送数据给服务器，创建或者更新资源

（3）PUT请求：用来创建或者替换目标资源

（4）PATCH，对资源进行部分修改

（5）DELET，删除资源

 （1）安全性：HTTP明文传输，易受攻击，HTTPS安全性更高

（2）端口：HTTP：80，HTTPS：443

（3）灵活性：HTTP简单快速，https门槛较高

（1）应用层：网络服务于用户的一个接口

（2）表示层：数据的表示

（3）会话层：建立、管理、终止会话

（4）传输层：定义传输数据的协议端口号

（5）网络层：进行逻辑地址寻找，实现不同网络之间的路径选择

（6）数据链路层：建立逻辑连接，进行硬件地址寻址功能

（7）物理层：建立、维护、断开物理连接

（1）第一次握手:客户端向服务器发起，用来申请建立连接

（2）第二次握手：服务器回复客户端，用来确定并接受连接请求

（3）第三次握手：依旧是客户端发给服务器，用来确认服务器的回复消息

 （1）第一次挥手：客户端向服务器发起，用来申请断开连接

（2）第二次挥手：服务器回复客户端，用来确定客户端上一个断开连接请求的

（3）第三次挥手：服务器 发给客户端，告知客户端服务器的数据发送完毕了，需要断开连接

（4）第四次挥手，客户端回复服务器，确认服务器的上一个断开连接请求

（1）进行DNS域名解析

（2）建立TCP连接，发起三次握手

（3）发送一个HTTP请求

（4）服务器处理相关的请求并返回处理后的结果

（5）关闭TCP连接

（6）浏览器接受到服务器处理后的结果后，开始解析

（7）浏览器将解析后的资源进行请求，并对页面进行渲染展示

 （1）TCP面向连接，UDP无连接

（2）TCP可靠，能保证数据传输无差错，UDP尽最大努力交付，不可靠

 （3）TCP传输效率较低，UDP效率高，适合注重速度不在意丢包的场景

 （1）B/S架构：浏览器-服务器，不需要安装客户端，只需要通过浏览器就能访问，升级只需要更新服务器，需要考虑浏览器兼容性

（2）C/S架构:客户端-服务器端，需要安装一个客户端才能使用，需要考虑安装卸载

①考虑接口的正常使用

②业务约束规则验证：包括鉴权、逻辑约束

③考虑请求参数必填字段：

（1）参数长度边界值验证

（2）类型异常、null

（3）参数名错误、参数个数

（4）参数组合验证

④容错能力，大量数据，频繁请求，重复请求（如订单）

 （1）考虑接口正常调用

①按照接口定义，传递正确的接口信息，然后查看返回的响应结果和数据库数据是否正确

②传递的请求数据覆盖有效类，边界值

③返回的响应结果的每个字段都需检查

（2）考虑请求参数的错误、异常情况

①请求数据异常值：空值，长度类型异常

②业务约束：订单状态必须确认收货后才能评价

③输入错误的参数名：多一个参数，少一个参数，看接口是否正确处理

（3）安全性测试

①敏感数据，是否加密传输

②返回数据是否含有敏感数据

③接口是否防止恶意请求：如大量伪造请求接口致使服务器崩溃

（4）性能测试

①并发请求相同的接口，查看接口的处理情况

②接口响应时间在用户可接受范围内

③对于业务操纵频繁的接口做压力测试，监控性能资源

 （1）需要，接口测试主要是为了尽早发现问题提前介入，可以返现页面上发现不了的bug，还可以提高系统的稳定性

（2）虽然接口测试覆盖了所有功能层面的逻辑测试，但跟前端界面进行集成的时候，依然会出现问题，所以我们依旧需要所有功能在前端界面的测试验证

（1）请求参数：get请求参数是放在url里面，长度收到限制，安全性较差，而post请求参数是放在请求体里面的，长度没有限制，安全性相对较高

（2）访问：get请求可以通过浏览器直接访问，支持刷新和后退。post请求，不能直接被浏览器访问，刷新后台需要重新传送

 （1）先确认自己传参时的接口地址，请求方式，请求头和请求体是否正确

（2）如果正确，查看返回结果和接口文档进行对比，如果一致

（3）则判断数据库中的数据是否有问题

web测试：B/S架构，通过浏览器访问

App测试: C/S架构，通过客户端操作

（1）系统架构方面，web端，只需要更新服务器；App，服务器端和客户端都需要回归测试一遍

（2）客户端性能方面：web一般只需要关注响应的时间，App还需要关注流量，电量，cpu，内存

（3）兼容性方面：web要考虑不同操作系统下不同主流浏览器的兼容，App要考虑不同产商机型、操作系统、屏幕尺寸分辨率等兼容性问题

（1）安装卸载：

小程序不需要下载安装，不需要卸载；App需要下载并且安装后才能使用，清除时需要卸载

 （2）开发周期

小程序开发周期约2周，发布审核时间较短

App：需要在支持的android和ios平台分别开发，周期较长，审核时间也较长

（3）登录权限

小程序：一般微信登录，无需注册

App：需要注册登录系统，权限方面需要考虑是否可以访问手机通讯录，相册，相机

（4）兼容性

小程序：基于不同的公众平台，主要兼容不同的微信版本

App：考虑不同机型的兼容，分辨率，屏幕尺寸，操作系统等....

（1）硬件兼容性：需要覆盖市面上主流手机厂家及各型号的产品

（2）操作系统兼容性：对app安装及卸载测试，测试app能否正常运行

（3）分辨率的兼容性：对主流设备的分辨率及屏幕尺寸，测试app界面实现及排版是否正常

（4）网络兼容性：在不同的运营商下，app是否能够正常运行，需要真机环境进行测试

（1）长连接（保持连接时间比较长）

一个HTTP连接的建立需要三次握手，握手成功后，才可以建立数据包传输，为了降低握手的频率，在接口请求头部connection为keep-alive，如果一段时间不用，服务器就会主动发一段探测报文，看看连接状态，如果探测不通，服务器端就会主动断开连接

（2）短连接（连接时间很短）

需要的时候才会建立一个tcp连接，数据传输完成就结束

 （1）1xx（临时响应）：表示需要请求者继续执行操作

（2）2xx（成功）：表示成功

（3）3xx（重定向）

（4）4xx（客户端请求错误）

（5）5xx（服务器错误）

 （1）功能

①说出不同愿望（钱+人+精神需求），看魔盒是否都能实现

②说愿望，只说部分关键字，看是否能正常识别

③不说愿望，看魔盒是否提示人许愿

④是否会有魔盒实现不了的愿望

⑤许愿次数是否有上限

⑥是否有许愿咒语

（2）界面：外表设计是否符合审美要求

（3）兼容：声音大小，是否影响魔盒接受许愿者的愿望

（4）性能：连续多次许愿后，魔盒是否还能正常使用

 （1）功能操作卡

①反馈提交的资源过大，导致请求慢

②服务器对于当前请求的人数过多，导致卡

（2）整个app卡

①网络异常

②app占用内存大，导致手机内存不足

③当前app与其他软件、手机系统不兼容

④服务器资源不足，请求慢

功能测试

目的：确保所有功能按照设计要求正常运作。

直播创建：测试用户是否可以成功创建直播，包括设置标题、封面图、分类等。直播推流：检查推流功能是否稳定，测试不同设备和网络条件下的推流质量。实时互动：验证直播过程中聊天、弹幕、礼物等互动功能是否正常工作。直播结束：测试直播结束后的处理，包括保存直播记录、直播回放的生成和展示

 （1）抢劵设置是否正确，不同时间节点、优惠券类型，优惠券数量

（2）查看不同抢券时间点是否正常显示该优惠券

（3）测试优惠券不同状态，待开抢、正在抢、抢光了

（4）验证是否准点实现“开抢”按钮；抢到券显示抢券成功并能在我的优惠券页面查看，未抢到显示抢光了，并能正确回退到我的优惠券页面查看。

（5）后台是否记录到了每位抢券的用户相关信息

（6）一个用户id是否同一时间点、不同时间点抢多次券

说下模块的功能测试点怎么整理的？

（1）功能测试：

主要关注水杯基本功能

1、水杯是否可以正常装水

2、水杯是否可以正常喝水

3、水杯是否有盖子，盖子是否可以正常盖住

4、水杯是否有保温功能，保温功能是否正常保温

5、水杯是否会漏水，盖住盖子拧紧后是否会漏水

（2）界面测试：

主要关注水杯外观、颜色、设计等方面

1、外观是否完整

2、外观是否舒适

3、颜色搭配及使用是否让人感到舒适

4、杯子外观大小是否适中

5、杯子是否有图案，图案是否易磨损

（3）易用性测试：

主要关注水杯使用是否方便

1、水杯喝水时否方便

2、水杯拿起放下是否方便，这里会行注到水杯形状的测试

3、水杯装水是否方便

4、水杯携带是否方方便

5、水杯是否有防清功能

6、水杯装有低温或者高温水时，是否会让手感到不适

（4）性能测试：

1、水杯装满水时，是否会露出来

2、水杯最大使用次数

3、水杯的保温性是否达到要求

4、水杯的耐寒性是否达到要求

5、水杯的耐热性是否达到要求

6、水杯掉落时时，是否可以正常使用

7、水杯长时间放置时，是否会发生泄露

 （1）检查图片上传路径

（2）检查图片上传和修改功能

（3）检查各种扩展图像文件的上传

（4）检查文件名中含有空格或其他可用特殊字符的图片的上传

（5）检查重复名称图片上传

（6）图片尺寸大于最大允许值，上传时是否会有提示信息

（7）上传过程中的取消按钮是否有效

（8）上传文件的类型是否有限制

 手机拍照功能怎么测试？

界面、功能、兼容性、易用性

（1）界面：是否和界面原型图一致，考虑浏览器不同显示比例，屏幕分辨率

（2）功能：给不同人员打电话，不同运营商，测试按钮是否都能正常使用，多次拨打

（3）兼容性：不同系统版本，屏幕大小，内存大小

（4）易用性：操作是否越多越好

.给你一个 N95 口罩你要怎么编写测试用 例？

你讲一下登录功能，你会考虑哪些测试 点呢？

你能说说“支付功能”怎么测试么？

发现问题背景

在外卖下单派送功能的测试中，我们发现了一个严重的 bug：在用户选择配送时间段后，系统没有正确地将配送时间应用到订单中，导致订单的实际配送时间与用户选择的时间段不匹配。这一问题可能会影响用户体验，尤其是当用户对配送时间有明确要求时松本山雅分析预测推荐。

测试过程

测试步骤：

登录应用：使用测试账户登录外卖应用。选择商品：从餐厅菜单中选择几种商品，并添加到购物车中。下单流程：进入结算页面，选择配送地址和时间段。提交订单：确认订单详情并提交。

验证问题：

订单追踪：进入“我的订单”页面，查看刚刚提交的订单详情。时间验证：检查订单的配送时间是否与用户选择的时间段一致。

在测试过程中，我们发现订单的实际配送时间与用户选择的时间段不一致，出现了预期与实际不符的情况。

排查过程

重现问题：

重复测试：多次重复以上测试步骤，确认问题的存在不是偶发的。不同时间段：测试不同的时间段选项，验证是否所有时间段都出现相同的问题。

查看日志：

系统日志：查看服务器和客户端日志，检查订单处理的各个步骤是否有异常记录。错误日志：注意日志中的错误信息，特别是与时间相关的错误。

排查代码：

检查前端代码：审查时间选择器的代码，确保用户选择的时间被正确地提交到后端。后端逻辑：审查处理订单的后端代码，确认时间选择是否被正确地接收和处理。

数据库验证：

数据库记录：检查数据库中的订单记录，确认实际存储的配送时间是否与前端传递的时间一致。时间字段：确保数据库表中相关时间字段的格式和数据类型正确。

业务逻辑分析：

时间处理：分析订单时间处理的业务逻辑，确保没有逻辑错误导致时间设置不正确。时间转换：检查是否有时间格式转换错误或时区问题。验证过程

修复方案：

与研发讨论：将发现的问题详细报告给研发团队，协助他们分析问题根源并提出修复方案。代码修改：研发团队根据问题排查结果修复了代码中的时间处理错误，确保用户选择的时间段能够正确应用到订单中。

重新测试：

功能验证：修复后，重新进行相同的测试流程，确认问题是否已经解决。边界条件测试：测试各种时间段的边界条件，确保修复后的功能在所有情况下都能正常工作。

用户验证：

回归测试：在其他相关功能上进行回归测试，确认修复没有引入新的问题。用户反馈：在生产环境中监控用户反馈，确保修复后的功能在实际使用中没有再出现类似问题。帮助研发的方式

详细描述问题：在问题报告中提供详细的步骤、日志和截图，帮助研发团队快速定位问题。协助分析：与研发团队密切合作，分析日志和代码，提供必要的技术支持。验证修复：在问题修复后，进行全面的测试，确认修复的有效性，减少反复修改的时间。

（1）提交

（2）确认

（3）分配

（4）修复

（5）验证

（6）关闭

（1）代码错误、界面错误、设计缺陷、配置相关、性能问题

（2）参数的校验，边界值，复杂的逻辑，异常的业务场景

 （1）bug标题、bug模块、bug对应的版本、bug严重级别、bug详细现象描述、复现步骤

（2）唯一性：一个bug说明一个问题

（3）bug描述要前后一致，不能有歧义

（4）附带bug现象截图、报错日志

（5）bug不能带有个人观点，对事不对人

（1）先和开发说明bug情况，再定位分析bug，判断是前端还是后端bug再去提交bug

（2）简单清晰的bug标题，重现步骤，分析bug和预期正确结果，附加bug的截图或者日志

（3）提交完bug以后，还要跟踪bug修复情况

（1）用禅道管理

（2）提交bug给开发人员

（3）开发人员进行确认激活，修复完成后，标明修复状态

（4）测试人员复测通过则关闭bug，不通过打回给开发

 （1）致命：对业务有至关重要的影响，业务系统完全丧失业务功能

（2）严重：业务系统丧失部分业务功能

（3）一般：较小影响，界面错误，打印错误

（4）提示：无影响，辅助说明不清楚，提示不明确

（1）界面排版布局错误，兼容性问题，在网络不稳定下导致的js/css未加载完全或请求超时，也是前端bug

（2）对于数据或者逻辑处理上的问题，可以通过抓包工具fiddler，或者查看日志分析

①抓包工具：

检查请求地址、参数的正确性

不正确则为前端bug；

若正确进一步检查服务器返回的响应，若响应内容不正确，则是后端处理出错

请求和响应都正确，就是前端渲染响应的数据出错

②报错日志，分析日志里面的异常报错信息，查看数据库数据判断前端还是后端问题

 （1）首先确认开发环境是否和自己的测试环境一致，缓存有没有清除

（2）看bug是否能够重现，级别低的bug先记录到平台，级别高的bug对应需求文档的预期结果跟开发说明，实在不行找产品确认

 （1）复现率低的bug，要提交，描述清除问题的复现步骤，环境，测试数据和日志信息

（2）如果未复现，在接下来的测试中，时刻保持关注，每次执行同样的或者相近的步骤时候，看能否复现之前的bug

（3）如果一直未复现，可暂时关闭bug，备注说明关闭不是因为修复，而是经过多个版本后不复现了

 （1）判断页面的域名是否可以正常解析到

（2）ping命令判断服务器是否可达，如果不可达用trance route命令，查看一下是哪个节点出现问题

（3）如果不是网络问题，再去后台服务器查看服务进程有没有开启，数据库有没有开启

 （1）当发现线上的bug，应该快速响应处理，先积极配合开发重现bug来定位问题，如果严重bug，需要积极解决，更新版本，如果bug不是那么严重，则放到下一个迭代版本中处理。

（2）总结bug出现的原因和规避方案

①测试用例覆盖不全面---》优化测试用例，增加用例评审

②测试的时间不充分，规划充分的测试时间，严格按照时间节点完成测试工作

③测试的环境或者测试的数据受限---》在真实环境下覆盖测试

④开发人员修复其他问题时，引入了新的bug---》明确测试范围，尤其是代码修改的功能部分，回归测试时，主流程必须回归，必须是一个完整流程

（1）在fiddler中result右键customize rules，打开CustomRules.js文档

（2）修改文档中，每上传或下载1kb数据需要的时间来模拟弱网场景

（3）然后点击Simulate Modem SPeeds，开启弱网模拟

 （1）主要是修改请求和响应的数据

（2）比如提交订单，金额是200，测试时想篡改金额，可以通过fiddler对before requests设置断点，修改请求数据，传一个520金额，检查服务端是否会正常处理。

（3）测试会需要返回不同的数据前端展示，可以after response设置断点，修改返回的数据查看前端实现效果

 （1）

（1）Group by是分组

（2）Order by是排序 

两者如果要一起使用的话，先分组后排序

（1）where 子句中的条件表达式having都可以跟，而having有些 不行

（2）having子句可以用聚合函数（sum、count、avg、max），而where不行

（1）左连接（left join）显示左表所有数据及右表满足条件的数据，右表无数据则显示null

（2）右连接，则是显示右表的所有数据，及左表满足条件的数据，左表无对应数据则显示null

（3）内连接（inner join）显示左右两张表连接字段相等的数据

（1）查看日志命令，包括tail。head、cat、less等

（2）如果过多，可以通过tail -f查看实时日志 ，也可以加上grep错误关键字来过滤

（3）如果操作报错，使用ctrl+c结束日志打印，依据操作时间找到exception关键字后面的报错信息

（4）我们根据日志目录找到对应的日志文件，用 tail -200，或者 tail-500 查看文件内容

也可以重定向导出来查看。 如果是系统出现了异常导致的错误，我们跟去查找关键字，比如说 error 或者 exception 等 如果是逻辑错误，会把操作对应时间的日志跟对应开发一起去定位 bug

（1）开发会基于部署文档构建新镜像生成一个压缩包

（2）测试把压缩包传递到测试服务器，直接加载镜像，然后docker run 运行容器，并映射tomcat端口8080，mysql端口3306，以此完成测试环境部署

（1）vi或者vim，可以直接对linux文本进行编辑并保存

（2）sed，流式编辑器，以行为单位进行文本操作

（3）awk以行为单位进行文本编辑，也可以列为单位进行文本编辑

（4）cut对文本进行切割，以行为单位进行文本处理

（5）sort，对制定的文件按照一定的规则进行排序

 （1）-A，列出所有的进程

（2）-w，显示价款可以显示较多的资讯

（3）-au，显示较纤细的资讯

（4）-aux，显示所有包含其他使用者的行程

（1）一般用来定位后端bug

（2）tail -f 日志文件名来查看日志

（3）容器部署，docker cp 【容器ID】：【容器内部路径】【linux路径】方式导出日志到linux，再通过xftp将日志导出到本地查看

根据自己的项目整理完成，要点：

1）项目背景：专门为餐饮企业（餐厅、饭店）定制的一款软件产品，包括 系统管理后台 和 小程序端应用 两部分。

2）项目架构：B/S

数据库：mysql

3）系统管理后台主要提供给餐饮企业内部员工使用，可以对菜品、订单、员工等进行管理维护。

4小程序端主要提供给消费者使用，可以在线浏览菜品、添加购物车、下单、支付、催单等

 根据自己的项目整理完成，核心要点：

1）拿一个你负责过的模块，核心业务模块讲解

2）业务流程是怎样的，需求怎么样，有什么规则没，规则简单介绍

3）你是如何分析的，讲明分析思路，测试点，主要怎么考虑测试的，主要核心测试重点在哪里，

用了什么测试方法等等。

在回答您的问题之前我想了解一下贵公司的加班制度是怎样的，如果项目组比较忙，加班是没有问题的。

1.公司现在做什么项目

2.公司目前做哪方面测试

3.公司这边测试人员分配比例

4.进入公司，我这边大概的工作安排

5，公司这么后续发展机会还有培养

6，有没有培训

7，面试没有回答上的问题，再去请教

1、个人性格合适

2、前景还可以

3、个人技能也匹配