ISTQB认证-关于ISTQB一些知识点总结

如果要转载请注明 原文链接哦！ http://blog.csdn.net/maxdong24

ISTQB知识点总结：

注释：
K1：表示一般理解 K2：表示一般掌握 K3：表示重点掌握并能够应用

1.导致软件缺陷的原因（K2）
缺陷是错误的结果，更精确地说，缺陷是错误的表现。当缺陷被执行时会导致失效的发生。

2.软件测试在软件开发、维护和使用中的角色（K2）
软件测试是软件开发过程中关键的质量保证活动，是软件质量保证的一个环节。在软件开发过程中实施严格规范的测试有助于发现软件开发过程中不同阶段的缺陷，尽可能的将缺陷发现于本阶段并予以纠正，避免将缺陷带入下一个开发阶段，因为缺陷具有扩展的特点。所以在软件开发过程中，对文档和代码的测试会对软件的质量起到关键作用。
在软件的维护阶段，由于软件可能发生修改和功能增强，所以软件测试能发现由于修改和功能增强可能导致软件系统出现的问题，包括对文档和软件系统的测试。
软件在使用过程中可能由于硬件、环境及软件等原因出现各种问题，那么这些问题只有通过测试才能找到问题所在，或者通过软件测试模拟可能出现的问题。

3.什么是软件测试（K2）
“软件测试”的经典定义是在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。

4.什么是软件质量
“软件质量”是：软件满足规定或潜在用户需求特性的总和。

5.软件测试和软件质量保证的区别
区别如下：
质量保证：质量保证的重要工作通过预防、检查与改进来保证软件质量。QA采用“全面质量管理”和“过程改进”的原理开展质量保证工作，所关注的是软件质量的检查与测量，主要着眼于软件开发活动中的过程、步骤和产物，而不是对软件进行剖析找出问题或评估。

软件测试：测试虽然也与开发过程紧密相关，大关心的不是过程的活动，而是对过程的产物以及开发出的软件产品进行剖析。测试人员要“执行”软件，对过程中的产物——开发文档和源代码进行走查，运行软件，以找出问题，报告质量。

6.软件测试的目的和一般原则（K2）
测试是程序的执行过程，目的在于发现错误；
一个好的测试用例在于能发现至今未发现的错误；
一个成功的测试是发现了至今未发现的错误的测试。

测试原则如下几点：
1） 所有的软件测试都应追溯到用户需求；
2） 应当把“尽早的和不断地进行软件测试”作为软件测试者的座右铭。
3） 完全测试是不可能的，测试需要终止；
4） 测试无法显示软件潜在的缺陷；
5） 充分注意测试中的群集现象；
6） 程序员应该避免检查自己的程序；
7） 尽量避免测试的随意性。

7.基本的软件测试过程（K2）
软件测试过程包括：
软件测试计划和控制
测试分析和设计
测试实施和执行
退出测试的标准
测试报告
测试结束活动等方面

8.V模型（K2）

1）单元测试：与详细设计对应的是单元测试。单元测试检测代码的开发是否符合详细设计的要求。它主要是对详细设计中的每个功能单元（通常是函数或过程）进行逻辑覆盖测试，因此这种测试偏重于白盒测试。

2） 集成测试：与概要设计对应的是集成测试。因为概要设计的工作主要是根据功能把大的系统进行模块分解，所以集成测试的工作主要是，把各模块逐步集成在一起，来测试数据是否能够在各模块间正确流动，以及各模块能否正确同步。因为这种测试依赖于软件的架构但又不关心每个函数的实现细节，所以该测试关注的是模块之间的接口。

3）系统测试: 与需求分析对应的是系统测试。因为系统的需求分析的工作是分解用户的功能和性能需求并规格化，并对应到系统中。所以系统测试的工作主要就是测试这些功能和性能指标是否都在软件中正确实现。系统测试检测已集成在一起的产品是否符合系统规格说明书的要求。该测试把软件作为一个黑盒，针对每个需求规格组织各种输入并根据软件输出来判断该需求规格是否正确实现，因此系统测试偏重于黑盒测试。

4）验收测试：与用户需求对应的是验收测试。是针对系统是否满足用户需求、业务流程等的验收。当技术部门完成了所有测试工作后，由业务专家或用户进行验收测试，以确保产品能真正符合用户业务上的需要。

9.软件测试级别（K3）
1）单元测试：
单元测试或者模块测试是针对各个代码单元或者模块进行的测试。测试仅围绕着具体的程序模块进行。

