测试基础理论整理

软件测试流程

一、测试需求分析阶段

阅读需求，理解需求，与客户、开发、架构多方交流，深入的了解业务，分析需求点，并要参与需求评审会议。

二、测试计划阶段

主要任务就是编写测试计划，参考软件需求规格说明书，项目总体计划，内容包括测试范围（来自需求文档），进度安排，人力物力的分配，整体测试策略的制定。风险评估与规避措施有一个制定。

三、测试设计阶段

根据测试计划、任务分配、功能点划分，设计合理的测试用例，在设计过程中会参考需求文档（原型图），概要设计，详细设计等文档，用例编写完成之后会进行评审。

四、测试执行阶段

1、搭建环境，执行冒烟测试（预测试），然后进入正式测试，根据测试用例的详细步骤，执行测试用例执行结果记录和bug记录。

2、对每个case记录测试的结果，有bug的在测试管理工具中编写bug记录。要求追踪leader分配给你追踪的bug，直到 bug fixed。

3、测试日报测试人员对每天测试项目发送测试报告(若无要求，则不需要发送日报)。

日报所含内容：

（1）对当前测试版本质量进行分级

（2）严重阻塞进度的问题提出，提示开发同学优先修改

（3）对版本整体测试进度进行评估

（4）产品上线前，测试发送测试报告

五、测试评估阶段

通过不断测试、追踪，直到被测软件达到测试需求要求，并没有重大bug. 出测试报告，可以上线，否则终止上线。

软件测试过程理念

1.尽早测试

测试人员早期参与软件项目

尽早的开展测试执行工作

2.全面测试

对软件的所有产品进行全面的测试

软件开发及测试人员(有时包括用户)全面的参与到测试工作中

3.全过程测试

测试人员要充分关注开发过程。

测试人员要对测试的全过程进行全程的跟踪。

4.独立的、迭代的测试

测试活动是独立的。

测试活动应该是循环往复、不断的进行。

软件测试对象

对于当前的测试行业来说最经常测试的主题就是软件（主体功能），但是一个软件也不仅仅只有功能需要测试，对于一款软件来说从无到有需要不同的过程阶段，每个阶段都会有相应的测试对象。

1.需求分析阶段：各种需求规格说明

2.软件架构设计：api接口文档（接口测试）

3.编码实现阶段：源代码（白盒测试、单元测试）

4.系统功能使用：软件功能主体

软件测试模型

瀑布模型

瀑布模型的核心思想是按工序将问题简化，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。

 优点：

1）为项目提供了按阶段划分的检查点。

2）当前一阶段完成后，您只需要去关注后续阶段。

3）可在迭代模型中应用瀑布模型。增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本，同时增加更多的功能。每次迭代必须经过质量和集成测试。

4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

缺点：

1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。

2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。

3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

4）瀑布模型的突出缺点是不适应用户需求的变化。

V模型

V模型的过程：用户需求一需求分析一概要设计一详细设计一编码一单元测试一集成测试一系统测试一验收测试。

 优点：

1) V的左端表示传统的瀑布开发模型，V的右端明确地将测试分为不同的级别或阶段，测试过程更为具体。

2) 测试各个阶段和开发的各个阶段相对应。

3) V模型的测试策略包括低层测试和高层测试，低层测试是为了源代码的正确性，高层测试是为了整个系统满足用户的需求。

缺点：

1) 测试的对象就是程序本身。忽视了测试活动对需求分析，系统设计等活动的验证和确认的功能，直到后期的验收测试才被发现。

2) 测试是开发之后的一个阶段。实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。

W模型

W模型的过程：

左边V是：需求分析一概要设计一详细设计一编码实现一模块集成一系统构建一系统安装。

右边V是：需求測试一概要设计测试一详细设计测试一单元测试一集成测试一系统测试一验收测试。

优点：

1) W模型体现了尽早和不断测试的原则，既强调测试方案设计，也强调测试执行。

2) 左側V是开发，右侧V是与开发并行的测试，相对于V模型，W模型増加了软件各开发阶段中应同步进行的验证和确认活动，W明确表示出了测试与开发的并行关系。测试与开发是同步进行的，有利于尽早地全面的发现问题。

