文档库 最新最全的文档下载
当前位置:文档库 › 软件测试基础知识

软件测试基础知识

软件测试基础知识
软件测试基础知识

一软件测试基本概念

1. 软件的定义

软件是计算机中与硬件(hardware)相结合的一部分, 包括程序(program)和文档(document).

(“程序” 指的是能够实现某种功能的指令的集合, 如C语言程序, JAVA程序, VB程序.

“文档” 指的是软件在开发, 使用和维护过程中产生的图文集合, 如<<系统需求规格说明书>>,<<用户手册>>, readme, 甚至是一些软件市场宣传资料, 包括文字和图形等.)

2. 软件的分类

按照功能划分: 系统软件和应用软件

(系统软件: 能够直接操作底层的硬件, 并为上层软件提供支撑的软件, 如操作系统软件, 各种硬件驱动程序等. 这类软件需要我们结合底层的硬件加以测试.

应用软件: 能够为用户提供某种特定的应用服务的软件, 如Office, 金山词霸, QQ等. 这类软件也是今后测试的重点.)

按技术架构划分: 单机版软件, C/S结构软件, B/S结构软件.

(单机版软件: 直接在单个计算机上安装并运行的软件, 如Office, 画图工具等.

C/S结构软件: C=Client(客户端), S=Server(服务器端).点这种软件是基于局域网或互连网的. 如QQ, MSN以及各种网络游戏.

B/S结构软件: B=Browser(流览器), S=Server(服务器), 这种软件同样是基于局域网或互连网的.,不是它与C/S 结构软件的区别就在于不需要安装客户端(Client), 只需要有IE等流览器即可. 搜狐, 新浪等门户网战以及163邮箱都属于B/S结构软件.)

按照用户划分: 产品软件和项目软件.

(产品软件: 目标用户是大众用户, 测试这类软件比较麻烦, 因为最终用户使用的计算机系统千差万别, 需要考虑硬件和软件的兼容性测试.

项目软件: 目标是具体的用户.

按照开发规模划分: 小型, 中型和大型.

3. Bug

软件的Bug指的是软件中(包括程序和文档)不符合用户需求的问题.

(用户需求一般体现在<<系统需求规格说明书>>中(specification,一般由系统分析员或是项目经理根据用户需求撰写), 它是我们测试时需要参考的重要文档. 但是一定要记住, <<系统需求规格说明书>>绝对不等同于用户的需求, 因为从真实的用户需求到<<系统需求规格说明书>>, 这中间会有信息传递的误差.)

4. 软件测试

使用人工或自动手段,来运行或测定某个系统的过程. 其目的在于检验它是否满足规定的需求或弄清期望结果与实际结果之间的差别.

5. 测试环境

软件测试环境就是软件运行的平台, 即软件,硬件和网络的集合.

测试环境=软件+硬件+网络

硬件: 主要包括PC机(包括品牌机和兼容机), 笔记本, 服务器, 各种PDA终端等.

软件:, 这里主要指的是软件运行的操作系统.

网络: 主要针对的是C/S 结构和B/S结构的软件.

6. 怎样搭建测试环境

搭建测试环境有几个要点:

1) 真实(尽量模拟用户的真实使用环境)

2) 干净(测试环境中尽量不要安装其他与被测软件无关的软件)

3) 无毒(测试环境没有中毒)

4) 独立(测试环境和开发环境独立)

7. 测试环境的分类

软件开发环境: 软件在开发过程中使用的环境, 一般包括VB VC等一些开发工具.

软件生产运行环境: 最终用户使用的环境.

总结一句话: 软件测试环境要与软件生产运行环境保持一致, 要从开发环境中独立出来.

8. 测试用例

测试用例: 英文为Test Case, 缩写为TC, 指的是在测试执行之前设计的一套详细的测试方案, 包括测试环境, 测试步骤, 测试数据和预期结果.

测试用例= 输入+ 输出+ 测试环境

9 编写测试用例的注意事项

1) 为什么要写用例

编写测试用例, 有如下好处:

●便于团对交流: 假如一个测试团对有多个成员, 大家测试的时候都各自为政, 没有统一的标准, 测试的效率

无疑会大打折扣., 如果大家都遵循统一的用例规范去测试, 就会解决这一问题.

●便于重复测试: 软件在实际开发过程中是会有不同版本的, 测试用例就像一个备忘录一样,便于重复测试.

●便于跟踪统计: 这一点针对测试经理或项目经理来说的, 项目负责人通过看测试用例的执行情况, 就能了

