在本篇章开始之前，先对之前的内容进行一个简单的总结回顾一下：

基于需求设计测试用例，这里有个测试用例的万能公式：

功能（如果是软件，需要参考依据需求规格说明书；如果是物体，这个物体的功能是用来干嘛的）
界面（我们看到的是什么样的，软件布局、图片大小、文字字体、大小）
易用性（操作是否简单，各年龄段使用都方便）
兼容（不同的设备，不同的操作系统）
安全（SQL注入，权限处理等问题）
性能（接口响应时间、接口承载量）
网络（2g，3g，4g，WiFi等）

边界值，边界值上重要的三个点，上点、内点、离点。

判定表：关系（与或非恒等）

正交表，场景设计法，错误猜想法...

本课程主要讲解软件测试的各种技术。作为一个测试人员，需要不断扩充自己的知识，并将各种知识用于项目测试中。在这里我们根据以上的测试技能图来讲解

按照测试对象分类

界面测试

界面很好理解，登录之后就可以直接看到的就是界面。

例如我们wbb 端登录csdn，或者是app 上，还有微信里的那些小程序，以及各个公众号.....

这是个看脸的时代，这个界面就是程序的脸，这个很重要，用户和软件进行交互的时候，通常都是通过界面和软件进行沟通的，这里决定了用户对其的第一印象。

可靠性测试

可靠性（Availability）即可用性，是指系统正常运行的能力或者程度，一般用正常向用户提供软件服务的时间占总时间的百分比表示。
可靠性 = 正常运行时间/（正常运行时间+非正常运行时间）*100%
系统非正常运行的时间可能是由于硬件，软件，网络故障或任何其他因素（如断电）造成的，这些因素能让系统停止工作，或者连接中断不能被访问，或者性能急剧降低导致不能使用软件现有的服务等。
可用性指标一般要求达到4个或5个“9”，即99.99%或者99.999%

如果可用性达到99.99%，对于一个全年不间断（7*24的方式）运行的系统，意味着全年（252600min)，不能正常工作的时间只有52min，不到一个小时。
如果可用性达到99.999%，意味着全年不能正常工作的时间只有5min。

看到上面的运行时间，怪不得啊，服务器老是坏掉，几千个服务器，每天轮流坏也坏不玩啊；怪不得干运维的和对象出去约会也得背着个电脑！！

思考：如何对可靠性进行测试

服务器一年只有 5 分钟休息，我们要测试，不可能坐在电脑面前守着，所以我们需要借助一些工具，编写一些脚本，让那些脚本自动运行，自动运行之后会有报告，程序猿只需要看报告就好。

总之；一旦涉及到性能测试，就得借助工具，不能依靠人工进行测试。

容错性测试

容错性测试是指系统能够处理异常，用户的错误操作而不至于系统崩溃，从而能够提高系统的可用性。
容错性测试包含以下方面：

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

我们数据都是存在数据库中的，服务器也一样，一旦服务器宕机，重启就可以了，但是数据需要从数据库中重新交互而来。但是一旦数据库遭到了物理上的毁灭性打击，那么服务器就废了，所以一般那些大公司，他们的数据库存放都不在同一个地方，激素hi为了放置上述情况产生，进而导致服务器崩溃。

文档测试

我们大致分为三大类：

–开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
–用户文件:用户手册、操作手册，用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本。
–管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
在实际的测试中，最常见的是用户文件的测试，例如：手册说明书等。也会有一些公司对需求文档进行测试，来保证需求文档的质量。
文档测试的关注点：

文档的术语
文档的正确性
文档的完整性
文档的一致性
文档的易用性

兼容性测试

兼容性测试需求是指明确要测试的兼容环境，考虑软，硬件的兼容，就软件兼容来说，主要考虑以下几个方面：

系统自身版本的兼容，用户已有数据的兼容，数据兼容是重中之重，对用户来说，数据是最有价值的。
测试与应用环境的兼容性，比如操作系统，应用平台，浏览器的兼容
测试与第三方系统以及第三方数据的兼容性

对于环境（操作系统，应用平台）兼容性的测试不仅仅局限在操作系统，浏览器这两个因素，还包括以下，32位，64位CPU；手机平台Android ，iOS，Windows Phone；支持不同的Internet连接速度。
对于iOS和Android两个平台，还要区分手机和平板电脑，考虑不同的型号（屏幕尺寸，分辨率等）。

对于硬件而言我们主要考虑以下几个方面：

不同设备之间：电脑、手机、pad；如果是浏览器还需要考虑浏览器版本问题
不同的操作系统之间：如windows、mac、linux
APP之间的兼容：不能可以打开微信就打不开 QQ

易用性测试

软件设计需要符合大众审美，就比如我们常见的红绿灯：红灯停、绿灯行、黄色代表着"警告"和"提示"。我们写的代码也是一样，绿色表示通过、黄色表示警告、红色表示报错。

软件使用灵活、软件设计出来要简明知意：

看这个日历

安装卸载测试

应用的安装和卸载在任何一款APP中都属于最基本功能。一旦出错，就属于优先级为紧要Critical的缺陷。主要需要考虑以下方面：

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

按是否查看代码划分

在软件测试岗位的面试中，常常被面试官问到的概念就是黑盒和白盒的测试了

黑盒测试(Black-box Testing)

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

黑盒测试的优点：

不需要了解程序内部的代码以及实现，不关注软件内部的实现。
从用户角度出发设计测试用例，很容易的知道用户会用到哪些功能，会遇到哪些问题，锻炼测试人员的产品思维
测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的功能。

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

白盒测试(White-box Testing)

白盒测试又称为结构测试或逻辑测试，它一般用来分析程序的内部结构，针对程序的逻辑结构来设计测试用例进行测试
简单来说，就是白盒测试只关注代码层面的实现。

优点：代码覆盖率高

缺点：只关注了代码，一旦将模块结合到一起，那么就会出现问题

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

灰盒测试(Gray-Box Testing)

灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。

总之，无论我们选择哪个测试都无所谓，只要是适合目前业务的。能够保证软件质量的就是好测试方法。

按开发阶段划分

这里有个测试金字塔：

这里我们主要讲两个重点的测试，后面几章测试内容都围绕着这两个测试

单元测试(Unit Testing)
集成测试(Integration Testing)
后面就要开始讲解代码了。

按测试实施组织

α测试(Alpha Testing)

手机出厂前最后一次测试，开发和测试人员不参与。

β测试(Beta Testing)

新手机购买回来，参与测试的人是购买者，使用的场所及环境已不再是手面厂商的环境及场所。

Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个场所进行

α测试与Beta测试的区别：

测试的场所不同：Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试。
Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。beta测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。
alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。

按是否手工划分

手工测试(Manual testing)
手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。总结优缺点：

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

自动化测试(Automation Testing)
就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。简单说自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
自动化测试比如功能测试自动化、性能测试自动化、安全测试自动化。
自动化测试按照测试对象来分，还可以分为接口测试、UI测试等。接口测试的ROI（产出投入比）要比UI测试高。