• 需求了解分析
• 需求评审
• 制定测试计划【包括测试人员、时间、每人负责的模块、测试的风险项以及预防】
• 编写自动化测试用例 —— 测试评审【尽量丰富测试点】
• 编写测试框架和脚本（若是功能测试 可省去这步骤）
• 执行测试
• 提交缺陷报告
• 测试分析与评审
• 预发布环境验收测试
• 提交测试总结
• 准备下一版测试

• 项目立项
• 需求分析
• 概要设计
• 详细设计
• 编码开发
• 测试
• 验收

技巧：难度、偶现等

• 全部测试用例都执行完成
• 未修改的Bug都别确认或设置为应有的状态，暂缓处理的问题都需要有详尽的备注，方便以后进行复盘或者查验
• 测试报告编写完成
• 测试收尾工作结束
• 测试总结完成
• 项目处于试运行或上线阶段
• 达成在测试计划中定义的结束标准

考测试思维

1. 是否能正常打开或进入短信界面
2. 短信可以正常编辑、修改、删除
3. 短信可以正常发送、接收
4. 短信页面的字体、颜色显示是否正常【UI界面  手机设置了字体颜色 大小是否同步】
5. 短信的字体是否能够调整
6. 同时给多个人发短信是否成功【是否多发、漏发】
7. 给特殊号码发短信

• 手机号所属运营商【10086】
• 其他运营商【10000】
• 不存在的手机号【是否反馈发送失败】
• 不给手机号 （空着 ）
• 服务号（收费、不收费）   【若收费 是否扣费成功 】               

 8.接收验证码

9.短信耗电量测试

10.短信是否消耗流量【正常不消耗流量】

11.短信干扰测试

• 编辑短信时，电话进来
• 编辑短信时，切换至其他应用在返回【检查之前编辑的内容是否存在】

测试思维拓展性

• 写、画
• 染色
• 。。。。

• 人力资源
• 硬件资源【性能、自动化、功能  服务器 分布式+高并发 】
• 软件资源【JMeter、postman等等】

冒烟测试就是完成一个新版本的开发后，对该版本最基本的功能进行测试，保证基本的功能和流程能走通。

冒烟测试也叫版本验证测试、转测测试等。冒烟测试主要是为了确定开发交付的转测物能否正常运行，检查主功能是否能够正常运行，一般有一个人进行短时间的测试判断转测物是否达到转测标准，是否值得进行大规模的测试，冒烟测试中一般不测试次要功能和各种细微错误

验收测试：一般供求双方达成。一般由用户进行的，确认是否可以接收一个系统的验证性测试，验收测试是根据用户需求，对业务流程进行正式测试，以确保系统符合验收标准。一般由客户、产品经理、测试、项目经理等介入参加，目的在于对系统建立信心，对系统非功能性的特性赢得客户认可【例如：小图标、界面的设计】。

一般有三种验收测试的主体。

α测试：软件的开发商自己进行的交付前的测试

β测试：软件的需求方自己进行的测试

γ测试：第三方的测试

测试计划一般包含了产品概述，测试策略【测试方法：功能 自动化 性能】，测试资源，测试周期【时间】，进度安排，测试方法、风险分析等

目的：指导测试过程，规定测试活动的范围，方法，资源进度。明确测试项目、要测试的内容，以及人员责任范围的划分。确保测试工作能够根据计划正常开展。

• 通读需求文档，理解需求和设计思路
• 想好测试策略，确定好测试环境，评估测试周期，确定影响范围
• 根据需求文档，输出测试点，XMind 包含整个需求相关的测试点及影响范围内的测试内容
• 根据XMind输出测试用例，利用等价值、边界分析法、场景法确保每个测试点都被测试用例覆盖
• 进入用例评审阶段，根据评审建议优化我的测试用例
• 开始执行测试用例

• 首先自我分析，是否是自己测试数据错误或者需求理解错误，先确保不是因为自己的问题导致的
• 如果确定测试数据、操作都没有问题，会先和开发沟通，阐述我的操作和理解以及复现福州，并以需求文档作为佐证，证明Bug的真实性和修复的价值
• 如果开发不认可，联系产品经理，同时对Bug进行跟进和判断，确定是否为Bug以及后续处理

• 相同点：都工作在传输层，目标都是在程序之间传输数据【大多数情况下使用TCP连接】
• 不同点：
  • TCP是基于连接的，三次握手【在不可靠的信道上建立可靠的连接】+传输确认【解决了丢包、乱序问题】+四次挥手【关闭连接】；UDP是无连接的，直接进行数据传输
  • TCP是可靠传输【丢包重传机制】；UDP是不可靠传输
  • UDP是面向报文传输，TCP是面向字节流的
  • UDP适合直播，实时游戏等场景

主要通过接口进行判断，产品开发基本是前后端分离的

抓包获取接口信息

