软件测试的基础知识

1.1测试的方法

测试方法

内容描述

系统测试

系统测试是通过与系统的需求规格作比较-，发现软件与系统需求规格不相符合或与之矛盾的地方。它将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来，在实际运行（使用）环境下，对计算机系统进行的测试。

 

功能测试

就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。是基于用户观点出发的测试，主要是验证功能是否符合需求，包括原定功能的检验、是否有冗余功能、遗漏功能。功能测试也叫黑盒测试。通常又将黑盒测试叫做：基于规格的测试、输入输出测试、功能测试或数据驱动测试。

安全测试

主要是测试系统在没有授权的内部或者外部用户对系统进行攻击或者恶意破坏时如何进行处理，是否仍能保证数据的安全。测试人员可以学习一些黑客技术，来对系统进行攻击。

压力测试

对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。例如测试一个Web 站点在大量的负荷下，何时系统的响应会退化或失败。

接口测试

程序员对各个模块进行系统联调的测试，包含程序内接口和程序外接口测试。这个测试，在单元测试阶段进行了一部分工作，而大部分都是在集成测试阶段完成的。建议由开发人员进行。

兼容性测试

兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操纵系统平台上、不同的网络等环境中是否能够很友好的运行的测试。

性能测试

在交替进行负荷和强迫测试时常用的术语。性能测试关注的是系统的整体。它和通常所说的强度、压力/负载测试有密切关系。所以压力和强度测试应该于性能测试一同进行。

可靠性测试

这里是比较狭义的可靠性测试，它主要是对系统能否稳定运行进行一个统计，在实际工作中如果没有条件可以不必特意去做。重点做好与之紧密相关的功能测试、健壮性测试就可以了。

 

 

 

 

1.1.1 系统测试

Ø 系统测试的概念

 

系统测试就是将已经集成好的软件系统，作为整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。

 

Ø 系统测试的目的

 

系统测试的目的在于通过与系统的需求定义比较，检查软件是否存在与系统定义不符合或与之矛盾的地方，以验证软件系统的功能和性能等满足其规约所指定的要求。发现缺陷并度量产品质量，按照系统的功能和性能需求进行的测试。

一般使用黑盒测试技术

一般由独立的测试人员完成

是检验所开发的软件是否按软件需求规格说明中确定的软件功能、性能、约束及限制等技术要求进行工作

从用户的角度出发进行测试

 

Ø 系统测试的意义

　　1）系统测试的环境是软件真实运行环境的最逼真模拟。系统测试中，各部分研制完成的真实设备逐渐替代了模拟器，是软件从未有过的运行环境。有关真实性 的一类错误，包括外围设备接口、输入/输出、或多处理器设备之间的接口不相容，整个系统的时序匹配等，在这种运行环境下能得到比较全面的暴露。 

　　2）通常系统测试的困难在于不容易从系统目标直接生成测试用例。而系统测试由系统人员组织，从系统完成任务的角度测试，软件在系统测试下获得了系统任务下直接的“测试实例”，这对检验软件是否满足系统任务要求是非常有意义的。

 

1.1.2 功能测试

Ø 功能测试的目的和内容

 

²  程序安装、启动正常，有相应的提示框、错误提示等

²  每项功能符合实际要求

²  系统的界面清晰、美观

²  菜单、按钮操作正常、灵活，能处理一些异常操作

²  能接受正确的数据输入，对异常数据的输入有提示、容错处理等

²  数据的输出结果准确，格式清晰，可以保存和读取

²  功能逻辑清楚，符合使用者习惯

²  系统的各种状态按照业务流程而变化，并保持稳定

²  支持各种应用的环境

²  能配合多种硬件周边设备

²  软件升级后，能继续支持旧版本的数据

²  与外部应用系统的接口有效 

 

如：

   1.页面链接检查   

   2.相关性检查 

   3.检查按钮的功能是否正确 

   4.字符串长度检查

   5.字符类型检查 

   6.标点符号检查 

   7.中文字符处理    

   8.检查带出信息的完整性

   9.信息重复    

   10.检查删除功能

   11.检查添加和修改是否一致 

   12.检查修改重名 

   13.重复提交表单

   14.检查多次使用back键的情况 

   15. search检查 

   16.输入信息位置

   17.上传下载文件检查

   18.必填项检查

   19.快捷键检查

   20.回车键检查

1.1.3 性能测试

Ø 性能测试的概念

 

性能测试通常会使用特定的测试工具，来模拟超常的数据量、负载等，监测系统的各项性能指标，如CPU和内存的使用情况、响应时间、反应速度等。 

 

