测试基础

1.测试相关基础

• IT（Information Technology），即信息科技和产业的意思。
称呼：
IT男/IT女 IT 民工码农搬砖
• 软件：一系列按照特定顺序组织的计算机数据和指令的集合
程序+数据+文件
• 产品：能够供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，
包括有形的物品、无形的服务、组织、观念或它们的组合。
• 项目：指一系列独特的、复杂的并相互关联的活动，这些活动有着一个明确的目
标或目的，必须在特定的时间、预算、资源限定内，依据规范完成。

2.什么是软件测试？

定义：使用人工和自动（通过工具来模拟人）手段来运行或测试某个系统的过程，目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。

功能测试：功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。

性能测试：

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

3.为什么做软件测试？

一个糟糕的测试程序可能导致任务失败，影响操作的性能和可靠性，导致维护阶段的成本提高

一个好的测试程序可以降低项目的主要成本

一个好的测试可以迫使你在工作时必须面对和处理问题，使得修改缺陷成本降低

一个好的测试不能弥补一个糟糕的软件项目，但是的确有助于发现许多问题，并且至少使得你尽早知道你处在问题当中。

4.软件测试任职要求

1.硬实力：学历，专业，经验，测试技术，开发技能，业务知识

2.软实力：责任心，沟通能力，团队合作精神，耐心，细心，信心，风险防范意识，持续学习能力

对自己发现的bug，要有信心,不能被开发所牵制.

5.软件生命周期及各阶段相关工作

需求调研阶段request for proposal→需求分析阶段requirement analysis→设计阶段design→代码编写阶段coding→测试阶段testing→发布上线deploy→运行维护阶段→production support→下线

（需求调研，需求分析，设计，编写代码，测试，上线，运维，下线）

产品经理从各渠道收集需求，整理需求，建立文档

项目经理建立项目负责管理，协调整个项目组每个人员的工作，制作整体开发计划

开发团队任务分解，设计编码

测试人员测试执行，分解测试需求，完成测试用例；测试通过版本，交给配置人员

配置团队：形成发布版本

软件测试的对象和原则

编写测试用例的原则：“百分之百覆盖需求”

6.测试的基本原则

7.软件测试的对象：程序+数据+文档

8.软件开发模型

1>瀑布模型 每一个环节的工作依赖于上一步工作的完成的基础上；对每一个文档的要求质量高；一旦发现问题，维护成本很高。

2>原型模型 多一个输出物，原型设计；每一环节没有“瀑布模型”文档要求质量那么高，文档没有详尽描述，会增加后期维护成本。特点：重点关注原型图的设计。

3>敏捷模型（agile development），是一种以人为核心，迭代，循序渐进的开发方法。（目前主流的开发方法）

先发布一个原始版本，再制定版本迭代计划，不断迭代版本。例如微信的不断更新的各种版本。

研发模型 ---其他模型
其它研发模型：
• 螺旋模型：适合于大型复杂软件系统
• RUP模型（Rational Unified Process）：模型过于复
杂，难于掌握，耦合度高不适合

9.软件测试模型

10.软件测试阶段

需求测试，返工：70%~85%由于需求

重点：检查需求规格说明书 SRS

1）完整性；2）正确性；3）一致性；4）可行性

5）无二义性；6）健壮性；7）必要性；8）可测试性；9）可修改性 checklist，<检查依据，判断标准>

单元测试：

单元：函数，类

单元测试是针对软件基本组成单元（软件设计的最小单位）来进行

集成测试：

是对单元之间及单元与第三方接口之间的测试，目的是验证接口是否与设计相符，是否与需求相符。（即检测软件模块对《概要设计说明书》的符合程度）

集成策略：自底向上（上面的模块需要调用下面的模块，所以需要先测最底层模块，再逐渐向上与上一级模块进行集成测试，一步一步往上测；同时需要开发一个驱动模块使上一级可以调用下一级模块。），自顶向下（先测最顶层模块，之后一步一步调用下一步模块；需要开发“桩”来调用下一层模块）渐增式。