单元测试中常见的问题就是如何划分单元以及独立地对其进行测试。

传统的单元测试术语（unit testing terminology） 包括了驱动模块（driver） 和 桩模块（stub）。driver的目的很单纯，就是为了访问类库的属性和方法，来检测类库的功能是否正确；stub的目的同样单纯，就是提供需要和测试类库交互的那些类的实现。

单元测试必须将代码单元或模块与系统其他部分隔离，进行独立的测试。

2）集成测试：
集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。集成测试的工作主要是，把单元测试过的各模块逐步集成在一起，来测试数据是否能够在各模块间正确流动，以及各模块能否正确同步。

集成测试基本可以概括为以下两种：
- 非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求一次全部组装起来所要的系统，然后进行整体测试。
- 渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个模块结合进来测试。

集成测试可以分为两种：手工黑盒和代码灰盒。手工黑盒与后续的系统测试的测试用例存在重用，代码灰盒是指针对组件的接口采用代码调用的方式来测试，一般不会涉及白盒测试，即不关心组件内部是如何实现，只关心组件的接口。

3）系统测试：
系统全部组装完毕以后的测试是系统测试。系统测试的工作主要就是测试用户的功能和性能需求指标是否都在软件中正确实现。系统测试检测已集成在一起的产品是否符合系统规格说明书的要求。该测试把软件作为一个黑盒，针对每个需求规格组织各种输入并根据软件输出来判断该需求规格是否正确实现，因此系统测试偏重于黑盒测试。

系统测试人员负责制定测试计划并依照测试计划进行测试。这些测试包括功能性的测试（黑盒测试）和非功能性的测试（如，压力测试等）。测试人员需要良好的测试工具来辅助完成测试任务，自动化的测试工具将大幅度提高测试人员的工作效率和质量。

4）验收测试：
验收测试也叫做确认测试是软件开发结束后，验证软件的功能和性能及其它特性是否与用户的要求一致。验收测试包括用户验收测试、系统管理员的验收测试（包括测试备份和恢复、灾难恢复、用户管理、任务维护、定期的安全漏洞检查等）、基于合同的验收测试，α和β测试。验收测试是对软件质量评价的一个重要标准。

用户验收测试可以分为几个大的部分：确认测试的标准，软件配置审核（软件配置内容：可执行程序、源程序、配置脚本、测试程序或脚本。），可执行程序测试，α、β测试。其大致顺序可分为：文档审核、源代码审核、配置脚本审核、测试程序或脚本审核、可执行程序测试，α、β测试。

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

确认测试的测试内容：

（1）安装测试
（2）功能测试
（3）可靠性测试
（4）安全性测试
（5）时间及空间性能测试
（6）易用性测试
（7）可移植性测试
（8）可维护性测试
（9）文档测试

10.软件测试类型（K3）
功能性测试和非功能性测试。
功能需求指明软件必须执行的功能，定义系统的行为——即软件在某种输入条件下要给出确定的输出必须做的处理或转换。功能需求通常是软件功能的“硬指标”——如“支持分布式环境中消息的可靠传输”；
非功能需求不描述软件做什么，描述软件如何做。非功能需求通常作为软件设计的“软指标”——如“系统具有可伸缩性”。为此，我们可以把功能需求对应的功能称为“功能性特征”，把非功能需求对应的功能称为“非功能性特征”。

1） 功能性测试（黑盒测试（Black-box Testing）又称为功能测试或数据驱动测试）
把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。
采用黑盒技术设计测试用例的方法有：
等价类划分、边界值分析、决策表法、正交实验法，场景法等。

黑盒测试试图发现以下类型的错误：1）功能错误或遗漏；2）界面错误；3）数据结构或外部数据库访问错误；4）性能错误；5）初始化和终止错误。

2） 非功能性测试：
非功能性测试主要是基于产品的性能、负载、可用性、交互性、可维护性、可靠性及可移植性等方面的测试。还应该包括测试产品是否遵从指定的标准、规范和约束，以及操作界面的具体细节和构造上的限制。

3） 白盒测试：(White-box Testing，又称逻辑驱动测试,结构测试)
把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判（断）定覆盖、条件覆盖、判（断）定/条件覆盖、条件组合覆盖和路径覆盖。这六种覆盖标准发现错误的能力呈由弱至强的变化。

“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。

