软测
https://blog.csdn.net/weixin_46486131/article/details/120384652
https://gqa1lpz031e.feishu.cn/docx/XaTUdisiBo1u4FxgBPocr28rnZ6
JD
介绍和项目经历
面试官您好，很高兴有机会能参加这次面试！我是yyf，专业是软件工程；在校期间，我拿到了英语四级证书计算机三级数据库证书等，我在今年的6-12月份在科大讯飞实习，实习的岗位是软件测试实习生，在咱们测试方面我参与过大大小小的很多项目，其中较为有代表性的是商城后端外卖系统的这个测试
在公司做的项目是为中小学生提供个性化学习辅导和资源的教育服务平台，这个项目主要是为了能够更好的利用资源服务好师生和家长，这个项目主要有web端，app端，web后台管理端，我负责的模块是数智作业方面的一个制卡的功能测试和发布测试，方便老师或其他人员在制卡的时候不出现问题和顺利发布到学校作答，我主要是负责测试计划和测试用例的编写，对bug的追踪和管理，部分接口测试以及功能测试，也涉及到一些基本的自动化的测试，最后我本人对软件这个行业很有兴趣，也希望在软件测试这行业得到一定的成长，以上是我的基本情况，谢谢。
实习做了什么？
就是我们主要负责的产品，他们会就是做一个需求文档，然后需求文档做完之后，他们就是开一个需求文档的需求评审会议。然后就是UI和交互，它之后会出一个这种原型图和交互稿，然后之后做完过后就是测试组长和那个开发组长，他会召开，我们就是开一个选代会议，然后给我们发现分配任务嘛，然后每个人拿到那个任务过后就会，我们就有需求文档，就会用需求文档提取一下那个测试点，然后等到那个开发，他们把那边把开发方案写好过后，就会让我们去那个是给我们开一个开发方案的评审会议嘛。
然后我们就比如说需求文档，当时有不懂的就在这个会议上提出来去问，然后懂了过后就是后面就补全一下测试点，然后之后就是编写测试用例，然后测试用例过后就是编写完过后，我们会评发起一个用例评审，然后用例评审结束过后，我们会拿出比如说优先级最高的 10% 给开发，然后开发冒烟用例就当他来自测，自测完过后就是给我们提测!，然后我们就是正常的有 bug 就提交bu然后再验收一下那个bug。然后就是全部测试完过后，我们也有回归测试，然后后面就是测完后就会上线。
根据上述职责的描述，以下是详细的步骤和方法，具体分为功能测试、性能测试和自动化测试三个部分：
1. 功能测试
功能测试的目标是验证点单模块的各项功能是否符合需求。
需求分析：
阅读需求文档（PRD、BRD），明确点单模块的功能点，例如菜单展示、下单、支付、订单状态等。
测试用例设计：
编写测试用例，覆盖以下场景：
正常场景：如选择商品并成功下单。
边界场景：如空购物车无法下单。
异常场景：如库存不足或支付失败。
测试执行：
手动执行测试用例。
使用 Fiddler 抓包，验证接口返回的数据是否正确。
捕获请求和响应。
检查关键字段（如订单号、价格、状态码等）。
使用 Postman 发送接口请求，模拟前端发起的请求。
测试接口的功能是否正确。
验证接口的响应时间、状态码及返回数据。
缺陷报告：
将发现的缺陷记录到缺陷管理工具中（如 Jira 或禅道）。
包括复现步骤、环境、实际结果和预期结果等。
2. 性能测试
性能测试的目标是评估点单模块在高并发和大数据量情况下的响应时间、吞吐量等。
测试环境搭建：
确保测试环境与生产环境一致。
准备并发用户的数据和模拟场景。
使用 JMeter 设计性能测试：
创建 Test Plan。
配置 Thread Group：
设置用户数（如 100 个并发用户）。
设置 Ramp-Up 时间（如用户逐步增加的时间）。
设置测试持续时间（如 10 分钟）。
添加 HTTP Request Sampler：
填写接口 URL、请求方法（GET/POST）、请求参数等。
添加 Listeners：
如查看响应时间、吞吐量、错误率的图表。
执行性能测试：
启动测试计划，观察实时数据。
分析测试结果：
响应时间是否在接受范围内。
吞吐量是否满足要求。
系统是否出现错误（如超时、崩溃）。
优化建议：
如果性能指标未达标，根据测试结果分析瓶颈，提供优化建议（如数据库索引优化、负载均衡等）。
3. UI 自动化测试
UI 自动化测试的目标是验证界面交互和功能是否符合预期。
选择工具：
使用适合的工具（如 Selenium）。
配置测试框架（如 Python + Selenium + unittest 或 pytest）。
测试脚本开发：
运行脚本：
结果报告：
4. 接口自动化测试
使用 Python + requests + unittest：
执行脚本：
集成测试：
将脚本集成到 CI/CD 流程中（如 Jenkins），实现自动化测试。
面试常见问题
软件测试工作流程
首先产品会组织测试开发进行一个需求评审，我们在需求评审上会先去熟悉需求，包括一些需求不合理的地方提出自己意见和建议，需求评审结束以后就开始制定测试计划了，制定好我们这个版本谁来测，测什么东西，要测多久，然后再根据分配任务就自己去写需求的测试用例，等测试用例完成以后，然后等后端开发完就扣进行接口测试，通过postman去调用接口，看这个接口是否是通的，是否跟接口文档一致，那么接口测试完成后，这个时候前端也差不多对APP开始提测，先对提测版本进行冒烟测试，简单测试一下看功能是否正常，冒烟测试通过后，就可以进行专门的功能测试了，就拿之前写好的测试用例去进行执行，检测看有没有bug，有bug呢就通过禅道这类bug软件进行提上去给开发解决，并且对bug进行一个持续的跟踪，直到bug关闭，等整个的功能测试完成后呢会进行一些专项测试，比如兼容性测试或者网络测试，像弱网测试或者是安全测试等新功能都测试完，还会对老功能就行回归测试来保证老功能没有问题，等测试都完成后会便携测试报告，写清楚这个版本测试是否通过，以及版本测试信息，测试人员测试时间，测试内容，测试用例覆盖率等等然后开发进行打包上线，等上线通过后，会进行一些线上验证，把线上的包下载下来用一下看新功能是否真正上线了，老功能有没有收到影响，并且会持续跟踪一些用户的反馈
冒烟测试：对软件整个基础功能进行测试，看整个功能有没有实现，有没有出现功能缺失，就是检查整个的基本功能是否能够正常的运行
测试用例设计
先从功能考虑起，看正常情况能不能成功，这个功能之后的场景，然后考虑非功能场景，兼容性：不同浏览器，操作系统；网络：4g，5g，wifi；接口：jmeter，postman，fiddler；性能：jmerter；数据库校验，ui
用场景法，把功能拆成xx点；再看等价类，有效等价类，无效等价类（xx成功xx失败）；边界值
边界值法，等价类法（有效无效），判定表
你提交的bug开发人认为不是bug
首先会看一下这是什么样的bug，如果是一个功能上的bug，那可以先提给开发或者演示给开发看，如果还是不行可以给开发的领导进行一些反馈；若是一个需求不明确所导致的问题，可以去找产品来明确一下这个需求到底是怎么样的，按产品的意思去做
遇到产品需求变更怎么办
先看一下是什么样的需求的变更，要是只是在开发阶段，时间充足那开发就重新开发，测试就重新写用例；如果是时间很紧急的临时变更需求，可以跟产品提意见，能不能放到下个版本去处理
如何定义一个bug是前端还是后端bug
一般APP用fiddler去定位，web可以通过F12或者fiddler去定位，首先通过fiddler去抓包，比如现在有一个登录的功能，我输入一个正确的用户名和密码没有登录成功，通过抓包去看，如果说在登录点击后比方密码是123456但是参数只有12345，或者请求根本没有发送，那肯定就是前端的问题了；；如果说前端有发出去正确请求但是服务器没通，或者服务器通了但是返回的信息不对像这种就是后端的问题了，后端在处理逻辑的时候出了问题；；那若前端发出了请求后端也正确的返回了但是还是哦登录失败有可能是前端没有按成功的返回来，那还是前端的问题
接口测试怎么测
流程
需求评审-接口文档解析-设计测试用例-进行接口测试-缺陷的管理与跟踪-生成测试报告
API文档：功能、参数、返回
首先我们就先通过jmerter先调用接口，我们在jmerter里面先添加线组，再添加http请求，我们再添加这个查看结果树对不对，我们在http请求里面在具体添加这个接口的一些信息，比如说有接口的ip地址，url地址还有接口的请求参数还有接口的请求方式，添加到http请求之后，再去调用接口
看结果树的返回结果，第一个看接口有没有通，通了以后看他跟接口文档是否一致；；我们也可以故意搞些错误的传参，比如故意参数名不传，或参数类型不传看接口会不会报错，如果涉及到数据库的改动，可以去数据库看一下对应的信息有没有发生变化，因为不会吧所有数据都返回给你比如我们测一个支付的接口，接口是通了也返回一个支付成功，但是可能收到一些其他的信息没有，所以要去数据库看一下，除此之外还可以用fiddler这种抓包工具去掉用接口就去抓包一下，看前段发出去的请求有没有问题，如果是一些比较重要的接口，看一下有没有加密能不能被篡改
接口测试需要用到用户的token怎么办
我们先去登录获取token值，在要到使用到的地方去引用一下token值，在jmerter通过正则表达式吧token值给提取下来，把他设置成一个参数，我们后面接口需要用到这些的地方就用${参数名}去引用一下
token值具有唯一性，具有临时性
如何去做自动化测试
一般会用Python做一些简答的自动化，通过Python这个requests库去调用接口去看一下具体的请求方式，get就是request.get，post就是request.post，再把接口信息添加进去跟添加到jmter一样添加对应的ip地址，url地址，还有其他的参数，然后吧信息打印出来，可以添加一个断言把关键词提取出来通过assert去添加一个断言，对比一下预期和结果是否一致，最后还可以添加一个pytest框架，创建以text为核心的文件名，以及以test开头的方法，把之前写好的用例封装成一个函数，添加到里面去就行，然后看返回通了还是没通
import unittest # 导入unittest模块，用于测试框架
import requests # 导入requests模块，用于HTTP请求
class APITest(unittest.TestCase): # 定义一个继承unittest.TestCase的测试类
BASE_URL = "https://jsonplaceholder.typicode.com" # 定义测试接口的基础URL
def test_get_posts(self): # 定义一个测试方法，用于测试GET请求
"""测试获取所有帖子"""
endpoint = "/posts" # API的具体路径
url = self.BASE_URL + endpoint # 拼接完整的URL
response = requests.get(url) # 发送GET请求并获取响应
self.assertEqual(response.status_code, 200) # 断言状态码是否为200
self.assertIsInstance(response.json(), list) # 断言返回的数据是否是列表类型
print(f"GET /posts - 成功，返回了 {len(response.json())} 条记录") # 打印成功信息
def test_post_creation(self): # 定义另一个测试方法，用于测试POST请求
"""测试创建新帖子"""
endpoint = "/posts" # API的具体路径
url = self.BASE_URL + endpoint # 拼接完整的URL
payload = { # 定义POST请求的负载数据
"title": "foo",
"body": "bar",
"userId": 1
}
headers = {"Content-Type": "application/json"} # 定义请求头
response = requests.post(url, json=payload, headers=headers) # 发送POST请求并获取响应
self.assertEqual(response.status_code, 201) # 断言状态码是否为201（资源创建成功）
self.assertIn("id", response.json()) # 断言返回数据中是否包含"id"字段
print(f"POST /posts - 成功，创建的记录ID为: {response.json().get('id')}") # 打印成功信息
def test_invalid_get(self): # 定义测试方法，用于测试错误请求的处理
"""测试获取不存在的帖子"""
invalid_id = 999999 # 定义一个不存在的资源ID
endpoint = f"/posts/{invalid_id}" # 拼接路径
url = self.BASE_URL + endpoint # 拼接完整的URL
response = requests.get(url) # 发送GET请求并获取响应
self.assertEqual(response.status_code, 404) # 断言状态码是否为404（资源未找到）
print(f"GET /posts/{invalid_id} - 失败，资源未找到") # 打印失败信息
if __name__ == "__main__": # 如果脚本是直接运行的
unittest.main() # 执行所有测试
印象深的bug
JMeter 进行接口测试
安装 JMeter
从官网下载安装 JMeter，解压后直接运行即可。
创建测试计划
打开 JMeter，新建一个测试计划（Test Plan）。
添加线程组
在测试计划下添加一个 Thread Group，设置线程数和请求次数。
添加 HTTP 请求
在线程组下添加 HTTP Request，填写接口的 URL、方法（GET/POST）、路径、参数等信息。
配置请求头（可选）
添加 HTTP Header Manager，填写请求头信息（如 Content-Type、Authorization）。
添加断言
添加 Response Assertion，设置预期响应结果（如包含某些关键字）。
添加监听器
添加 View Results Tree 或 Summary Report，用于查看测试结果。
运行测试
点击 Start 按钮运行测试，在监听器中查看请求和响应结果。
使用 LoadRunner 进行性能测试的流程
创建脚本 (VuGen)
打开 VuGen，选择一个协议（例如 HTTP/HTTPS、Web Services 等）。
录制脚本：
点击“录制”按钮，按照操作流程在浏览器或客户端中执行用户操作。
VuGen 会自动记录用户操作并生成测试脚本。
编辑脚本：
检查生成的脚本是否需要优化，例如添加动态参数（关联）、数据驱动（参数化）或逻辑控制（事务）。
使用 Checkpoints 验证服务器的正确响应。
2) 创建测试场景 (Controller)
启动 Controller，新建一个场景。
导入在 VuGen 中创建的脚本。
配置 测试场景：
用户负载：设置并发用户数。
运行模式：例如 并发用户增长 或 稳定负载。
运行时间：例如设置测试持续时间为 30 分钟。
监控设置：添加服务器监控，实时跟踪资源使用情况（CPU、内存、带宽等）。
3) 执行测试
点击运行按钮开始测试。
在运行过程中：
实时监控系统的性能指标。
注意错误或异常（如超时、崩溃）。
4) 分析测试结果 (Analysis)
打开 Analysis，导入测试结果文件。
生成性能报告，包括：
响应时间：不同事务的平均响应时间。
吞吐量：每秒处理的请求量。
并发用户数：系统可支持的最大用户数量。
错误率：用户操作的失败率。
可视化图表：
响应时间 vs 并发用户数。
资源使用率（CPU、内存）随时间的变化。
你还有哪些要问我的
请问软件测试岗位相关的考核指标有哪些？
请问软件测试岗位的薪资构成是怎样的呢？
软件生命周期
软件生命周期
是指软件生命周期是指一个计算机软件从功能确定设计，到开发成功入使用，并在使用中不断地修改、增补和完善，直到停止该软件的使用的全过程(从酝酿到废弃的过程)
阶段
软件计划、需求分析、软件设计、程序编码、软件测试、软件维护
常见模型
瀑布模型（线性开发，不可回溯）、增量模型（每模块作为一个增量组件）、快速原型（开发人员对用户提出问题进行总结，对原型进行反复修改）、螺旋（结合元素原型和瀑布模型，适用于大型）模型等
软件开发方法论：
敏捷开发：强调适应性、客户协作和快速响应变化。
Scrum：敏捷框架，通过迭代和增量方法管理产品开发。
极限编程（XP）：强调简单、交流、反馈和勇气。
Lean Development：消除浪费，快速交付价值。
软件过程模型：
V模型：强调测试和开发阶段的对称性。
RUP（Rational Unified Process）：统一过程的一种，强调迭代和用例驱动。
敏捷统一过程（AUP）：敏捷版本的统一过程。
软件工程原则：
抽象化：隐藏复杂性，只展示必要的细节。
模块化：将系统分解成独立的模块。
封装：将实现细节隐藏在接口后面。
继承：允许新的对象继承已有对象的特性。
软件项目管理：
项目规划：定义项目范围、时间和资源。
风险管理：识别、分析和响应项目风险。
配置管理：管理变更和版本控制。
质量保证：确保产品满足既定的质量标准。
软件工程
软件工程的三要素：方法、工具、过程
计算机软件：程序、数据、相关文档的集合
软件危机 泛指计算机软件的开发和维护过程中所遇到的一系列严重问题，例如软件呢的整张得不到满足，不可维护或维护程度低
四种基本活动PDCA：
（1）plan:软件规格说明。规定软件的功能及其运行中的限制
（2）do : 软件开发与软件设计与实现。生产满足规格说明的软件
（3）check:软件确认。确认软件能够满足用户的需求
（4）action: 软件演进。为满足客户的需求，软件必须在使用的过程中演进
软件开发过程： 把客户要求转化为软件产品的过程
软件开发声明周期：软件计划、需求分析、软件设计、程序编码、软件测试、软件维护
需求分析阶段的工作
需求获取
需求分析
编写需求规格书
需求评审
需求分析方法：结构化分析是：使用数据流图（DFD）、数据字典（DD）、结构化英语、判定表和判定树等工具；面相对象分析
设计的准则
（1）提高模块独立性
（2）模块规模适中
（3）深度、宽度、扇出、扇入适当
什么是软件测试：为了发现程序中的错误而执行程序的过程
测试的目的：以最少人力、物力和时间找出软件中潜在各种错误和缺陷，通过修正种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。
软件测试的准则
1.所有测试都应追溯到需求
2.严格执行测试计划，排除测试的随意性
3.充分注意测试中的群集现象
4.程序员应避免检查自己的程序
5.穷举测试不可能
6.妥善保存相关资料
黑盒测试方法与测试用例设计（用得最多）
黑盒测试方法也称功能测试或数据驱动测试。
黑盒测试是对软件已经实现功能是否满足需求进行测试和验证。
完全不考虑程序内部逻辑结构和内部特性，只依据程序的需求和功能规格说明，检查是否符合功能说明。
方法 ：
（1）等价类划分法
（2）边界值分析法
（3）错误推断法
白盒测试方法与测试用例设计
白盒测试：也称结构测试或逻辑驱动测试，根据软件产品内部工作过程，检查内部成分，以确认每种内部操作符合设计规格要求
在程序内部进行，主要用于完成软件内部操作的验证
（1）逻辑覆盖测试
语句覆盖、基本路径覆盖 、判定覆盖、条件覆盖、判断-条件覆盖
每个~至少经历一次
（2）基本路径测试
根据软件过程性描述中的控制流程确定程序的环路复杂性度量，用此度量定义基本路径集合，并由此到处一组测试用例对每一条独立执行的路径进行测试
以下是 Linux 中一些常见的命令，按功能分类并附带简要说明：
Linux常用命令
1. 文件与目录操作
2. 文件内容查看与编辑
3. 压缩与解压
4. 权限管理
5. 用户管理
6. 系统管理
7. 网络操作
8. 搜索
9. 时间与日期
10. 其他实用命令
总结
这些命令覆盖了日常 Linux 使用的大部分场景。在面试或实际使用中，熟悉这些命令不仅能够快速上手操作系统，还可以展示你对 Linux 的掌握程度。建议根据常用程度多加练习。
----------分割线------------以下无章节性-------------
xmind -> excel ->实际测试
测试用例：描述测试点执行的文档
测试用例八大要素
1、用例编号；
2、测试项目；
3、测试标题；
4、重要级别；
5、预置条件；
6、测试输入；
7、操作步骤；
8、预期输出
执行用例
对项目开始测试
准备：测试环境+项目
关注：实际执行与预期是否一致等
用禅道提交bug
业务测试
业务测试方法
流程图法
流程图设计测试点步骤
①确认流程图
②流程图从开始到结束每条路径都为一条测试用例
提示
项目先测主业务在测单模块
提测时先对主业务流程正向用例进行测试（冒烟）
项目测试
卖家：商品上架业务、发货业务、入库业务、核算业务…
在测核心业务中单功能/页面
买家：登录、搜索、购物车、下单、支付、订单状态、评论…
卖家：供货商管理、商品基本信息、出库、入库、促销活动…
本次目标:
核心业务：下单业务
核心模块：注册登录、搜索、购物车、下单、支付
判定表
多条件且条件意见有约束规则的需求设计测试点
组成：条件桩，条件项，动作桩，动作项
2的n次方种规则
软件测试分类方法
按照阶段划分
单元测试：针对程序源代码的测试【开发】
集成测试：针对功能模块组装的测试
系统测试：针对整个系统（功能、非功能）进行测试
验收测试：以用户身份验证系统是否满足需求【用户】
按代码可见度划分
黑盒测试：针对有UI界面软件系统输入输出类测试
灰盒测试：针对无UI界面软件系统输入输出和内部逻辑结构的测试(能看到部分源代码)
白盒测试：针对程序源代码及内部逻辑本身进行测试
其他
冒烟测试：保障提测内容具备可测性
回归测试：对已修复功能\更新后对已测内容再次测试
质量模型
功能、性能、兼容、易用、安全、可靠性、移植性、维护性
WEB测试
单功能
等价划分法
用少量数据获得较好测试结果的工具
场景：表单类页面元素测试
步骤
1.划分有效等价类
2.划分无效等价类
3.每类中选取代表数据
边界值分析法
选取：上点（边界上的点），离点（距离上点最近的点），内点（边界范围的任意点）
APP测试
功能测试 性能测试 专项测试
利用solopi进行手机端的测试
利用sdk，用命令进行Monky测试
AI进行
需求分析
测试计划
测试用例编写
测试用例执行
测试评估
