测试开发面试题

1. 谈谈对测试的理解？

1. 不仅仅是找出错误，还包括验证软件的功能、性能、可靠性和用户体验等方面，找到问题并及时发现解决。
2. 测试可以提前发现和修复缺陷，减少未来的维护成本。
3. 包括功能测试、性能测试和安全测试。

2. 测试开发需要掌握的知识

1. 编程技能：掌握一种编程语言，能够编写一些自动化测试脚本和工具
2. 掌握测试基本知识，单元测试、集成测试、系统测试和验收测试，掌握黑盒测试和白盒测试的原理和适用场景
3. 知道如何进行测试需求分析，设计有效的测试用例和测试计划
4. 熟悉常用的测试工具和框架，例如Selenium，JMeter、Jenkins等

3. 测试开发需要哪些能力

1. 分析能力：根据复杂的软件系统和业务需求，设计有效的测试用例
2. 技术能力：编程能力，了解不同的测试框架和编程语言，编写自动化测试脚本
3. 细节观察能力：对细节高度敏感，发现bug
4. 沟通能力：与开发团队、产品经理进行沟通，确保测试结果被正确传达
5. 学习能力：不断学习测试知识和业务知识
6. 解决问题的能力

4. 测试流程

1. 需求分析
2. 制定测试计划
3. 测试用例设计
4. 测试用例评审
5. 配置测试环境，执行测试用例，记录测试结果，报告发现的bug
6. 回归测试：代码更改后，执行回归测试确保新的更改没有破坏原有的功能
7. 性能测试
8. 部署到预生产环境
9. 编写测试报告
10. 复盘和总结

5. 针对测试流程，输出的材料

1. 测试计划
2. 测试用例
3. 测试脚本
4. 错误报告
5. 测试执行日志
6. 测试环境配置文档
7. 测试报告

6. 测试的常用方法

功能测试 单元测试 集成测试 系统测试 回归测试 性能测试 验收测试

7. 单元测试和集成测试的了解

1. 单元测试是针对软件的最小可测试部分（通常是一个类、一个方法或类）进行测试。通常在编写或修改代码后立即进行，以快速发现和修正代码中的错误，常用的工具Junit，PyTest等
2. 集成测试是在多个模块或组件集成在一起后进行的测试，用来验证不同模块间的接口和交互是否按预期工作，通常使用集成测试框架，比如Postman Selenium进行
3. 增量集成：逐步添加新的模块并测试
4. 大爆炸集成：同时集成所有模块后一次性测试。

8. 系统测试和集成测试的区别和使用场景

1. 系统测试是在整个软件系统完成集成后进行的测试。目的是验证整个系统是否符合制定的需求。
2. 集成测试是在多个软件模块或组件被集成在一起时的测试。目的是验证模块或组件之间的交互。 集成测试通常在单元测试之后，系统测试之前。当整个应用开发接近完成时，进行系统测试。

9. 什么是黑盒测试

黑盒测试，称为功能测试或行为测试，测试者只关注软件的输入和输出，不需要了解程序的内部实现，主要验证软件的功能是否符合用户需求和规格说明。常用的测试方法包括等价类划分、边界值分析、因果图法、状态转换测试、错误猜测等。

10. 什么是白盒测试

白盒测试，也称为功能测试和透明盒测试，测试者需要了解程序内部工作机制，包括代码、逻辑流程、内部结构、主要验证代码的逻辑路径。主要适用于单元测试和集成测试。

11. 等价类划分和边界值法

1. 等价类划分 等价类划分是将系统的输入划分为若干个部分，然后从每个部分选取少量代表性数据进行测试。

• 有效/无效等价类：符合/不符合规格说明的输入条件 通过测试有效等价类来验证系统的正确性，测试无效等价类测试系统的健壮性。

2. 边界值法 软件错误往往发生在输入或输出范围的边缘，所以边界值分析专注于测试输入数据的边界条件而不是中间值。

12. 等价类划分的难点是什么

1. 正确定义等价类，难点在于正确理解需求和规格说明。理解不全面，可能导致等价类的定义不准确，从而影响测试覆盖率和有效性。
2. 识别有效和无效的等价类
3. 处理复杂的输入条件，当输入条件非常复杂或者相互依赖时，定义清晰且准确的等价类变得更加困难。

