各位小伙伴们面对软件测试技术考试是不是很烦躁呢读本篇博客也许不会让你那么烦躁~
本文内容主要来自于董老师的提纲。

第一章

1.1 为什么要进行软件测试

1、产品质量的保证
2、控制成本的关键
3、软件可靠性确认
4、让企业具备国际竞争的实力

1.2 什么是软件测试

1、Bill Hetzel博士（正向思维的代表）：
（1） 软件测试就是为程序能够按预期设想那样运行而建立足够的信心。
（2）软件测试是一系列活动以评价一个程序或系统的特性或能力并确定是否达到预期的结果
（3）测试是为了验证软件是否符合用户需求，即验证软件产品是否能正常工作
2、Glenford J. Myers （反向思维的代表）：
（1）测试是为了证明程序有错，而不是证明程序无错误
（2）一个好的测试用例是在于它能发现至今未发现的错误
（3）一个成功的测试是发现了至今未发现的错误的测试
（4）软件测试是由“验证（Verification）”和“有效性确认（Validation）”活动构成的整体。“验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性；“有效性确认”是确认所开发的软件是否满足用户真正需求的活动。

1.3 软件测试的四种导向

1、1957～1978年，以功能验证为导向，测试是证明软件是正确的（正向思维）。
2、1978～1983年，以破坏性检测为导向，测试是为了找到软件中的错误（逆向思维）。
3、1983～1987年，以质量评估为导向，测试是提供产品的评估和质量度量。
4、1988年起，以缺陷预防为导向，测试是为了展示软件符合设计要求，发现缺陷、预防缺陷。

1.4 测试和质量的关系

修复软件缺陷的代价：
假设在需求分析阶段修复软件缺陷的代价为“单位1”。
设计阶段：3～6倍。
编程阶段：10倍。
内部测试阶段：20～40倍。
外部测试阶段：30～70倍。
产品发布后：40～1000倍。
修正错误的代价不是随时间线性增长，而几乎是呈指数增长的。

软件测试结束的标准：
用例全部测试；
覆盖率达到标准；
缺陷率达到标准；
其他指标达到标准。

1.5 软件测试的分类

静态测试：
静态测试就是静态分析，对模块的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和仿真运行。静态测试包括对软件产品的SRS，SAD进行评审、对程序代码进行复审等。静态分析的查错和分析功能是其他方法所不能替代的。可以采用人工检测和计算机静态分析手段进行检测。但现在越来越多的静态测试采用了自动化工具进行分析。

动态测试：
通过真正运行程序发现错误，通过观察代码运行过程来判断系统是否存在问题。或者通过有效的测试用例和对应的输入输出来分析程序运行的情况，发现缺陷。

性能测试：
为了发现系统性能问题或获取系统性能相关指标而进行的测试。一般在真实环境、特定负载条件下，通过工具模拟实际软件系统的运行及其操作，同时监控性能各项指标，最后对测试结果进行分析来确定系统的性能状况。

回归测试：
为保证软件中新的变化（新增加的代码、代码修改等）不会对原有功能的正常使用有影响而进行的测试。（原有功能不应该因为代码变化而出现任何新的问题。）

压力测试：
用来检査系统在不同负载条件下的系统运行情况，特别是高负载、极限负载下的系统运行情况，以发现系统缺陷。

1.6 软件测试的工作范围

1、软件测试工作的组织与管理：制定测试策略、测试计划，确认所采用的测试方法与规范，控制测试进度，管理测试资源。
2、测试工作的实施：编制符合标准的测试文档，搭建测试环境，开发测试脚本、与开发组织协作实现各阶段的测试活动。

第二章

2.1 软件质量与软件缺陷

软件质量：
软件产品满足使用要求的程度。

产品质量：
是人们实践产物的属性和行为，是可以认识，可以科学地描述的。并且可以通过一些方法和人类活动，来改进质量。
质量模型: McCall 模型, Boehm 模型, ISO 9126 模型
过程质量:
软件能力成熟度模型 CMM。
国际标准过程模型 ISO 9000
软件过程改进和能力决断 SPICE

软件缺陷：
从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。

2.2 白盒测试黑盒测试

白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。

黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

2.3 测试用例

测试用例：
为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

设计测试用例的原因：
测试用例构成了设计和制定测试过程的基础。
测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，对产品质量和测试流程也就越有信心。判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。
测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。
测试设计和开发的类型以及所需的资源主要都受控于测试用例。
测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例：一个测试用例用于证明该需求已经满足，通常称作正面测试用例；另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。
测试用例是软件测试的核心。

第三章

3.1软件测试方法

等价类划分法：
分为有效等价类和无效等价类。有效等价类是有意义的、合理的输入数据，可检查程序是否实现了规格说明中所规定的功能和性能。无效等价类与有效等价类的意义相反。

