《软件评测师教程笔记之第2章软件测试基础25页》由会员分享，可在线阅读，更多相关《软件评测师教程笔记之第2章软件测试基础25页（25页珍藏版）》请在金锄头文库上搜索。
1、第2章软件测试基础1、什么是软件测试测试（test）被当作一个常规的检验产品质量的生产活动。测试的含义为“为检验产品是否满足需求为目标”。“软件测试”的经典定义是在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。软件是由文档、数据以及程序组成的，那么软件测试就应该是对软件形成过程的文档、数据以及程序进行的测试，而不仅仅是对程序进行的测试。2、什么是软件质量ISO9126中定义的“软件质量”是：软件满足规定或潜在用户需求特性的总和。ISO14598中“软件质量”定义是：软件特性的总和，软件满足规定或潜在用户需求的能力。ISO9126定义的软件质量包括“内部质量”、“外部质量”、“使用质
2、量”三部分。也就是说，“软件满足规定或潜在用户需求的能力”要从软件在内部、外部和使用中的表现来衡量。3、软件测试是在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。4、软件质量定义是：软件特性的总和，软件满足规定或潜在用户需求的能力。软件质量包括：内部质量、外部质量、使用质量三个部分。5、软件测试与质量保证的区别：质量保证（QA）质量保证的重要工作通过预防、检查与改进来保证软件质量。QA采用“全面质量管理”和“过程改进”的原理开展质量保证工作。关注软件质量的检查与测量。软件测试也与软件开发过程紧密相关，关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。测试员要“执行”软
3、件，对过程中的产物开发文档和源代码进行走查，运行软件，以找出问题，报告质量。对测试中发现的问题的分析、追踪和回归测试。软件测试是保证软件质量的一个重要环节。6、软件测试目的测试目的三个观点：测试是程序的执行过程，目的在于发现错误；一个好的测试用例在于能发现至今未发现的错误；一个成功的测试是发现了至今未发现的错误的测试；测试的目的，是想以最少的人力、物力和时间找出软件潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造居的隐患所带来的商业风险。测试是对软件质量的度量与评价，以验证软件的质量满足用户的需求的程度，为用户选择与接受软件提供有力的依据。7、
4、软件测试原则所有的软件测试都应追溯到用户需求。应当把“尽早地和不断地进行软件测试”作为软件测试者的座左铭。完全测试是不可能的，测试需要终止。 在有限的时间和资源条件下，软件趋于完美，是不可能的。主要有三个原因： 软件入量太大； 输出结果太多； 路径组合太多。测试无法显示软件潜在的缺陷充分注意测试中的群集现象。程序员应避免检查自己的程序。尽量避免测试的随意性。（应该从工程的角度去理解软件测试，它是有组织、有计划、步骤的活动。）8、软件测试对象根据软件定义，软件包括程序、数据和文档，所以软件测试并不仅仅是程序测试。在软件编码结束后，对编写的每一个程序模块进行测试，称为模块测试或单元测试。在模块集成
5、后，对集成在一起模块组件，有时称为部件，进行测试，称为集成测试。在集成测试后，需要检测与证实软件是否满足软件需求说明书中规定的要求，称为确认测试。将整个程序模块集成为软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为系统测试。软件错误中，属于需求分析和软件设计的错误约为64%，属于程序编写的错误仅占36%。验证（verification）是保证软件正确实现特定功能的一系列活动和过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。确认（validation）是保证软件满足用户需求的一系列的活动和过程，目的是在软件开发完成后保证软件与用
6、户需求相符合。验证与确认都属于软件测试，它包括对软件分析、设计以及程序的验证和确认。需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为“软件测试”的对象。在软件编码结束后，对编写的每一个程序模块进行测试，称为“模块测试”或“单元测试”；在模块集成后，对集成在一起的模块组件，有时也可称为“部件”，进行测试，称为“集成测试”；在集成测试后，需要检测与证实软件是否满足软件需求说明书中规定的要求，称为“确认测试”。将整个程序模块集成为软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称
7、为“系统测试”。测试过程按4个步骤进行，即单元测试、集成（组装）测试、确认测试和系统测试。9、软件测试分类按照开发阶段划分软件测试可分为：单元测试、集成测试、系统测试、确认测试和验收测试。单元测试：单元测试又称模块测试，是针对软件设计的最小单位程序模块进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。集成测试：也叫组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部
8、件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。确认测试：就是通过检验和提供客观证据，证实软件是否满足特定预期用途的要求。确认测试是检测与证实软件是否满足软件需求说明书中规定的要求。系统测试：它是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并满足用户需求。验收测试：按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。l 按照开发阶段划分 单元测试。单元测试又称模块测试，是针对程序模
9、块进行正确性检验的测试工作。 集成测试集成测试也叫组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。冒烟测试也叫验证测试、提交测试。 确认测试确认测试是通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。确认测试是检测与证实软件是否满足软件需求说明书中规定的要求。 系统测试系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接
10、、并满足用户需求。 验收测试按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。l 按照测试实施组织划分按照测试实施组织划分，软件测试可分为开发方测试、用户测试（Beta测试）、第三方测试。（1）开发方测试通常也叫“验证测试”或“测试”。验证测试是在软件开发环境下，由开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。主要是指在软件开发完成以后，开发方对要提交的软件进行全面的自我检查与验证，可以和软件的“系统测试”一并进行。（2）用户测试在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符合自己预期的要求。用户测
11、试不是指用户的“验收测试”，而是指用户的使用性测试，由用户找出软件的应用过程中发现的软件的缺陷与问题，并对使用质量进行评价。（3）第三方测试介于软件开发方和用户方之间的测试组织的测试。一般情况下是在模拟用户真实应用环境下，进行软件确认测试。l 按照测试技术划分按照测试技术划分：白盒测试、黑盒测试、灰盒测试。也可划分为静态测试和动态测试。静态测试是指不运行程序，通过人工对程序和文档进行分析与检查：静态测试技术又称静态分析技术，静态测试实际上是对软件中的需求说明书、设计说明书、程序源代码等进行非运行的检查，静态测试包括：走查、符号执行、需求确认等。动态测试是指通过人工或使用工具运行程序进行检查、分
12、析程序的执行状态和程序的外部表现。 （1）白盒测试通过对程序内部结构的分析、检测来寻找问题。了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。（2）黑盒测试通过软件的外部表现来发现其缺陷和错误。黑盒测试法把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现。（3）灰盒测试灰盒测试关注输出对于输入的正确性 静态测试它是指不运行程序，通过人工对程序和文档进行分析与检查； 静态测试技术又称静态分析技术，静态测试实际上是对软件中的需求说明书、设计说明书、程
13、序源代码等进行非运行检查，静态测试包括：走查、符号执行、需求确认等。 动态测试它是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。 白盒测试又称结构测试。通过对程序内部结构的分析、检测来寻找问题。 黑盒测试通过软件的外部表现来发现其缺陷和错误。它是在程序界面处进行测试，它只是检查样序是否按照需求规格说明书的规定正常实现。10、软件测试过程模型 V模型它反映了测试活动与分析和设计的关系，从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系，如图所示，图中的箭头代表了时间方向，左边下
14、降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。V模型指出，单元和集成测试是验证的程序设计，检测程序的执行是否满足软件设计的要求；系统测试应当验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标； 测试员和用户进行软件的确认测试和验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满足用户需求或合同的要求。V模型存在一定的局限性，它仅仅是测试过程作为在需求分析、概要设计、详细设计及编码后的一个阶段。需求分析阶段隐藏的问题一直到后期的验收测试才被发现。V模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了源代码的正确性，高层测试为了使整个
15、系统满足用户的需求。 W模型1、W模型建立V模型的局限性在于没有明确地说明早期的测试，不能体现“尽早地和不断地进行软件测试”的原则。在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型，因为实际上开发是“V”，测试也是与此相并行的“V”。基于“尽早地和不断地进行软件测试”的原则，优点：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。体现“尽早地和不断地进行软件测试”的原则。在V模型中增加软件和开发阶段应同步进行的测试。局限性：软件开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可正式开始下一个阶段。这就无法支持迭代、自发性以及变更调整。2、W模型应用它强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。只要相应的开发活动完成，我们就可以开始执行测试，可以说，测试与开发是同步进行的，有利于尽早地发现问题。以需求为例，需求分析一完成，我们就可以对需求进行测试，而不是等到最后才进行针对需求的验收测试。参与前期工作的测试者可以预先估计问题和难度，这将可以显著地减少总体测试时间，加快项目进度。根据W模型的要求，一旦有文档提供，就要及时确定测试条件，以及编写测试用例。
