测试基础

1. 测试基础

1.1 什么是软件测试？

使用某些技术手段对软件进行操作，发现软件缺陷，判断软件是否满足用户使用的需求。

测试分类

1.1 什么是单元测试

完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确的编码，使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误，通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。

1.2 什么是集成测试

通过测试发现与模块接口有关的问题。目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构，应当避免一次性的集成（除非软件规模很小），而采用增量集成。

自顶向下集成：模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。

自底向上集成：从原子模块开始来进行构造和测试，因为模块是自底向上集成的，进行时要求所有隶属于某个给顶层次的模块总是存在的，也不再有使用稳定测试桩的必要。

1.3 什么是系统测试

是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。

系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。

1.4 什么是回归测试

回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。根据修复好了的缺陷再重新进行测试。回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。

1.5 什么是验收测试

验收测试是指系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。

验收测试包括Alpha测试和Beta测试。

Alpha测试：是由用户在开发者的场所来进行的，在一个受控的环境中进行。

Beta测试：由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件。

1.6 什么是黑盒测试？

黑盒测试：在进行测试时，我们看不见程序的源代码，只对程序的功能进行测试。

就号像一个黑色的盒子一样，看不到内部有什么东西。

在黑盒测试的过程中主要关注输入与输出以及输出是否符合预期，并不关注具体代码的实现。

常用的黑盒测试方法有：等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。

1.7 什么是白盒测试？

白盒测试：在测试的过程中能看到程序的源代码，主要是对程序的源代码进行测试。

测试人员检查程序的内部结构，根据内部逻辑来设计测试用例，比如单元测试就是一种白盒测试。

白盒测试根据软件的内部逻辑设计测试用例，常用的技术是逻辑覆盖，即考察用测试数据运行被测程序时对程序逻辑的覆盖程度。

主要的覆盖标准有 6 种：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合条件覆盖和路径覆盖。

覆盖标准从弱到强

1. 语句覆盖每条语句至少执行一次。
2. 判定覆盖每个判定的每个分支至少执行一次。
3. 条件覆盖每个判定的每个条件应取到各种可能的值。
4. 判定/条件覆盖同时满足判定覆盖条件覆盖。
5. 条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
6. 路径覆盖使程序中每一条可能的路径至少执行一次。

1.8 什么是灰盒测试？

灰盒测试：是介于白盒测试和黑盒测试之间的一种测试方法，它能看见程序的部分源码，主要是对程序的接口进行测试。

在我们执行测试的过程中，一般是先进行单元测试 -> 集成测试 -> 系统测试。

在我们测试完成单个模块运行正确之后，还需要去验证单个模块与模块组合在一起时是否会出现问题，这个测试方式就是灰盒测试。

1.9 为什么进行了白盒测试之后还要进行黑盒测试？

白盒测试不仅仅关注输入与输出的结果是否正确，同时还关注程序是如何处理的。而黑盒测试在整个测试过程中只关注输入和输出，如果输入一个测试数据，输出的结果是正确的，我们就认为这个功能是正确的。虽然从某种角度来看，白盒测试比黑盒测试更为全面。但是有一些黑盒测试的内容是白盒测试不能做到的。比如黑盒测试是更接近于用户角度使用的测试，因此我们还会关注程序的易用性、界面展示、业务流程等，而白盒测试时并不考虑这些。

2. 测试基本流程是什么？

1. 需求分析：阅读需求文档，联合前端、后端、测试、产品等部门，确保各部门对需求理解一致，了解软件需要的具体功能；
2. 计划编写：确定测试的目标和范围，对人力、物力进行分配，确定哪些人要具体做哪些事情，对进度进行安排，确定要使用哪些测试工具、测试策略；
3. 用例设计：分析需求，从需求中提取测试点，用来设计测试用例；
4. 用例执行，提交缺陷，回归测试：当进行测试后，会发现软件的缺陷。确定缺陷后，将缺陷提交给开发人员，开发人员修改后进行回归测试；
5. 测试报告：编写测试的总结报告。

3. 常见的测试方法有哪些？

3.1 等价类划分法

适用于穷举场景下

具体内容：在所有的测试数据中，对具有某种共同特征的数据集合进行划分，然后从每一个子集中选取少数具有代表性的数据作为测试用例。

比如：验证6-10位自然数QQ号的合法性