4） 再测试回归测试
当一个缺陷被发现并被改正之后，软件应该重新进行测试（再测试）以确保原来的缺陷成功地被消除。当软件相关模块（组件）修改以后或软件增加了相关模块（组件），为了确保软件的正确性，也必须对相关模块进行回归测试。

5） 维护性测试：
维护测试通常始于客户对系统变化或发布下一个版本需求的确认。软件测试管理人员也会以这些确认文档为基础设计维护测试计划。有了明确的测试目标后，测试员应该设计并执行新的测试用例、修改过的测试用例以及回归测试。在维护测试结束后，这些测试及结果也应该保留起来。

6） 静态测试技术：
软件工作产品可以通过不同的静态技术进行检查以评估工作产品的质量，而这种静态技术不同于软件的动态测试技术。静态测试是相对于动态测试而言的，即不要求在计算机上实际执行所测程序所进行的测试。静态测试主要以一些人工的模拟技术对软件进行分析和测试，是白盒测试方法的一种，包括代码检查、静态结构分析等。

静态测试可以分为评审和工具支持的静态测试技术。相对于动态测试而言，静态测试成本更低，效率较高，更重要的是可以在软件开发生命周期早期就发现缺陷和问题。

11.评审相关
1）评审定义
评审是指由软件工作产品生产者的同行遵循已定义的规程对产品所做的评审，目的在于识别出缺陷和需改进之处。
评审是一个总体的概念，在实际执行时有不同的组织形式，由严格的，也有松散的。根据具体情况的不同，可以把评审分为非正式评审和正式评审。
- 非正式是指工作产品没有完成，正在开发中不需要遵循明确定义的过程等情形。
- 正式是指作者已经确认工作产品已经完成，评审会议遵循一个已经明确定义的过程，参与人员有明确的职责与检查表. 不同的角色明确定义的进入与完成准则。

其中正式评审根据评审对象，关注内容等不同，又分为走查，技术评审和正规检视。

2）评审过程
评审过程一般包括：计划阶段、准备阶段、自评审阶段、评审会阶段、重新修改阶段和分析总结阶段。

A.计划阶段
定义评审标准
选择人员
分配角色
为更加正式的评审类型（比如审查）制定入口和出口准则；
选择需要进行评审的文档的内容
核对入口准则（针对更正式的评审类型）

B.预备会阶段
分发文档
向评审参与者解释评审的目标、过程和文档

C.个人准备阶段（自评审）
先行评审文档，为评审会议做准备
标注可能的缺陷、问题和建议

3）责任和角色
在正式的评审中一般包括如下角色：协调负责人、作者、记录员、评审者。他们在正式的评审中承担不同的责任。不同的评审形式可能包括更多种角色。

12.走查相关
1）定义：
走查是评审的一种基本形式，但评审对象主要是软件代码，通过对源程序代码进行分析、检验，并补充相关的文档，发现程序中的错误。

一般由作者和一个以上其他评审人员组成。

2）目的：
进行走查的方式，主要对以下内容进行检查：
- 检查代码和设计的一致性
- 代码对标准的遵循、可读性
- 代码逻辑表达的正确性
- 代码结构的合理性
- 程序编写与编写标准的符合性
- 程序中不安全、不明确和模糊的部分
- 编程风格问题等
3）走查过程：
计划走读会议；
评审产品；
进行走读；
解决缺陷；
记录走读；
返工产品。

13.测试设计技术的分类（K2）
软件测试技术主要包括：黑盒（功能性）测试技术（以规约为基础的测试技术）、白盒（结构性）测试技术（以程序结构为基础的测试技术）及经验为基础的测试。经验为基础的测试主要是根据测试人员的技术、经验及知识来设计测试用例，这是一种测试用例设计的补充。

1） 结构性测试
结构性测试是另一种用于设计测试用例的基本方法。为了与功能性测试形成对比，结构性测试有时叫做白盒(或甚至叫做透明盒)测试

2） 功能性测试（黑盒测试）与结构性测试（白盒测试）的区别
功能性测试只利用规格说明设计测试用例，而结构性测试使用程序源代码(实现)作为测试用例设计的基础。

13.功能性测试（黑盒测试）：
包括等价类划分，边界值分析，决策表、正交实验、use-case以及特殊值法等。
1）等价类划分（K3）
等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。

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

无效等价类：与有效等价类的定义恰巧相反。

2）边界值分析（K3）
边界值分析是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。
对边界值设计测试用例，应遵循以下几条原则：
(1)如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
(2)如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据。
(3)根据规格说明的每个输出条件，使用前面的原则(1)。
(4)根据规格说明的每个输出条件，应用前面的原则(2)。
(5)如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
(6)如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例。

