测试基础

测试的分阶

入门阶

1、入门阶的测试员不需要掌握过多的计算机基础技术， 只需要像用户一样对系统做各种操作，如果出现不符合预期的结果，则就可以认为是系统存在的bug 。这种测试被称为功能测试

2、 功能测试是通过测试来检测每个功能是否都能正常使用，只关注外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行的测试。主要以手工测试为主

及早介入测试的重要性：

随着项目的进展， 越到后期修复bug的代价越大 ，所以 测试工程师需要尽早启动测试活动 ， 从需求分析阶段进入就是最好的时间点 。在理解需求的基础上，提取测试需求，为编写测试用例做准备

测试活动贯穿整个软件生命周期：

测试并不是软件生命中的一部分，而是 贯穿整个周期 。测试人员需要积极参与需求设计调研及评审等会议， 务求让测试渗透各个方面 ，为后续测试执行做好充足的准备

测试项目流程图：

从上面流程图中可以看出：

1、测试人员在开发阶段进入测试用例的编写工作

2、参加测试用例评审会议、开发提供测试版本

3、进入测试执行阶段：首先对开发版本执行冒烟测试

4、冒烟测试通过后正式进入整体测试阶段：执行系统测试、接口测试、性能测试等

5、测试过程中测试人员提交bug、跟踪bug状态等

6、测试人员完成测试且bug修复率满足测试准出标准时，测试人员进入编写测试报告阶段

7、完成测试报告后提交测试报告

备注：

冒烟测试的定义是将测试用例内最主要、最基础的功能或业务点罗列出来，用作冒烟测试用例 。当开发提供的测试版本通过冒烟测试时，测试人员正式进入整体测试阶段。如果冒烟测试不通过，则将测试版本打回，开发修改后再次提交测试直至冒烟测试通过

测试计划

1、文档说明 ：包含文档目的和读者对象

①文档目的：描述编写本文档的目的

注： 明确测试任务和测试方法，保证测试实施过程的顺畅，跟踪和控制测试进度，应对测试过程中的各种变更。

②对读者对象：主要包括部门经理、项目经理、项目组、测试人员和其他相关人员

2、术语与参考 ：包含参考资料和术语解释

①参考资料：编写该文档时使用的设计文档、开发文档等

②术语解释：解释测试人员使用的专业术语，如集成测试、冒烟测试等

3、测试计划概述：

①测试系统概述：测试系统主要的功能和性能、架构以及项目的简史。集成测试相关的系统分解或组装情况。

②确定测试任务：介绍需要完成的测试任务

③测试目标、方法及策略：说明测试目标、测试方法(手工、自动)、分阶段测试的策略等

④确定时间进度：依照项目总体开发情况，预估发布测试版本时间、发布的周期频度、测试时间、发布稳定版本、正式版本的时间(各阶段的计划开始时间、实际开始时间、最终完成时间)

4、测试范围： 描述系统测试的范围

①从系统的功能模块及测试类型进行阐述，对需要测试的、不需要测试的分别进行描述(交互)

5、分阶段测试： 包含测试阶段定义、准入与准出标准、测试内容

①阶段测试定义如下表所示：

②测试准入与准出标准如下表所示：

③测试内容如下表所示

注： 表中测试物或对象说明为被测系统模块的说明；用例\包为测试用例或测试包的获取路径

6、环境与工具：

所有测试类型的测试环境和测试工具

①测试环境：

根据不同测试类型的测试要求，搭建不同的测试环境，对不同环境做出说明

②测试工具：说明测试工具及其用途、来源、版本

7、测试开发

①测试需求：由需求说明书提取出来的测试需求

②测试用例库：按不同的测试类型分类，列举本项目开发的所有测试用例

③测试包：所有测试包的名称、路径、用途

8、阶段测试详细计划

根据项目情况，计划每个阶段中的每一轮测试计划，包括测试的系统版本、测试物、策略要求、人员、进度、采用的测试包和测试用例

9、风险预估：

阐述项目测试可能遇到的风险

测试需求分析文档

1、测试需求概述：

描述本文档的目的、项目达成的标准等

2、被测对象

简要描述测试项目的背景、重要模块、需要达到的质量目标

3、测试模型需求：

①测试原理\策略：描述所需测试类型的内容以及是否使用辅助工具等

②操作流程需求：描述不同类型测试间的先后顺序，以及测试流程的向后顺序

4、整体测试需求：