按照等价类划分法：

• 有效等价类：6-10位自然数；
• 无效等价类：小于6位，大于10位自然数，以及6-10位非自然数

3.2 边界值分析法

适用于有边界的范围

具体内容：对输入、输出的边界值进行测试，在边界值分析法中规范了要选择的边界值，上点、离点、内点。

• 上点：正好等于；
• 离点：刚好大于或刚好小于；
• 内点：范围内的点；

image-20230827164118183

3.3 判定表法

以表格的形式表达多条件依赖逻辑判断的工具。

比如：验证“若用户欠费或者关机，则不允许主被叫”功能的测试。

• 条件桩：列出问题中的所有条件，列出条件的次序无关紧要；
• 动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束；
• 条件项：列出条件对应的取值，所有可能情况下的真假值；
• 动作项：列出条件项的、各种取值情况下应该采取的动作结果

image-20230827164544031

3.4 因果图分析法

利用图解法分析输入的各种组合情况，从而设计测试用例。

3.5 错误推测法

根据测试者以往的测试经验对可能出现的错误进行测试。

4. 为什么要进行自动化测试？

自动化测试是指使用自动化测试工具来执行测试用例。

1. 通过采用自动化测试，可以替代大量重复性的工作，提高测试效率；
2. 保证每次测试的一致性和可重复性。由于每次自动化测试执行时脚本都是相同的，所以每次执行的测试具有一致性，同时也可以提高回归测试的效率；
3. 可以更好的利用非工作时间。由于自动化测试能按计划自动执行，因此就可以利用非工作时间使用自动化测试来执行测试。

4.1 说说你知道的自动化测试框架

• Selenium（Web应用程序自动化测试）
• Appium（移动应用程序自动化测试）
• TestComplete（桌面应用程序自动化测试）
• JMeter（负载测试）
• Robot Framework（通用自动化测试框架）

4.2 自动化测试和手动测试的优缺点

4.2.1 手动测试

缺点:

1. 重复的手动测试，代价高 ;
2. 依赖于测试人员的能力。

优点:

1. 可以依据测试人员的经验和对错误的猜测能力；
2. 测试人员具有审美能力和心理体验；
3. 测试人员具有逻辑推理能力和是非判断能力。

4.2.2 自动化测试

优点:

1. 减少时间和成本，提高资源利用率；
2. 能够测试手动测试无法进行测试的板块；
3. 测试具有重复性、一致性和复用性；
4. 能够增加软件信任度。

缺点:

1. 非常依赖测试质量；
2. 不能取代手动测试，查出的缺陷比手动测试更少；
3. 测试自动化不能提高有效性，还有可能制约软件开发；
4. 工具本身不具备想象力。

4.3 说一说jmeter

jmeter是一款JAVA环境运行的工具，只要按装了java环境就可以直接打开jmeter包了，不需要另外安装。jmeter是一款多功能的接口测试用具并且可以进行性能测试，可以实现多线程组同时启动。

功能比postman多。

4.4 有用过什么测试工具吗？

• 接口测试用Swagger、postman；
• 抓包工具用WireShark、Fiddler；
• 性能测试用jmeter；
• 自动化测试用selenium、appium。

5. 软件开发的流程是什么？

5.1 需求分析

1. 相关系统分析员向用户初步了解需求，然后用相关的工具软件列出要开发的系统的大功能模块，每个大功能模块有哪些小功能模块，对于有些需求比较明确相关的界面时，在这一步里面可以初步定义好少量的界面。
2. 系统分析员深入了解和分析需求，根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚列出系统大致的大功能模块，大功能模块有哪些小功能模块，并且还列出相关的界面和界面功能。
3. 系统分析员向用户再次确认需求。

5.2 概要设计

开发者需要对软件系统进行概要设计，即系统设计。概要设计需要对软件系统的设计进行考虑，包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。

5.3 详细设计

在概要设计的基础上，开发者需要进行软件系统的详细设计。在详细设计中，描述实现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系，需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑，以便进行编码和测试。应当保证软件的需求完全分配给整个软件。详细设计应当足够详细，能够根据详细设计报告进行编码。

5.4 编程实现

在软件编码阶段，开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求，开始具体的编写程序工作，分别实现各模块的功能，从而实现对目标系统的功能、性能、接口、界面等方面的要求。