3） 决策表法（K3）
4） 正交试验法 （K2）
5） Use-Case法（场景法）（K3）
6） 基于经验的特殊值测试（K2）
7） 黑盒测试方法的选择（K3）
在任何情况下都必须使用边界值分析方法。经验表明，用这种方法设计出的测试用例发现程序错误的能力最强。

14.结构性测试（白盒测试）：
白盒测试主要是检查程序的内部结构、逻辑、循环和路径。白盒测试的常用测试用例设计方法有：逻辑覆盖和基本路径测试。
根据覆盖测试的目标不同，逻辑覆盖又可分为：语句覆盖、判定覆盖、判定-条件覆盖、条件组合覆盖及路径覆盖。

1） 语句覆盖：语句覆盖就是设计若干个测试用例，运行所测程序，使得每一条可执行语句至少执行一次。语句覆盖是最弱的逻辑覆盖准则。
2） 条件覆盖：条件覆盖就是设计若干个测试用例，运行所测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。
3） 判定覆盖：判定覆盖就是设计若干个测试用例，运行所测程序，使得程序中每个判断的取TRUE分支和取FALSE分支至少经历一次。判定覆盖又称分支覆盖。
4） 判定-条件覆盖：判定-条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断的所有可能判断结果至少执行一次。
5） 条件组合覆盖：条件组合覆盖就是设计足够的测试用例，运行所测程序，使得每个判断的所有可能的条件取值组合至少执行一次。
6） McCabe覆盖

15.测试技术的选择（K2）
边界值测试方法是一种机械的设计用例方法，容易产生冗余的测试用例，因为本方法没有考虑程序变量之间的关系；等价类方法可能存在用例设计的漏洞，因为测试的好坏依赖于等价类的划分的粒度；决策表方法用例的设计花费的时间多等等。所以在具体的软件测试过程中可以使用不同的测试方法来设计一组合理的测试用例集。
另外，结构性的测试方法和功能性的测试方法在测试过程中也可以进行交叉设计，达到互相补充的目的。如，在满足语句覆盖的同时，满足Use-case法的覆盖。

16.传统结构化软件测试（K3）
1）结构化单元测试概念
单元测试是对软件基本组成的单元进行的测试，这里的基本单元不一定是指一个具体的函数(Function或Procedure)或一个类的方法(Method)，“单元”具有一些基本属性，如：
明确的功能、规格定义、与其他部分的明确的接口定义等，可清晰地与同一程序的其他单元划分开来。在具体实现时，也可能对应的是多个程序文件中的一组函数。

单元测试过程分为计划、设计、实现、执行、评估等几个步骤，各步骤的任务如下：
(1)计划单元测试。确定测试需求，制定测试策略，确定测试所用资源(包括人力资源和设备资源)，创建测试任务的时间表等。
(2)分析和设计单元测试。设计单元测试模型，制定测试方案，确认并结构化测试过程。
(3)实现单元测试。参考测试模型和测试方案，制定具体的测试用例，创建可重用的测试脚本。
(4)执行单元测试。根据单元测试的方案、用例对单元进行测试，验证测试的结果并记录测试过程中出现的缺陷。
(5)评估单元测试。对单元测试的结果进行评估，主要从需求覆盖和代码覆盖的角度，进行测试完备性的评估。

2）单元测试的设计模型
因为单元本身不是一个独立的程序，一个完整的、可运行的软件系统并没有形成，所以在测试模型设计中必须为每个单元测试开发驱动模块(Driver)和桩模块(Stub)。在绝大多数应用中，驱动模块只是一个接收测试数据并把数据传送给(要测试的)模块，然后打印相关结果的“主程序”。“桩模块”的功能是替代那些隶属于本模块(被调用)的模块，桩模块要使用子模块的接口，做少量的数据操作，并验证打印入口处的信息，然后返回。

17.测试用例设计原则
(1)为系统运行起来而设计用例
(2)为正向测试而设计用例
(3)为逆向测试而设计用例
(4)为满足特殊需求而设计用例
(5)为代码覆盖而设计用例

