【笔记】软件测试基础

课程目标（总体框架见文末）

了解软件测试的含义

软件测试遵循的准则

软件测试有哪些分类？分别是什么概念

何时开始测试？测试方案如何设计？

测试流程是怎样的？怎么提bug？怎么写报告？

为什么要做自动化？怎么做？

 

 

1-1软件测试概要

 

什么是软件测试？

IEEE定义：使用人工或自动的手段来运行或测量软件系统的过程，以检验软件系统是否满足规定的要求，并找出与预期结果之间的差异。

软件测试的测试对象

软件需求、软件概要设计、软件详细设计、软件运行环境、可运行程序、软件源代码（涵盖软件开发整个过程）

五大要素和两个目标

软件测试所遵循的原则

1、测试显示缺陷的存在，但不能证明系统不存在缺陷

2、穷尽测试是不可能的，应设定及时终止的条件

3、测试应该尽早进行

4、缺陷具备群集特性（发现问题多的模块可能存在更多的问题）

5、测试的杀虫剂悖论（测试用例和测试方法应该定期修改/增加，从而能发现更多缺陷）

6、测试的二八原则（80%的时间和资源用在20%的重点模块上，来达到高测试效率和最佳的资源配置比例）

7、测试活动依赖于测试背景

 

 

2-1软件测试阶段

 

软件测试的分类

按测试阶段来分：单元测试集成测试 系统测试 验收测试

 

单元测试

1、定义

对软件中的最小可测试单元进行检查和验证。（如C中的函数，Java中的类，有界面的功能软件中的菜单项或者说功能项）

2、单元测试的原则

1）尽可能保证各个测试用例是相互独立的。（即不要在测试用例中调用外部依赖的函数或类，因为这样无法判断是调用的依赖有问题还是函数本身有问题）

2）一般由代码的开发人员来实施，用以检验所开发的代码功能符合自己的设计要求。

3、单元测试的益处

1）能尽早发现缺陷（例如TDD是测试驱动开发（Test-DrivenDevelopment）的英文简称，是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。）

2）有利于重构

3）简化集成（保证最小单元模块的稳定性和正确性，为集成测试奠定基础。）

4）文档（减少代码对应的文档的修改）

5）用于设计（设计本身可以用来验证设计）

4、单元测试的限制

1）不可能覆盖所有的执行路径，所以不可能保证捕捉到所有路径的错误。

2）每一行代码，一般需要3-5行测试代码才能完成单元测试，所以存在投入和产出的一个平衡。

5、单元测试框架

Xunit：Junit（针对java）、Nunit（针对.NET）、PHP Unit（针对PHP）、CPPUnit（针对c++）。

例如：

在Eclipse中使用JUnit4进行单元测试（初级篇）

http://blog.csdn.net/andycpp/article/details/1327147/

集成测试

1、定义

是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。

2、集成测试的主要实施方案

1）Big Bang（所有东西组装好，然后一起做测试）

2）自顶向下（递增组装软件，从控制层逐层向下）

3）自底向上（传统最常用，从下向上组装，容易锁定故障所在位置）

4）核心系统集成（先对核心部分测试，再逐步扩展到外围）

5）高频集成（每隔一段时间开发团队就进行一次集成测试）（4、5是敏捷开发中常用的）

集成测试&单元测试

1、测试的对象不同

集成测试：模块与子系统，模块之间接口关系

单元测试：最小单元

2、测试的依据不同

集成测试：概要设计

单元测试：详细设计

3、测试的方法不同

系统测试

1、定义

是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效的测试，以发现软件潜在的问题，保证系统的正常运行。（企业的岗位一般是针对系统测试，如功能测试、性能测试、稳定性测试）

2、关注点

关注系统本身的使用

关注系统与其他相关系统间的连通

关注系统在不同使用压力下的表现

关注系统在真实使用环境下的表现

系统测试&集成测试

1、测试对象

系统测试：除了软件之外，还包括计算机硬件及相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统

集成测试：由通过了单元测试的各个模块所集成起来的构件

2、测试时间

集成测试介于单元测试和系统测试之间

系统测试在集成测试之后

3、测试内容

集成测试：各个单元模块之间的接口

系统测试：整个系统的功能和性能

4、测试角度