5.5 测试

测试编写好的系统。交给用户使用，用户使用后一个一个的确认每个功能。测试同样是项目研发中一个相当重要的步骤，对于一个大型软件，3个月到1年的外部测试都是正常的，因为永远都会有不可预料的问题存在。完成测试后，完成验收并完成最后的一些帮助文档，整体项目才算告一段落，当然日后少不了升级，修补等等工作，只要不是想通过一锤子买卖骗钱，就要不停的跟踪软件的运营状况并持续修补升级，直到这个软件被彻底淘汰为止。

5.6 软件交付

在软件测试证明软件达到要求后，软件开发者应向用户提交开发的目标安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等双方合同约定的产物。

5.7 验收

5.8 维护

6. 如何设计搜索框测试用例？

6.1 功能测试

1. 搜索内容为空，验证系统如何处理；
2. 搜索内容为空格，查看系统如何处理；
3. 边界值验证：在允许的字符串范围内外，验证系统的处理；
4. 超长字符串输入，系统是否会截取允许的长度来检验结果；
5. 合法的字符串长度后，加空格验证检索结果；
6. 多关键字中间加入空格，逗号，tab验证系统的结果是否正确；
7. 验证每种合法的输入，结果是否正确；
8. 是否支持检索内容的复制、粘贴、编辑等操作；
9. 是否支持回车键搜索；
10. 多次输入相同的内容，查看系统的检索结果是否一致；
11. 特殊字符、转义字符、html脚本等需要做处理；
12. 敏感词汇，提示用户无权限等；
13. 输入的内容是否支持快捷键操作等；
14. 只能输入允许的字符串长度等；
15. 输入链接是否正确跳转；
16. 搜索的历史纪录是否显示在下面；
17. 搜索内容有没有联想功能。

6.2 界面测试

1. 查看UI是否显示正确，布局是否合理；
2. 是否有错别字；
3. 搜索结果显示的布局是否美观；
4. 已查看的结果链接，链接的颜色要灰化处理；
5. 结果数量庞大时，页面的分页布局是否合理。

6.3 安全性测试

1. 脚本的禁用；
2. SQL的注入，检索SQL SELECT语句等；
3. 敏感内容的检索是禁止的；
4. 特殊字符的检索；
5. 被删除、加密、授权的数据，不允许被查出来，是否有安全设计控制。

6.4 兼容性测试

1. 多平台Windows，mac；
2. 移动平台android，ios；
3. 多浏览器火狐、chrome、IE等。

6.5 性能测试

1. 搜索页面的链接打开速度是否满足设计要求；
2. 搜索出结果消耗时间，是否满足设计要求。

7. 如何设计购物车的测试用例？

7.1 功能测试

• 添加商品
  1. 是否能够添加商品；
  2. 添加单个商品数量是否有上下限；
  3. 添加商品种类是否有上下限；
  4. 添加同类型商品的不同规格商品显示是否分条显示；
  5. 加入购物车商品排序是否合理。
• 删除商品
  1. 能否删除单类商品；
  2. 是否有快速删除多种商品方式（全选，删除）；
  3. 删除商品是否有确认提示。
• 跳转商品详情
  1. 跳转商品图片显示是否正常；
  2. 跳转商品链接显示内容是否完整，是否过长；
  3. 点击图片或者链接是否能够跳转商品详情。
• 编辑商品、商品跳转
  1. 是否有通过+ -编辑商品数量方式；
  2. 是否有通过输入直接编辑商品数量方式；
  3. 编辑商品数量是否有上下限；
  4. 编辑商品数量是否考虑库存情况；
  5. 商品链接能否自动跳转。
• 检查商品数量，金额，优惠明细
  1. 商品加入购物车内是否和原价格一致；
  2. 商品数量显示是否正确；
  3. 选择商品总数是否正确；
  4. 选中商品价格总额是否正确。
• 购物车与用户模块关联
  1. 未登录用户是否可以添加商品到购物车；
  2. 未登录用户添加商品到购物车，登录后是否将商品合并到用户购物车；
  3. 若不允许未登录用户添加商品到购物车，点击加购物车后是否有登录提示；
  4. 用户有会员折扣时，购物车内商品价格是否对应。