①测试环境需求：描述所需测试类型的环境需求，如功能测试环境、性能测试环境需求

②被测对象需求包括应测试的特性和不应被测试的特性：

⑴应测试的特性包括：

功能特性->需测试的模块及其功能

性能特性->测试系统需达到的性能指标

配置特性->使用的操作系统、硬件限制以及数据库版本等

⑵不被测试的特性包括：

本项目不需要被测试的内容，如UI界面测试及稳定性测试等

③测试工具需求：描述本项目需使用的测试工具

④测试代码需求：描述本项目需使用的测试代码

⑤测试数据需求：描述本项目需使用的测试数据，如功能测试中的预置条件、性能测试中的数据准备等

⑥测试用例需求：描述测试用例的框架结构以及使用的设计方法(每个功能点在编写用例时的设计方法)

5、测试需求细化

项目测试细化需求分为：需求汇总分析、流程分析、数据功能点分析和角色及部门分析

1、需求汇总分析表主要是汇总模块的分支流程、主模块与子模块、功能点以及功能逻辑

①测试需求流程分解：包括总流程与子流程信息。将这些数据流分解成最小的子集，对预估测试工作量以及提高对系统的熟悉度都十分有效

②主模块：填写需求分析后的系统模块名称。

③子模块：填写需求分析后主模块下的子模块信息

④功能点：填写该子模块下所包含的功能点。用于编写、优化测试用例

⑤逻辑：填写该功能点的逻辑(程序逻辑等)

bug管理流程

测试用例

界面测试用例主要包括以下几点：

测试类型编号： 是指当前sheet所在测试类型的唯一ID。用例一般会按照测试类型来分，测试类型包括：功能、流程、业务、界面、接口、性能、单元、冒烟测试。

测试类型描述： 是指当前sheet所在测试类型的名称

功能模块名称： 该用例所属功能、模块

测试数据准备： 指测试执行前的准备工作。如：相关文档

其余的还有： 文档作者、创建时间、测试用例版本、最后一次更新时间、更新人、修订记录、用例总览(用例总数、未测试、通过、未通过、阻碍测试、无法测试、完成进度)

测试用例编号： 每一条用例的编号

预置条件： 测试执行前需要满足的条件

测试步骤： 测试执行时使用的步骤

预期结果： 测试执行后正确的输出结果

实际结果： 测试执行后实际的输出结果

用例等级： 用例执行的先后等级(高、中、低)

执行状态： 用例的执行结果(未测试、通过、未通过、阻碍测试、无法测试)

编写用例方法：

等价划分法： 等价类是指某个输入域的子集合

顾名思义，等价类划分，就是将测试的范围划分成几个互不相交的子集，他们的并集是全集，从每个子集选出若干个 有代表性 的值作为测试用例。

例1：

我们要测试一个用户名是否合法，用户名的定义为：8位数字组成的字符。我们可以先划分子集：空用户名，1-7位数字，8位数字，9位或以上数字，非数字。然后从每个子集选出 若干个 有代表性的值：

空用户名：“ ”   ： （无效等价类实例： 不满足程序输入要求或者无效的输入数据构成的集合

）

1-7位数字：“234”  ： （无效等价类实例）

8位数字：“00000000” （有效等价类实例： 对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。

能检验程序是否实现了规格说明中所规定的功能和性能）

9位或以上数字：“1234567890” （无效等价类实例）

非数字：“abc&!!!” （无效等价类实例）

他们5个，就是用等价类划分选出的测试用例。实际上，对于1-7位数字的子集来说，选“234”和“11111”没有本质的区别。 等价类的划分，最关键的是子集的划分 。实际上，非数字还可以继续划分子集：字母，特殊字符。

边界值分析： 应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据

选出的测试用例，应选取正好等于、刚刚大于、刚刚小于边界的值 。如：对于在区间min，max的值，测试用例可以记为min，min+，max，max-。

例2：

假定 X 为整数,10≤X≤100,那么 X 在测试中应该取的边界值为：10，11，99，100。

注：上面只是说边界值，如果是完整的测试，除了边界值外，还需要一个正常值，即12-98之间的任意值。(感觉还可以考虑0或负数)

因果图分析： 考虑输入条件之间的联系,相互组合等

错误推测法： 根据测试经验，列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例

场景分析方法： 指根据用户场景来模拟用户的操作步骤

正交表分析法： 通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性

