测试/测试开发八股——找大厂测试实习基础篇_测开 八股

第一部分：基础概念

1. 软件测试是什么？

在规定的条件下对一个产品或者程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
软件测试工程师的任务

2. 软件测试工程师的任务

软件测试工程师主要工作是检查软件是否有bug、是否具有稳定性，写出相应的测试计划、测试规范、测试用例、测试数据、测试报告，及时纠错及时更正，确保产品的正常运转。

3. 测试开发工程师的任务

测试开发的核心职能依然是测试。
只是工程师在具备测试经验、熟练使用测试工具并有一定开发能力的前提下，可以自主开发平台，或对现有的开源工具进行二次开发
最终目的是提升产品的测试效率。

4. 测试开发与开发的联系

测试开发是测试岗位衍生的一个分支，利用开发能力解决测试工作中的问题，
小到生成数据、并发模拟等工具的开发，大到整个自动化测试平台的设计与实现，
旨在提高效率，降低成本。

5. 你知道哪些测试方法？

黑盒测试（也称为功能测试）：把测试对象看成一个黑盒子，不需要了解其内部实现，只需要根据需求说明书来检查程序的功能是否满足它的功能说明。（UI自动化测试实现是一个黑盒测试，只是功能测试的案例变成了代码执行）
白盒测试：把测试对象当成一个透明的盒子，针对其代码内部实现进行测试。（一般是大企业 开发来搞）
灰盒测试：介于黑盒测试和白盒测试之间，需要了解一点业务+代码，比如自动化接口测试
单元测试：白盒测试的一种，对软件设计中的单元模块进行测试。
集成测试：在单元测试的基础上，对单元模块之间的连接和组装进行测试。
系统测试：在所有都考虑的情况下，对系统进行测试。
验收测试：第三方进行的确认软件满足需求的测试。
回归测试：开完修改完后，验证之前出现的问题是否还会在新版本中再次出现

6. 你理解的黑盒测试和白盒测试是什么？

黑盒测试常用方法并举例：

等价类划分法
等价类划分是将系统的输入域划分为若干部分，从每个部分选取代表性数据进行测试，一个理想的测试用例能独自发现一类错误。
边界值分析法
边界值分析法是对等价类划分的一种补充，通过优先选择不同等价类间的边界值覆盖有效等价类和无效等价类来更有效的进行测试，因此该方法要和等价类划分法结合使用。选取的测试数据应该刚好等于、刚刚小于和刚刚大于边界值（验证程序员的>= <=这种写的对不对）
判定表法
判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
错误分析法
错误推测法是基于以往的经验和直觉，参照以往的软件系统出现的错误，推测当前被测程序中可能存在的缺陷和错误。

白盒测试常用方法并举例：

强度由低到高：
语句覆盖：设计若干个测试用例，保证程序中的每一个执行语句至少执行一次，是”最弱的覆盖“，难以发现代码中的问题

判定覆盖（分支覆盖）：使得程序中每个判断的取真或取假至少经历一次。

条件覆盖：每个条件至少有一次真值或假值（不考虑组合情况）。

判定条件覆盖：包含判定覆盖和条件覆盖。说白了程序中每个判断的取真或取假至少经历一次（判定覆盖），同时每个条件至少有一次真值或假值（条件覆盖）。不难发现判定条件覆盖同时满足判定覆盖和条件覆盖，弥补了两者各自的不足，但是判定条件覆盖并未考虑条件的组合情况。

条件组合覆盖（组合覆盖）：每个条件的每种组合至少出现一次。显然，满足条件组合覆盖的测试用例一定是满足判定覆盖、条件覆盖和判定条件覆盖的。

路径覆盖：所有路径至少执行一次。

7. 软件测试的流程是什么？测试人员该从那个阶段进行介入？

