面试QA整理(9)——测试开发相关知识
Welcome to xpt’s blog! 2021年准备秋招期间整理的一些笔记，分享给大家！
文档分享的初衷是给师弟师妹们作为参考，主要是适合想去大厂+测试开发岗的朋友们。
建议大家自己整理文档，把我的文档作为参考，有些东西自己整理，自己去写出来，才是最适合你自己的！
文章还未精细整理，如存在错误之处，可以邮件or微信反馈给我呀，感激不尽！
想进大厂，要抓住提前批免笔试的机会！（例如京东、字节、百度等报名时间一般为七月，面试时间为报名后的一周内，面试一般为3轮，面试相关经验后续我会单独再写blog分享^_^，也欢迎大家来跟我talk，一定知无不言。）
本人情况：普通211、研究生、有京东、百度、以及字节提前批测开岗offer。7月初开始准备，准备太迟，一边准备一边投简历+面试。
- 投递简历时间：京东（7.14），字节（7.30），百度（7.30）
- 三轮面试时间：京东（7.21-7.22-7.26），字节（8.4-8.6-8.9），百度（8.9-8.12-8.16）
- 意向书时间：京东（8.12），字节（8.16），百度（9.9）
京东提前批开始很早，我投的时候已经是第二批。经过京东几轮面试，熟悉了面试流程，大概掌握了测开岗会问些什么问题。
字节和百度提前批我是在ddl前一天投递，其实已经算很迟了，hc不多了。
投递要趁早，很多岗位有固定hc。
多拿offer，才有谈薪资的底气。
我面试的岗位有以下：
1、测试开发岗（京东、百度、以及字节提前批）
2、银行java开发岗（所以我会整理一点java，银行问的都很简单，所以我这里对java的整理比较少）
整理的内容均来源于历年网络上分享的面经（主要来源于牛客），以及我面试时被问过的问题，list如下：
(1)——计算机网络
(2)——操作系统
(3)——数据库
(4)——数据结构
(5)——python
(6)——java
(7)——linux
(8)——常考编程题
(9)——测试开发相关知识
面试QA整理(9)——测试开发相关知识
测试流程—-软件生命周期 （六个阶段:计划/需求/设计/编码/测试/运行与维护)
软件生命周期的六个阶段：
计划阶段（planning）-〉需求分析（requirement）-〉软件设计阶段（design）-〉编码（coding）->测试（testing）->运行与维护（running maintrnacne）（集成-实施-交付）
测试里面还可以细分：单元测试、集成测试、系统测试、验收测试(Alpha、Beta)、回归测试
一、问题定义及规划阶段
主要确定软件的开发目的及其可行性，制定开发计划
此轮是软件开发人员和需求方之间的探讨，以此确认软件开发目标和可行性。
二、需求分析/评审阶段
分析来源（原型图/软件需求说明书）、参与人员（主持–产品经理，其他参与、研发、设计、测试）、关注一个问题–测试参与这个需求分析的目的是什么？（知己知彼、方便提出疑问）
在确定软件开发可行的情况下，将对软件需要实现的每个功能进行详细分析。
需求分析阶段是非常重要的阶段。这个阶段做得很好，将为整个软件开发项目的成功奠定良好的基础。
三、软件设计阶段（属性：属于开发的工作）
在此阶段，将根据需求分析的结果来设计整个软件系统，例如系统框架设计，数据库设计等。软件设计一般分为总体设计和详细设计。
总体设计：总体架构 、、、概要设计（数据库 表 等框架性的东西）
详细设计(LLD)：每个模块的设计、、、、、、详细设计（伪代码级别）
四、软件编码阶段
开发人员任务、程序员编码
五、软件测试阶段
测试工程师的任务或开发的任务
开发：单元测试、
开发or测试：集成测试—接口测试
测试人员：系统测试、
客户or产品经理：验收测试—Alpha测试、Beta测试
六、软件运行维护阶段
版本、产品上线（版本的升级改进）BUG的修复
单元测试、集成测试、系统测试、验收测试(Alpha、Beta)、回归测试
链接：https://www.nowcoder.com/questionTerminal/edeb39cdb48346f780b2b8cc99e48059
来源：牛客网
请你分别介绍一下单元测试、集成测试、系统测试、验收测试、回归测试
单元测试：单元测试就是最初的白盒测试，测试编码是否符合设计要求。软件中最小的测试单元，比如java中的一个方法。相关单元测试放在一起就是一个模块。
集成测试：集成测试就是接口测试，对接口是否能够实现进行测试，对接口实现后的结果进行测试。通过测试发现与模块接口有关的问题。在单元测试的基础上将所有模块按照要求设计组装。测试不同模块之间是否按照预期工作，比如不同模块之间的数据传输。
系统测试：系统测试就是对可视化图形界面测试。对整个系统功能进行测。是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。
验收测试：验收测试就是模拟客户进行测试。确保软件各部分功能正常运行。确定产品是否能够满足合同或用户所规定需求的测试。验收测试包括Alpha测试和Beta测试。
回归测试：在缺陷修复之后的检验测试，回归测试，是软件维护阶段对软件修改后进行的测试，指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误
https://blog.csdn.net/qq_42434318/article/details/109099271
单元测试
完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确的编码，使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误，通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。
集成测试
通过测试发现与模块接口有关的问题。目标是把通过了单元测试的模块拿来，构造一个在设计中所述的程序结构，应当避免一次性的集成（除非软件规模很小），而采用增量集成。
自顶向下集成：模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。
自底向上集成：从原子模块开始来进行构造和测试，因为模块是自底向上集成的，进行时要求所有隶属于某个给顶层次的模块总是存在的，也不再有使用稳定测试桩的必要。
系统测试
是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。
回归测试
回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。根据修复好了的缺陷再重新进行测试。回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。
回归测试，是软件维护阶段对软件修改后进行的测试，指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误
验收测试
验收测试是指系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。验收测试包括Alpha测试和Beta测试。
Alpha测试
是由用户在开发者的场所来进行的，在一个受控的环境中进行。
例如游戏的删档内测，Alpha测试不是面对所有的用户，而是针对公司内部员工进行游戏试玩，来检测是否存在一些bug，然后反馈错误给开发去修复。
Beta测试
它不是受控活动，因为它发生在用户身边。在将软件交付给客户之前，它视为最终测试。发布用于beta测试的软件称为测试版软件。
由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件。
例如游戏的不删档公测，通过Alpha内测之后，会进行不删除用户资料的公共测试，让大量的用户去进行体验，试玩。许多用户可以使用它，并传达他们对应用程序的反馈。提交给测试，测试再提交给开发人员去修复。
https://www.bilibili.com/video/BV1Tt411c78F?p=3 7:03
黑盒测试和白盒测试
软件测试方法一般分为两种：白盒测试与黑盒测试。
其中，白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试，着重于程序的内部结构及算法，通常不关心功能与性能指标。
黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试，实际上是站在最终用户的立场上，检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。
黑盒测试方法，不考虑程序内部结构和内部特性，而是从用户观点出发，针对程序接口和用户界面进行测试，根据产品应该实现的实际功能和已经定义好的产品规格，来验证产品所应该具有的功能是否实现，是否满足用户的要求。
所以，黑盒测试方法技术相对要求低，方法简单有效，可以整体测试系统的行为，可以从头到尾（end-to-end）进行数据完整性测试。
黑盒测试方法适合系统的功能测试、易用性测试，也适合和用户共同进行验收测试、软件确认测试。
黑盒测试方法不适合
单元测试、集成测试，而且测试结果的覆盖度不容易度量，其测试的潜在风险比较高。
白盒测试方法，已知产品的内部工作过程，针对性很强，可以对程序每一行语句、每一个条件或分支进行测试，测试效率比较高，而且可以清楚已测试的覆盖程度。如果时间足够多，可以保证所有的语句和条件得到测试，测试的覆盖程度达到很高。
- 白盒测试方法所以适合单元测试、集成测试，
- 而不适合系统测试。白盒测试方法准备的时间很长，如果要覆盖全部程序语句、分支的测试，一般花费比编程更长的时间。
白盒测试方法所要求的技术也较高，相应的测试成本要大。对于一个应用的系统，程序的路径数可能是一个天文数字，即使借助一些测试工具，白盒测试法也不可能进行穷举测试，企图遍历所有的路径往往是做不到的。即使，穷举路径测试，也不能查出程序违反了设计规范的地方，不能发现程序中已实现但不是用户所需要的功能，可能发现不了一些与数据相关的错误或用户操作行为的缺陷。所以白盒测试方法也存在一定的局限性。
常用的黑盒测试方法有：
等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。
等价类划分法，主要解决穷举的问题：
- 等价类划分法将测试数据中具有某种共同特征的数据集合，进行划分。
- 有效等价类:满足需求的数据集合
无效等价类:不满足需求的数据集合
边界值分析法
- 选取正好等于、刚好大于、刚好小于边界的值作为测试数据
判定表
- 是一种以表格形式表达多条件逻辑判断的工具
- 判定表中贯穿条件项和动作项的一列就是一条规则
假设有n个条件，每个条件的取值有两个(0,1)，全组合有2的n次方种规则
场景法
- 场景法也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。
- 意义:
➢用户使用角度:用户平时使用的不是单个功能，而是多个功能组合起来进行使用
➢测试人员角 度:平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试
白盒测试主要是检查程序内部的逻辑结构，也就是对所有逻辑路径进行测试，是一种穷举路径的测试方法。
白盒测试：逻辑覆盖+路径覆盖
白盒测试常用方法：
1、逻辑覆盖测试：语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖、路径覆盖
六种覆盖标准发现错误的能力呈由弱到强的变化： 1.语句覆盖每条语句至少执行一次。 2.判定覆盖每个判定的每个分支至少执行一次。 3.条件覆盖每个判定的每个条件应取到各种可能的值。 4.判定/条件覆盖同时满足判定覆盖条件覆盖。 5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。 6.路径覆盖使程序中每一条可能的路径至少执行一次。
所以理论上来讲路径覆盖是最彻底的测试用例覆盖，但实际上很多时候路径覆盖的可操作性不强。
2、基本路径覆盖测试：选择足够的测试用例，使得运行这些测试用例时，被测程序的每条可能执行的路径都至少经过一次。
数据流测试：
循环测试：简单循环、嵌套循环、串接循环和非结构循环。
黑盒白盒适合运用于什么场景
黑盒测试与白盒测试优缺点
黑盒测试的优点有：
比较简单，不需要了解程序内部的代码及实现；
与软件的内部实现无关；
从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；
基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；
在做软件自动化测试时较为方便。
黑盒测试的缺点有：
不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%；
自动化测试的复用性较低。
白盒测试的优点有：
帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。
白盒测试的缺点有：
程序运行会有很多不同的路径，不可能测试所有的运行路径；
测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；
系统庞大时，测试开销会非常大。
冒烟测试
冒烟测试： 确保开发人员修复了 bug 后，这个 bug 的修复没有影响到其他功能模块。
冒烟测试是否通过决定了下一轮系统测试是否可以执行。
冒烟测试的重要性，不作用于本身，而是决定了下一轮测试是否能达到理想的效果
与系统测试不同之处在于冒烟测试是一种不要求覆盖面有多广的测试，但是要保证被测对象的主要部分功能要得到测试，不要求每一个功能都面面俱到，但是要保证所有被修改过以及与修改相关的功能、主要的功能都是可用的，即证明这个版本可进行系统测试
冒烟测试，是版本验证测试，主要确认新的版本是否存在致命性bug，功能可以正常运行（不会出现跑不通的状况），不会影响下一轮测试的进行，如果上述都符合那么这个版本就可以进行下一轮测试。
https://zhuanlan.zhihu.com/p/103637689
与回归测试不同，回归测试，是软件维护阶段对软件修改后进行的测试，指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误
- 1.什么是测试用例
- 用例:用户使用的案例
测试用例:执行测试时用户案例
英文: Test Case - 2.为什么 需要编写测试用例
- 目的:保证测试点的正确执行
- 3.测试用例编写格式
- 说明:用例编写格式一般由八大要素组成。
- 4.编写示例
微信登录测试点:
1、登录成功
2、密码错误,登录失败
☆☆☆测试用例☆☆☆
这几个方面看（功能、界面、性能、安全性、兼容性
=====具体的例子，要说详细。在测试内容明确的基础上，再从测试手段上去进行考量，才是比较全面的思路=====
But，还没有结束。如果更近一步，可以从测试手段上进行进一步的思考。你是希望测试一个矿泉水瓶呢还是一百万个？测试一个的话手动就行了。如果是一百万个？只能借助机器，用自动化的方式来实现了。再比如稳定性测试中，瓶盖是需要开启十次还是一万次？十次手动做做还可以接受，一万次扭下来估计手也要废掉了。所以必须考虑自动化。诸如此类
【飞书】视频会议测试用例
功能测试
界面测试
性能测试
兼容性测试
一、功能测试
发起新会议，按钮是否可用，弹出的界面是否正确
是否支持设置会议主题，验证每种合法的输入，结果是否正确，各种正常输入的字符，混合输入，排列组合。
是否可以输入数字，英文，中文，特殊字符等
是否可以混合输入数字，英文，中文，特殊字符等
边界值验证：不输入字，输入字，最多输入多少字，在允许的字符串长度内外，系统如何处理
是否只能输入允许的字符串长度
超长字符串粘贴输入，系统是否会截取允许的长度来检验结果
输入框是否支持编辑、复制、粘贴、剪切、等操作
- 麦克风设置，是否支持关闭、开启麦克风；是否支持切换扬声器选项；是否支持测试扬声器和麦克风可用性
- 摄像头设置，是否支持关闭、开启摄像头；是否支持设置虚拟背景，虚拟形象；
- 如果使用手机应用，使用移动网络进行视频通话是否会有提示：使用流量提示
- 开始会议，音视频是否连接成功
- 清晰度，流畅度，声音和画面是否正常，是否同步
- 是否支持录制，录制之后是否支持飞书妙记的功能
- 会议分享邀请功能是否可用
- 会议权限设置，根据不同的权限，测试有效和无效用例
- 屏幕共享功能，，，是否所有进程都能被检测到，飞书云文件文档是否也可分享
- 字幕功能是否可用，字幕设置语言，可进行实时翻译
- 多人视频会议可容纳的人数上限
- 视频会议中，网络质量差是否有提示信息
- 视频会议挂断功能是否正常（全员结束会议
- 会议记录详情
- 加入会议功能是否可用，会议ID错误是否有提示
- 会议ID输入框，是否只支持输入数字，其他特殊字符是否可输入
- 在断网的情况下视频会议,检查是否有提示信息
- 在弱网的情况下视频会议，网络延迟，卡顿，服务器响应, 检查提示信息
异常：
无网络是否可以发起会议，是否提示：当前网络不可用，请检查网络设置
无网络是否可以结束会议（通话中断
网络质量不好的情况下发起、接收会议
会议中有新的会议邀请
会议中手机/电脑没电、断网、故障、系统更新、应用app切换（中断测试
会议中来电话，短信（中断测试
会议时电脑/手机重启、手机卡死（中断测试
会议中系统版本升级（中断测试
二、界面测试
- 查看界面是否显示正确，布局是否合理
- 界面是否简单，美观
- 界面文字，图片和图标显示正常
- 是否有错别字
- 操作过程中出现的各种提示显示正常。
- 双方视频框大小布局合理
- 按钮、控件是否整齐，长度高度是否符合要求
- 界面的设计风格，颜色搭配是否合理，是否符合UI设计风格
三、性能测试
- 视频会议接听后的响应速度
- 高并发场景下，多人同时进入视频会议的响应情况
- 压力测试——长时间视频会议（如12小时）是否能保持正常（CPU，内存消耗，流量消耗）等；
- 稳定性测试——频繁进行视频会议；
- 不同网络测试：2G,3G,4G,5G,wifi和热点，不同运营商测试；不同网速测试
四、安全性测试
- 脚本的禁用，防止XSS攻击，填入js代码是否异常（alert(1111)）
- SQL的注入，检索SQL SELECT语句等（’ or 1=1# ）如单引号、%等等，造成查询SQL拼接出的语句产生漏洞
- 文字聊天中，敏感内容是禁止的，对涉及国家安全、法律禁止的内容是否进行了相关的过滤和控制
- 是否有安全设计控制
五、兼容性测试
- 不同手机型号，不同手机操作系统（例如ios12,13,14，安卓）
- 不同的电脑机型，不同的电脑操作系统（win7,8,10,mac,linux
- 多浏览器chrome、IE、火狐、360等
- 不同的飞书版本
- 不同的分辨率下显示是否正常。
- 不同语言环境下，页面的显示是否正确，是支持多种语言版本
视频直播测试用例（直播或播放
功能测试
界面测试
性能测试
安全性测试
兼容性测试
一、功能测试
使用移动网络是否会有提示：移动网络下将产生手机流量
进入直播中，视频能否链接成功
进入直播中，声音和画面是否正常，是否同步
进入直播中，插拔耳机是否能正常直播
直播的模式：横屏，竖屏，或者来回切换。
直播中，网络质量差是否有提示信息
直播间可容纳的人数上限
播放的UI键位：返回，关闭，播放/暂停，最大化/最小化，音量的调节。
是否可以点击返回键、Home键
是否可以与其他应用切换
挂断功能是否正常
直播播放的机制：首次进入正常播放 ，暂停播放，继续播放，快进播放，倍速播放，连续播放，拖拽播放等等情况
直播延迟情况：对于直播，延迟是否在需求内
直播中的互动：互动，评价等是否正常
播放缓存机制：如支持缓存下载，则校验下载，下载完成播放，下载暂停，下载继续，下载删除再下载等情况
直播结束，直播者结束直播，接收者是否也结束
直播详情页面，是否有直播显示记录
播放的网络：WIFI、2G、3G、4G网络环境下的播放和加载情况。断网之后能否继续恢复播放
异常：
无网络是否可以发起直播，是否提示：当前网络不可用，请检查网络设置
无网络是否可以结束视直播（直播中断
网络质量不好的情况下发起、接收直播
直播中手机没电、断网、手机故障、系统更新、app切换（中断测试
直播中来电话，短信（中断测试
直播手机重启、手机卡死（中断测试
直播直播软件版本升级（中断测试
异常情况：播放中多个APP前后切换，播放是否正常
异常情况：播放中被外界打断，如来电，短信，按home键等
二、界面测试
- 查看界面是否显示正确，布局是否合理
- 界面是否简单，美观
- 界面文字，图片和图标显示正常
- 是否有错别字
- 操作过程中出现的各种提示显示正常。
- 双方视频框大小布局合理
- 按钮、控件是否整齐，长度高度是否符合要求
- 界面的设计风格，颜色搭配是否合理，是否符合UI设计风格
三、性能测试
- 发起直播的响应速度，打开直播的响应速度
- 高并发场景下用户进入直播的响应时间测试。
模拟大量用户同时进入直播，检查一定压力下能否正常跳转。 - 负载测试：看极限能承载多大的用户量同时正常使用
- 弱网测试，弱网时直播的响应时间
- 压力测试——长时间直播（如12小时）是否能保持正常（CPU，内存消耗，流量消耗）等；
- 稳定性测试——频繁进行直播；
- 不同网络测试：2G,3G,4G,5G,wifi和热点，不同运营商测试；不同网速测试
四、安全性测试
- 脚本的禁用，防止XSS攻击，填入js代码是否异常（alert(1111)）
- SQL的注入，检索SQL SELECT语句等（’ or 1=1# ）如单引号、%等等，造成查询SQL拼接出的语句产生漏洞
- 直播中，敏感内容是禁止的，对涉及国家安全、法律禁止的内容是否进行了相关的过滤和控制
- 是否有安全设计控制
五、兼容性测试
- 不同手机型号，不同手机操作系统（例如ios12,13,14，安卓）
- 不同的电脑机型，不同的电脑操作系统（win7,8,10,mac,linux
- 多浏览器chrome、IE、火狐、360等
- 不同的直播软件版本
- 不同的分辨率下显示是否正常。
- 不同语言环境下，页面的显示是否正确，是支持多种语言版本
登录测试用例（例如微信等APP，网站登录
功能测试
界面测试
性能测试
安全性测试
兼容性测试
一、功能测试
- 输入已注册正确的用户名和密码，点击提交按钮，验证是否能正确登录。检查登录成功后数据库是否写入了session信息
- 输入未注册用户名或者错误的密码，验证登录会失败，并且提示用户或密码错误信息。检查登录失败时数据库生成的session不会记录用户信息
- 什么都不输入，点击提交按钮，检查提示信息。（微信是什么都不输，登录按钮为不可用灰色）
- 未注册用户通过手机号验证码第一次登录成功时，是否提示修改密码
- 通过手机号+验证码方式登录，在用户授权的情况下，检查能不能自动获取到短信验证码
- 登录成功后能否跳转到正确的页面
- 检查能否选择不同登录方式进行登录，如使用手机号登录、使用微信号登录或扫码登录。
- 扫码登录，检查二维码是否可以定时失效刷新
- 检查有没有记住用户名的功能
- 登陆失败后，不能记录密码的功能
- 密码是否非明文显示，使用星号圆点等符号代替。
- 有验证码时，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色、刷新或换一个按钮是否好用
- 登录页面中的注册、忘记密码，登出用另一帐号登陆等功能的链接是否正确
- 输入密码的时候，大写键盘开启的时候要有提示信息
- 在断网的情况下能否正常登录**,检查是否有提示信息**
- 在弱网的情况下能否正常登录，网络延迟服务器响应, 检查提示信息
二、界面测试
- 布局是否合理，textbox（文本框控件）和按钮是否整齐。
- textbox和按钮的长度，高度是否符合要求。
- 界面的设计风格，颜色搭配是否合理，是否符合UI设计风格
- 界面中的文字简洁易懂，没有错别字。
三、性能测试
- 打开登录页面，需要的时间是否在需求要求的时间内。
- 不同网速下搜索时的响应时间3g,4g,5g,WIFI、热点；不同运营商网络
- 单用户登录的响应时间。
输入正确的用户名和密码后，检查登录成功跳转到新页面的时间是否在需求要求的时间内。 - 高并发场景下用户登录的响应时间测试。
模拟大量用户同时登陆，检查一定压力下能否正常登陆跳转。
四、安全性测试
- 登录成功后生成的Cookie，是否是http-only (否则容易被脚本盗取)。
- 用户名和密码是否通过加密的方式，发送给Web服务器。
- 用户名和密码的输入框，应该屏蔽SQL注入攻击。
- 用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）。
- 防止暴力破解，检测是否有错误登陆的次数限制。
- 是否支持多用户在同一机器上登录。
- 同一用户能否在多台机器上登录。
- 密码输入框是否是不支持复制粘贴的
- 异地登录校验、更换设备校验
五、兼容性测试
- 不同移动平台或PC环境下下能否显示正常且功能正常（平台不同
- 同种平台下不同微信版本下能否显示正常且功能正常。（微信版本
- 不同的分辨率下显示是否正常。
- 不同语言环境下，页面的显示是否正确，是支持多种语言版本。（本地化测试）【就比如设置手机语言环境为英文/中文】
百度搜索框测试用例
功能测试
界面测试
性能测试
安全性测试
兼容性测试
特性
一、功能测试
- 验证每种合法的输入，结果是否正确，各种正常输入的字符，混合输入，排列组合。
- 是否可以输入数字，英文，中文等
- 是否可以混合输入数字，英文，中文等
- 分词功能，在输入一些毫无关联的文字时，是否针对其中某一个有实际的关键词进行搜索
- 搜索内容与搜索结果的匹配程度
- 点击搜索，是否正常显示搜索界面
- 搜索内容为空，系统如何处理（为空测试
- 搜索内容为空格，系统如何处理
- 边界值验证：不输入字，输入字，最多输入多少字，在允许的字符串长度内外，系统如何处理
- 是否只能输入允许的字符串长度
- 超长字符串粘贴输入，系统是否会截取允许的长度来检验结果
- 在系统允许的合法的字符串长度后，加空格来验证检索结果是否变化
- 多个关键字中间加入空格，逗号，验证系统的结果是否正确
- 输入拼音能不能进行检索
- 输入特殊字符、转义字符等是否可以搜索
- 是否支持语音搜索，语音搜索按钮是否可用，语音搜索的内容是否匹配
- 是否支持图片搜索，图片搜索按钮是否可用，进行图片搜索时是否可以选择拍照或从相册中选取图片进行搜索
- 如果从相册中选取图片进行搜索，图的大小是否有限制
- 能否识别图片中的内容
- 是否支持回车键搜索
- 输入的内容是否支持快捷键操作等
- 是否支持检索内容的编辑、复制、粘贴、剪切、等操作
- 重复提交，多次输入相同的内容，查看系统的检索结果是否一致
- 搜索内容有没有搜索联想功能
- 搜索的历史纪录是否显示，是否有缓存记录
- 点击清空历史记录，搜索框是否会清空
- 输入链接是否正确跳转
- 在断网的情况下无法搜索,检查是否有提示信息
- 在弱网的情况下能否搜索，网络延迟服务器响应, 检查提示信息
二、界面测试
- 查看界面是否显示正确，布局是否合理，
- 按钮、控件是否整齐，长度高度是否符合要求
- 是否有错别字
- 搜索结果显示的布局是否美观
- 已查看的结果链接，链接的颜色要灰化处理，
- 结果数量庞大时，页面的分页布局是否合理
- 界面的设计风格，颜色搭配是否合理，是否符合UI设计风格
三、安全性测试
- 脚本的禁用，防止XSS攻击，填入js代码是否异常（alert(1111)）
- SQL的注入，检索SQL SELECT语句等（’ or 1=1# ）如单引号、%等等，造成查询SQL拼接出的语句产生漏洞
- 敏感内容的检索是禁止的，对涉及国家安全、法律禁止的内容是否进行了相关的过滤和控制
- 特殊字符的检索
- 被删除、加密、授权的数据，不允许被查出来
- 是否有安全设计控制
四、性能测试
- 搜索页面的链接打开速度的时间
- 搜索出结果消耗时间
- 高并发场景下用户搜索的响应时间测试。
模拟大量用户同时搜索，检查一定压力下能否正常跳转。 - 弱网时搜索的响应时间
- 不同网速下搜索时的响应时间3g,4g,5G,WIFI、热点，不同运营商网络
五、兼容性测试
- 多平台Windows，mac
- 移动平台android，ios
- 多浏览器chrome、IE、火狐、360等
- 不同的分辨率下显示是否正常。
- 不同语言环境下，页面的显示是否正确，是支持多种语言版本
微信朋友圈点赞测试
功能测试
界面测试
接口测试（相同好友
性能测试
安全性测试
兼容性测试
一、功能测试
按点赞人
- 是否可以点赞，点赞成功是否显示结果
- 点赞后能否取消点赞，取消后重新点赞情况
- 点赞是否显示头像和昵称
- 点赞之后能否进行评论
- 点赞后，其他共同好友点赞，是否有消息提醒
- 点赞后，其他非共同好友点赞，是否有消息提醒
- 点击点赞人的昵称，能否跳转到其资料页（可以点自己的，也可以点别人的
- 从朋友圈动态点赞
- 访问好友相册，对历史动态点赞情况，点赞不同时间的朋友圈（当天，一周后，一月后，半年后
- 点赞已经被删除的朋友圈（点赞方还没来得及刷新的时候
- 点赞时手机没电、断网、手机故障、系统更新、app切换（中断测试
- 点赞时来电话，来信息有没有影响（中断测试
- 点赞时手机重启、手机卡死（中断测试
- 点赞时微信版本升级（中断测试
按被点赞人
- 自己给自己点赞
- 点赞人昵称是否显示正常（有备注的是否展示备注名，昵称特殊符号能否展示
- 点赞后列表显示，是否是按时间顺序进行排列
- 点赞显示区域一行可以显示多少人，是否换行显示
- 从朋友圈动态页查看，是否显示点赞用户昵称
- 从个人相册页查看，是否显示点赞用户头像图标
- 从个人相册页点击单张图片查看，是否显示点赞用户数量
- 解除好友关系后，或者屏蔽好友后是否还展示其点赞
按点赞内容：
- 点赞不同类型的朋友圈，图片，文字，视频，链接
消息提醒：
- 进去朋友圈，顶端消息提醒
- 用户屏蔽了朋友圈提醒，有新点赞是否不提醒
- 动态删除后，原来未查看的消息，是否展示
- 消息列表展示详情
- 消息未查看，换设备登录，是否仍存在消息提醒
其他
- 多次点赞会出现什么情况
- 点赞是否有人数限制？
- 同一朋友圈，多个好友同时点赞
- 同一朋友圈，用户在手机和电脑上同时点赞
- 弱网的时候进行点赞是什么情况
- 没有网络时是否可以点赞
二、界面测试
- 查看界面是否显示正确，布局是否合理
- 界面是否简单，美观
- 点赞的头像是否显示正常，大小是否合适
- 按钮、控件是否整齐，长度高度是否符合要求
- 界面的设计风格，颜色搭配是否合理，是否符合UI设计风格
三、接口测试相同好友
- 点赞之后相同好友是否收到提示信息
- 相同好友处的提示信息是否按照时间顺序
- 相同好友处的点赞是否显示头像和名称
四、性能测试
- 点赞图标的显示速度——用户点击点赞几秒后可以看到点赞成功，取消点赞后几秒可以看到取消
- 多用户同时给我点赞时，我是否可以全部接收到提示消息（压力测试
- 频繁点击是否卡顿
- 频繁浏览是否易崩溃
- 3g,4g,5G,WIFI、热点，不同运营商网络的网络测试
- 弱网测试，网络延迟，断网的响应结果
五、安全性测试
点赞是否会泄漏微信用户相关信息
六、兼容性测试
- 不同手机型号，不同手机操作系统，是否都可以进行点赞和取消点赞功能（例如ios12,13,14，安卓）
- 不同的电脑机型，不同的电脑操作系统（win7,8,10,mac,linux
- 不同的微信版本
- 不同的分辨率下显示是否正常。
- 不同语言环境下，页面的显示是否正确，是支持多种语言版本
微信视频通话测试用例
功能测试
界面测试
性能测试
兼容性测试
一、功能测试
发起视频通话，使用移动网络进行视频通话是否会有提示：移动网络下将产生手机流量
发起视频通话，对方接听前，是否可以点击取消，取消有无信息提示
发起视频通话，是否可以听到铃声
发起视频通话，对方接听前是否可以切换到语音通话
发起视频通话，对方正在视频通话是否会有提示信息“对方忙”
发起视频通话，对方无应答，是否有提示信息
发起视频通话，对方拒绝，是否有提示信息
视频通话中，视频能否链接成功
视频通话中，声音和画面是否正常，是否同步
视频通话中，是否可切换到语音通话
视频通话中，前后摄像头转换是否正常
视频通话中，插拔耳机是否能正常通话
视频通话中，点击对方视频窗口是否可以窗口交换
视频通话中，点击音量键是否可以调节音量
视频通话中，是否可以点击返回键、Home键
视频通话中，是否可以与其他应用切换
视频通话中，挂断功能是否正常
视频通话中，网络质量差是否有提示信息
视频通话结束，发起者结束通话
视频通话结束，接收者结束通话
视频通话结束，是否会返回聊天页面
聊天页面，是否有显示记录（通话时长00:27，对方已取消，对方已拒绝，通话中断，对方忙线中，已拒绝，已取消……
多人视频通话：
勾选好友后，确认按钮才可以点击
邀请的好友是否都可以进入视频通话
未被邀请的好友能否进入视频通话
未被邀请的好友是否可以发起视频通话（只能加入正在进行的通话，不能发起
在群聊里发起视频通话是否有消息显示：谁谁谁发起了语音通话
在群聊里视频通话结束是否有已经结束的提示：语音通话已结束
使用移动网络进行视频通话是否会有提示
异常：
无网络是否可以发起视频通话，是否提示：当前网络不可用，请检查网络设置
无网络是否可以结束视频通话（通话中断
网络质量不好的情况下发起、接收视频通话
视频通话中有新的视频通话邀请
视频通话中手机没电、断网、手机故障、系统更新、app切换（中断测试
视频通话中来电话，短信（中断测试
视频通话时手机重启、手机卡死（中断测试
视频通话中微信版本升级（中断测试
二、界面测试
- 查看界面是否显示正确，布局是否合理
- 界面是否简单，美观
- 界面文字，图片和图标显示正常
- 是否有错别字
- 操作过程中出现的各种提示显示正常。
- 双方视频框大小布局合理
- 按钮、控件是否整齐，长度高度是否符合要求
- 界面的设计风格，颜色搭配是否合理，是否符合UI设计风格
三、性能测试
- 视频通话接听后的响应速度
- 多人视频通话可容纳的人数上限
- 压力测试——长时间视频（如12小时）是否能保持正常（CPU，内存消耗，流量消耗）等；
- 稳定性测试——频繁进行视频通话；
- 不同网络测试：2G,3G,4G,5G,wifi和热点，不同运营商测试；不同网速测试
四、兼容性测试
- 不同手机型号，不同手机操作系统，是否都可以进行点赞和取消点赞功能（例如ios12,13,14，安卓）
- 不同的电脑机型，不同的电脑操作系统（win7,8,10,mac,linux
- 不同的微信版本
- 不同的分辨率下显示是否正常。
- 不同语言环境下，页面的显示是否正确，是支持多种语言版本
微信发红包测试用例
功能测试
界面测试
性能测试
安全性测试
兼容性测试
一、功能测试
发给单个好友红包
输入正确或错误的金额、有无留言、有无表情、有无选择红包封面 做排列组合的测试
是否可以按返回键，是否可以取消发红包
对于金额，是否只能输入数字和小数点
对于金额，是否支持复制、粘贴、剪切
对于金额，测一些边界值（0，0.01，01，199.99，200，200.01）
对于金额，检查限制几位小数点，最少可以输入的钱数
对于金额，检查限制单个红包金额，最多可以输入的钱数，是否不超过200
对于金额（0.01-200），输入0，或者0.0或者0.00，是否可以点击塞钱进红包（为空测试
对于超过200的金额，是否可以点击塞钱进红包
直接输入小数点，那么小数点之前是否自动补0
对于输入0开头的金额，比如023，是否会去掉首部0，只显示23
对于留言，测试默认留言：恭喜发财，大吉大利
测试输入数字、中文、英文、特殊字符、emoji表情,；或者他们的组合
测试留言长度限制，输入超长文本时，是否会截断显示限制
是否支持复制、粘贴、剪切
测试表情，是否支持选择自己收藏的表情测试（动图/静图）
测试表情，是否支持选择下载的表情测试（动图/静图）
自拍表情，是否支持录制并添加进行测试
选择完表情之后，是否图标改变，预览显示小表情
点击表情，是否支持删除已选择表情
是否支持添加红包封面，输入序列号领取
是否支持切换红包封面
是否显示红包封面的有效期
是否能查看已失效的红包封面
是否下一次发红包，默认是上一次选择的红包封面（没过期失效的情况下
点击塞钱进红包，弹出来的界面是否正确
如果未开通微信支付，有无引导提示！！！！！
如果有开通微信支付，则支付方式是否可以修改
信用卡交易，不可选
零钱或者零钱通余额小于要发红包的金额，不可选
有没有添加新的银行卡选项
选择支付方式之后，是否按用户设置的默认方式进行支付，例如使用正确指纹、或者正确面容、或者正确密码确认付款功能是否正常
不正确的指纹或者面容，不正确的是否提示，重试依旧不正确之后是否提示密码输入
选择支付方式之后，使用密码确认付款（正确的/不正确的密码，不正确的是否提示）
密码是否非明文显示
密码输入错误，是否可以选择忘记密码，或者重试，跳转页面是否正确
是否限制密码输入错误次数
考虑所选支付方式金额不足的情况，如果支付失败，是否会提示余额不足
如果余额不足是否会提示，换支付方式，已经尝试过的余额不足的选项是否被灰化
如果红包发送成功，所选支付方式是否减少了相应的金额
账单明细里是否会同步显示
发送者/接收者，点击红包是否可以查看红包的具体信息，金额，留言，表情等显示正确
发给单个用户的红包，发送者自己无法领取
接收者点击红包之后，零钱中将增加相应的金额，再次点击之后，只能查看到红包的信息
被领取的红包有颜色变化，颜色被弱化
24小时之内没有领取的红包，将退回原账户，此时原账户的零钱将增加相应金额的金钱。
24小时后好友点击红包，显示红包已过期，无法查看到红包的详情以及红包金额
发送群红包（仅写出与单用户发红包不同的地方
红包类型可以选择，拼手气，专属红包
红包个数的输入框中只能输入数字
红包个数最大限制，100
红包个数，输入0，输入01，输入最大100
拼手气红包是否每个红包金额随机
普通红包是否每个红包金额一样，塞进红包钱数是不是个数×单个金额
拼手气红包，测试红包个数为3，总金额为0.02情况，会显示单个红包不可低于0.01
群中所有人均可以抢红包（包括自己），每个人最多只有一次抢该红包的机会
发红包的人聊天界面是否可以看到红包被领取的消息提示
在24小时之内红包的金额被完全抢完，且此时为拼手气红包时，金额最多的人会显示为运气王（若有两个人取得红包的最大值时，则只有一个人会显示为最佳手气）；
在24小时之内，若没有被完全抢完，则没有最佳手气，检查余额会退还到原账户
超过24小时没有领取的红包，检查是否不可以领取
异常：
发红包、抢红包时手机没电、断网、手机故障、系统更新、app切换（中断测试
发红包、抢红包时来电话，来信息有没有影响（中断测试
发红包、抢红包时手机重启、手机卡死（中断测试
发红包、抢红包时微信版本升级（中断测试
断网时，无法发红包，抢红包
二、界面测试
- 查看界面是否显示正确，布局是否合理
- 界面是否简单，美观
- 界面文字，图片和图标显示正常
- 是否有错别字
- 操作过程中出现的各种提示显示正常。
- 按钮、控件是否整齐，长度高度是否符合要求
- 界面的设计风格，颜色搭配是否合理，是否符合UI设计风格
三、性能测试
- 弱网时，抢红包，发红包时间
- 2G,3G,4G,5G,wifi和热点，不同运营商测试；不同网速测试时，抢红包，发红包的时间
- 发红包和收红包成功后的跳转响应时间
- 稳定性：是否可以连续多次发红包
- 群发红包，多人同一时间抢，高并发场景下响应时间
- 耗电量
- 消耗流量的多少
- 所占内存
四、安全性测试
- 对方微信号异地登录，是否会有提醒
- 红包被领取以后，收红包金额会增加
- 红包未领取，超时是否原路返回
- 发送红包失败，余额和银行卡里的钱数不会少
- 红包发送成功，是否会收到微信支付的通知
五、兼容性测试
- 不同手机型号，不同手机操作系统（例如ios12,13,14，安卓）
- 不同的微信版本
- 不同的分辨率下显示是否正常。
- 不同语言环境下，页面的显示是否正确，是支持多种语言版本
微信评论测试用例（论坛评论、抖音评论功能
功能测试
界面测试
性能测试
接口测试（共同好友
安全性测试
兼容性测试
（论坛评论，需要另外注意，1、用户是否登录，是否有权限评论； 2、没有共同好友可见这种说法
（抖音评论，需要另外注意，1、用户是否登录，是否有权限评论； 2、没有共同好友可见这种说法；3.可以@别人，提醒功能，可以给评论点赞功能，可以给别人评论回复，点赞多5-5条的是否置顶显示，评论的点赞数显示是否正常，某条评论的回复互动是否可以展开，收起
一、功能测试
按评论人
- 是否可以评论，评论成功是否显示结果
- 评论后能否删除评论，删除后重新评论情况
- 支持哪些评论类型：文字、表情
- 能否评论为空，评论空格（为空测试！！！！！！！
- 评论的字数长度限制
- 评论输入框是否支持复制粘贴剪切
- 能否多次评论
- 评论后是否显示头像和昵称
- 评论后，其他共同好友是否可以看到
- 是否可以看到其他共同好友的评论
- 是否可以回复其他共同好友的评论
- 评论后，其他共同好友评论，是否有提醒
- 评论后，其他非共同好友评论，是否有提醒
- 点击评论人的昵称，能否跳转到其资料页（可以点自己的，也可以点别人的
- 从朋友圈动态页评论
- 访问好友相册，对历史动态评论，评论不同时间的朋友圈（当天，一周后，一月后，半年后
- 评论已经被删除的朋友圈（还没来得及刷新的时候
- 评论时手机没电、断网、手机故障、系统更新、app切换（中断测试
- 评论时来电话，来信息有没有影响（中断测试
- 评论时手机重启、手机卡死（中断测试
- 评论时微信版本升级（中断测试
按被评论人：
- 自己给自己评论
- 评论人头像、昵称是否显示正常（有备注的是否展示备注名，昵称特殊符号能否展示
- 评论后列表显示，是否是按时间顺序
- 评论显示区域是否按评论人单独一行显示，一行最多多少字，长度超过是否换行显示
- 从朋友圈动态页查看，是否显示评论用户头像、昵称、评论内容
- 从个人相册页点击单张图片查看，是否显示评论的数量
- 解除好友关系后，或者屏蔽好友后是否还展示其评论
按评论的朋友圈内容：
- 评论不同类型的朋友圈，图片，文字，视频，链接
消息提醒：
- 进去朋友圈，顶端消息提醒
- 用户屏蔽了朋友圈提醒，有新评论是否不提醒
- 动态删除后，原来未查看的消息，是否展示
- 消息列表展示详情
- 消息未查看，换设备登录，是否仍存在消息提醒
其他
- 多次评论会出现什么情况
- 评论是否有人数限制？
- 同一朋友圈，多个好友同时评论
- 同一朋友圈，用户在手机和电脑上同时评论
- 弱网的时候进行评论是什么情况
- 没有网络时是否可以评论
二、界面测试
- 查看界面是否显示正确，布局是否合理
- 界面是否简单，美观
- 评论人的头像、昵称等是否显示正常，大小是否合适
- 按钮、控件是否整齐，长度高度是否符合要求
- 界面的设计风格，颜色搭配是否合理，是否符合UI设计风格
三、接口测试（相同好友
- 评论之后相同好友是否收到提示信息
- 相同好友处的提示信息是否按照时间顺序
- 相同好友处的评论是否显示头像和名称
四、性能测试
- 评论的显示速度——用户评论几秒后可以看到评论显示成功，取消评论后几秒可以看到取消
- 多用户同时给我评论时，我是否可以全部接收到提示消息（压力测试
- 频繁评论是否卡顿
- 频繁浏览是否易崩溃
- 3g,4g,5g,WIFI、热点，不同运营商网络的网络测试
- 弱网测试，网络延迟，断网的响应结果
五、安全性测试
- 评论是否会泄漏微信用户相关信息
- 评论里放不安全的链接
六、兼容性测试
- 不同手机型号，不同手机操作系统，是否都可以进行评论和取消评论功能（例如ios12,13,14，安卓）
- 不同的电脑机型，不同的电脑操作系统（win7,8,10,mac,linux
- 不同的微信版本
- 不同的分辨率下显示是否正常。
- 不同语言环境下，页面的显示是否正确，是支持多种语言版本
购物车测试（例如淘宝、淘宝结账测试用例
业务流程：
进入购物车->加商品到购物车->编辑购物车->选择商品->提交订单
一、功能测试
- 用户的权限：用户登录后才能对购物车操作，未登录会提示需要登录
- 未登录时，将商品加入购物车，页面跳转到登录页面，登录成功后购物车数量增加
- 未登录时，点击底部购物车菜单栏，页面跳转到登录页面，登录成功后可以查看购物车
- 登录后，验证所有链接是否跳转正确，是否能够正常进入购物车页面，有两种方式：通过底部菜单栏或在商品详情页面跳转到购物车结算。
- 对购物车商品的操作：
- 添加商品
商品是否可以成功加入购物车
添加一件商品到购物车，查看购物车页面商品是否增加
添加同一个店铺的多个商品到购物车，查看显示是否正常
添加不同店铺的多个商品到购物车，查看显示是否正常
店铺或商品名过长时，是否进行部分显示
点击商品链接是否能跳转到商品详情
购物车商品总数是否有限制
购物车商品总数是否正确
新加入购物车商品排序（添加购物车中存在店铺的商品，购物车中不存在店铺的商品）显示是否正确 - 删除商品
删除功能是否好用
点击删除商品，是否有提示
商品删除后商品总数是否减少 - 增加/减少商品数量
通过“+”、“-”来增加/减少商品数量，考虑边界值0、最大限购数量、库存
通过输入来确定数量，是否只支持整数输入，有效：整数；无效：特殊字符、小数、负数是否不允许输入；输入023是否自动会自动检测为23 - 对商品的管理
是否支持重新选择商品规格
打折或者活动，例如满减商品是否打标
移入收藏夹，收藏夹有相应商品，购物车中没有
是否支持找相似商品的功能
单选、按店铺全选和整个购物车全选功能是否好用
多选商品，数量与选择是否一致
商品无货或下架等，是否移到失效
是否有回到顶部的功能
是否支持一键清理，一键删除的功能，是否有警告提示 - 结算
对选择的商品进行结算，数量与选择的是否一致，需支付价格与实际价格总和是否一致。
- 添加商品
二、界面测试
- 查看界面是否显示正确，布局是否合理
- 不同卖家的商品是否区分明显！！！！
- 界面是否简单，美观
- 界面文字是否显示清晰，图片和图标显示正常
- 是否有错别字
- 操作过程中出现的各种提示显示正常。
- 按钮、控件是否整齐，长度高度是否符合要求
- 界面的设计风格，颜色搭配是否合理，是否符合UI设计风格
三、性能测试
加入购物车响应速度
打开购物车响应速度
进入购物车结算响应速度
高并发场景下用户进行购物车操作的响应时间测试。
模拟大量用户同时加购物车，检查一定压力下能否正常跳转。频繁加购物车，频繁浏览是否易卡顿、崩溃
中断测试：
加购物车时手机没电、断网、手机故障、系统更新、app切换（中断测试
加购物车时来电话，来信息有没有影响（中断测试
加购物车时手机重启、手机卡死（中断测试
加购物车时淘宝版本升级（中断测试弱网测试（地铁，高铁，山区）延时，丢包，fiddler，弱网时加购的响应时间.
延时——超时, 2min之内没有收到请求;合理性提示.
丢包——系统2min之内，没有上传到服务器，做失败处理;重发机制不同网速下加购的响应时间3g,4g,5G,WIFI、热点，不同运营商网络
网络延迟，断网的响应结果
四、安全性测试
- 通过一些工具进行安全扫描，检查是否有安全漏洞
- 防止结算价格修改等，fiddler
- 防止sql注入，跨站攻击等
- 验证敏感信息是否加密，是否可以篡改
五、兼容性测试
- 不同手机型号，不同手机操作系统，是否都可以进行正常的购物车功能（安卓系统、ios系统，主流的系统版本需要测试覆盖）
- 不同的电脑机型，不同的电脑操作系统（win7,8,10,mac,linux
- 不同的淘宝版本
- 不同的分辨率下显示是否正常。
- 不同语言环境下，页面的显示是否正确，是支持多种语言版本
淘宝搜索框测试用例
功能测试
界面测试
性能测试
安全性测试
兼容性测试
一、功能测试
未登录情况和登录情况下的搜索（登录情况下存储用户搜索的关键字/搜索习惯）
输入搜索关键字，验证每种合法的输入，结果是否正确，各种正常输入的字符，混合输入，排列组合。
是否可以输入数字，英文，中文等
是否可以混合输入数字，英文，中文等
输入可查到结果的正常关键字、词、语句，
输入不可查到结果的关键字、词、语句；
输入一些特殊的内容，如空、特殊符、标点符；（为空测试点击搜索，是否正常显示搜索界面
搜索内容与搜索结果的匹配程度，点击商品链接是否正确跳转
查看返回结果是否准确，返回的商品文本长度是否有限制
结果显示：标题，卖家，销售量，价格，单行/多行，列表/平铺显示，是否有图片
结果排序：按价格 销量 综合 信用
返回结果数量很多时，限制一页的显示量，是否支持下拉
筛选功能是否可用：分类、价格区间、发货地、品牌、产地、折扣与服务（是否天猫，是否全球购，是否包邮，是否支持7天内退货等）筛选与设置
是否支持模糊搜索（输入拼音能不能进行检索），有疑似输入条件错误时提示可能正确的输入项等等处理（栗子七，你要找的是不是李子柒
标题查询、全文检索、模糊查询、容错查询、多关键字查询（空格间格开）等搜索方式是否正常
是否支持图片搜索，图片搜索按钮是否可用，进行图片搜索时是否可以选择拍照或从相册中选取图片进行搜索
如果从相册中选取图片进行搜索，图的大小是否有限制
能否识别图片中的内容
是否支持检索内容的编辑、复制、粘贴、剪切、等操作
重复提交，多次输入相同的内容，查看系统的检索结果是否一致
搜索内容有没有搜索联想功能
搜索的历史纪录是否显示，是否有缓存记录
点击清空历史记录，是否有提示确认，历史记录是否会清空
在断网的情况下无法搜索,检查是否有提示信息
在弱网的情况下能否搜索，网络延迟服务器响应, 检查提示信息
二、界面测试
- 交互界面的设计是否便于理解、易于使用依据不同的查询结果会有相关的人性化提示，查不到时告知？查到时统计条数并告知？
- 查看界面是否显示正确，布局是否合理，
- 按钮、控件是否整齐，长度高度是否符合要求
- 是否有错别字
- 搜索结果显示的布局是否美观
- 已查看的结果链接，链接的颜色要灰化处理，
- 结果数量庞大时，页面的分页布局是否合理
- 界面的设计风格，颜色搭配是否合理，是否符合UI设计风格
三、性能测试
- 搜索商品响应速度
- 高并发场景下用户搜索的响应时间测试。
模拟大量用户同时搜索，检查一定压力下能否正常跳转。 - 负载测试：看极限能承载多大的用户量同时正常使用
- 弱网测试，弱网时搜索的响应时间
- 网络测试，不同网速下搜索时的响应时间3g,4g,5G,WIFI、热点，不同运营商网络
- 稳定性测试：常规压力下能保持多久持续稳定运行
- 内存测试：有无内存泄漏现象
- 大数据量测试：如模拟从庞大的海量数据中搜索结果、或搜索出海量的结果后列示出来，看表现如何等
四、安全性测试
- 脚本的禁用，防止XSS攻击，填入js代码是否异常（alert(1111)）
- SQL的注入，检索SQL SELECT语句等（’ or 1=1# ）如单引号、%等等，造成查询SQL拼接出的语句产生漏洞
- 敏感内容的检索是禁止的，对涉及国家安全、法律禁止的内容是否进行了相关的过滤和控制
- 特殊字符的检索
- 被删除、加密、授权的数据，不允许被查出来
- 是否有安全设计控制
五、兼容性测试
- 多平台Windows，mac、LINUX
- 移动平台android，ios
- 多浏览器chrome、IE、火狐、360等
- 不同淘宝版本
- 不同的分辨率下显示是否正常。
- 不同语言环境下，页面的显示是否正确，是支持多种语言版本
支付功能测试（支付宝支付，微信支付，银行卡支付等
一、功能测试
支付流程测试点
- 正常完成支付的流程；
- 调起订单后，取消订单
- 支付中断后，继续支付的流程；
- 支付中断后，结束支付的流程；
- 单订单支付的流程；
- 多订单合并支付的流程；
- 支付失败后，再次支付
- 弱网状态下，连续点击支付功能功能，会不会支付多次；
- 找人代付；
- 密码错误；
- 密码错误次数过多，是否限制；
- 支付后，有没有跳回原页面
- 支付成功后，产品购买是否成功
支付方式测试点
- 不同的支付方式：银行卡网银支付、支付宝支付、微信支付等；
- 不同终端上支付：包括PC端的支付、笔记本电脑的支付、平板电脑的支付、手机端的支付等；
- （支付宝）支付过程中是否允无网络的情况下，可以进行打开付款码界面，被扫码支付。
- （支付宝）支付宝付款码是否付款码每间隔一段时间会更新一次。
- （支付宝）主动扫一扫支付，被动付款码支付
- （支付宝）点击主页“付钱/收钱”按钮， 是否可以成功的调出二维码识别界面。
- 有优惠券、折扣、促销价进行结算是否正确；
- 优惠券/折扣是否是必选，是否可以不选择折扣
- 支付订单退款完成后，优惠券/折扣是否还能使用
支付金额测试点
- 正常金额支付
- 金额字段校验：非数字、sql相关字符、负数、边界值与数据库设计长度，为空是否报错
- 金额的最小值：0.01
- 无意义的值：0元
- 最大金额：设置支付的最大金额
- 银行卡或微信等，设置每日最大消费金额或者单笔最大消费金额
- 余额不足；
- 是否支持添加新卡支付；
- 付款金额和应付金额是否一致，（比如：扫描的支付二维码，和显示的应支付金额是否一致）。支付还是要走整个支付流程才行，从确认订单到最后的支付成功，任何一步都有可能有问题。
- 支付成功后，用户的金额是否扣除成功
- 取消支付后，退款金额是否正确
二、界面测试
- 各种提示，是否显示正常（例如点击付款按钮取消付款，是否有提示；
- 交互界面的设计是否便于理解、易于使用
- 查看界面是否显示正确，布局是否合理，
- 按钮、控件是否整齐，长度高度是否符合要求
- 界面的设计风格，颜色搭配是否合理，是否符合UI设计风格
三、性能测试
支付的响应时间，取消支付的响应时间；
高并发场景下用户进行支付操作的响应时间测试。
模拟大量用户同时支付，检查一定压力下能否正常跳转。中断测试：
支付时手机没电、断网、手机故障、系统更新、app切换（中断测试
支付时来电话，来信息有没有影响（中断测试
支付时手机重启、手机卡死（中断测试
支付时当前支付软件版本升级（中断测试弱网测试（地铁，高铁，山区）延时，丢包，fiddler，弱网时加购的响应时间.
延时——超时, 2min之内没有收到请求;合理性提示.
丢包——系统2min之内，没有上传到服务器，做失败处理;重发机制不同网速下加购的响应时间3g,4g,5G,WIFI、热点，不同运营商网络
网络延迟，断网的响应结果
四、安全性测试
- 通过一些工具进行安全扫描，检查是否有安全漏洞
- 使用Fiddler拦截订单信息，并修改订单金额，或者修改订单号，(下两个订单A,B，付款时拦截订单B，并把订单B的订单号改为A订单的订单号)是否无法完成支付；
五、兼容性测试
- 多平台Windows，mac、LINUX
- 移动平台android，ios
- 多浏览器chrome、IE、火狐、360等
- 支付软件不同版本
- 不同的分辨率下显示是否正常。
- 不同语言环境下，页面的显示是否正确，是支持多种语言版本
支付宝转账测试用例
转账方–>支付宝–>收款方流程，观察测试场景
一、功能测试
转账流程测试点
- 正常完成转账的流程；
- 发起转账后，取消转账
- 转账支付中断后，继续转账支付的流程；
- 转账支付中断后，结束转账支付的流程；
- 给单人转账
- 给多人转账；
- 转账人确认与校验
- 转账失败后，再次转账
- 弱网状态下，连续点击转账支付功能，会不会转账多次；
- 面容支付，或者指纹，或者密码错误；
- 密码错误次数过多，是否限制；
转账方式测试点
- 不同的转账支付方式：面容支付，指纹支付，密码支付等；
- 不同终端上转账支付：包括PC端的支付、平板电脑的支付、手机端的支付等；
转账金额测试点
- 正常金额转账
- 转账金额大于、等于、小于当前余额，余额不足的情况
- 金额字段校验：非数字、sql相关字符、负数、边界值与数据库设计长度，为空是否报错
- 金额的最小值：0.01
- 无意义的值：0元
- 最大金额：转账的最大金额
- 银行卡或微信等，设置每日最大转账金额或者单笔最大转账金额
- 是否支持添加新卡转账支付；
- 转账金额和扣款金额是否一致
- 转账成功后，用户的金额是否扣除成功
- 转账之后是否对方是否到账
二、界面测试
- 各种提示，是否显示正常（例如转账，取消转账，转账确认等，是否有提示；
- 交互界面的设计是否便于理解、易于使用
- 查看界面是否显示正确，布局是否合理，
- 按钮、控件是否整齐，长度高度是否符合要求
- 界面的设计风格，颜色搭配是否合理，是否符合UI设计风格
三、性能测试
转账的响应时间，取消转账的响应时间；
高并发场景下用户进行转账操作的响应时间测试。
模拟大量用户同时转账，检查一定压力下能否正常跳转。中断测试：
转账时手机没电、断网、手机故障、系统更新、app切换（中断测试
转账时来电话，来信息有没有影响（中断测试
转账时手机重启、手机卡死（中断测试
转账时支付宝版本升级（中断测试弱网测试（地铁，高铁，山区）延时，丢包，fiddler，弱网时加购的响应时间.
延时——超时, 2min之内没有收到请求;合理性提示.
丢包——系统2min之内，没有上传到服务器，做失败处理;重发机制不同网速下加购的响应时间3g,4g,5G,WIFI、热点，不同运营商网络
网络延迟，断网的响应结果
四、安全性测试
- 通过一些工具进行安全扫描，检查是否有安全漏洞
- 使用Fiddler拦截转账信息，并修改转账金额，或者修改转账交易号，(下两个转账A,B，转账时拦截订单B，并把转账B的交易号改为转账A的交易号)是否无法完成支付；
五、兼容性测试
- 多移动平台android，ios
- 支付宝不同版本
- 不同的分辨率下显示是否正常。
- 不同语言环境下，页面的显示是否正确，是支持多种语言版本
=====实物类测试=====
自动售货机测试用例
功能测试
界面测试(外观，大小等)
性能测试
安全性测试
兼容性测试
首先，拆解自动售货机为不同模块，存放货物区、取货区、付钱区
一、功能测试
- 自动售货机的按钮能否正常使用，有没有按不动的情况
- 货物是否正常放置
- 验证用户选择饮料功能是否正确，比如选择农夫山泉最终出来的是不是农夫山泉
- 点击货物选择按钮是否能进入支付页面
- 是否支持选择多个货物
- 是否支持硬币、纸币、微信、支付宝等方式支付
- 付了钱选择了货物，是否能正常出货
- 验证投币付款功能是否正确，是否支持找零
同面额的纸币硬币，有面额不接受怎么办
付钱不够怎么办
付钱多了怎么办
付钱多了但是没有零钱找怎么办
付钱不是正常的钱怎么办，比如假钱，游戏币等 - 货物是否能正常取出(有的货物过大、过小、形状不规范等)，取货口是否好拿货物（针对不同的人群，是否使用方便，孕妇、儿童、老人、成年人
- 出现故障时能否自动退款
- 货物卡住了或者钱没有退，是否有联系客服的方式
- 屏幕是否正常播放广告
- 屏幕是否显示二维码
- 操作过程有没有相应的提示音
- 售货机缺货时会不会有提醒
- 定价功能可否正常使用，是否支持非整数定价，像定个九块
- 优惠信息可否正常折扣，像有优惠券或打折时
- 操作是否跟网络状态有关系（弱网、强网、无网）
- 对于存放的货物有没有常温、冷藏、加热功能，温度能不能设置
有效的等价类有：
金额刚够，顺利出货
金额超出，找零出货
金额超出, 没钱找零,出货
金额不足，进行提示，把货币退出
金额足够，取消交易
假币，不出货
无效等价类：
投入金额，不出货，不找零
投入金额，不出货，退钱
金额超出，出货，不找零
金额超出，不出货，找零
金额不足，出货，找零l
金额不足，出货，不找零
金额不足，不出货，不退款
金额刚够，不出货，退款
金额刚够，出货，找零
金额刚够，不出货，找零
不投金额，直接出货
二、界面测试
- 外观设计是否合理，售货机的大小是否合适
- 操作界面的布局搭配是否合理，不同模块的大小分配是否合理（投币口是否明显，取物口是否明显
- 操作是否简便，流程是否复杂，使用说明是否通俗易懂
- 操作接口是否齐全
- 按钮的大小、颜色、形状是否美观，是否通俗易懂
- 有没有设备编号、服务电话标识
- 有没有消费者投诉电话
三、性能测试
- 选择商品后跳转到支付页面的时间
- 利用微信、支付宝等第三方平台支付时的响应速度
- 支付成功后商品掉落时间
- 退币时的响应时间和退币速度
- 付款时突然断电，异常断电、系统故障，是否有恢复功能
- 跟第三方支付平台的接口对接是否可用
- 软硬件结合的效率，软硬件软件发出操作指令后，硬件的及时正确响应
- 多个用户同时扫码支付
四、安全性测试
- 售货机上的二维码是否屏幕实时显示，刷新，防止他人恶意替换二维码
- 收款码是否携带恶意病毒
- 售货机的材料是否安全无害
- 玻璃是否易被敲碎
- 是否漏电，下雨天会不会漏水
- 受到外力撞击是否容易倾倒
- 售货机设计的有没有锋利的地方，会不会划伤到顾客
- 售货机存钱的地方是否安全，会不会被他人偷取
五、兼容性测试
- 是否能在室外、室内工作
- 是否能在高温下工作
- 是否能在低温下工作
水杯测试用例（一次性咖啡杯、纸杯等等
功能测试+易用性测试
界面测试(外观，大小)
性能测试
安全性测试
兼容性测试
一、功能测试
盛放半杯水是否漏水
超过水杯规定的安全线是否漏水
盛放一整杯水是否会溢出
拧紧盖子，摇晃是否漏水
水杯容量是否与需求一致 (例如需求是500ml)
盛放热水是否烫手
（易用性测试）
杯子倒水是否方便
杯子喝水是否方便
水杯是否使用简单，容易操作
杯子是否方便外带
二、性能测试
水杯耐热性
水杯耐寒性
水杯能够盛放热水的容量
水杯能够盛放冷水的容量
能够使用的最大次数或时间
盖子拧多紧不会漏水
掉在地上不易摔坏
能否保温，保温时长
长时间放置是否漏水(7×24h)
检查水杯的最大抗压和拉扯承受力
杯子从不同高度掉下的损坏程度
防震性能测试：杯子加包装(有填充物) ，六面震动，检查产品是否能应对恶劣的铁路/公路/航空运输
三、界面测试
使用手册是否对杯子的用法、限制、使用条件等有详细描述
水杯外观是否简单、美观
水杯设计是否符合人体，拿着舒服
水杯大小是否与设计一致（水杯的高、宽、容量、直径
水杯材质是否与需求一致
水杯上图案是否合法，是否容易掉落，遇水是否掉落
四、安全性测试
检查水杯万一被破坏，是否会伤害使用者
杯子使用的材质是否有毒或有细菌
杯子盛放热水、冷水是否有有毒气体散发（高温下材质是否释放毒性、低温下材质是否释放毒性
杯子是否有防滑措施
五、兼容性测试
除盛放水外，能否盛放果汁、碳酸饮料等
除盛放饮用品外，能否盛放硫酸、酒精、汽油等
杯子在不同地方、不同温度环境下都可以正常使用
矿泉水瓶测试用例
一、功能测试
装水、喝水的功能，具体如下：
- 检查矿泉水瓶的容量是否符合设计要求
- 将空瓶和装满水的瓶子放在电子秤上，检查瓶子装满水前后的重量，是否符合设计要求。
- 检查水瓶在装少量水、半瓶水、装满水的情况下是否会漏水；
- 检查水瓶在装少量水、半瓶水、装满水的情况下能否喝到水；
- 在瓶盖拧紧不漏水的情况下，分别让成年男性、成年女性和小孩尝试拧开瓶盖，看是否成功；
- 分别将水瓶放在手中、口袋、包包、车上等不同位置，看是否方便携带
二、界面测试（外观测试
主要是两方面，水瓶的大小、水瓶外观设计：
- 瓶子的高度、底座尺寸是否符合设计要求；
- 瓶子的口径尺寸是否符合设计要求；
- 瓶身上的字体颜色、大小是否符合设计要求，是否有错别字；
- 瓶身上的纹路、线条是否符合设计要求；
- 瓶身上图标布局是否合理，其间距、大小是否符合公设计要求；
- 是否符合用户审美，用户体验感
三、性能测试
测试水瓶的抗摔、抗压、抗高低温等情况：
- 将瓶子装满水后拧紧瓶盖，将其倒置或使劲摇晃、各种角度挤压，看是否漏水或破裂。
- 将空瓶、半瓶水、满瓶水分别从不同的高度（1m、3m、8m、15m）摔下来，看瓶子是否摔坏，是否漏水；
- 将空瓶和半瓶水、满瓶水分别放置于不同温度下（冰箱、室内和太阳光高温）下一段时间（1天，10天，1个月，6个月），观察瓶子是否漏水，瓶身是否破裂；
- 将空瓶、装半瓶水的瓶子、装满水的瓶子分别置于水平桌面上，用电风扇吹桌面上的瓶子，调节电风扇的风力大小，观察瓶子是否会被吹倒或吹走
- 满瓶的水加包装后，六面震动，检查产品是否能应对铁路/公路/航空等运输环境。
四、安全性测试
测试水瓶使用时是否会伤害到人、是否产生对人体有害物质等：
用手去抚摸瓶身的内壁和外壁，是否感觉光滑舒适不刺手；
用矿泉水瓶喝水，并转动瓶口，感受瓶口是否圆滑；
空瓶长时间放置一段时间（一个月、三个月、半年），一起检测是否产生塑化剂或细菌；
将空瓶子燃烧掉，观察燃烧时的火焰，闻燃烧时的气味，查看燃烧的残留物是否符合材质的燃烧特性，是否产生有害的毒气。
矿泉水瓶分别装满不同液体（水、碳酸饮料、果汁等），放置一段时间，看瓶身是否与液体之间发生化学反应，是否产生有毒物质或细菌；
矿泉水瓶中装入热水（或放入微波炉），观察瓶子是否变形，是否有异味产生
用手轻拿装满水的瓶子，看是否轻易掉落，是否有防滑措施；
矿泉水瓶分别装入不同温度（30℃、60℃、80℃）的水，用手感受瓶身温度，看是否会烫手，因为感受不到的话更容易烫嘴。；
五、兼容性测试
- 瓶中分别装入碳酸饮料、果汁、咖啡、茶水、油类等液体，放置一段时间是否变味；
- 瓶中是否可以装入固体例如饼干、沙子，石头等），且瓶子与装入的固体是否会发生化学反应。
But，还没有结束。如果更近一步，可以从测试手段上进行进一步的思考。你是希望测试一个矿泉水瓶呢还是一百万个？测试一个的话手动就行了。如果是一百万个？只能借助机器，用自动化的方式来实现了。再比如稳定性测试中，瓶盖是需要开启十次还是一万次？十次手动做做还可以接受，一万次扭下来估计手也要废掉了。所以必须考虑自动化。诸如此类
在测试内容明确的基础上，再从测试手段上去进行考量，才是比较全面的思路。
一个网站测试用例
首先，查找需求说明、网站设计等相关文档，分析测试需求。
制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试
设计测试用例：
功能性测试
可以包括，但不限于以下几个方面：
链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。
提交功能的测试。
多媒体元素是否可以正确加载和显示。
多语言支持是否能够正确显示选择的语言等。
界面测试
可以包括但不限于一下几个方面：
页面是否风格统一，美观
页面布局是否合理，重点内容和热点内容是否突出
控件是否正常使用
对于必须但未安装的控件，是否提供自动下载并安装的功能
文字检查
性能测试
一般从以下两个方面考虑：
压力测试；负载测试；强度测试
数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。
安全性测试：
基本的登录功能的检查
是否存在溢出错误，导致系统崩溃或者权限泄露
相关开发语言的常见安全性问题检查，例如SQL注入等
如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持
兼容性测试，
根据需求说明的内容，确定支持的平台组合：
浏览器的兼容性；
操作系统的兼容性；
软件平台的兼容性；
数据库的兼容性
开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。
定期评审，对测试进行评估和总结，调整测试的内容。
App测试用例
（1）APP的功能性测试
功能测试都是我们首要测试的，只有功能实现了才算符合上线发布的最低标准。我们需要检测产品功能是否已实现、产品功能是否符合设计要求、产品功能是否有重复、产品是否有重复的功能
（2）APP易用性测试
检测界面是否美观、操作是否简单易用，符合用户的操作行为、产品是否有相关的帮助文档
（3）APP兼容性测试
检测与本地及主流APP是否兼容、各设备是否兼容（不同手机屏幕分辨率的兼容性、不同手机品牌的兼容性、不同手机操作系统的兼容性）
（4）APP交叉事件测试（也属于功能测试的范畴）
检测APP运行时前/后台切换是否影响正常功能、APP运行时拨打/接听电话APP是否能正常响应、APP运行时发送/接收信息APP是否能正常响应、
APP运行时发送/收取邮件APP能否正常响应、APP运行时浏览网络能否正常响应、APP运行时使用蓝牙传送/接收数据APP是否能正常响应
（5）APP安全性测试
检测软件是否有正规的数字签名、软件程序是否有加密、敏感数据是否有脱敏显示、数据传输时是否有加密、安全性漏洞、系统漏洞
（6）APP可靠性测试
验证程序中影响软件可靠性的故障，并排除故障实现软件可靠性增长、验证软件当前的可靠性水平是否满足用户的要求、验证软件的数据备份、恢复
（7）APP性能测试
检测程序在正常情况、峰值情况下的系统的各项性能指标是否正常。性能指标主要有：响应时间（应用响应时间从发出请求开始到客户端接收到响应所消耗的时间）、最大并发用户数、吞吐量、CPU内存占用、耗电量、流量
一个口罩测试用例
- 测试一个口罩
我当时从性能、功能、外观、系统、压测、运输、易用性、移植性等测试的，然后反问环节面试官说我对测试基础知识不太了解。。。他也没问我测试方法，就测试一个口罩，不知道为什么就被贴标签了。。。而且我看网上都是这么测的，也没标准答案，大家可以讨论一下
后来我想到这么测
大方向 单元测试（把口罩拆成各个部分）、集成（不同单元组合测试）、系统（性能、功能、外观、系统、压测、运输、易用性、移植性等）、回归、验收 前三步可以穿插黑盒白盒测试方法，总结起来就是你知道啥流程、方法都套进去，估计那个面试官想让我这么测，这个方法还是搜集了很多资料慢慢总结出来的
洗衣机测试用例
功能测试：该洗衣机是否能正常的洗衣服，能否预约，按钮设置是否都可用等等等
需求测试：查看洗衣机的使用说明书和安全说明书等
性能测试：使用时用电量如何，是否满足用户需求
界面测试：洗衣机的外观是否满足客户的需求
易用测试：该洗衣机是否容易操作
兼用性测试：该洗衣机除了能洗衣服以外还能洗别的吗
安全性测试：该洗衣机通电以后人接触以后是否有电，童锁
负载测试：通过逐步增加系统负载，最终确定在什么负载条件下系统性能将处于崩溃状态，以此获得系统能提供的最大服务
压力测试：通过逐步增加系统负载，最终确定在什么负载条件下系统性能将处于崩溃状态，以此获得系统能提供的最大服务级别的测试。
稳定性测试：加到一定的衣服然后过一段时间看洗衣机是否正常洗
电梯测试用例
1.功能测试：上升、下降、停止、开门、关门、梯内电话、灯光、指示灯等；每个单元测试后进行集成测试。
2.性能测试：速度、反应时间、关门时间等；
3.压力测试：超载、尖锐物碰撞电梯壁等；
4.安全测试：停电、报警装置、轿箱停靠位置、有人扒门时的情况等；
5.可用性：按键高度、操作是否方便、舒适程度等；
6.UI测试：美观程度、光滑程度、形状、质感等；
7.稳定性测试：长时间运行情况等；
8.兼容性测试：不同电压是否可工作、不同类型电话是否可安装等。
功能测试：
1.测试电梯能否实现正常的上升和下降功能。
2.电梯的按钮是否都可以使用。
3.电梯门的打开，关闭是否正常。
4.报警装置是否可用。
5.与其他电梯之间是否协作良好。
6.通风状况如何。
7.突然停电时的情况。
8.上升途中的响应。
1）电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来；
2）电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停。
9.是否有手机信号
安全性：
1.门关上的一刹那出现障碍物。
2.同时按关门和开门按钮。
3.点击当前楼层号码
4.多次点击同一楼层号码
5.同时按上键和下键
易用性：
电梯的按钮的设计符合一般人的习惯吗
用户文档：
使用手册是否对电梯的用法、限制、使用条件等有详细的描述
压力测试：
1.看电梯的最大承重量，在负载过重时报警装置是否有提醒
2.在一定时间内不断让电梯上升、下降
稳定性测试：
看电梯在最大负载下平稳运行的最长时间
判断IP地址是否合法的测试用例
https://www.cnblogs.com/mrwuzs/p/8028373.html 看这个！！！打开链接看
等价类划分
首先把IP地址分成有效可用的IP地址和有效但不可用的IP地址两个等价类；其中有效可用的IP地址中包括IP地址的A，B，C三类地址，有效但不可用的IP地址包括D、E两类IP地址和A、B、C三类地址中的全网地址、广播地址以及回环地址。
如果是有效的 IPv4 地址，有效可用，有效不可用，（边界值等等）
如果是有效的 IPv6 地址
无效的
测试人脸识别系统
功能测试
界面测试
性能测试
安全性测试
兼容性测试
人脸识别设计到AI的两个概念：
计算机视觉（机器视觉）和生物识别。由此展开测试寻找测试点
AI测试与传统测试的异同点：
AI测试需要结合AI架构，算法，应用场景等针对测试。
这里的人脸查准率和人脸设定阈值有关系
设定阈值的过程就是模型评估，阈值设定越低，通过率越高，误报率越低
阈值设置越高，通过率越低，误报率越高
一、功能测试
1、启动系统，是否能跳转到正确的页面
2、人脸检测
人脸/非人脸（拍摄的不是人脸，结果的验证
对人脸属性进行验证(年龄、性别、种族、表情、脸型、是否戴眼镜)
照相功能、打开摄像头功能、关闭摄像头功能、按钮的验证
检测状态(动态和静态)（静态指图片，动态指活体检测）
光线(强弱、顺逆)
人脸截取是否合理（拍摄人脸面积的不同，结果的验证
单脸/多脸检测（拍摄多个人，结果的验证；多次拍摄同一个人的照片,结果的验证
检测距离、距离远近与结果的关系
检测姿势(拍摄角度不同，结果的验证
遮挡/衣着影响（同一个人穿衣不同，结果的验证
抓拍/正常拍
3、人脸对比
选择/上传图片，图片类型、路径、大小、清晰度、像素、按钮验证
显示图片，与上传图片是否一致、显示顺序
两次传入同一张图
传入图像的类型不符合
后台做增删查改后再次人脸验证
按钮验证
结果的验证：
上传同一张图像
上传不同的图像
上传不是人脸图像的结果验证
4、异常检测
网络测试：断网、弱网、网络正常
中断测试：
占用摄像头(拍摄、录像、关闭摄像头)
系统没电、断网、系统故障、系统更新（中断测试
手机来短信，来电话
系统重启、系统卡死（中断测试
系统版本升级（中断测试
不合法图片or选择不是人脸图像的文件上传
提示语：执行不同功能，后台消息打印的验证
二、界面测试
- 查看界面是否显示正确，布局是否合理
- 界面是否简单，美观
- 界面文字是否显示清晰，图片和图标显示正常
- 是否有错别字
- 操作过程中出现的各种提示显示正常。
- 按钮、控件是否整齐，长度高度是否符合要求
- 界面的设计风格，颜色搭配是否合理，是否符合UI设计风格
三、性能测试
- 检测速度、响应速度
- 精准率
- 多人检测的响应时间测试。
- 高并发场景，模拟多用户同时进入人脸识别系统检测
- 频繁进行人脸识别，是否易卡顿、崩溃
- 弱网测试（地铁，高铁，山区）延时，丢包，fiddler，弱网时加购的响应时间.
延时——超时, 2min之内没有收到请求;合理性提示.
丢包——系统2min之内，没有上传到服务器，做失败处理;重发机制 - 不同网速下的响应时间3g,4g,5G,WIFI、热点，不同运营商网络
- 网络延迟，断网的响应结果
四、安全性测试
活体检测、连续检测、3D检测
- 活体检测：判断用户是否为正常操作，通过指定用户做随机动作，一般有张嘴、摇头、点头、凝视、眨眼等等，防止照片攻击。 判断用户是否真实在操作，指定用户上下移动手机，防止视频攻击和非正常动作的攻击。
- 3D检测：验证采集到的是否为立体人像，能够防止平面照片、不同弯曲程度的照片等。
- 连续检测：通过连续的检测，验证人脸运动轨迹是否正常，防止防止跳过活体检测直接替换采集的照片，也能够防止中途切换人。
五、兼容性测试
- 不同手机型号，不同手机操作系统，是否都可以进行正常的识别功能（安卓系统、ios系统，主流的系统版本需要测试覆盖）
- 不同的电脑机型，不同的电脑操作系统（win7,8,10,mac,linux
- 不同的人脸识别系统版本
- 不同的分辨率下显示是否正常。
- 不同语言环境下，页面的显示是否正确，是否支持多种语言版本
微信注册页面密码的测试用例编写
https://www.cnblogs.com/niuniu0328/p/14721497.html
要求： 6~18位且由数字和字母组成，注册成功,跳转页面；注册失败，请重新输入密码
- 画思维导图
- excel编写测试用例
☆☆☆定位bug、定位前后端问题☆☆☆
什么情况下用数据库，Linux，fiddler
用数据库
- 修改数据，方便测试
- 校验数据落地，比如你充值了1万，页面显示你充值成功，所以到底成没成功，要去看数据库
用Linux
（Xshell连Linux，cd到日志存放的地方，一般日志分小时去切割，日志号一般般根据设备号或者手机号去筛选
- 查看日志
- 埋点/打点测试，比如要新增两个功能，读书，看视频，想看有多少人点击了，收集行为，每点一个按钮，都会发送日志，向后台发送json，应该是点一次打一个，需要看有没有多打，点一次打三个就是bug了
用fiddler，charles
- 手工测不出来
- 看重要请求有没有加密，能不能篡改
- 请求会不会重复发送（滴滴打车，会不会同时呼叫了好几个司机
抓包的方式，获取请求数据和响应的数据，然后去对应开发人员提供的接口文档
如果请求数据有问题，那么这就是客户端的问题，如果在这种情况下还是无法定位这个bug的话，
可以通过接口测试的方式来定位，比如说登录功能，正确的用户名正确的密码，如果用app来登录的话，提示失败
而使用接口测试的方式来进行登录的话，提示成功，这种情况下就可以判断出，这个bug是属于前端的bug
成功购买后，查看订单有商品没有显示出来
假设你在某购物网站上购买了两件商品，一件打折的，一件不打折，当你下完订单并且成功支付之后，再次去我的订单中查看订单内容时，发现两件商品，只显示出来一件， 而打折的商品并没有显示出来。
1、有权限的话，查看服务器日志，grep,tail等命令
- 有日志话，分别查看购买记录和订单相关的日志
- 查看前端请求是否正常
- 请求不正确，前端的问题
- 请求参数正确
- 查看服务器返回的结果
- 如果服务器返回结果错误，后端的问题
- 如果服务器端返回结果正确，前端的问题（因为，前端没有将正确的结果显示出来
- 查看服务器返回的结果
- 没有日志的话，可以再去看数据库
2、查看数据库，一些select查询语句
- 查看订单表数据是否正常
- 如果数据库没有记录，说明是后端的问题（因为，你已经下完订单并且成功支付了
- 如果数据库有记录，可以去抓包
3、抓包，用抓包工具，例如Fiddler、Charles
- 抓前端查看订单请求
- 前端是否发送请求，没有发送请求的话，说明是前端问题
- 如果前端发送了请求，查看前端发送的请求格式是否正确，请求参数错误，前端问题
- 前端去调后端，请求是否接通。没接通，查看服务器是不是挂了
- 如果请求参数正确，请求接通，可以正常连接，再去抓服务器返回结果
- 抓服务器返回结果
- 服务器返回数据错误，后端问题
- 服务器返回数据正确，前端问题（因为，前端没有将正确的结果渲染，显示在页面上
如果出现加入购物车商品，再结账时不正确，怎么定位异常？
1、有权限的话，查看服务器日志，grep,tail等命令
- 有日志话，分别查看加入购物车记录和订单相关的日志
- 查看前端请求是否正常
- 请求不正确，前端的问题
- 请求参数正确
- 查看服务器返回的结果
- 如果服务器返回结果错误，后端的问题
- 如果服务器端返回结果正确，前端的问题（因为，前端没有将正确的结果显示出来
- 查看服务器返回的结果
- 没有日志的话，可以再去看数据库
2、查看数据库，一些select查询语句
- 查看加入购物车商品数据是否正常
- 如果数据库没有记录，说明是后端的问题（因为，你已经加入购物车，但是数据库里没有
- 如果数据库有记录，可以去抓包
3、抓包，用抓包工具，例如Fiddler、Charles
- 抓前端查看订单请求
- 前端是否发送请求，没有发送请求的话，说明是前端问题
- 如果前端发送了请求，查看前端发送的请求格式是否正确，请求参数错误，前端问题
- 前端去调后端，请求是否接通。没接通，查看服务器是不是挂了
- 如果请求参数正确，请求接通，可以正常连接，再去抓服务器返回结果
- 抓服务器返回结果
- 服务器返回数据错误，后端问题
- 服务器返回数据正确，前端问题（因为，前端没有将正确的结果渲染，显示在页面上
如果A给B评论了但是没显示可能是什么原因造成的（例如微信评论）
1、排除本身网络的问题，先确保网络连接通畅。是谁没显示？排除网络问题先
3、有权限的话，查看服务器日志，grep,tail等命令
- 有日志话，分别查看发送评论请求与响应的相关日志
- 查看前端请求是否正常
- 请求不正确，前端的问题
- 请求参数正确
- 查看服务器返回的结果
- 如果服务器返回结果错误，后端的问题
- 如果服务器端返回结果正确，前端的问题（因为，前端没有将正确的结果渲染出来
- 查看服务器返回的结果
- 没有日志的话，可以去抓包
3、抓包，用抓包工具，例如Fiddler、Charles
从接口请求，参数，接口响应来分析
- 抓前端查看请求
- 前端是否发送请求，没有发送请求的话，说明是前端问题
- 如果前端发送了请求，查看前端发送的请求格式是否正确，请求参数错误，前端问题
- 前端去调后端，请求是否接通。没接通，查看服务器是不是挂了
- 如果请求参数正确，请求接通，可以正常连接，再去抓服务器返回结果
- 抓服务器返回结果
- 服务器返回数据错误，后端问题
- 服务器返回数据正确，前端问题（因为，前端没有将正确的结果渲染，显示在页面上
视频不能播放了，定位错误
排除本身网络的问题，先确保网络连接通畅。
前端APP崩溃，肯定前端的问题
如果是别的问题，通过抓包分析
- 抓前端请求
- 前端是否发送请求，没有发送请求的话，说明是前端问题
- 如果前端发送了请求，查看前端发送的请求格式是否正确，请求参数错误，前端问题
- 前端去调后端，请求是否接通。没接通，查看服务器是不是挂了
- 如果请求参数正确，请求接通，可以正常连接，再去抓服务器返回结果
- 抓服务器返回结果
- 服务器返回数据错误，后端问题
- 如果后端返回的值正确的话，就查看前端读取值进行处理读取的是否正确
朋友圈刷不出来了怎么排查
1、排除本身网络的问题，先确保网络连接通畅。
如果切换网络测试，其他app应用都能正常访问，那么说明是微信服务器的问题
2、有权限的话，查看服务器日志，grep,tail等命令
- 有日志的话，分别查看朋友圈请求与响应的相关日志
- 查看前端请求是否正常
- 请求不正确，前端的问题
- 请求参数正确
- 查看服务器返回的结果
- 如果服务器返回结果错误，后端的问题
- 如果服务器端返回结果正确，前端的问题（因为，前端没有将正确的结果显示出来
- 查看服务器返回的结果
- 没有日志的话，可以去抓包
3、抓包，用抓包工具，例如Fiddler、Charles
从接口请求，参数，接口响应来分析
- 抓前端查看请求
- 前端是否发送请求，没有发送请求的话，说明是前端问题
- 如果前端发送了请求，查看前端发送的请求格式是否正确，请求参数错误，前端问题
- 前端去调后端，请求是否接通。没接通，查看服务器是不是挂了
- 如果请求参数正确，请求接通，可以正常连接，再去抓服务器返回结果
- 抓服务器返回结果
- 服务器返回数据错误，后端问题
- 服务器返回数据正确，前端问题（因为，前端没有将正确的结果渲染，显示在页面上
点击购买后页面加载不出来，怎么排查？
1、排除本身网络的问题，先确保网络连接通畅。
如果切换网络测试，其他app应用都能正常访问，那么说明是服务器的问题
2、有权限的话，查看服务器日志，grep,tail等命令
- 有日志的话，分别查看购买的请求与响应的相关日志
- 查看前端请求是否正常
- 请求不正确，前端的问题
- 请求参数正确
- 查看服务器返回的结果
- 如果服务器返回结果错误，后端的问题
- 如果服务器端返回结果正确，前端的问题（因为，前端没有将正确的结果显示出来
- 查看服务器返回的结果
- 没有日志的话，可以去抓包
3、抓包，用抓包工具，例如Fiddler、Charles
从接口请求，参数，接口响应来分析
- 抓前端查看请求
- 前端是否发送请求，没有发送请求的话，说明是前端问题
- 如果前端发送了请求，查看前端发送的请求格式是否正确，请求参数错误，前端问题
- 前端去调后端，请求是否接通。没接通，查看服务器是不是挂了
- 如果请求参数正确，请求接通，可以正常连接，再去抓服务器返回结果
- 抓服务器返回结果
- 服务器返回数据错误，后端问题
- 服务器返回数据正确，前端问题（因为，前端没有将正确的结果渲染，显示在页面上
微信抢红包测试，如果按钮失灵怎么定位问题
1、排除本身网络的问题，先确保网络连接通畅。
2、排除手机故障问题，排除屏幕失灵问题
3、有权限的话，查看服务器日志，grep,tail等命令
- 有日志话，分别查看抢红包请求与响应的相关日志
- 查看前端请求是否正常
- 请求不正确，前端的问题
- 请求参数正确
- 查看服务器返回的结果
- 如果服务器返回结果错误，后端的问题
- 如果服务器端返回结果正确，前端的问题（因为，前端没有将正确的结果渲染出来
- 查看服务器返回的结果
- 没有日志的话，可以去抓包
3、抓包，用抓包工具，例如Fiddler、Charles
从接口请求，参数，接口响应来分析
- 抓前端查看请求
- 前端是否发送请求，没有发送请求的话，说明是前端问题
- 如果前端发送了请求，查看前端发送的请求格式是否正确，请求参数错误，前端问题
- 前端去调后端，请求是否接通。没接通，查看服务器是不是挂了
- 如果请求参数正确，请求接通，可以正常连接，再去抓服务器返回结果
- 抓服务器返回结果
- 服务器返回数据错误，后端问题
- 服务器返回数据正确，前端问题（因为，前端没有将正确的结果渲染，显示在页面上
有用户反应邀请好友给她砍一刀没有成功怎么排查
1、排除本身网络的问题，先确保网络连接通畅。
2、有权限的话，查看服务器日志，grep,tail等命令
- 有日志话，分别查看砍价的请求与响应的相关日志
- 查看前端请求是否正常
- 请求不正确，前端的问题
- 请求参数正确
- 查看服务器返回的结果
- 如果服务器返回结果错误，后端的问题
- 如果服务器端返回结果正确，前端的问题（因为，前端没有将正确的结果渲染出来
- 查看服务器返回的结果
- 没有日志的话，可以去抓包
3、查看数据库，一些select查询语句
- 查看加入砍价商品的数据是否正常
- 如果数据库没有记录，说明是后端的问题（因为，前端已经显示砍价成功，但是数据库里没有记录
- 如果数据库有记录，可以去抓包
4、抓包，用抓包工具，例如Fiddler、Charles
从接口请求，参数，接口响应来分析
- 抓前端查看请求
- 前端是否发送请求，没有发送请求的话，说明是前端问题
- 如果前端发送了请求，查看前端发送的请求格式是否正确，请求参数错误，前端问题
- 前端去调后端，请求是否接通。没接通，查看服务器是不是挂了
- 如果请求参数正确，请求接通，可以正常连接，再去抓服务器返回结果
- 抓服务器返回结果
- 服务器返回数据错误，后端问题
- 服务器返回数据正确，前端问题（因为，前端没有将正确的结果渲染，显示在页面上，没成功，但是显示砍价成功，这就是错误的渲染
用户反映你开发的网站访问很慢可能会是什么原因。
（1）可能的原因一：服务器出口带宽不够用。这是一个很常见的瓶颈。一方面，可能是本身购买的服务器出口带宽就很小（企业购买带宽相当昂贵），一旦用户访问量上来了，并发量大了，自然均分给用户的出口带宽就更小了，所以某些用户的访问速度就会下降了很多。另一个，就是跨运营商网络导致带宽缩减，例如很多公司的网站（服务器）是放在电信的网络上的，而如果用户这边对接的是长城或者说联通的宽带，运营商之间网络传输在对接时是会有限制的，这就可能导致带宽的缩减。
（2）可能原因二：服务器负载过大忙不过来，比如说CPU和内存消耗完了，这个容易理解，不展开。
（3）可能原因三：网站的开发代码没写好，例如mysql语句没有进行优化，导致数据库的读写相当耗费时间。
（4）可能原因四：数据库的瓶颈，也是很常见的一个瓶颈，这点跟上面第三个原因可以一起来说。当我们的数据库变得愈发庞大，比如好多G好多T这么大，那对于数据库的读写就会变得相当缓慢了，索引优化固然能提升一些效率，但数据库已经如此庞大的话，如果每次查询都对这么大的数据库进行全局查询，自然会很慢。这个学过数据库的话也是挺容易理解的。
二、针对上面可能的原因，有哪些方法和工具去检测呢：
（1）某个用户反馈网站访问变慢，怎么去定位问题。首先你自己也打开下网站，看是否会出现用户反映的问题，如果你这边访问没问题，那就可能是用户那边的问题了，这块就是要先确定是用户那一方的问题还是自身比如说服务器或者网站的问题。
（2）发现确实是自己服务器或者网站的问题，那么可以利用浏览器的调试功能（一般浏览器都会有），调试网络看看各种数据加载的速度，哪一项消耗了多少时间都可以看到，是哪块数据耗时过多，是图片加载太慢，还是某些数据加载老半天都查不出来。
（3）然后针对服务器的负载情况，可以去查看下服务器硬件（网络带宽、CPU、内存）的消耗状况。带宽方面查看流量监控看是不是已经到了峰值，带宽不够用了，如果是公司自己买服务器搭的网站服务器的话，需要自己搭建监控环境；如果用的是阿里云腾讯云这些的，那这些平台那边会提供各方面的监控比如CPU、带宽等等，在后台就可以看到了。
（4）如果发现硬件资源消耗都不高，都比较充裕，那要去看看是不是程序的问题了。这个可以通过查日志来找，比如PHP日志、Apache日志、mysql日志等等的错误日志，特别如mysql有个慢查询的日志功能，可以看到是不是某条mysql语句特别慢，如果某条语句花的时间太长，那这条语句很有可能有问题。
（5）至于说到的数据库太庞大，这个直接看就看得到了，比如一个表的文件大小变得特别大了。
三、针对上面的这些问题，有哪些解决和优化的办法呢：
（1）出口带宽的问题，这个很简单，加带宽，有钱就多买带宽，很简单。
（2）mysql语句优化，开发人员职责。
（3）数据库太庞大，为了读写速度，进行“拆表”、“拆库”，就是把数据表或者数据库进行拆分。
（4）上面的拆库拆表都是针对数据库实在太庞大才会这样做，一般在此之前会有其他优化方法，比如mysql的主从复制，一台主服务器专门用于写，然后其他从服务器用来读，写完之后会同步更新到其他读的服务器中。例如阿里的双十一活动，都不知道用了多少万台服务器一起在扛着。
（6）还有这几年用得比较多的非关系型数据库，它使用了缓存机制，它把数据缓存到了内存，用户访问数据直接从内存读取，读取速度就比在磁盘中读取快了很多，还有它的一个key-value读取机制。
（7）CDN（content-delivery-network：内容分发网络），鸡蛋放在多个篮子里，把数据放在离用户更近的位置（例如网站的一些静态文件比如图片或者js脚本），用户访问时判断IP来源是广州，那就通过智能DNS解析到广州的服务器上，直接从广州的篮子里去获取数据，速度就快了。这里有个静态数据和动态数据的概念，例如图片和一些js文件一般是不变的，那就可以把它们的映像分布到全国各地，加快速度，而一些需要在网站后台动态产生的一些数据，则需要去到网站所在的服务器去产生并得到。这个涉及到两种数据的显示的问题，这就交由浏览器处理了。同时异步加载的技术例如前端的Ajax技术，异步请求数据，可以使这些动态数据延迟加载，这块自己不怎么了解，可能表述不好。前端开发的人员应该更懂一些。
（8）上面都没有说到架构的优化，如果网站扛不住，是不是网站架构已经不能适应了，比如做个小博客把数据库服务器和web服务器都用同一台服务器，那所有负载都在同一台服务器上了。但是访问量上来扛不住了，就得加服务器了，就得在架构上优化了，比如在数据库上做集群，在web服务器上也做集群，比如web服务器集群，在服务器前面加一个负载均衡，负载均衡就是专门负责分发，把用户的请求均匀分布到各个服务器上。
浏览器打不开是什么原因？（输入一个URL，但是没有访问到预期的网站
1.网络断开了
2.是否数据库问题
3.是否被攻击了，网页被劫持了。请求或者响应在网络传输中途被劫走了
4.DNS无法解析网址
5.服务器负载过大，服务器是不是挂了，服务器拒绝访问
6.链路本身问题，供应商网络出口出现问题
1、排除本身网络的问题，先确保网络连接通畅。
2、有权限的话，查看服务器日志，grep,tail等命令
- 有日志话，分别查看访问的请求与响应的相关日志
- 查看前端请求是否正常
- 请求不正确，前端的问题
- 请求参数正确
- 查看服务器返回的结果
- 如果服务器返回结果错误，后端的问题
- 如果服务器端返回结果正确，前端的问题（因为，前端没有将正确的结果渲染出来
- 查看服务器返回的结果
- 没有日志的话，可以去抓包
3、抓包，用抓包工具，例如Fiddler、Charles
从接口请求，参数，接口响应来分析
- 抓前端查看请求
- 前端是否发送请求，没有发送请求的话，说明是前端问题
- 如果前端发送了请求，查看前端发送的请求格式是否正确，请求参数错误，前端问题
- 前端去调后端，请求是否接通。没接通，查看服务器是不是挂了
- 如果请求参数正确，请求接通，可以正常连接，再去抓服务器返回结果
- 抓服务器返回结果
- 服务器返回数据错误，后端问题
- 服务器返回数据正确，前端问题（因为，前端没有将正确的结果渲染
接口测试
接口测试用例设计思路（支付为例
通用信息校验：如检查URL，请求方法，请求头，接口鉴权
接口参数校验：检查参数长度，类型，有效性等
什么是接口测试
接口测试其实最主要的验证接口逻辑，可用性，边界值，异常检查.
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等（通俗来说就是，检查业务逻辑是否满足业务需求，校验字段是否正常你实际结果是否满足预期）
一般来说，测试接口，就是指测试接口的功能，性能和稳定性测试，当然可能还有安全性测试。
一般来说我们听说到的接口基本上都是指HTTP或者HTTPS协议的接口测试，也就是一些web服务请求。
一个软件项目中，有很多接口，少的有几十个，多的有几百上千个接口。
这个时候，我们没有软件界面，没有具体的测试场景，只有一个接口描述文档。
我们需要把接口这样抽象的东西，通过软件测试的理论和方法去测试接口，找出接口的功能和安全性的缺陷。接口有内部接口和外部接口。内部接口就是开发人员自己开发的接口。外部接口，好比网站调用微信支付和支付宝支付接口。还有一些模块与模块之间的接口。
为什么要做接口测试
1、现在很多系统前后端架构是分离的，因为不同端（前段，后端）的工作进度不一样，所以我们要针对最开始出来的接口，以及需要调用其他公司的（银行，支付宝，微信，qq等）一些接口进行接口测试及验证数据。
从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端太容易了）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。在这种情况下就需要从接口层面进行验证。前后端传输、日志打印等信息是否加密传输也是需要验证的，特别是涉及到用户的隐私信息，如身份证，银行卡等。
2、如今系统越来越复杂，传统的靠前端测试已经大大降低了效率，而且现在我们都推崇测试前移也叫测试左移，希望测试能更早的介入，那接口测试就是一种及早介入的方式。例如传统测试，你是不是得等前后端都完成你才能进行测试，才能进行自动化代码编写。 而如果是接口测试，只需要前后端定义好接口，那这时自动化就可以介入编写接口自动化测试代码，手工测试只需要后端代码完成就可以介入测试后端逻辑而不用等待前端工作完成。
举例：
例如一个登陆接口，例如产品上规定用户名6-10个字符数字下划线，但后端没做判断。但我们业务人员测试肯定验证，但只是前端做了校验，后端压根就忘了这个小需求。那么后果来了如果一个懂的直接抓包去篡改你的接口，然后绕过校验，通过sql注入直接随意登录。如果你这是一个下单业务，是不是给公司造成了很大损失
接口的组成：
a、接口说明
b、调用url（请求的地址）
c、请求方法（get\post）
GET提交的数据显示在地址栏，不安全;提交的数据量有限制;不重要的数据使用GET
POST隐式提交数据，更安全;没有数据量大小的限制;重要数据使用POST
d、请求参数、参数类型、请求参数说明
e、返回参数说明
怎么测：
A. 用例设计（根据业务逻辑来设计用例，登录5次，需要2分钟后再登录 删除关注的车，列表少一条数据）
B. 参数组合（传入不同值）
C. 接口安全（绕过验证/绕过身份验证/参数是否加密等）
D. 异常验证（输入异常参数边界值）
用什么工具测
功能：Postman/HTTPrequest/jemter
自动化：restassured/ python httprequest
性能测试
什么是性能测试？
性能测试，顾名思义，就是测试软件性能方面的质量，它是一种非功能性的测试。
在整个测试中，应用程序的性能在预期的或更高的负载下进行评估。评估系统的不同性能属性，如响应时间（速度）、吞吐量、可靠性、资源使用率、可扩展性等。监控系统的各项指标，是否符合需求，如果不符合，就发现了系统的性能瓶颈
性能测试的分类（负载、压力、容量、并发、配置、可靠性持久性
负载测试：通过在被测系统上不断加压（如逐渐增加模拟用户的数量），直到性能指标达到极限，来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等。
- 看你在什么时候已经超出“需求”或系统崩溃。
- 以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。负载测试更多地体现了一种方法或一种技术。
- 这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测试系统的业务压力量和典型场景、使得测试结果具有业务上的意义。
压力测试：系统在强负载（大数据量、大量并发用户等）下的测试，例如cpu、内存在饱和使用情况下，看系统在峰值使用情况下是否稳定，看系统处理的会话能力以及哪里会出问题。
- 从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。
容量测试：通过测试预先分析出系统某项指标的极限值（如最大并发用户数、数据库记录数等）
容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量
例：一个人背X斤。
负载测试：200斤情况下，是否能坚持5分钟。
压力测试：200,300,400… 斤情况下，他的表现，什么时候失败，失败之后什么表现，重新扛200是否正常。
容量测试：在坚持5分钟的情况下，他一次最多能扛多少斤。
并发测试：模拟多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题
配置测试：通过对被测系统软硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则
- 关注点是“微调”，通过对软硬件的不段调整，找出他们的最佳状态，使系统达到一个最强的状态。
可靠性测试(持久性测试)：给系统施加一定的业务压力，让其持续运行一段时间，测试在这种条件下能否稳定运行。
- 关注点是“稳定”，不需要给系统太大的压力，只要系统能够长期处于一个稳定的状态。
- 通常可以测试出系统是否有内存泄露的问题。
性能测试常用指标（并发数、响应时间、吞吐量、资源利用率
并发数
- 并发用户数：指同一时间点向系统提交请求的用户数
- 在线用户数：某段时间内访问系统的用户数。这些用户并不一定同时向系统提交请求
- 系统用户数: 系统注册的总用户数据
响应时间：用户发送一个请求到用户接收到服务器的响应数据这段时间
- 响应时间=网络传输(请求)时间+服务器处理(一层或多层)时间+网络传输(响应) 时间+页面前端解析渲染时间
吞吐量：一段时间内系统处理用户（客户端）请求的数量
- 计算单位: 一般用请求数/秒作为吞吐量的单位。从业务角度来说也可使用访问人数/天，或者页面访问量/天作为单位
- 吞吐量逐渐达到饱和：意味着系统的一种或多种资源利用达到的极限。通常可以利用拐点来进行性能测试分析和定位
资源利用率：对不同系统资源的使用程度， 系统资源(CPU/内存/磁盘/网络)使用占比(使用量/总量*100%)
- 利用率指标:(没有特殊要求情况下)
- CPU 不超过 75%-85%
- 内存不超过 80%
- 硬盘不超过 90%(容量占有率/读写时间比)
常用服务器资源指标（CPU、内存、磁盘、网络、TPS、QPS、HPS、PV、UV
CPU处理器、MEM内存(临时保存)、IO磁盘 (永久保存)、网络(带宽)
车间中加工原料，当车间中没有原料了，在从仓库中取原料，对原料进行加工；
内存本身有一定的存储空间，对内存中的数据进行处理的速度比从硬盘取数据再处理的速度快很多
CPU指标主要指的CPU利用率，包括用户态(user)、系统态(sys)、等待态(wait)、空闲态(idle)。
内存是与CPU进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的，因此内存的性能对计算机的影响非常大
CPU、MEM、IO之间的关系
CPU对数据进行判断以及逻辑处理，本身不能存储数据；这时cpu从内存取数据进行逻辑计算，如果内存没有数据，才会从硬盘读数据到内存，再对数据进行处理。当cpu进程等待，会造成内存开销的增加，内存不够用的时候会用到虚拟内存，导致虚拟内存的增加，这时磁盘IO开销就会增加，系统态sy%提升，cpu开销增加；内存里数据不够用，才用磁盘中取数据。
网络吞吐量简称为Network Throughput，是指在无网络故障的情况下单位时间内通过的网络的数据数量。单位为Byte/s。网络吞吐量指标主要有每秒有多少兆流量进出。
TPS(Transactions Per Second,每秒事务数) ：是单位时间内处理事务的数量
- 从代码角度来说,一段代码或多段代码可以组成一个事务。单位时间内完成的事务数越多,服务器的性能越好
**QPS(Query Per Second,每秒查询数)**：QPS是单位时间内处理请求的数量
- 比TPS划分的更细致一些，因为一个事务可能会包含多个请求。
TPS(每秒事务数) 和 QPS(每秒查询数)区别:
- TPS代表一个事务的处理，可以包含了多次请求
- TPS的一次事务代表一次用户操作到服务器返回结果，QPS的一次请求代表一个接口的一次请求到服务器返回结果。
- 当一次用户操作只包含一个请求接口时，TPS和QPS没有区别。
- 当用户的一次操作包含了多个服务请求时，这时候选TPS作为这次用户操作的性能指标更好。
- 例如：访问一个页面会请求服务器30次，一次访问，产生一个“TPS”，产生30个“QPS”
**点击数HPS(每秒点击次数)**：是指发起请求时, 服务端 对请求 进行响应的页面资源 对应的请求数量
- 每秒用户向web服务器提交的HTTP请求数，并非鼠标的一次单击操作，因为一次单击操作中，客户端可能向服务器发送多个HTTP请求
**PV(Page View, 页面访问量)**：访问一个URL，产生一个PV
- 每日每个网站的总PV量是形容一个网站规模的重要指标
**UV (Unique Visitor,用户访问量)**：作为一个独立的用户，访问站点的所有页面均算作一个UV
性能测试的目的?为什么要进行性能测试？
识别系统的弱点，评估系统能力，发现系统性能瓶颈，提高系统可靠性能和稳定性
进行性能测试主要是为了保障软件能够在期望的负载下运行良好，并且通过发现性能问题来消除应用程序的性能瓶颈。
●提供系统速度的度量；这些测试有助于对参数进行基准测试，如度量应用程序速度的响应时间，我们都知道，这对于应用程序的成功至关重要。
●有助于评估应用程序的可扩展性；性能测试有助于检查应用程序是否有能力扩充更多的用户量。
●有助于检查应用程序的健壮性；通过压力测试，我们可以检查应用程序在工作负载高于预期或高于应用程序阈值时的稳健性。
●有助于检查应用程序的可靠性；进行不同类型的性能测试是为了检查应用程序是否可靠，是否提供了正确的和一致的输出。性能测试，如负载测试和耐久测试，有助于评估系统在预期的工作负载下的正确性。
测试报告的内容
软件测试报告的组成：
一、概述
包括项目背景、需求分析
二、测试时间 测试人员、测试环境（设备）
投入了哪些人，用了多少时间，测试起止时间。
用到哪些测试手机，什么客户端环境，什么浏览器等等。
三、测试过程
评审记录、测试内容、测试范围、测试用例
四、功能实现清单
列出是否已经按照测试计划实现功能
五、缺陷统计，缺陷分析
测试缺陷统计；
测试用例执行情况统计（一共多少，执行了多少，未执行多少，通过多少，失败多少）
六、测试统计情况
资源统计、执行情况、问题统计、问题列表、遗留的问题
七、测试总结
测试结论；（是否通过）
测试内容、测试用例的覆盖程度、bug的解决程度
八、测试风险
测试框架
Appium
appium 1. 13之后安卓上默认的工作原理：
appium的整体架构是C/S模式，整体流程（返回顺序为逆向）：
脚本请求 ——> 4723端口appium server ——> 解析参数给PC端4724端口 ——> 发送给设备4724端口 ——> 通过设备4724端口发给bootstrap.jar ——> Bootstrap.jar把命令发给uiautomator
首先我们要开启appium服务，即Appium server，也就是在命令行用appium命令打开的东西，默认监听4723端口。4723端口专门和脚本打交道，基于WebDriver协议。
client 创建1个session，在该session中通过http向appium server发送请求，appium server解析请求，完成相应操作并返回response。
创建session成功之前，就已将bootstrap.jar放入手机中，并开启设备上的基于appium bootstrap的socket服务，绑定本机和boostrap通信的端口号4724用于和Android设备通讯，默认监听4724端口，等待client的连接。
Appium server将脚本的请求解析后给到4724端口，通过设备的4724端口转发解析后的请求， 此时，对于socket服务来说，appium server就充当了client的角色，appium server通过4724端口主动去请求设备上的socket服务，即向socket服务发送请求，即bootstrap.jar，Bootstrap.jar再把Appium的命令转换成uiautomator的命令来让uiautomator进行处理。有请求就有返回，socket接收到请求后会做出响应，原路返回给脚本，然后脚本再进行下一次的请求。
网络上的两个程序通过一个双向的通信连接实现数据的交换，这个连接的一端称为一个socket。appium和手机的通信过程,主要是数据交换的一个过程，socket的作用是就是为了实现双向通信，它需要一对端口号，对应到这里就是4724，手机端的bootstrap就是socket-server端，appium server就是socket-client端。
关于socket的通信原理，先从服务器端说起。服务器端先初始化Socket，然后与端口绑定(bind)，对端口进行监听(listen)，调用accept阻塞，等待客户端连接。在这时如果有个客户端初始化一个Socket，然后连接服务器(connect)，如果连接成功，这时客户端与服务器端的连接就建立了。客户端发送数据请求，服务器端接收请求并处理请求，然后把回应数据发送给客户端，客户端读取数据，最后关闭连接，一次交互结束。
微信
支付宝