1.判断请求接口URL、传参是否正确，页面展示数据异常，数据精度【100.00—> 100】异常的，交互流程异常都是属于前端的Bug

2.接口传参异常、业务处理异常、接口异常报错等错误，基本属于后端的Bug

3.也有时可能为前后端都能处理，要考虑处理成本和影响范围，使用最优解决方案来处理

Fiddler、Charles 主要是抓取http协议的接口信息用于辅助测试

用途：

1.从功能测讨的角度来说，通过抓包工具能够查看到页面上未显示的隐藏字段。而这些隐藏字段通常都有一些特的作用，能帮助查看前后端功能是否有异常。

2.通过抓包工具能够详细了解接口信息，方便开展接口或性能测试

3、通过抓包工具能够检查前端传参字段加密是否正确，例如登录的接口 密码是否加密 检查数据加密是否正确，安全行考虑 4、通过抓包也能更对的理解整个系统，通过抓包工具检查接口我能够确定提供接口服务的是哪个后端服务，方便我定位问题及分配bug。5、基于抓包工具代理的特殊性，我能手动篡改接口请求及返回信息，帮助我提交一些页面上不能构造的数据情况或数据结构，尽可能全面的测试覆盖后端代码逻辑，发现一些隐藏的bug。【不太了解】 6、同时，我也可以通过抓包工具限制网络带宽，构造特殊场景完成一些专项测试，比如说app弱网测试。【例如：APP弱网测试】

root账户是一个系统管理员账户，允许完全控制系统，可以使用root账户创建和维护用户账户，为每个账户分配不同的权限，每次安装linux都是默认root账户

linux查看文件使用什么命令 ？LS和LL什么区别？

一般使用ls命令，ls命令会直接返回目录下所有非隐藏文件和目录，而ll命令能够返回文件和目录的详细信息，比如说权限信息，文件大小，创建时间等

致命、严重、一般、提示

首先需要审视Bug的严重程度是否影响大部分用户使用，判断问题的轻重缓急 如果问题非常严重，已经影响了大部分用户的使用，这时候可能需要选择版本回退方案，尽快回复线上环境的正常运行

如果是个别用户收到了影响，就需要开发团队整体上协作，紧急迭代下一个版本上去进行Bug修复，同时对已经产生异常的数据进行修复

Bug解决后，需要进行复盘，分析问题发生的原因，总结经验教训，避免下次错误发生

---

元素定位的目的：使用Web自动化操作元素，让程序操作指定元素，就必须找到此元素

共有8种定位方式

• 与name有关的：name、class_name、tag_name【标签名定位】
• 与link相关的：link_text【精准匹配】、partitial_link_text【模糊定位】
• 与id相关的：id
• 全能的：XPath、css【常用】
• 如果存在id，优先使用id定位，比较简单，方便，CSS定位器

selenium中没有提供原生的方法判断元素是否存在

可以通过元素定位+异常捕获的方式来判断，比如说封装一个方法，找到元素就返回true，否则返回false， 以此来判断元素是否存在

遇到过的异常一般有四种

• 元素定位不到【ElementNotSelectableException】，这时候我就需要去检查我的元素定位表达式写的是否正确工比如动态元素可能我使用的属性值变了，是否存在多表单，当前所在页面是不是句柄是否正确，是否元素还没有加载出来，元素隐藏了，需要一定的操作交互才能显示出来;
• 元素无法正常交互，一般这时候我就需要去检查我定位的元素标签是不是可操作的，页面没有最大化，导致元素没有显示，拖动页面，展示隐藏的元素
• 超时【TimeoutException】，一般我会在自动化测试框架中封装好查找元素的方法，使用显示等待，超时没有找到元素就会报超时异常;
• 无法创建session【WebDriverException】，初始化浏览器driver的时候可能会报这个错，大概率会是所使用的驱动与浏览器版本不匹配需要去检查确认

我主要学习的UI【Web】测试框架是基于python语言编写的，基于PO设计模式封装，用pytest管理测试用例，yaml管理测试数据并参数化运行测试用例，通过allure生成测试报告，并集成了git和Jenkins，能够实现在Jenkins/gitlab上自动拉取最新的测试代码并进行测试【不太熟悉 】

不可以，自动化是对已有功能的测试用例进行自动运行，提高测试效率，解放人力专注于新逻辑新业务的测试，并不能创造性的进行工作。而手工测试有其不可替代的地方，因为人具有很强的判断能力，而工具没有。测试人员的经验和对错误的判断能力是工具不可替代的。人类的审美观和心理体验是工具不可模拟的。人们对是非的判断、逻辑推理能力是工具不具备的。

1. 等待元素出现： 使用适当的等待机制来等待页面加载完成以及与元素定位。Selenium提供了不同类型的等待，如显式等待（Explicit Wait）和隐式等待（Implicit Wait）

