测试笔记总结

                    软件测试笔记

                                  作者：小全子

首先，在此要感谢小全子辛苦整理的笔记，作为刚走入社会的他来说，这样的社会不适合还没完全适应的他，但他是个好孩子，学习刻苦，努力，并没有比同龄人差，甚至我觉得他的选择是对的，比同龄人领先了一步，而这一步他走的很扎实；其次，作为我的好哥们，我很佩服他的努力奋斗精神，我自认没有他那么仔细认真，甚至我有点过于自信。下面是他整理的软测理论笔记，将持续更新。

 

软件测试概述

1: 软件测试（test）（广泛的讲）：

测试必须包含的两个过程包含两个结果①预想结果，②实际结果。

预想结果就是：测试之前先猜想结果会是什么样的；

实际结果就是：测试之后得到的结果；

如果前者和后者一致就完成了测试这一过程。

2：概述（了解即可）

1）软件测试起源于上世纪70年代中期，在1975年软件测试才被确定为一种研究方向；在1979年Glen Ford Myers的《软件测试的艺术》（The Art of Software Testing）给软件测试定义为：“测试是为了发现错误而执行的一个程序或者系统的过程。”

2)软件测试在国内的发展历程：

2000~2005刚开始出现测试，从2005~2008年软件测试逐步兴起，走向了正式的轨道。

3：概念与目的

1）软件测试就是：使用人工或自动手段来运行或测试某一系统的过程，其目的在于发现错误，检验是否满足用户需求或弄清预期结果与实际结果的差别。（或，以检验产品是否满足需求为目标）

2）关于软件测试有不同的定义，有一下几点：

①软件测试正向思维

它的核心思想：测试的方法是试图验证软件是工作的，即软件的功能是按照预先设计的执行的，以正向思维，针对系统的所有功能，逐个验证其正确性。

软件测试正向思维的出发点：使自己确信产品是能够正常工作的评价一个程序和系统的特性或能力，并确信它是否达到期望的结果，软件测试就是以此为目的的任何行为。

其实说白了：正向思维思维就是对这个软件抱着没有错的情况下去测试这个软件，然而就测不出任何错误。

②软件测试反向思维

软件测试反向思维就是认为软件有错的情况下去测试这个软件。

关于软件测试反向思维的三个重要观点：

a : 测试是为了证明程序有错，而不是证明程序无错的。

b : 一个好的测试用例在于它能发现以前未发现的错误。

c : 一个成功的测试是发现了以前未发现错误的测试。

③ IEEE定义的测试

IEEE/ANSI将测试定义为一下两点：

a : 在规定条件下运行系统或构件的过程。观察和记录结果，并对系统或构件的某些方面给出评价。

b : 分析软件项目的过程，检测现有状况和所需状况之间的不同，并评估软件项目的特性。

④广义软件测试定义

广义的测试，引入两个概念来覆盖测试的范畴：验证（Verification）,确认（Validation）

验证（Verification）：通过检查和提供客观证据来证实指定的需求是否满足。

确认（Validation）:通过检查和提供客观证据来证实特定目的的功能或应用是否已经实现。

比较V and V的特点：

验证：就是验证需求是否满足；

确认：就是确认功能是否实现。

 

测试的目的：

以最少的人力，物力和时间找出软件中潜在的各种错误和缺陷，用过修正各种错误和缺陷提高软件质量，避免软件发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险。同时利用测试过程中得到的测试结果和测试信息，作为后续项目开发和测试过程改进的重要输入，避免在将来的项目开发和测试中重复同样的错误；采用更高效的测试管理手段，提高软件测试的效率和软件产品的质量。

 

4：测试和调试的区别

 

	测试（test）	调试（debug）
目标	发现缺陷	差错
对象	软件（程序+文档）	代码
方法	多种多样，动静结合	编译
周期	贯穿整个软件生命周期	只在代码编写阶段
人员	测试和开发人员	开发人员

开发阶段的软件测试过程：单元测试（unit  testing），集成测试(integration  testing)，确认测试(validation  testing)，系统测试(system  testing)，验收测试(acceptance  testing)。

 

5：软件的典型错误（课本 7~11）

 

6：软件测试从业人员的职业要求

软件测试人员应具备对的素质

①    他们善于说服

②    他们不放过蛛丝马迹

③    他们具有创造性

④    他们是问题的发现者

