单元1 软件测试的认知与体验_第1页
单元1 软件测试的认知与体验_第2页
单元1 软件测试的认知与体验_第3页
单元1 软件测试的认知与体验_第4页
单元1 软件测试的认知与体验_第5页
已阅读5页,还剩95页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、单元1 软件测试的认知与体验软件测试概述1.1软件测试的地位和作用1.2软件测试的目的1.3软件测试的原则1.4教学目标(1)熟悉软件测试的基本概念以及软件测试在整个软件开发生命周期中的地位和作用(2)了解软件测试的分类和对软件测试人员的要求(3)掌握软件测试的目的、原则和流程(4)掌握场景设计法与软件测试的基线(5)学会对Windows操作系统自带的计算器进行功能测试和界面测试(6)学会应用场景法对ATM机进行黑盒测试(7)学会应用场景法对QQ登录的界面和功能进行测试教学方法讲授分析法、任务驱动法、探究学习法课时建议6课时测试阶段验证测试、确认测试测试对象计算器、ATM机、QQ登录测试方法黑

2、盒测试法、功能测试、界面测试、场景法1.1软件测试概述1软件的概念 软件是计算机系统中与硬件相互依存的一个部分,它是源程序、数据及其相关文档的集合。 2软件缺陷的概念 软件缺陷(Defect)是指计算机软件中存在的某种破坏其正常运行的问题、错误,或者其中隐藏的功能缺陷,称为“Bug”,“Bug”在英语中是臭虫的意思,通常用“Bug”表示计算机系统硬件或软件中隐藏的错误、缺陷或问题。 软件缺陷的存在会导致软件产品在某种程度上不能满足用户的需要,在软件开发过程中,产生软件缺陷是不可避免的,产生软件缺陷的原因比较复杂,主要包括以下几个方面。(1)软件项目复杂(2)沟通交流不够(3)程序设计错误(4)

3、软件需求变化(5)代码文档缺陷(6)开发工具错误3软件测试的概念 简单地说,软件测试就是为了发现错误而执行程序的过程。 软件测试的主要工作是验证(Verification)和确认(Validation)。 软件测试的对象不仅仅是程序,还包括整个软件开发期间各个阶段所产生的文档。4测试用例的概念 测试用例是为某个特定目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。 测试用例(Test Case)可以用一个简单的公式来表示:测试用例输入输出测试环境5测试环境的概念 简单地说,测试环境就是软件运行的平台,即进行软件测试所必需的工作平台和前提条件,可用如

4、下公式来表示: 测试环境硬件软件网络历史数据1.2软件测试的地位和作用 软件测试在整个软件开发生命周期中占据着重要的地位 。(1)需求分析阶段 进行这些测试有助于明确系统需求,这些测试将成为最终测试单元的核心。(2)系统设计阶段 系统设计阶段要阐明一般测试策略,如测试方法和测试评价标准,并创建测试计划。 另外,重大测试事件的日程安排也应在这一阶段构建,同时还要建立质量保证和测试文档的框架。(3)系统编码阶段 代码走查和代码审查都是有效的人工测试技术;静态分析技术通过分析程序特征来排除错误;对于大型程序,需要用自动化工具来完成这些分析。(4)系统测试阶段 测试应用系统应着眼于功能上的测试,严格控

5、制和管理测试信息是最重要的。(5)系统安装阶段 系统安装阶段的测试必须确保投入运行的程序是正确的,例如,程序是正确的版本,确保数据被正确地更改和增加。(6)系统维护阶段 系统在每一次更改之后都需要重新测试,这种重新进行的测试称为回归测试。1.3软件测试的目的 (1)软件测试是一个为了发现错误而执行程序的过程。 (2)软件测试是为了证明程序有错,而不是证明程序无错。 (3)一个好的测试用例在于它能发现至今尚未发现的错误。 (4)一个成功的测试是发现了至今尚未发现错误的测试。1.4软件测试的原则 (1)应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。 (2)程序员应避免检查自己的程序。

6、 (3)测试用例应由测试输入数据和与之对应的预期输出结果两部分组成。 (4)在设计测试用例时,应当包括合理的输入条件和不合理的输入条件。 (5)充分注意软件测试时的群集现象。 (6)严格执行测试计划,排除测试的随意性。 (7)应当对每一个测试结果做全面检查。 (8)妥善保存测试过程中产生的各种数据和文档。 (9)注意回归测试的关联性。1.5软件测试的分类1.5.1按测试阶段分类 软件测试按测试阶段可划分为单元测试、集成测试、确认测试和系统测试,最后进行验收测试。1单元测试 单元测试(Unit Testing)又称模块测试(Module Testing),是指对软件中的最小可测试单元进行测试 。