13. 接口测试用例的编写需要注意哪些要点

1. 明确接口规格：接口功能、输入输出参数、数据格式、请求方法（GE T、POST、PUT、DELETE等）和预期的行为。
2. 返回值：（正常和异常的输入值）下的响应内容是否正常。
3. 接口的业务逻辑和功能是否正常。
4. 数据库校验。
5. 性能测试（响应时间、tps等）
6. 安全性，敏感信息加密，权限控制等。

14. 接口测试有哪些工具

• Postman: API测试工具，用于发送各种HTTP请求，并检查响应。
• JMeter：测试web应用程序的性能和负载。
• Swagger UI： 用于设计、构建、文档化和测试REST API的工具

15. 测试接口的流程

1. 理解接口文档，了解接口的业务功能，请求方法、请求参数、响应结构、错误码以及对应的数据库存储
2. 编写测试用例，涵盖正常的输入情况和异常的输入情况
3. 使用测试工具，观察响应是否符合预期，验证响应的状态码、响应体内容、响应时间等。

16. 性能测试时，一般关注的指标

1. TPS:每秒事务数，代表性能的好坏，TPS越高，性能越好。
2. 平均响应时间：请求的平均消耗时间，时间越短，性能越好。
3. 并发数：同时向服务端发起请求的虚拟用户数，在不同的工具中可以用多个进程/线程来实现。
4. 错误率：失败的请求比例

17. 功能测试用例一般包含哪些内容

1. 测试用例ID：一个唯一标识符，用于区分和引用测试用例
2. 测试用例标题： 简短描述测试用例的目的或主要功能
3. 功能模块：指明
4. 测试目的/描述：
5. 前置条件：
6. 测试步骤：
7. 测试数据
8. 预期结果
9. 实际结果
10. 通过/失败标准
11. 测试环境
12. 备注信息
13. 缺陷/问题ID

18. 如何写测试用例

1. 测试人员提前介入，彻底理解需求
2. 如果有类似的需求，参考类似需求的测试用例，以及类似需求的bug情况
3. 清楚输入、输出的各种可能性，以及各种输入输出之间的关联关系，理解清楚需求的执行逻辑，通过等价类、边界值、判定表等方法找出大部分用例
4. 找到需求相关的特性，补充测试用例
5. 多总结类似功能点的测试点，写出质量高的测试用例
6. 书写格式清晰

设计测试用例的方法

黑盒测试方法：

1. 等价类划分法
2. 边界值分析法
3. 因果图测试法
4. 决策表测试法
5. 转台转换法 白盒测试法：
6. 语句覆盖
7. 分支覆盖
8. 路径覆盖
9. 条件覆盖
10. 循环覆盖

如何提高用例的覆盖率，减少漏测

1. 根据需求文档编写用例， 确保每条需求都能被对应的用例覆盖。
2. 充分了解业务，挖掘隐形需求，并编写对应的用例
3. 除了正常的业务场景，多考虑异常的场景和数据
4. 从多个维度对软件进行测试，功能、性能、安全等方面
5. 多站在用户的角度思考问题，模拟用户的使用场景
6. 组织用例评审

21. bug 的生命周期

1. New:(新的)
2. Assigned:(已指派的)
3. Open：（打开的）
4. Fixed：（修复的）
5. Pending Reset：（待在测试的）
6. Reset：（在测试的）
7. Closed：（已关闭的）
8. Reopen（再次打开的）
9. Pending Reject（拒绝中）
10. Rejected（被拒绝的）
11. Postponed（延期）

22. 常见的测试工具

1. 自动化测试工具

• Selenium：用于自动化Web应用程序测试的工具，
• Appium：用于自动化移动应用程序测试的开源工具，

2. 性能测试工具

• JMeter： 用于测试Web应用程序的性能和负载
• LoadRunner：支持模拟大量用户测试系统的性能。

3. 接口测试

• Postman：用于API开发和测试的流行工具
• Swagger UI：用于设计、构建、文档化和测试REST API的工具

4. 单元测试

• Pytest：用于Python的测试框架
• Junit：用于Java应用程序的单元测试框架，支持自动化测试脚本的执行和报告生成。