需求分析阶段
测试人员会进行需求评审，对产品的功能进行整体把握，根据需求写用例
写测试计划
根据开发计划制定具体的测试时间和人员计划
撰写测试用例
根据详细的需求文档，进行用例的编写
使用思维导图列举测试大纲，尽量发散，想到什么就写什么。先放后收，对知识点进行总结和归纳，标记重点测试模块，删除冗余及重复测试点
可使用边界值法、等价类划分法、错误推测法、因果图法等设计案例
根据测试大纲制定测试用例，需包含模块名、测试优先级、操作步骤、期望结果、测试结果、备注
用例评审
测试作为主导，联合开发、项目经理、PM进行测试用例评审
可先讲解测试大纲，让开发、项目经理对测试用例有个大概后再详细测试用例讲解
执行测试用例
根据测试用例执行测试
发现问题保留现场，记录测试方法，通知开发解决问题
覆盖测试用例之外若有时间可进行探索性测试
缺陷报告编写及提交
将发现的缺陷编写成正式的缺陷报告，提交给开发人员进行缺陷的确认和修复
跟踪BUG修改情况
执行自动化测试，编写脚本，执行，分析，报告
进行性能测试，压力测试等其他测试，执行，分析，调优，报告

8. 什么是单元测试？什么是集成测试？什么是系统测试？什么是回归测试？什么是验收测试？

测试的相关流程：需求测试->概要设计测试->详细设计测试->单元测试->集成测试->系统测试->验收测试
单元测试：白盒测试的一种，对软件设计中的单元模块进行测试。
集成测试：黑盒和白盒结合，在单元测试的基础上，对单元模块之间的连接和组装进行测试。
系统测试：黑盒测试的一种，是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等是否满足其规约所指定的要求。
回归测试：是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。
验收测试：是部署软件之前的最后一个测试操作。目的是确保软件准备就绪，展示该系统满足用户的需求

9. 单元测试、集成测试、系统测试、验收测试、回归测试这几步最重要的是那一步？

我认为系统测试更重要
因为此时单元测试和集成测试已经完成，能够对软件所有功能进行功能测试，能够覆盖系统所有联合的部件，是针对整个产品系统进行的测试，能够验证系统是否满足了需求规格的定义，因此我认为系统测试很重要。

10. 测试用例设计的方法有哪些？

等价类划分法
边界值分析法
判定表法
错误推测法

11. Bug

Bug的周期？

提交->确认->分配->修复->验证->关闭

Bug的不同阶段？

1. New:(新的)
   当某个bug 被第一次发现的时候，测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来。并将bug的状态设为new
   2）Assigned(已指派的)
   当一个Bug被指认为New之后，将其反馈给开发人员，开发人员将确认这是否是一个Bug,如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为assigned
   3）Open 打开的
   一旦开发人员开始处理bug的时候，他就将这个bug的状态设置为Open,表示开发人员正在处理这个Bug
   4)Fixed 已修复的
   当开发人员进行处理（并认为已经解决）之后，他就可以将这个bug的状态设置为fixed并将其提交给开发组的负责人，然后开发组的负责人将这个Bug返还给测试组
   5）Pending Reset 待在测试的
   当bug被返还给测试组后，状态设为这个
   6）Reset 再测试
   测试组的负责人将Bug指定给某位测试人员进行再测试，并将Bug的状态设置为Reset
   7）closed 已关闭的
   如果测试人员经过再次测试之后确认bug已经被解决之后，就将状态设置为closed
   8）Reopen 再次打开的
   如果经过再次测试发现bug仍然存在的话（指bug本身而不是包括因修复而引发的新bug），测试人员将bug再次传递给开发组，并将bug的状态设置为Reopen
2. pending reject 拒绝中
   如果测试人员传递到开发组的bug 被开发人员认为是正常行为而不是Bug时，这种情况下开发人员可以拒绝，并将Bug的状态设置为pending reject
   10）rejected 被拒绝的
   测试组的负责人接到上述bug的时候，如果他发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作Bug的时候，开发组负责人就将这个Bug的状态设置为rejected
   11）postponed 延期
   对于一些特殊的Bug的测试需要搁置一段时间，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，Bug的状态就被设置为postponed

Bug类型

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

缺陷报告里包含哪些内容？

ID
测试时间
系统环境
硬件环境
缺陷严重程度
软件版本
确认人
功能模块
问题描述 发现缺陷的详细步骤 是否会复现

怎样提交一个高质量的缺陷：

1）缺陷的标题尽量简单、明确、完整
2）尽量使用惯用的表达术语和表达方法，保证表达准确专业
3）一个缺陷报告只包括一个缺陷，复现步骤描述清楚
4）是UI问题的话，尽量配上截图标注好有问题的地方；功能问题，尽量配上视频；闪退一类的Bug配上Log日志等
5）一些特殊数据出现的bug,需要备注好数据信息
6）一些非必现的问题，多测试几遍，然后备注清楚bug的复现率
7）兼容性问题需要备注好设备型号、操作系统及浏览器版本信息
8）缺陷尽量保证不重复提交