18.面向对象的动态测试
1．桩（stub）是代替那些还没实现的或还没有经过测试的部分，在桩内只实现要替代部分的一些基本功能。采用由底向上的方式进行开发，底层的代码先开发并先测试，可以避免编写大量的桩代码。
2．测试驱动器（driver）是一个运行测试用例并收集运行结果的程序。它的主要任务是初始化被测试程序，使被测类处于一个特定的开始状态，然后测试驱动器按照测试用例所定义的输入参数去运行相应的方法（Methods）。在运行过程中要检查被测试部分的状态并做好记录，通过比较期望的结果和实际的结果最终确定是否有错，而期望的结果可以从规范书（specification）内获得，任何偏离规范书（specification）的行为都视为错误。

19.GUI测试概述
图形用户界面的测试（GUI testing）主要包括两项内容：界面显示测试和界面功能测试。

为了更好地进行GUI测试，提倡界面与功能的设计分离。一般可以把 GUI 系统分为3个层次：界面层、界面与功能的接口层、功能层。这样GUI的测试可以把重点放在界面层和界面与功能的接口层上，并可使用黑盒测试原理来进行功能测试（black box testing）。
在设计GUI测试用例时，可以按4个步骤进行思考：
划分界面元素，并根据界面的复杂性进行分级
根据不同的界面级别确定不同的测试策略
进行测试数据的分析，提取测试用例
使用自动测试工具

20.测试经理和测试成员的角色
测试团队中测试经理任务主要有：负责整改测试项目，包括制定测试计划、协调和管理监督测试过程，和其他小组的沟通、协调等。

测试成员负责测试计划中具体事项的执行，记录并报告测试结果等。

21.测试文档 （K2）
每个软件测试项目有5类基本测试文档：
- 测试计划文档
- 测试方案文档
- 测试用例文档
- 测试报告文档

22.测试计划和估算 （K2）
1）在需求分析阶段，要完成验收测试计划，并与需求规格说明一起提交评审。
2）在概要设计阶段，要完成和评审系统测试计划。
3）在详细设计阶段，要完成和评审集成测试计划。
4）在编码实现阶段，要完成和评审单元测试计划。
5）对于测试计划的修订部分，需求进行重新评审。

测试计划中包含的主要内容有：明确要完成的测试活动，评估完成活动所需时间和资源，设计测试组织和岗位职权，进行活动安排和资源分配，安排跟踪和控制测试过程的活动，制定测试策略，确定测试范围、测试目的、测试方法、回归测试的技术要求、测试通过/失败的标准、测试终止准则，进行测试结果分析和度量以及测试风险评估，对测试过程的质量保证和配置管理工作进行明确规定，应交付的测试工作产品。

23．软件配置管理
配置管理是通过对在软件生命周期的不同的时间点上的软件配置进行标识，并对这些被标识的软件配置项的更改进行系统控制，从而达到保证软件产品的完整性和可溯性的过程。

24.项目风险相关
1）项目风险
项目风险是指关于项目按目标交付的能力方面的风险。
如用户需求不明确，项目组未正确理解客户需求，缺乏项目管理经验，资源冲突，进度延误等。
2）产品风险
在软件或系统中的潜在失效的区域（即将来可能发生的不利事件或危险）称之为产品风险，因为它们对产品质量而言是一个风险。
交付后的产品存在问题而导致的风险。
缺陷导致人员的伤害、企业的财政损失、功能失效、性能不良等。
产品风险对于项目的成功来讲是一种特殊类型的风险。
作为一种风险控制活动，测试通过评估修正严重缺陷的能力和应急计划的有效性来提供关于残留风险的反馈信息。

25.测试工具类型
类型
测试管理工具（管理测试用例、脚本、资源、计划、缺陷）
测试控制工具（控制测试执行并收集测试结果）
测试执行（回放）工具（执行脚本并返回测试结果）
测试辅助工具（辅助进行管理、控制、执行、分析、设计等的工具）

常见的测试工具软件
MercuryInteractive - WinRunner, QuickTestProfessional
Segue - Slik Test
IBM Rational – Robot, Functional Tester
Compuware - QARun

---

一些选择题会出现的知识点总结：

1.关于缺陷错误失效：

当存在缺陷的代码被执行时，可能引发的是软件失效，不是错误；
（人为）错误，（内在）缺陷，（外部）失效。失效是缺陷在外部的反映；
静态测试，不运行程序，发现的是缺陷；
动态测试，运行程序，发现的是失效；
程序期望结果和实际结果有所偏差称为失效；
失效也可能是外部环境造成的，如电磁场辐射的影响；
缺陷有可能会导致失效，但不是必然的。如果程序不被运行的话，失效也就不会发生。