23. App测试和Web测试有什么区别

1. web和app的区别

• web项目，一般是b/s架构，基于浏览器的
• App是C/S架构，必须要有客户端。
• 从系统架构来说，web测试更新了服务器端，客户端会同步更新。且保证每个用户的客户端是一致的。APP测试，如果修改了服务端，客户端用户使用的核心版本都需要回归测试一遍。

2. 性能方面

• web只关注响应时间
• App关心流量、电量、CPU、GPU、内存等

3. 兼容性方面。

• Web基于浏览器的，更倾向于浏览器和硬件，电脑系统方向的兼容，但是还是以浏览器为主。浏览器的兼容则一般是选择不同的浏览器进行测试。
• App的测试必须依赖phone或pad，不仅要看分辨率、屏幕尺寸，还要看操作系统。

4. 相较于web测试，app更是多了专项测试：中断、来电、短信、关机重启等，以及弱网测试。（弱网测试是App测试中必须执行的一项测试。包含弱网和网络切换测试。需要测试弱网所造成的用户体验，重点考虑回退和刷新是否造成二次提交。需要测试丢包、延时的处理机制。

• 安装、卸载、更新 web测试不考虑这些。app必须测试安装、更新、卸载。除了常规的安装、更新和卸载，还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件，更新的强制更新与非强制更新、增量包更新、断点续传、弱网，卸载后删除app的相关文件等。
• 界面操作 现在app产品的用户产品都是触摸屏手机，测试的时候包括手势，横竖屏切换，多点触控，事件触发区域等测试。

24. 软件质量的六个特征

任何事物的用例设计，需要按照软件质量六大特征来分类说明

1. 功能性：表示软件能够提供满足明确和隐含需求的功能。涉及适用性、准确性、互操作性、安全性和功能性。
2. 可靠性：指软件在特定条件下持续正常运行的能力。包括成熟度、容错性、恢复能力等。
3. 易用性：软件的界面和功能对用户是否有好，是否易于理解、学习、使用和吸引用户。包括可理解性、易学性、操作性、吸引力和用户界面的适用性。
4. 效率。指软件在特定条件下对系统资源的有效使用。涉及时间效率和资源效率。
5. 可维护性：指在必要时能够有效的进行修正和改进软件的能力。包括模块化、可重用性、分析性、修改性和测试性。
6. 可移植性：标识软件从一个环境迁移到另一个环境的能力。

25. 如果做一个杯子的检测，怎么测试

从软件质量的六⼤特征（功能性、可靠性、易⽤性、效率、可维护性、可移植性）的⻆度来看，对⼀个实体产品如杯⼦进⾏类⽐测试，可以这样考虑：
1. 功能性
适⽤性：测试杯⼦是否适合其设计⽤途，如饮⽤⽔、茶、咖啡等。
准确性：确保杯⼦的容量标示准确。
符合性：检查杯⼦是否符合相关的健康和安全标准。
2. 可靠性
成熟度：确保杯⼦在正常使⽤条件下不会轻易破裂或损坏。
容错性：测试杯⼦在⾮常规使⽤（如⾼温、跌落）情况下的性能。
3. 易⽤性
理解性：检查杯⼦是否容易被⽤户正确使⽤（如是否明显标示不可微波）。
学习性：对于特殊设计的杯⼦（如带温度显示），测试⽤户学习如何使⽤的难易程度。
操作性：确保杯⼦设计⽅便持握和使⽤。
4. 效率
时间⾏为：对于保温杯，测试保温效果持续的时间。
资源利⽤：评估杯⼦设计在材料利⽤上的效率。
5. 可维护性
分析性：检查是否容易识别杯⼦的损坏或磨损。
修改性：评估修复损坏杯⼦的难易程度（尽管⼤多数杯⼦可能是⼀次性的）。
6. 可移植性
适应性：测试杯⼦是否适⽤于各种环境（如室内、户外）。
安装性：考虑杯⼦是否容易清洁、存储。

26. 给你一个页面，如何展开测试