解项目目前的概况, 比如机警执行了哪些测试, 还有哪些测试没有执行, 测试没有通过的地方主要集中在哪些模块等.

●便于用户自测: 尤其是项目软件, 有时用户希望自己测试一下软件产品, 但是用户大多数都是非专业人士,

他需要根据你写好的用例来更好地检验产品的质量.

一个明显的缺点: 需要花费大量的时间

2) 什么时候写用例

什么时候写用例, 没有统一的标准答案, 但有一点可以肯定, 就是测试用例要尽早编写.

通常会在测试设计阶段来写用例, 即<<需求规格说明书>> 和<<测试计划>>都已完成之后.

3) 由谁来写测试用例

测试人员会有不同的角色, 一般分为测试经理,测试设计人员, 测试执行人员和测试工具开发人员等, 一般测试用例是由测试设计人员来编写的, 由测试执行人员来执行, 这就要求测试设计人员有一定的用例设计经验, 并对被测系统有深入的了解.

4) 根据什么写测试用例

编写测试用例的唯一标准就是用户需求, 具体的参考资料就是<<系统需求规格说明书>>和软件原形, 其中软件原形指的是没有嵌入全部源代码的软件界面.

但需要说明的是, 用户需求不是一成不变的, 而是在一直变化的. 这就需要根据不断调整变化的用户需求, 来修改和维护我们已经写好的测试用例, 这个工作量也是很大的.

二软件测试分类

1 黑盒测试和白盒测试

黑盒测试(Black-box testing), 指的是把被测的软件看作是一个黑盒子, 我们不去关心盒子里面的结构是什么样子的, 只关心软件的输入数据和输出结果.

黑盒测试既包括功能测试, 也包括性能测试.

白盒测试(White-box testing), 指的是把盒子盖打开, 去研究里面的源代码和程序结构.

在软件公司里面,往往采用黑盒和白盒测试相结合的方法, 对软件的整体功能和性能进行黑盒测试, 对软件的源代码采用白盒测试.

灰盒测试(gray-box testing): 可以看作是黑盒测试和白盒测试册一种结合.

2. 静态测试和动态测试

静态测试(static testing): 是指不实际运行被测软件, 而只是静态地检查程序代码, 界面或文档中可能存在的错误的过程.

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

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

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

动态测试(dynamic testing): 顾名思义是指实际运行被测程序, 输入相应的测试数据, 检查实际输出结果和预期结果是否相符的过程, 所以我们判断一个测试属于动态测试还是静态测试, 唯一的标准就是是否运行程序.

黑盒测试, 白盒测试, 静态测试和动态测试之间的交叉关系, 总结以下4句话:

●黑盒测试有可能是动态测试(运行程序, 只看输入和输出),也有可能是静态测试(不运行程序,只查看界面) ●白盒测试有可能是动态测试(运行程序,并分析代码结构),也有可能是静态测试(不运行程序,只静态查看代码) ●动态测试有可能是黑盒测试(运行程序,只看输入和输出),也有可能是白盒测试(运行程序, 并分析代码结构) ●静态测试有可能是黑盒测试(不运行程序, 只查看界面),也有可能是白盒测试(不运行程序, 只静态查看代码)

3. 单元测试, 集成测试, 系统测试和验收测试

单元测试(unit test)

1) 什么是单元测试: 是指对软件中的最小可测试单元进行检查和验证.

2) 什么时候进行单元测试: 通常在程序员编码之后, 代码已经通过编译后进行单元测试.

3) 由谁来进行单元测试: 单元测试一般由白盒工程师或开发人员来测试. 如果开发人员来测试, 最好做到交

叉测试, 避免1个人只测试自己的代码.

4) 单元测试的依据: 单元测试的依据主要有两个: 一是源程序本身, 包括代码和注释; 还有一个就是项目的<<

详细设计>>文档.

5) 单元测试通过的标准是什么?

不同的公司会有不同的说法. 下面有一个比较通用的通过标准供大家参考:

程序通过所有单元测试的用例

语句覆盖率达到100%

分支的覆盖率达到85%

6) 国内单元测试的现状: 国内目前的很多软件公司的单元测试还很不正规, 只是由开发人员来简单地编译和

调试一下自己的程序, 没有相应的单元测试计划, 单元测试用例和代码覆盖率的统计, 所以也急需大量高素质的白盒工程师来填补这一空白.