2.关于测试不同阶段的目标：
早期测试（静态测试）的目标：预防缺陷。
开发阶段的测试（组件测试，集成测试，系统测试）目标：发现缺陷。
验收测试的目标：建立信心。
运行阶段的测试（维护测试）目标：提供信息。

3.关于测试原则：
1） 所有的软件测试都应追溯到用户需求；
2） 应当把“尽早的和不断地进行软件测试”作为软件测试者的座右铭。
3） 完全测试是不可能的，测试需要终止；
4） 测试无法显示软件潜在的缺陷；
5） 充分注意测试中的群集现象；
6） 程序员应该避免检查自己的程序；
7） 尽量避免测试的随意性；
8） 测试应尽早介入。

4.关于独立测试：
测试人员具有专业测试知识背景，独立测试可以更高效地发现软件缺陷和软件存在的失效；
软件测试与软件开发的思维方式不同。由于思维定势，开发人员难于发现自己的错误；
测试通常被认为是破坏性的活动，而软件开发通常被认为是建设性的活动；
独立测试可以应用在任何级别的测试活动中。

5.关于杀虫剂悖论和缺陷集群性：
定期对TC进行Review并持续改善更新，体现了杀虫剂悖论原则。
很多缺陷会集中在某一模块上，体现了缺陷集群性原则。

6.关于测试类型：
结构性测试又称逻辑驱动测试，功能测试又称数据驱动测试。
与变更相关的测试包括确认测试和回归测试。
可移植性测试属于非功能测试。
非功能测试包括性能，负载，可用性，交互性，可维护性，可靠性及可移植性等方面的测试。
功能测试不考虑程序的具体执行路径，仅关注功能是否实现。
安全性测试和互操作性测试属于功能测试的一种。
交互性测试属于非功能测试。

7.各个类型测试的目的：
集成测试的目的是发现接口和集成后组件间协同工作的缺陷。
系统测试的目的是验证系统是否符合用户需求。
验收测试的目的是对系统或子系统建立信心。
组件测试的目的是检查代码是否符合设计和规范。确认所有的错误处理路径属于组件测试的目的。

8. 关于迭代-增量开发模型：
验证和确认可以在每个增量模块中进行。
在完成第一次迭代后，对所有的迭代进行回归测试会变得越来越重要。
在每次迭代过程中，对迭代产生的系统可能需要在不同的测试级别上进行测试。
迭代开发是先开发大体的框架，后开发具体的详细内容。
增量开发是先开发一个详细的模块，再开发另一个详细的模块，形成一个逐渐增大的系统。

9. 系统测试的测试依据：
系统测试的测试依据：1. 系统和软件需求规格说明 2. 用例 3. 功能规格说明 4. 风险分析报告
集成测试的测试依据：1. 软件和系统设计文档 2. 系统架构 3. 工作流 4. 用例

10. 桩模块与驱动模块相关：
桩模块：对顶层或上层模块进行测试时所编写的替代下层模块的程序。
驱动模块：对底层或子层模块进行测试所编写的调用这些模块的程序。

渐增式测试模式自顶向下集成时，前期完成的模块将是后期模块的驱动程序。
渐增式测试模式自底向上集成时，前期完成的模块将是后期模块的桩程序。

非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求一次全部组装起来所要的系统，然后进行整体测试。非渐增式集成测试是不科学的集成测试方式。
渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个模块结合进来测试。

Alpha测试：潜在客户/用户在开发现场进行的测试。
Beta测试：潜在客户/用户在自己的环境下测试。

11.关于评审相关：
1）正式评审:1. 走查 2. 技术评审 3. 审查。
2）工具支持的静态测试（静态分析）: 1. 词法和语法分析 2. 静态错误分析（控制流分析和数据流分析）。
3）
非正式评审没有正式的过程。
走查由作者主持开会。
技术评审可能是没有管理者参与的同行评审。
审查由专门培训的主持人来领导。根据入口、出口准则的检查列表和规则定义正式的评审过程。

12. 3个测试术语相关：
测试条件—-》能通过1个或多个测试用例进行验证的一个条目或事件（比如功能，事物处理，质量特征或结构元素等。）
测试用例—-》一组输入值，执行的前提条件，预期结果和执行的后置条件等元素组成，以覆盖一定的产生目标或测试条件。
测试规程—-》描述测试用例的执行顺序

