【2022秋招面经】——测试

概念

测试的流程

一、评审阶段

1.1 需求的评审

一般在需求的评审阶段中，参与者至少会有产品经理、开发、测试。对测试而言，在需求评审中，最需要做两件事情。

• 理解需求：在需求评审阶段就搞懂需求是什么。
• 提出疑问：因为产品的需求也不一定合理，我们要带着怀疑的态度参与到需求的评审当中。对于新人来说，参与需求评审也是一个熟悉业务的好机会。

需求评审阶段，我们需要关注以下相关问题。

• 交付目标：改需求面向的人群是谁？是外部用户、供应商？还是公司内部商务、运营、客服使用。
• 交付计划：需求的上线计划，验收计划，是否灰度，以及测试工作量的评估。
• 业务流程：本次是新增的功能或流程，还是原来业务上新增的节点或者逻辑。

补充知识，灰度：
所谓“灰度测试”，就是在某项产品或应用正式发布前，选择特定人群试用，逐步扩大其使用者的数量，以便机试发现和纠正其中的问题。

灰度测试步骤：

1. 定义目标，对什么产品进行灰度
2. 选定策略：用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
3. 筛选用户：用户特征、用户数量、用户常用功能、用户范围等
4. 部署系统：部署新系统、部署用户行为分析系统、设定分流规则、运营数据分析、分流规则微调
5. 发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表
6. 产品完善
7. 新一轮灰度发布或完整发布

1.2 设计评审

设计评审：开发人员在听完需求评审后，先编好开发设计文档，根据项目的大小是否需要进行设计评审，对于比较大的项目，会和产品、测试进行设计的评审。作为测试而言，设计参与评审一是为了加深需求的理解，二是理解开发的设计，也要注意开发的设计是否合理。

在设计评审中，测试一般需要关注以下相关的问题(不一定全面，可能会存在相关差异)。

• 流程设计图：开发设计的流程图是否能达到产品需求的流程？
• 数据库表设计：是否新增表？是否需要分库分表？如何保证唯一性？表字段默认值？是否需要添加索引？
• 接口：接口层面分为本系统和上下游系统。本系统：新增接口的调用方是谁？原有接口修改后是否影响上下游业务？上下游系统：调用其他系统接口或者被其他系统调用的接口，是否有对接？需要评估是否对接口负载有影响？一般核心域的核心接口，在有新增入参的情况下，也会根据线上情况进行不同入参下的性能测试，评估接口QPS是否能达到预期，防止上线后出现性能问题。
• 组件变更：是否有配置变更，配置的默认值是否合理？是否有环境变量变更？相关组件是否有变更？
• 灰度：是否有开关？灰度方案是什么？是根据用户灰度还是？
• 回滚：如果出现问题，回滚方案是什么？回滚时相关域的回滚顺序是怎么样的？

1.3 用例评审

1.3.1 功能用例评审

功能用例评审：测试人员在编写好用例后，可以通过邮件的形式将发送给对应开发和产品，查看用例场景是否有遗漏。一般开发和产品不怎么看这个邮件的话，就可以抽了十多分钟，拉上会议，进行一个当面的用例评审。

如果是新入职的新人，一般是编写好用例后，先发送邮件给产品、开发，抄送给本组的测试同事，然后再拉上产品、开发进行一个当面的沟通。

1.3.2 联调用例评审

联调用例评审：如果需求涉及到多个系统的话，一般是需要进行一个联调用例评审。评审前一般是会先确定好本次需求的主测试，然后主测会编写好联调文档。

联调用例评审会上会有以下几件事需要做：

宣讲用例：主测宣讲联调的用例，各系统的测试查看是否有场景遗漏，并进行补充。
确定分工：相关基础数据的准备交给对应系统。确定是否有本次需求系统无需变更，但是要协助联调的系统，确定跟进人。
问题记录：对于联调评审中无法确定的问题，进行记录，后续跟进解决。

二、测试阶段

2.1 冒烟测试

冒烟测试：在开发提测后，就进入测试阶段。首先进行冒烟测试，冒烟测试一般需要注意相关问题：

• 静态代码扫描：进行静态代码扫描，是否有blocker、critical的代码。
• 代码编译 & 服务部署：测试分支进行开发代码编译和部署，查看是否能编译和部署成功。且部署成功后，一般会查看环境中服务的日志，查看有无明显的报错日志。
• 冒烟测试用例：首先执行冒烟的自动化Case,然后根据自己设计的冒烟阶段的用例，执行用例并测试。

