基础

问题报告单样式

问题报告单

测试计划文档组成

测试工作流程

掌握需求 ->测试计划->测试用例->测试执行->测试报告->回归测试

测试开始时，须有：1.系统需求说明书文档 2.BUG管理工具的地址和账户

单元测试：在开发阶段进行，验证单个代码单元的正确性。

集成测试：在单元测试之后进行，验证多个模块的协同工作。

系统测试：在集成测试之后进行，验证整个系统的功能和性能。

验收测试：在系统测试之后进行，由客户或最终用户确认系统是否满足需求

名词解释

黑盒测试：不关心代码，只测输入输出。

白盒测试：基于代码结构设计测试。

结构测试：通过代码结构设计测试用例。

功能测试：验证功能是否符合需求。

路径测试：覆盖代码中的所有路径。

增量测试：逐步集成和测试新模块。

崩溃测试：测试系统在极端条件下的稳定性。

性能测试：评估系统在不同负载下的性能。

回归测试：确保修改后原有功能不受影响。

单元测试：测试最小可测试单元。

集成测试：测试多个模块的组合。

系统测试：测试整个系统。

验收测试：由客户确认系统是否满足需求。

负载测试：模拟高负载测试性能。

压力测试：测试系统的极限能力。

安全测试：评估系统安全性。

兼容性测试：测试系统在不同环境下的兼容性。

冒烟测试：快速测试主要功能。

探索性测试：无预设用例，通过探索发现问题。

α测试：由内部人员在开发环境中进行

β测试：是软件发布前的最终测试阶段，通常在α测试之后进行。它由真实用户在实际环境中执行，目的是发现开发团队未察觉的问题。

用户验收测试（UAT）：由客户确认软件是否满足需求，β测试更侧重于广泛用户反馈。

迭代测试：是敏捷开发中的一种测试方法，随着每个开发迭代的进行，测试活动也同步展开。每次迭代都会进行完整的测试循环，包括单元测试、集成测试、系统测试等，以确保新增功能和现有功能都符合需求。特点：持续进行：测试贯穿整个开发周期，而非仅在开发完成后进行。增量式：每次迭代只测试新增或修改的部分，同时进行回归测试以确保原有功能不受影响。快速反馈：通过频繁测试，开发团队能快速发现并修复问题。能都经过充分测试。

面试

测试流程与规范

偶现bug怎么处理？

截图、保留证据，根据操作路径进⾏重现，提交禅道，上线前继续跟踪，上线后再跟踪⼀两个版本，最后作为遗留bug写到测试报告⾥⾯

没有需求⽂档，如何开展测试？

1、与相关⼈员沟通，产品或开发
2、参考同⾏业竞品，总结梳理需求
3、根据⽤户习惯和⾏业规范，总结梳理

线上出现bug怎么办？

⾸先评估严重程度和产⽣原因，
1、如果是影响⾯⽐较⼤的功能性问题，且短时间内不好定位具体原因，⾸先考虑做代码回滚，恢复到上
⼀个稳定版本，然后在测试环境进⾏重现，定位问题原因
2、如果是能快速定位问题原因，就让开发做紧急修复，测试后进⾏上线
3、如果是性能问题，⼀般会进⾏扩容，或重启尝试解决，然后开发会做进⼀步的问题定位和优化
4、如果是⼀些优化性问题，会先进⾏记录，然后在下个版本解决
最后，线上bug解决后，要对问题进⾏复盘，分析和总结，避免后续再出现类似问题

临近上线发现了bug要怎么处理？

⾸先与相关⼈员（开发、产品）评估bug的严重程度和影响范围，
如果是轻微的bug，可以考虑先上线，后续版本迭代中修复，
如果是⽐较严重的bug，找开发沟通，能否快速修复，并且有⾜够的时间去做下测试
如果时间不⾜了，那就得和相关⼈员后台，是否可以延期上线，避免上线后造成严重的后果
参加⼈员：测试⼈员、开发⼈员、产品⼈员会议评审

⽤例评审都有哪些⼈参加？怎么做的？有什么标准？

参加⼈员：测试⼈员、开发⼈员、产品⼈员会议评审
标准：

