黑盒测试

测试人员不关注内部代码的实现 , 通过一些科学的手段 , 向测试系统发起测试数据 , 关注结果是否与预期结果一致

黑盒测试的缺点是 不可能覆盖所有代码

黑盒测试用到的测试方法有 : 等价类 , 边界值 , 判定表 , 正交表 , 场景设计 , 错误猜测

基于需求的设计方法

1. 功能测试需求

业务流程相关 ( 需求规格说明书 )
界面 ( UI设计稿 )
易用性 ( 测试人员经验 )
…

2. 非功能测试需求

外部大型复杂网络应用系统，比如电子商务，网上银行，视频网站（腾讯，优酷）等，除了有复杂的系统的功能测试需求外，在 系统的 性能，安全性，兼容性，网络 等都有很高的要求。

等价类

依据需求将输入划分为若干个等价类，从等价类中选出一个测试用例，
如果这个测试用例测试通过，则认为所代表的等价类测试通过，
这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

• 有效等价类：满足用户需求输入的集合
• 无效等价类：不满足用户输入需求的集合

例如 : 在登录页面要输入用户名

边界值

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。
通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界

判定表

判定表是一种 表达 逻辑判断 的工具

关系 :

1. 与 ( && ) 所有条件满足 则真
2. 或 ( | | ) 满足其中一个条件 则真
3. 非 ( ! ) 条件为假 , 结果才真
4. 恒等 ( == ) 条件为真 , 结果一定真

• 如何设计测试用例

1. 分析所有 可能的输入和输出
2. 找出 输入与输出之间的 对应关系
3. 设计判定表
4. 将判定表对应到 每一个测试用例

例如 : 淘宝搞活动 , 订单已提交 , 订单合计金额大于 300元 或 有红包 , 就有优惠

输入 : 订单已提交 , 金额大于 300 , 有红包
输出 : 优惠 , 不优惠

正交表

因素 : 输入变量
水平 : 每一个输入变量取值

性质1 : 每一列中 , 各数字出现的次数都一样多
性质2 : 任意两列中各有序数对出现的次数一样多

• 通过正交表设计测试用例
  

以 注册邮箱 为例 :
因素 : 姓名 , 邮箱 , 密码 , 确认密码 , 验证码
水平 : 填写 , 不填写

场景设计法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流

错误猜测法

错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。

这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。
错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应运于测试。
这个方法的缺点是难以系统化，并且过度依赖个人能力。

Fiddler

Postman

测试用例

• 水杯测试用例
  

• 微信发送朋友圈
  

• 登录页面
  

• 淘宝购物车
  

测试分类

按测试对象

界面测试

界面测试（简称UI测试)，指按照界面的需求（一般是UI设计稿）和界面的设计规则，对我们软件界面所展示的全部内容进行测试和检查

1. 验证界面内容显示的完整性，一致性，准确性，友好性。比如界面内容对屏幕大小的自适应，换行，内容是否全部清晰展示；
2. 验证整个界面布局和排版是否合理，不同板块字体的设计，图片的展示是否符合需求；
3. 对界面不同控件的测试，比如，对话框，文本框，滚动条，选项按钮等是否可以正常使用，有效和无效的状态是否设计合理；
4. 界面的布局和色调符合当下时事的发展。

可靠性测试

可靠性（Availability）即可用性，是指系统正常运行的能力或者程度，一般用正常向用户提供软件服务的时间占总时间的百分比表示。
可靠性 = 正常运行时间/（正常运行时间+非正常运行时间）*100%

系统非正常运行的时间可能是由于硬件，软件，网络故障或任何其他因素（如断电）造成的，这些因素能让系统停止工作，或者连接中断不能被访问，或者性能急剧降低导致不能使用软件现有的服务等。可用性指标一般要求达到4个或5个“9”，即99.99%(不到一小时不工作)或者99.999%(不到5分钟)

容错性测试

指系统能够处理异常，用户的错误操作而不至于系统崩溃，从而能够提高系统的可用性。

容错性测试包含以下方面：

1. 输入异常数据或进行异常操作，以检验系统的保护性。
   如果系统的容错性好，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。(比如数据级测试，校验测试，环境容错性测试，界面容错性测试)
2. 灾难恢复性测试。
   通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复。

文档测试

• 开发文件 ：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。

• 用户文件 : 用户手册、操作手册，用户文档的作用 ; 改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本。

• 管理文件 ：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
  在实际的测试中，最常见的是用户文件的测试，例如：手册说明书等。也会有一些公司对需求文档进行测试，来保证需求文档的质量。

兼容性测试

易用性

1. 规范性
现有的软件运行平台通常其UI标准已经不知不觉地被确立了，成为大家的共识。
多数用户已经习惯并且接受了这些标准和规范，或者说已经认同了这些信息所代表的的含义。