补充：
测试条件：组件或系统中能被一个或多个测试用例验证的条目或事件。例如：功能、事物、特性、质量属性或者结构化元素。
测试用例：为特定目标或测试条件而制定的一组输入值，执行入口条件，预期结果和执行出口条件。
测试规程：描述测试用例的执行顺序。
测试设计规格说明：为一个测试条目指定测试条件，具体测试方法，并识别相关高层测试用例的文档。
测试用例规格说明：为测试项指定一套测试用例的文档。
测试规程规格说明：规定了执行测试一系列行为的文档，也称为测试脚本或手工测试脚本。

13. 软件测试设计技术相关：
基于规格说明或黑盒测试技术：等价类，边界值，因果图与决策表，状态转换，用例。
基于结构的或白盒测试技术：语句覆盖，判定覆盖等。
基于经验的测试技术：探索性测试，错误推测法。

14. 使用模型来描述需要解决的问题，软件或其组件的是哪种测试技术？
使用正式或非正式的模型来描述需要解决的问题、软件或其组件，是基于规格说明的测试技术特点。

补充：
基于规格说明的测试技术特点：
使用正式或非正式的模型来描述需要解决的问题、软件或其组件等。
根据这些模型，可以系统地导出测试用例。

基于结构的测试技术特点：
根据软件的结构信息设计测试用例，比如软件代码和软件设计规格说明文档。
可以通过已有的测试用例测量软件的测试覆盖率，并通过系统化的导出设计用例来提高覆盖率。

基于经验的测试技术特点：
测试用例根据参与人员的经验和知识来编写。
测试人员、开发人员、用户和其他的利益相关者对软件、软件使用和环境等方面所掌握的知识作为信息来源之一。
对可能存在的缺陷及其分布情况的了解作为另一个信息来源。

黑盒测试是基于规格说明的测试技术。
基于经验的测试技术指的是探索性测试和错误推测法。

15.关于语句覆盖：
100%的判定覆盖可以保证100%的语句覆盖，反之则不行。
逻辑覆盖由弱到强的排列是：语句覆盖，判定覆盖，条件覆盖，判定条件覆盖，条件组合覆盖，路径覆盖。

16.测试员测试经理职责:
测试经理（测试组长）的职责：主要负责测试计划、监视与控制、协调等。
测试员的职责：主要负责测试分析、设计与执行等。

17.测试方法的选择：
典型的测试方法：
分析的方法，比如基于风险的测试，直接针对风险最高的部分进行测试；
基于模型的方法，比如随机测试利用失效率（如：可靠性增长模型）或使用率（如：运行概况）的统计信息；

系统的方法，比如基于失效的方法（包括错误推测和故障攻击），基于检查表的方法和基于质量特征的方法；

基于过程或符合标准的方法，比如在行业标准中规定的方法或各类敏捷的方法；
动态和启发式的方法，类似于探索性测试，测试很大程度上依赖于事件而非提前计划，而且执行和评估几乎是同时进行的；

咨询式的方法，比如测试覆盖率主要是根据测试小组以外的业务领域和技术领域专家的建议和指导来推动的；

可重用的方法，比如重用已有的测试材料，广泛的功能回归测试的自动化，标准测试套件等。

18.关于项目风险和产品风险：
项目风险的因素：组织方面、技术方面、供应商方面。

产品风险的因素和表现：
易错的软件交付使用。
软件、硬件对个人或公司造成伤害的可能性。
劣质的软件特征（比如功能性、可靠性、可用性和性能等）。
低劣的数据完整性和质量（例如：数据迁移问题、数据转换问题、数据传输问题、违反数据标准问题）。
软件没有实现既定的功能。

19.入口、出口准则：
测试入口准则：
测试环境已经准备就绪并可用
测试环境中的测试工具已经准备就绪
可测的对象可用
测试数据可用

测试出口准则：
完整性测量，比如代码、功能或风险的覆盖率。
对缺陷密度或可靠性度量的估计。
成本。
遗留风险，比如没有被修改的缺陷或在某些区域缺少测试覆盖等。
进度表，如基于交付到市场的时间。

20.测试管理工具：
测试管理工具的功能：
管理软件需求
管理测试计划
管理测试用例
缺陷跟踪与管理
测试过程中各类数据的统计和汇总
测试管理工具不负责对测试人员进行绩效管理