3) 测试伴随整个软件开发周期，且测的对象不仅仅是程序，需求、设计等同样要测试。

缺点：

在模型中，需求、设计、编码等活动被视为串行的，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结東，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型，不利于当前软件开发复杂多变的情况。

H模型

H模型将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。H模型的测试流程是只要测试准备工作完成，达到测试就绪点，测试就可以执行了。

优点：

1) 软件测试不仅仅指测试的执行，还包括很多其他的活动。

2) 软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。

3) H模型反映出软件测试要尽早准备，尽早执行。

软件测试可以进行迭代、反复进行。

X

 X模型提出先对程序片段进行独立的测试和编码，再进行频繁的交换，通过集成形成可执行程序（左边部分）。集成的可执行程序进行集成测试，通过集成测试的程序可能成为更大范围集成的一部分，也可能（形成最终产品时）封版提交给客户（右上部分）。另外，可以对集成的程序进行测试计划外的探索性测试（右下部分）。

优点：通过分离-集成的方法使得测试变得灵活。探索性测试能帮助有经验的测试员发现更多计划之外的错误。

缺点：探索性测试对测试员有一定的经验要求，并且会照成一定的人力、财力、时间损耗。

软件测试分类

按开发阶段划分：单元测试，集成测试，确认测试，系统测试，验收测试    

按测试组织划分：开发方测试（α测试），用户测试（β测试），第三方测试     

按测试技术划分：白盒测试，黑盒测试，灰盒测试

按代码运行划分：静态测试、动态测试

按测试类型划分：功能测试、性能测试、安全测试、易用性测试、兼容性测试

按开发阶段划分

单元测试

对编写的每一个程序模块进行测试，可以是一个接口，一个类，一个函数，也称为模块测试。

集成测试

在模块测试通过后，对集成在一起的模块组件进行测试，也称为部件测试。

确认测试

集成测试后，对系统是否满足软件需求说明书中规定的要求进行测试。

系统测试

将软件安装在运行环境下，对硬件，网络，操作系统及支撑平台等构成的整体系统进行测试。

验收测试

按照软件项目任务书或合同，供需双方约定的验收含依据文档进行的对整个系统的测试与评审，决定是否接受或拒收系统。

按测试组织划分

开发方测试（α测试）

在软件开发环境下，由开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。

用户测试（β测试）

在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现否符合自己预期的要求。

第三方测试

介于软件开发方和用户方之间的测试组织的测试。第三方测试也称为独立测试。软件质量工程强调开展独立验证和确认活动。

按测试技术划分

白盒测试

又称为结构测试或逻辑驱动测试，是一种按照程序内部逻辑结构和编码结构，设计测试数据并完成测试的一种测试方法。

黑盒测试

又称为数据驱动测试，把测试对象当做看不见的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性，它是站在使用软件或程序的角度，从输入数据与输出数据的对应关系出发进行的测试。

灰盒测试

是一种综合测试法，它将“黑盒”测试与“白盒”测试结合在一起，是基于程序运行时的外部表现又结合内部逻辑结构来设计用例，执行程序并采集路径执行信息和外部用户接口结果的测试技术。

按代码运行划分

静态测试

指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。

动态测试

是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能指标。

按测试类型划分

功能测试

测试软件的功能是否符合功能性需求，通常采用黑盒测试方式。一般由独立的测试人员执行。

性能测试

测试软件在各种状况下的性能，如在正常或最大负载下的状况。

安全测试

测试该系统防止非法侵入的能力。

易用性测试

测试软件是否易用，主观性比较强。一般要根据很多用户的测试反馈信息，才能评价易用性。

兼容性测试

测试该系统与其它软件硬件兼容的能力。

软件测试原则

基于测试是为了寻找软件错误与缺陷，评估与提高软件质量提出了以下原则：

1）所有的软件测试都应追溯到用户需求

2）应当把“尽早地和不断的进行软件测试”作为软件测试者的座右铭

3）完全测试是不可能的，测试需要终止

4）测试无法显示软件潜在缺陷

5）充分注意测试中的群集现象

6）程序员应避免检查自己的程序

7）尽量避免测试的随意性