2. 直观性
求软件功能特性易懂，清晰。用户界面布局合理，对操作的响应在用户的预期之中

3. 舒适性
界面友好，美观，操作过程顺畅，色彩用运恰当，按钮的立体感

4. 灵活性
以有不同的选项以满足不同使用习惯的用户来完成相同的功能
例如手机键盘有九宫格和全键盘，还支持手写，满足了不同用户的需求

安装卸载测试

• 软件不同的安装和卸载方式；
• 应用是否可以在不同的环系统，版本下安装（安装兼容性）
• 安装或者卸载过程中是否可以手动暂停或取消
• 安装空间不足的时候系统是否有提示
• 是否可以正常的卸载，以及应用软件的各种卸载方式
• 卸载和安装过程中出现环境问题，能否应对，比如死机，断电，断网等

安全测试

• 输入域，如输入恶性或者带有病毒的脚本或长字符串；
• 代码中的安全性问题，如SQL/XML注入
• 不安全的数据存储或者传递
• 有问题的访问控制，权限分配等
• 假冒ID：身份欺骗
• 篡改，对数据的恶意修改，破坏数据的完整性

性能测试

软件网页打开时越来越慢，查询数据时很长时间才显示列表，软件运行越来越慢等问题

• 资源泄露
• 资源瓶颈
• 线程死锁，线程阻塞
• 查询速度慢或效率低
• 受外部系统影响越来越大

衡量一个系统性能好坏的关键性指标有:
用户响应时间，事务平均响应时间（TPS），吞吐率，每秒点击次数，内存和CPU使用率等。

内存泄漏测试

内存泄露是会累积的，只要执行的次数足够多，最终会耗尽所有可用内存，使软件的执行越来越慢，最后停止响应。

• 分配完内存之后忘了回收。
• 程序写法有问题，造成没办法回收（如死循环造成无法执行到回收步骤）。
• 某些API函数的使用不正确，造成内存泄露。

内存泄漏的检测方法

人工静态法：代码走读，人工查找未被回收的内存。
自动工具法：借助相应测试内存泄漏的工具，如Visual Leak Detector，记录每次内存分配，清楚告诉用户内存是如何泄漏的。

白盒测试

优点 : 关注内部代码实现 , 代码覆盖率高
缺点 : 只关注了代码 , 但是将模块组合在一起 , 有可能出问题

白盒测试又称为结构测试或逻辑测试，它一般用来分析程序的内部结构，针对程序的逻辑结构来设计测试用例进行测试。

白盒测试的测试目的

1. 通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；
2. 在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。

主要包含六种测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖

黑盒白盒 测试不分好坏 , 只要适应当前业务 , 保证软件质量 , 就是一个好测试

灰盒测试

是介于白盒测试与黑盒测试之间的一种测试

灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。

开发阶段

单元测试

单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。又称为模块测试

集成测试

集成测试也称联合测试（联调）、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确

系统测试

将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试

回归测试

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误

冒烟测试

冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件主要功能和核心流程正
常，在正式进行系统测试之前执行。冒烟测试一般在开发人员开发完毕后提交给测试人员来进行测试
时，先进行冒烟测试，保证基本功能正常，不阻碍后续的测试

验收测试

是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。
验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求

按测试实施组织

α测试(Alpha Testing)

β测试(Beta Testing)

α 测试与 β 测试的区别：

1. 测试的场所不同：
   α 测试是指把用户请到开发方的场所来测试 ,
   β 测试是指在一个或多个用户的场所进行的测试。

2. α 测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。
   β 测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。

3. alpha测试先于beta测试执行
   通用的软件产品需要较大规模的β 测试,测试周期比较长

按是否手工划分

自动化测试

是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。简单说
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。

自动化实施步骤：
1.完成功能测试，版本基本稳定
2.根据项目特性，选择适合项目的自动化工具，并搭建环境
3.提取手工测试的测试用例转化为自动化测试的用例
4.通过工具、代码实现自动化的构造输入，自动检测输出结果是否符合预期
5.生成自动测试报告
6.持续改进，脚本优化。

手工测试

由人去一个一个的输入用例，然后观察结果，和机器测试相对应，比较原始但是必须的一个步骤。

总结优缺点：
优点：自动化无法替代探索性测试、发散思维结果的测试。
缺点：执行效率慢，量大易错。

一、自动化测试的优势

• 自动化测试 可以执行手工测试相当困难或根本做不到的测试

如 : 并发测试、疲劳性测试和强度测试。

• 自动化测试具有一致性和可重复性

• 自动化脚本完全可复用

二、自动化测试的劣势

• 手工测试发现的缺陷更多

• 自动化测试对测试人员的技术要求较高

• 自动化测试成本高、风险大

• 自动化测试是死的，不具有情感