• 购物车与商品订单模块关联
  1. 加入购物车商品有价格调整，购物车内商品价格是否跟随变化；
  2. 加入购物车商品，库存变化时购物车是否有对应调整；
  3. 购物车商品确认订单后是否会从购物车清除；
  4. 订单价格是否与购物车内一致。
• 购物车与优惠活动模块关联
  1. 商家发放用户优惠券购物车对应变化；
  2. 商品满减活动，购物车价格对应变化。

7.2 性能测试

1. 进入购物车页面消耗时长；
2. 添加商品到购物车时长；
3. 进入购物车结算时长；
4. 对购物车页面内容变更，页面内容更新速度。（增加某个购买数量，页面对应显示更新速度）
5. 耗电量；
6. 消耗流量的多少；
7. 所占内存等。

7.3 界面测试

1. 界面的设计风格是否统一；
2. 界面中文字是否简洁，没有错别字。

7.4 安全性测试

1. 支付过程中是否有个人信息/密码丢失的风险；
2. 是否有金额被盗刷的风险。

7.5 兼容性测试

1. 苹果手机和安卓手机；
2. 苹果手机的不同版本；
3. 安卓手机不同的机型；
4. 网页版测试，五大浏览器；
5. 不同分辨率。

7.6 易用性测试

是否易操作，易学习，易理解

7.7 网络测试

1. 网络兼容性：2g/3g/4g，WiFi，热点，移动/联通/电信；
2. 无网测试；
3. 弱网：延时&丢包。

7.8 中断测试

前后台切换，网络异常，低电量，断电，来电，短信等

8. 如何设计微信红包测试用例？

微信红包测试用例

9. 如何设计手机开机键的测试用例？

9.1 功能测试

• 关机情况
  1. 长按是否正常开机；
  2. 单击是否可以开机；
  3. 双击是否可以开机。
• 开机情况
  1. 单点是否关闭屏幕；
  2. 双击是否关闭屏幕后重新打开；
  3. 长按是否关机；
  4. 来电时点击是否取消来电响铃；
  5. 打开APP后点击关机键是否息屏；
  6. 关机键+音量键组合使用是否有其他效果；
  7. 连续多次点击关机键是否有后台设置的sos效果；
  8. 充电时是否可以关机和开机。

9.2 性能测试

1. 息屏状态，短按开机键，检查屏幕点亮时间是否在需求时间内；
2. 亮屏状态，短按开机键，检查屏幕关闭时间是否在需求时间内；
3. 按下开机键，开机时间是否在需求时间内。

9.3 可靠性

连续点击n次，检查开机键寿命次数是否符合需求。

9.4 易用性

1. 开机键是否防滑；
2. 开机键是否容易被摸到；
3. 开机键是否容易按下；
4. 开机键位置是否合理，符合人体工学。

10. 如何设计微信账号密码登录界面测试用例？

10.1 功能测试

1. 输入正确的用户名和密码，点击提交按钮，验证是否能正确登录；
2. 输入错误的用户名或者密码,验证登录会失败，并且提示相应的错误信息；
3. 登录成功后能否能否跳转到正确的页面；
4. 检查能否选择不同登录方式进行登录，如使用手机号登录、使用微信号登录或扫码登录；
5. 记住用户名的功能；
6. 登陆失败后，不能记录密码的功能；
7. 密码是否非明文显示显示，使用星号圆点等符号代替；
8. 有验证码时，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色、刷新或换一个按钮是否好用；
9. 登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确；
10. 输入密码的时候，大写键盘开启的时候要有提示信息；
11. 什么都不输入，点击提交按钮，检查提示信息。

10.2 界面测试

1. 布局是否合理，testbox和按钮是否整齐；
2. testbox和按钮的长度，高度是否复合要求；
3. 界面的设计风格是否与UI的设计风格统一；
4. 界面中的文字简洁易懂，没有错别字。

10.3 性能测试

1. 打开登录页面，需要的时间是否在需求要求的时间内；
2. 输入正确的用户名和密码后，检查登录成功跳转到新页面的时间是否在需求要求的时间内；
3. 模拟大量用户同时登陆，检查一定压力下能否正常登陆跳转。

10.4 安全性测试