• UI测试：页面布局、页面钥匙检查、空间长度是否够长；显示时是否被截断；支持的快捷键，Tab键切换焦点顺序正确性等。
• 功能测试：页面上各类控件的测试范围，测试点。结合控件的实际作用来补充检查点
• 安全测试：输入特殊字符，sql注入，脚本注入测试。后台验证测试，对于重要的表单，绕过js检验后台是否验证；数据传输是否加密处理
• 兼容性测试
• 性能测试

27. 说说用户界面登录过程都需要哪些测试

1. 功能测试
输⼊正确的⽤户名和密码，点击提交按钮，验证是否能正确登录。
输⼊错误的⽤户名或者密码,验证登录会失败，并且提示相应的错误信息。
登录成功后能否能否跳转到正确的⻚⾯
⽤户名和密码，如果太短或者太⻓，应该怎么处理
⽤户名和密码，中有特殊字符（⽐如空格），和其他⾮英⽂的情况
记住⽤户名的功能
登陆失败后，不能记录密码的功能
⽤户名和密码前后有空格的处理
密码是否⾮明⽂显示显示，使⽤星号圆点等符号代替。
牵扯到验证码的，还要考虑⽂字是否扭曲过度导致辨认难度⼤，考虑颜⾊（⾊盲使⽤者），刷新或换⼀个按钮是否好⽤
登录⻚⾯中的注册、忘记密码，登出⽤另⼀帐号登陆等链接是否正确
输⼊密码的时候，⼤写键盘开启的时候要有提示信息。
什么都不输⼊，点击提交按钮，检查提示信息。
2. 界⾯测试
布局是否合理
界⾯的设计⻛格是否与UI的设计⻛格统⼀。
界⾯中的⽂字简洁易懂，没有错别字。
3. 性能测试
打开登录⻚⾯，需要的时间是否在需求要求的时间内。
输⼊正确的⽤户名和密码后，检查登录成功跳转到新⻚⾯的时间是否在需求要求的时间内。
模拟⼤量⽤户同时登陆，检查⼀定压⼒下能否正常登陆跳转。
4. 安全性测试
登录成功后⽣成的Cookie，是否是httponly (否则容易被脚本盗取)。
⽤户名和密码是否通过加密的⽅式，发送给Web服务器。
⽤户名和密码的验证，应该是⽤服务器端验证， ⽽不能单单是在客户端⽤javascript验证。
⽤户名和密码的输⼊框，应该屏蔽SQL注⼊攻击。
⽤户名和密码的的输⼊框，应该禁⽌输⼊脚本 （防⽌XSS攻击）。
防⽌暴⼒破解，检测是否有错误登陆的次数限制。
是否⽀持多⽤户在同⼀机器上登录。
同⼀⽤户能否在多台机器上登录。
5. 可⽤性测试
是否可以全⽤键盘操作，是否有快捷键。
输⼊⽤户名，密码后按回⻋，是否可以登陆。
输⼊框能否可以以Tab键切换。
6. 兼容性测试
不同浏览器下能否显示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。
同种浏览器不同版本下能否显示正常且功能正常。
不同的平台是否能正常⼯作，⽐如Windows, Mac。
移动设备上是否正常⼯作，⽐如Iphone, Andriod。
不同的分辨率下显示是否正常。
7. 本地化测试
不同语⾔环境下，⻚⾯的显示是否正确。

28. 测试提交一个bug，开发认为不是bug，如何处理

1. 告知开发bug 的判断依据，同时明确开发说不是bug 的理由
2. 对开发的理由进行校验，校验依据：a. 参照需求文档 b. 跟产品经理进行沟通确认
3. 校验结果不是bug，关闭bug，如果是bug提交给开发进行处理，确保产品质量。

29. 发现一个bug，如何定位是客户端还是服务端的问题

1. 复现问题，确保能够可靠的重现这个bug。记录重现bug 的具体步骤、输入、环境配置等。
2. 查看错误日志，通过查看客户端/服务端日志，分析有没有异常的日志信息，从而确定具体原因
3. 分析客户端：使用开发者工具来检查网络请求、响应数据、控制台输出等，如果客户端收到的响应数据是正确的，但表现异常，可能是客户端问题。
4. 分析服务端：检查服务端的处理逻辑。确保服务端正确处理了来自客户端的请求，并返回了正确的响应。如果处理请求出现了错误或者返回了错误数据，问题可能出现在服务端。
5. 验证网络通信。