2. 定位元素的唯一性： 确保使用的元素定位方法是唯一的，可以准确地找到目标元素。使用ID、类名、CSS选择器或XPath等定位方法，但应确保选择的定位方法足够准确且不易受到页面结构的变化影响。

3. 使用XPath或CSS选择器： XPath和CSS选择器是两种强大的定位元素的方法，它们可以更精确地定位元素，并且相对于使用标签名称或类名等定位方法更加稳定。

4. 避免使用绝对路径： 尽量避免使用绝对的XPath路径来定位元素，因为页面结构的变化可能会导致绝对路径失效。尽量使用相对路径或其他更稳定的定位方法。

5. 使用try-catch处理异常： 在执行操作之前，使用try-catch语句来捕获可能出现的异常情况，例如元素未找到或不可点击等异常，在捕获到异常时可以进行相应的处理或重试操作。

6. 检查元素可见性和可点击性： 在执行操作之前，可以先检查目标元素是否可见和可点击，以确保元素在执行操作时处于正确的状态。可以使用Selenium提供的is_displayed() 和is_enabled()方法。

7. 日志记录和错误处理： 在测试代码中添加适当的日志记录功能，以便在出现问题时能够更容易地定位和调试错误。另外，编写健壮的错误处理代码，以处理可能出现的异常情况并进行适当的反馈或重试操作。【规范开发人员开发习惯，给页面元素添加唯一的name，id】

•  优化测试用例，设置等待时间的时候，少用固定等待（sleep），尽量不使用隐式等待，多用显示等待

• 减少不必要的操作步骤，如经过三四步才能打开要测试的页面的话，可以直接通过网址来加载

• 元素定位多用id等，定位速度较快

• 中断页面接在，如果加载的内容不影响我们测试，就设置超时时间，中断页面加载

1.在经常检测失败的元素前尽量加上显式等待时间，等要操作的元素出现之后再执行下面的操作;

2.多线程的时候，减少测试用例耦合度【两个模块之间相互交互】，因为多线程的执行顺序是不受控制的; 3.多用 try捕捉，处理异常: 4.尽量使用测试专用环境，避免其他类型的测试同时进行，对数据造成干扰【例如：当前正在搜索A用户，但数据库那边正在删除A用户信息，就会导致测试不通过】 5.测试用例框架里面设置失败重跑机制【可以理解为对Bug的复现】

• 使用四层结构实现业务逻辑、脚本、数据分离
• 使用PO模式，将一个页面用到的元素和操作步骤封装在一个页面类中，如果一个元素定位发生了改变，我们只需要修改这个页面的元素属性
• 对于页面类的方法，尽量从客户的正向逻辑去分析，方法中是一个独立场景，例如：登录到退出，而且不能把所有的步骤都封装在一个方法中
• 测试用例设计中，减少测试用例之间的耦合度

CI/CD

频繁的将代码集成到主干，持续性的进行项目的架构，以便能够快速发现错误

是的，需要确保页面显示或接口返回数据与数据库匹配，是断言的重要内容

首先出发动态事件，然后在定位，如果是动态菜单，则需要层级定位

1. 先找该元素不变的属性，钥匙都变，那就找不变的父元素，用层级定位
2. 通过相对位置来定位，例如XPath的轴，兄弟级/父级/子级定位

不会，有时候当selenium并未加载完一个页面时再请求页面资源，则会误报不存在此元素，因此，首先应该首先考虑，selenium是否加载完此页面，其次再通过函数查找该元素

selenium是否加载完此页面：可以通过显示等待【explicit wait】来判断页面是否加载完毕

通俗来讲，把每个页面当成一个页面对象，页面层写定位元素方法和页面操作方法，可以做到定位元素与脚本分离

核心框架就是分层+PO（page object）模式

PO模式：对代码分层进行优化，代码重用性强、维护性强、可读性、稳定性

base 基类 一些公共的方法。比如：Web自动化测试中将获取浏览器驱动、定位元素、点击、截图等操作封装在base基类中

page页面对象层：一个页面封装为一个对象 例如 计算器在线计算测试中 将计算加减乘除单独封装为一个页面类、或者将登录页面单独封装为一个类

scripts层 业务层 测试用例层：调用page页面，测试层

数据层：

日志层：

• 使用selenium中Select类，调用select_by_value("XX")【重点回答】
• 也可以直接使用元素定位获取

先功能测试，再自动化测试，因此自动化测试用例从手工用例中提取

抽取主要的正向流程测试用例，进行自动化测试用例的开发和维护，提高自动化测试覆盖的内容，实现在下个版本中，自动化测试脚本可以尽可能的替代人工进行回归测试

• 不稳定
• 可靠性不强
• 不易维护
• 成本与收益
• 缺少手工测试的创造性和拓展性

webdriver不能用于做接口测试，是专门做UI自动化参数

•  元素定位方法写错了，页面上找不到该元素