1. 登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)；
2. 用户名和密码是否通过加密的方式，发送给Web服务器；
3. 用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript 验证；
4. 用户名和密码的输入框，应该屏蔽SQL注入攻击；
5. 用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）；
6. 防止暴力破解，检测是否有错误登陆的次数限制；
7. 是否支持多用户在同一机器上登录；
8. 同一用户能否在多台机器上登录。

10.5 兼容性测试

1. 不同移动平台或PC环境下下能否显示正常且功能正常；
2. 同种平台下不同微信版本下能否显示正常且功能正常；
3. 不同的分辨率下显示是否正常。

10.6 本地化测试

不同语言环境下，页面是否跟随系统语言变化。

11. 说一说bug的生命周期和bug的类型

11.1 bug的生命周期

发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG

1、发现bug

1. 按照测试用例进行操作，发现和测试用例的预期结果不一致的,都可以被称之为Bug。
2. 测试用例不可能穷尽，总有超出你预料之外的因素,或者是神操作出现的bug。
3. 成本问题，没有充足的时间编写测试用例，发现的bug

2、提交bug

在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属性。Bug重现环境，bug类型，bug等级，bug的优先级以及详细的重现步骤，结果与期望等。当然，我们在提交一个问题之前首先应该保证，这个缺陷是没有被提过的，以免造成重复缺陷单。

3、指派bug

这一步不是必须的，跟项目模式有关，有些公司测试部门与开发部门独立，那么测试人员就不确定自己测试的模块是由哪位开发人员负责的，在这种情况下，测试人员统一把问题指派给项目组长或经理，由项目组长（或经理）对问题进行确认后再次分配给相应的开发人员。

有些测试人员是穿插到不同研发团队中的，所以对不同的开人发员负责的开发模块非常清楚，这个时候就可以将问题直接指派给相应的开发人员。也有一种情况，本来此问题应该由A开发人员负责，但由于A开发人员的调离或辞职，些问题为转交给其它人员处理。“分配”强调是上级对下级；“转交”强调的是平级之间。

4、确认缺陷

当开发人员接到一个缺陷时，首先是对其进行分析与重现，如果对其进行分析发现不是缺陷（可能由于测试人员不了解需求）或无法对此问题进行重现，那么就需要将此问题反回给测试人员，并注明原因。如果确认为缺陷则需要对其进行处理。

5、修复BUG

推迟处理
　　在处理问题之后，还需要进行一次判断，是否需要推迟处理，有些需求已经确认了是问题，由于其可能在极端情况下才会出现，或需要对系统架构进行改动，或其优先级非常低，所以暂时不需要对此问题进行处理（或到下个版本进再进行修复）。

固定
　　对于推迟处理的问题可以暂时进行固定（“固定”为QC中的叫法。）一般固定的问题需要经过项目经理与测试经理协商后才能固定。

处理缺陷
　　开发人员在确认完一个问题需要处理时，那么就对其进行处理工作。（例如，redmine 是支持处理人时时更新问题处理进度的，如 已处理30% ，已处理80% 等，当然，对于短时间内可以修复的问题就没必要时时的去更新处理进度。）

6、回归验证BUG

回归缺陷对于测试人员来说是非常重要的工作，其有三个入口两个出口。

　　确认非缺陷问题：对于提交的一个缺陷，开人员处理为非问题或无法重现，然后直接转交给测试人员回归。测试人员再次确认，如果真如开发人员所说，则将问题关闭。如果非开发人员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发人员。

　　确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则关闭问题。确认不通过，将问题再次打开并转给开发人员。

　　确认固定问题：有计划的对固定问题进行确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些固定问题依然存在且变得紧急，对于这类问题应该及时打开交给开发人员处理。

7、关闭缺陷

　对于已经修复的缺陷进行关闭，这也是一个缺陷的最后一个状态。

11.2 bug的类型

• 代码错误；
• 界面优化；
• 设计缺陷；
• 配置相关；
• 安装部署；
• 安全相关；
• 性能问题；
• 标准规范；
• 测试脚本。

12. 怎么编写测试用例？

1. 首先要先理解产品需求，严格按照需求文档来进行测试用例的编写；
2. 在编写用例过程中可以与产品或者开发沟通返讲需求，对遗漏的地方补充到测试用例；
3. 设计用例的时候可以参考以前类似的经验，或者测试用例设计常用的方法。如边界值，等价类，因果图，正交表等；
4. 按照实际的应用场景来编写,用自己以往的测试经验进行补充。