7、 单元测试具有以下优点。 (1)是一种管理和组合测试元素的手段。 (2)可以减轻调试的难度。 (3)提供同时测试多个单元的可能。2集成测试 集成测试(Integration Testing)又称为组装测试,是在单元测试的基础上,按照设计要求,将通过单元测试的单元组装成系统或子系统而进行的测试 。3系统测试 系统测试(System Testing)是为了验证和确认系统是否达到其原始目标,而对集成的硬件和软件系统进行的测试,是在真实或模拟系统运行的环境下,检查完整的程序是否能和系统(包括系统软件、支持平台、硬件、外设和网络)正确配置、连接,并满足用户需求。4确认测试 确认测试是通过检验和提供客观证

8、据,证实软件是否满足特定预期用途的需求,检测与证实软件是否满足软件需求说明书中规定的要求。5验收测试 验收测试(Acceptance Testing)又称接受测试,是在系统测试后期,以用户测试为主,或有质量保证人员共同参与的测试。 验收测试又分为测试和测试。 测试也称为开发方测试,开发方通过检测和提供客观证据,证明软件运行是否满足用户规定的需求。 测试是内部测试之后的外部公开测试,是将软件完全交给用户,让用户在实际使用环境下进行的对产品预发版本的测试。 1.5.2按是否需要执行被测试软件分类1静态测试 静态测试(Static Testing)又称为静态分析(Static Analysis),是

9、不实际运行被测软件,而是直接分析软件的形式和结构,从而查找缺陷的测试 。(1)测试程序代码 测试程度代码主要是为了查看代码是否符合相应的标准和规范 。(2)测试界面 测试界面主要是查看软件的实际操作和运行界面是否符合需求中的相关说明,是否符合用户的要求。(3)文档测试 文档测试主要是检查需求规格说明书、用户手册与需求说明是否真正符合用户的实际需求。2动态测试 动态测试(Dynamic Testing)又称为动态分析(Dynamic Analysis),是指需要实际运行被测软件,通过观察程序运行时所表现出来的状态、行为等发现软件缺陷的测试 。1.5.3按是否需要查看代码分类1黑盒测试 黑盒测试(

10、Black-box Testing)是软件测试的主要方法之一,也称功能性测试(Functional Testing)或数据驱动测试(Data-driven Testing),但并不仅限于功能测试。 2白盒测试 白盒测试主要分析程序内部的逻辑结构及算法,通常不关心功能与性能指标。 白盒测试又称为结构性测试(Structural Testing)或逻辑驱动测试(Logic-driven Testing) 。 与黑盒测试相比,白盒测试具有如下特殊的应用领域。 (1)程序代码具有多个分支。 (2)白盒测试的覆盖指标可以充当黑盒测试的检查手段。 (3)代码中常存在内存泄露的问题,尤其C/C+程序。 (4

11、)有时只有在某种极端的条件下才会出现的情况,是难以直接进行功能测试的。3灰盒测试 灰盒测试是介于白盒测试和黑盒测试之间的测试,灰盒测试关注输出对于输入的正确性,同时也关注内部表现,但这种关注不像白盒测试那样详细、完整,只是通过一些表征性的现象、事件和标志来判断内部的运行状态。1.5.4按测试执行时是否需要人工干预分类1手工测试 手工测试完全由人工完成测试工作,包括制订测试计划、设计和执行测试用例、检查和分析测试结果等。2自动测试 自动测试是各种测试活动的管理与实施使用自动化测试工具或自动化测试脚本来进行的测试,以某种自动测试工具来验证测试需求。 1.5.5按测试目的分类1功能测试2界面测试3性