Ø 性能测试的目的 

为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。

 ① 能力验证

 ② 能力规划

 ③ 性能调优

 ④ 缺陷发现

如，一般用户登录系统都是小于3S

 

Ø 性能测试指标的来源

用户对各项指标提出的明确需求；如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。（需求+经验）

 

Ø 主要的性能指标

服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间。

响应时间

从应用系统发出请求开始，到客户端接收到最后一个字节数据为止所消耗的时间。
合理的响应时间取决于实际的用户需求。

并发用户数

一般是指同一时间段内访问系统的用户数量。

   系统用户数，在线用户数

吞吐量

单位时间内系统处理的客户请求数量。

性能计数器

描述服务器或操作系统性能的一些数据指标，比如Windows系统资源管理器。

如：

中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器 。合理使用的范围在60%至70%。

 

Ø 性能测试要点

 

（1）测试环境应尽量与产品运行环境保持一致，应单独运行尽量避免与其他软件同时使用。

（2）性能测试一般使用测试工具和测试人员编制测试脚本来完成。

（3）性能测试的重点在于前期数据的设计与后期数据的分析。

（4）性能测试的用例主要涉及到整个系统架构的问题，所以测试用例一旦生成，改动一般不大，所以做性能测试的重复使用率一般比较高。

 

Ø 性能测试的过程

如：

对于LMS项目，我们至少需要可以测试这些性能指标：服务器响应速度、客户端上传下载文件的速度和文件大小、能同时支持的在线人数、系统运行的可靠性（稳定性）、邮箱容量、邮件收发速度、审批的响应时间。

1.1.4 压力测试

Ø 压力测试的概念

 

压力测试是指在正常资源下使用异常的访问量、频率或数据量来执行系统。在一种需要反常（如长时间的峰值）数量、频率或资源的方式下，执行可重复的负载测试，以检查程序对异常情况的抵抗能力，找出性能瓶颈。

在压力测试中可执行以下测试：

 

①如果平均中断数量是每秒一到两次，那么设计特殊的测试用例产生每秒十次中断。

②输入数据量增加一个量级，确定输入功能将如何响应。

③在虚拟操作系统下，产生需要最大内存量或其它资源的测试用例，或产生需要过量磁盘存储的数据。

 测试压力估算 

 测试环境准备 

 问题的分析 

 累积效应 

 

Ø 压力测试的类型

Ø 压力测试的目的

 

压力测试一般用于测试系统的稳定性。

如果一个系统能够在压力环境下稳定运行一段时间，那么该系统在普遍的运行环境下就应该可以达到令人满意的稳定程度。

在压力测试中，通常会考察系统在压力下是否会出现错误等方面的问题。

 

Ø 压力测试和性能测试的区别

1.1.5 安全测试

安全测试用来验证系统内部的保护机制，以防止非法侵入。要验证系统内的保护机制能否抵御入侵者的攻击。在安全测试中，测试人员扮演试图侵入系统的角色，采用各种办法试图突破防线。因此系统安全设计的准则是要想方设法使侵入系统所需的代价更加昂贵。

如：

Ø 用户ID及密码的设立限制是否有效

Ø 登陆失败次数的限制是否有效

Ø 用户ID及密码的存储是否加密

Ø 用户密码是否可以剪贴

Ø 登陆后空机时间控制是否有效

Ø 登陆后是否按用户资格规定在授权范围内操作

Ø 登陆完毕退出后，是否仍可以利用浏览器“退回”按钮回到登陆才可以进入的网页而不需要重新登陆

Ø 登陆后将任意一网页的URL存起，然后退出，再将该URL贴上浏览器地址栏，看是否可以绕道进入而不需登陆

Ø 如果测试的软件包含数据库，则所有以用户输入数据作为数据库查询语句组成部分的地方，都要找出是否允许一些SQL语言中有特殊意义的字符（如’，”，；，*，%，_等）在输入数据中出现，以保护数据库所有数据的完整性

Ø 专门开发软件来破坏系统的保护机制

Ø  故意导致系统失败，企图趁恢复之机非法进入

Ø  试图通过浏览非保密数据，推导所需信息

Ø 网页显示出错信息时不应显示一些敏感的资料。如向用户显示出错的某个文件存放处。

例如：File Not Found: \\MachineName\SecretDir\SomeSubDir\xFile

 

评价标准：有效性；生存性；精确性；出错反应时间；吞吐量

 

v 特别声明：

理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值，此时非法侵入者已无利可图。

 

1.1.6 容错性测试