12. 你认为软件测试的核心竞争力是什么？

测试用例设计能力、快速学习的能力、探索式测试思维、缺陷分析能力、自动化测试技术
测试人员的核心竞争力在于提早发现问题，并能够发现别人无法发现的问题。
①早发现问题：问题发现的越早，解决的成本越低。
②发现别人发现不了的问题。

13. 从那几个方面对一个新的产品进行测试？

UI界面、易用性、兼容性、功能测试、接口测试、弱网测试、性能测试、安全测试

14. 为什么选择测试开发

【岗位角度来说】
从用户角度来说，现在的软件产品种类多样，已经可以满足用户大部分的基本需求了，对于同类产品，用户会更加关注产品的质量和服务，所以测试的发展前景是非常好的。在产品研发中，提前发现和定位问题，对整个产品和质量和公司的成本都是非常重要的，测试人员的责任非常大，是非常重要的一个岗位。

【自己角度来说】(你的经历都是开发为什么会想到做测试？)
测开还有一部分开发工作，无论是自动化脚本还是测试工具或框架，都提高了测试的效率。所以测开的所需技术广度也是很高，会激发我持续学习的态度。
并且，我目前具备了一些测开所必备的理论知识和技能，并且还在不断地学习中，我认为我可以较快的胜任这个岗位

15. 测试开发需要哪些知识和能力？

需要的知识：

软件测试基础理论知识，如黑盒测试、白盒测试等
编程语言基础，如C/C ++、java、python等
计算机基础知识，如数据库、Linux、计算机网络等
自动化测试工具，如Selenium、Appium、Robotium等
测试框架，如JUnit等

需要具备的能力：

测试能力
业务分析能力，分析被测系统架构、分析被测业务模块、分析整体业务流程、分析被测业务数据、分析测试所需资源、分析测试完成目标；
缺陷洞察能力，一般缺陷的发现能力、隐形问题的发现能力、发现连带问题的能力、发现问题隐患的能力、尽早发现问题的能力、发现问题根源的能力；
宏观把控能力，有效制定测试计划、有效进行风险评估、有效控制测试时间、有效控制测试成本、有效控制测试方向。
个人能力
专业技术能力，掌握测试基础知识、掌握计算机知识、熟练运用测试工具；
逻辑思考能力，判断逻辑的正确性、对可行性逻辑分析、站在客观角度思考
问题解决能力，技术上的问题、工作中的问题、沟通问题
团队能力
沟通表达能力，和技术人员、产品人员、上下级的沟通
团队协作能力，合理进行人员分工、协助组原解决问题、配合完成测试任务、配合开发重现缺陷、督促项目整体进度、出现问题勇于承担

第二部分：性能测试

1. 什么是性能？

时间：系统处理用户请求的响应时间
资源：系统运行过程中，系统资源的消耗情况

2. 什么是性能测试？

使用自动化工具，模拟不同场景，对软件各项性能指标进行测试和评估的过程。

3. 功能测试和性能测试有什么区别？

功能测试：验证系统的功能。（功能的正向、逆向）
性能测试：验证系统的业务需求场景。（时间、资源）

4. 性能测试的分类

基准测试：建立基准线，当代系统的软硬环境发生变化之后再进行一次基准测试以确定变化对性能的影响。
负载测试：
概念：通过不断逐步增加系统负载，确定在满足系统的性能指标情况下，找出系统所能承受的最大负载量的测试。
作用：系统最大负载量达到用户要求时，系统才能正式上线使用。
压力测试：在强负载下的测试，查看系统在峰值情况下是否有功能隐患、系统是否具有良好的容错能力和恢复能力。
稳定性测试：在服务器稳定运行（用户正常的业务负载下）的情况下进行长时间测试（1天~一周等），并保证服务器能够满足线上业务需求。
并发测试：指在极短的时间内，发送多个请求，来验证服务器对并发的处理能力（响应时间、吞吐量和资源利用率等）。

5. 性能测试的完整流程

和功能测试不同。
分为五个阶段：1.需求调研，2.测试准备，3.测试执行，4.测试报告，5.测试总结
需求调研——做需求调研和分析，产出文档：性能测试需求表、性能测试计划表；
测试准备——构建测试模型，设计测试方案，压测环境、数据的准备、脚本开发，产出文档：测试用例、测试方案
测试执行——执行压测，记录执行过程和结果，对结果做分析，产出文档：性能测试日志
测试报告——测试报告，发现的性能瓶颈，性能测试结论(是否达标)
测试总结——总结和复盘