⑤    他们是完美追求者

⑥    他们是有很好的洞察力

⑦    他们是幽默的

⑧    他们是善于学习的

 

 

软件开发生命周期

1 开发生命周期（life cycle）

软件：立项，设计，编码测试，发布，淘汰。

 

获取测试需求

↓

 

编写测试计划

↓

 

制定测试方案

↓

 

开发与设计测试用例

↓

 

执行测试

↓

 

提交缺陷报告

↓

 

测试分析与评审

↓

 

提交测试总结

↓

 

准备下一个版本的测试

 

2 软件开发模型（model）

1) 瀑布模型

步骤：需求分析，设计，编程，测试，维护

特点：严格规定各阶段的任务，上一阶段任务输出作为下一阶段工作输入。

缺点：测试出现时间太晚，导致没有充足的时间来测试，产品的质量没有了保障。

修改：从需求分析之后就开始介入测试，其后的步骤都有测试介入，直到整个项目完成。这样既缩短了整个项目的时间，也保障了产品的质量。

2）快速原型模型

①原型是指模拟某种产品的原始模型，在其他产业中经常使用。软件开发中的原型是软件的一个早期可运行的版本，它反映了最终系统的重要特性。

②快速原型模型的类型

a : 探索型原型

这种类型的原型是把原型用于开发的需求分析阶段，目的是为了弄清用户的需求，确定所期望的特性，并探索各种方案的可行性。它主要针对开发目标模糊，用户与开发都项目缺乏经验的情况，通过对原型的开发来明确用户的需求。

b : 实验型原型

这种模型主要用于设计阶段，考核；实现方案是否合适，能否实现。对于一个大型系统，若对设计方案心中没有把握时，可通过阵中原型来证实设计方案的正确性。

c : 演化型原型

这种原型主要用于及早向用户提交一个原型系统，该原型系统或者包含系统的框架，或者包含系统的主要功能，在得到用户的认可后，将原型系统不断扩充演变为最终的软件系统。它将原型的思想扩展到软件开发的全过程。

③ 快速原型模型的运用方式

a : 抛弃策略

将原型用于开发过程的某一阶段，促使该阶段的开发结果更加完整，准确，一致，可靠，该阶段结束后，原型随之作废。探索型和实验型就是采用此策略的。

b : 附加策略

将原型用于开发的全过程，原型由最基本的核心开始，逐步增加新的功能和新的需求，反复修改反复扩充，最后发展为用户满意的最终系统，演化型快速原型就是采用此策略。

④快速原型模型的开发步骤

快速分析，构造原型，运行原型，评价原型，修改

 

3）增量模型和迭代模型

①增量模型就是把一软件分成若干个小模块，然后完成每个小模块的功能，再有开发人员将其组装成一个完整的软件

②迭代模型

。步骤：需求分析（可逆）设计（可逆）编程（可逆）测试，维护

 

4) 螺旋模型

①螺旋模型是沿着螺线进行若干次迭代；

a : 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件。

b : 风险分析：分析评估所选方案，考虑如何识别和消除风险。

c : 实施工程：实施软件开发和验证。

d : 客户评估：评价开发工作，提出修改建议，制定下一步计划。

②螺旋模型的限制条件：

a : 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并作出相关反应是不容易的，因此，这种模型往往适应内部的大规模软件开发。

b : 如果执行风险分析将大大影响项目的利润那么进行风险分析毫无意义，因此，螺旋形只适合大规模软件项目。

c : 软件开发人员应该擅长寻找可能的风险，准确的分析风险，否则将会带来更大的风险。

 

软件开发过程

 

1）  软件开发流程：

 

软件立项

 

↓

 

可行性研究

 

↓

 

需求分析

 

↓

 

概要设计

 

↓

详细设计

 

↓

编码实现

 

↓

 

单元测试

 

↓

 

集成测试

 

↓

 

系统测试

（包含确认测试）

↓

 

验收测试

 

↓

 

运行维护

 

 

注：软件立项到验收测试阶段已经开始测试和测试评审。

1）  缺陷

①    软件缺陷构成示意图：

15%代码，6%其它，25%需求规格说明书，54%设计

需求规格说明书：a:分析不到位，不准确b:没有形成相应的文档c:需求没有评审和测试。

软件需求规格说明在开发，测试，质量保证，项目管理以及相关项目功能中都起了重要作用。对一个复杂产品来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于软件部件。