Ø 容错性测试的概念

 

也叫做健壮性测试

主要用于测试系统抵御错误的能力。这里的错误通常指的是由于设计缺陷而带来的系统错误。测试的重点为当出现故障时，是否能够自动恢复或忽略故障继续运行。

 

Ø 容错性测试有两层含义

 

² 一是高可靠性

 

它体现了软件系统的质量；

需要根据符合规格说明的数据选择测试用例，用于检测在正常情况下系统输出的正确性。

² 二是从错误中恢复的能力

 

它体现了软件系统的适应性；

需要在异常数据中选择测试用例，检测非正常情况下的系统行为。

1.1.7可用性测试

可用性测试是面向用户的系统测试。

进行可用性测试时，测试人员应该关注如下几个方面：

² 系统中是否存在繁琐的功能以及指令；

² 安装过程是否复杂；

² 错误信息提示内容是否详细；

² GUI接口是否标准；

² 登录是否方便；

² 需要用户记住内容的多少；

² 帮助文本是否详细；

² 页面风格是否一致；

² 是否会造成理解上的歧义。

² 执行的操作是否与预期的功能相符，如点击保存按钮时记录是否存入数据库。

 

1.1.8 GUI测试

v GUI----Graphical User Interface，图形用户界面

 

² GUI测试是对图形用户界面进行的测试。一般来说，当一个软件产品完成GUI设计后，就确定了它的外观架构和GUI元素。

² GUI测试主要核实用户与软件之间的交互，验证用户界面中的对象是否按照预期的方式进行，并符合国家或行业的标准。

² 优秀的用户界面（UI）应具有7个要素：

符合标准和规范：

 

是否具有良好的可操作性和友好的界面效果，界面测试的目的是否能最大程度的满足用户的使用要求，通过测试，把系统的不足之处，并加以改进

 

1.1.9 兼容性测试

Ø 兼容性测试目的

 

就是检验被测应用对其他应用或者系统的兼容性，比如在对一个共享资源（数据、数据文件或者内存）进行操作时，检测两个或多个系统需求能否正常工作以及相互交互使用。

 

在做兼容性测试时，要主要关注如下几个问题：

①当前系统可能运行在哪些不同的操作系统环境下？

②当前系统可能与哪些不同类型的数据库进行数据交换？

③当前系统可能运行在哪些不同的硬件配置的环境上？

④当前系统可能需要与哪些软件系统协同工作？这些软件系统可能的版本有哪些？

⑤是否需要综合测试？

1.1.10 恢复测试

Ø 恢复性测试的目标

 

就是验证系统从软件或者硬件失败中恢复的能力。在测试过程中会采取各种人工干预方式使软件出错，而不能正常工作，进而检验系统的恢复能力。

    在进行恢复性测试时，同样首先要进行恢复性测试分析，经常要考虑的主要问题有如下几个：

1）恢复期间的安全性过程；

2）恢复处理日志方面的能力；

3）当出现供电问题时的恢复能力；

4）恢复操作后系统性能是否下降。

1.1.11 回归测试

Ø 回归测试的概念

 

回归测试是在软件发生变动时保证原有功能正常运作的一种测试策略和方法。

回归测试不需要进行全面的测试，而是根据修改的情况进行有选择性的测试。

这里所说的保证软件原有功能正常运作，可以从两方面来理解：

Ø 回归测试的目的 

 

² 所做的修改达到了预期的目的，例如缺陷得到了修改，新增加的功能得到了实现；

² 软件的修改没有引入新的缺陷，没有影响原有的功能实现。

² 不影响软件原有功能的正确性。

 

Ø  回归测试的方法

1．测试用例库的维护

(1) 删除过时的测试用例 

(2) 改进不受控制的测试用例 

(3) 删除冗余的测试用例

(4) 增添新的测试用例 

2．回归测试包的选择 

(1) 再测试全部用例 

(2) 基于风险选择测试 

(3) 基于操作剖面选择测试 

(4) 再测试修改的部分 

1.1.12 验收测试

Ø 验收测试的概念和目的

 

验证系统是否达到了用户需求规格说明书（可能包括项目或产品验收准则）中的要求，测试试图尽可能地发现软件中存留的缺陷，从而为软件进一步改善提供帮助，并保证系统或软件产品最终被用户接受。主要包括易用性测试、兼容性测试、安装测试、文档（如用户手册、操作手册等）测试等几个方面的内容。 

验收测试是将程序与其最初的需求及最终用户当前的需要进行比较的过程，是部署软件之前的最后一个测试操作。

 