软件需求分析

目标分析

对软件测试要解决的问题进行详细的分析

弄清楚参与软件测试活动的相关人员对软件测试活动和交付物的要求，包括需要输入什么数据、要得到什么结果、最后应输出什么等。

步骤分析

根据软件开发需求说明书逐条列出软件开发需求，并判断其可测试性

形成可测试的描述并界定出测试范围

根据质量标准，逐条制定质量需求，即测试通过标准分析测试执行时需要实施的测试类型

测试用例

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

测试用例应该包含以下内容：

标识符：由测试设计过程说明和测试程序说明引用的惟一标识符

测试项：描述被测试的详细特性、代码模块等，应该比测试设计说明中所列的特性更加具体。还要指出引用的产品明书或者测试用例所依据的其他设计文档。

输入说明：该说明列举执行测试用例的所有输入内容或者条件。

输出说明：描述进行测试用例预期的结果。

环境要求：是指执行测试用例必要的硬件、软件、测试工具、人员等。

特殊要求：描述执行测试必须的特殊要求。

用例之间的依赖性：如果一个测试用例依赖于其他用例，或者受其他用例的影响，就应该在此注明。

用例设计和编写的作用：

有效性：测试用例是测试人员测试过程中的重要参考依据。

可复用性：良好的测试用例具有重复使用的功能，使得测试过程事半功倍，提高测试效率。

易组织性：即使是小的项目，也可能会有几干甚至更多的测试用例，测试用例可能在数月甚至几年的测试过程中被创建和使用。

可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证。

可管理性：测试用例也可以作为检验测试人员进度、工作量以及跟踪/管理测试人员的工作效率的标准。

测试用例的设计

编写测试用例之前我们需要对项目的需求有清晰的了解，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数，作为测试用例的编写者不仅了解要有常见的测试用例编写方法，同时需要了解被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构。步骤：

1、测试需求分析

从项目部拿到软件的需求规格说明书后，开始对项目的需求进行分析，通过自己的分析、理解，整理成为测试需求， 清楚分析出被测试对象具有哪些功能。 明确测试用例中的测试集用例与需求的关系，即一个或多个测试用例集对应一个测试需求。

2、业务流程分析

分析完需求后，明确每一个功能的业务处理流程，不同的功能点作业务的组合，以及项目的隐式需求。如遇复杂的测试用例设计前，先画出软件的业务流程。从业务流程上，应得到以下信息：

A、 主流程是什么?

B、 条件备选流程是什么?

C、 数据流向是什么?

D、 关键的判断条件是什么?

3、测试用例设计

完成以上两步则可进行测试用例设计，功能测试用例，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。设计测试用例的常见方法：

1）等价类    

2）边界值    

3）因果图    

4) 判定表    

5) 状态迁移    

6) 正交实验    

7) 场景法    

8) 错误推断

（注意：编写测试用例时，我们尽可能取的不应该是有效等价类而应该是无效等价类）

4、编写完成后自我检查以及部门内部评审

1）测试用例本身的描述是否清晰，语言准确；是否存在二义性；

2）测试用例内容是否完整，是否清晰的包含输入和预期输出的结果；测试步骤是否清晰；3）测试用例中使用的测试数据是否恰当，准确；

4）测试用例是否具有指导性，是否能灵活的指导软件测试工程师通过测试用例发现更多的缺陷，而不是限制他们的思维；

5）是否考虑到测试用例执行的效率。对于不断重复执行的步骤，是否保证了验证点相同；或者测试用例的设计是否存在冗余性等。这些都可能导致测试用例执行效率低下；

6）画出软件需求跟踪矩阵，验证测试用例是否完全覆盖了需求，验证测试用例的覆盖性；7）测试用例是否完全遵守了软件需求的规定。这一点其实有一些难做到。考虑到时间/成本的关系，应该视具体情况而定。

5、测试用例更新完善测试

用例编写完成之后需要不断完善，如遇需求更改或功能新增时，测试用例必须配套修改更新，同时在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。

测试用例执行过程