②软件缺陷中的8020原则（即二八原则）：

在软件测试过程中，从需求分析开始到集成测试阶段引入测试手段，能发现所有缺陷的80%；系统测试阶段引入测试手段，能发现剩余缺陷的80%；在运行维护阶段经长时间，大量运行软件后，能够发现剩余的20%。

例：假如：一个软件有100个缺陷，从需求分析开始到集成测试阶段引入测试手段，能发现所有缺陷的80%，即80个缺陷；系统测试阶段引入测试手段，能发现剩余缺陷的80%；即（1—80%）80%，16个缺陷；在运行维护阶段经长时间，大量运行软件后，能够发现剩余的（1—80%）20%，4个缺陷。

从价格上体现缺陷发现的阶段与修复之间的成本关系可以得出：（课本24页）

因此：在软件开发开始阶段，软件测试就要引入，越早引入软件测试，越能早发现缺陷，就可以早修复，这样就可以节省成本，有利于提高软件产品质量。

2）  软件需求：

软件需求阶段是整个开发过程中最重要的阶段，也是衡量一个软件产品质量好坏的关键。

①    软件需求定义：

需求分类：

A : 需求开发：细化需求

B : 需求管理：对需求审核

需求开发可进一步分为四个阶段：

a : 需求获取阶段

b : 需求分析阶段

c : 编写需求规格阶段

d : 需求验证阶段

需求管理可分为七个阶段：

a : 定义需求

b : 需求确认

c : 建立需求状态

d : 需求评审

e : 需求承诺

f : 需求跟踪

g :需求变更控制

 

②    软件需求过程的标准：

清楚（clear）,完整（complete）,一致（consistent）,可测试（testable）

③    软件需求包括三个不同的层次：

a : 业务需求（business  requirement）反映了组织机构或客户对系统，产品高层次的目标要求，他们在项目视图与范围文档中予以说明。

b : 用户需求（user  requirement）文档描述了用户使用产品必须要完成的任务，这在使用实例（user case）文档或方案脚本（scenario）说明中予以说明。

c : 功能需求（functional  requirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。

 

其他的看课本。

 

3）  软件设计

①    概要设计：把需求分析得到的文档转换为软件结构和数据结构。

a : 设计软件结构的具体任务是：将一个复杂系统按功能模块划分，建立模块的层次结构及调用关系，确定模块间的接口及人机界面。

b : 数据结构设计包括数据特征的描述，确定数据的结构特性，以及数据库的设计，显然总体设计建立的目标系统的逻辑模型与计算机无关。

②模块独立性：

耦合：模块间的连接程度

内聚：一个模块内部各各元素之间的紧密程度（一个模块值做一件事）

总之一个良好的软件结构设计：低耦合高内聚，如实在无法平衡，尽可能保持高内聚。

我的理解：

例：耦合，就好比一家酒店里在一条走廊里有两排都是单个的房间，高耦合就是每排房间只用一扇门，这样使用起来非常麻烦。低耦合就是每间都有自己的门，这样使用起来就灵活了，不互相打扰。

 

4）  详要设计

目标：实现模块功能的算法，要逻辑上正确和算法描述要简明易懂。

主要任务：设计每个模块的实现算法所需的局部数据结构。

 

 

总结：

1）  概要设计实现软件总体设计，模块划分，用户界面设计，数据库设计等等。

2）  详要设计则根据概要设计所做的模块划分，实现各模块的算法设计实现用户界面设计数据结构设计的细化等。

需求阶段 _{（需求规格说明书）}   系统测试；

概要阶段（概要设计文档）   集成测试；

详要设计  （详细设计文档）   单元测试。

 

5）  CMM（了解）

①    CMM：能力成熟度模型

②    SW---CMM:软件能力成熟度模型

③    CMM的概貌：

 

优化及（5）

（引用其他行业或组织的成熟经验）

↑（不断改进的过程）

 

已管理级（4）

（高层管理里介入）

↑（可预测的过程）

 

已定义级（3）

（文档成熟）

↑（标准一致的过程）

 

可重复级（2）

（文档化（最重要），制度化，标准化）

↑（有纪律的过程）

 

初始级（1）

 

 

软件测试分类（重点）

1）  按照开发阶段分

可分为：单元测试，集成测试，确认测试，系统测试，验收测试。