关于静态代码扫描、代码编译等，需要看所在公司对于相关测试平台的建设。例如我现在所在的公司，就是可以创建一个流水线，其中可以配置下面这些功能：代码编译、单元测试、单元测试覆盖率、静态代码检查、项目打包，镜像烘焙、部署、系统测试(自动化代码执行)。所以一般开发提测后，就是执行一下对应的流水线，查看代码是否能编译通过，静态代码扫描是否有问题，原先的自动化Case中的冒烟Case是否能通过等。

在冒烟测试过程中，我们需要有以下记录：

• 用例上传及执行：上传冒烟测试用例，并在执行用例后，记录为用例已执行。
• BUG记录：如果冒烟Case不通过，提冒烟Bug给开发。
• 工时记录：记录冒烟测试阶段的使用工时。
• 补充冒烟自动化Case：如果是接口域，根据情况看是否需要补充冒烟的自动化AT，有则补充自动化AT，分组设置为冒烟。

2.2 功能测试

功能测试：在冒烟测试通过后，进行到功能测试。功能测试与冒烟测试的不同在于，冒烟测试只是先将主流程走了一遍，而功能测试需要考虑常规情况和异常情况下的所有情况。在功能测试阶段需要注意以下问题：

• 前置准备：准备好基础的测试数据，相关变更需要在测试环境中执行等。

• 用例执行：根据用例设计执行功能测试部分的用例。一般而言，在功能测试阶段，需要调用外部系统服务的话，采用Mock的方式，Mock外部系统的返回，除去Mock外部系统的正常返回，还要Mock超时，抛出异常等异常情况。

• 预期结果：测试用例执行的结果是否符合预期结果。

• 前置准备：准备好基础的测试数据，相关变更需要在测试环境中执行等。

• 用例执行：根据用例设计执行功能测试部分的用例。一般而言，在功能测试阶段，需要调用外部系统服务的话，采用Mock的方式，Mock外部系统的返回，除去Mock外部系统的正常返回，还要Mock超时，抛出异常等异常情况。

• 预期结果：测试用例执行的结果是否符合预期结果。

在功能测试过程中，我们需要有以下记录：

• 用例上传及执行：上传功能测试用例，并在执行用例后，记录为用例已执行。
• BUG记录：如果功能Case不通过，提功能测试阶段Bug给开发。
• 工时记录：记录功能测试阶段的使用工时。
• 补充自动化Case：补充本次需求的自动化Case。
• 功能测试报告：发送功能测试报告，内容包括是否通过？遗留问题及风险点。

2.3 联调测试

联调测试：一般只有当需求涉及到多个系统的变更的时候，才需要进行联调测试。而联调测试一般就是各系统将各自的服务部署再Staging联调环境中后，模拟生产一样，按照联调用例走一趟实际的流程。

在联调测试中，需要关注以下的点：

• 真实数据：联调的数据要是真实的数据，一定不能Mock数据！！！。而且不要直接修改数据库、Redis中的数据
• 核心流程回归：对于原有的核心的流程，也要做到一定程度的回归，防止对原有流程有影响。
• 联调日报：主测需要通过邮件的形式汇报整体联调的进度，以及联调进度的风险、联调发现的问题等。

2.4 回归测试

回归测试：在测试分支进行完功能测试后，在发布上线前，开发合并代码到dev、master分支后，分别进行一次回归测试。回归测试一般需要注意相关问题：

• 回归时间：一般而言，当有一个域需要在明天发布，会在确定今天这个域没有发布、或这个域今天需要发布上线的需要已经上线后，才让开发合并代码到dev分支或者master分支，待合并代码后再进行回归。
• 静态代码扫描：代码依次合并到dev、master分支后，进行静态代码扫描，确保没有blocker、critical。
• SDK升级：本域服务和依赖的外部服务需要升级为正式版，不使用SNAPSHOT版。
• 全量AT回归：针对接口域，会进行全量接口自动化AT的回归，确保自动化Case没有失败的情况下才会进行下一步。

在回归测试过程中，我们需要有以下记录：