13. 如何设计微信朋友圈点赞测试用例

13.1 功能测试

1. 点击能否成功；
2. 取消点赞能否成功；
3. 点赞后通知对方；
4. 取消点赞不通知对方；
5. 取消点赞再点赞不通知该用户；
6. 点赞后显示头像；
7. 点赞后，共同好友都能看见点赞人；
8. 当前用户在单个人朋友圈点赞；
9. 当前用户在多个人点赞效果；
10. 当前用户的朋友被单个人点赞；
11. 当前用户的朋友被多个朋友点赞；
12. 点击点赞区的名字可以打开个人页面；
13. 点赞的先后时间排序；
14. 点赞后时效性测试三天可见。

13.2 界面测试

点击图标好不好看，什么颜色，什么形状，什么大小等。

13.3 接口测试

点赞后，当前用户响应情况，对方朋友响应情况。

13.4 性能测试

1. 能否点赞多次；
2. 点击响应时间情况；
3. 对方响应时间情况；
4. 点赞支持的最大点赞数；
5. 同一时间点赞用户。

13.5 安全测试

修改点赞的用户信息，篡改请求测试。

13.6 弱网测试

弱网情况下点赞是否实时更新。

13.7 中断测试

点赞有电话和短信干扰等情况。

13.8 兼容性测试

1. 不同的手机型号；
2. 不同的分辨率；
3. 不同的操作系统；
4. 不同的系统版本；
5. 不同的客户端同步情况。

14. 如何对一个杯子设计测试用例

14.1 功能测试

1. 水倒水杯容量的一半；
2. 水倒规定的安全线 ；
3. 水杯容量刻度与其他水杯一致；
4. 盖子拧紧水倒不出来；
5. 烫手验证。

14.2 性能测试

1. 使用最大次数或时间；
2. 掉地上不易损坏 ；
3. 盖子拧到什么程度水倒不出来；
4. 保温时间长 ；
5. 杯子的耐热性 ；
6. 杯子的耐寒性 ；
7. 长时间放置水不会漏；
8. 杯子上放置重物达到什么程度杯子会被损坏 。

14.3 界面测试

1. 外观完整、美观；
2. 大小与设计一样（高、宽、容量、直径）；
3. 拿着舒服；
4. 材质与设计一样；
5. 杯子上的图案掉落；
6. 图案遇水溶解。

14.4 安全测试

1. 杯子使用的材质毒或细菌的验证；
2. 高温材质释放毒性；
3. 低温材质释放毒性。

14.5 易用性

1. 倒水方便;
2. 喝水方便;
3. 携带方便;
4. 使用简单，容易操作;
5. 防滑措施 。

14.6 兼容性

杯子能够容纳果汁、白水、酒精、汽油等。

14.7 震动测试

杯子加包装（有填充物），六面震动，检查产品是否能应对铁路/公路/航空运输。

14.8 可移植性

杯子在不同地方、温度环境下都可以正常使用。

15. 如何设计微信支付测试用例？

微信支付测试用例

16. 如果页面点击一个按钮但是没反应，怎么排查这个问题？

首先进行抓包，观察请求数据，有以下几种可能：

1. 抓包时，点击关注按钮，没有发送关联请求，那么这个问题得反应给前端开发让他修改。
2. 发送了请求，但是请求的参数错误，也需要前端修改。
3. 请求数据都正确，但是后端返回的结果错误，或者报404等错误，得让后端进行排查。

16.1 怎么进行抓包？

通过WireShark工具进行抓包，就拿抓取ping命令举例：

1. 选择菜单栏上Capture -> Option，勾选WLAN网卡（这里需要根据各自电脑网卡使用情况选择，简单的办法可以看使用的IP对应的网卡）。点击Start。启动抓包。
2. wireshark启动后，wireshark处于抓包状态中。
3. 执行需要抓包的操作，如ping www.qq.com。
4. 操作完成后相关数据包就抓取到了。为避免其他无用的数据包影响分析，可以通过在过滤栏设置过滤条件进行数据包列表过滤，获取结果。比如：ip.addr == 185.199.111.153 and icmp表示只显示ICPM协议且源主机IP或者目的主机IP为185.199.111.153的数据包。说明：协议名称icmp要小写。

17. 项目实操测试

17.1 怎么进行压测？