测试人员在编写用例时需要考虑：

1、编写测试用例的最终目标是：一个对于产品毫无所知的人员，也能够快速的熟悉用例并执行用例 (用例的执行顺序、组织架构，不能重复且要保证覆盖率)

2、用例划分基本原则是以最小功能模块来划分，为保障用例的可执行性、覆盖度

3、用例编写最基本的要求：

1.具有清晰名称、前提条件、操作步骤、期望结果的；

2.可被他人理解的；

3.可被他人执行的；

以最少的用例在合理的时间内发现最多的问题

工程师阶

按项目开发阶段来分：单元测试、集成测试、系统测试、验收测试

单元测试

1、单元测试在实际工作中，一般是由开发人员在开发完成后自行进行的测试

2、单元测试是一种测试，它需要独立设计测试用例及执行bug修复的过程，而不是开发在完成程序的调试工作。调试是调试，测试是测试，这是两个概念。

3、单元测试是指对软件中的基本组成单位进行测试，如一个模块、一个过程等。它是软件动态测试中最基本的部分

(静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。)

4、单元测试的目的是检验软件基本组成单位的正确性。进行充分的单元测试，是提高软件质量，降低开发成本的必由之路

5、单元测试的方法包括：控制流测试、数据流测试、排错测试、分域测试等

备注：

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。

例如， 你可能把一个很大的值放入一个有序list 中去，然后确认该值出现在list 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。

集成测试

1、集成测试是在单元测试之后进行的测试。项目中的集成测试大多数是由开发完成的，开发把这种测试叫做接口联调。

2、独立的集成测试是指在软件系统集成过程中所进行的测试。其主要的目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确

3、 集成测试的策略主要有自顶向下和自底向上两种：

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

②自底向上的集成是从最底层模块(叶子结点)开始。需要对那些未经集成测试的模块开发驱动模块

4、测试人员所做的集成测试又被称为接口测试，接口测试主要分为两种：

系统层面：

①模块与模块间的接口传输是否正确

②系统与系统间的接口传输是否正确

代码层面：

类与方法的调用：在系统未被组建时，对模块的接口调用进行测试

备注：

对于复杂大型的系统架构而言，系统与系统间的接口测试比模块与模块间的接口测试更为重要。模块与模块间的接口问题可以通过功能测试发现，但是系统与系统间的接口问题，则需要独立的集成测试才能被今早发现

系统测试

1、系统测试是指对已经集成好的软件系统进行测试，以验证软件系统的功能的正确性和性能等是否能满足其需求规定的要求

2、 系统测试的方法很多，主要有冒烟测试、功能测试、性能测试、回归测试、兼容性测试等

功能测试：

主要针对软件界面个软件功能进行测试

界面测试：

界面是软件与用户交互最直接的层，界面的好坏决定了用户对软件的第一映像

回归测试：

是指在修改了旧代码之后，重新进行测试以确定修改没有引入新的错误或导致其他代码产生错误。回归测试的难度在于不好确定哪些内容应当被重新测试

冒烟测试

是指对软件的基本功能进行测试，以确定软件的基本功能是正常的

备注：

系统测试分为：测试需求提取、测试框架确定、测试用例编写、测试用例执行、测试报告编写等

验收测试

验收测试是在系统测试结果之后进行的测试。 由客户或最终用户执行 。目的在于向软件购买者展示该软件系统满足其用户的需求。它的 测试数据通常是系统测试的测试数据的子集 ，不同的是验收测试常常有软件购买者在现场

通常验收测试分为两个阶段：

①Alpha测试：由用户在开发环境的场所进行，并且由测试人员对用户进行"指导"，测试人员负责记录发现的错误及问题。总之， Alpha测试是在受控的环境中进行的

②Beta测试：由软件的最终用户们在一个或多个客户现场进行。此次测试中测试人员和开发人员都不在现场(软件在测试开发人员不能控制的环境中进行)。客户反馈问题后，测试开发人员确定是否为缺陷，以确定是否修改。最后交付最后的产品

按测试执行的类型来分： 功能测试、自动化测试、性能测试

功能测试

理论上是指通过测试来 检测系统中每个功能是否都能正常使用 ，主要关注外部结构，不考虑系统内部逻辑结构，主要针对软件界面和软件功能进行的测试

注：

1、个人感觉其实功能测试其实很难的。特别是想要找出深层次的问题，这个对测试人员理解系统的程度要求很高以及个人的经验