12、能测试4负载测试5易用性测试6兼容性测试7安全性测试8接口测试9文档测试10安装与卸载测试11压力测试12强度测试13可靠性测试14健壮性测试15恢复测试1.5.6其他测试类型1冒烟测试 冒烟测试的名称可以理解为该种测试耗时短,仅用一袋烟功夫足够了。 也有人认为该名称是形象地类比新电路板基本功能检查,任何新电路板焊好后,先通电检查,如果存在设计缺陷,电路板可能会短路冒烟。 冒烟测试的优点是可以节省大量的测试时间,防止创建失败,其缺点是覆盖率较低。2随机测试 随机测试是这样一种测试,在测试中,测试数据是随机产生的。 这样的测试有时被称为猴子测试(Monkey Testing)。3回归测试 回归测

13、试是验证缺陷是否修改正确和修改过程中是否会引入新问题的活动,回归测试并不是一个测试级别,却是各个测试阶段必须包括的一个测试活动。 1.6软件测试的流程1制订测试计划(1)软件测试背景(2)软件测试依据(3)测试范围的界定(4)测试风险的确定(5)测试资源的确定(6)测试策略的确定(7)制订测试进度表2设计测试用例和测试过程 测试用例是为特定目标开发的测试输入、执行条件和预期结果的集合,这些特定目标可以用于验证一个特定的程序路径,或核实是否符合特定需求。 测试过程一般分成几个阶段:代码审查、单元测试、集成测试、系统测试和验收测试等 。3实施软件测试 (1)测试准备和建立测试环境。 (2)获取测试

14、数据。 (3)执行测试。 执行测试一般由输入、执行过程、检查过程和输出4个部分组成。4评估与总结软件测试 软件测试的主要评估方法包括缺陷评估、测试覆盖和质量评测。 质量评测是对测试对象的可靠性、稳定性以及性能的评测,它建立在对测试结果的评估和对测试过程中确定的变更请求分析的基础上。1.7软件测试人员的类型和要求1软件测试人员的类型 软件测试过程中,必须要合理地组织人员,一般将软件测试人员分成3部分:一部分为上机测试人员(测试执行者),一部分为测试结果检查核对人员,还有一部分是测试数据制作人员,这3部分人员应该紧密配合、相互协调,保证软件测试工作的顺利进行。(1)上机测试人员。(2)测试结果检查

15、核对人员。(3)测试数据制作人员。(4)测试经理。(5)测试文档审核师。(6)测试工程师。2软件测试人员的要求 (1)懂得计算机的基本理论,又有一定的软件开发经验。 (2)了解软件开发的基本过程和特征,对软件有良好的理解能力,掌握软件测试相关理论及技术。 (3)具有软件业务经验。 (4)能根据测试计划和方案进行软件测试,针对软件需求制订测试方案,安排测试计划,设计测试用例,搭建测试环境,进行软件测试。 (5)能够规划测试环境,编制测试大纲并设计测试用例,对软件进行全面测试。 (6)能够编制测试计划,评审测试方案,规范测试流程及测试文档,分析测试结果,管理测试项目。 (7)会操作测试工具。 软件

16、测试人员应具备以下基本素质。 沟通能力。 技术能力。 自信心。 洞察力。 探索精神。 不懈努力。 创造性。 追求完美。 判断准确。 老练稳重和说服力。1.8场景设计法 场景设计法是一种典型的黑盒测试方法,它不考虑软件的内部结构。 场景设计法的一般步骤如下。 构造基本流和备选流。 根据基本流和备选流构造场景。 根据场景设计测试用例。 对每个测试用例补充必要的测试数据。 图1-1所示为场景法的基本流与备选流的示意图,图中包括1个基本流和3个备选流,备选流3涉及的是循环的情况。(1)基本流 基本流是整个业务流程中最基本的一个事件流程(2)备选流 备选流以基本流为基础,在经过的每个判定节点处满足不同的

17、触发条件而导致的其他事件流。(3)场景 所谓场景,可以看作是基本流与备选流的有序集合。备选流3备选流2备选流1基本流开始测试结束测试图1-1场景法的基本流与备选流1.9软件开发与软件测试的基线 基线(Baseline)是一个已经被正式评审和批准的规格或产品,它作为进一步开发的一个基础,并且必须通过正式的变更流程来变更。 基线是软件文档或源码(或其他产出物)的一个稳定版本,它是进一步开发的基础,基线是项目储存库中每个工件版本在特定时期的一个“快照”。【引导测试】【任务1-1】对Windows操作系统自带的计算器的功能和界面进行测试【任务描述】 对Windows操作系统自带的计算器的功能实现情况和