1. 首先对要测试的系统进行分析，明确需要对那一部分做压力测试，比如秒杀，支付；
2. 如何对这些测试点进行施压？ 第一种方式可以通过写脚本产生压力机器人对服务器进行发包收报操作 ，第二种借助一些压力测试工具比如Jmeter；
3. 如何对这些测试点进行正确的施压？需要用压力测试工具或者其他方法录制脚本，模拟用户的操作；
4. 对测试点设计多大的压力比较合适？需要明确压力测试限制的数量，即用户并发量 ；
5. 测试结束后如何通过这些数据来定位性能问题？通过测试可以得到吞吐量，平均响应时间等数据，这个数据的背后是整个后台处理逻辑综合作用的结果，这时候就可以先关注系统的CPU，内存，然后对比吞吐量，平均响应时间达到瓶颈时这些数据的情况，然后就能确认性能问题是系统的哪一块造成的。

17.2 你项目的接口设置多少并发？

首先涉及到并发用户数可以从以下几个方面去做数据判断：

1. 系统用户数(注册用户数量)；
2. 在线用户数(平均每天大概有多少个用户要访问该系统，可以从系统日志从获得)；
3. 并发用户数(高峰期的时候的在线用户数量)。

三者之间的关系：

1. 在线用户数的预估可以采取20%的系统用户数。例如某个系统在系统用户数有1000，则同时在线用户数据有可能达到200，或者预估200做参考；
2. 在线用户数和并发用户数又存在着关系。即: 平均并发用户数为C=NUTL为在线时长，T为考核时长例如考核时长为1天，即8小时，但是用户平均在线时长为2小时，则c=n2/8，N为登录系统的用户数，L为登录的时长，例如一个系统有400个用户登录，然后每个用户登录大概停留2小时，则以一天8小时考核，算平均并发用户=400*2/8.

17.3 你们项目的吞吐量是多少？响应时间是多少？设置了多少并发？

• 登录模块：吞吐量大概在13.5/sec，响应时间<1s，设置的并发数180个并发数；
• 查询模块：吞吐量大概在36/sec，响应时间<3s，设置的并发数500个并发数；
• 下单模块：吞吐量大概在25.6/sec，响应时间<3s，设置的并发数350个并发。

17.4 项目有没有做过稳定性测试？具体怎么做？

稳定性测试主要就是看某个业务在高并发情况下是否能持续稳定运行嘛，当时大部分的核心业务都有做过稳定性的，这个需是把并发数设置为峰值，然后循环次数设置为永远。

另外要开启调度器，调度器中的持续时间设定为3600秒，让它持续压测1个小时。看下接口的各项性能指标的变化，是否在预期的指标范围之内。

17.5 讲一下你负责的一个具体模块，怎么测试？

讲支付测试或者搜索功能测试都可以。

18. 遇到过那些印象深刻的bug？怎么解决的？

翻页搜索组合场景下，清空搜索结果后默认页码设置为1的bug。

比如：翻页到第二页，使用搜索功能，然后清空关键字，此时应默认显示第二页的内容，页码为2，但实际情况是页码为1，但内容为第二页的。

随后进行接口测试出现bug的原因：

1. 数据错误，后台sql语句编写错误导致返回数据有误；
2. 未做权限处理，所有人都能随便请求数据；
3. 逻辑错误，导致返回数据与期望不一致或返回错误的错误信息；
4. 未做边界处理，超出边界未返回正确错误信息；
5. 并发问题，多个用户同时访问同一个接口可能导致数据混乱的问题；
6. 未对参数进行校验，导致返回数据出错。

19. 给你一个字符串判断是否为ip地址，并设计测试用例

19.1 判断字符串是否为ip地址

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

public static void main(String[] args){
    Scanner scanner = new Scanner(System.in);
    String ipStr = scanner.next();
    boolean isIpLegal = isIpLegal(ipStr);
    if(isIpLegal) {
    	System.out.println(ipStr + " 合法");
    }else{
    	System.out.println(ipStr + " 非法");
    }
}