6. 评估和确定性能测试指标

响应时间（Response Time，RT）：处理一个请求所需要的时间。
在网络状态良好的情况下，网页打开时间一般要求在3s内；普通接口的响应时间在500ms内。

并发数：网站系统在同一时间需要处理的请求数，包括正在处理的请求和处于等待的请求。

吞吐量：网站系统在一段时间（每秒）处理请求的数量，常见单位TPS、RPS、QPS。
RPS、QPS都是每秒处理的请求数量；TPS是每秒处理的事务数。
以一个购物行为为例，假设用户的操作需要3步：查看商品列表-查看商品详情-下单商品，那么整个购买行为是1个事务 3次请求，理论上TPS是RPS的1/3。

TPS：Transaction Per Second，服务器每秒处理事务数。
RPS：Request Per Second，发起方（用户）的每秒请求数。
QPS：Query Per Second，服务器每秒查询率，服务器的查询率。
计算方式：吞吐量 = 并发数/平均响应时间。

错误率：一段时间的请求错误率。0.5%以下即可

以上4个性能指标任意一个单拿出来都不能描述系统性能，只有4个性能指标结合才能描述系统性能

7. 性能压力测试流程

①确定需求，性能场景分析与创建
②计划和方案
人员、场景、指标，模型简历、环境（等比缩放），风险等
③搭建环境，压测脚本编写及调试
④执行阶段
⑤输出测试报告
⑥总结

目标是什么？
新系统：测最大容量
旧系统：性能没有下降，在有限的资源里把性能进行调优

8. Jmeter

JMeter是Apache组织开发的基于Java的开源软件
常用于对系统做接口功能测试和接口性能测试

8.1 Jmeter怎么做接口测试？

首先，做接口测试的流程是根据开发提供的接口文档来编写接口测试用例，根据用例使用Jmeter来进行测试。
Jmeter做接口测试，需要添加线程组、http请求，然后在http请求中设置好地址、参数以及要添加的请求头信息，之后再添加查看结果树用来查看响应结果。对比接口测试用例中的预期结果是否一致，同步检查数据库确认接口是否通过，涉及到的批量测试会使用csv配置元件来读取数据；

8.2 Jmeter如何测试接口的关联？

接口关联使用Jmeter的后置处理器，主要是JSON提取器和正则表达式提取器。比如我们获取token，会将提取到的token值赋值给一个变量，在下一个接口调用此变量即可。

Jmeter入门核心步骤？
①添加线程组
②添加HTTP请求
③添加查看结果树

8.3 Jmeter进行压测流程

①设置测试参数：

线程数：根据实际需求设定总共有多少个线程参与压测。
Ramp-Up Period：多少秒启动完所有线程。
循环次数：定义要执行的循环次数。
调度器：如果选中了这个选项，需要在配置中进行相关设置。

②判断压测机可运行的线程数
通过逐步增加线程数，观察压测机CPU的使用情况，以及JMeter的响应时间。当发现CPU稳定且响应时间随线程数增加而增大时，此时所设置的线程数为压测机能承受的最大线程数。
③开始压测
按照计划进行压测，可以选择使用多进程（多个JMeter实例）逐步加压，并观察服务器性能是否符合预期。
④配置主控机和远程服务器：
将主控机的IP地址添加到远程服务器配置中。
设置JMeter服务器是否使用SSL加密。
在主控机上启动JMeter服务器，并将远程服务器加入其集群。
⑤启动测试：
在主控机上运行JMeter，并通过“远程测试”功能发送测试计划到远程服务器。
⑥查看测试结果：
使用JMeter监听器实时监控测试过程和结果。
测试结束后，可以通过导出结果文件或查看聚合报告来获取详细测试结果。
⑦分析测试结果：
根据生成的测试报告，分析测试过程中的各项指标，如响应时间、吞吐量、错误率和成功率等。

8.4 Jmeter和postman

我接触到的：
①用例组织方式不同
jmeter组织方式相对比较扁平，没有工作空间的概念，直接就是测试计划，一个测试计划对应一个测试用例
postman组织方式会比较轻量级，主要是针对单个的HTTP请求
②jmeter支持中文界面 postman是英文界面
③jmeter会更强大，除了做功能测试，还可以做性能测试；postman主要是功能测试
④postman不能连接数据库 jmeter可以连接数据库进行数据验证