首先搭建测试环境，准备好测试数据，进行预测，预测通过之后，按照测试用例进入正式测试，有效的测试执行可以将测试用例发挥最大的价值。因此，测试用例规范执行有助于更好的发现代码中存在的缺陷。好的测试执行应该包含如下内容：

1、测试执行中评估测试执行时间不足，需及时上报风险。满足质量优先，进度其次原则。2、测试用例按优先级顺序执行，通常是基本、详细和异常顺序执行。

3、未执行用例、标志为删除或者无效的用例，需注明原因。

4、执行过程中有疑问的测试用例（场景、操作步骤、检查点等）需找测试设计人员澄清。5、测试执行需对用例描述的检查点逐一检查，避免遗漏。

6、重视不易重现的缺陷场景，可能是一个bug。

7、执行过程中发现有前期设计遗漏用例需补充到用例文档并执行验证。

8、建议测试人员交叉执行重复测试用例，用例执行对相同测试人员有免疫性。避免可能的缺陷一直遗漏到现网。

9、如有需要，建议保留测试结果，结果可视。也便于不同版本间的测试结果对比。

10、已确认问题需及时按照问题单提单要求（规范和缺陷定级）提单。

11、跟踪问题单修复情况并回归验证问题单。

12、每轮次测试结束，find一下是否有core文件产生。

13、测试结束，将最终测试用例文档上传到归档目录，实现用例重用。

测试报告内容总结

首页 

引言（目的、背景、缩略语、参考文献）

测试概要(测试方法、范围、测试环境、工具)

测试结果与缺陷分析（功能、性能）

测试结论与建议（项目概况、测试时间 测试情况、结论性能汇总）

附录（缺陷统计）

至此并不算最后的完结工作，软件测试还包含了线上功能检查、当前版本问题反馈以及改进建议 等。这样才算是软件测试最终结束，软件测试是贯穿于整个软件生命周期的。

注意事项

不要设计”穷举测试用例”

在详细测试用例与有效测试时间中找到平衡点

好的测试用例应该多关注”反向测试问题”

测试用例库应该不断更新和维护

测试用例可以复用，但要注意数据有效性与环境变化

测试用例是设计出来的，不是写出来的

多去学习经验丰富的测试工程师所设计的测试用例

针对不同的需求类型和测试对象，灵活采用不同的测试用例设计方法

黑盒测试用例方法

等价类划分法

什么是等价类     

等价类是某个输入域的集合，在这个集合中每个输入条件都是等效的。如果其中一个的输入不能导致问题发生，那么集合中其它输入条件进行测试也不可能发现错误。等价类分为有效等价类和无效等价类。

有效等价类    

有效等价类就是由那些对程序的规格说明有意义的、合理的输入数据所构成的集合，利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

无效等价类  

无效等价类就是那些对程序的规格说明不合理的或无意义的非法的输入数据所构成的集合。

什么是等价类划分

等价类划分法是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的，常用的黑盒测试用例设计方法。划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并是整个集合。

等价类的原则

如果规定了输入值的范围(闭区间)，可以分为一个有效等价类，两个无效的等价类；

如果输入是布尔表达式，可以分为一个有效等价类和一个无效等价类；

如果规定了输入数据的一组值，而且程序对不同输入值做不同的处理，则每个允许的输入值

是一个有效的等价类，此外还有一个无效的等价类（任意一个不允许的输入值）；

如果规定了输入数据必须遵循的规则，可以划分出一个有效的等价类（符合规则）和若干个

无效的等价类（从不同角度违反规则）。

等价类划分的测试用例设计

测试用例设计原则根据等价类表，然后从划分出的等价类中按以下三个原则设计测试用例：

1、为每一个等价类规定一个唯一的编号。

2、设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止。

3、设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。

等价类划分法优缺点

等价类划分法的优点是考虑了单个输入域的各类情况，避免了盲目或随机选取输入数据的布完整性和覆盖的不稳定性。

等价类划分法虽然简单易用，但是没有对组合情况进行充分的考虑。需要结合其他测试用例设计的方法进行补充。如边界值分析法常与等价类分析法结合使用。

边界值分析法

什么是边界值分析      

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。

边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。      

边界值分析关注的是输入空间的边界，边界值测试背后的基本原理是错误更可能出现在输入变量的极值附近。