⽤例设计的结构安排是否清晰、合理，是否利于⾼效对需求进⾏覆盖。
优先极安排是否合理。
是否覆盖测试需求上的所有功能点。
⽤例是否具有很好可执⾏性。例如⽤例的前提条件、执⾏步骤、输⼊数据和期待结果是否清晰、正确；
期待结果是否有明显的验证⽅法。
是否已经删除了冗余的⽤例

迭代测试发现不了问题，怎么办？

1)必要的业务培训
结合业务流程图、系统架构图，对业务系统有个整体的感知。知道业务系统的整体业务流向及涉及的系统架构，这样有助于测试⼈员从⼤的⽅向去拉通测试场景，不⾄于陷⼊细节中⽽⽆法顾及全貌。
2)制定明确地测试策略
即明确两个问题：测什么？怎么测？“减少缺陷的出现”可以通过测试前移等⽅法来解决，在进⾏软件需求分析和架构设计的时候发现
缺陷；
3)严格执⾏测试流程
设计测试⽤例、⽤例评审、开发⾃测等
4)建⽴质量意识和责任感
出现问题时，测试应该有责任和能⼒去探查问题的根源并加以改进
5)定期回顾和总结
缺陷分析，在某个迭代或者版本的周期内（或者更⻓时间），对BUG产⽣的原因、修复周期、累
积趋势进⾏分析。总结分析bug和测试过程问题，形成的质量报告不仅能准确评估过去产品质量，还能为未来产品提出改进建议，持续推进产品质量的不断提⾼和完善

接口测试

什么时候会做接⼝测试

回归测试
前后端联调阶段（开发进⾏⾃测）
验证⼀些后端接⼝是否有限制的场景（资⾦相关）

怎么做接⼝测试的

1、获取到接⼝⽂档、熟悉单接⼝的业务、连接接⼝业务，包括接⼝地址，请求⽅式，鉴权，⼊参，出
参，错误码等加密，签名等
2、编写接⼝⽤例并评审
正例：单接⼝，链接接⼝
反例：鉴权（过期的场景、不正确）
参数（类型异常、⻓度异常），
错误码（-1 系统繁忙、不同公司不⼀样），
⿊名单（⿊名单⽤户是否还允许访问）
禁⽤
调⽤次数（⼿续费）
分⻚（每⻚10条，每⻚是否都有数据，总数据是否正确，边界值）
兼容性（不同调⽤⽅式下（如app版本不⼀样时），接⼝返回的数据是否相同）
3、执⾏⽤例
举出具体的接⼝案例以及⼀些特定场景，如：接⼝串联（token传递）、环境变量、全局变量、随机数获
取（⽐如第三⽅单号）

4、持续集成
钉钉群通知、电⼦邮件

如果⼀个接⼝请求不通，那么你会考虑哪些⽅⾯的问题？

1、检查请求四要素：请求⽅式、域名、请求头、请求参数、有没有空格
2、⽹络情况
3、项⽬迭代过程中是否有部署好
4、服务器的防⽕墙
5、查看后台⽇志是否有报错
6、访问权限是否到位
7、⼀边打开fiddler（打开代理服务器，证书有问题）⼀遍做接⼝测试（基于https）
8、检查是否绑定了错误的hosts

接⼝测试的作⽤

1、接⼝测试是⽆⻚⾯的功能测试，设计⽤例思路跟功能测试⼀样（只是⼀个注重的是测前端⻚⾯，⼀个注重的是测后端接⼝）
2、接⼝测试可以绕开前端
3、接⼝测试可以校验并发的情况
4、可以核对接⼝请求资源⼤⼩
5、可以进⾏弱⽹测试

接⼝测试的主要关注点？

（1）业务逻辑（业务逻辑覆盖）
（2）响应结构
（3）数据格式
（4）数据正确性（依据来源：查数据库与服务器和接⼝返回值⽐较）

Cooike、session、token的区别

相同点：三者都⽤于鉴权，都是服务器⽣成
不同点：
Cooike：保存在浏览器，不安全
session：保存在服务器的内存，并且它⼀般是通过cooike传输sessionid，它⽐cooike更安全，当访问量⼤的时候影响服务器的性能
token 存储在服务器的数据库，通常是通过登录或者⼀个特定的接⼝传⼊appid和appsect来获取，后续所有的接⼝都必须带上token 才能请求成功，有些项⽬toekn也是通过cookie传输的