自顶向下的集成是从主控模块（主程序，即根结点）开始，按照系统程序结构，沿着控制层次从上而下，逐渐将各模块组装起来。在从上向下的集成测试过程中，需对那些未经集成的模块开发桩模块。在集成过程中，可以采用宽度优先或深度优先的策略向下推进。

自底向上的集成是从最底层模块（即叶子结点）开始，按照调用图的结构，从下而上，逐层将各模块组装起来。在从下而上的集成测试环境中，需对那些未经集成测试的模块开发驱动模块。

系统测试：系统是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的测试工作

系统测试的目的在于通过与《需求规格说明书》做比较，发现软件与系统需求定义不符合

确认测试：又称为有效性测试，它的任务是验证软件的有效性，即验证软件的功能

验收测试：交付给用户部署前，进行验收测试；以用户为主，验收组：项目组成员，用户代表或者系统的其他利益相关者。根据合同。《需求规格说明书》或《验收测试计划》对成品进行验收测试。

Alpha测试：尽量模拟真实环境测试（内部，模拟、真实）；Beta测试：外部，真实。

UAT测试：（User Acceptance Test）用户接受度测试，验证系统的可用性

回归测试（Regression Testing）：软件在测试或其他活动中发现的缺陷经过修改后进行的测试。目的是验证缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能。

回归测试可以发生在任何一个阶段，包括单元测试，集成测试，系统测试。（穿插在测试过程的各个阶段）

10软件测试阶段

回归测试可以发生在任何一个阶段，包括单元测试，集成测试，系统测试。（穿插在测试过程的各个阶段）

回归测试策略：1>完全重复测试，重新执行所有在前期的测试阶段建立的测试用例，来确认问题修改的正确性和修改过的扩散局部影响

2>选择性重复测试，即有选择的重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序。

3>选择性重复测试，覆盖修改法，针对被修改的部分，选取或重新构造测试用例验证没有错误再次发生的用例选择方法。周边影响法：该方法不但要包含覆盖修改法确定的用例，还需要分析修改的扩散影响，对那些收到修改间影响的部分选择测试用例验证它没有收到不良影响，该方法比覆盖修改法更充分一点。

指标达成法：这是一种类似于单元测试的方法，在重新执行测试前，先确定一个要达成的指标，如修改部分代码百分之百覆盖

以下流程适合于单元测试、集成测试和系统测试
• 1、在测试策略制定阶段，制定回归测试策略
• 2、确定需要回归测试的版本
• 3、回归测试版本发布,按照回归测试策略执行回归测试
• 4、回归测试通过，关闭缺陷跟踪单（问题单）
• 5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，
再次提交测试人员回归测试

回归测试自动化

（1）回归测试是一个重用以前成果的测试，很难预料到要经过多少次回归系统才能达
到满意的水平，结果，这种回归测试将可能演变成一种重复的、令人心烦意乱的工作，
效果与人员的积极性将大打折扣，因此，在回归测试道路上的自动化便是我们工作的
追求
（2）回归测试的自动化法包括测试程序的自动运行、自动配置，测试用例的管理和自
动输入，测试的自动执行，测试信息与结果的自动采集，测试结果的自动比较和结论
的自动输出，尤其前面提到的各类数据的共享决策
（3）对系统测试功能比较简单、测试界面相对稳定并且测试用例良好组织的测试来说，
采用“捕捉回放”工具是比较合适的，这类工具有Selenium等

冒烟测试：该种测试耗时短，仅用一袋烟功夫足够了。

对象是每一个薪编译的需要正式测试的软件版本，目的是确认软件爱你基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。

单元，集成，系统，验收，回归，α测试（内侧），β测试（公测）

-----------------

11.软件测试类型

功能测试：功能测试是根据产品的需求规格说明书和测试需求列表，验证产品的功能实现是否符合产品的需求规格

目标：是否有不正确或遗漏了的功能？功能实现是否满足用户需求和系统设计的隐藏需求？输入能否正确接收？能否正确输出结果
性能测试：就是用来测试软件在集成系统中的运行性能的。

目标：度量系统相对于预定义目标的差距