• 用例上传及执行：上传回归测试用例，并在执行用例后，记录为用例已执行。
• BUG记录：如果回归时Case不通过，提回归测试阶段Bug给开发。
• 工时记录：记录回归测试阶段的使用工时。

三、发布上线（预发布->生产）

预发布环境连接的是真实生产的数据库，所以回归测试完成后，一般会先发布到预发布环境。待开发、产品验收无问题后，才会发布到生产环境。在这个过程中，需要注意以下几方面。

• 依赖变更：确定相关组件、配置、环境变量是否做了变更。在很多情况下，有些DB变更需要提前做，因为可能有的DB变更需要长达几个小时，如果等到要发布的时候，才想到要变更，可能今天就发布不了了。
• 验收：一般而言，是先发布到预发布环境，待产品、开发验收无问题，才会进行生产发布。如果有问题，重新修改代码再推预发布再验收。生产发布完成后，产品也需要再进行一遍验收。
• 发布顺序：检查发布域的版本号是否为正式版，且要按照顺序发布。发布系统可以做到模块关联，设置某一个域发布完成之后，另一个域才能发布。
  发布时间间隔：根据域的重要性不同，生产服务器机器数量也不同，所以发布的时候会设置批次。而每个批次的发布之间，最好进行一定时间的间隔。
• 日志监控：在生产发布的过程中，需要通过日志系统查看有无异常日志，如果出现预期外的异常日志，需要和开发沟通后判断是否需要回滚。
• 告警监控：通过发布系统查看是否有本域告警和上下游告警，如果有，也需要找开发确认是否有影响，再决定是否回滚。
• 回滚：如果出现核心流程的告警，或者不能确定的告警和异常情况下，一般会先直接进行回滚操作。需要注意的是，需要注意回滚的顺序。如果由于回滚前，造成相关异常数据，在回滚后，还需要进行异常数据的处理。

参考链接：https://blog.csdn.net/qq_37688023/article/details/115047532

测试用例怎么编写，用例包括哪几部分的内容

编写测试用例的方向主要从以下三个部分展开：

1. 常规思考：
   罗列功能点，对每一项功能都做以下正常验证和异常验证。

2. 理论角度：
   从测试理论角度来思考设计测试用例，熟知的测试用例设计方法有：

• 观察法
• 等价类、边界值
• 判定表、因果图
• 流程图、场景法
• 错误推导法等

3. 经验积累：
   不断学习、熟悉产品、积累常见的测试用例，例如在一个登录的测试中，需要记住常用的测试用例。
   

测试用例（格式）一般会包括：
用例编号、测试项、测试标题、用例属性、重要级别、预置条件、测试输入、操作步骤、预期结果、实际结果

bug记录

bug标题、详细描述(含步骤)、项目模块、严重程度、优先级、bug类型、bug状态、提交人、提交日期、附加信息、解决人、解决日期、解决方式、解决用时。

bug的严重程度分为：

1. Blocker（有妨碍的）: 即系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。
2. Critical（紧要的）：即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
3. Major（严重的）：即界面、性能缺陷、兼容性。
4. Minor/Trivial（次要的/不严重的）:即易用性及建议性问题。

优先级划分：
1.Immediate（立刻）
2. Urgent（紧要、优先）
3. High（高度重视）
4. Normal（正常）
5. Low（稍缓）

测试方法和分类

一、从是否关心软件内部结构和具体实现的角度划分

1. 白盒测试，关注结构
2. 黑盒测试，关注功能
3. 灰盒测试

①白盒测试：

• 白盒测试是能够清楚的了解程序结构和处理过程，检查所有的结构及路径是否都是正确的。
• 白盒测试方法有：代码检查法、路径覆盖、逻辑覆盖和条件覆盖等方法。

②黑盒测试：

• 看不到程序内部结构的测试，只能通过检查判断是否按需求说明的正常实现了。
• 黑盒测试方法有：等价类划分法（有效等价类、无效等价类）、边界值分析法、错误推测法、因果图法等。

二、从事构执行程序的角度

1. 静态测试
2. 动态测试

三、从软件开发的过程

1. 单元测试
2. 集成测试
3. 确认测试
4. 系统测试
5. 验收测试

非功能性测试方法有哪些

1. 安全性：
   测试系统遭受内部和外部来源的攻击，是否能正常运行。

杯子有没有毒或细菌。

2. 可靠性：
   在没有故障的情况下连续执行指定功能的程度。

