测试基础理论学习

1、软件测试的目的：
发现软件中存在的错误，提高软件质量，降低软件项目的风险。
（把软件的错误控制在一个可以进行产品交付/发布的程度上，可以交付/发布产品并不是没有错误的产品）

2、软件测试只能证明软件存在错误，而不能证明软件没有错误。

3、软件测试不可能无休止的进行下去。随着测试时间的延伸，发现错误的成本会越来越大，这就需要测试有度，而这个度并不能由项目计划实际判断，而是要根据测试发现错误的概率来判断。

4、软件测试是指对软件形成过程中的文档、数据及程序进行的测试，而不仅仅是对程序进行的测试。

5、软件测试与质量保证的区别

     质量保证（QA）：质量保证的重要工作通过预防、检查与改进来保证软件质量，QA采用“全面质量管理”和“过程改进”的原来来开展质量保证工作，所关注的是软件质量的检查与测量。QA的工作是软件生命周期的管理及验证软件是否满足规定的质量和用户需求，因此主要着眼于软件开发活动中的过程、步骤和产物，而不是对软件进行剖析找出问题或评估。

     软件测试：软件测试虽然也与开发过程紧密相关，但关心的不是过程的活动，而是对过程的产物以及开发出来的软件进行剖析。

6、软件测试的作用

（1）对软件质量进行度量和评估，以验证软件的质量满足用户的需求的程度，为用户选择和接受软件提供有力的依据；

（2）通过分析错误产生的原因帮助发现当前开发工作所采用的软件过程的缺陷；

（3）通过测试结果的分析整理，还可以修正软件开发规则，并未软件可靠性分析提供依据；

7、软件测试的原则

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

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

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

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

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

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

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

8、软件测试的对象

软件中的程序、数据和文档。软件测试贯穿字整个软件生命周期中，各阶段有不同的测试对象，形成了不同阶段的不同类型的测试。

（1）需求分析、概要设计、详细设计以及程序编码等各个阶段所得的文档，包括需求规格说明书、概要设计规格说明、详细设计规格说明以及源程序；

（2）在软件编码结束之后，对编写的每个程序模块进行测试，称为“模块测试”或“单元测试”；

（3）在模块集成后，对集成在一起的模块组件，有时也可称为“部件”，进行测试，称为“集成测试”；

（4）在集成测试之后，需要检测与证实软件满足软件需求规格说明书中规定的要求，这就成为“确认测试”；

（5）将整个程序模块即成为软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为“系统测试”。

9、验证与确认

验证是保证软件正确实现特定功能的一系列活动和过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标；确认是保证软件满足用户需求的一系列的活动与过程，目的是在软件开发完成后保证软件与用户需求相符合。

验证与确认均属于软件测试，包括对软件分析、设计及程序的验证和确认。

10、软件测试的分类

按照全生命周期的软件测试概念，测试对象应该包括软件设计开发的各个阶段的内容，此处重点讲述开发阶段的测试和程序测试。

（1）按照开发阶段划分：

按照开发阶段划分软件测试可分为：单元测试、集成测试、系统测试、确认测试和验收测试。

1）单元测试：单元测试又称为模块测试，是针对软件设计的最小单位—程序模块进行正确性检验的测试工作。其目的在于坚持每个程序单元能否正确的实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

2）集成测试：集成测试也叫做组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步即成为符合概要设计要求的程序部件或整个系统。

软件集成的过程是一个持续的过程，会形成很多个临时版本，在不断地集成过程中，功能集成的稳定性是真正的挑战。在每个版本提交时，都需要进行冒烟测试，即对程序主要功能进行验证。冒烟测试（BVT (Build Verification Test)）也叫做版本验证测试、提交测试。

3）确认测试：确认测试时通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。确认测试是检测与证实软件是否满足软件需求说明书中规定的要求。

4）系统测试：系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统的测试。系统测试时在真实或者模拟系统运行的环境下，检查完整的程序能否与系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并满足用户需求。

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

（2）按照测试实施组织划分

按照测试实施组织划分，软件测试可分为开发方测试、用户测试（β测试）、第三方测试。

1）开发方测试：通常也叫“验证测试”或“α测试”。开发方通过检测和提供客观证据，证实软件的实现是否满足规定的需求。验证测试是在软件开发环境下，由开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。主要是指在软件开发完成以后，开发方对要提交的软件进行全面的自我检查与验证，可以与软件的“系统测试”一并进行。

2）用户测试：在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符合自己预期的要求。通常情况下，用户测试不是指用户的“验收测试”，而是指用户的使用性测试，由用户找出软件应用过程中发现的软件的缺陷与问题，并对使用质量进行评价。

β测试通常被看成是一种“用户测试”。β测试主要是把软件产品有计划地免费分发到目标市场，让用户大量使用，并评价、检查软件。通过用户各种方式的大量使用，来发现软件中存在的问题与错误，把信息反馈给开发者修改。β测试中厂商获得的信息，可以有助于软件产品的成功发布。

3）第三方测试：介于软件开发方和用户方之间的测试组织的测试，第三方测试也成为独立测试。独立的验证和确认活动。在模拟用户真实应用环境下，进行软件确认测试。

（3）按照测试技术分

第一种划分：静态测试、动态测试；

1)静态测试：指不允许程序，通过人工对程序和文档进行分析与检查。又称为静态分析技术，实际上是对软件中的需求说明书、设计说明书、程序源代码等进行非运行检察，包括：走查、符号执行、需求确认。

2)动态测试：是指通过人工或者使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。

第二种划分：白盒测试、黑盒测试、灰盒测试；

1)白盒测试：通过对程序内部结构的分析、检测来寻找问题。白盒测试是在清楚了解程序结构和处理过程的基础上，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明书的规定正常进行。又称为结构测试。

2)黑盒测试：通过软件的外部表现来发现其缺陷和错误，完全不考虑程序内部结构和处理过程，在程序界面处进行测试，只是检查程序是否按照需求规格说明书的规定正常实现。

3)灰盒测试：介于白盒测试与黑盒测试之间的测试，关注输出对于输入的正确性；同时也关注内部表现，但是这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、时间、标志来判断内部的运行状态。

11，用例设计方法
白盒测试：逻辑覆盖、循环覆盖、基本路径覆盖
黑盒测试：边界值分析法、等价类划分、错误猜测法、因果图法、状态图法、测试大纲法、随机测试场景法
1）逻辑覆盖：
逻辑覆盖法包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖
逻辑覆盖法设计测试用例步骤：
1.1）画流程图
语句覆盖：将所有可执行的路径执行一遍
判定覆盖：根据判定覆盖的定义，应该使两个判断语句中的Ture和False都出现一次
条件覆盖测试用例：应使得每个条件的真假至少满足一次
（条件覆盖一般比判定覆盖强，但并不是实现了条件覆盖就一定能实现判定覆盖）
判定/条件覆盖：
1.所有条件可能取值至少执行一次；
2.所有判定可能结果至少执行一次；
（判定/条件覆盖可同时满足判定覆盖准则和条件覆盖准则）
条件组合覆盖：
（1）列出各个判定内的条件完全组合
(2)分析条件之间的制约关系
（条件组合覆盖测试用例比较复杂。满足条件组合覆盖的测试用例一定满足判定覆盖、条件覆盖和判定/条件覆盖。）