测试的分类 (1)测试用例设计方法 (1)黑盒测试（Black-box Test Design Technique）技术一: (1)黑盒测试（Black-box Test Design Technique）技术二: (3)（参考技术一得到的测试用例设计流程） (4)白盒测试(White-box Test Design Technique)技术一: (5)测试策略与过程 (6)单元测试 (6)集成测试 (7)系统测试 (7)验收测试 (7)基本要求和适用要求 (7)测试基本方法 (7)测试组织 (7)选择测试技术的相对依据 (7)测试的分类测试用例设计方法黑盒测试（Black-box Test Design Technique）技术一:（从黑盒测试的技术来分类）1.等价类划分（Equivalence Partitioning）：定义：分步骤的把无限的测试用例集减的很小，但过程同样有效。
目标：把可能的测试用例集缩减到可控制且仍然足以测试软件的小范围内。
分类：有效等价类、无效等价类特性：严格控制测试用例的增加，减少为达到“合理测试”的某些既定目标而必须设计的其他测试用例的数量它覆盖了大部分其他可能的测试用例。
（它会告诉我们，使用或不使用这个特定的输入集合，哪些错误会被发现，哪些会被遗漏掉）等价类覆盖率计算：等价类覆盖率=（已覆盖等价类数目/总等价类数目）*100%优点：在有明确的条件和限制的情况下，利用等价类划分技术可以帮助测试人员在有限的时间内选择合适的测试数据和组合，以减少冗余的测试用例2.边界值分析（Boundary Value Analysis）：定义：通过分析输入或输出的边界值并取值进行测试用例设计的一种黑盒测试。
包含：边界条件、次边界条件（有些边界在软件内部，最终用户几乎看不到，但是软件测试员仍有必要进行检查。
这样的边界条件称为次边界条件sub-boundary conditions或者内部边界条件internal boundary conditions）注意：缓冲区溢出（buffer overrun）是由边界条件却引起的，它是造成软件安全问题的头号原因等价类划分与边界值分析的区别：与从等价类中挑选出任意一个元素作为代表不同，边界值分析需要选择一个或多个元素，以便等价类的每个边界都经过一次测试。
与仅仅关注输入条件（输入空间）不同，还需要考虑从结果空间（输出等价类）设计测试用例边界值覆盖率计算：边界值覆盖率=（已覆盖的边界值数目/总的边界值数目）*100%优点：边界值分析技术往往是等价类划分技术的有效补充3.决策表测试：定义：决策表或因果图是通过分析说明，识别出系统可能的条件和行为，并最终设计测试用例的技术。
决策表组成部分：条件桩（Condition Stub）:列出了测试对象的所有条件。
一般情况下，列出的条件的次序不会影响测试对象的动作动作桩（Action Stub）:列出了测试对象的所有可能执行的操作。
一般情况下，这些执行的操作没有先后顺序的约束。
条件项（Condition Entry）组合：列出针对特定条件的取值的组合，即条件的真假值。
每一列条件值得组合形成一个规则。
动作项（Action Entry）组合：列出在不同条件项的各种取值组合下（规则），测试对象应该执行的组合。
决策表或因果表的覆盖率计算：决策表覆盖率=（已覆盖的规则书/总的规则数）*100%优缺点：决策表技术将各种输入条件的组合，以及它们的行为生成决策表，是一种系统化而且非常正式的方法，它可以覆盖一些在其他测试设计技术中没有包含的输入组合。
随着被测对象条件数目的增加，得到的决策表和因果图的规模会急剧变大，不仅失去可读性，并且变得难以处理4.状态转换测试：定义：指的是所设计的测试用例用来执行有效和无效的状态转换的一种黑盒测试技术。
状态转换图：通过描绘系统的“状态”及引起系统“状态转换”的“事件”，来表示系统的行为。
此外状态转换图还指明了作为特定事件的结果，系统将做哪些“动作”（例如处理数据）。
因此状态转换图提供了行为建模机制。
状态转换图应该表示出的项目：软件可能进入的每一种独立状态。
从一种状态转入另一种状态所需的输入和条件。
进入或者退出某周状态时的设置条件及输出结果。
状态转换树：由于状态转换图中可能存在循环的回路，为了方便设计测试用例，需要将状态转换图转变为只包含特定转换顺序的状态转换树。
优点：状态转换测试技术适用于那些状态起着重要作用，并且功能也会因为状态不同而受到影响的测试对象。
在面向对象的系统中，对象可以有不同的状态，选择针对对象进行操作的方法必须能根据不同的状态做出相应的反应。
状态转换测试技术对于面向对象的测试非常重要，因为它考虑到了面向对象的特征。
5.用例测试：定义：通过用例或业务场景设计测试用例的测试技术。
黑盒测试（Black-box Test Design Technique）技术二:（从黑盒测试的内容分类）软件最简单的分类：数据（范围）和程序数据包括键盘输入、鼠标单击、磁盘文件、打印输出等。
软件是指可执行的流程、转换、逻辑和运算。
1.数据测试：数据测试关键的原则：边界条件次边界条件空值无效数据2.状态测试有效状态测试参考上述转换测试。
失效状态测试包含以下三种测试条件：竞争条件和时序错乱:（牵扯硬件上运行的其他软件共用同一种的资源时发生的特殊情况）重复测试：是不断执行同样的操作。
主要原因是检查是否存在内存泄露（memory leaks）。
压迫测试：使软件在不够理想的条件下运行-----内存小、磁盘空间少、CPU速度慢、调制调解器速率低等。
目的是观察软件对外部资源的要求和依赖的程度。
重负测试：尽可能的提供条件任其发挥。
让软件处理尽可能大的数据。
目的是最大限度的发掘软件的能力，让其不堪重负。
（参考技术一得到的测试用例设计流程）通过分析决策表测试确认系统可能运行的行为和所需条件 通过状态转换测试来确认系统在状态转换间所需要的行为和所需条件通过分析等价类划分来确定等价值集合需要进行数据测试的系统行为（数据包括键盘输入、鼠标单击、磁盘文件、打印输出等）需要进行状态测试的系统行为（指可执行的流程、转换、逻辑和运算）通过对等价值集合的分析获得边界值、次边界值、空值、无效数据测试用例决策表到底是什么？我的理解是：例如一个注册用户的页面，决策表测试就是测试用户在这个页面的所有可响应的操作所需要的条件和行为。
白盒测试(White-box Test Design Technique)技术一:静态白盒测试定义：静态白盒测试是在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程，也称为结构化分析。
静态白盒测试的优点：1.尽早发现软件缺陷，以找出动态黑盒测试难以发现或隔离的软件2.为黑盒测试员在接受软件进行测试时设计和应用测试用例提供思路静态白盒测试的过程与规范：正式审查（formal review）就是进行静态白盒测试的过程。
它包含了四个基本要素：1.确定问题：审查的目的是找出软件的问题--不仅是出错的项目，还包括遗漏项目。
2.遵守规则：审查要遵守一套固定的规则，规则可能设定要审查的代码量，花费多少时间，哪些内容需要做评价。
3.准备：每一个参与者都为审查做准备，并尽自己的力量。
4.编写报告：审查小组必须做出审查结果的书面报告总结，并使报告便于开发小组的成员使用。
编码标准和规范：有三个重要的原因要坚持标准或规范1.可靠性：事实证明按照某种标准或规范编写的代码比不这样做的代码更加可靠和安全2.可读性/维护性：符合设备标准和规范的代码易于阅读、理解和维护3.移植性：代码经常需要在不同的硬件中运行，或者使用不同的编译器编译。
如果代码符合设备标准，迁移到另一个平台就会轻而易举，甚至完全没有障碍。
通用代码审查清单：数据引用错误：指使用未经正确声明和初始化的变量、常量、数组、字符串或记录而导致的软件缺陷。
（引起缓冲区溢出的主要原因）数据声明错误：数据声明缺陷产生的原因是不正确的声明或使用变量和常量。
计算错误：计算或者运算错误实质上是糟糕的数学问题。
计算无法得到预期结果。
比较错误：小于、大于、等于、不等于、真、假。
比较和判断错误很可能是由于边界条件问题。
控制流程错误：控制流程错误的原因是编程语音中循环等控制结构未按预期方式工作。
它们通常由计算或者比较错误直接或间接造成。
子程序参数错误：来源是软件程序不正确的传递数据。
输入输出错误：输入输出错误包括文件读取、接受键盘或鼠标输入以及向打印机或者屏幕等输出设备写入错误。
其他检查：动态白盒测试定义：动态白盒测试不仅仅是查看代码的运行情况，还包括直接测试和控制软件。
动态白盒测试的4个主要部分：1.直接测试底层函数、过程、子程序和库。
在Microsoft Windows 中这称为应用程序编程接口（API）。
2.以完整程序的方式从顶层测试软件，但是根据对软件运行的了解调整测试用例。
3.从软件获得读取变量和状态信息的访问权，以确定测试与预期结果是否相符，同时，强制软件以正常测试难以实现的方式运行。
4.估算执行测试时“命中”的代码量和具体代码，然后调整测试，去掉多余的测试用例，补充遗漏的用例。
注意：动态白盒测试和调试（debugging）不同。
动态测试的目标是寻找软件缺陷，调试的目标是修复缺陷。
灰盒测试：测试策略与过程在底层进行的测试称为单元测试（unit testing）或者模块测试（module testing）。
单元经过测试，底层软件缺陷被找出并修复之后，就集成在一起，对模块的组合进行集成测试（integration testing）。
这个不断增加的测试过程继续进行，加入越来越多的软件片段，直至整个产品---至少是产品的主要部分-----在称为系统测试（system testing）的过程中一起测试。
递增测试分为两条途径：1自底而上(bottom-up)2自顶而下（top-down）单元测试定义：针对单个软件组件的测试称为单元测试（组件测试）。
目的：为了验证软件组件是否按照组件详细说明的要求工作，发现需求和设计中存在的错误以及编码过程中引入的错误。
组件测试的任务：局部数据结构测试、组件边界值测试、组件中独立的执行路径测试，以及组件的错误处理测试等方面。
组件测试：包括性能测试和特定的非功能测试。
桩或驱动器：需要一些辅助的组件与被测组件一起形成一个可运行的系统，这些辅助的组件称为桩、驱动器等。
桩的定义：1.驱动器模块：用于模拟被测组件的上级模块，它生成测试数据，把相关数据传送给被测组件，启动被测组件获得反馈信息并输出相应的结果。
2.桩模块：用于模拟被测组件工作过程中所调用的模块，它们一般只进行很少的数据处理，例如打印返回信息。
组件测试目的：通过组件测试可以发现各种典型的软件缺陷，例如计算错误、需求或功能遗漏或程序路径选择错误。
![明尼苏达多相人格测验（MMPI,399题）实验报告[5篇范例]](https://img.taocdn.com/s1/m/88b29fe585254b35eefdc8d376eeaeaad1f316a0.png)