纸杯用了很多次，都不会坏。

3. 易用性：
   用户通过与系统的交互可以轻松学习，操作，准备输入和输出。

纸杯用法是否简单，步骤是否难懂。

4. 兼容性：
   在不同的环境中，是否还可用。

纸杯在夏天和冬天是不是可用。

5. 效率：
   可以处理的容量，数量和相应时间的程度。

纸杯一次能装多少水。

6. 压力测试：
   能处理请求的 数量/容量/并发数 极限，引发系统软件的奔溃。

给纸杯不断加压，看达到多少压力，纸杯会穿透。

回归测试

回归测试就是把之前测试过的用例，再重新测一遍，主要分为两类：用例回归、错误回归。

1. 用例回归：过一段时间以后再回头对以前使用的用例再重新进行测试。
2. 错误回归：在新版本中，对以前版本中出现并修复的缺陷进行再次验证，并以缺陷为核心，对相关修改的部分进行测试。

性能测试指标

包括资源指标、系统指标。

1. 资源指标有：CPU、内存、IO、带宽、吞吐量；
2. 系统指标：并发用户数、相应时间、事务成功率、超时错误率。

自动化测试缺陷

1. 一旦项目发生变化，测试用例就需要改进，工作量大
2. 验证的范围有限，操作更加复杂，比如说简单的一个验证验证码，如果是人工识别很快就可以输入，但是自动化测试中会增添很多困难。那么这个时候速度也不如人工。
3. 不稳定。
4. 可靠性不强。
5. 成本与收益。

自动化测试的时候是不是需要连接数据库做数据校验

1. UI自动化不需要
2. 接口测试会需要

敏捷测试

敏捷测试是测试的一种。

遵循的原则有：

1. 强调从用户的角度出发，从用户的角度来测试系统；
2. 重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段；
3. 尽早开始而此时，一旦系统某个层面可测，就尽快开始模块层面的单元测试，同时随着测试的深入，持续进行回归测试保证之前测试过内容的正确性。

敏捷测试和普通测试的区别：

1. 开发与测试并行，项目整体时间较快
2. 传统测试强调计划性；敏捷测试强调测试的速度和适应性，不断调整以适应需求的变化。
3. 传统测试强调阶段性、流程规范性；敏捷测试强调持续的测试、持续的质量反馈，模糊了阶段性。

持续集成

持续集成的概念是指，频繁的将代码集成到主干。

它的好处主要有两个：

1. 快速发现错误，每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
2. 防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。

持续集成的目的，就是让产品快速迭代，同时提高质量。核心举措是，代码集成到主干之前，必须通过自动话测试，只要有一个测试用例失败，就不能集成。

其他持续的知识补充

持续交付
频繁的更新软件版本，交付给质量审核团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。
持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。

持续部署
持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。
持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。

如何保证测试开发的质量

1. 充分理解需求，并将需求转换成测试点，测试点评审无误之后，转换成测试用例，尽量提高测试用例场景覆盖度
2. 测试过程遵循实事求是原则，严格按测试用例执行，除测试用例之外，还需要进行随机测试
3. 同时严格遵循测试准入准出条件，当bug修复率达到一定程度时才允许入库和上线

怎样才是一个好的测试用例

必须具备以下三个特征

1. 整体完备性：
   是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。

2. 等价类划分的准确性：
   指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。

3. 等价类集合的完备性：
   需要保证所有可能的边界值和边界条件都已经正确识别。

场景题

测试从哪几方面考虑

0. 功能性：

   • 罗列功能，对每个功能点进行黑盒或者白盒测试。

1. 安全性：
   测试系统遭受内部和外部来源的攻击，是否能正常运行。

   • sql 注入
   • XSS 攻击

2. 可靠性：
   在没有故障的情况下连续执行指定功能的程度。

3. 易用性：
   用户通过与系统的交互可以轻松学习，操作，准备输入和输出。

   • 快捷键

4. 兼容性：
   在不同的环境中，是否还可用。

   • 不同操作系统，IOS、安卓还是Windows、Linux

5. 效率：
   可以处理的容量，数量和相应时间的程度。

   • 运行速度

6. 压力测试：
   能处理请求的 数量/容量/并发数 极限，引发系统软件的奔溃。

   • 最大并发量
   • 在最大压力下的运行速度

