软件测试教程 第六节 进阶篇
本课程主要讲解软件测试的各种技术。作为一个测试人员，需要不断扩充自己的知识，并将各种知识用于项目测试中。
在这里我们根据以下的测试技能图来讲解
按开发阶段划分
ROI：投入产出比
单元测试(Unit Testing)
单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。Findyou又称为模块测试
测试阶段：编码后或者编码前（TDD）
测试对象：最小模块
测试人员：白盒测试工程师或开发工程师
测试依据：代码和注释+详细设计文档
测试方法：白盒测试
测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
集成测试(Integration Testing)
集成测试也称联合测试、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。阿旺主要目的是检查软件单位之间的接口是否正确。
测试阶段：一般单元测试之后进行
测试对象：模块间的接口
测试人员：白盒测试工程师或开发工程师
测试依据：单元测试的模块+概要设计文档
测试方法：黑盒测试与白盒测试相结合
测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
系统测试(System Testing)
将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段
测试阶段：集成测试通过之后
测试对象：整个系统（软、硬件）
测试人员：黑盒测试工程师
测试依据：需求规格说明文档
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等
验收测试(Acceptance Testing)
验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求。
测试阶段：系统测试通过之后
测试对象：整个系统（包括软硬件）。
测试人员：主要是最终用户或者需求方。
测试依据：用户需求、验收标准
测试方法：黑盒测试
测试内容：同系统测试(功能...各类文档等)
回归测试(Regression Testing)
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。随着系统的庞大，回归测试的成本越来越大，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。
冒烟测试（smoke testing）
这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。也可以理解为该种测试耗时短，仅用一袋烟功夫足够了。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。
冒烟测试一般在开发人员开发完毕后送给测试人员来进行测试时，测试人员会先进行冒烟测试，保证基本功能正常，不阻碍后续的测试。
α测试(Alpha Testing)
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。
大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试。α测试不能由程序员或测试员完成。
β测试(Beta Testing)
Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个客房场所进行。
α测试与Beta测试的区别：
测试的场所不同：Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试。
Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。beta测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。
alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。
按是否运行划分
静态测试(Static testing)
静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。分析如下
检查项：代码风格和规则审核；程序设计和结构的审核；业务逻辑的审核；走查、审查与技术复审手册。
静态质量：度量所依据的标准是ISO9126。在该标准中，软件的质量用以下几个方面来衡量，即功能性(Functionality)、可靠性(Reliability)、可用性(Usability)、有效性(Efficiency)、可维护性（Maintainability）、可移植性(Portability)。
代码静态分析和文档测试都属于静态测试
动态测试(Dynamic testing)
动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能。这种方法由三部分组成：构造测试用例、执行程序、分析程序的输出结果。
大多数软件测试工作都属于动态测试。
按是否手工划分
手工测试(Manual testing)
手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。总结优缺点：
优点：自动化无法替代探索性测试、发散思维类无既定结果的测试。
缺点：执行效率慢，量大易错。
自动化测试(Automation Testing)
就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。简单说自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
自动化测试比如功能测试自动化、性能测试自动化、安全测试自动化。
通常所说的自动化是指功能测试自动化。
自动化测试按照测试对象来分，还可以分为接口测试、UI测试等。接口测试的ROI要比UI测试高。
**按是否查看代码划分 **
不管黑盒、白盒，抓住bug就是好盒
黑盒测试(Black-box Testing)
黑盒测试也称功能测试，测试中把被测的软件当成一个黑盒子，不关心盒子的内部结构是什么，只关心软件的输入数据与输出数据。
业务测试
是测试人员把系统各个模块串接起来运行、模拟真实用户实际的工作流程，满足用户需求定义的功能来进行测试的过程。
业务测试关注需求和用户
界面测试
界面测试（简称UI测试)，测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。
一般大厂都有自己的规范可以作为测试参考。中小公司这部分测试一般都没有，除非明确的错误，否则容易和开发人员引起争议。
文档测试
国家有关计算机软件产品开发文件编制指南中共有14 种文件，可分为3 大类。
–开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
–用户文件:用户手册、操作手册，用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本。
–管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
在实际的测试中，最常见的是用户文件的测试，例如：手册说明书等。也会有一些公司对需求文档进行测试，来保证需求文档的质量。
文档测试的关注点：
文档的术语
文档的正确性
文档的完整性
文档的一致性
文档的易用性
兼容性测试
兼容性主要是指软件之间能否很好的运做，会不会有影响、软件和硬件之间能否发挥很好的效率工作，会不会影响导致系统的崩溃。
平台测试
浏览器测试
软件本身能否向前或者向后兼容
测试软件能否与其它相关的软件兼容
数据兼容性测试
最常见的就是浏览器的兼容性测试，不同浏览器在css，js解析上的不同会导致页面的显示不同。常见的IE8的兼容性。
易用性测试
易用性（Useability）是交互的适应性、功能性和有效性的集中体现。易用性属于人体工程学的范畴，人体工程学（ergonomics）是一门将日常使用的东西设计为易于使用和实用性强的学科。
在某些大厂会有专门的部门来进行易用性测试，又叫用户体验测试。
内存泄漏测试
很多软件系统都存在内存泄露的问题，尤其是缺乏自动垃圾回收机制的“非托管”语言
编写的程序，例如C、CH、Delphi等。从用户使用的角度来看，内存泄露本身不会造成什
么危害，一般用户可能根本不会感觉到内存泄露的存在。但是内存泄露是会累积的，只要执
行的次数足够多，最终会耗尽所有可用内存，使软件的执行越来越慢，最后停止响应。可以
把这种软件的问题比喻成软件的“慢性病”。
造成内存泄露的原因有很多，最常见的有以下几种。
分配完内存之后忘了回收。
程序写法有问题，造成没办法回收。
某些API函数的使用不正确，造成内存泄露。
没有及时释放。
内存泄漏的检测：
1、对于不同的程序可以使用不同的方法来进行内存泄露的检查，还可以使用一些专门的工具来进行内存问题的检查，例如MemProof. AQTime、Purify、BundsChecker等。
有些开发工具本身就带有内存问题检查机制．要确保程序员在编写程序和编译程序的时候打开这些功能。
2、通过代码扫描分析工具来检查
安装测试
测试程序的安装、卸载
典型的是app的安装、卸载
控件测试
控件：是程序软件的组成部分，如软件中所经常涉及到的按钮、界面风格、表格、报表等，都可以直接使用控件。控件就像是一间房子里的桌椅家具一样，和整个房子的其它部份构成一套完整的住宅。
使用控件的必要性：
控件是程序开发过程中用于调用的部分，在整个程序中主要用于方便调用，并且可以使用控件美化程序界面等，但控件本身的开发强度较大，代码烦琐，如果将控件编写与软件编写同时进行，则将导致程序及其代码显得比较臃肿，并且大大地降低了工作效率，提高开发成本。因此，控件的使用采用调用方式较为可取。而调用方式则是使用现有的已经为程序准备好的控件。
测试控件就是对控件的各种输入、设置进行测试
国际化测试
软件的国际化和软件的本地化是开发面向全球不同地区用户使用的软件系统的两个过程。而本地化测试和国际化测试则是针对这类软件产品进行的测试。由于软件的全球化普及，还有软件外包行业的兴起，软件的本地化和国际化测试俨然成为了一个独特的测试专门领域。
本地化和国际化测试与其他类型的测试存在很多不同之处。下面是本地化和国际化测试
的一些要点。
1、本地化后的软件在外观上与原来版本是否存在很大的差异，外观是否墼齐、不走样。
2、是否对所有界面元素都进行了本地化处理，包括对话框、菜单、工具栏、状态栏、提示信息（包括声音的提示）、日志等。
3、在不同的屏幕分辨率下界面是否正常显示。
4、是否存在不同的字体大小，字体设置是否恰当。
5、日期、数字格式、货币等是否能适应不同国家的文化习俗。例如，中文是年月日，而英文是月日年。
6、排序的方式是否考虑了不同语言的特点。例如，中文按照第一个字的汉语拼音顺序排序，而英文按照首字母排序。
7、在不同的国家采用不同的度量单位，软件是否能自适应和转换。
8、软件是否能在不同类型的硬件上正常运行，特别是在当地市场上销售的流行硬件上。
9、软件是否能在Windows或者其他操作系统的当地版本上正常运行。
10、联机帮助和文档是否已经翻译，翻译后的链接是否正常。正文翻译是否正确、恰当，
是否有语法错误。
软件本地化和国际化测试是一个综合了翻译行业和软件测试行业的测试类型。它要求测
试人员具备一定的翻译能力、语言文化，同时具备测试人员的基本技能。
安全测试
安全测试是一个相对独立的领域，需要更多的专业知识。例如web的安全测试，需要熟悉各种网络协议TCP\HTTP，防火墙，CDN，熟悉各种操作系统的漏洞，熟悉路由器等。从软件来说，熟悉各种攻击手段，例如SQL注入、Xss等。
作为web入门测试，可以IBM的appscan。
web测试
web测试一般从以下方面进行测试：
- Web功能测试
- Web性能测试
- Web界面测试
- Web兼容性测试
- Web安全性测试
app测试
由于手机的某些局限性和手机应用软件的特点，决定了测试人员在对手机的应用程序进行测试时需要注意以下要点。
1、由于手机的显示区域小，不能有太丰富的展示效果，因此要求设计要精简而不失表达能力，测试人员需要注意界面美观和简洁度的测试。而且不同型号的手机屏幕大小不一致，设置形状不一致，因此需要注意测试图片的自适应问题、界面元素的布局问题等。
2、手机的操作交互过程不能设计得太复杂，交互步骤不能太多，应该尽量多设计快捷方式，测试人员需要注意易用性和用户体验的测试。
3、不同型号的手机支持的图片格式、声音格式、动画格式不一样，需要选择尽可能通用的格式，或者针对不同的型号进行配置选择，测试人员需要注意兼容性测试。
4、由于内存限制，很容易出现内存泄露、越界等问题，因此需要注意这方面的测试。
5、要注意手机应用在操作过程中断电、重启、断网等意外情况发生时的处理是否正确，也就是所谓的“暴力测试”。
6、由于不间款式的手机在实现同一平台时存在细微的差异，因此不要仅仅在手机模拟器上测试，还要放到真正的手机上进行测试。
白盒测试(White-box Testing)
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒指的打开盒子，去研究里面的源代码和程序结果。
灰盒测试(Gray-Box Testing)
灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。