与等价划分的区别  

1)边界值分析不是从某等价类中挑一个为代表，而是使这个等价类的每个边界都作为测试条件。  

2)边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

边界值分析方法

1）如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。

2）如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据。    

3）根据规格说明的每个输出条件，应用前面的原则①②。    

4）如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。

5）如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。

6）分析规格说明，找出其它可能的边界条件。

因果图法

什么是因果图      

是一种从用自然语言书写的程序规格说明的描述中找到因（输入条件）和果（输出或程序状态的改变）的关系，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

因果图能检查出规格的错误，并最终导出为判断表。

因果图基本关系 因果关系中的四种基本关系：恒等、非、或、与。 

因果图分析的特点

考虑输入条件间的组合关系；

考虑输出条件对输入条件的信赖关系，即因果关系；

测试用例发现错误的效率高；

能检查出功能说明中的某些不一致或遗漏；

因果图方法最终生产的就是判定表，它适合于检查程序输入条件和各种组合情况。

因果图分析

1) 分析软件规格说明描述中， 那些是原因(即输入条件或输入条件的等价类)，那些是结果(即输出条件)， 并给每个原因和结果赋予一个标识符

2) 分析软件规格说明描述中的语义.找出原因与结果之间， 原因与原因之间对应的关系. 根据这些关系，画出因果图

3) 由于语法或环境限制， 有些原因与原因之间，原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况， 在因果图上用一些记号表明约束或限制条件

4) 把因果图转换为判定表

5) 把判定表的每一列拿出来作为依据，设计测试用例

判定表法

判定表也称为决策表，能表示输入条件的组合，以及与每一输入组合对应的动作组合。与因果图法相似，判定表法主要侧重输入条件之间的逻辑关系。

判定表主要包含以下五部分：

条件桩：列出所有可能的条件

条件项：列出所有的条件取值组合

动作桩：列出所有可能的操作

条件项：列出在每一种条件取值组合的情况下，执行动作桩中的哪些动作。

规则：一种条件取值组合与其对应的动作组合（即判定表中贯穿条件项和动作项的一列）构成判定表的一个规则。条件组合的数目就是规则的数目。

建立判定表可遵循的步骤

1）列出条件桩和动作桩

2）确定规则的个数，用来为规则编号。若有n个原因，且每个原因的可取值为0或者1，那么将会有2n个规则。

3）完成所有条件项的填写。

4）完成所有的动作项的填写。（得到初始判定表）

5）合并相似规则，用以对初始判断表进行简化。有两个或者多条规则具有相同的动作，并且条件项之间存在极为相似的关系就可以进行合并。

适合使用判定表设计测试用例的条件：

规格说明以判定表的形式给出，或很容易转换成判定表

条件的排列顺序不影响执行哪些操作

规则的排列顺序不影响执行哪些操作

当某规则的条件已经满足，并确定要执行的操作后，不必检验别的规则

如果某一规则要执行多个操作，这些操作的执行顺序无关紧要

场景法

什么是场景法

场景法是通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。

设计测试用例

1. 根据说明，描述出程序的基本流及各项备选流。

2. 根据基本流和各项备选流生成不同的场景。

3. 对每一个场景生成相应的测试用例。

4. 对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值。

场景法设计测试用例的优缺点

优点：涉及到业务流程的业务需求适合用场景法。

缺点：只验证业务流程，不验证单点功能，一般先采用先用等价类，边界值，错误推断，判定表等方法对单点功能进行验证，验证通过后再采用场景法进行业务流程的验证。

正交实验法

正交实验法就是利用正交表来对试验进行整体设计、综合比较、统计分析，实现通过少数的实验次数找到较好的生产条件，以达到最好效果。这种试验设计法是从大量的试验点中挑选适量的具有代表性的点，利用已经造好的正交表来安排试验井进行数据分析的方法。

基本思想