边界值分析法：
确定边界情况（输入或输出等价类的边界），选取正好等于、刚刚大于或刚刚小于边界值作为测试数据。

因果图法：
用图解的方法表示输入的各种组合关系，写出判定表，从而设计相应的测试用例。

判定表法：
就是指把所有的输入条件、所有可能采取的动作按表格列出来，每一种条件和动作的组合构成一个用例。

用条件覆盖法设计白盒测试用例。
用等价类和边界值设计黒盒测试用例。

3.2 基于逻辑覆盖的方法

语句覆盖：
语句覆盖法的基本思想是设计若干测试用例，运行被测程序，使程序中的每个可执行语句至少被执行一次。

判定覆盖：
判定覆盖法的基本思想是设计若干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足。

条件覆盖：
条件覆盖的基本思想是设计若干测试用例，执行被测程序以后，要使每个判断中每个条件的可能取值至少满足一次。

3.3 扩展有限状态机的方法

有限状态机：
一种进行对象行为建模的工具，用来描述对象在其生命周期内所经历的状态序列，以及如何响应来自外界的各种事件。

状态图：

第四章

4.1 W模型

5.3 集成测试

集成测试：
集成测试是将软件集成起来，对模块之间的接口进行测试。 集成测试又叫子系统测试、组装测试、部件测试等。

1、模块内的集成，主要是测试模块内各个接口间的交互集成关系；
2、子系统内的集成，测试子系统内各个模块间的交互关系；
3、系统内的集成，测试系统内各个子系统和模块间的集成关系。

集成测试的测试人员：有经验的测试人员和开发者共同进行测试。

非渐增式测试模式：
先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。

渐增式测试模式：
把下一个要测试的模块同已经测试好的模块结合进来进行测试，测试完后再把下一个应该测试的模块结合起来测试。

渐增式测试又可以根据每次添加模块的路线分为自顶向下测试、自底向上测试和混合测试（三明治集成方法）等方式。

第六章

6.1 系统测试

系统测试（特征测试）：
检验系统所有元素之间协作是否合适，整个系统的性能和功能是否达到要求。

系统测试的测试内容：功能测试，非功能测试与回归测试。

非功能性测试（特征测试）包含的内容：
性能测试，压力测试，容量测试，安全性测试，可靠性测试，容错性测试。

系统测试的测试依据：
需求说明书，概要设计说明书，详细设计说明书，最重要的是需求说明书。

6.2 性能测试

性能测试（performance test）就是为了发现系统性能问题或获取系统性能相关指标而进行的测试。一般在真实环境、特定负载条件下，通过工具模拟实际软件系统的运行及其操作，同时监控性能各项指标，最后对测试结果进行分析来确定系统的性能状况。

第七章

7.1 验收测试

验收测试：
检查软件是否符合合同要求，包括需求规格说明、设计规格说明和用户手册等。

验收测试的测试人员：用户和测试部门共同完成。

验收测试的测试依据 ：
国家规范，行业标准，合同条款，用户确认的SRS。

7.2 α，β测试

α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。
经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。

第八章

国际化与本地化

软件国际化（SW Internationalization，I18N）
I18N是借助功能设计和代码实现中软件系统有能力处理多种语言和不同文化，使创建不同语言版本时，不需要重新编写代码的软件工程方法。

软件本地化（SW Localization，L10N）
L10N是将一个软件产品按特定国家/地区或语言市场的需要进行加工，使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动。

软件本地化和软件国际化的关系：是一个辩证的关系，本地化要适应国际化的规定。而国际化是本地化的基础和前提，为本地化做准备，使本地化过程不需要对代码做改动就能完成，或将代码修改降到最低限度。

全球化：是一个概念化产品的过程，它基于全球市场考虑，以便一个产品只做较小的改动就可以在世界各地出售。全球化可以看作国际化和本地化两者合成的结果。

作为国际化软件，要么在应用软件运行时可以动态切换某种国家或地区的语言，要么在应用软件启动前或启动时可以设置某种语言。

软件国际化标准：
1、切换语言的机制。
2、与语言无关的输出接口。
3、与语言无关的输入接口和标准的输入协议。
4、资源文件的国际化。

软件本地化步骤：
1、建立配置管理体系，跟踪目标语言各个版本的源代码。
2、创造和维护术语表。
3、源语言代码和资源文件分离、或提取需要本地化的文本。
4、把分离或提取的文本、图片等翻译成目标语言。
5、把翻译好的文本、图片重新检入目标语言的源代码版本。
6、如果需要，编译目标语言的源代码。
7、测试翻译后的软件，调整UI 以适应翻译后的文本。
8、测试本地化后的软件，确保格式和内容都正确。

第九章

9.1 自动化测试

自动化测试是相对手工测试而存在的一个概念，由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。

自动化测试框架：

来源：shadowingszy