• 元素定位使用的是id定位，但id是动态的id 导致找不到元素

• 元素定位表达式在页面上存在多个元素，单个元素定位方式就无法定位

• 元素在表单内部，需要switch_to切换进入表单才能够定位到元素

• 页面元素还没有加载进来，也会导致定位不到元素

• 上一步动作切换了页面，需要通过句柄switch_to切换到正确页面才能定位到元素

 

---

基准测试  负载测试  稳定性测试  压力测试   并发测试

1. 简单 容易上手，工作皎洁比较方便，而且运行稳定
2. 开源，开源的工具社区比较活跃，遇到问题也能很快找到解决方案，免费降低成本
3. 支持分布式，
4. 支持Java拓展，根据实际业务需求，编写jar包拓展脚本，提升我们测试脚本的稳定性和拓展性

1. 需求分析【确定具体的需求指标，设计性能测试场景】
2. 性能测试计划和方案
3. 性能测试用例
4. 性能测试执行：建立测试环境—》 编写测试脚本【使用工具或者脚本】——》准备测试数据—》性能测试监控—》执行测试脚本并收集测试数据
5. 性能测试分析和调优：经过分析后，如果不符合性能需求，则会提出性能Bug，然后由开发人员进行后续的调优——》回归测试【需要进行多轮，并且回归测试的数据要和之前的测试数据保持一致】
6. 性能测试报告

1.  【排除自身问题】首先检查测试机的情况，因为测试机压力过高的情况下也会影响测试结果，首先排除测试机的问题

2. 检查Web度武器上面的消息转发会不会有问题导致耗时较长

3. 检查应用服务器的资源占用情况，CPU、内存、I/O 、带宽、确定了是有某些硬件资源占用过高后，找到占用资源最高的进程，在定位具体问题

4. 检查数据库查询是否存在慢查询，互斥锁，检查是否因为数据库配置导致数据库响应时间较长

使用最多场景：登录 同时传入不同的用户名和密码【重点掌握前两种】

• 可以通过函数助手来实现参数化，比如_counter计数器函数
• 通过CSV读取文档数据实现参数化
• 通过配置元件、用户定义的变量来实现参数化
• 通过前置处理器中的用户参数也可以实现参数化

用户定义的变量：在启动运行时获取一次值，在运行过程中，不再动态获取值（不管设置多少个线程数或者循环多少次，度获取一次值，不会变）

用户参数：在启动时获取一次值，在运行过程中，每次使用该参数都会动态获取一次值

问性能测试流程

• get在url里传参，post在body里传参
• get传参有长度限制，post传参长度没有限制
• get向比较post安全低
• get请求相对于post响应更快

1.它们的用例组织方式是不一样的，像jmeter它的用例组织方式就比较扁平化，它没有测试集合和空间的一个概念，直接就是TestPlan，而postman它比较轻量级，主要是针对的是单个htp请求;

2.它们支持的接口类型以及测试类型也是有不一样的，jmeter相对来说比较强大一些，它可以支持Rest风格的接口，还有Soap【web-sever】类型的接口，以及它可以去测试接口测试功能，以及测试一个性能测试，而postman它只支持Rest风格的接口，而且也基本上做的比较多的是功能测试:

3.在流程控制上面它们也是不太一样的，比如说JMeter它是通过像Switch控制器等一系列控制器以及像beanshall脚本来实现一个流程控制的，而postman通过Javascript来进行一个流程控制:

4.它们两个在脚本结果解析和展示以及在断言还有一些功能扩展性也是有很多的区别的

---

（1）基本功能测试

• 关键词搜索：输入一个特定的关键词进行搜索，检查是否返回包含该关键词的相关结果
• 空搜索：不输入任何关键词直接搜索，检查是否有提示信息，例如“请输入搜索内容”
• 若搜索的内容不存在，检查页面是否有相应的提示如“您搜索的内容为空”
• 自动化补全功能，输入关键词的一部分，检查是否有补全功能
• 支持拼音、特殊字符搜索
• 搜索内容进行页码跳转【首页、尾页、上一页、下一页】

 （2）高级搜索功能测试

• 使用过滤器/高级搜索选项：例如使用（时间范围、类别等进行筛选），检查是否搜索成功
• 排序功能：对搜索的结果选择相关排序功能（如：最新排序等），检查搜索后的结果是否按照排序规则进行展示

（3）关闭/取消搜索 

• 打开搜索框，输入搜索内容，但点击关闭按钮、检查是否取消搜索
• 再次打开搜索框，检查上次输入的搜索内容是否清空

（4） 兼容性测试 

• 在不同的浏览器或者设备上进行搜索，检查是否搜索成功

 （5）安全性测试

• SQL注入：在搜索框中输入SQL语句，检查是否搜索成功【预期：系统阻止SQL注入】