a : 单元测试：单元测试又称模块测试，是针对软件的最小单位——程序模块进行正确性检验的正式工作。

b : 集成测试：也叫组装测试，通常在单元测试的基础上，将所有的程序模块进行有序的递增测试。

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

d : 系统测试：在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统（包括硬件，外设，网络和系统软件，支持平台）正确配置，连接，并满足用户需求。（除功能外）

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

{ 模拟验收测试：（阿尔法）α测试：有公司内部人员来模拟用户来实施验收测试。β测试：有真实用户参与的验收测试。}

 

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

a : (阿尔法)α测试：有公司内部人员来模拟用户来实施验收测试

b :β测试：有真实用户参与的验收测试

c ：第三方测试：介于软件开发方和用户之间的测试组织的测试，第三方也称为独立测试。（比如公司甲让公司乙研发一款聊天工具，快研发完成的时候，公司甲怕公司乙自己测会出现质量问题。就委托公司丙调出一个测试团队来到乙公司一同对这款聊天工具进行确认测试）

 

3）  按照测试技术划分

白盒测试，黑盒测试，灰盒测试。

①    白盒测试：逻辑驱动测试（程序内部的逻辑结构）

必须要了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。白盒测试又称结构测试。

②    黑盒测试：功能驱动测试（软件外在功能的实现，输入和输出的对应关系）黑盒测试不需要考虑内部的逻辑结构，只在界面外进行测试，它只检查样序是否按照需求规格说明书的规定正常实现。

③    灰盒测试：介于白盒和黑盒之间的测试。既有逻辑驱动测试也有功能驱动测试。

例：有一个计算的程序，需求规格说明书上写的当你输入2时，输出的结果为4；其中y=2x；

当你输入2时，结果为6；则说明这程序有错误，把错误提交上去就OK了，若输出的是4则说明程序正确，这就是黑盒测试。白盒测试就是要知道运算过程，要看代码是不写的y=2x,若是写的代码为y=x^2,若代码是y=x^2就说明程序是错的。灰盒测试测试既要运行当输入2时输出是不是为4，要看其代码是不是y=2x来证明程序的对错。

 

软件测试方法和技术的分类与软件开发过程相关联，它贯穿了整个软件的生命周期，走查，单元测试，集成测试，系统测试（包含了确认测试），用于整个开发过程的不同阶段开发文档和源程序可以应用单元测试应用走查的方法；单元测试可应用白盒测试方法，集成测试应用近似灰盒的测试方法，而系统测试和确认测试应用黑盒测试方法。

 

单元测试：→白盒测试（动静结合）；

集成测试：→白为主，黑为辅；

确认，系统，验收测试：→黑盒测试（动静结合）。

 

4）  按代码运行划分

①    静态测试：指不实际运行被测软件，而只是静态的检查代码，界面或文档中可能存在的错误。

对于代码测试：主要测试代码是否符合相应的标准和规范。

对于界面测试：主要测试软件的实际界面与需求中的说明是否相符。

对于文档测试：主要测试用户手册和需求说明是否真正符合用户的实际需求。

②    动态测试：指实际运行被测程序，输入相应的测试数据，检查实际输出的结果和预期结果是否相符的过程，所以我们判断一个测试属于动态测试还是静态测试，唯一的标准就是看是否运行程序，

 

5）  按软件特性分类

①    功能测试：是黑盒测试的一方面，它检查实际软件的功能是否符合用户需求，一般分为逻辑功能测试，界面测试，易用性测试，安装测试，兼容性测试。

②    性能测试：（必须的功能测试完成后）软件的性能包含很多方面，主要有时间性能和空间性能两种。

性能测试一般分为：

a : 一般性能测试：指让被测系统在正常的软硬件环境下运行，不向其施加任何压力的性能测试。

b : 稳妥定性测试：也叫可靠性测试，只连续运行被测系统，检查系统运行的稳定程度。

c :负载测试：通常是指让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性，压力测试：通常是指持续不断地给被测系统增加压力，直到将被测系统压垮为止，用来测试系统能承受的最大压力。

负载测试：（load testing）能够承受的最大负荷点。

压力测试：（stress testing）让被测试的物体承受一定压力（要接近最大负荷点），测试其无差错长时间运行的时间段（之内）

流程：

 

 

获取测试需求

 

↓

 

制定测试计划

 

↓

 

测试计划，开发

 

↓

 

执行测试

 