集成测试：偏于技术角度的验证

系统测试：偏于业务角度的验证

验收测试

1、定义

也称交付测试。针对用户需求、业务流程的正式的测试，确定系统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统。（强调用户角度）

2、细分

1）

用户验收测试（开发方自己验收）

运行验收测试（运维角度，如系统备份、容灾、灾难恢复）

合同和规范验收测试（参照合同规范，针对政府法律法规验证）

2）

Alpha测试（开发者提供的场所和环境中，由用户执行）

Beta测试（完全脱离开发者，在用户提供的场所和环境中测试）

3、应用

在敏捷开发中，有验收测试驱动开发ATDD，是TDD的延伸。也有叫BDD行为驱动开发的。ATDD与BDD概念类似。

 

 

2-2 软件测试手段

 

软件测试的分类

按测试手段来分类

测试时对象的可见度：黑盒测试、白盒测试

状态：静态测试、动态测试

测试执行方式：手工测试、自动化测试

黑盒测试

1、定义

黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。黑盒测试是事件驱动的，是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。（在系统测试阶段用的最多）

2、优点

1）容易实施，不需要关注内部的实现

2）更贴近用户的使用角度

3、缺点

1）测试覆盖率较低，一般只能覆盖到代码量的不到40%

2）针对黑盒的自动化测试，复用率较低，维护成本较高

4、主要测试什么？

1）是否有不正确或遗漏的功能？

2）在接口上，输入是否能正确的接受？能否输出正确的结果？

3）是否有数据结构错误或外部信息（例如数据文件）访问错误？

4）性能上是否能够满足要求？

5、主要设计方法

1）等价类划分法：把程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。

2）边界值分析法：是通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。它是对等价类划分方法的补充。

3）错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

4）因果图法：分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。根据这些关系，画出因果图。再根据规格的语义说明，把因果图转换为判定表。最后根据判定表编写测试用例。

5）正交试验分析法：通过正交性从一组数据中筛选出典型的代表性数据的设计方法。主要用于筛选输入数据，然后设计测试用例。

6）状态迁移图法：通过梳理软件功能点里的状态迁移关系来设计测试用例。

7）流程分析法：通过梳理程序的逻辑执行路径来设计测试用例。

白盒测试

1、定义

测试人员全面了解程序内部逻辑结构、对所有逻辑路径进行测试。又称为结构测试、透明盒测试。针对逻辑结构来设计测试用例。用逻辑的覆盖率衡量测试的完整性。

2、主要的逻辑单位

语句、条件、条件组合、分支、路径。

不同的逻辑单位有不同的覆盖方法。逻辑覆盖包括语句覆盖（保证程序的每条语句至少执行一次）、条件覆盖（所有条件的表达式至少计算一次）、条件组合覆盖（覆盖所有各种条件的组合情况）、判定/分支覆盖（保证每个分支至少执行一次）、判定和条件组合覆盖和路径覆盖（每条可能的路径至少执行一次，分支是路径的一部分）。

3、优点

1）迫使测试人员去仔细思考软件的实现，理解原理

2）可以检测代码中的每条分支和路径

3）揭示隐藏在代码中的错误

4）对代码的测试比较彻底

4、缺点

1）昂贵

2）无法检测代码中遗漏的路径（代码中少写的）和数据敏感性错误（数据处理有问题）

3）不能直接验证需求的正确性

5、主要测试方法

1）代码检测法：主要包括多面检查、代码审查、走查。主要检查代码和设计的一致性。对代码本身进行检查。

2）静态结构分析法：测试者通过使用测试工具，分析源代码的系统结构、数据结构、内部的控制逻辑，通过内部结构的分析设计测试用例。

3）静态质量度量法：根据标准的质量模型（如ISO），构造质量的度量模型，用于评估软件各方面要素。

4）逻辑覆盖法：见2

5）基本路径测试法（主要）：在程序控制流图的基础上，通过分析控制构造的圈复杂度，导出基本可执行路径的集合，进而设计测试用例。

灰盒测试

介于黑、白盒测试之间的，关注输出对于输入的正确性，同时也关注内部表现。更多是在系统组件这层评价应用软件的设计符合需求的情况。

静态测试

1、定义