公司内一直在使用的测试系统（B/S架构）突然不能访问了，需要你进行排查并恢复，说出你的检查方法？

1. 检查网址是否有误，如果网络地址无误，换一个网站访问一下，看看是不是自己的网站出了问题。

2. 检查是不是“防火墙”程序出错、错误的代理设置导致无法上网？暂时关闭电脑的防火墙，取消一切代理，再试一下网络是否恢复；

3. 在 cmd 中使用 ipconfig ，查看 ip地址、子网掩码、默认网关地址。

4. ping 本机回环 127.0.0.1，如果ping不通，那么是自己电脑的 TCP/IP 协议出错，需要重新安装。ping 本机ip，ping不通，则网卡出现问题。ping 服务器ip，ping不通则检查服务器。

5. 测试FTP是否正常可以登录，不能登录的直接问空间商那是空间商的问题直接联系他们。

6. 空间赠送的三级域名是否能够访问网站打开网站（空间都赠送三级域名），如果也不能访问应该是空间问题。

7. 在cmd中 ping 自己的域名，如果看不到IP或IP地址与你的主机地址不符，则说明域名解析有误,是域名的问题得重新解析域名。

测试中发现一个Bug, 但是开发认为这不是一个bug，你应该怎么解决？

先将问题提交到缺陷管理库里面进行备案。然后获取判断的依据和标准：

1. 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
2. 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
3. 根据用户的一般使用习惯，来确认是否是缺陷；
4. 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；

合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。

设计一个登录的测试用例

• 功能测试：正确输入、为空输入、字符类型校验、长度校验、密码是否加密显示、大写提示、跳转页面是否成功、登出后用另一个账号登录
• UI：界面布局合理、风格统一、界面文字简洁好理解、没有错别字
• 性能测试：打开登录页面需要几秒、点击登录跳转首页需要几秒、多次点击、多人点击
• 安全性：用户名和密码是否加密发送给服务器、错误登录的次数限制（防止暴力破解）、一台机器登录多个用户、一个用户多方登录、检查元素能否看到密码
• 兼容性测试：不同浏览器、不同的平台（Windows、Mac）、移动设备能否工作
• 易用性：输入框可否tab键切换、回车能否登录等

App兼容性怎么测，App的接口测试怎么测

• 系统兼容（ios，安卓）、机型兼容（iphtone、华为、小米、三星、vivo、oppo）、分辨率兼容、软件本身向前向后兼容。
• 接口测试：获取接口文档，使用fiddler抓包工具获取接口的请求方式、url、请求参数、返回参数、然后使用postman、jmeter进行测试。

Web 端测试和 App 端测试有何不同

• 系统结构方面

  • Web 项目，b/s结构，基于浏览器的；web测试只要更新了服务端，客户端就会同步更新；
  • App项目，c/s结构，必须要有客户端；App修改了服务端，则客户端用户所有核心版本都需要进行回归测试一遍。

• 兼容方面

  • Web项目：a. 浏览器（火狐、谷歌、IE等）b. 操作系统（Windows7、Windows10、Linux等）
  • App项目：a. 设备系统: iOS（ipad、iphone）、Android（三星、华为、联想等） 、Windows（Win7、Win8）、OSX（Mac）b. 手机设备可根据 手机型号、分辨率不同

• 性能方面

  • web项目 需监测 响应时间、CPU、Memory
  • app项目 除了监测 响应时间、CPU、Memory外，还需监测流量、电量等

• 相对于 Wed 项目，APP有专项测试

  • 干扰测试：中断，来电，短信，关机，重启等
  • 弱网络测试（模拟2g、3g、4g，wifi网络状态以及丢包情况）；网络切换测试（网络断开后重连、3g切换到4g/wifi 等）
  • 安装、更新、卸载
    • 安装：需考虑安装时的中断、弱网、安装后删除安装文件等情况
    • 卸载：需考虑 卸载后是否删除 App 相关的文件
    • 更新：分强制更新、非强制更新、增量包更新、断点续传、弱网状态下更新
    • 界面操作：关于手机端测试，需注意手势，横竖屏切换，多点触控，前后台切换
    • 安全测试：安装包是否可反编译代码、安装包是否签名、权限设置，例如访问通讯录等
    • 边界测试：可用存储空间少、没有SD卡/双SD卡、飞行模式、系统时间有误、第三方依赖（QQ、微信登录）等
    • 权限测试：设置某个 App 是否可以获取该权限，例如是否可访问通讯录、相册、照相机等