• 数据存储:数据库，关系型数据库MySQL
• 搜索引擎：如Elasticsearch、Apache Solr，有专门为搜索优化的存储系统
• 数据索引：
• 分词器：用于文本分词
• 用户界面：前后端node、restful等

文档索引：

• 分词：将文本内容分解成单词或短语的过程，有助于搜索引擎理解和索引内容；
• 倒排索引：将每个单词映射到包含该单词的所有文档，使得搜索引擎能快速进行搜索

 查询处理：

• 进行搜索内容匹配 跟索引匹配

 相关性评分：

• 根据文档与查询的匹配程度计算每个文档的得分。
• 然后根据得分最高的展现在界面最上方

•  广告投放和管理

• 广告索引和匹配

• 广告相关计算

• 广告排序和评分

• 广告展示和点击

1. 规则的定义和管理：优惠的条件和范围
2. 优惠券的计算：根据不同规则的计算
3. 规则组合和顺序：确定那个规则优先级高
4. 边界情况和异常处理：例如没有满300不能使用优惠券，输入无效折扣，提示不能使用
5. 测试和验证：模拟各种场景，边界值法，模拟是否与预期结果一致

• 输入参数和输出参数的合法性，参数必填，默认值，参数长度和格式校验，边界值，图片长度，大小，格式等
• 如果是查询：要考虑到数据排序，分页显示
• 业务逻辑和功能实现
• 数据库校验
• 性能测试【接口的响应时间】
• 兼容性：新老版本
• 安全性:数据加密、防止恶意攻击、权限的设置
• 第一次支付成功 再次支付时提示已经支付成功等

考点：接口关联

• 接口数据关联指定是上一个接口的返回值，是下一个接口的请求参数
• 同步接口测试场景
• 携带token等：如果上一个接口返回值属于json格式，那么可以使用json提取器将需要的参数保存到变量中
• 如果是其他格式，可以使用正则提取器进行保存数据
• 使用下一个接口中${变量名}【JMeter中】就可以使用这个数据

• 接口的数量较多且复杂【手工测试的话比较容易出错，且效率低下，使用自动化框架的话可以提高效率并且不容易出错】
• 接口变更比较频繁【需求变化导致接口变化】
• 需要持续的集成和持续部署【每次代码更新都会触发自动化测试，使用jekins部署自动化测试，可以保证每次代码变更能及时的进行回归测试，从而保证软件的质量】

体现的价值：

• 提高效率，可以减少人工干预，降低成本，
• 提高测试覆盖率，通过自动化测试可以及时得到反馈，通过持续的自动化测试可以发现潜在的问题并且及时修复，保证系统的质量，减少线上故障的风险
• 提高可维护性和可复用性，当接口发生变更时，只需要更新相应的接口测试模块即可，而不需要对整个测试框架进行修改，降低了测试框架的可维护性成本
• 促进团队协作，通过开发自动化测试，测试人员可以专注于测试用例的编写，并且为整个开发团队提供统一的测试平台，方便团队成员之间沟通于协作

• 接口自动化测试：根据接口数量决定用例的个数

  200个接口，4500个左右测试用例； 100个接口，2000左右测试用例

• 覆盖率：达到99%以上

• 数据驱动测试主要结合pytest测试框架中的装饰器parametrize实现

        比如一个接口有多个测试用例，但是区别是传入的参数不一样，比如一些必填项的校验，这   个时候可以使用参数化，把框架中yaml文件的数据进行读取（自定义函数进行调用，获取符合参数化标准的数据结构）传入到测试用例中，从而实现数据和测试用例代码分离，降低代码耦合性

实习的公司使用Azure管理Bug

• 复现Bug发生的步骤，详细记录Bug发现的步骤，并且准确复现Bug
• 日志分析【通过查看系统应用日志文件 重点关注错误日志和调试日志以便了解具体错误信息和异常跟踪】
• 使用调试工具，跟踪代码执行过程，逐步的观察一些变量值和函数的调用顺序找到问题所在
• 数据分析：分析测试数据的输入，找出导致问题出现的数据边界值条件，跟新数据
• 代码审查：通过查看与问题相关的模块查找一些逻辑性错误、
• 团队合作：和开发人员进行讨论沟通，可以快速查找到问题的原因

功能性测试

1.正确性测试:测试支付流程在提供正确信息时能否顺利完成，验证支付成功后的状态更新和通知

2.异常测试：

• 模拟各种支付异常情况，如网络断开、支付超时、取消支付等，检查系统能否正确处理并给出合理反馈；
• 测试输入错误的用户信息、支付信息（如错误的金额、银行卡账户不存在等）系统的响应时间

3.退款处理：

• 测试退款功能是否正常，包括全额退款和部分退款。
• 验证退款后的状态更新和通知。

4.支付限额测试：

• 检查支付接口对单笔交易和日交易量的限额控制是否有效。

兼容性测试