静态测试是指无须执行被测程序，而是通过评审软件文档或代码，度量程序静态复杂度，检查软件是否符合编程标准，借以发现编写的程序的不足之处，减少错误出现的概率。

2、方式

互审（两个程序员，不正式）、走查（小组）、会议（正式）

动态测试

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

手工测试

由专门的测试人员从用户视角来验证软件是否满足设计要求的行为。更适用针对深度的测试和强调主观判断的测试。

如众包测试、探索式测试

自动化测试

使用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动检查。

如单元测试、接口测试、性能测试等。

手工测试vs自动化测试

手工测试：

优点：易发现缺陷；容易实施；创造性、灵活性

缺点：覆盖量化难；重复测试效率低；不一致性、可靠性低；人力资源依赖

自动化测试：

优点：高效率、速度快；高复用性；覆盖率容易度量；准确、可靠；不知疲劳

缺点：机械、发现缺陷率低；一次性投入较大

 

 

2-3 软件测试模式

软件测试的分类

按测试模式来分类

瀑布模型、敏捷测试、基于脚本的测试、基于风险的测试、探索式测试等

 

传统的瀑布模型

1、优点

1）强调需求、设计的作用

2）前一阶段完成后，只需关注后续阶段

3）为项目提供了按阶段划分的检查点，里程碑清晰

4）文档规范

2、缺点

1）难以适应需求的频繁变化

2）项目周期后段才能看到成果

3）强制的里程碑、完成时间点

4）文档工作量大

 

V模型

V模型明确界定测试过程存在不同阶段，明确测试不同阶段和研发不同阶段的对应关系。

V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。

 

W模型

测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等开发输出的文档同样要测试。也就是说，测试与开发是同步进行的，是对V模型的改进。

但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。

 

X模型

X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。由图中可见，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。

 

H模型

H模型揭示了一个原理：软件测试是一个独立的流程，以独立完整“微循环”流程，参与产品生命周期的各个阶段，与其他流程并发地进行。H模型指出软件测试要尽早准备，尽早执行，只要某个测试达到准备就绪点，测试执行活动就可以开展，并且不同的测试活动可按照某个次序先后进行，但也可以是反复进行的。

 

敏捷测试

1、定义

又叫Agile Testing，指的是遵循敏捷宣言的一种测试实践。

敏捷宣言：

个体与交互重于 过程和工具

可用的软件重于 完备的文档

客户协作重于 合同谈判

响应变化重于 遵循计划

（在每对比较中，后者并非全无价值，但我们更看重前者）

2、特点

1）强调从客户角度进行测试

2）重点关注迭代测试新功能，不再强调测试阶段

3）尽早测试，不间断测试，具备条件即测试（与H模型一样）

4）强调持续反馈

5）预防缺陷重于发现缺陷

3、敏捷测试VS传统测试

传统测试：

测试是质量的最后保护者；严格的变更管理；预先的计划和细节的准备；重量级文档；

各阶段测试严格的入口和出口标准；更多在回归测试时进行重量级的自动化测试；严格依赖流程执行；测试团队和开发团队是相对独立的。

敏捷测试：

开发和测试人员是紧密合作，大家都有责任对软件负责；变更是可接受的，拥抱变更；计划随着进展时常调整；只需要绝对必要的文档；

各迭代之间已经没有明显的入口和出口标准；所有阶段都需要自动化测试，每个人都需要做，是项目集成的一部分；流程不再需要严格执行；团队合作是无缝隙合作。

 

基于脚本的测试—SBT（Script-basedTesting）或ST（Script Testing）

先做测试设计，再做测试。首先设计出Script，在手工测试指的是测试用例，而在自动化测试当中就是所说的脚本。遵照测试计划属于传统测试。

 

探索式测试—ET（Exploratory Testing）

完全抛开测试脚本的测试，通过探索被测系统，带着问题使用被测系统。测试设计和测试执行两者并行。

是一种测试风格、思维而不是一种测试技术。

 

1、ET和ST的使用

 

2、ST VS ET

ST：系统性强；容易管理、控制；设计在先，执行在后；主要是验证自己的思路；可预见性

ET：自由灵活；和ST互补；执行和设计（思考）并行；不断和系统交互，带着问题测试；学习的过程

 

3、探索式测试的优点