性能测试必须要有工具支持，GUI,Web性能测试工具：Loadrunner，Jmeter(接口功能，自动化，性能测试），SilkPerformer，WebLoad

性能测试收集的信息
• CPU使用情况
• IO使用情况
• 内存使用情况
• 信道使用情况
• 每个模块执行时间百分比
• 一个模块等待IO完工的百分比
• 指令随时间的跟踪路径
• 每一组指令页换入和换出的次数
• 系统反应时间
• 系统吞吐量，即每个时间单元的处理数量
• 所有主要指令的单元执行时间

负载测试：超过被测对象标准的性能负荷指标下，验证系统的负载承受力。并要求超负荷情况下，依然正常实现业务功能。是通过不断对被测对象施加符合，观察被测对象在不同负载下的性能表现。

软件测试质量：是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。人们通过改善软件的各种质量属性，从而提高软件的整体质量。一个人跑100米需要多少时间；一个人拎50斤东西跑100米需要多少时间。

压力测试：调查系统在其资源超负荷的情况下的表现。尤其感兴趣的是这些对系统的处理时间有什么影响。这类测试在一种需要反常数量，频率或资源的方式下执行系统。目标通过极限测试方法，发现系统在极限或恶劣环境中

例子：成千上万的客户同一时间登陆到Internet；同时引入大量操作。

容量测试：目的是使系统承受超额的数据容量来发现它是否能够正确处理。例子：使用编译器编译一个极其庞大的源程序；一个操作系统的任务队列被充满。

能力：功能性；非功能性

安全性测试：用来验证集成在系统内的保护机制是否能够在实际中保护系统不受到非法的入侵。

GUI测试：针对软件系统界面进行的测试。包括：界面实现与界面设计的吻合情况；确认界面处理的正确性。GUI自动化工具：QTP, SilkTest, QARun、

QuickTestProfessional,selenium等。

文档测试:文档测试(Documentation Testing)的目标是验证用户文档是正确的
并且保证操作手册的过程能够正确工作。

稳定性测试:系统稳定性测试目的是评价系统在一定负荷情况下、长时间的运行情况。包括系统在一定负荷下，再增加新的业务，原有的业务是否受影响，新的业务是否能正常工作，系统资源有无泄漏，数据有无不一致的情况，系统性能是否会降下来，关键点是长时间的运行后，系统的状况如何，系统平均无故障时间MTBF是否满足系统设计要求

12.软件测试方法

1.测试活动从不同的角度出发，可以有不同的分类。主要用对
照比较的方式讲解下面一些测试分类：
• 黑盒测试和白盒测试、灰盒测试
• 静态测试和动态测试
• 人工测试和自动化测试
还有其它一些分类方式，要搞清每一种分类的具体含义

软件测试的两种极端情况
任何软件产品都可以使用以下
的两种方法之一进行测试：
• 已知产品的需求规格，但不知道
其内部实现，可以进行测试证明
每个需求是否实现。
• 已知产品的内部实现过程，可以
通过测试证明每种内部操作是否
符合设计规格的要求，所有内部
成分是否已经过检查。
计算器例子
• 参照SRS直接测试计算器的加
法功能。这就是黑盒测试。
• 参照LLD根据加法主函数的伪
码或者流程图测试该主函数的
结构。这就是白盒测试。

SRS：需求分析文档；

HLD：概要设计文档；

LLD：详细设计文档；

BD :基本设计;

DD :详细设计;

FD :结构设计;

白盒测试：1.依据被测软件分析程序内部构造，并根据内部构造设计用例，来对内部控制流程进行测试，可完全不顾程序的整体功能实现情况。

2.白盒测试是基于程序结构的逻辑驱动测试。

3.又被称为玻璃盒测试，透明盒测试，开放测试，结构化测试，逻辑驱动测试。

为什么进行白盒测试：1.一般在测试前期进行，通过达到一定的逻辑覆盖率指标，使得软件内部逻辑控制结构上的问题能基本得到消除。

2.白盒测试能保证内部逻辑结构达到一定的覆盖程度，能够给予软件代码质量更大的保证。

3.白盒测试发现问题后解决问题的成本较低。