9. 压测对象

压测对象

第二部分：用例设计

面试官一般会这么问，说你最熟悉的一个APP，比如你说微信，他就提问微信相关的测试用例~
回答思路：
万能公式：UI界面、易用性、兼容性、功能测试、接口测试、弱网测试、性能测试、安全测试

UI界面：界面布局、排版是否符合设计师或产品需求：文字，图标大小。比如点赞的按钮位置、点赞人的名称、点赞红星图标、点赞个数
易用性：操作简单，操作是否有友好提示，如果是输入框（是否支持TAB、ENTER等快捷键），比如：点赞后有提示、点赞流程简单、点赞入口
兼容性：不同手机、浏览器、操作系统版本、软件版本、分辨率，显示正常且功能正常，比如：平板、小米、华为、微信客户端
功能测试：常见+流程（用户可能执行的操作，业务流程）+增删改查+排序，比如：点赞成功，取消点赞、点赞后是否看到共同好友、删除朋友圈、点赞的排序
接口测试：接口正常调用，返回报文正常。比如：点赞接口调用、参数（后端）
弱网测试：断网、网络信号差，操作的时候来电话，3G/4F网络切换，比如：打电话的时候点赞、断网点赞
性能测试：使用该功能的响应时间是否在需求规定的时间，多次快速操作。比如：点赞到显示点赞的响应时间、点赞后好友消息更新的速度、同时点赞、多次点赞
安全测试：客户端和服务端都需要验证（不能单单是在客户端验证），设计手机号、身份证、银行卡、密码等敏感信息是否加密，比如点赞是否泄漏用户信息。
总结：
①没有需求文档或者需求不完整的情况下如何进行测试？
②能不能把测试用例方法应用到实际工作中去？
③测试思维是否完整？应变能力如何？表达能力如何？

以百度搜索为例，设计测试方案
对这个上传文件进行测试用例设计
对微信扫码进行测试用例设计
对登录页面进行测试用例设计
微信红包测试
微信朋友圈测试
电梯进行测试用例设计
淘宝购物车设计测试用例
对直播间设计测试用例
对微信发消息设计测试用例
对滴滴打车设计测试用例
对三角形的三边设计测试用例
对浏览器白屏设计测试用例
如何测试网站的高并发？

1. 测试用例的组成元素

内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等

2. 测试用例主要包含四个内容：

用例标题-主要描述测试某项功能；
前置条件-用例标题需要满足该条件
测试步骤-描述用例的操作步骤
预期结果-符合预期需求（开发规格书、需求文档、用户需求等）

3. 如何写测试用例

①测试人员尽早介入，彻底理解清楚需求，这个是写好测试用例的基础
②如果以前有类似的需求，可以参考类似需求的测试用例，然后还需要看类似需求的bug情况
③清楚输入、输出的各种可能性，以及各种输入的之间的关联关系，理解清楚需求的执行逻辑，通过等价类、边界值、判定表等方法找出大部分用例
④找到需求相关的一些特性，补充测试用例
⑤根据自己的经验分析遗漏的测试场景
⑥多总结类似功能点的测试点，才能够写出质量越来越高的测试用例
⑦书写格式一定要清晰(测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果)

4. 常见的输入框异常用例，包括一些异常的触发条件

4.1 微信红包设计

单个红包的功能上：
发送方：
输入红包金额：红包金额为0、0.01 200.00 200.01 199.99 20
输入留言：留言输入数字、字母、汉字、特殊字符；留言长度；留言复制粘贴
选择表情：表情-选择收藏的表情、其他表情； 删除表情、选择新的表情
选择红包封面：封面选择
选择支付方法：（零钱、零钱通、银行卡、添加新卡支付）判断里面钱数与红包钱数的关系；使用指纹、面部识别、密码支付（正确输入、错误输入的情况）
钱财金额：红包发送成功后，钱包金额减少对应数值

接收方：
接收方收到红包：接受者对红包封面、留言、表情、金额均能正确了解
接收方的金额：被领取后显示已领取，领取者钱包增加相应金额，再次点开红包只能显示红包信息
只有接收方可以点开：发送方点开不能领取，只显示相关信息
未领取：24小时后未领取显示退回，钱包金额增加，对方不能再领取