public static boolean isIpLegal(String str){
    //检查ip是否为空
    if(str == null){
    	return false;
    }
    
    //检查ip长度，最短为：x.x.x.x(7位)，最长为：xxx.xxx.xxx.xxx(15位)
    if(str.length() < 7 || str.length() > 15){
    	return false;
    }

    //对输入字符串的首末字符判断，如果是"."则是非法IP
    if(str.charAt(0) == '.' || str.charAt(str.length()-1) == '.'){
    	return false;
    }

    //按"."分割字符串，并判断分割出来的个数，如果不是4个，则是非法IP
    String[] arr = str.split("\\.");
    if(arr.length != 4){
    	return false;
    }
    
    //对分割出来的每个字符串进行单独判断
    for(int i = 0; i < arr.length; i++){
        //如果每个字符串不是一位字符，且以'0'开头，则是非法的IP，如：01.002.03.004
        if(arr[i].length() > 1 && arr[i].charAt(0) == '0'){
        	return false;
    	}
        
        //对每个字符串的每个字符进行逐一判断，如果不是数字0-9，则是非法的IP
        for(int j = 0; j < arr[i].length(); j++){
        	if (arr[i].charAt(j) < '0' || arr[i].charAt(j) > '9'){
        		return false;
        	}
        }
    }
    
    //对拆分的每一个字符串进行转换成数字，并判断是否在0~255
    for(int i = 0; i < arr.length; i++){
        int temp = Integer.parseInt(arr[i]);
        if(i == 0){
       		if (temp < 1 || temp > 255){
        		return false;
        	}
        }else{
    		if(temp < 0 || temp > 255){
    			return false;
    		}
    	}
    }
    return true;
}

19.2 设计测试用例

等价类划分：

测试用例输入和输出：

20. 开放性问题

20.1 项目上线因为开发而推迟，测试时间被压缩该怎么办？

⾸先看下⾃⼰还剩下多少时间，然后要评估⼯作量，评估下⻛险，⽐如说，可能我根本做不完，⻛险太⼤，那么这个我⾸先要把⻛险提出来，给对应的领导，那么我会要求有⼈协助我完成，需要多少人力来完成；

如果只是说，正常时间完不成，那么我可以提下加班，看加班这个时间段能否完成，如果可以，我会和老大商量，提出加班计划。

如果是其他的，先跟领导确认，⽐如说我只需要把优先级⾼的⼯作完成其他⼯作可以安排到下⼀个版本去做,那么我就做个计划，把计划个老大说下。

20.2 项目上线后发现bug，该怎么处理？

当发现线上的 bug，项⽬组应快速响应处理，先积极配合开发重现 bug 定位问题;

如果是严重 bug，则需积极解决，更新版本；若 bug 不是那么严重，⼀般会放到下⼀个送代版本中处理。 然后，更重要的是经验总结，反思 bug出现的原因和规避⽅案。

总结⼀下常⻅的线上 bug 原因及规避⽅案:

1. 测试⽤例覆盖不全⾯，尤其⽤户不可控的使⽤场景，导致出现漏测。 解决⽅案：优化测试⽤例，增加⽤例评审。
2. 测试的时间不充分，导致⼀些次要功能点在测试的过程中被忽略。解决⽅案：规划充分的测试时间， 严格按照时间节点完成测试⼯作。
3. 测试的环境或者测试的数据受限，导致了测试不到位，解决⽅案：考虑 在真实环境下覆盖测试。
4. 开发⼈员修复其他问题时，引⼊了新 bug。解决⽅案：明确测试范围，尤其是代码修改的功能部分。 回归测试时，主流程必须回归，必须走⼀个完整流程。

20.3 开发人员说不是bug该怎么应对？

1. 详细描述问题，确认你与开发⼈员对问题的理解是⼀致的，避免双⽅争论不同的问题。
2. 附上需求⽂档需求描述。如果需求⽂档明确描述了需求点，在问题单预期结果处可以截图附上需求 ⽂档某处的需求要求，让开发与产品经理去确认。
3. 经验阐述。尽量阐述清楚你认为是问题的依据是什么，如果不解决该问题，⽤户侧可能会导致的后果。有理有据，如果开发还是不改，问题单给到产品经理，让产品经理决策。测试⼈员应该要坚持自己的⽴场，有⼀定的判断能⼒。
4. 建议性或低优先问题。有些问题如果是建议性或低优先的问题，修改与否不影响⽤户使⽤的。建议 性问题可以提成优化单给到产品经理，由产品经理决策并规划，低优先问题可经由多⽅确认后期迭代解决。