更能激发测试人员的创造性和工作乐趣

增加了发现新的或较深入BUG的可能性

在较短时间内找到更多BUG以及对SUT（被测系统）作一个快速的评估

有利于更加有效地实施自动化

更加适用于敏捷项目

减少了在简单、繁复用例上的无谓编写时间

 

4、探索式测试的缺点

测试管理上有局限性，较难协调和控制

对于BUG的重复利用和重现上作用有限

对测试人员的测试技能和业务知识深度依赖较大

只有在SUT已完全可用的前提下才更有作用

ET的生产率很难定义

ET本身较难进行自动化

 

5、局部探索式测试

从被测系统的五大要素入手：

（1）输入

任务：接受输入、产生输出、存储路径、进行运算；

测试角度：输入顺序、输出内容、输出异常。

（2）状态

临时状态：运行时有效、阶段有效

永久状态：数据库保存、文件保存

（3）代码路径

对代码的覆盖

（4）用户数据

采用真实的用户数据，或构造合理的数据

（5）执行环境

操作系统、系统组网的网络拓扑、和系统交互的第三方系统、系统的配置数据、运行系统的硬件设备

 

6、全局探索式测试

漫游测试法：测试人员像游客游览一样，把被测系统按照不同属性分成不同区域，进行针对性测试。

（1）商业区：软件从启动到关闭之间，用户主要可能使用的软件特性和功能。（指南测试法、麻烦测试法）

（2）旅馆区：软件在休息或没有在实际运行时的功能，一般指运行在后台的一些进程或定时任务。（懒汉测试法）

（3）历史区：版本的历史遗留代码中的一些功能，或在以前的测试中发现较多问题的功能。（恶邻测试法）

（4）旅游区：新用户会使用或比较关注的一些功能，如新手指引，新用户注册等。

（5）娱乐区：主要功能之外的辅助特性和功能。（深巷测试法）

（6）破旧区：系统废弃或隐藏的、用户看不到的一些功能，一般在用户手册中提及。（破坏测试法）

 

7、执行探索式测试

（1）了解测试任务的重点，有总体思路

（2）详细地学习、探索被测系统

（3）主要的实施阶段，完成主要功能点的测试验收，完成测试点的覆盖

（4）在（3）的基础上进一步的深入的发散式的探索式测试，挖掘深层次的问题

（5）总结，整理测试信息，分析测试过程的覆盖率

（6）针对性地进行缺陷大扫除（可能会有这个阶段，有时会包含在（4）中）

 

 

基于风险的测试—RBT（Risk-based Testing）

一种基于对软件失效的风险评估并以此指导测试计划、设计、执行、结果评价的软件测试类型。

1、哪些是风险？

质量风险：被测系统的质量问题，如软件的功能、性能、应用性等。

管理风险：人员技能不足、项目人力不足、测试环境不具备、需求不清晰、被测系统关联的第三方系统有问题等

风险级别=风险可能性×风险严重度

 

2、识别风险

可能性：复杂性、时间压力、高变更率、技能水平、地理分散度

严重程度：使用频率、失效可视性、商业损失、组织负面影响和损害、社会损失和法律责任

风险要素分=Sum（单项权重*得分）

 

3、RBT的优点

 

 

基于模型的测试-MBT

测试用例是从一个模型中完整或部分导出得到的，而该模型描述了被测系统的某些（通常是功能）方面。 此处的“模型”指对需求功能点建模。

https://blogs.msdn.microsoft.com/sechina/2009/11/18/123/

 

1、主要的MBT工具

Spec Explorer（Microsoft）

GraphWalker（OpenSource）

http://graphwalker.github.io/

Tcases（OpenSource）

https://github.com/Cornutum/tcases

modeljunit（OpenSource）

http://www.cs.waikato.ac.nz/~marku/mbt/modeljunit/

 

 

 

3-1 软件测试类型

 

软件测试的分类

按测试类型来分类

 

功能测试

1、定义

根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。

针对的问题：功能错误或遗漏、界面问题、性能错误（软件本身）、数据及访问错误、初始化及终止错误

 

2、功能测试工具：

商用：QTP、winrunner、silkTest、Rational robot

开源：selenium、Watir、Sikuli

 

性能测试

1、进一步衍生出——