群发红包功能：
红包个数：红包个数为空、0、001、100、99、101
红包金额：红包拆开每个金额一样，均为发红包时设置的单个金额对应的钱数
红包被拆提示：红包被拆时，有相应提示
退回：红包24小时内未被拆完，剩余钱被退回，相应支付方式中钱数增加
群发红包-拼手气红包功能
每个人拆开数额不同，总金额等于红包总额；24小时内领完显示最佳手气，否则不显示

兼容性测试：
测试安卓、ios不同型号收集

UI测试：显示无错误，风格样式统一
中断测试：不同应用间切换、没电、没网、来电话、短信

网络测试：2g、3g、4g、5g、wifi、移动联通电信、弱网、没网

4.2 用户登录过程需要做哪些分析？

功能测试：
输入用户名和密码：
用户名和密码，太短或太长的处理（边界值法）
用户名和密码，有特殊字符(比如空格)及其他非英文的情况
记住用户名，记住密码
登录失败后，不记录密码
用户名和密码前后有空格的处理
密码是否是密文显示，使用*号或圆点等符号代替
验证码的辨认难度，考虑颜色（色盲使用者），刷新或换一个按钮是否好用
输入密码时，大写键盘开启时是否有提示信息
什么都不输入，点击提交按钮，检查提示信息、
登录流程：
正常流程（正确账号密码，点击提交，验证能否正确登录）
异常流程（错误的账号密码，点击提交，验证登录失败，并提示相应错误信息）
登录成功后能否正确跳转
登录token测试

界面测试：
布局是否合理，按钮和表单是否整齐
按钮和表单高度和长度是否符合要求
界面风格是否符合UI设计稿
文字有无错别字

性能测试：
打开登录界面，需要的时间是否在需求要求的时间内
输入正确的账号密码，点击登录，是否在需求时间内跳转成功
模拟大量用户同时登录，检查一定压力下能否正常跳转

安全性测试：
用户名或密码是否通过加密方式，发送给后端服务器
用户名和密码应该在前端和后端做双重验证
用户名和密码的输入框，应该屏蔽SQL注入攻击
用户名和密码的输入框，应该禁止输入脚本（防止XSS攻击）
防止暴力破解，检测是否有错误登录的次数限制
是否支持多用户在同一机器上登录
同一用户能否在多台机器上登录

可用性测试：
是否可以用全键盘操作，是否有快捷键
输入用户名，密码后按回车，是否可以登录
输入框是否可以Tab切换

兼容性测试：
不同浏览器下能否显示正常，且功能正常
同种浏览器下不同版本能否显示正常且功能正常
不同的操作系统是否能正常工作
移动设备上是否正常工作

4.3 如何对短视频APP(抖音)进行测试

功能测试：
刷抖音：
视频清晰度
视频暂停、播放功能
视频信息（标题、描述、音乐、标签）
点赞数、双击点赞功能
评论功能（评论数、查看评论、发表评论）
分享转发
同款音乐
用户个人主页
搜索测试（热搜、话题功能）
拍抖音
调起摄像头
视频拍摄、本地视频
视频剪辑功能测试
选择音乐功能测试
道具、表情、滤镜
发布短视频测试
商业化
广告植入（跳过广告）
抖音商城

性能测试：
视频质量（码流、帧率、不卡帧）
网络测试（wifi/5G/4G/3G/弱网、断网）
服务器负载测试
服务器压力测试
长时间运行
耗电量
内存是否泄漏
CPU状况

安全测试：
视频链接加密
视频防止去水印
视频反爬
异常测试

弱网、断网等异常测试
码率切换测试
破坏性点击（疯狂点赞、取消点赞）
切换前后台
兼容性测试

移动端系统兼容性
应用权限测试
安装、卸载测试

4.4 如何对聊天系统（偏客服系统）进行测试