1. 不同支付方式：

   测试接口是否支持微信钱包内的所有支付方式，如微信余额、银行卡、微信红包等。

2. 不同设备和操作系统：

   确保支付接口在各种设备（手机、平板、PC等）和操作系统（iOS、Android、Windows等）上均能正常工作。

3. 不同网络环境：

   测试在不同网络环境（Wi-Fi、4G、3G等）下接口的性能和稳定性。

4. 多语言和地区：

   如果服务面向国际用户，确保接口能够支持多种语言和适应不同地区的支付习惯。

性能测试

1. 并发处理能力：

   测试在高并发条件下接口的处理能力和响应时间。

2. 压力测试：

   在超过正常负载的条件下测试系统的稳定性和处理能力。

3. 稳定性测试：

   长时间运行测试，确保在连续运行的情况下接口的稳定性和可靠性。

 补充：用户体验测试

支付流程简便性：评估用户完成支付所需的步骤和时间，确保流程尽可能简便

错误提示和帮助信息：当发生错误时，是否有提示信息【例如：支付余额不足时，是否有提示：您的余额不足】

1. 安装Docker【目前只使用到Windows桌面版】
2. 创建DockerFile：包含一系列指令，用于定义如何构建Docker镜像，【项目所需要的环境和依赖】
3. 构建Docker镜像【docker build】
4. 运行Docker容器【docker run】
5. 配置Docker compose 将多个环境集成到一起 然后运行
6. 持续集成，以便实时更新拉取【公司代码都集成在私有仓库 gitlab上】——需要构建yaml文件（包含Docker命令）——自动化构建

质量保证（Quality Assurance，QA）是指一系列过程、活动和管理技术，旨在确保产品或服务满足特定质量标准和满足用户需求。它是软件开发、制造和各种服务领域中的一个关键组成部分，旨在系统性地防止缺陷，提高产品质量，并确保产品能够可靠、有效地执行其预期功能。质量保证不仅仅关注最终产品的质量，更重要的是关注改进和优化制造或开发过程的质量，以减少或消除缺陷的产生。

1.检查系统是否有中毒的特征；

2.软硬件性能监控：在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况

3.如果是B/s或C/S架构，可以检查是否因为服务器的连接有问题，或者访问有问题造成的

4.在不同的环境或操作系统上运行该程序，若在其他操作系统运行环境良好，但在当前系统上运行缓慢，可能是跟软硬件有关

兼容性测试旨在评估软件、应用程序或网站在不同环境下的运行能力

1. 操作系统兼容性

测试软件在不同操作系统上的运行情况，如Windows、macOS、Linux、各种移动操作系统（如Android和iOS）等。这包括不同版本的操作系统以及各种操作系统的更新或补丁

2. 浏览器兼容性

特别针对网站和Web应用程序，测试在不同的Web浏览器上的表现，包括Chrome、Firefox、Safari、Edge、Internet Explorer等，以及这些浏览器的不同版本。

3. 设备兼容性

对于移动应用或响应式网站，测试在不同设备上的表现，包括各种智能手机、平板电脑、笔记本电脑和桌面电脑等，涵盖不同的屏幕尺寸和分辨率。

4. 网络兼容性

评估软件在不同网络环境下的性能，包括不同的网络速度（如4G、5G、Wi-Fi）以及不同的网络供应商。

5. 分辨率兼容性

对于图形界面的应用程序，测试在不同的显示分辨率和方向（横屏/竖屏）下的用户界面布局和元素显示。

6. 国际化和本地化

对于面向多语言和多文化用户的软件，测试软件在不同语言和地区设置下的表现，确保文本、格式（如日期、时间、货币）和内容适当地适应目标市场。

7. 硬件兼容性

验证软件在不同硬件配置下的表现，包括CPU、内存、存储、显卡等。

1. 网络连接问题

• 慢速或不稳定的网络连接：如果你的网络连接速度慢或者不稳定，视频可能会需要更长的时间来缓冲。
• 网络拥堵：在网络高峰时段，大量的数据传输可能导致网络拥堵，影响视频加载速度。
• 网络配置问题：错误的网络设置或配置也可能导致加载问题。

2. 服务器端问题

• 抖音服务器故障：如果抖音的服务器出现问题或正在进行维护，可能会影响视频的加载。
• 服务器带宽限制：服务器的带宽限制也可能导致视频加载缓慢。

3. 设备性能问题

• 设备性能不足：如果你的设备性能（如处理器速度、内存）不足以流畅播放视频，可能会导致加载缓慢。
• 存储空间不足：设备上的可用存储空间不足可能影响应用程序的性能，包括视频加载。

4. 应用程序问题

• 应用程序缓存：应用程序缓存过多或数据损坏可能会导致加载问题。
• 应用程序版本过旧：使用过时的抖音应用程序版本可能导致兼容性问题，影响视频加载。

5. 视频格式或编码问题