Ø 验收测试的步骤

 

² 制定测试计划，测试项，测试策略及验收通过准则，并经过客户参与的计划评审。

² 建立测试环境，设计测试用例，并经过评审。

² 准备测试数据，执行测试用例，记录测试结果。

² 分析测试结果，根据验收通过准则分析测试结果，作出验收是否通过及测试评价。

l 测试项目通过；

l 测试项目没有通过，并且不存在变通方法，需要很大的修改；

l 测试项目没有通过，但存在变通方法，在维护后期或下一个版本改进；

l 测试项目无法评估或者无法给出完整的评估。此时必须给出原因。如果是因为该测试项目没有说明清楚，应该修改测试计划。 

² 提交测试报告

验收测试报告，也称为发布报告（Release Report）

Ø 验收测试完成标准

 

完全执行了验收测试计划中的每个测试用例。

在验收测试中发现的错误已经得到修改并且通过了测试或者经过评估留待下一版本中修改。 

完成软件验收测试报告。

 

注意事项：

必须编写正式的、单独的验收测试报告

验收测试必须在实际用户运行环境中进行

由用户和测试部门共同执行。如公司自开发产品，应由测试人员，产品设计部门，市场部门等共同进行。

v 特别说明：

实际上，以上多种测试内容并不是都要进行的，而是在制定测试策略和测试计划的时候有不同的侧重点，这与测试目标、测试资源、软件系统特点和业务环境有关。

 

 

1.2测试人员的职责

1.2.1测试人力的资源

Ø 测试团队

 

l 测试团队一般4-5人，还可细分为测试组

l 测试经理/测试组长

² 制定测试计划和测试方案

² 分配测试任务并检查测试进度

² 代表测试团队与开发、产品、用户沟通

² 实际测试

l 测试员

² 设计测试用例

² 执行测试用例并填写缺陷报告

² 检查缺陷处理结果

 

1.2.2测试员的效率

² 平均每个工作日发现3-5个Bug

² 平均每修正3个Bug，会引进1个新的Bug

² 平均75%的Bug会在单元测试阶段解决掉

² 平均20%的Bug会在集成测试和系统测试阶段解决掉

² 平均5%的Bug会被交付给用户

² 普通大型民用软件平均错误率5个/10,000LOC

² 电信/银行/操作系统等软件平均错误率5个/100,000LOC

 

v 说明：

l 软件规模代码行（LOC, Line of Code）是软件规模的一种量度，它表示源代码行数。

l 对于图片、Flash等非文本文件统计文件数量、文件大小；

l 对于文本文件统计文件数量、文本行数、字符数；

1.2.3测试和开发的人员比例

与产品大小、复杂度、质量要求相关

 

调查结果显示：

测试人员最贫乏的：20个开发人员对1个测试人员 

测试人员最丰富的：15个开发人员对8个测试人员 

也有一个异常数据：4个开发人员对0个测试人员

平均比率是 4.52个开发人员对1个测试人员

最常见的情况是：3个开发人员对1个测试人员

其次是：2.5 个开发人员对1个测试人员  

多数是开发人员与测试人员比率是3:1 或更低（即2.5:1 或 2:1 ） 

通常是1：3，即一个测试人员对3个开发人员。不同的公司、不同的团队这个比例相差还是很多的。 

 

 比如微软：微软公司的测试人员与开发人员比例一般为1:1，甚至在Windows 2000开发团队中，有1800个测试人员，900个开发人员，测试人员与开发人员比例为2:1。但是微软的测试是包含了单元测试、自动化测试、测试工具开发、手工测试、本地化测试等多项测试内容。他们的软件都经过了N多道测试工序的。如果单纯指手工测试的话，比例就低很多了。

 国内的一些小企业，比例可能只有1：10；那是因为公司还在起步阶段，市场影响力还不大，质量要求还不高的情况下。如果质量要求提升了，这个比例就远远不能达到要求了。

在Google(谷歌)公司，则测试人员与开发人员比例则很低，据谷歌公司的测试经理介绍，为1:10。

因此测试与开发的比例要基于几个条件来确定：

· 项目要求的可靠性

· 必须测试的可配置的范围

· 软件的易测试程度

· 工具的可用性

· 测试人员和开发人员的经验

· 必须坚持的质量标准

1.开发能力基线；开发能力强，产出质量好，测试的效率就高了，所需要投入的测试人头就可以少些；即在相同的质量标准前提下，测试与开发的比例与开发能力基线成反比。

2.测试能力基线；测试人员能力强，一个抵三个，当然所需测试人头就可以少些了；即在相同的质量标准前提下，测试与开发的比例与测试能力基线成反比。