给你一个网站，你如何测试？

1. 首先，查找需求说明、网站设计等相关文档，分析测试需求

制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试

2. 设计测试用例

功能性测试包括：

• 链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。
• 提交功能的测试。
• 多媒体元素是否可以正确加载和显示。
• 多语言支持是否能够正确显示选择的语言等。

界面测试包括：

• 页面是否风格统一，美观
• 页面布局是否合理，重点内容和热点内容是否突出
• 控件是否正常使用
• 对于必须但未安装的控件，是否提供自动下载并安装的功能
• 文字检查

性能测试包括：

• 压力测试；负载测试；强度测试

数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。

• 安全性测试：

基本的登录功能的检查
是否存在溢出错误，导致系统崩溃或者权限泄露
相关开发语言的常见安全性问题检查，例如SQL注入等
如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持

• 兼容性测试：

• 浏览器的兼容性

• 操作系统的兼容性

• 软件平台的兼容性

• 数据库的兼容性

3. 记录测试结果并评审

开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。

定期评审，对测试进行评估和总结，调整测试的内容。

怎么测试一个水杯？

1. 安全性：
   测试系统遭受内部和外部来源的攻击，是否能正常运行。

杯子有没有毒或细菌。

2. 可靠性：
   在没有故障的情况下连续执行指定功能的程度。

纸杯用了很多次，都不会坏。

3. 易用性：
   用户通过与系统的交互可以轻松学习，操作，准备输入和输出。

纸杯用法是否简单，步骤是否难懂。

4. 兼容性：
   在不同的环境中，是否还可用。

纸杯在夏天和冬天是不是可用。

5. 效率：
   可以处理的容量，数量和相应时间的程度。

纸杯一次能装多少水。

6. 压力测试：
   能处理请求的 数量/容量/并发数 极限，引发系统软件的奔溃。

给纸杯不断加压，看达到多少压力，纸杯会穿透。

有验证码的功能，怎么做性能测试

1. 将验证码暂时屏蔽，完成性能测试后，再恢复
2. 使用万能的验证码
3. 使用脚本进行解析

微信发红包的测试用例

功能测试

1. 红包最多可以输入的金额；
2. 红包一次性可以发送的最大个数；
3. 在输入红包的钱数和个数时只能输入数字；
4. 当余额不足时，红包发送失败；
5. 发送的红包自己是否可以领取；
6. 发送的红包别人是否可以领取；
7. 红包超过24小时是否可以领取；
8. 红包超时未领取，是否退回原账户；
9. 是否可以自己选择支付方式；
10. 红包描述可以输入的最大字符；
11. 余额不足时，是否可以切换支付方式；

UI界面测试

1. 输入界面是否清晰可见；
2. 红包界面颜色搭配是否美观；
3. 输入金额界面是否有错别字；

性能测试

1. 发红包成功后的跳转时间；
2. 红包超时未领取后的退款时间；
3. 网速较差时，发红包的时间；

安全测试

1. 红包发送成功后，微信是否会收到通知；
2. 红包发送失败，余额不会产生变化；

弱网测试

1. 弱网下是否可以发送红包；
2. 弱网下发送红包的时间；

易用性测试

1. 是否可以选择默认支付方式；
2. 余额不足时，是否可以切换支付方式；
3. 是否支持密码支付和指纹支付；

对登录功能进行测试用例的编写

一、了解需求
1、登录界面是弹窗式的，还是直接卸载网页里面的？
2、账号长度和密码强度？（多少位、大小写敏感、特殊字符混搭等）
3、界面美观是否右要求？（即是否要进行UI测试）…
4、应用在手机上测试还是在电脑上

二、设计测试用例
功能性测试：

1. 输入正确的账号密码，点击提交，验证是否能正确通过（正确输入）
2. 输入错误的账号或者密码，验证登录是否会失败，并且提示响应的错误信息（错误校验）
3. 登录成功后能否跳转到正确的页面
4. 账号密码中有特殊字符（空格），是否做了过滤
5. 记住账号的功能
6. 登录失败之后，不能记住密码
7. 密码是否加密显示
8. 验证码辨识难度问题，考虑色盲使用者，刷新和换一个按钮是否可用
9. 注册、忘记密码、登出按钮是否正确跳转页面
10. 输入密码大写提示
11. 密码非空检查