18、用户界面进行测试,检验计算器的功能和界面是否符合规格说明书。 【任务实施】1设计软件测试用例(1)功能测试用例设计。 计算器的功能测试用例如表1-2所示。 (2)用户界面测试用例设计。 计算器的用户界面测试用例如表1-3所示。测试用例编号测试范围测试用例预期输出calcTest11窗口界面窗体大小、控件布局、前景与背景颜色合理calcTest12快速或慢速移动窗体背景及窗体本身刷新正确calcTest13改变屏幕显示分辨率显示正常calcTest14菜单界面菜单功能齐全且能正确执行calcTest15菜单的快捷命令方式合适calcTest16菜单文本的字体、大小和格式合适calcTest17菜

19、单名称具有自解释性calcTest18菜单标题简明、有意义calcTest19命令按钮命令按钮的标识与操作响应一致calcTest20单击命令按钮响应操作正确calcTest21非法的运算式给出对应的提示信息calcTest22文本框显示运算结果与提示信息正确表1-3计算器的用户界面测试用例2执行软件测试与分析测试结果 (1)执行功能测试。 Windows操作系统自带的计算器运行外观如图1-2所示。图1-2Windows操作系统自带计算器的运行外观续表 (2)执行用户界面测试。 计算器用户界面的测试过程如表1-5所示。测试顺序测试范围测试内容测试方法测试结论11窗口界面窗体大小、控件布局、前景

20、与背景颜色目测合格12快速或慢速移动窗体移动操作、目测合格13改变屏幕显示分辨率操作、目测合格14菜单界面菜单功能操作、目测合格15菜单的快捷命令方式目测合格16菜单文本的字体、大小和格式目测合格17菜单名称目测合格18菜单标题目测合格19命令按钮命令按钮的标识与操作响应操作、目测合格20单击命令按钮响应操作操作、目测合格21非法的运算式操作、目测合格22文本框显示运算结果与提示信息操作、目测合格表1-5计算器用户界面的测试过程【任务1-2】应用场景法对ATM机进行黑盒测试【任务描述】 ATM机操作用例如图1-3所示,假设某银行的ATM机内目前的现金为5000元,卡号尾数为468596的银行卡

21、的账面金额为600元,该银行卡的密码为123456,应用场景法设计测试用例,对ATM机的密码验证功能和取款功能进行测试。 图1-3ATM机操作用例图【任务实施】1设计软件测试用例 (1)分析ATM机取款的基本流和备选流。 ATM机取款的基本流和备选流如表1-6所示。流的类型流的描述基本流正常的取款备选流备选流1ATM机内没有现金备选流2ATM机内现金不足备选流3密码有误(限制3次输入机会)备选流4账户不存在或账户类型有误备选流5账户余额不足表1-6 ATM机取款的基本流和备选流 (2)分析设计场景。 ATM机取款的场景设计如表1-7所示。场景编号场景名称流场景1成功取款基本流场景2ATM机内没

22、有现金基本流备选流1场景3ATM机内现金不足基本流备选流2场景4密码有误(第1次密码错误)基本流备选流3场景5密码有误(第2次密码错误)基本流备选流3场景6密码有误(第3次密码错误)基本流备选流3场景7账户不存在或账户类型有误基本流备选流4场景8账户余额不足基本流备选流5表1-7ATM机取款的场景设计 (3)构造测试用例设计矩阵。 表1-7中的8个场景中的每个都需要确定测试用例,可以采用矩阵或决策表来确定和管理测试用例。 用例编号场景密码账号输入或选择的金额账面金额ATM机内的现金预期结果bankCardTest01场景1vvvvv成功取款bankCardTest02场景2vvvvi取款功能不

23、可用bankCardTest03场景3vvvvi警告重新输入取款金额bankCardTest04场景4ivnvv警告重新输入密码bankCardTest05场景5ivnvv警告重新输入密码bankCardTest06场景6ivnvv警告没有机会重新输入密码bankCardTest07场景7niniv警告账户不能用bankCardTest08场景8vvviv警告账户余额不足表1-8测试用例设计矩阵2执行软件测试与分析测试结果 确定了测试用例,就应对这些用例进行复审和验证以确保其准确且适用,并取消多余或等效的测试用例。 测试顺序场景密码账号输入或选择的金额账面金额ATM机内的现金操作结果测试结论1场景11234564685962006005000成功取款200元,账户余额为400元合格2场景212

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论