测试笔记-
1.软件测试的目的是：
发现错误而执行程序的过程，不涉及改错。
2.程序调试的基本步骤：
错误定位、修改设计和代码，以排除错误、进行回归测试，防止引进新的错误。称为Debug，即排错。
3.软件测试的基本准则：
所有测试都应追溯到需求、严格执行测试计划，排除测试的随意性、充分注意测试中的群集现象、程序员应避免检查自己的程序、穷举测试不可能、妥善保存测试计划等文件。
4.软件测试主要包括：
单元测试、集成测试、确认测试、系统测试
5.疲劳强度是：
指材料在无限多次交变载荷作用而不会产生破坏的最大应力，称为疲劳强度或疲劳极限。就像寻找项目的极值，当到达极值后，会首先出现内存泄漏。
6.测试用例设计
https://blog.csdn.net/wanglilingb/article/details/54019467?ops_request_misc=&request_id=&biz_id=102&utm_term=%E6%B5%8B%E8%AF%95%E7%94%A8%E4%BE%8B%E8%AE%BE%E8%AE%A1&utm_medium=distribute.pc_search_result.none-task-blog-2allsobaiduweb~default-4-54019467.nonecase&spm=1018.2226.3001.4187
7.负载测试：
负载测试是模拟在超负荷环境中运行，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。负载测试更多地体现了一种方法或一种技术。
8.强度测试：
强度测试是一种性能测试，它在系统资源特别低的情况下软件系统运行情况。例如，①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；②定量地增长数据输入率，检查输入子功能的反映能力；③运行需要最大存储空间（或其他资源）的测试用例；④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。
9.容量测试：
确定系统可处理同时在线的最大用户数。容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。
10.编写测试用例的目的：
- 从测试用例追溯回功能需求以确保没有需求被疏忽
- 用测试用例来验证产品需求模型的正确性
- 通过测试用例以确认是否达到了产品期望的要求
11.集成测试的过程包括：
- 构建的确认过程
- 系统集成测试测试组提交过程
- 测试用例设计过程
- Bug的报告过程
12.测试驱动开发：
TDD，Teat Driven Development
13.某典型基准测试程序在A上运行时20s，B25s：
机器A的平均CPI是B的1.25倍
CPI：Clock Cycles Per Instruction：每条指令的平均时钟周期个数。本题没有说两机器时钟周期一样，所以不能说一定有倍数关系。
A的平均CPI：1/20=0.05
B的平均CPI：1/25=0.04
0.05/0.04=1.25
14.单元测试：
详细设计文档；集成测试：概括设计文档；系统测试：系统设计文档
15.如果某测试用例集实现了某软件的路径覆盖，那么它一定同时实现了该软件的：判定覆盖
判定覆盖是每个判定的真假一次，就会导致所有的结果路径会实现；
条件覆盖是每个判定里的条件各取一次，不一定会产生所有的结果。
16.程序片中，所定义的变量未被使用可以通过哪种测试方法进行定位：
数据流测试
数据流测试按照程序中的变量定义和使用的位置来选择程序的测试路径
17.
风险曝光度等于风险发生的概率乘以风险发生时带来的项目成本
（20×100×150）×（1 - 0.5）×0.6 = 90000
18.项目立项前测试人员不需要提交任何工件。工件是加工过程中的生产对象。
19.白盒测试是基于代码的测试，通过程序代码或者通过开发工具找出软件的缺陷。总体分类两类：静态方法，动态方法。
静态方法：
不通过执行程序而进行测试的技术。关键功能是检查软件的表示和描述是否一致，没有冲突或没有歧义。
动态方法：
动态分析的主要特点是当软件系统在模拟的或真实的环境中执行之前、之中和之后，对软件系统行为的分析。动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。在动态分析技术中，最重要的技术是路径和分支测试。
20.测试工具：
| 工具 | 功能 |
|---|---|
| Appium | AppUI自动化测试 |
| Selenium | WebUI自动化测试 |
| Postman | 接口测试 |
| Jmeter | 接口测试，性能测试 |
| Loadrunner | 性能测试，负载测试 |
| Jenkins | 持续集成。自动化构建 编译，部署，任务执行，测试报告，邮件通知 |
21.测试分为：
个人审查、抽查和审查、黑盒测试、白盒测试
黑盒测试方法有： 等价类划分法、边界值分析法、因果图法、错误推测法、综合策略、正交分析法，用于软件的确认测试
白盒测试方法有： 逻辑覆盖发法，主要包括语句覆盖、判断覆盖、条件覆盖、判断条件覆盖、条件组合覆盖、路径覆盖
22.手机兼容性测试
23.软件测试开发流程：
1.需求分析： 在测试前拿到产品需求文档，进行需求分析及需求评审前先对需求文档进行详细的阅读，对有疑问的地方进行标注。
具体可从以下进行：
1. 分析产品功能点
2. 产品核心竞争力
3. 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. 总结归纳版本情况，评估发布与否
24.软件测试方法：
- 软件测试方法 ： 白盒测试、黑盒测试、灰盒测试、静态测试、动态测试
- 白盒测试 ： 是一种测试用例设计方法，在这里盒子指的是被测试的软件，白盒，顾名思义即盒子是可视的，你可以清楚盒子内部的东西以及里面是如何运作的，因此白盒测试需要你对系统内部的结构和工作原理有一个清楚的了解，并且基于这个知识来设计你的用例。
白盒测试技术一般可被分为静态分析和动态分析两类技术。
静态分析主要有： 控制流分析技术、数据流分析技术、信息流分析技术。
动态分析主要有： 逻辑覆盖率测试(分支测试、路径测试等)，程序插装等。
白盒测试优点： 迫使测试人员去仔细的思考软件的实现；可以检测代码中的每条分支和路径；揭示隐藏在代码中的错误；对代码的测试比较彻底；最优化。
白盒测试缺点： 昂贵；无法检测代码中遗漏的路径和数据敏感性错误；不验证规格的正确性。
- 黑盒测试 又叫功能测试 ，这是因为在黑盒测试中主要关注被测软件的功能实现，而不是内部逻辑。在黑盒测试中，被测对象的内部结构，运作情况对测试人员是不可见的，测试人员对被测产品的验证主要是根据其规格，验证其与规格的一致性。
在绝大多数没有用户参与的黑盒测试中，最常见的测试有：功能性测试、容量测试、安全性测试、负载测试、恢复性测试、标杆测试、稳定性测试、可靠性测试等。
- 灰盒测试 ： 白盒测试和黑盒测试往往不是决然分开的，一般在白盒测试中交叉使用黑盒测试的方法，在黑盒测试中交叉使用白盒测试的方法。灰盒测试就是这类界于白盒测试和黑盒测试之间的测试。
最常见的灰盒测试是集成测试 。
- 静态测试： 是一种不通过执行程序而进行测试的技术。它的关键功能是检查软件的表示和描述是否一致，没有冲突或者没有歧义。
- 动态测试 ： 包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。
单元测试属于白盒测试范畴；集成测试属于灰盒测试范畴；系统测试属于黑盒测试范畴 。
25.CI/CD理解
持续集成
持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
持续交付
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。 比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。
持续部署
持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。
开发过程中最怕集成时遇到问题导致返工，而持续集成、持续交付、持续部署恰恰可以早发现早解决，从而可以避免这个问题。
26.如何设计一个好的测试用例：
“好的”测试用例一定是一个 完备 的集合，它能够 覆盖所有等价类 以及各种 边界值 ，而跟能否发现缺陷无关。
一个“好的”测试用例，必须具备以下 三个特征 。
- 整体完备性 ： “好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。
- 等价类划分的准确性 ： 指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
- 等价类集合的完备性 ： 需要保证所有可能的边界值和边界条件都已经正确识别。
三种最常用的测试用例设计方法：
等价类划分法、边界值分析法、错误推测方法。
第一，等价类划分法
我们只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
现在，我给你看一个具体的例子：学生信息系统中有一个“考试成绩”的输入项，成绩的取值范围是0100之间的整数，考试成绩及格的分数线是60。为了测试这个输入项，显然不可能用0100的每一个数去测试。通过需求描述可以知道，输入059之间的任意整数，以及输入60100之间的任意整数，去验证和揭露输入框的潜在缺陷可以看做是等价的。
那么这就可以在059和60100之间各随机抽取一个整数来进行验证。这样的设计就构成了所谓的“有效等价类”。
你不要觉得进行到这里，已经完成了等价类划分的工作，因为 等价类划分方法的另一个关键点是要找出所有“无效等价类” 。显然，如果输入的成绩是负数，或者是大于100的数等都构成了“无效等价类”。
在考虑了无效等价类后，最终设计的测试用例为：
有效等价类1：0~59之间的任意整数；
有效等价类2：59~100之间的任意整数；
无效等价类1：小于0的负数；
无效等价类2：大于100的整数；
无效等价类3：0~100之间的任何浮点数；
无效等价类4：其他任意非数字字符。
第二，边界值分析方法
边界值分析是对等价类划分的补充，你从工程实践经验中可以发现，大量的错误发生在输入输出的边界值上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
我们继续看学生信息系统中“考试成绩”的例子，选取的边界值数据应该包
括：-1，0，1，59，60，61，99，100，101。
第三，错误推测方法
错误推测方法是指 基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法 。 这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。
错误推测法和目前非常流行的“探索式测试方法”的基本思想和理念是不谋而合的，这类方法在目前的敏捷开发模式下的投入产出比很高，因此被广泛应用。但是，这个方法的缺点也显而易见，那就是难以系统化，并且过度依赖个人能力。
总结：在我看来，深入理解被测软件需求的最好方法是，测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。
摘自《测试工程师全栈技术进阶与实践》茹炳晟
27.针对某一个产品写测试用例：
测试水杯（★）
1、基本功能测试
硬度：是否达到设计标准
装载能力：在杯子内分别装入少量的、半杯的、潢杯的，看其装载量是否达到设计标准
装载种类：开水(是否产生异味）、温水、冷水、咖啡
用水杯装水看漏不漏；水能不能被喝到
输入条件： 冷水，热水，冰水。。。
输出条件： 是否退色 是否变形 是否有毒
一杯开水（假定100摄氏度）保温的时间（多久后变到室温），自然还有冰块在室温下多长时间融化
2、界面测试(UI测试)
看其形状、大小设计是否符合需求规格说明书的定义，适合人方便拿起喝水；
外观是否吸引人，赏心悦目；
广告图案沾水后是否掉色、模糊；
广告图案是否使用环保材料、不影响使用者健康和回收再利用；
广告图案是否和当地政治、宗教符合，没有冲突；
广告图案是否做到了本地化和国际化。
3、易用性测试
看其形状、大小设计是否适合人方便拿起；
残疾人士用此杯去喝水的容易程度；
杯子设计是否上大下小，在运输过程中可以套在一起有效利用空间，在使用时也容易拿开
4、稳定性测试（24*7）
装入液体后记录其多久以后会漏水；
5、安全性测试
杯子所用的材料（包括纸基、涂层和广告颜料)是否符合食品卫生标准，在内外温度待环境因素下是否会与所盛各种饮料反应，而产生对人体有害的物质；
6、本地化测试
为国际化和本地化的需要，广告图案和文字是否在政治、宗教和文化方面具有广泛的适用性；
安全性：杯子有没有毒或细菌；
可靠性：杯子从不同高度落下的损坏程度；
可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用；
7、对设计的改进建议
“如果是一次性杯子，能否标示已使用(比如：变色)”和“杯子是否有使用者标贴（多人使用时防止混淆)”。
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
8、 性能测试
温度/杯质的抗压力/寿命/广告漆的耐久度/等等
作者：NanamiKento
链接：https://www.nowcoder.com/discuss/607662
来源：牛客网
测试一个输入框(计数)（★★）
相信不少朋友在笔试的时候都遇到过测试用例设计的笔试题。通常是一个登陆页面，上面有用户名，密码的输入框，再多一点的有个验证码。
不过要是你见到的是以下的这道测试用例设计笔试题，不用问，面试官一定是看过《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的个数等，自动生成测试输入和验证。
针对“用户登录”设计测试用例（★★★）
以用户登录为例，一般的小白可能只能够想到一些功能性测试（如下）。
现在，针对“用户登录”功能，基于等价类划分和边界值分析方法，我们设计的测试用例包括：
- 输入已注册的用户名和正确的密码，验证是否登录成功；
- 输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确；
- 输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确；
- 用户名和密码两者都为空，验证是否登录失败，并且提示信息正确；
- 用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确；
- 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，验证是否登录成功；
- 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登录失败，并且提示信息正确。
的确，上面的测试用例集已经涵盖了主要的功能测试场景。但是在一个优秀的测试工程师眼中，这些用例只能达到勉强及格的标准。
现在，我跟你分享一下有经验的测试工程师会再增加的测试用例：
- 用户名和密码是否大小写敏感；
- 页面上的密码框是否加密显示；
- 后台系统创建的用户第一次登录成功时，是否提示修改密码；
- 忘记用户名和忘记密码的功能是否可用；
- 前端页面是否根据设计要求限制用户名和密码长度；
- 如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用；
- 刷新页面是否会刷新验证码；
- 如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
- 用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；
- 不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；
- 页面默认焦点是否定位在用户名的输入框中；
- 快捷键Tab 和Enter等，是否可以正常使用。
从软件测试的维度来看，还应该包含非功能性需求。主要涉及 安全性、性能以及兼容性 三大方面。 在上面所有的测试用例设计中，我们完全没有考虑对非功能性需求的测试，但这些往往是决定软件质量的关键因素。
安全性测试用例包括：
- 用户密码后台存储是否加密；
- 用户密码在网络传输过程中是否加密；
- 密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；
- 不登录的情况下，在浏览器中直接输入登录后的URL地址，验证是否会重新定向到用户登录界面；
- 密码输入框是否不支持复制和粘贴；
- 密码输入框内输入的密码是否都可以在页面源码模式下被查看；
- 用户名和密码的输入框中分别输入典型的“SQL注入攻击”字符串，验证系统的返回页面；
- 用户名和密码的输入框中分别输入典型的“XSS跨站脚本攻击”字符串，验证系统行为是否被篡改；
- 连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
- 同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
- 同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。
性能压力测试用例包括:
- 单用户登录的响应时间是否小于3秒；
- 单用户登录时，后台请求数量是否过多；
- 高并发场景下用户登录的响应时间是否小于5秒；
- 高并发场景下服务端的监控指标是否符合预期；
- 高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
- 长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。
兼容性测试用例包括：
- 不同浏览器下，验证登录页面的显示以及功能正确性；
- 相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
- 不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
- 不同分辨率的界面下，验证登录页面的显示以及功能正确性。
微信红包测试用例（★★★★★）
单个红包：
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/4g WiFi 移动联通电信 弱网 无网
微信朋友圈测试用例（★★★★★）
功能测试
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工具实现，频繁发送朋友圈，浏览朋友圈请求，是否容易发生崩溃
28.智力题
- 1000 瓶无色无味的药水，其中有一瓶毒药，10只小白鼠拿过来做实验。喝了无毒的药水第二天没事儿，喝了有毒的药水后第二天会死亡。如何在一天之内(第二天)找出这瓶有毒的药水？（被问过）
- 现在有9个球，其中有1个球相对轻一点。你手里只有一个天平，称2次，怎样找出那个轻的球？（被问过）
- 25匹马赛跑，共有5个赛道，最少赛多少次可以找出前三名、前五名？（被问得太多）
- 64匹马赛跑，8个赛道的问题。
- 一个瓶子，有三种颜色糖果，问多少次，能确保拿到两个颜色一致的糖果。
- 70克盐，20克砝码，一个天平，称出5克盐。
- 两个杯子倒水：一个7升，一个3升，如何在一个杯子倒出5升？（被广州一家公司问过，公司名字我记不太清了，当时说了两种方法）
8.两根分布不均匀的蜡烛,每根燃烧的时间是一个小时,问怎样算出15分钟的时间?（秋招时上海美团三面有问，一开始没思路，面试官一直在引导）
菜鸟轻松拿offer
软件质量
一个高质量的软件应该具有哪些特性？
满足用户需求、能够在一定程度上适应需求的变更、有效的处理能力以及可持续发展，兼顾成本。
质量模型
| 方面 | |
|---|---|
| 功能性 | 正常性、完备性、适合性、依从性 |
| 性能 | 时间特性、资源利用率、容量 |
| 兼容性 | 共存性、互操作性 |
| 易用性 | 易辩识性、易学性、易理解性、易操作性 |
| 可靠性 | 成熟度、可用性、容错性、易恢复性 |
| 安全性 | 保密性、完整性、不可抵赖、可审核性、真实性 |
| 可维护性 | 模块化、可复用性、易分析性、易修改性、易测试性、稳定性 |
| 可移植性 | 适应性、一致性、可安装性、可替换性 |
为什么开展软件测试工作？
防止软件上线后出现宕机、死顿、功能模块不能使用等情况，预先测试保证软件质量，保证企业信誉。
软件测试的目的？
预防错误，发现错误，以保证软件质量
如何保证软件质量？
项目需要整个团队的努力。
制定规范项目流程；做好计划与预判；保证设计的延续性；严格遵循开发规范操作；测试方面，验证产品逻辑的同时，多站在用户角度进行验证，尽可能多的使用技术手段保证测试质量；每个版本结束后进行总结，对本版本工作进行回顾，对下一个版本进行预估。