界面测试：

1. 布局是否合理，按钮是否对齐
2. textbox 和按钮长宽是否符合要求
3. 界面风格是否统一
4. 界面文字简洁易懂，没有错别字

性能测试：

1. 打开登录界面，需要几秒
2. 其他页面跳转的跳转时间

安全性测试：

1. 登录后的Cookie是否是httponly（降低被盗风险）
2. 账号密码是否通过加密方式发送给服务器
3. 账号密码输入要防止 SQL 注入和 XSS 攻击
4. 错误登录次数限制，防止暴力破解
5. 是否支持多用户在同一机器上登录
6. 是否支持一个用户在多台机器上登录

可用性测试：

1. 是否有快捷键，例如tab和回车

兼容性测试：

1. 不同浏览器是否能正常工作
2. 不同操作系统下是否能正常工作，如 Linux 和 Windows
3. 不同移动设备下是否能正常工作，如 Android 和 IOS
4. 不同分辨率

淘宝上搜索商品的用例设计

功能测试：

1. 输入可查到结果的正常关键字，检索到的内容、链接准确性
2. 输入不可查的关键字，有无错误信息提示
3. 输入一些特殊的内容，如空字符、特殊字符等，可引入等价类划分的方法
4. 测试返回结果的排序：价格、销量、评价、综合
5. 当返回结果庞大的时候，限制第一页的输出量
6. 多选项筛选：关键字、销量、评价、综合
7. 是否支持模糊搜索，通配符查询
8. 网速慢的情况下的搜索
9. 搜索为空的情况
10. 未登录情况和登录情况下的搜索

性能测试：

1. 在不同开发用户数的压力下的表现（评价指标、响应时间）
2. 极限能承载多少用户量同时正常使用
3. 常规压力下能保持多久持续稳定运行
4. 有无内存泄露现象

易用性测试：

1. 交互界面是否方便使用
2. 查询结果的未知按规则列示方便定位，显示字体、字号、色彩便于识别等等
3. 搜索条件的空间风格设计、位置摆放是否醒目、有无快捷查询方式等人性化设计

兼容性测试：

1. Windows/Linux/Unix 等各类操作系统下及各版本下的应用
2. IE/火狐/谷歌/360/QQ等各类浏览器下及各版本、各显示器分辨率条件下的应用
3. SQL/ORACLE/MySQL 等各类数据库存储下的兼容性测试
4. 简体中文、繁体中文、英文等各类语言的兼容性测试
5. iphone/ipad/安卓 等各类移动应用产品下的兼容性测试
6. 与相关监控程序的兼容性测试，如输入法、杀毒、监控、防火墙等工具的同时使用

安全测试：

1. 被删除、加密、授权的数据，不允许被SQL注入等攻击方式查出，是否有安全控制设计
2. 录入一些数据库查询的保留字符，如单引号、%等，造成查询SQL拼接出来的语句产生漏洞
3. 通过白盒测试技术，检查一下在程序设计上是否存在安全方面的隐患
4. 对涉及安全、法律禁止的内容是否进行了相关的过滤和控制

工具

2021年软件测试工具大全（自动化、接口、性能、安全、测试管理）

Selenium —— UI自动化工具

原理：
Selenium是通过模仿浏览器行为，selenium会通过打开一个浏览器，然后执行我们实现设置好的操作事件，从而实现数据获取。

流程：

1. 创建并且发送给浏览器的驱动；
2. 驱动中包含一个HTTP Server，用于接收http请求；
3. HTTP Server根据请求操控浏览器执行步骤；
4. 浏览器将步骤执行结果返回给HTTP Server；
5. HTTP Server将结果返回给Selenium脚本。

优点：

1. Selenium 能解决 web 自动化测试问题
2. Selenium 容易学
3. Selenium 资料丰富
4. Selenium 方便迁移和扩展
5. Selenium 方便团队协作
6. Selenium 免费开源

缺点

1. 截图、录制、回溯不方便
2. 没有流量拦截
3. 没有 mock
4. 在反爬中会被识别，当然其他工具也是。

Postman —— 接口测试手动工具

原理：
通过postman给服务器发送请求，服务器处理完成后，传回给postman，postman显示处理结果。