功能测试：
用户端：
登陆状态下正常发送消息
未登录状态下发送消息，会提示去登陆
输入框发消息测试（过长、过短、表情、图片、视频、语音、英文、数字、url、卡片、红包、位置等）
接收消息测试
消息顺序（不乱序、不重复、不错误、不丢失）
历史消息
未读消息提醒（小红点显示隐藏、未读消息数）
用户头像点击
自动回复选项点击
长按消息（复制/转发/删除/撤回/引用）
一键跳转到最新消息
客服端：
正常回复消息
输入框发消息测试（过长、过短、表情、图片、视频、语音、英文、数字、url、卡片、红包、位置等）
接收消息测试
消息顺序（不乱序、不重复、不错误、不丢失）
历史消息
未读消息提醒
自动回复设置
用户头像点击，用户信息采集
长按消息（复制/转发/删除/撤回/引用）
一键跳转到最新消息
消息群发（有可能也没有此功能）
接口测试：
发送消息接口(msg_type/msg_content/埋点测试/extra_content)
RPC接口调用
消息队列（排序、队列长度、数据格式）
性能测试：
模拟多用户同时向单用户发送消息
模拟单用户同时向多用户发送消息
1s内发送多条消息
同一聊天室内，1s内接收多条消息，端上应有消息延迟展示策略
兼容性测试：
跨平台跨系统登陆接收消息并展示
多端登陆同一个账号，接收别人发来的消息（若支持多端登录）
多端登录同一个账号，一端发送消息，自己的消息在别的端的展示情况（若支持多端登录）
异常测试：
断网/弱网情况下发送消息
输入框输入sql、脚本等

4.5 如何对长视频APP（优酷）进行测试

1.功能测试：
视频能够正常播放
会员特权（购买、有效期、行使特权）
播放组件（点播播放器、直播播放器、缓存视频播放器）
视频清晰度转换（手动、自动）
全屏/缩放； 横屏/竖屏；锁屏
播放/暂停/下一集
进度条（快进、快退、锚点播放）
亮度
声音
弹幕
缓存
投屏
选集
倍速
断点续播
视频水印
返回键
分享/收藏
睡眠模式
商业化（广告）
片前广告/片中广告/片尾广告
暂停广告弹窗
VIP跳过广告
广告倒计时自动关闭

2.性能测试
清晰度测试（4K、蓝光、超清、高清、标清、流畅），测试固定码率播放以及切换码率播放
负载测试（最大同时拉流数）
网络测试（wifi/5G /4G/3G/弱网、断网）
首屏加载时间
长时间运行
耗电量
内存泄漏
CPU状况
是否有丢帧

3.安全测试：
视频流地址加密
会员接口不对外暴露
防止去广告脚本攻击
缓存视频加密

4.异常测试：
弱网、断网等异常测试
码率切换测试
频繁切换前后台

5.兼容性测试
移动端兼容性
PC端兼容性
浏览器兼容性
TV端

4.6 如何对列表页（贝壳找房）进行测试

功能测试：
列表排序
列表翻页
列表筛选
列表少结果、无结果、多结果的页面展示
检索系统、推荐系统、商业化（广告）测试
回到顶端浮标
列表卡片跳转
列表卡片UI展示（价格、标题、描述、标签等）
上滑加载更多
下拉刷新列表
其他（浮标按钮等）

性能测试：
压力测试
负载测试
大数据量返回的表现（一般后端会做翻页）
页面响应时间测试

兼容性：
浏览器兼容性
PC端操作系统兼容性
移动端操作系统兼容性
弱网/无网显示

埋点测试：
曝光埋点
点击埋点
PV/uv统计

4.7 如何对搜索框（贝壳找房）进行测试

功能测试：
输入关键字，查看返回结果是否准确
查询有结果的显示
查询无结果的显示
查询少结果的显示
输入框测试：输入特殊内容，过长/过短的关键词，关键词输入
正常：楼盘、地区、街道、公司、城市、地铁沿线、商圈等关键词
异常：空格及其他特殊字符、代码等。
热门关键词搜索测试（需要结合CMS后台测试）
sug动态搜索测试
商业化（广告）相关测试
搜索出来的楼盘结果列表：排序、翻页、是否列表去重
搜索历史功能测试
检索系统和推荐系统的测试
结果跳转（跳转到详情页、跳转到列表页）

性能测试：
sug耗时
点击搜索结果，渲染结果列表耗时
压力测试，不同用户数压力下的表现
负载测试，看极限能承受多大的用户量同时正常使用
大数据量返回的表现

易用性：
功能是否易用，输入法调起是否正常，按钮可点击区域是否满足易用性
针对不同，是否有友好的提醒
搜索结果的楼盘卡片是否显示合理（价格、标题、描述等）
搜索结果是否准确，排序是否合理
控件设计是否符合APP整体设计风格

兼容性：
浏览器兼容性
PC端操作系统兼容性
移动端操作系统兼容性
杀毒软件、防火墙、不同输入法等工具共同使用，是否适配