7) 如何进行单元测试: 单元测试主要用白盒测试方法, 一般我们先静态地检查代码是否符合规范, 然后动态

8) 桩模块和驱动模块:

桩模块(stub)是指模拟被测模块所调用的模块.

驱动模块(driver)是指模拟被测模块的上级模块, 驱动模块用来接收测试数据, 启动被测模块并输出结果

集成测试

1) 什么是集成测试: 集成测试是单元测试的下一个阶段, 是指将通过测试的单元模块组装成系统或子系统,

再进行测试, 重点测试不同模块的接口部分.

2) 什么时候进行集成测试: 理论上, 集成测试在单元测试之后进行, 但实际上, 我们不可能等到所有的单元模

块都测试完成后再进行集成测试, 那样效率太低, 所以往往是单元测试和集成测试同步进行, 在单元测试中先测试几个函数的自身功能, 然后再集成测试一下这几个函数的接口(即参数传递)

3) 由谁来进行集成测试: 一般由白盒测试工程师或是开发人员进行.

4) 集成测试的依据是什么: 一般的说法是, 集成测试的依据是单元测试的模块以及<<概要设计>>文档.

系统测试和验收测试

集成测试之后就是系统测试和验收测试了, 这也是我们测试的重点.

系统测试(system testing), 指的是将整个软件系统看做一个整体进行测试, 包括对功能, 性能, 以及软件所运行的软硬环境进行测试.

目前系统测试主要由黑盒测试工程师在整个系统集成完毕后进行测试, 前期主要测试系统的功能是否满足要求, 后期主要测试系统运行的性能是否满足要求, 以及系统在不同的软硬环境中的兼容性等.

系统测试是测试人员需要花费大量的时间和精力去完成的, 也是软件交给用户进行验收测试的最后一道关口.

系统测试的主要依据是<<系统需求规格说明书>>文档.

验收测试(acceptance testing), 指的是在系统测试的后期, 以用户测试为主, 或有测试人员等质量保障人员共同参与的测试, 它也是软件正式交给用户使用的最后一道工序.

验收测试的重要性不言而喻, 因为它涉及到用户能否最终验收签字并付款.

验收测试又分为alpha测试和beta测试, 其中alpha 测试指的是由用户, 测试人员, 开发人员等共同参与的内部测试, 而beta 测试指的是内测后的公测, 即完全交给最终用户测试.

4, 功能测试和性能测试

功能测试(function testing), 是黑盒测试的一个方面, 它检查实际软件的功能是否符合用户的需求.

功能测试又可以分为很多种: 逻辑功能测试, 界面测试, 易用性测试, 安装测试, 兼容性测试等.

1) 逻辑功能测试(logic function testing)

2) 界面测试(UI testing=User Interface testing) 界面测试的内容很多, 以Windows程序为例, 主要有以下的

测试项: 窗口, 下拉式菜单和鼠标操作, 数据项等.

3) 易用性测试(usability testing), 易用性测试是指从软件使用的合理性和方便性等角度对软件系统进行检查,

来发现软件中不方便用户使用的地方.

4) 安装测试(installation testing), 这里面的安装测试是指广义上的, 包括安装和卸载.

5) 兼容性测试(compatibility testing), 兼容性测试包括硬件兼容性和软件兼容性测试,

硬件兼容性主要是指软件运行的不同硬件平台的兼容性, 如PC机, 笔记本, 服务器等.

软件兼容性主要讨论产品软件的兼容性测试. 分单机版, C/S结构和B/S结构软件.

5, 性能测试

性能测试(performance testing) 是软件测试的高端领域, 性能测试一般要用到自动化测试工具.

软件的性能包括很多方面, 主要有时间性能和空间性能两种.

1) 时间性能: 主要指软件的一个具体事务的响应时间(respond time),

标准, 而且跟用户的主观感受有关系.

2) 空间性能: 主要软件运行时所消耗的系统资源.

比如, 某软件在推荐配置下运行时, CPU的利用率为10%, 内存占有率为20%, 则这两个指标可看作该软件的空间性能.

软件性能测试分类: 分为一般性能测试, 稳定性测试, 负载测试和压力测试.

1) 一般性能测试: 一般性能测试指的是让被测系统在正常的软硬环境下运行, 不向其施加任何压力的测试.

2) 稳定性测试(reliability testing), 是指连续运行被测系统, 检查系统运行时的稳定程度.

通常用MTBF (Mean Time Between Failure, 错误发生的平均时间间隔) 来衡量系统的稳定性, MTBF越大, 系统的稳定性越强.