• 视频编码问题：特定的视频格式或编码可能不被设备或应用程序完全支持，导致加载失败。
• 视频质量过高：如果视频质量过高（如4K视频），而网络带宽或设备性能无法满足需求，也可能导致加载缓慢。

解决方法

• 检查网络连接并尝试切换到更快或更稳定的网络。
• 重启路由器和设备，以排除临时的网络或设备问题。
• 清除抖音应用的缓存或数据，并尝试重新启动应用。
• 更新抖音应用到最新版本。
• 如果可能，降低视频的播放质量设置。
• 检查设备存储空间，必要时清理空间

针对点赞功能的测试用例设计应覆盖各种用户行为、系统响应和边界条件。以下是一些关键的测试用例：

1. 基本功能测试

• 点赞：验证用户可以成功为内容（如帖子、评论、图片等）点赞。
• 取消点赞：验证用户可以取消已点赞的内容。
• 点赞计数：验证点赞后，相关内容的点赞计数正确增加；取消点赞后，点赞计数正确减少。

2. 用户状态测试

• 登录用户：确保登录用户能够点赞和取消点赞。
• 未登录用户：验证未登录用户点击点赞时，系统是否提示登录或禁止操作。
• 用户权限：测试不同权限的用户（如普通用户、管理员）对点赞功能的访问权限。

3. 数据一致性和持久性

• 数据持久性：确认点赞操作后，即使页面刷新或重新登录，点赞状态和计数仍然保持正确。
• 多设备同步：验证用户在一个设备上的点赞操作能够在其他设备上实时反映。

4. 界面和交互

• 点赞图标状态：验证点赞和取消点赞操作后，点赞图标的显示状态（如颜色、形状变化）是否正确。
• 点赞反馈：测试点赞操作是否有适当的用户反馈（如动画、提示信息）。

5. 性能和压力测试

• 响应时间：测试点赞和取消点赞操作的响应时间，确保在正常和高负载下都能快速响应。
• 高并发测试：模拟多用户同时对同一内容点赞，确保系统稳定性和点赞计数的准确性。

6. 异常和边界条件测试

• 重复点赞：测试用户对同一内容重复点赞的情况，确保点赞计数不会错误增加。
• 快速连续操作：模拟用户快速连续进行点赞和取消点赞操作，检查系统处理逻辑和数据一致性。
• 网络异常：模拟网络延迟或中断的情况，测试点赞操作的容错处理和用户提示。

7. 安全性测试

• 操作验证：确保点赞操作是由用户本人发起，防止CSRF等攻击。
• 数据篡改：测试系统是否能防止恶意用户通过篡改请求来点赞未授权的内容。

8. 兼容性测试

• 不同浏览器和设备：测试点赞功能在不同浏览器（如Chrome、Firefox、Safari等）和不同设备（如PC、手机、平板）上的表现。

功能性测试

1. 秒杀开启和结束：

   • 测试秒杀活动在预定时间准确开启和结束。
   • 验证活动结束后用户无法进行秒杀操作。

2. 商品库存：

   • 测试系统能够正确处理商品库存，确保不会超卖。
   • 当库存为0时，验证系统能够立即停止秒杀操作。

3. 用户下单：

   • 测试用户能够在秒杀活动期间成功下单。
   • 验证系统对每个用户的下单数量进行限制。

4. 订单处理：

   • 测试系统能够快速生成订单，并保证订单数据的准确性。
   • 检查在高并发情况下订单处理的稳定性。

性能测试

1. 并发用户：

   • 模拟大量用户同时访问秒杀页面，测试系统的承载能力。
   • 验证系统能否在高并发压力下正常响应用户请求。

2. 响应时间：

   • 测试在高并发场景下系统响应时间，确保在可接受范围内。

3. 资源消耗：

   • 监控系统在高并发下的CPU、内存和网络资源消耗情况。

异常和边界条件测试

1. 网络延迟和中断：

   • 模拟网络延迟和中断情况，测试用户操作的容错性。

2. 重复请求：

   • 测试系统如何处理同一用户的重复秒杀请求。

3. 秒杀前后：

   • 验证在秒杀刚开始和即将结束时的系统表现。

安全性测试

1. 恶意攻击：

   • 测试系统能否抵御SQL注入、DDoS攻击等网络攻击。

2. 身份验证：

   • 验证系统是否有效验证用户身份，防止未授权用户参与秒杀。

3. 机器人和脚本：

   • 测试系统能否识别和防止自动化脚本参与秒杀，保证活动的公平性。

用户体验测试

1. 页面加载速度：

   • 测试在高并发访问下，秒杀页面的加载速度。

2. 操作反馈：

   • 验证用户操作（如点击秒杀按钮）后的即时反馈，如提示信息的准确性和可见性。

3. 失败处理：

   • 测试在秒杀失败（如库存不足、活动结束）时，用户得到的提示信息和引导操作。

