测试开发岗-高频知识整理【春招】 ，内附面试题答案！
1. 本文内容来源：本文是将自己在20年里找工作的部分笔记重新整理了下，不少内容当时是查阅的知乎、博客园、书籍等(部分还能找到原帖的均附上了链接)。我自己在这一年里也是从牛客上学习了很多面经和经验帖，收获了好几家大厂offer。最近整理出来这些，也算是回馈牛客吧，希望能对找测开岗的朋友们有帮助！2. 本文内容顺序：测试基础理论、测试岗经常被问到的场景题、智力题、测试岗高频算法题、数据库、 Linux知识点。
3. 本文阅读建议：我结合了自身的面试经历，把高频的、重要的知识点都用★标注了，★越多代表自己被问得次数越多。(当然这也只是我的面试经历，存在局限性。）
4. 叨逼叨：亲测，测试岗的面试难度相对开发岗确实低一些，不过面试的内容差别倒不是特别大，像计网、OS、数据结构、数据库、算法/刷题这些都是要准备的，并且测试岗的面试还需要你额外掌握测试相关的知识，也就是本文的一、二两部分内容。不然你叫面试官怎么想你呢？你一点测试的理论知识都不了解，对方只会觉得你大概率是做不来开发才想着试试测试岗吧，所以得快速支棱起自己的测试技能树，让面试官觉得你是有志于干测试开发的。 这一点很重要。
常用自动化测试工具
1、Appium
官网： Mobile App Automation Made Awesome.
AppUI自动化测试
Appium 是一个移动端自动化测试开源工具，支持iOS 和Android 平台，支持Python、Java 等语言，即同一套Java Python 脚本可以同时运行在iOS 和Android平台，Appium 是一个C/S 架构， 核心是一个 Web 服务器，它提供了一套 REST 的接口。当收到客户端的连接后，就会监听到命令，然后在移动设备上执行这些命令，最后将执行结果放在 HTTP 响应中返还给客户端。
License：免费
2、Selenium（★★）
官网： https://www.seleniumhq.org/download/
WebUI自动化测试
Selenium是一个用于Web应用程序测试的工具，Selenium已经成为Web自动化测试工程师的首选。Selenium测试直接运行在浏览器中，就像真正的用户在操作一样。支持的浏览器包括IE(7、8、9)、Mozilla Firefox、Mozilla Suite等。这个工具的主要功能包括：测试与浏览器的兼容性——测试你的应用程序看是否能够很好得工作在不同浏览器和操作系统之上。测试系统功能——创建回归测试检验软件功能和用户需求。支持自动录制动作和自动生成 .Net、Java、Perl等不同语言的测试脚本。Selenium 是ThoughtWorks专门为Web应用程序编写的一个验收测试工具。其升级版本为Webdriver。
License：免费
3、Postman（★★★）
官网： https://www.getpostman.com
接口测试
Postman 提供功能强大的 Web API 和 HTTP 请求的调试，它能够发送任何类型的HTTP 请求 (GET, POST, PUT, DELETE…)，并且能附带任何数量的参数和 Headers。不仅如此，它还提供测试数据和环境配置数据的导入导出，付费的 Post Cloud 用户还能够创建自己的 Team Library 用来团队协作式的测试，并能够将自己的测试收藏夹和用例数据分享给团队。
License：免费
4、Jmeter（★★★）
官网： https://jmeter.apache.org
接口测试，性能测试
JMeter是Apache组织的开放源代码项目，它是功能和性能测试的工具，100%的用java实现；
JMeter可以用于测试静态或者动态资源的性能（文件、Servlets、Perl脚本、java对象、数据库和查询、ftp服务器或者其他的资源）。JMeter用于模拟在服务器、网络或者其他对象上附加高负载以测试他们提供服务的受压能力，或者分析他们提供的服务在不同负载条件下的总性能情况。你可以用JMeter提供的图形化界面分析性能指标或者在高负载情况下测试服务器/脚本/对象的行为。
使用Jmeter做接口测试需要注意一点，小心使用“用户定义变量”，Jmeter组件有优先级的，如果多个线程同时执行的时候，“用户定义变量”组件定义的变量可能会乱套。
License：免费
5、Loadrunner
官网： https://software.microfocus.com/en-us/products/loadrunner-load-testing/overview
性能测试
LoadRunner，是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。企业使用LoadRunner能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。 LoadRunner可适用于各种体系架构的自动负载测试，能预测系统行为并评估系统性能。
License：商业
6、Jenkins（★★★★★）
官网： https://jenkins.io
持续集成
自动化构建 编译，部署，任务执行，测试报告，邮件通知等。
License：免费
手机兼容性测试(机型选择)
测试基础理论
软件测试开发流程：
1.需求分析
在测试前拿到产品需求文档，进行需求分析及需求评审前先对需求文档进行详细的阅读，对有疑问的地方进行标注。
具体可从以下进行：
a.分析产品功能点
b.产品核心竞争力
c.Kano模型、马斯洛需求分析、多问几个为什么、上下文分析法
2.制订测试用例（重要）
工欲善其事，必先利其器；对测试而言，测试用例就是器，做好了才能把好关
a.使用思维导图列举测试大纲，尽量发散，想到什么就写什么，；先放后收，对知识点进行总结和归纳，标记重点测试模块，删除冗余及重复测试点。
b.可使用边界值法、等价类划分法、错误推测法、因果图法等设计案例
c.根据测试大纲制定测试用例，需包含模块名、测试优先级、操作步骤、期望结果、测试结果、备注
3.评审测试用例
a.测试作为主导，联合开发、项目经理、PM进行测试用例评审
b.可先讲解测试大纲，让开发、项目经理、PM心中对测试用例有个大概；后再进行详细测试用例讲解
4.执行测试
a.根据测试用例执行测试
b.发现问题保留现场，记录测试方法，通知开发解决问题
c.覆盖测试用例之外若有时间可进行探索性测试
5.提交Bug并推动Bug解决
a.在Bug管理工具上提交Bug，详细记录测试步骤
b.根据Bug严重程度划分Bug等级:致命、严重、一般、提示
c.推动开发解决问题，记录问题进展，一般聊天沟通，若问题严重则需通过邮件推动解决
6.回归测试
a.对已修复的Bug进行验证
b.对Bug所在模块进行基本功能测试；整体进行冒烟测试，确保不会因为修改Bug而引起其他功能出现问题
7.编写并提交测试报告
可使用金字塔原理设计测试报告，先总后分，上级统领下级，下级推导出上级，环环相扣
a.对Bug进行汇总，筛选出各个等级的Bug存活情况
b.制订Bug发现及解决曲线图，一般版本正常应是前期多，后期收敛，存活的是级别较低的Bug
c.总结归纳版本情况，评估发布与否
软件测试方法（★★★★★）
1. 软件测试方法 ：白盒测试、黑盒测试、灰盒测试、静态测试、动态测试
2. 白盒测试 ：是一种测试用例设计方法，在这里盒子指的是被测试的软件，白盒，顾名思义即盒子是可视的，你可以清楚盒子内部的东西以及里面是如何运作的，因此白盒测试需要你对系统内部的结构和工作原理有一个清楚的了解，并且基于这个知识来设计你的用例。
白盒测试技术一般可被分为静态分析和动态分析两类技术。
静态分析主要有：控制流分析技术、数据流分析技术、信息流分析技术。
动态分析主要有：逻辑覆盖率测试(分支测试、路径测试等)，程序插装等。
白盒测试优点：迫使测试人员去仔细的思考软件的实现；可以检测代码中的每条分支和路径；揭示隐藏在代码中的错误；对代码的测试比较彻底；最优化。
白盒测试缺点：昂贵；无法检测代码中遗漏的路径和数据敏感性错误；不验证规格的正确性
3. 黑盒测试又叫功能测试 ，这是因为在黑盒测试中主要关注被测软件的功能实现，而不是内部逻辑。在黑盒测试中，被测对象的内部结构，运作情况对测试人员是不可见的，测试人员对被测产品的验证主要是根据其规格，验证其与规格的一致性。
在绝大多数没有用户参与的黑盒测试中，最常见的测试有：功能性测试、容量测试、安全性测试、负载测试、恢复性测试、标杆测试、稳定性测试、可靠性测试等。
4. 灰盒测试 ：白盒测试和黑盒测试往往不是决然分开的，一般在白盒测试中交叉使用黑盒测试的方法，在黑盒测试中交叉使用白盒测试的方法。灰盒测试就是这类界于白盒测试和黑盒测试之间的测试。
最常见的灰盒测试是集成测试 。
5. 静态测试 ：是一种不通过执行程序而进行测试的技术。它的关键功能是检查软件的表示和描述是否一致，没有冲突或者没有歧义。
6. 动态测试 ：包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。
单元测试属于白盒测试范畴；集成测试属于灰盒测试范畴；系统测试属于黑盒测试范畴 。
CI/CD理解（★★★★★）
摘自 如何理解持续集成、持续交付、持续部署？ - yumminhuang的回答 - 知乎 如何理解持续集成、持续交付、持续部署？
持续集成
持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
持续交付
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。
持续部署
持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。
我个人觉得持续集成、持续交付、持续部署非常值得推广。开发过程中最怕集成时遇到问题导致返工，而持续集成、持续交付、持续部署恰恰可以早发现早解决，从而可以避免这个问题。
接口文档（★★★）
一、什么是接口文档？
在项目开发中，web项目的前后端分离开发，APP开发，需要由前后端工程师共同定义接口，编写接口文档，之后大家都根据这个接口文档进行开发，到项目结束前都要一直维护。
二、为什么要写接口文档？
1、项目开发过程中前后端工程师有一个统一的文件进行沟通交流开发
2、项目维护中或者项目人员更迭，方便后期人员查看、维护
三、接口规范是什么？
首先接口分为四部分：方法、uri、请求参数、返回参数
1、方法:新增(post) 修改(put) 删除(delete) 获取(get)
持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。
我个人觉得持续集成、持续交付、持续部署非常值得推广。开发过程中最怕集成时遇到问题导致返工，而持续集成、持续交付、持续部署恰恰可以早发现早解决，从而可以避免这个问题。
接口文档（★★★）
一、什么是接口文档？
在项目开发中，web项目的前后端分离开发，APP开发，需要由前后端工程师共同定义接口，编写接口文档，之后大家都根据这个接口文档进行开发，到项目结束前都要一直维护。
二、为什么要写接口文档？
1、项目开发过程中前后端工程师有一个统一的文件进行沟通交流开发
2、项目维护中或者项目人员更迭，方便后期人员查看、维
三、接口规范是什么？
首先接口分为四部分：方法、uri、请求参数、返回参数
1、方法:新增(post) 修改(put) 删除(delete) 获取(get)
示例：
请求地址：get /a/student/list
请求参数：
返回参数：
单元测试（★★★）
理解：类比电视机组装完后不能点亮，如果检测的话，需要一个一个电器器件去排查。如果从一开始对每个元器件进行测试，就能够极大程度的排除这个问题。
定义：单元测试是指，对软件中的最小可测试单元在与程序其他部分相隔离的情况下进行检查和验证的工作，这里的 最小可 测试单元通常是指 函数或者 类。
单元测试通常由开发工程师完成，一般会伴随开发代码一起递交至代码库。单元测试属于 最严格的软件测试手段，是最接近代码 底层实现的验证手段，可以在软件开发的早期以最小的成本保证局部代码的质量。另外，单元测试都是以自动化的方式执行，所以在大量 回归测试的场景下更能带来高收益。
如何设计一个好的测试用例：（★★★）
“好的”测试用例一定是一个 完备 的集合，它能够 覆盖所有等价类 以及各种 边界值 ，而跟能否发现缺陷无关。
一个“好的”测试用例，必须具备以下 三个特征 。
1. 整体完备性 ： “好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。
2. 等价类划分的准确性 ： 指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
3. 等价类集合的完备性 ： 需要保证所有可能的边界值和边界条件都已经正确识别。
三种最常用的测试用例设计方法：
等价类划分法、边界值分析法、错误推测方法。
第一，等价类划分法
我们只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
现在，我给你看一个具体的例子：学生信息系统中有一个“考试成绩”的输入项，成绩的取值范围是0~100之间的整数，考试成绩及格的分数线是60。为了测试这个输入项，显然不可能用0~100的每一个数去测试。通过需求描述可以知道，输入0~59之间的任意整数，以及输入60~100之间的任意整数，去验证和揭露输入框的潜在缺陷可以看做是等价的。
那么这就可以在0~59和60~100之间各随机抽取一个整数来进行验证。这样的设计就构成了所谓的“有效等价类”。
你不要觉得进行到这里，已经完成了等价类划分的工作，因为 等价类划分方法的另一个关键点是要找出所有“无效等价类” 。显然，如果输入的成绩是负数，或者是大于100的数等都构成了“无效等价类”。
在考虑了无效等价类后，最终设计的测试用例为：
有效等价类1：0~59之间的任意整数；
有效等价类2：59~100之间的任意整数；
无效等价类1：小于0的负数；
无效等价类2：大于100的整数；
无效等价类3：0~100之间的任何浮点数；
无效等价类4：其他任意非数字字符。
第二，边界值分析方法
边界值分析是对等价类划分的补充，你从工程实践经验中可以发现，大量的错误发生在输入输出的边界值上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
我们继续看学生信息系统中“考试成绩”的例子，选取的边界值数据应该包
括：-1，0，1，59，60，61，99，100，101。
第三，错误推测方法
错误推测方法是指 基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。 这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。
错误推测法和目前非常流行的“探索式测试方法”的基本思想和理念是不谋而合的，这类方法在目前的敏捷开发模式下的投入产出比很高，因此被广泛应用。但是，这个方法的缺点也显而易见，那就是难以系统化，并且过度依赖个人能力。
总结：在我看来，深入理解被测软件需求的最好方法是，测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。
上文摘自《测试工程师全栈技术进阶与实践》 茹炳晟
针对某一个产品写测试用例：（★★★★★）
此类问题几乎每个面试官都会问！基本思路：可以从功能测试，UI测试，稳定性测试，压力测试（边界极限），安全测试，本地化测试等角度去考虑
测试水杯（★）
1、基本功能测试
硬度：是否达到设计标准
装载能力：在杯子内分别装入少量的、半杯的、潢杯的，看其装载量是否达到设计标准
装载种类：开水(是否产生异味）、温水、冷水、咖啡
用水杯装水看漏不漏；水能不能被喝到
输入条件： 冷水，热水，冰水。。。
输出条件： 是否退色 是否变形 是否有毒
一杯开水（假定100摄氏度）保温的时间（多久后变到室温），自然还有冰块在室温下多长时间融化
2、界面测试(UI测试)
看其形状、大小设计是否符合需求规格说明书的定义，适合人方便拿起喝水；
外观是否吸引人，赏心悦目；
广告图案沾水后是否掉色、模糊；
广告图案是否使用环保材料、不影响使用者健康和回收再利用；
广告图案是否和当地政治、宗教符合，没有冲突；
广告图案是否做到了本地化和国际化。
3、易用性测试
看其形状、大小设计是否适合人方便拿起；
残疾人士用此杯去喝水的容易程度；
杯子设计是否上大下小，在运输过程中可以套在一起有效利用空间，在使用时也容易拿开
4、稳定性测试（24*7）
装入液体后记录其多久以后会漏水；
5、安全性测试
杯子所用的材料（包括纸基、涂层和广告颜料)是否符合食品卫生标准，在内外温度待环境因素下是否会与所盛各种饮料反应，而产生对人体有害的物质；
6、本地化测试
为国际化和本地化的需要，广告图案和文字是否在政治、宗教和文化方面具有广泛的适用性；
安全性：杯子有没有毒或细菌；
可靠性：杯子从不同高度落下的损坏程度；
可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用；
7、对设计的改进建议
“如果是一次性杯子，能否标示已使用(比如：变色)”和“杯子是否有使用者标贴（多人使用时防止混淆)”。
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
8、 性能测试
温度/杯质的抗压力/寿命/广告漆的耐久度/等等
测试一个输入框(计数)（★★）
相信不少朋友在笔试的时候都遇到过测试用例设计的笔试题。通常是一个登陆页面，上面有用户名，密码的输入框，再多一点的有个验证码。
不过要是你见到的是以下的这道测试用例设计笔试题，不用问，面试官一定是看过《Google软件测试之道》的。（也脑补一下，万一面试官是看过CC先生的简书呢…… 嗯嗯，梦想还是要有的）
出题时间：
在一个Web测试页面上，有一个输入框，一个计数器（count）按钮，用于计算一个文本字符串中字母a出现的个数。这里的问题是，请设计一系列测试用例用以测试这个Web页面。
很多朋友可能拿到这道题的时候已经开始写下1.2.3.了，不过根据经验上来说，追求数量而非质量的倾向，是一种低效的工作方式。（特别在有面试官在旁边看到你答题的时候，请保持沉思者状保持10-15秒）
能够针对题目提出一些问题来的候选者会被认为更有潜质来做测试人员，比如大写还是小写？只是英语吗？计算完成后文本会被清除吗？多次按下按钮会发生什么事情？诸如此类。
通常说来，我们考虑一个测试对象的时候至少从以下六方面来考虑。
功能性
易用性
可靠性
性能
安全
兼容性
如果你是一个测试菜鸟，从功能性出发，你可能会列出以下一个典型的列表：
“banana”：3（一个合法的英文字）。
“A” 和“a”：1（一个简单有正常结果的合法输入）。
“”：0（一个简单的结果为0的合法输入）。
Null：0（简单的错误输入）。
“AA” 和“aa”：2（个数大于1并且所有字符都为a/A的输入）。
“b”：0（一个简单的非空合法输入，结果为0）。
“aba”：2（目标字符出现在开头和结尾，以寻找循环边界错误）。
“bab”：1（目标字符出现在中间）。
space/tabs：N（空白字符与N个a的混合）。
不包含a的长字符串：N（N大于0）。
包含a的长字符串：N（N是a的倍数，试试龙妈的名字）。
{java/C/HTML/JavaScript}：N是a出现的个数（可执行字符，或错误，或代码解释）。
….
更优秀的测试工程师，会开始考虑后面五个方面，设计以下用例。
质疑界面的外观、调色板和对比度（这与相关应用风格一致么？）
文本框太小了，建议加长以便显示更长的输入字符串
这个应用能否在同一台服务器上运行多个实例，多个用户同时使用是否会有问题。
是否会根据用户的输入自动匹配内容？
建议使用真实的数据，如从词典或书中选择输入内容。
提出疑问：“输入的数据是否会被保存”，输入字符串可能包含地址或其他身份信息。
输入HTML和JavaScrip，看是否会破坏页面渲染。
尝试复制/粘贴字符串。
提出疑问：“计算足够快么？在大并发下使用”。
提出疑问：“用户怎么找到该页面？”
提出疑问：“有快捷键的设置么？比如输完字符后敲入回车键而不是点击提交按钮”
还有一些测试点，只有经验丰富的测试工程师才会想到。
意识到计算会通过URL-encodedHTTP GET请求传递到服务器，字符串可能会在网络传输时被截断，因此，无法保证支持多长的URL。
建议将此功能参数化，为什么只对字母a计算呢？
考虑计算其它语言中的a（α，Alpha）。
考虑到该应用是否应该国际化。
考虑到输入法全角输入和半角输入是否相同。
考虑编写脚本或者手工采样来探知字符串长度的上限，然后确保在此区间内功能正常。
考虑背后的实现和代码。也许已经有一个计数器遍历该字符串。
提出疑问：“HTTP POST方法和参数会被黑掉码？也许有安全漏洞？”
用脚本创建各种有趣的排列组合和字符串特性，如长度、a的个数等，自动生成测试输入和验证。
针对“用户登录”设计测试用例（★★★）
以用户登录为例，一般的小白可能只能够想到一些功能性测试（如下）。
现在，针对“用户登录”功能，基于等价类划分和边界值分析方法，我们设计的测试用例包括：
1. 输入已注册的用户名和正确的密码，验证是否登录成功；
2. 输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确；
3. 输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确；
4. 用户名和密码两者都为空，验证是否登录失败，并且提示信息正确；
5. 用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确；
6. 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，验证是否登录成功；
7. 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登
录失败，并且提示信息正确。
的确，上面的测试用例集已经涵盖了主要的功能测试场景。但是在一个优秀的测试工程师眼中，这些用例只能达到勉强及格的标准。
现在，我跟你分享一下有经验的测试工程师会再增加的测试用例：
1. 用户名和密码是否大小写敏感；
2. 页面上的密码框是否加密显示；
3. 后台系统创建的用户第一次登录成功时，是否提示修改密码；
4. 忘记用户名和忘记密码的功能是否可用；
5. 前端页面是否根据设计要求限制用户名和密码长度；
6. 如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用；
7. 刷新页面是否会刷新验证码；
8. 如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
9. 用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；
10. 不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；
11. 页面默认焦点是否定位在用户名的输入框中；
12. 快捷键Tab 和Enter等，是否可以正常使用。
从软件测试的维度来看，还应该包含非功能性需求。主要涉及 安全性、性能以及兼容性 三大方面。 在上面所有的测试用例设计中，我们完全没有考虑对非功能性需求的测试，但这些往往是决定软件质量的关键因素。
安全性测试用例包括：
1. 用户密码后台存储是否加密；
2. 用户密码在网络传输过程中是否加密；
3. 密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；
4. 不登录的情况下，在浏览器中直接输入登录后的URL地址，验证是否会重新定向到用户登录界面；
5. 密码输入框是否不支持复制和粘贴；
6. 密码输入框内输入的密码是否都可以在页面源码模式下被查看；
7. 用户名和密码的输入框中分别输入典型的“SQL注入攻击”字符串，验证系统的返回页面；
8. 用户名和密码的输入框中分别输入典型的“XSS跨站脚本攻击”字符串，验证系统行为是否被篡改；
9. 连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
10. 同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
11. 同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。
性能压力测试用例包括:
1. 单用户登录的响应时间是否小于3秒；
2. 单用户登录时，后台请求数量是否过多；
3. 高并发场景下用户登录的响应时间是否小于5秒
4. 高并发场景下服务端的监控指标是否符合预期；
5. 高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
6. 长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。
兼容性测试用例包括：
1. 不同浏览器下，验证登录页面的显示以及功能正确性；
2. 相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
3. 不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
4. 不同分辨率的界面下，验证登录页面的显示以及功能正确性。
微信红包测试用例（★★★★★）
单个红包：
1、红包金额为空、0、0.01、200.00、200.01、199.99、200
2、留言输入数字、字母、汉字、特殊字符
3、留言长度
4、留言复制粘贴
5、表情选择收藏表情、其他表情
6、删除表情、重新选择表情
7、选择支付方式 零钱、银行卡、添加新卡支付。其中钱数<红包钱数、其中钱数=红包钱数、其中钱数>红包钱数
8、使用指纹确认付款（正确的、错误的指纹）
9、使用密码确认付款（正确的、错误的密码）
10、红包成功发送后 相应支付方式中钱数减少（减少金额与红包金额一致）
11、接受者能看到红包具体信息，红包金额、留言、表情均能正确显示
12、红包被拆开后显示已领取，领取者零钱中增加正确金额，再次领取只能查看红包信息
13、发红包者自己领红包
14、红包24小时未被领取提示红包被退回，相应支付方式中钱数增加（增加金额与红包金额一致），对方不能领红包
群发红包-普通红包： （只写了与单个红包不同的地方）
1、红包个数 为空、0、001、100、99、101
2、红包拆开每个金额一样 均为发红包时设置的单个金额对应的钱数
3、红包被拆时，有相应提示
4、发红包者自己领红包
5、红包24小时内未被拆完，剩余钱被退回，相应支付方式中钱数增加
群发红包-拼手气红包：
1、红包总额/红包个数<0.01
2、红包每个人拆开金额不同，总金额与发红包设置的总额一致
3、红包24小时内拆完后显示最佳手气
4、红包24小时内未被拆完不显示最佳手气
兼容性： 安卓、苹果 不同型号版本手机
UI测试： 界面无错别字，风格统一
中断测试： 不同应用之间切换、断网、来电、短信、低电量、手机没电
网络测试： 2g/3g/4gWiFi 移动联通电信弱网无网
微信朋友圈测试用例（★★★★★）
功能测试
1、朋友圈发送功能
1）只发送文本
a、考虑文本长度：1-1500字符（该数据为百度数据）、超出最大字符长度
b、文本是否支持复制粘贴
c、为空验证
2）只发送图片
a、本地相册选择/拍摄
b、图片数量验证：1-9张图片、超出9张
c、为空验证
3）只发送视频
a、本地相册选择/拍摄
b、视频秒数验证：1-10s，超出10s
c、视频个数验证：1个，超出1个
d、视频格式验证：支持的视频格式，例mp4、不支持的视频格式
e、视频大小验证：苹果400kb以内、Android200-300kb（此为百度数据）、超出规定大小
f、视频预览增删改操作
g、为空验证
4）发送文本+图片：输入满足要求的文本、图片进行一次验证
5）发送文本+视频：输入满足要求的文本、视频进行一次验证
6）发送图片+视频：不支持发送
7）朋友圈发送内容是否有限制，例如涉及黄赌毒等敏感字
8）所在位置
a、不显示位置：发送到朋友圈动态不显示位置
b、选择对应位置：搜索支持、自动定位、手动编辑
C、点击取消，返回上一级页面
9）谁可以看
a、设置公开：所有朋友可见
b、设置私密（仅自己可见）：自己查看朋友圈-可见、好友查看朋友圈-不可见
c、设置部分可见（部分朋友可见）：选择的部分好友-可见、不被选择的好友-不可见、是否有人数上限
d、设置不给谁看（选中的朋友不可见）：不被选中的朋友-可见、被选中的朋友-不可见、是否有人数上限
e、点击取消，返回发送页面
10）提醒谁看
a、提醒单人/提醒多人：被提醒的朋友-收到消息提醒、未被提醒-未有消息提醒
b、是否有人数上限
c、点击取消，返回发送页面
11）同步QQ空间：默认不同步、同步到QQ空间
12）取消发送朋友圈操作
a、选择相机，点击取消，返回朋友圈页面
b、进入朋友圈发送页面，选择文本图片，点击取消
13）朋友圈当天发送次数是否有上限限制
2、朋友圈浏览功能
1）文本查看：
a、过长文本内容是否隐藏，并支持查看全文
b、右键选择复制、收藏、翻译
c、url链接是否支持点击跳转网页
2）图片查看
a、小图右键支持收藏/编辑
b、点击支持大图浏览
c、选择发送给朋友、收藏、保存图片、编辑
d、多张图片支持左右滑动浏览
3）视频查看
a、右键视频支持静音播放/搜藏
b、点击视频播放按键支持播放视频
c、选择发送给朋友、收藏、保存视频、编辑
4）分享动态浏览：QQ空间/公众号文章/非腾讯产品分享后朋友圈是否正常显示
5）赞：点赞、取消点赞
6）评论
a、评论长度：评论字数合理长度、评论超过字数上限
b、评论类型：纯中文、纯数字、纯字母、纯字符、纯表情（微信表情/手机自带表情）、混合类型、包含url链接；
c、评论是否支持复制粘贴
d、为空验证
e、发表评论后删除
f、评论回复操作
7）删除朋友圈动态
8）更换相册封面
9）刷新是否正常获取新动态
10）上滑是否加载更多
界面/易用性测试
1、技术人员角度：页面布局设计是否跟产品原型图/ui效果图一致
2、但除了考虑1之外，我们同样要考虑到用户使用：功能操作是否简便，页面布局排版风格是否美观合理，提示语相关信息是否易于理解
中断测试
1、主要考虑：a)核心功能b)当前功能存在实时数据交换，例发朋友圈、浏览朋友圈进行中断，是否容易出现崩溃
2、中断包括：前后台切换、锁屏解锁、断网重连、app切换、来电话/来短信中断、插拔耳机线/数据线
网络测试
1、三大运营商不同网络制式测试
2、网络切换测试：WIFI/4G/3G/2G
3、无网测试：对于缓存在本地的数据，部分朋友圈信息是否支持浏览
4、弱网测试：
a、延时：页面响应时间是否可接受、不同网络制式是否区分超时时长、出现请求超时，是否给予相应的提示
b、丢包：有无超时重连机制、如果未响应，是否给予相应提示
c、页面呈现的完整性验证
兼容性测试
1、Android手机端、苹果手机端、pad版（主流）功能界面显示是否正常
2、各平台朋友圈展示数据是否一致
安全测试
发送朋友圈时，文本输入脚本代码，是否出现异常
性能测试
1、服务器性能测试
可通过loadrunner/jmeter工具实现，主要关注TPS、响应时间、吞吐量、CPU、内存等
2、app客户端性能测试
可通过GT工具实现，运行时关注cpu、内存、流量、电量等占用率
3、app压力稳定性测试
通过monkey工具实现，频繁发送朋友圈，浏览朋友圈请求，是否容易发生崩溃
----------------------------- [爱]
干杯
页:
[1]