21.测试执行工具：
1）测试执行工具使用自动化的测试脚本执行测试对象。
2）通过记录测试员手动操作的捕捉过程往往开始看起来似乎很吸引人，但是这种方法不适合大量的自动化测试。捕获的脚本知识用特定数据和动作来线性表示每个脚本的一部分。当发生意外时间时，这类脚本是不稳定的。　
3）数据驱动的方法是将测试输入（数据）与测试用例分离，并将测试输入存放在一个电子表格中，这样可以使用不同的数据进行相同的测试。
4）关键字驱动的测试方法中，电子表格含有描述系统要采取的行为的关键字（也称为行为字）和测试数据。测试员（即使不熟悉脚本语言）也能针对被测应用，使用这些关键字来定义测试。

22.商业区娱乐区：
商业区：指南、卖点、地标、极限、快递、深夜、遍历。
娱乐区：配角、深巷、通宵。

23.几种测试方法总结：
1）快递测试法：执行操作后，后台数据有相应的变化，操作过程中的所有数据变化都能正常显示。
2）上一版测试法：思考新版本的更新内容，是否对老版本的功能有影响（Side Effect）。
3）深夜测试法：当我们不对测试对象操作时，测试对象能否会自动完成各种维护任务，将数据归档，自动记录发生的异常情况等。如：周排行榜，每日任务的Reset（重置）功能。
4）通宵测试法：程序一直保持运行，而不去关闭它。如：长时间挂机，长时间后台放置。

---

关于评审选择题会出现的知识点总结：

1.评审的说明
1）评审是静态测试技术
2）软件开发的所有作业成果物是都可以评审的
3）比动态测试更简单地找到需求规定说明、功能或处理的遗漏
4）评审比动态测试技术不容易发现的错误是内存泄漏，容易发现的是否遵守代码规则、需求规则的遗漏以及设计遗漏。

2．不同评审类型的说明
1）评审没有固定过程（非正式评审）
2）根据相关材料按方案实行（走查）
3）目的是：学习和理解软件设计，传播知识，了解情况，查找错误（走查）
4）对错误指出，可以技术专家参加，评审的过程是按规范的步骤，并且文档化。（技术评审）
5）以过程本身改进为目的，引入了度量，并且有宣读员（审查）
6）目的是：讨论，作决策，评估候选方案，指出错误，解决技术问题，验证技术问题，验证软件符合它的需求规格 （技术评审）
7）比如二人一组，对软件程序，由技术的负责人来评审设计或代码（非正式审查）
8）有正式的跟踪过过程 （审查）

3.正式评审的阶段定义
1）对于人选，分配任务，决定评审文档的哪些部分，正式程度高的评审，比如审查要定义。
——-计划阶段

2）讨论评审对象的文档，记录讨论的结果，正式的评审中要在议事录中保留开会讨论事项的结果或议事的内容，评审的参加者指出缺陷，表达对缺陷的处理方法的意见，关于缺陷要作出决定
——-评审会阶段

3）要确认是否处理了缺陷，收集指标，正式程度高的评审要确认结束条件
——-跟踪阶段

4）配布文档，对参加者说明目的，过程，文档的说明了，正式程度高的评审要确认开始条件
——-预备会阶段

补充：
确认是否处理了缺陷
收集指标
确认结束条件 ——-问题跟踪

4.评审中的不同角色定义
1）决定实施评审，建立实行的计划表，判断评审的目的是否恰当
——-经理

2）对某种技术很了解，拥有很好的业务背景，也叫检查员或审查员，对评审对象，要指出有注意到的地方。比如说缺陷
——-评审员

3）调解文档的评审，评审的目的，计划，评审的展开，还包含跟踪，有必要的情况，还要从不同的视点来考虑事物，评审成功与不成功多取决于这个人。
——-主持人

4）记录在评审时受理的所有课题，问题点，没有解决的事项
——-记录员

5.静态测试技术与评审说明
早期检出缺陷并修正可以缩短开发期间。
所有的静态测试都是停靠人力来实施地。
静态测试适用于代码的规则违反或找出软件的设计上的缺陷。

6. 关于静态测试和动态测试的关系
静态测试在动态测试实施前实施，期待大的效果

7.关于静态分析工具
1）初期能指出代码缺陷，预期得到的回报率
2）能计策复杂度，表示维护性的困难度
3）能指出变量的初期値的错误，结构上的欠缺

8.关于主持人职责
进行不同观点之间的协调

9.不参加技术评审的是 经理

10.关于评审的特征的是：
审查：由主持人或评审负责人支持；使用入口和出口准则
通行评审：没有参与管理
非正式评审：不需要文件证明
走查：有作者负责主持

                       待续......