↓

 

测试评审

 

↓

 

测试总结

 

↓

 

进入下一个版本测试

 

过程可以从某一个开始，流程一个都不能拉。

 

6）  其他分类

a : 随机测试：（random testing）也有人称为猴子测试，是指测试中所有的输入数据都是随机产生的其目的是模拟用户的真实操作，并发现一些边缘性的错误。

随机测试还有一种测试叫法就是 ADHOC testing 这种测试方法是根据直觉和经验来判断的。

b : 冒烟测试（版本验证测试）；（必须做，标志测试的开始）只是测试该版本主要功能是否已完成，及是否具有可测性。

测试步骤：→拿到软件的中间版本→进行冒烟测试→执行测试用例→大范围随意性测试→该版本测试总结。

c : 回归测试：在当前版本去重复执行之前某一版本所有的测试用例。

目的：①验证之前某个版本所有缺陷全部被修复

②确认修复这些缺陷没有发现新的缺陷。

若在冒烟测试之后的测试过程中发现了缺陷并给开发人员修复，但是由于开发人员的疏忽又造成了新的缺陷，从而要用到回归测试。它从冒烟测试步骤的执行测试用例→大范围随意性测试之间插入。然后进行测试。

 

7）  看课本；

 

8）软件测试的原则

①所有测试的标准都是建立在用户需求之上（测试基于需求）；

③    软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间要服从质量（原则）；

④    事先定义好产品质量的标准，只有有了质量标准，才能根据测试的结果对产品的质量进行分析和评估（CMM）；

⑤    软件项目已启动，软件测试也就是开始，而不是等程序写完。才开始进行测试（软件测试应该尽早执行）；

⑥    穷举测试是不可能的（把所有模块都测一遍），甚至一个大小适度的程序，其路径排列的数量也非常大，因此，在测试中不可能运行路径的每一种组合。

⑦    第三方进行测试会更客观，更有效；

⑧    软件测试计划是做好软件测试的前提（重点）；

⑨    测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多滴发现错误，提高程序的可靠性；

⑩    对发现错误较多的程序段，应进行更深入的测试，一般来说，一段程序中已发现的错误越多，其中存在的错误概率就越大；

①    重视文档，妥善保存一切测试文档（测试计划，测试用例，测试报告等）

②    应当把“尽早和不断地测试”作为测试人员的座右铭；

③    回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见；

④    测试应从“小规模”开始，逐步转向“大规模”；

⑤    不可将测试用例置之度外，排除随意性；

⑥    必须彻底检查每一个测试结果；

⑦    一定要注意测试中的错误集中发现现象，这和程序员的编程水平和习惯有很大的关系；

⑧    对测试错误结果一定要有一个确认的过程。

 

                      

                                 测试计划

计划测试软件工作

1）  测试计划（test  plan）(文档)

制定测试目标从以下几方面入手；

A : 理解系统

B : 及早介入

C : 理解企业文化和过程

D : 测试期望

E : 吸取教训

F : 工作量大小

G : 解决方案的类型

H: 技术选着（是否引入自动化）

I : 预算

J : 时间表

K : 分阶段的解决方案。

什么是测试计划？

规定测试活动的范围，办法，资源和进度；明确正在测试的项目，要测试的特性，要执行的测试任务，每任务的负责人，以及与计划相关的风险。

2）  测试项目简介：

①    产品规格

产品名称制造商和产品版本号的说明；

②    产品信息

产品的用户，开发该产品的背景

③    技术结构

介绍产品的主要功能，可以借助图表的格式

3）  测试参考文档

测试计划中引用的文档或书籍

4）  测试提交文档

①    测试用例

A : 提供测试用例模板

B : 确定测试用例的编号规则

编号最好用这样的：产品名称（包括版本号）___模块名称___测试类型__用例编号

例：测试腾讯的登陆页面

Tencent QQ 2012__login__GUI__0001

（登陆）（页面）

②    测试日志

提供测试日志模块

③    缺陷报告

A : 提供缺陷报告模版（包括包含哪些内容）

B : 缺陷跟踪系统还是电子文档

C : 确定严重程度和优先级别怎么划分

严重程度：当缺陷发生时对于被测对象正常运行的影响程度。

优先级别：修复缺陷的响应时间。

④    测试总结

提供缺陷总结模板。

 

软件测试计划的模板（p106）

测试策略是重点