功能性测试

1. 满减条件测试：

   • 测试订单金额达到满减条件时，是否正确应用满减优惠。
   • 测试订单金额未达到满减条件时，满减优惠不应被应用。

2. 多重满减规则：

   • 对于多个满减规则并存的情况（如“满100减10，满200减30”），测试系统是否能正确识别并应用最优惠的满减规则。

3. 特定商品满减：

   • 验证只有特定商品或分类参与满减时，满减优惠是否只针对这些商品计算。

4. 满减与其他优惠共用：

   • 测试满减优惠是否可以与其他优惠（如优惠券、折扣）叠加使用，以及如何叠加的规则。

5. 满减优惠上限：

   • 验证满减优惠是否有最大优惠额度的限制，以及该限制是否正确执行。

异常和边界条件测试

1. 边界值测试：

   • 测试订单金额刚好等于满减条件的边界值时，满减优惠是否被正确触发。
   • 测试订单金额刚好超过和刚好未达到满减条件的边界值，检查满减优惠的应用情况。

2. 无效和过期的满减：

   • 测试当满减优惠无效或已过期时，系统是否能正确识别并防止应用这些优惠。

3. 取消订单和退款：

   • 测试在应用了满减优惠的订单被取消或部分退款后，满减优惠的处理方式（如是否退还、如何退还）。

性能测试

1. 响应时间：

   • 测试在应用满减规则时，系统计算优惠和更新订单总额的响应时间。

2. 高并发测试：

   • 模拟高峰时段多用户同时下单并触发满减优惠的场景，测试系统的性能和稳定性。

用户体验测试

1. 界面显示：

   • 测试满减优惠的规则、适用条件等信息是否在用户下单界面清晰显示。
   • 测试订单总额更新后，满减优惠的金额是否在订单详情中明确展示。

2. 提示和引导：

   • 测试当用户的订单金额接近满减条件时，是否有提示或引导帮助用户获得优惠。

安全性测试

1. 滥用和欺诈：
   • 测试系统是否有机制防止用户通过分拆订单、重复使用优惠等方式滥用满减优惠。

---

确保一个类只有一个实例，而且自行实例化并向整个系统提供这个实例

作用：确保一个雷只有一个实例存在（Web页面的计数器），减少资源的消耗

1.DNS对域名进行解析； 2.建立TCP连接（三次握手）； 3.发送HTTP请求； 4.服务器处理请求； 5.返回响应结果； 6.关闭TCP连接（四次挥手）； 7.浏览器解析HTML； 8.浏览器布局渲染；

DNS域名解析：

将域名解析为IP地址【例如将baidu.com 解析为IP地址】，域名比较便于记忆

权威域名服务器【域名对应的IP地址】

顶级域名服务器【com   cn   edu  等属于顶级域名服务器】

根域名服务器

1. 首先先会在自己浏览器检查是否有该域名的IP地址，若有，直接使用；
2. 若没有，DNS向本地的域名服务器询问对应的IP地址是多少，若缓存记录有，直接使用
3. 若没有，向根域名服务器发送请求，询问顶级域名服务器地址是多少
4. 本地域名服务器按照地址找到顶级域名服务器，然后问到权威域名服务器地址
5. 本地根据地址找到权威服务器，找到IP地址【存放在缓存中方便下次使用】，然后返回给主机

1. 都是http请求方式
2. get从服务器上获取数据，post向服务器传送数据
3. get请求的参数是放在url里面的，post请求参数是放在请求体里的
4. get请求是可以被浏览器缓存的，post请求不能被缓存，每次请求都会想服务器发送完整的数据【存疑】
5. get请求参数受限【2048个字符】，post请求参数没有限制
6. get请求安全性较差，因为数据参数在url中，post安全性较好’
7. get请求可以直接通过浏览器访问，支持刷新和后退；post请求不能直接使用浏览器访问，刷新后数据要重新发送

HTTP（Hypertext Transfer Protocol）中的状态码是服务器向客户端返回的响应的一部分，用于表示服务器对请求的处理结果

1.性质不同

（1）final为关键字;

（2）finalize()为方法;

（3）finally为为区块标志,用于try语句中;

2. 作用

（1）final为用于标识常量的关键字,final标识的关键字存储在常量池中

         被final修饰的类不能被继承；修饰的方法不能被重写；修饰的变量不能被改变

（2）finalize()方法在Object中进行了定义,用于在对象“消失”时,由JVM进行调用用于对对象 进行垃圾回收;

    以上就是本篇文章【软件测试面试题整理】的全部内容了，欢迎阅览 ！ 文章地址：http://yy520w.xhstdz.com/news/845.html 
     资讯      企业新闻      行情      企业黄页      同类资讯      首页      网站地图      返回首页 物流网资讯 http://gzhdwind.xhstdz.com/ , 查看更多