安全性：
表单不允许被SQL注入（录入一些数据库查询的保留字符，如单引号，%等）
是否有反爬策略
是否有黄反策略或对涉及国家安全、法律禁止的内容是否进行过滤和控制

4.8 测试一瓶矿泉水

功能测试：
水瓶漏不漏、瓶中的水能不能被喝到
界面测试：
外观是否没管
安全性：
瓶子的材质有没有毒或者细菌
可靠性：
从不同高度落下的损坏程度
可移植性：
在不同的地方、温度等环境下是否都可以正常使用
兼容性：
是否能够容纳果汁、白水、酒精、汽油等
易用性：
是否烫手、是否有防滑措施，是否方便饮用
用户文档：
使用手册是否对用法、限制、使用条件等有详细描述
疲劳测试：
将盛上水放24小时检查泄漏时间和情况；盛上汽油放24小时检查泄漏时间和情况等
压力测试：
用根针并在针上面不断加重量，看压强多大时会穿透
跌落测试：
测试在何种高度跌落会破坏水瓶

4.9 测试朋友圈点赞功能

功能测试：
是否可以正常点赞和取消
点赞的人是否在可见分组里
点赞状态是否能即时更新显示
点赞状态，共同好友是否可见
点赞显示的是否正确，一行几个
点赞是否按时间进行排序，头像对应的是否正确
是否能在消息列表中显示点赞人的昵称

接口测试：
点赞朋友圈，验证朋友能否收到提示消息

性能测试：
点赞朋友圈，是否在规定时间显示结果，是否在规定时间在朋友手机上进行提示

兼容性测试：
在不同的终端上点赞，验证是否成功

5. 答题角度总结

日常物品

功能测试：等价类划分+边界值分析。
外观测试：外观完整、美观；尺寸大小/材质；外部说明清晰；舒适度
性能测试：使用寿命、响应时间、长时间使用情况、负载情况、压力情况
安全测试：材质毒性
兼容测试：
易用测试：使用方便、携带方便、操作简单、防护措施
异常测试：耐破坏性、异常情况的响应、应急情况
可维护性：配件更换、维修、拆除

文本框/登录/聊天/查找类

功能测试：太短/太长(边界值分析)/特殊字符/输入为空、正常流程、异常流程、选中、复制粘贴、光标位置
性能测试：响应时间、压力测试、负载测试、单人聊天、多人聊天
易用/界面：输入法调起、按钮点击区域、提醒到位、搜索结果、展示结果是否合理、设计风格、快捷键
兼容性：浏览器、PC端、移动端、杀毒软件、防火墙、不同输入法、不同版本、
安全性：异常测试（弱网、断网）、反爬策略、内容审核、不允许SQL注入、加密传输、防止暴力破解、多端登录

支付交易类

功能测试：支付方式、余额充足或不足、密码输入正确或错误、验证码、金额校验(空值、负值、最小金额、最大金额、消费上限)、取消支付
性能测试：页面跳转时间、耗电量和流量、更换支付方式响应时间、并发情况下、多端登录
外观测试：页面美观、布局合理、信息提示正确、字体清晰
安全测试：密码暗纹、支付金额过大、对面账户异常、新设备授权、
易用测试：操作简单快捷、提示信息到位
兼容性测试：不同系统、不同版本、不同网络、不同浏览器、
异常测试：断网、弱网、关机、刷新页面、退出程序

人工智能类

功能测试：不说话/声音小/错别字/文字长度限制/语音时间限制/不同语言/不同物种语音/多语音/敏感词处理/断句功能/识别数字
性能测试：响应时间、耗电量、资源占用
外观测试：界面设计、布局合理、信息提示正确
易用测试：操作简单快捷、提示信息到位
兼容性测试：不同系统、不同版本、不同网络、不同浏览器
异常测试：断网、弱网发送顺序、关机

视频类

功能测试：清晰度、暂停播放、视频信息、互动功能、分享转发、个人主页、广告植入、会员特权、播放组件（弹幕、进度条、声音、投屏、小屏幕、）断点续播
性能测试：负载测试、压力测试、资源消耗、视频质量（帧率、码流）
安全测试：视频链接加密、反爬、防止去水印、脚本攻击
异常测试：弱网、断网、码率切换测试、破坏性点击、切换前后台
兼容性测试：不同设备、不同网络、不同操作系统