在一项试验中，把影响试验结果的量称为试验因素(因子），简称因素。在试验过程中每一个因素可以处于不同的状态或状况，把因素所处的状态或状况，称为因素的水平，简称水平。

每列中不同数字出现的次数相等。这一特点表明每个因素的每个水平与其他因素的每个水平参与饰演的几率是完全相同的，能有效的比较实验结果并找出最优的实验条件。

在任意两列其横向组成的数字对中，每种数字对出现的次数相等。这个特点保证了试验点均匀地分散在因素与水平的完全组合之中。

正交法实现的基本步骤

确定因素：这里的因素是指对软件运行结果有影响的软件

确定因素的取值范或集合

因素的取值范围是指软件输入的取值范围或集合以及可用的硬件资源

确定每个因素的水平

根据因素的取值范围或集合，采用等价类划分、边界值分析以及其他软件测试技术，在 每个因素的取值范围或集合内挑出有效等价类、无效等价类、正好等于、刚刚大于或刚 刚小于边界值等有代表性的测试值

选择正交表

根据确定的因素和水平，选择适合的正交表

如果没有合适的正交表可用或需要的测试用例个数太多，要对因素和水平进行调整

功能图法

功能图方法是用功能图形象的描述程序的功能说明，并机械的生成功能图的测试用例。功能图由状态迁移图和逻辑功能模型构成：

状态迁移图

用于表示输入数据序列以及相应的输出数据。在状态迁移图中，由输入数据和当前状态决定输出数据和后续状态。

逻辑功能模型

用于表示在状态中输入条件和输出条件之间的对应关系。逻辑功能模型仅用于描述静态说明，输出数据仅由输入数据决定。测试用例则是由测试中经过一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成。

导出测试用例的步骤

1、明确状态节点。分析被测对象的测试特性及需求规格说明书，明确被测对象的状态节点数量及相互迁移关系。

2、绘制状态迁移图。利用圆圈表示状态节点，有向箭头表示状态间的迁移关系，根据需要在箭头旁边标识迁移条件。可以利用绘图软件绘制状态迁移图。

3、绘制状态迁移树。根据状态迁移图，按照广度优先和深度优先搜索绘制状态迁移树。首先确定起始节点和终止节点，在绘制时，当路径上遇到终止节点时，不再扩展，遇到已经出现的节点也停止扩展。

4、抽取测试路径设计用例。根据绘制好的状态迁移树，提取测试路径，从左到右，横向抽取，每条路径构成一条测试规则，然后再利用等价类和边界值等测试用例设计方法设计具体的测试用例。

用例方法选择

1、首先进行等价类划分

2、在任何情况下都必须使用边界值分析法

3、如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法

4、对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果

5、对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程

6、可以用错误推测法追加一些测试用例

缺陷

什么是缺陷

软件未实现产品说明书要求的功能

软件出现了产品说明书指明不应该出现的功能

软件实现了产品说明书未提到的功能

软件未实现产品说明书虽未明确提及但应该实现的目标

软件难以理解、不易使用、运行缓慢或者(从测试的角度看)最终用户会认为不好

缺陷属性

1.缺陷标识(Identifier)：缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识。

2.缺陷类型 (Type)：缺陷类型是根据缺陷的自然属性划分的缺陷种类。

3.缺陷严重程度 (Severity) ：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。

4.缺陷优先级(Priority)：缺陷的优先级指缺陷必须被修复的紧急程度。

5.缺陷状态(Status) ：缺陷状态指缺陷通过一个跟踪修复过程的进展情况。

6.缺陷起源(Origin) ：缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。

7.缺陷来源(Source)：缺陷来源指引起缺陷的起因。

8.缺陷根源(Root Cause)：缺陷根源指发生错误的根本因素。

缺陷的级别

1、微小的（Minor）。一些小问题如有个别错别字、文字排版不整齐等，对功能几乎没有影响，软件产品仍可使用。

2、一般的（Major）。不太严重的错误，如次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等。

3、严重的（Critical）。严重错误，指功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失，或致命的错误声明。

4、致命的（Fatal）。致命的错误，造成系统崩溃、死机，或造成数据丢失、主要功能完全丧失等。

产生缺陷的原因

人员之间的沟通交流不够，交流上有误解或者根本不进行交流

文档不完善甚至没有文档

需求不断的变化

参与人员的过度自信

程序设计本身有错误

软件复杂度大，缺陷很难避免

工期短，任务重，时间压力大