2、比如一个功能点，可能有很多实现方法，这就要求测试人员去思考如何用不同的方法实现功能点(操作的多样性)

自动化测试

优点：

1、 能够完成许多手工测试无法实现或难以实现的测试: 压力测试、负载测试、大数据盘测试、兼容性测试等

2、正确、合理地实施自动化测试，能够快速全面地对软件进行测试，从而 提高测试效率，缩短测试工作时间 ：特别是重复性、不会有很大变化的功能的工作

3、 测试具有一致性和可重复性： 可以重复使用已有的测试

自动化更适用于成熟稳定的项目

缺点：

1、 不能完全代替人工测试

2、不能保证100％的测试覆盖率

3、维护成本大

自动化与手工测试的不同点

1、 测试目的不同： 手工测试是通过"破坏"发现系统有bug。自动化测试是"验证"系统有没有bug

2、 覆盖范围不同： 手工测试可以尽可能的覆盖系统的各个角落。自动化测试只能覆盖系统的主要功能

3、 智能判断不同

性能测试

1、性能测试是指通过自动化工具 模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行的测试。常见的性能测试有负载测试和压力测试 ，两者可以结合进行

①负载测试用来确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况

②压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试

③强度测试：在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响

2、 性能测试的基本指标：事务响应时间、TPS( 事务数/秒)、并发用户数、吞吐量、点击率、资源利用率等。

备注：

TPS是指事务数/秒 。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。

客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些信息来估计得分。

并发测试

1、并发大多分为两种情况

① 点层面上的并发 ,例如，在中午12点这个时间点，大家同时订饭

② 线层面上的并发 ，例如，在中午12点到13点这个时间段内，大家可能干不同的事，但同时对服务器产生压力(这种情况不要和在线人数混淆了，在线数和并发数是两个不同的概念。在线人数即并不表示服务器实际承载的压力)

2、测试目的并非为了获得性能指标，而是为了发现并发引起的问题

3、 并发测试并不等于性能测试 ：性能测试中把并发分为负载和压力测试。但并发测试不仅存在于性能测试中

并发测试的分类

1、对于功能并发测试，要先进行测试单业务功能场景的并发测试，在进行混合业务功能场景的并发测试

①功能并发测试的目的是为验证系统功能是否符合需求规格说明说的要求

2、对于性能并发测试，通常是满足某些系统性能指标的前提下，让被测试对象承担不同的工作量，以评估被测对象的最大处理能力及是否存在缺陷

①性能并发测试的目的是为验证系统性能指标是否符合需求规格说明书的要求

3、对于稳定性并发测试，通常是判断测试系统的长期稳定运行的要求

①稳定性并发测试的目的是为验证系统稳定性是否符合需求规格说明书的要求

4、对于异常性并发测试，模拟系统在较差、异常资源配置下运行。如人为降低系统工作环境所需要的资源、网络带宽、系统内存等，以评估被测对象在资源不足的情况下的工作状态

①异常性并发测试的目的是为验证系统异常响应机制是否符合需求规格说明书的要求

安全测试

1、安全测试的主要目的是查找软件自身程序设计中存在的安全隐患，并检查应用程序对非法侵入的防范能力

2、 常用的安全测试方法有：静态的代码安全测试、动态的渗透测试和程序数据扫描

按测试技术的不同来分：黑盒测试、白盒测试、灰盒测试

黑盒测试

1、把测试对象看做一个黑盒子，测试人员不用考虑程序内部的逻辑结构和内部特性，只需依据程序的需求说明书来检查程序的功能是否符合它的功能说明。界面测试、功能测试就属于黑盒测试

2、黑盒测试常用的方法有：等价划分、边界值分析、因果图分析、错误推测法

白盒测试

1、把测试对象看做一个透明的盒子，测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。

2、 单元测试就属于白盒测试，白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖和程序变异。

备注：

白盒测试法的覆盖标准有 逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。

六种覆盖标准：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖发现错误的能力呈由弱至强的变化。语句覆盖每条语句至少执行一次。判定覆盖每个判定的每个分支至少执行一次。条件覆盖每个判定的每个条件应取到各种可能的值。判定/条件覆盖同时满足判定覆盖条件覆盖。条件组合覆盖每个判定中各条件的每一种组合至少出现一次。路径覆盖使程序中每一条可能的路径至少执行一次。

灰盒测试

灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。

例子：