特定接⼝：对于需要做RSA加密的接⼝，需要做签名的接⼝在Jmeter/postman要如何处理？

JMeter

使用 JSR223 预处理器 或 BeanShell 预处理器 编写脚本实现 RSA 加密和签名。

将结果存储到 JMeter 变量中，并在请求中使用。

Postman

使用 Pre-request Script 编写脚本实现 RSA 加密和签名。

将结果存储到 Postman 变量中，并在请求中使用。

如何验证接⼝是否返回成功

1、校验状态码是否200（状态断⾔只有⼀个）
2、核⼼业务断⾔
返回结果⽐较短的：key=value
返回结果较⻓的：通过关键信息，数据库校验⻓度
3、XML或JSON：通过正则，jsonpath提取关键的业务字段进⾏断⾔

接⼝关联怎么做

⽤⼀个全局变量来处理依赖的数据，⽐如登录后返回 token,其它接⼝都需要这个 token,那就⽤全局变量来传 token 参数

没有接⼝⽂档如何做接⼝测试

可以使⽤抓包⼯具进⾏抓包看接⼝请求参数，然后不懂的跟开发沟通

常⻅的接⼝请求头

Accept
X-Requested-With
User-Agent
Content-Type

接⼝测试常⽤检查点

接口测试检查点（按检查类型分类）

检查类型	检查点	描述
业务测试	正常流程返回数据的正确性	验证接口在正常业务流程下返回的数据内容、格式、逻辑是否符合预期。
	接口文档符合性	验证返回值是否按接口文档规定格式（如JSON/XML）、编码（UTF-8）、字段命名（如`return_msg`）返回。
	参数类型传递正确性	验证接口是否正确处理参数类型（如数字、字符串、布尔值等）。
	接口依赖关系测试	验证接口依赖的其他服务或数据源异常时，是否能正确处理（如降级、超时）。
	异常业务处理逻辑	验证业务异常场景（如余额不足、库存为负）是否返回明确的错误码和描述。
参数测试	参数值全量覆盖验证	对参数所有可能取值（枚举值、布尔值等）进行覆盖测试。
	必填参数正确性验证	必填参数传入有效值时，接口返回预期结果。
	必填/非必填参数组合验证	测试不同必填与非必填参数组合下的接口行为（如缺少非必填参数是否影响功能）。
	参数边界值验证	验证参数在边界值（如最大值、最小值、空值、超长字符串）下的处理逻辑。
异常测试	必填参数缺失	缺失必填参数时是否返回明确错误码（如`400 Bad Request`）。
	非法参数值	传入非法参数（如非数字传入数字字段）是否返回类型错误提示。
	超限参数值	参数超过允许范围（如金额超限）是否触发业务规则校验。
性能测试	响应时间	单请求响应时间是否在SLA要求范围内（如≤500ms）。
	并发处理能力	高并发场景下接口是否稳定（如100并发用户请求成功率≥99%）。
	大数据量处理	处理大量数据时（如万级列表查询）是否返回正确且性能达标。
安全性测试	敏感信息加密	返回的敏感数据（如手机号、身份证号）是否脱敏或加密。
	未授权访问防护	未携带Token或权限不足时是否返回`401 Unauthorized`。
	SQL注入防护	传入SQL注入语句（如`' OR 1=1 --`）是否被拦截并返回错误。
幂等性测试	重复请求一致性	多次提交相同请求（如支付）是否仅产生一次有效结果。
兼容性测试	多版本兼容	新旧版本接口参数格式（如v1/v2）是否能兼容处理。
	多客户端兼容	不同客户端（Web/App/第三方）调用接口时返回数据格式是否一致。

功能测试

测试环境没问题，但⽣产/灰度环境有问题，会从哪些原因去定位排查

1、部署原因，⽣产/灰度环境的代码与测试环境验证通过的不⼀致
2、测试数据问题，有些bug需要特殊的数据才能重现出来
3、配置原因，⽣产/灰度环境的配置出问题