3.公司对产品的质量要求；质量要求高，当然测试投入就要多些，质量要求低，测试投入就可以少些；即在开发测试能力相同的前提下，测试与开发的比例与质量要求成正比。

   所以谈论测试与开发的比例都不能离开这几个条件：公司对产品的质量要求；开发人员的能力；测试人员自身的能力。

1.3软件文档的分类

1.4测试等级的划分

1.4.1 Bug严重程度分为四个级别

 

级别一：死机，数据丢失，主要功能丧失，系统悬挂

级别二：主要功能丧失，导致严重的问题，或致命的错误声明

级别三：次要功能丧失，不太严重，如提示信息不太准确

级别四：微小的问题，对功能几乎没有影响，产品及属性还可使用，如有错别字

 

1.4.2优先级别分为四个级别：

 

级别一：必须立即修改

级别二：一天内修改

级别三：三天内修改

级别四：短期内无须解决或在下一版本中解决

说明：验证程度越高，优先级越高，原有错误优先级高于新版本错误

同样的bug重复修改的次数，是衡量开发人员工作效率的重要依据

 

1.4.3缺陷类型定义

本规范定义以下五类缺陷：

Ø A类——严重错误，包括：

1. 由于程序所引起的死机,非法退出

2. 死循环

3. 导致数据库发生死锁

4. 数据通讯错误

5  严重的数值计算错误

Ø B类——较严重错误，包括：

1. 功能不符

2. 数据流错误

3. 程序接口错误

4. 轻微的数值计算错误

Ø C类——一般性错误，包括：

1. 界面错误(详细文档)

2. 打印内容、格式错误

3. 简单的输入限制未放在前台进行控制

4. 删除操作未给出提示

Ø D类——较小错误，包括：

1. 辅助说明描述不清楚

2. 显示格式不规范

3. 长时间操作未给用户进度提示

4. 提示窗口文字未采用行业术语

5. 可输入区域和只读区域没有明显的区分标志

6. 系统处理未优化

Ø E类——其它（非缺陷）

1.光标跳转设置不好，鼠标定位错误

2.一些建议性的问题

1.5测试的标准

1.5.1测试的标准

Ø 第一种：以缺陷类型做为标准

软件测试合格须符合以下标准

以上比例为错误占总测试模块的比例。

软件产品未经测试合格，不允许投运。

v 特别说明：

表格中的A.B.C.D.E类是指缺陷的类型

 

Ø 第二种：以测试用例作为标准

一般有“基于测试用例”和“基于缺陷密度”两种评比准则，在这里我们采用前者。

准则如下：

Ø 功能性测试用例通过率达到100％；

Ø 非功能性测试用例通过率达到95％；

Ø 沒有高于优先级3以上的问题；

Ø 一般是3-4个版本后bug数量减少，达到出货的要求

备选通过办法：

   根据实际情况由软件开发部门的经理、项目经理和测试负责人等共同讨论确定本阶段是否结束。 

 

Ø 第三种：以测试用例作为标准

 

测试停止的标准：

（1）.各个模块或各个模块下的各个功能的测试用例覆盖为100%；

（2）.测试用例执行覆盖率为100%，通过测试的测试用例所占必需在90%以上；

（3）.bug走势图中，系统错误、功能错误、数据处理错误在连续3个工作日内未出现bug，其他错误在连续3个工作日内未出现合计5个以上（含5个）错误。此时可对软件停止测试。

1.5.2验收测试停止的标准

² 软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。

² 在验收测试中发现的错误已经得到修改，各级缺陷修复率达到标准

² 需求分析文档、设计文档和编写实现一致

² 验收测试工件齐全（测试计划、测试用例、测试日志、测试通知单、测试分析报告，待验收的软件安装程序）

1.5.3测试的修复率和覆盖率标准

Ø 缺陷修复率标准：

² A.B级修复率应达到100%

² C.D修复率应达到90%以上

² E错误修复率应达到60%以上

 

Ø 覆盖率标准

² 语句覆盖率最低不能小于80%（白盒测试时的语句覆盖率）

² 测试用例执行覆盖率应达到100%（功能测试用例均已执行）

² 测试需求执行覆盖率应达到100%（业务测试用例均已执行）

第二章 测试的流程与规范

2.1测试-开发流程

2.1.1开发流程

2.1.2开发-测试流程图

2.1.3测试流程图

2.1.3.1计划与设计阶段

2.1.3.2实施测试阶段

2.1.3.3测试总结