负载测试：测试过程中逐步增加负载，记录被测系统的性能表现，最终确定系统在正常指标下最大的负载。

压力测试：测试系统在什么样的压力情况下会导致系统失效。确定系统能承受的最大极限。

稳定性测试：以稍大于正常业务量的负载对系统进行持续的长时间的测试，如24h*5。

 

2、性能指标

 

3、性能测试工具

4、静态性能评估

开发Web应用时，基于一系列Web应用页面性能优化的最佳实践对Web应用的页面进行静态分析，并给出评估结果的性能分析方法。

评估标准/工具：YSlow和PageSpeed（均为浏览器插件）

 

5、应用性能管理（APM）

提供对系统的实时监控以实现性能管理、故障管理的解决方案。

http://www.tingyun.com/

 

 

安全测试

对软件产品进行测试以确保其符合产品安全需求和质量标准。

【补充】渗透测试（即取得用户授权的攻击）

通过模拟对软件系统的恶意攻击行为来评估系统安全性的一种测试。

 

1、渗透测试VS安全测试

攻——防

点——面

 

2、OWASP（Open WebApplication Security Project）

https://www.owasp.org/index.php/Main_Page

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project十大安全漏洞

https://www.owasp.org/index.php/Category:OWASP_Testing_Project测试指南

 

3、安全测试工具

 

兼容性测试

1、内容

软件本身的兼容性（新版本对旧功能的兼容）

不同平台下的兼容性（如Linux下有各种不同版本）

软件对运行设备的兼容性（32位/64位，PC、Pad、手机、电视盒子等）

软件互操作性（不同软件之间的兼容性）

 

2、浏览器内核的兼容性

内核

 

浏览器

 

3、浏览器兼容性测试工具

http://browsershots.org/

 

 

文档测试

针对软件产品的交付品，配套的文档类部件的测试。如用户手册、使用说明、用户帮助文档等。

1、关注要点

完整性、正确性、一致性、易理解性、易浏览性。

 

可靠性测试

1、软件可靠性：软件系统在规定时间内，规定环境下能完成规定功能的能力。

2、硬件可靠性（更多）：硬件产品在设计应用过程中受气候环境、机械环境的影响，能否正常工作。

 

易用性测试

易用性测试是指测试用户使用软件时是否感觉方便，是否能保证用户使用体验的测试类型。比如是否最多点击鼠标三次就可以达到用户的目的。

易用性和可用性存在一定的区别，可用性是指是否可以使用，而易用性是指是否方便使用。

 

本地化测试

针对软件的本地化版本实施的针对性测试。（如中文版、英文版）

主要测试内容：语言、书写习惯；时区、日期格式、货币；当地风俗、法律法规；政治敏感内容。

 

部署测试

也称安装测试，主要验证系统部署过程，并确保软件经过安装测试后可以正常使用。

主要测试内容：在不同环境下的部署验证；参照部署文档执行，过程的合理、正确性；基础数据。

 

无障碍测试

Accessibility Test.也称可访问性测试。是指软件需要提供便于特殊人群使用的功能，包括视障、听障、老年人、身体残疾用户等，无障碍测试则是针对这部分功能的测试。

 

 

4-1 其他测试分类

软件测试的分类

其他的一些测试类型概念

回归测试

软件功能修改后，对软件进行重新测试以确认修改没有引入新的错误或导致其他部分代码产生错误。

回归测试的重心在关键模块和重点功能组件。

软件研发周期中会进行多次回归测试，且尽量实现自动化。

 

Monkey测试

也称搞怪测试，就是用一些随机、稀奇古怪的方式来操作软件，以测试系统的健壮性和稳定性。

 

冒烟测试

这一术语源自硬件行业。软件上则用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。重点在全流程的测试。

“每日构建”中用冒烟测试来确认合入的代码没有影响主要功能的正常。

 

A/B测试

多用于互联网行业，通过为页面提供2个版本给用户使用并记录相关的用户行为数据，来确定更优化设计的一种测试方案。

1、A/B测试实施要点

多个方案并行；

每次测试仅改动一个变量；

按照某种规则进行优胜劣汰。

 

2、A/B测试工具

Google Analytics Content Experiments，Visual WebsiteOptimizer

 

回顾总结