稳定性测试的方法也很简单, 即采用24 x 7 (24小时x 7 天) 的方式让系统不间断运行, 至于具体运行多少天, 是一周还是一个月, 视项目的实际情况而定.

3) 负载测试(load testing), 是性能测试的一种, 通常是指让被测系统在其能忍受的压力的极限范围之内连续

运行, 来测试系统的稳定性.

负载测试和稳定性测试比较相似, 都是让被测系统连续运行, 区别就在于负载测试需要给被测系统施加其刚好能承受的压力, 负载测试为我们测试系统在临界状态下运行是否稳定提供了一种方法.

4) 压力测试(stress testing), 是性能测试的一种, 通常是指连续不断地给被测系统增加压力, 直到将被测系统

压垮为止, 用来测试系统所能承受的最大压力.

6, 回归测试, 冒烟测试, 随机测试

回归测试( regression testing) 是指对软件的新的版本测试时, 重复执行上一个版本测试时的用例.

回归测试可以在任何测试阶段进行(单元测试, 集成测试, 系统测试, 验收测试等), 既有黑盒测试的回归, 也有白盒测试的回归.

冒烟测试(smoke testing), 是指在对一个新版本进行系统大规模的测试之前, 先验证以下软件的基本功能是否实现, 是否具备可测性.

冒烟测试和回归测试往往结合起来使用, 每当我们拿到一个新版本时, 都首先进行冒烟测试, 如果通过, 则进行回归测试.

随即测试(random testing), 是指测试中所有的输入数据都是随机生成的, 其目的是模拟用户的真实操作, 并发现一些边缘性的错误.

三软件测试的常识

软件的生命周期

基本定义: 软件生命周期是指软件开发和测试全部过程, 活动和任务的结构框架, 是从可行性研究到需求分析, 软件设计, 编码, 测试, 软件发布维护的过程.

分为软件开发的生命周期和软件测试的生命周期.

软件开发的生命周期也叫软件开发的流程, 是指软件的开发过程中需要经过哪些环节.

需求分析→概要设计→详细设计→编码→维护

1) 首先, 系统分析师或是项目经理对用户的需求进行需求分析(requirement analysis), 生成<<需求规格说明

书>>(Specification).

2) 然后, 由系统架构师或是技术经理根据<<需求规格说明书>>来进行系统设计(design), 其中概要设计主要

包括功能模块划分, 系统架构( B/S, C/S等)设计, 选用开发工具和技术等, 详细设计包括模块算法详细设计, 模块间接口设计, 后台数据库设计等. 一般生成<<概要设计>> 和<<详细设计>>文档.

3) 其次, 软件工程师或是程序员根据<<需求规格说明书>>, <<概要设计>> <<详细设计>>进行编码, 生成系

统的源代码.

4) 最后, 软件发布后, 需要由技术支持工程师或是售后服务工程师对系统进行维护(maintenance)

其中每一个环节都有一个小圆圈, 表示每一个过程都是一个迭代xuan环的过程.

软件测试的生命周期:

1) 首先, 在项目的初期, 需要由测试经理或是测试组长根据<<需求规格说明书>> 或是界面原型来编写测试

计划(test plan), 生成测试计划文档.

2) 然后, 在概要设计和详细设计阶段, 由测试设计人员根据<<需求规格说明书>>或是界面原型来进行测试设

计(test design), 主要包括编写测试用例(test case), 设计测试策略等, 主要生成测试用例文档.

3) 其次, 在编码的后期, 由测试执行人员参考<<需求规格说明书>>和<<测试用例>>来对系统进行测试实施,

这里面又包括了单元测试, 集成测试, 系统测试, 主要生成大量的<<缺陷报告>> (defect report).

4) 最后, 项目的后期, 由测试经理或是测试组长评估一下测试的过程和结果, 为下一阶段或是下一个项目的

测试积累一些经验和教训, 一般生成一个<<测试总结报告>(Test report).

软件生命周期的模型:

1) 瀑布模型

3) V模型

V模型属于比较新的模型

V模型的优点就是详细表示了测试的各个阶段以及参考依据

●单元测试参考的是<<详细设计>>

●集成测试参考的是<<概要设计>>

●系统测试参考的是<<需求规格说明书>>

●验收测试参考的是实际用户需求.

V模型的缺点是没有说明在项目的前期测试需要做哪些工作(编写测试计划, 测试用例等),待而且和瀑布模型一样, 流程也是单项的,不可逆.

相关文档