内容大纲:
软件测试的各种技术
1. 按照测试对象划分
1.1 界面测试
内容:
- 验证界面内容显示的完整性，一致性，准确性，友好性。比如界面内容对屏幕大小的自适应，换行，内容是否全部清晰展示；
- 验证整个界面布局和排版是否合理，不同板块字体的设计，图片的展示是否符合需求；
- 对界面不同控件的测试，比如，对话框，文本框，滚动条，选项按钮等是否可以正常使用，有效和无效的状态是否设计合理；
- 界面的布局和色调符合当下时事的发展
常见的页面错误,比如:重叠
1.2 可靠性测试
一般用正常向用户提供软件服务的时间占总时间的百分比表示
可靠性 = 正常运行时间/（正常运行时间+非正常运行时间）*100%
系统非正常运行的时间可能是由于硬件，软件，网络故障或任何其他因素（如断电）造成的，这些因素能让系统停止工作，或者连接中断不能被访问，或者性能急剧降低导致不能使用软件现有的服务等
可用性指标一般要求达到4个或5个“9”，即99.99%或者99.999%
- 如果可用性达到99.99%，对于一个全年不间断（7*24的方式）运行的系统，意味着全年（252600min)不能正常工作的时间只有52min，不到一个小时。
- 如果可用性达到99.999%，意味着全年不能正常工作的时间只有5min。
- 不同的应用系统，可用性的要求是不一样的，非实时性的信息系统或一般网站要求都很低，99%和 99.5%就可以了，但是军事系统，要求则很高；
那么如何进行可用性的测试?
需要借助测试工具
1.3 容错性测试
指系统能够处理异常，用户的错误操作而不至于系统崩溃，从而能够提高系统的可用性
内容:
①输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。
比如数据级测试，校验测试，环境容错性测试，界面容错性测试
②灾难恢复性测试:
通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据 是否能尽快恢复。
1.4 文档测试
–开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
–用户文件:用户手册、操作手册，用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本。
–管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
关注点:
- 文档的术语
- 文档的正确性
- 文档的完整性
- 文档的一致性
- 文档的易用性
1.5 兼容性测试
- 系统自身版本的兼容，用户已有数据的兼容，数据兼容是重中之重，对用户来说，数据是最有价值 的。
- 测试与应用环境的兼容性，比如操作系统，应用平台，浏览器的兼容
- 测试与第三方系统以及第三方数据的兼容性
举个例子,当我们在各个购物平台购买东西,这些记录就需要在支付宝展示出来
1.6 易用性测试
让用户获得舒适，易用的体验
易用性包含七个要素：符合标准和规范，直观性，一致性，灵活性，舒适性，正确性和实用性
- 直观性:例如条形图，扇形图等展示清晰直观
- 灵活性: 例如手机键盘有九宫格和全键盘，还支持手写，满足了不同用户的需求
- 舒适性:例如左手鼠标的设置给习惯用左手的人带来了便利，也为右手十分劳累时提供了另一种途径
1.7 安装卸载测试
- 软件不同的安装和卸载方式
- 应用是否可以在不同的环系统，版本下安装（安装兼容性）
- 安装或者卸载过程中是否可以手动暂停，或者取消
- 安装空不足的时候系统是否有提示
- 是否可以正常的卸载，以及应用软件的各种卸载方式
- 卸载和安装过程中出现环境问题，软件是否可以正常并且合理的应对，比如死机，断电，断网等
1.8 安全性测试
系统常见的安全漏洞和威胁如下:
- 输入域，如输入恶性或者带有病毒的脚本或长字符串
- 代码中的安全性问题，如SQL/XML注入
- 不安全的数据存储或者传递
- 数据文件，邮件文件，系统配置文件等里面有危害系统的信息或者数据
- 有问题的访问控制，权限分配等
- 假冒ID身份欺骗
- 篡改，对数据的恶意修改，破坏数据的完整性
1.9 性能测试
我们在使用软件的时候有时会碰到软件网页打开时越来越慢，查询数据时很长时间才显示列表，软件运行越来越慢等问题，这些问题都是系统的性能问题引起的。
衡量一个系统性能好坏的关键性指标有，用户响应时间，事务平均响应时间（TPS），吞吐率，每秒点击 次数，内存和CPU使用率等。
常见的性能问题如下：
- 资源泄露
- 资源瓶颈
- 线程死锁，线程阻塞
- 查询速度慢或效率低
- 受外部系统影响越来越大
1.10 内存泄漏测试
从用户使用的角度来看，内存泄露本身不会造成什么危害，一般用户可能根本不会感觉到内存泄露的存在。但是内存泄露是会累积的，只要执行的次数足够多，最终会耗尽所有可用内存，使软件的执行越来越慢，最后停止响应。
最常见的造成内存泄露的原因:
- 分配完内存之后忘了回收
- 程序写法有问题，造成没办法回收（如死循环造成无法执行到回收步骤）
- 某些API函数的使用不正确，造成内存泄露
内存泄漏的检测方法
- 人工静态法：代码走读，人工查找未被回收的内存
- 自动工具法：借助相应测试内存泄漏的工具，如Visual Leak Detector，记录每次内存分配，清楚 告诉用户内存是如何泄漏的
问:人工静态法与自动工具法哪个更好?
各有各的好处
2. 按照是否查看代码划分
2.1 黑盒测试
黑盒测试(数据驱动测试)就是在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使用、是否能适当的接收输入数据而输出正确的结果，满足规范需求。
优点:
- 不需要了解程序内部的代码以及实现，不关注软件内部的实现,对测试人员代码能力要求较低
- 从用户角度出发设计测试用例，很容易的知道用户会用到哪些功能，会遇到哪些问题，锻炼测试人 员的产品思维
- 测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的功能。
缺点:
- 不可能覆盖所有代码
特点:
- 关注业务功能是否符合预期
- 不关注代码
黑盒测试用到的测试方法:
等价类，边界值，因果图，场景法，错误猜测法等
2.2 白盒测试
白盒测试又称为结构测试或逻辑测试，它一般用来分析程序的内部结构，针对程序的逻辑结构来设计测 试用例进行测试。
优点:
对测试人员代码能力要求较高
缺点:
虽然代码覆盖较高,但是项目上线之后,业务逻辑可能会有问题
特点:
- 关注内部代码逻辑
- 不关注业务功能
白盒测试用到的测试方法:
语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖
2.3 灰盒测试
灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。
3. 按照开发阶段划分
测试金字塔:
从下到上,对测试人员的代码技术要求越来越低,越来越接近客户,定位问题的成本越来越高
3.1 单元测试
- 测试阶段：编码后或者编码前（TDD）
- 测试对象：最小模块
- 测试人员：白盒测试工程师或开发工程师
- 测试依据：代码和注释+详细设计文档
- 测试方法：白盒测试
- 测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
3.2 集成测试
- 测试阶段：一般单元测试之后进行
- 测试对象：模块间的接口
- 测试人员：白盒测试工程师或开发工程师
- 测试依据：单元测试的模块+概要设计文档
- 测试方法：黑盒测试与白盒测试相结合
- 测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
3.3 系统测试
- 测试阶段：集成测试通过之后
- 测试对象：整个系统（软、硬件）
- 测试人员：黑盒测试工程师
- 测试依据：需求规格说明文档
- 测试方法：黑盒测试
- 测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等
3.4 验收测试
- 测试阶段：系统测试通过之后
- 测试对象：整个系统（包括软硬件）
- 测试人员：主要是最终用户或者需求方
- 测试依据：用户需求、验收标准
- 测试方法：黑盒测试
- 测试内容：同系统测试(功能...各类文档等)
3.5 回归测试
- 是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误
- 在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试
- 属于系统测试
3.6 冒烟测试
- 冒烟测试一般在开发人员开发完毕后提交给测试人员来进行测试时，先进行冒烟测试(在正式进行系统测试之前执行)，保证基本功能正常，不阻碍后续的测试。
- 如果冒烟测试通过，则测试人员开始进行正式的系统测试，如果不通过，则测试人员可以让开发人员重新修复代码直到冒烟测试通过，再开始进行系统测试。
- 属于系统测试
4. 按照实施组织划分
4.1 α测试
- α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试
- α测试不能由程序员或测试员完成
4.2 β测试
- Beta测试是一种验收测试
- Beta测试由软件的最终用户们在一个或多个场所进行
4.3 α测试与β测试区别
- 测试环境:α测试是在公司内部测试的,内部环境,β测试各种环境都有可能
- 测试人员:α测试是公司内部员工测试的,β测试是客户测的
- 测试时间节点:α测试在前,β测试在后
- 测试人员数量区别: α测试人员比β测试人员少
4.4 第三方测试
介于开发方和用户方间的组织的测试。
5. 按照是否手工划分
5.1 手工测试
就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应
- 优点：自动化无法替代探索性测试、发散思维结果的测试。
- 缺点：执行效率慢，量大易错。
5.2 自动化测试
在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。简单说 自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
自动化测试比如功能测试自动化、性能测试自动化、安全测试自动化。
自动化测试按照测试对象来分，还可以分为接口测试、UI测试等。接口测试的ROI（产出投入比）要比 UI测试高。
6. 按照地域划分
6.1 国际化测试
- 本地化后的软件在外观上与原来版本是否存在很大的差异，外观是否墼齐、不走样。
- 是否对所有界面元素都进行了本地化处理，包括对话框、菜单、工具栏、状态栏、提示信息（包括 声音的提示）、日志等。
- 在不同的屏幕分辨率下界面是否正常显示。
- 是否存在不同的字体大小，字体设置是否恰当。
- 日期、数字格式、货币等是否能适应不同国家的文化习俗。例如，中文是年月日，而英文是月日 年。
- 排序的方式是否考虑了不同语言的特点。例如，中文按照第一个字的汉语拼音顺序排序，而英文按 照首字母排序。
- 在不同的国家采用不同的度量单位，软件是否能自适应和转换。
- 软件是否能在不同类型的硬件上正常运行，特别是在当地市场上销售的流行硬件上。
- 软件是否能在Windows或者其他操作系统的当地版本上正常运行。
- 联机帮助和文档是否已经翻译，翻译后的链接是否正常。正文翻译是否正确、恰当， 是否有语法 错误。
6.2 本地化测试
之前我们所讲的全是本地化测试。
7. 按照是否运行划分
7.1 静态测试
是不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。
不以测试数据的执行而是对测试对象的分析过程，仅通过分析或检查源程序的设计、内部结构、逻辑、代码风格和规格等来检查程序的正确性。
7.2 动态测试
是实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以判断一个测试属于动态测试还是静态的，唯一的标准就是看是否运行程序。