功能：

1. 测试常见类型的接口请求；
2. 批量执行接口请求；
3. 生成调试报告等。

优点：

1. 门槛低，上手快
2. 跨平台
3. 免费，开源

缺点：

1. 不支持封装公共函数
2. 不能操作文件

Jmeter —— 性能测试手动工具

功能：可以对系统做压力和性能测试，同样也可以对数据库进行测试（基于JDBC）

优点：

1. 免费开源
2. 安装方便
3. 拓展方便，可以编写自己的测试
4. 可以集成 Selenium 进行自动化测试

缺点：

1. 使用Jmeter无法验证JS程序，也无法验证页面，所以需要手工去验证
2. Jmeter的断言功能不是很强大
3. Jmeter脚本的维护需要保存为本地文件，而每个脚本文件只能保存一个测试用例，不利于脚本的维护。

Linux 命令

查看系统日志

1. 查看内存使用情况
打开syslog日志文件，可以使用箭头向下滚动一行。

less /var/log/syslog
1

会输出syslog文件的末尾几行。

tail -f /var/log/syslog
1

Linux 定时任务 —— crontab

使用如下命令编辑当前定时任务、列出当前定时任务、删除工作表

crontab [-u username]　　　　//省略用户表表示操作当前用户的crontab
    -e      (编辑工作表)
    -l      (列出工作表里的命令)
    -r      (删除工作作)
1
2
3
4

使用 crontab -e 进入当前用户的工作表编辑，界面是VIM界面。每一行是一条定时任务的命令。
命令的构成未 时间+动作，时间有分、时、日、月、周五种，操作符有

• *取值范围内的所有数字
• /每过多少个数字
• x-y 从x到y
• ，散列数字

实例：

参考：菜鸟教程：Linux Crontab 定时任务

apt换源

记录软件源的文件为 /etc/apt/sources.list，打开该文件，进行编辑即可。

ip配置怎么改，在哪个文件

改 ip 配置的命令为 ifconfig 命令。配置文件位于/etc/sysconfig/network-scripts。

CPU占用率满了，怎么排查问题？

• 使用top命令，找到CPU占用过高的进程
• 使用 ps -mp pid -o THREAD,tid,time | sort -rn 进程中占用CPU过高的线程
• 使用 echo ‘obase=16;[线程id]’ | bc或者printf “%x\n” [线程id] 将线程ID转为16进制格式
• 使用 jstack pid |grep tid -A 30 [线程id的16进制] 打印线程的堆栈信息。

如何查找home目录下某个日志文件的错误信息？

cat -n test.log | grep ‘error’ 查询日志中含有某个关键字的信息,显示出行号

find 命令找出文件

查找当前目录下.phtml文件中，最近30分钟内修改过的文件。
find ./ -name '*.phtml' -type f -mmin -30

查找当前目录下.phtml文件中，最近30分钟内修改过的文件，的详细情况
find . -name ‘*.phtml‘ -type f -mmin -30 -ls

查找当前目录下，最近1天内修改过的常规文件。
find . -type f -mtime -1

查找当前目录下，最近1天前（2天内）修改过的常规文件。
find . -type f -mtime +1
1
2
3
4
5
6
7
8
9
10
11

grep 命令查找文件和文件内容

grep -c ‘要查找的内容’ 查找的文件

找test文件中含有内容hyzx的行数
grep -c hyzx ./test
1
2

sed 查找和替换文件中的字符串

sed -i 's/Search_String/Replacement_String/g' Input_File
1

• sed：这是一个 Linux 命令。
• -i：这是 sed 命令的一个选项，它有什么作用？默认情况下，sed 打印结果到标准输出。当你使用 sed 添加这个选项时，那么它会在适当的位置修改文件。当你添加一个后缀（比如，-i.bak）时，就会创建原始文件的备份。
• s：字母 s 是一个替换命令。
• Search_String：搜索一个给定的字符串或正则表达式。
• Replacement_String：替换的字符串。
• g：全局替换标志。默认情况下，sed 命令替换每一行第一次出现的模式，它不会替换行中的其他的匹配结果。但是，提供了该替换标志时，所有匹配都将被替换。
• /：分界符。
• Input_File：要执行操作的文件名。

top 命令有哪些显示

ubuntu显示top命令为：