范文一:软件测试基本理论
软件测试基本理论 2007-10-20 16:52
分类:求职就业 字号: 大大? 中中? 小小 软件工程模型
谈起测试学,不得不讨论一下软件工程模型,因为测试学与软件工程学的发展依依相关,相辅相成。另外对于比较先进的测试理念,测试工程师应该贯穿于软件工程的整体过程之中。
瀑布模型
这个模型大概是现在最经典的软件工程模型,业务建模-〉系统分析-〉概要设计-〉详细设计-〉编码-〉测试-〉部署。
但是这个模型存在着比较严重的问题:
1,不可反复,不适应与需求变更处理:由于瀑布模型从业务建模到部署一脉相承,不可以回复。现代软件项目中需求变更是无处不存在的:唯一不变的就是需求变更。而运用这种模型,只要项目需求发生变化,就要打翻重新进行系统分析,概要设计,详细设计…
2,用户很难在项目初期了解项目状态:由于用户在项目初期很难提出自己的需求,他们有时候也不知道该做些啥?而利用瀑布模型只有到编码结束,用户才可以看到正正他们所需要的产品,而初期这些产品往往是他们所了解不全的,需要补充的,客户往往在这个时期推翻他们的需求,要求另立需求,这样往往给客户方,需求方带来比较麻烦的结果。
迭代模型和螺旋模型:
这两个模型往往在概念上区别不明显,许多书上将这两个模型混为一谈。其实这两个模型的思想本质上是一致的。他将客户的需求按照用户的重要等级和模块自身的等级,从最基础的进行分析,设计,编码,测试,然后再进入下一轮迭代。这样用户可以在每一轮结束就可以看到产品的一些雏形,进行需求变更和下一轮的建议,由于初期开发工作比较少,用户又可以在产品初期提出相对可观的下一轮的需求,所以这样的模型往往利于现在软件公司产品的开发,著名的RUP工具每一项都遵循迭代的思想。
测试模型
V模型
单元测试--编码
集成测试--详细设计
系统测试--总体设计
接收测试--产品
单元测试相对于编码进行,这一步往往由测试人员来执行;
集成测试相对于详细设计,他将模块由上到下,由下到上进行逐步的集成。以测试模块与模块,类与类之间的关联性;
系统测试是相对于总体设计而言的,测试人员站在用户的角度对系统进行全面的测试工作;
接收测试是用户对产品进行测试,一般分为Alpha测试和Beta测试。Alpha测试一般由公司内部的非技术人员或非参与人员对产品进行的测试;Beta测试往往是指定客户对公司进行测试,是系统推出市场之前,测试阶段推出的第二个版本。
V模型可以运用于瀑布模型和迭代模型
X模型
X模型是将软件系统分为若干模块,对每个模块进行单元,集成以及系统测试,然后统一对模块进行集成测试,这种测试方法目前软件行业处于淘汰趋势。
前置模型
图示中所列出的是面向对象的前置模型,其他编成方法的前置模型大小意,就是将测试贯穿于软件开发的全部过程。在需求,设计和编码阶段对产生的工件进行复审,提出自己的建议和意见。对于前置软件测试法,bug在软件前期就可以发现从而降低软件开发成本。
不利用前置方法的bug曲线。
利用前置方法的bug曲线,bug在开始之前就能够被发现。
软件测试方法
白盒 黑盒
动态? 就是利用KDE的调试功能逐步调试程序,进行测试? 就是普通所说的通过人工或者自动方法进行测试
静态 即test review? 就是对需求,设计工件进行审核
软件测试步骤
测试计划
书写测试用例
开发测试代码
开展测试工作(往往需要进行几次轮测包括测试和复测,每次对于测试中的bug,要求开发人员给与明确答复修改完毕,非法bug以及下一版中解决)
2 评估测试
软件测试类型
1.数据和数据库完整性测试
在项目名称中,数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时,不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS),还需要进行深入的研究,以确定可以支持以下测试的工具和技术。
2.功能测试
对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面 (GUI) 与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要:
3.UI测试
用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外,UI 测试还可确保 UI 中的对象按照预期的方式运行,并符合公司或行业的标准。包括用户友好性,人性化测试。
4.性能测试
4.1负载测试:
负载测试是一种性能测试。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。
4.2强度测试
是一种性能测试,实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
4.3容量测试
容量测试使测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如,如果测试对象正在为生成一份报表而处理一组数据库记录,那么容量测试就会使用一个大型的测试数据库,检验该软件是否正常运行并生成了正确的报表。
4.4基准测试
与已知系统的比较
4.5竞争测试
软件竞争使用各种资源(数据纪录,内存等)
5. 安全性和访问控制测试
安全性和访问控制测试侧重于安全性的两个关键方面:
应用程序级别的安全性,包括对数据或业务功能的访问
系统级别的安全性,包括对系统的登录或远程访问。
应用程序级别的安全性可确保:在预期的安全性情况下,主角只能访问特定的功能或用例,或者只能访问有限的数据。例如,可能会允许所有人输入数据,创建新账户,但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性,测试就可确保“用户类型一” 能够看到所有客户消息(包括财务数据),而“用户二”只能看见同一客户的统计数据。
系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问。
6.故障转移和恢复测试
可确保测试对象能成功完成故障转移,并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
故障转移测试可确保:对于必须持续运行的系统,一旦发生故障,备用系统就将不失时机地“顶替”发生故障的系统,以避免丢失任何数据或事务。
恢复测试是一种对抗性的测试过程。在这种测试中,将把应用程序或系统置于极端的条件下(或者是模拟的极端条件下),以产生故障(例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字)。然后调用恢复进程并监测和检查应用程序和系统,核实应用程序或系统和数据已得到了正确的恢复。
7.配置测试
配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。(如浏览器版本。OS版本等)
8.安装测试
安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如,进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。
9.本地化测试
又称本地化测试,是指为各个地方开发产品的测试,如英文版,中文版等等,包括程序是否能够正常运行,界面是否符合当地习俗,快捷键是否正常起作用等等,特别测试在A语言环境下运行B语言软件(比如在英文win98下试图运行中文版的程序),出现现象是否正常。
10.文字测试
测试文字是否拼写正确,是否易懂,不存在二义性,没有语法错误;文字与内容是否由出入等等,包括图片文字
11.分辨率测试
测试在不同分辨率下,界面的美观程度,分为800*600,1024*768,1152*864,1280*768,1280*1024,1200*1600大小字体下测试
12发布测试
主要在产品发布前对一些附带产品,比如说明书,广告稿等进行测试
12.1说明书测试
主要为语言检查,功能检查,图片检查
语言检查:检查说明书语言是否正确,用词是否易于理解;
功能检查:功能是否描述完全,或者描述了并没有的功能等;
图片检查::检查图片是否正确
12.2宣传材料测试
主要测试产品中的附带的宣传材料中的语言,描述功能,图片
12.3帮助文件测试
帮助文件是否正确,易懂,是否人性化
12.4广告用语
产品出公司前的广告材料文字,功能,图片,人性化的检查
软件测试曲线
大家都知道软件的bug是不可能为零的,它一般随着时间的推移bug数逼近于零,用一个曲线图表示:
这里横坐标是时间,纵坐标是还没有发现的bugs数。项目开始之前bug为无穷大,随着时间的推移,bug趋于零但是不会等于零。
由于bug不会等于零,难道产品就不发布了吗?还有一种bug可以确定产品发布时间。
横坐标为时间,纵坐标是已经发现的bugs数,当这个曲线趋于平稳,也就是说它的斜率趋于零的时候,这个产品就可以发布了。
软件的杀虫剂现象
由于测试人员的思路不尽相同,每个人测试的侧重点不同,由于都按照测试用例进行测试,但是测试用例一般仅描述系统的一些基本测试项,不会将所有的测试用例方方面面都写到,有时还需要测试人员的经验和素质。所以A测试某个产品用了七个工作日,第一天到第四天报出许多bug,但从第五天开始几乎报不出啥 bug了。七天后换了B,B一下子又测试出一堆bug,不能说A的水平差,只能说,该产品已经对A产生了抗药性,这就是测试学中的杀虫剂现象。用图表示:
所以在测试中每次轮流测试最好安排不同的测试人员进行不同模块测试工作,以避免杀虫剂现象产生。
范文二:软件测试基本理论
软件测试基本理论 软件测试概念:通过各种手段和测试工具,判断软件系统是否能够满足预期期望。 从软件开发的过程按阶段划分有
A.单元测试 B.集成测试 C.确认测试 D.系统测试 E.验收测试
* 测试过程按4个步骤进行,即单元测试、集成测试、确认测试和系统测试及发版测试。 * 开始是单元测试,集中对用源代码实现的每一个程序单元进行测试,检查各个程序模块是否正确地实现了规定的功能。
* 集成测试把已测试过的模块组装起来,主要对与设计相关的软件体系结构的构造进行测试。
* 确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求,以及软件配置是否完全、正确。
* 系统测试把已经经过确认的软件纳入实际运行环境中,与其它系统成份组合在一起进行测试。
单元测试 (Unit Testing)
* 单元测试又称模块测试,是针对软件设计的最小单位 — 程序模块,进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。
* 单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
1. 单元测试的内容
* 在单元测试时,测试者需要依据详细设计说明书和源程序清单,了解该模块的I/O条件和模块的逻辑结构,主要采用白盒测试的测试用例,辅之以黑盒测试的测试用例,使之对任何合理的输入和不合理的输入,都能鉴别和响应。
(1) 模块接口测试
* 在单元测试的开始,应对通过被测模块的数据流进行测试。测试项目包括: – 调用本模块的输入参数是否正确;
– 本模块调用子模块时输入给子模块的参数是否正确;
– 全局量的定义在各模块中是否一致;
* 在做内外存交换时要考虑:
– 文件属性是否正确;
– OPEN与CLOSE语句是否正确;
– 缓冲区容量与记录长度是否匹配;
– 在进行读写操作之前是否打开了文件;
– 在结束文件处理时是否关闭了文件;
– 正文书写/输入错误,
– I/O错误是否检查并做了处理。
(2) 局部数据结构测试
* 不正确或不一致的数据类型说明
* 使用尚未赋值或尚未初始化的变量
* 错误的初始值或错误的缺省值
* 变量名拼写错或书写错
* 不一致的数据类型
* 全局数据对模块的影响
(3) 路径测试
* 选择适当的测试用例,对模块中重要的执行路径进行测试。
* 应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。
* 对基本执行路径和循环进行测试可以发现大量的路径错误。
(4) 错误处理测试
* 出错的描述是否难以理解
* 出错的描述是否能够对错误定位
* 显示的错误与实际的错误是否相符
* 对错误条件的处理正确与否
* 在对错误进行处理之前,错误条件是否已经引起系统的干预等
(5) 边界测试
* 注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例,认真加以测试。
* 如果对模块运行时间有要求的话,还要专门进行关键路径测试,以确定最坏情况下和平均意义下影响模块运行时间的因素。
2. 单元测试的步骤
* 模块并不是一个独立的程序,在考虑测试模块时,同时要考虑它和外界的联系,用一些辅助模块去模拟与被测模块相联系的其它模块。
– 驱动模块 (driver)
– 桩模块 (stub) —— 存根模块
* 如果一个模块要完成多种功能,可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作,对关键模块还要做性能测试。
* 对支持某些标准规程的程序,更要着手进行互联测试。有人把这种情况特别称为模块测试,以区别单元测试。
集成测试(Integrated Testing)
* 集成测试 (集成测试、联合测试)
* 通常,在单元测试的基础上,需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是:
– 在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失;
– 一个模块的功能是否会对另一个模块的功能产生不利的影响;
– 各个子功能组合起来,能否达到预期要求的父功能;
– 全局数据结构是否有问题;
– 单个模块的误差累积起来,是否会放大,从而达到不能接受的程度。
在单元测试的同时可进行集成测试,
发现并排除在模块连接中可能出现
的问题,最终构成要求的软件系统。
* 子系统的集成测试特别称为部件测试,它所做的工作是要找出集成后的子系统与系统需求规格说明之间的不一致。
* 通常,把模块集成成为系统的方式有两种
– 一次性集成方式
– 增殖式集成方式
1. 一次性集成方式(big bang)
* 它是一种非增殖式组装方式。也叫做整体拼装。
* 使用这种方式,首先对每个模块分别进行模块测试,然后再把所有模块组装在一起进行测试,最终得到要求的软件系统。
2. 增殖式集成方式
* 这种集成方式又称渐增式集成
* 首先对一个个模块进行模块测试,然后将这些模块逐步组装成较大的系统
* 在集成的过程中边连接边测试,以发现连接过程中产生的问题
* 通过增殖逐步组装成为要求的软件系统。
(1) 自顶向下的增殖方式
* 这种集成方式将模块按系统程序结构,沿控制层次自顶向下进行组装。
* 自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。
* 选用按深度方向组装的方式,可以首先实现和验证一个完整的软件功能。
(2) 自底向上的增殖方式
* 这种集成的方式是从程序模块结构的最底层的模块开始集成和测试。
* 因为模块是自底向上进行组装,对于一个给定层次的模块,它的子模块(包括子模块的所有下属模块)已经组装并测试完成,所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。
* 自顶向下增殖的方式和自底向上增殖的方式各有优缺点。
* 一般来讲,一种方式的优点是另一种方式的缺点。
(3) 混合增殖式测试
* 衍变的自顶向下的增殖测试
– 首先对输入/输出模块和引入新算法模块进行测试;
– 再自底向上组装成为功能相当完整且相对独立的子系统;
– 然后由主模块开始自顶向下进行增殖测试。
* 自底向上-自顶向下的增殖测试
– 首先对含读操作的子系统自底向上直至根结点模块进行组装和测试;
– 然后对含写操作的子系统做自顶向下的组装与测试。
* 回归测试
– 这种方式采取自顶向下的方式测试被修改的模块及其子模块;
– 然后将这一部分视为子系统,再自底向上测试。
关键模块问题
* 在组装测试时,应当确定关键模块,对这些关键模块及早进行测试。
* 关键模块的特征:
① 满足某些软件需求;
② 在程序的模块结构中位于较高的层次(高层控制模块);
③ 较复杂、较易发生错误;
④ 有明确定义的性能要求。
确认测试(Validation Testing)
* 确认测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
* 对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。
1. 进行有效性测试(黑盒测试)
* 有效性测试是在模拟的环境 (可能就是开发的环境) 下,运用黑盒测试的方法,验证被测软件是否满足需求规格说明书列出的需求。
* 首先制定测试计划,规定要做测试的种类。还需要制定一组测试步骤,描述具体的测试用例。
* 通过实施预定的测试计划和测试步骤,确定
– 软件的特性是否与需求相符;
– 所有的文档都是正确且便于使用;
– 同时,对其它软件需求,例如可移植性、兼容性、出错自动恢复、可维护性等,也都要进行测试
* 在全部软件测试的测试用例运行完后,所有的测试结果可以分为两类:
– 测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合,从而这部分程序被接受。
– 测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致,因此要为它提交一份问题报告。
2. 软件配置复查
n 软件配置复查的目的是保证
u 软件配置的所有成分都齐全;
u 各方面的质量都符合要求;
u 具有维护阶段所必需的细节;
u 而且已经编排好分类的目录。
n 应当严格遵守用户手册和操作手册中规定的使用步骤,以便检查这些文档资料的完整性和正确性。
验收测试(Acceptance Testing)
* 在通过了系统的有效性测试及软件配置审查之后,就应开始系统的验收测试。 * 验收测试是以用户为主的测试。软件开发人员和QA(质量保证)人员也应参加。 * 由用户参加设计测试用例,使用生产中的实际数据进行测试。
* 在测试过程中,除了考虑软件的功能和性能外,还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。
* 确认测试应交付的文档有:
– 确认测试分析报告
– 最终的用户手册和操作手册
– 项目开发总结报告。
系统测试(System Testing)
* 系统测试,是将通过确认测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起,在实际运行环境下,对计算机系统进行一系列的组装测试和确认测试。
* 系统测试的目的在于通过与系统的需求定义作比较, 发现软件与系统的定
义不符合或与之矛盾的地方。
软件工程模型
谈起测试学,不得不讨论一下软件工程模型,因为测试学与软件工程学的发展依依相关,相辅相成。另外对于比较先进的测试理念,测试工程师应该贯穿于软件工程的整体过程之中。 瀑布模型
这个模型大概是现在最经典的软件工程模型,业务建模-〉系统分析-〉概要设计-〉详细设计-〉编码-〉测试-〉部署。
但是这个模型存在着比较严重的问题:
1,不可反复,不适应与需求变更处理:由于瀑布模型从业务建模到部署一脉相承,不可以回复。现代软件项目中需求变更是无处不存在的:唯一不变的就是需求变更。而运用这种模型,只要项目需求发生变化,就要打翻重新进行系统分析,概要设计,详细设计… 2,用户很难在项目初期了解项目状态:由于用户在项目初期很难提出自己的需求,他们有时候也不知道该做些啥?而利用瀑布模型只有到编码结束,用户才可以看到正正他们所需要的产品,而初期这些产品往往是他们所了解不全的,需要补充的,客户往往在这个时期推翻他们的需求,要求另立需求,这样往往给客户方,需求方带来比较麻烦的结果。 迭代模型和螺旋模型:
这两个模型往往在概念上区别不明显,许多书上将这两个模型混为一谈。其实这两个模型的思想本质上是一致的。他将客户的需求按照用户的重要等级和模块自身的等级,从最基础的进行分析,设计,编码,测试,然后再进入下一轮迭代。这样用户可以在每一轮结束就可以看到产品的一些雏形,进行需求变更和下一轮的建议,由于初期开发工作比较少,用户又可以在产品初期提出相对可观的下一轮的需求,所以这样的模型往往利于现在软件公司产品的开发,著名的RUP工具每一项都遵循迭代的思想。
测试模型
V模型
单元测试相对于编码进行,这一步往往由测试人员来执行;
集成测试相对于详细设计,他将模块由上到下,由下到上进行逐步的集成。以测试模块与模块,类与类之间的关联性;
系统测试是相对于总体设计而言的,测试人员站在用户的角度对系统进行全面的测试工作;
接收测试是用户对产品进行测试,一般分为Alpha测试和Beta测试。Alpha测试一般由公司内部的非技术人员或非参与人员对产品进行的测试;Beta测试往往是指定客户对公司进行测试,是系统推出市场之前,测试阶段推出的第二个版本。
V模型可以运用于瀑布模型和迭代模型
X模型
X模型是将软件系统分为**模块,对每个模块进行单元,集成以及系统测试,然后统一对模块进行集成测试,这种测试方法目前软件行业处于淘汰趋势。
前置模型
图示中所列出的是面向对象的前置模型,其他编成方法的前置模型大小意,就是将测试贯穿于软件开发的全部过程。在需求,设计和编码阶段对产生的工件进行复审,提出自己的建
议和意见。对于前置软件测试法,bug在软件前期就可以发现从而降低软件开发成本。 不利用前置方法的bug曲线。
利用前置方法的bug曲线,bug在开始之前就能够被发现。
软件测试方法
测试计划
书写测试用例
开发测试代码
开展测试工作(往往需要进行几次轮测包括测试和复测,每次对于测试中的bug,要求开发人员给与明确答复修改完毕,非法bug以及下一版中解决)
2 评估测试
软件测试类型
1.数据和数据库完整性测试
在项目名称中,数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时,不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS),还需要进行深入的研究,以确定可以支持以下测试的工具和技术。
2.功能测试
对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面 (GUI) 与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要:
3.UI测试
用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外,UI 测试还可确保 UI 中的对象按照预期的方式运行,并符合公司或行业的标准。包括用户友好性,人性化测试。
4.性能测试
4.1负载测试:
负载测试是一种性能测试。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。
4.2强度测试
是一种性能测试,实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺
陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
4.3容量测试
容量测试使测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如,如果测试对象正在为生成一份报表而处理一组数据库记录,那么容量测试就会使用一个大型的测试数据库,检验该软件是否正常运行并生成了正确的报表。
4.4基准测试:与已知系统的比较
4.5竞争测试
软件竞争使用各种资源(数据纪录,内存等)
5. 安全性和访问控制测试
安全性和访问控制测试侧重于安全性的两个关键方面:
应用程序级别的安全性,包括对数据或业务功能的访问
系统级别的安全性,包括对系统的登录或远程访问。
应用程序级别的安全性可确保:在预期的安全性情况下,主角只能访问特定的功能或用例,或者只能访问有限的数据。例如,可能会允许所有人输入数据,创建新账户,但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性,测试就可确保―用户类型一‖ 能够看到所有客户消息(包括财务数据),而―用户二‖只能看见同一客户的统计数据。
系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问。
6.故障转移和恢复测试
可确保测试对象能成功完成故障转移,并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
故障转移测试可确保:对于必须持续运行的系统,一旦发生故障,备用系统就将不失时机地―顶替‖发生故障的系统,以避免丢失任何数据或事务。
恢复测试是一种对抗性的测试过程。在这种测试中,将把应用程序或系统置于极端的条件下(或者是模拟的极端条件下),以产生故障(例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字)。然后调用恢复进程并监测和检查应用程序和系统,核实应用程序或系统和数据已得到了正确的恢复。
7.配置测试
配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。(如浏览器版本。OS版本等)
8.安装测试
安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如,进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。
9.本地化测试
又称本地化测试,是指为各个地方开发产品的测试,如英文版,中文版等等,包括程序是否能够正常运行,界面是否符合当地习俗,快捷键是否正常起作用等等,特别测试在A语言环境下运行B语言软件(比如在英文win98下试图运行中文版的程序),出现现象是否正常。
10.文字测试
测试文字是否拼写正确,是否易懂,不存在二义性,没有语法错误;文字与内容是否由出入等等,包括图片文字
11.分辨率测试
测试在不同分辨率下,界面的美观程度,分为800*600,1024*768,1152*864,1280*768,1280*1024,1200*1600大小字体下测试
12发布测试
主要在产品发布前对一些附带产品,比如说明书,广告稿等进行测试
12.1说明书测试 主要为语言检查,功能检查,图片检查 语言检查:检查说明书语言是否正确,用词是否易于理解; 功能检查:功能是否描述完全,或者描述了并没有的功能等; 图片检查::检查图片是否正确
12.2宣传材料测试
主要测试产品中的附带的宣传材料中的语言,描述功能,图片
12.3帮助文件测试
帮助文件是否正确,易懂,是否人性化
软件的杀虫剂现象 由于测试人员的思路不尽相同,每个人测试的侧重点不同,由于都按照测试用例进行测试,但是测试用例一般仅描述系统的一些基本测试项,不会将所有的测试用例方方面面都写到,有时还需要测试人员的经验和素质。所以A测试某个产品用了七个工作日,第一天到第四天报出许多bug,但从第五天开始几乎报不出啥 bug了。七天后换了B,B一下子又测试出一堆bug,不能说A的水平差,只能说,该产品已经对A产生了抗药性,这就是测试学中的杀虫剂现象。 所以在测试中每次轮流测试最好安排不同的测试人员进行不同模块测试工作,以避免杀虫剂现象产生。
1.什么是测试?
IEEE定义:使用人工或自动化来测试某个程序,来验证它是否满足规定的需求或者实际结果和预期结果之间的差别.
简单定义:找出软件中的BUG
2.为什么要测试?
在软件开发过程中容易出现缺乏有效沟通,软件复杂,编程错误,需求不断变更,时间的压力,缺乏文档的代码,软件开发工具和人员的自大等原因引发的错误,通过测试能够找出其中的错误,解决错误,从而提高软件的质量.
3.测试的目的是什么?
证明软件没有问题(20世纪60年代)
发现软件中的错误(20世纪70年代)
验证软件与需求是否一致的一系列活动(现在) 提高软件质量
4.软件的生命周期分为哪几个阶段?具体的内容是什么?
计划:确定软件开发总目标;给出软件各方面的设想;研究可行性和解决方案;给出评估计划;指定完整的实施计划
需求分析:对开发软件进行详细定义,给出《需求规格说明书》SRS
设计:在设计阶段把各项需求转换成相应的体系结构,给出概要设计
编码:将软件设计成计算机能识别的语言,给出《详细设计》
测试:检测软件是否符合用户需求
运行:将软件交付给用户使用
评价:用户对软件的好与坏给出判定
5.研发团队的组织架构与研发流程是什么?
瀑布模型 螺旋模型 RUP模型 IPD 模型
6.测试阶段怎么划分?
测试计划阶 段测试设计阶 段测试实施阶 段测试执行阶段
7.什么是UT,IT,ST?它们有什么区别?
单元测试:对软件的基本组成单元来进行正确性检验,目的在于检测软件模块对《详细设计说明书》的符合程度,属于白盒测试,
测试范围为单元内部的数据结构,逻辑控制,异常处理
评估标准为逻辑覆盖率
集成测试:测试模块或子系统组装后功能以及模块间接口是否正确,目的在于检测软件模块对《概要设计说明书》的符合程度。
属于灰盒测试,测试范围为模块之间接口与接口数据传递的关系,以及模块组合后的功能,
评估标准为接口覆盖率
系统测试:将被测软件系统和计算机硬件,数据库,外设,人员以及其它软件结合在一起,在实际运行环境下对计算机系统进行的一系列的组装测试和确认测试。
目的在于检测软件对《需求规格说明书》的符合程度。属于黑盒测试,测试范围为整个系统,
评估标准为测试用例对需求规格的覆盖率
8.什么是回归测试?为什么要回归测试?回归测试的流程是什么?回归测试的测试策略有哪些?
回归测试:是软件维护阶段,对缺陷进行修复后的测试。
目的在于:验证缺陷已经得到修复,检测是否引入新的缺陷
流程:1.在测试策略制定阶段,制定回归测试策略
2.确定需要回归测试的版本
3.测试版本发布后,按照回归测试策略来执行回归测试
4.回归测试通过,关闭缺陷跟踪单
5.回归测试不通过,缺陷跟踪单返回给开发人员,开发人员重新修改BUG.再次提交给测试人员回归测试
测试策略:1.完全重复测试:重新执行前期设计的用例,来确认问题修改的真确性和修改的扩散局部影响性
2.选择性重复测试:
1)覆盖修改法:针对被修改的部分,选取或重新构造测试用例验证没有错误再次发生的选择方法
2)周边影响法:该方法包括覆盖修改法,还要分析修改后对扩散的影响
3)指标达成法:先确定一个达成的指标,基于这种要求选择一个最小的测试用例集合
13.测试的方法有哪些?
按是否使用工具:人工测试 自动化测试
按软件是否运行:静态测试 动态测试
按测试的重点:白盒测试 黑盒测试 灰盒测试
14.什么是白盒测试?
依据被测软件分析程序内部构造,并根据内部构造设计用例,来对内部控制流程进行测试。
15.什么是黑盒测试?
把测试对象看做一个黑盒,只考虑整体特性,不考虑内部具体实现
16.什么是静态测试?
不运行被测软件系统,而采用其他手段和技术对被测软件进行检测的一种技术
17.什么是动态测试?
运行被测软件系统的测试
18.什么是人工测试?
测试活动由人来完成,狭义上指测试执行由人工完成。
19.什么是自动化测试?
通过计算机模拟人的测试行为,替代人的测试活动,狭义上指测试执行由计算机来完成
20.逻辑覆盖关注的内容是哪些?
逻辑覆盖测试
语句覆盖 条件覆盖 判定覆盖 路径覆盖 判定-条件覆盖
21.常见的黑盒测试方法有哪些?
等价类划分法 边界值分析法 因果图分析法 判定表法 正交试验法 状态迁移法
25. 什么是缺陷管理?引入的原因有哪些?
缺陷管理的目的: 保证信息的一致性;保证缺陷得到有效跟踪,解决;
获取正确的Bug信息,用作缺陷分析和产品度量。
引入原因:
1.开发过程中缺乏有效沟通,或者没有沟通 2.软件负责度越来越高
3.编程中产生的错误 4.需求不断变更 5.项目进度的压力
6.不重视开发文档 7.软件开发工具本身隐藏的问题
33.系统测试的类型有哪些?
1.功能测试
概念:根据产品的需求规格说明书和测试需求列表,验证产品的功能实现是否符合产品需求规格
目标:1.是否有遗漏需求。2.是否正确的实现所有功能
3.隐示需求在系统是否实现 4.输入,输出是否正确
2.性能测试
概念: 用来测试软件在集成系统中的运行性能
目标: 度量系统相对于预定义目标的差距
3.压力测试
压力测试:在一定的软硬件及网络环境中,通过模拟大量的用户执行多种业务处理大量数据,使系统在极限环境下长时间运行,目的在于寻找系统的失效点
负载测试:在一定的软硬件及网络环境下,通过模拟不同的用户,执行一种或多种业务,
观察系统在不同负载下的性能表现。
目标: 通过极限测试方法,发现系统在极限或恶劣的环境中自我保护能力,主要验证系统的可靠性
4.容量测试
概念: 使系统承受超额的数据容量来发现它是否能够正确处理
目标:是面向数据的,显示系统可以处理目标内确定的数据容量
5.安全性测试
概念:用来验证集成在系统内的保护机制是否能够在实际中保护系统不受非法的侵入。 目标:通过安全性测试,来检查系统的功能性是否完善
6.GUI测试
概念:指界面的外形是否与设计内容一致
7.可用性测试
概念:检测用户在理解和使用系统方面到底有多好?
8.安装测试
概念: 检测软件在安装过程中的错误
目标:不仅仅找安装软件本身的错误,还要找到安装文档的错误。
9.配置测试
概念: 测试系统在各种软硬件配置,不同的参数配置下系统具有的功能和性能
目标:验证全部配置的可操作性和有效性,特别需要对最大配置,最小配置和特殊配置进行测试
10.异常测试(恢复性测试)
通过人工干预手段使系统发生软,硬件异常,通过验证系统异常前后的功能和运行状态,达到检验系统容错,排错和恢复的能力
11.备份测试
验证系统在软件或者硬件的事件中备份它数据的能力
12.健壮性测试
用于测试系统在出现故障时,是否能够自动恢复或忽略故障继续运行
13.文档测试
验证用户文档是否正确的并且保证操作手册的过程能够正确工作
14.在线帮助测试
验证系统的实时在线帮助的可用性和正确性
15.网络测试
在网络环境下和其他设备对接,进行系统功能,性能与指标方面的测试,保证设备对接正常
16.稳定性测试
评价系统在一定负荷情况下,长时间的运行情况
范文三:软件测试基本理论
软件测试应掌握的一些理论知识:
1.什么是测试?
使用人工和自动手段运行或检测软件系统,其目的是为了检验它是否满足实际的需求,弄清
预期结果与实际结果之间的差别。
2.为什么要测试?
在软件开发过程中由于缺乏有效的沟通、软件复杂度高、编程错误、不断变更的需求、项目
进度的压力、不重视文档的开发、软件开发人员的自大等原因造成软件开发过程中出现错误,
进行软件测试可以找出错误,解决错误,提高软件的质量。
3.测试的目的是什么?
证明:表明软件是正确的
检测:发现存在的错误
预防:管理质量
4.软件的生命周期分为哪几个阶段?具体的内容是什么?
软件生命周期分6个阶段:
Planning计划:确定软件开发的总目标
给出软件方面的设想
研究可行性和解决方案
给出评估计划
指定完整的实施计划
Requirement Analysis需求分析:对开发软件进行详细定义,给出《需求规格说明书》SRS
Design设计:在设计阶段把各项需求转换成相应的体系结构,给出《概要设计说明书》HLD
Coding程序编码:将软件设计转换成计算机能识别的语言,给出《详细设计说明书》LLD
Testing测试:检测软件是否符合用户需求
Run and Maintenance运行和维护:用户对软件的好与坏给出判定
5.研发团队的组织架构与研发流程是什么?
研发团队的组织架构:
软件开发组:开发经理、分析人员、设计人员、开发人员
软件测试组:测试经理、测试人员
配置管理组:配置管理经理、CMO
研发流程:
瀑布模型、螺旋模型、RUP流程、IPD流程
6.测试阶段怎么划分?
①、组织内部人员实施:单元测试、集成测试、系统测试、回归测试
②、其他用户实施:验收测试、alpha测试、beta测试
7.什么是UT,IT,ST?它们有什么区别?
UT--定 义:软件最基本单元正确性的检测
目 的:检测软件模块与《详细设计说明书》LLD的符合程度
方 法:白盒测试
评估标准:逻辑覆盖率
考察范围:被测软件内部数据结构、逻辑控制、异常处理
IT--定 义:测试模块与子系统组合后的功能及模块间接口的是否正确
目 的:检测软件模块与《概要设计说明书》HLD的符合程度
方 法:灰盒测试
评估标准:接口覆盖率
考察范围:软件模块接口与接口数据传递的关系,以及模块组合后的整体功能
ST--定 义:将被测软件系统与计算机硬件、外设、人员和计算机软件结合在一起,在实
现运行环境下,对被测软件系统进行组装测试和确认测试。
目 的:通过与系统需求定义比较,发现软件与需求定义不符合或与之相矛盾的地方。
方 法:黑盒测试
评估标准:需求覆盖率
考察范围:软件系统对需求的符合程度
8.什么是回归测试?为什么要回归测试?回归测试的流程是什么?回归测试的测试策略有
哪些?
软件在测试或者其他活动中发现的缺陷修改后进行的测试。
回归测试的目的:
①、验证缺陷得到了正确的修复。
②、验证对系统的变更没有影响到以前的功能。
回归测试的策略:
①、 完全重复测试:
②、 选择性重复测试:覆盖测试法、周边影响法、指标达成法
回归测试的流程:
①、在测试策略制定阶段,制定回归测试策略
②、确定回归测试版本
③、回归测试版本发布,按照回归测试策略执行回归测试用例
④、回归测试通过,关闭缺陷跟踪单
⑤、回归测试不通过,将缺陷跟踪单返回开发人员,开发人员重新修改问题,再次提交测试人员进行回归测试
9.画V&V模型?
10.软件质量的定义是什么?影响软件质量的因素是哪些?ISO 2000的八大原则是什么?
ISO关于软件质量的定义:一个实体的所有特性,基于这些特性可以满足显示的和隐含的需
求,而质量就是实体与之这些特性满足需求的程度。
影响软件质量的因素:流程,技术,组织
ISO 2000的八大原则:
①、以顾客为中心
②、领导作用
③、全员参与
④、过程方法
⑤、管理的系统方法
⑥、持续改进
⑦、基于事实的决策方法
⑧、互利的供方关系
11.CMM/CMMI是什么?它的等级怎么划分?有什么目的?有什么作用?
CMM/CMMI:软件能力成熟度模型。是美国软件研究院研究的一种评级软件承包商能力并
帮助改善软件质量的方法。
CMM1:初始级--不可预测,不可控
CMM2:可重复级--可以重复以前的经验
CMM3:已定义级--过程被描述,并被很好的理解
CMM4:已管理级—过程被测量并受控
CMM5:优化级—关注过程改进
目的:
帮助软件企业对软件工程进行管理和改进,增强开发与管理能力,从而能按时的,不超预算的生产高质量的软件产品。
作用:
①、评估组用来评价组织的强除和弱点
②、评价组用来识别和选择软件承包商的风险和监督作用
③、管理者用来了解组织的能力,并了解为了提高能力成熟度进行软件过程改进所需要进行的活动
④、技术人员和过程改进组作为指南,指导他们在组织中定义和改进软件过程
12.描述软件质量模型中的内容?
①、功能性:适合性、准确性、互操作性、保密安全性、功能性的依从性
②、可靠性:成熟性、容错性、易恢复性、可靠性的依从性
③、易用性:易理解性、易学性、易操作性、吸引性、易用性的依从性
④、效率:时间特性、资源利用性、效率依从性
⑤、可维护性:易分析性、易改变性、稳定性、易测试性、维护性的依从性
⑥、可移植性:适应性、易安装性、共存性、易替换性、可移植性的依从性
13.测试的方法有哪些?
黑盒测试、灰盒测试、白盒测试、静态测试、动态测试
14.什么是白盒测试?
依据被测软件,分析内部构造,并根据内部构造设计用例,进行内部控制流程的测试,不考虑程序的整体功能实现情况。
15.什么是黑盒测试?
黑盒测试是把被测软件堪称一个黑盒,只考虑其整体特性,不考虑其内部构造。
16.什么是静态测试?
不运行被测软件,才有其他手段和技术对软件进行检测的一种方式
17.什么是动态测试?
运行被测软件系统的测试。
18.什么是人工测试?
测试活动由人来完成。
19.什么是自动化测试?
通过计算机模拟人的测试。
20.逻辑覆盖关注的内容是哪些?
①、逻辑覆盖测试 ②、语句覆盖 ③、条件覆盖
④、判定覆盖 ⑤、路径覆盖 ⑥、判定-条件覆盖
21.常见的黑盒测试方法有哪些?
等价类划分法,边界值分析法,因果图分析法,判定表法,状态迁移法
22.什么是同行评审?
同行评审:(Peer Review)是一种通过作者的同行来确认缺陷和需要变更区域的检查方法。需要进行同行评审的特定产品在定义项目软件过程的时候被确定并且作为软件开发计划的一部分被安排了进度。
23.自动化测试有什么意义?
提高回归测试效率
减少重复劳动时间
减少软件发布时间
测试脚本可重复利用
24.测试用例的八大要素是什么?
用例编号,测试项目,测试标题,重要级别,预置条件,测试输入,操作步骤,预期输出
25.什么是缺陷管理?引入的原因有哪些?
BUG:
程序缺陷,电脑系统或者程序中存在的任何一种破坏正常运转能力的问题或者缺陷,都叫“BUG”,在实际工作中缺陷、错误和BUG都认为是一样的。
缺陷:
指静态存在于软件工作产品(文档、代码)中的错误,也指软件运行时由于错误被激发引起的和软件产品预期属性的偏离现象。
错误:
指编写错误的代码。语法错误、逻辑错误。
故障:
软件运行中出现的状态,可引起意外情况,若不加处理,可产生失效,是一种动态行为 失效:
软件运行时产生的外部异常行为结果,表现与用户需求不一致,功能能力终止,用户无法完成所需要的应用。
26.缺陷的属性有哪些?
Bug发现人,bug发现时间。Bug的发现状态,bug的严重程度,bug所属版本,bug的修改日期
27.画缺陷管理流程图?
28.如何写缺陷跟踪单?
缺陷跟踪单写作5C原则:
Correct准确:每个组成部分的描述准确,不会引起误会
Clear清晰:每个组成部分的描述清晰,易于理解
Concise简洁:只包含必不可少的信息,不包括任何多余的内容
Complete完整:包含发现缺陷的过程以及其他的本质信息
Consistent一致:按照一致的格式书写全部缺陷报告
29.什么是测试覆盖率?
覆盖率是用来度量测试完整性的一个手段。是对测试覆盖率的一个度量
覆盖率大体可以分为两大类:逻辑覆盖和功能覆盖
30.会计算语句覆盖率,判定覆盖率,条件覆盖率,判定-条件覆盖率,路径覆盖率,指令块覆盖率等。
33.系统测试的类型有哪些?
功能测试、性能测试、压力测试、容量测试、安全性测试、gui测试,可用性测试,安装测试,配置测试,异常测试,健壮性测试,备份测试,文档测试,在线帮助测试,网络测试,稳定性测试
34.系统测试执行的活动有哪些?
搭建系统测试环境、系统测试预测试、转系统测试评审、执行系统测试、编写系统测试报告
35.单元测试目的是什么?
发现各模块内部可能存在的各种错误。检验软件模块与需求规格说明书的符合程度
36.单元测试的关注点是什么?
单元接口 :检测输入输出是否和预期符合、
局部数据接口: 检查代码的正确性,是否存在数据类型不一样,数据未定义就使用等、
独立路径 :查找由于错误计算,不正确的比较或不正常的控制流而导致的错误 出错处理 :对错误程序重新安排,保证逻辑上的正确性、
边界条件 :对于数据边界上的检测,这是比较容易出错的地方
37.什么是驱动?什么是桩?
驱动:用来模拟被测单元的上层单元,相当于被测函数的主程序
桩:用来代替被测单元工作过程中调用的子单元
38.单元测试的测试策略是哪些?各有什么优缺点?
孤立的单元测试策略:
优:方法简单,易操作,是纯粹的单元测试
缺:驱动和桩的数量庞大,效率低
自顶向下的单元测试策略:
优:节省了驱动的工作量,提高了测试效率
缺:随着单元的渐渐加入,测试过程变得复杂了,增加了开发和维护
自底向上的单元测试策略:
优:节省了桩的开发工作量,提高了测试效率
缺:不是纯粹的单元测试,底层的测试质量对上层的测试影响很大
39.什么是集成测试?目的是什么?
在单元测试的基础上,把所有的函数按照《概要设计说明书》要求组装成子系统或系统进行的测试
目的:验证接口是否与设计相符合
发现设计和需求中存在的错误
40.集成测试的关注点是什么?
①、把各个模块连接起来的时候,模块接口的数据是否会丢失
②、各个子功能组合起来,能否达到预期要求的父功能。
③、一个模块的功能是否会对另一个模块的功能产生影响
④、全局数据是否有问题,会不会被异常修改
⑤、单个模块的误差积累起来,是否会放大,从而达到不可接受的程度
41.集成测试的测试策略是哪些?各有什么优缺点?
①、大爆炸集成:
优:方法简单,只要很少的驱动和桩,并可进行工作,对人力,物力资源的利用率高 缺:成功率小,不容易定位,内部接口测试的不充分
②、自顶向下集成:
优:不需要驱动,内部接口测试充分,容易定位,时间控制接口较早的得到测试 缺:需要大量的桩,底层测试比较晚,时间长,并行性差
③、自底向上集成:
点:底层模块较早的得到测试,较少了桩的工作量,并行性比自顶向下集成要好 缺:需要大量的驱动,顶层测试较晚
④、三明治集成:
优:集合了自顶向下和自底向上两种有点
缺:中间部分测试不充分
⑤、基干集成
优:具有三明治的有点
缺:由于局部使用大爆炸集成策略,所以有些接口部分测试不完整,必须分析系统结构和相
互依存性,要大量的驱动和桩
⑥、分层集成
优:有大爆炸,自顶向下,自底向上,三明治的优点
缺:有大爆炸,自顶向下,自底向上,三明治的缺点
⑦、基于功能的集成
优:功能明确,需要的驱动较少,与大爆炸相比,测试比较充分,容易定位,对功能较早的
完成测试等
缺:存在冗余测试,与大爆炸相比,时间成本高,与自顶向下和自底向上比,不容易定位 ⑧、基于消息集成
优:关键消息处理较早完成,进度比自顶向下,自底向上,三明治集成要短
缺:有较大的冗余测试,接口测试不充分
⑨、基于进度的集成
优:具有较高的并行性,能够有效的缩短项目开发的进度
缺:桩和驱动庞大,模块的不稳定,导致冗余测试比较多
11、基于风险的集成:
优:最具有风险的模块最早进行验证,有助于系统的快速稳定
缺:需要各组件的风险有一个清晰的认识
42.配置管理的术语,配置管理的活动有哪些?
术语:配置、配置项、基线、版本、版本标识
活动:配置计划、配置标识、配置控制、配置状态发布、配置审计
范文四:软件测试的理论和实践
软件测试的理论和实践
原作者:Blueski 由网友:XO转载 发布时间:2005-02-06 浏览量:749
题记,测试是交付成功的优质的产品的保证
我们每个人,不会都是软件测试人员,但都是某些软件的用户。缺省或默认情况下,用户都会觉得买到的软件是没有问题的,一般不会去想这样的软件可能会有问题,用户只要使用这些软件来解决他们需要解决的问题就可以了。当他们发现问题的时候,甚至会感到震惊。存在的问题很多都和测试的成效有关系,一般的软件产品存在的问题确实比较少,但我觉得即使是以前买的正版的金山快译2000都有着一些显而易见的bug。如果测试不充分,那么这些问题会潜伏在软件中,等到用户发现以后,再有开发人员进行维护,改正错误的费用一般是开发阶段的
40倍到60倍。
人们对测试存在着一些误区,例如,
1 测试是想象到可能出现的问题,然后试图验证这些问题。实际上能想象到的只是一部分的情况,随意性太大,还要取决于开发人员的经验,对业务的熟悉程度和他想象到的程度。
2 让时间有富裕的员工去做一些测试表面上看这体现了管理的效率和灵活性,但实际上也体现了管理者对测试的轻视。测试和测试的人有很大关系。测试工作人员应该是勤奋并富有耐心,善于学习、思考和发现问题,细心有条理,总结问题,如果具备这样的优点,做其它工作同样也会很出色,因此这里还有一个要求,就是要喜欢测试这项工作。如果他是专职的,那么肯定更有经验和信心。国内的小伙子好象都喜欢做程序员,两者工作性质不同,待遇不同,地位不同,对自我实现的价值的认识也不同,这是行业的一个需要改善的问题。如果只是为了完成任务而完成任务,或者发现了几个问题就觉得满意了,这在任何其它工作
中都是不行的。
3 测试是相对简单的工作。实际上并非如此,要真正做好一件事都不容易。测试也有很多相关技术和工具。而对测试的轻视问题,也许要通过痛苦的经历和结果才可能确切体会到。很多专家都在对测试的理论进行深入的探讨和研究。
测试的基本知识
让我们一起快速过一遍,
什么是软件测试,在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复审,是软件质量保证的关键步骤。测试的目标,以较少的用例、时间和人力找出软件中潜在的各种错误和缺陷,以确保系统的质量。从测试的类型来看,测试分为2种,黑盒测试和白盒测试。黑盒测试又称为功能测试或数据驱动测试,把系统看成一个黑盒子,不考虑程序的内在逻辑,只根据需求规格说明书的要求来检查程序的功能是否符合它的功能说明。白盒测试又称为结构测试和逻辑驱动测试,允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例,对程序的逻辑路径进行测试。测试用例由测试输入数据以及与之对应的输出结果组成。测试用例设计的好坏直接决定了测试的效果和结果。从测试实际的前后过程来看,软件测试上是由一系列的不同测试所组成,这些软件测试的步骤分为,单元测试、组装测试,集成测试,、确认测试和系统测试。软件开发的过程是自顶向下的,测试则正好相反,以上这些过程就是自底向上,逐步集成的。
单元测试,模块测试,,针对每个模块进行的测试,可从程序的内部结构出发设计测试用例,多个模块可以平行地对立地测试。通常在编码阶段进行,必要的时候要制作驱动模块和桩模块。集成测试,在单元测试的基础上,将所有模块按照设计要求组装成为系统,必须精心计划,应提交集成测试计划、集成测试规格说明和集成测试分析报告。 确认测试,验证软件的功能和性能及其它特性是否与用户的要求一致。
系统测试,将软件放在整个计算机环境下,包括软硬件平台、某些支持软件、数据和人员等,在实际运行环境下进行一系列的测试。
测试工作的文档主要有,测试计划、测试模型和用例设计或规格说明、测试分析报告等。从软件工程上说,这是属于软件配置的一部分。,我不知道,如果什么报告都没有,只是不断地摆弄执行程序,看到错误和问题就记下来,算不算真正的测试,,
测试需要一定的技术和工具
在用例设计过程中,可以考虑到很多方面,并且也有很多的指导方法和技术。
黑盒测试用例设计包括,
等价类划分,划分等价类--确立测试用例--设计用例边界值分析,通过分析,考虑如何确立边界情况错误推测法,靠经验和直觉来推测程序中可能存在的各种错误,从而有针对性地编写用例。可以列举出可能的错误和可能发生错误的地方,然后选择用例。因果图,通过画因果图,在图上标明约束和限制,转换成判定表,然后设计测试
用例。这适合于检查程序输入条件的各种组合情况。
功能图FD,通过形式化地表示程序的功能说明,并机械地生成功能图的测试用例。
白盒测试用例设计包括,
1 逻辑覆盖,以程序内在逻辑结构为基础的测试,包括以下5种类型,
1.1 语句覆盖,每一条可执行语句至少覆盖一次,
1.2 判定覆盖,分支覆盖,,设计若干个测试用例,运行所测程序,使程序中每个判断的取真分支和取假分支至少执行一次,
1.3 条件覆盖,设计足够多的测试用例,运行所测程序,使程序中每个判断的每个条
件的每个可能取值至少执行一次,
1.4 判定-条件覆盖,设计足够多的测试用例,运行所测程序,使程序中每个判断的每个条件的所有可能取值至少执行一次,并且每个可能的判断结果也至少执行一次,
1.5 条件组合测试,设计足够多的测试用例,运行所测程序,使程序中每个判断的所有可能的条件取值至少执行一次,
1.6 路径测试,设计足够多的测试用例,运行所测程序,要覆盖程序中所有可能的路径。
2 基本路径测试
在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例。包括以下5个方面,
2.1 程序的控制流图,描述程序控制流的一种图示方法。
2.2 程序环境复杂性,McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数,这是确定程序中每个可执行语句至少执行依次所必须的测试用例数目的上界。
2.3 导出测试用例
2.4 准备测试用例,确保基本路径集中的每一条路径的执行
2.5 图形矩阵,是在基本路径测试中起辅助作用的软件工具,利用它可以实现自动地确定一个基本路径集。
程序的静态分析方法,
1 生成各种引用表、静态错误分析
2 人工测试,桌前检查、代码评审等
3 软件测试工具,包括静态分析工具、动态测试工具、测试数据自动化生成工具、模块测试台、测试合成环境
3.1 静态分析工具,语言程序的预处理器、数据库工具、错误分析器和报告生成器。直接扫描所测试的正文,对程序的数据流和控制流进行分析,然后送出测试报告。
3.2 动态测试工具,通过选择适当的测试用例,实际运行所测程序,比较实际运行结果和预期结果,发现错误。
3.3 测试数据自动化生成工具,包括路径测试数据生成程序、随机测试数据生成程序以及根据数据规格说明生成测试数据
3.4 模块测试台是一种专门的测试用例描述语言,负责将输入数据传送到所测试模块中,然后将实际输出结果与在描述测试用例的语言中所表述的期望结果进行比较,发现错误。另外,也包括其它的功能,语句跟踪、动态断句、覆盖度量、用户自定义符号表、内容表和输出格式。
3.5 测试合成环境,包括环境模拟程序,代码检查程序,测试文档生成程序,测试执行严整程序,输出比较程序,程序正确性证明程序等,以及各种调试工具。而且还有集成系统,集成了多种工具,如SADAT、Microsoft Test for Windows和PureArtria等。 测试的管理
作为项目或产品开发的一个必要的组成部分,需要良好的组织和管理。使用软件质量规范,编写和实现测试用例和模型,可以有效地组织测试。
一般的测试工作过程也可以是,计划-->配置,必要的软硬件资源下,-->开发,构造或配置测试工具、创建测试套件和测试方案库、准备适当的报告工具并记录测试系统如何运转,-->测试执行,进行测试、记录测试条件和问题,报告结果,。
测试管理也可以从测试经理和测试小组2个方面去看,
测试经理要管理好团队,很多人认为测试是枯燥乏味的事情,而且似乎低级的事情,所以测试经理应该不断地激励小组成员,为他们争取利益。在时间进度上保证稳步前进。就象赛跑,一开始就加班加点,只会导致极限的过早到来。作为测试经理,应该有足够的质量意识。评价质量风险的方法是“失败模式和效果分析”(Failure Mode and Effect Analysis,
FMEA)。这种方法可以允许您在特定的质量风险和结果上映射需求、规范,以及项目小组假设。然后,按照风险级别进行分类,并按序排列。实际上如果能得到充分的资源已是很困难的了,能用好临时的测试人员也已经不错了。一般企业的主管和技术经理都并不怎么真正重视测试工作的意义和价值。也许他们认为临时的投入一次性的强力测试足以发现绝大部分问题,而实际上这对产品的长远发展,以及质量改进都没有太大好处。
测试过程中软件功能可能进行调整和变化,测试发现问题也会导致变化,需要重新的测试。对这些变更也需要进行管理。另外,由于上层管理部门的不重视,必须想办法与之进行清楚而有效的沟通,同开发部门的沟通也非常重要,因为开发和测试在性质上是有些对立的,很容易在相互之间产生一些不必要的矛盾。和开发部门不同的是,一般质量或测试部门和市场或销售部门的立场倒是比较一致的,如果双方都认为高质量的产品是市场战略中重要的品牌战略,彻底的测试对于达到这样的目标来说意义重大。因此,有必要和市场部门保持协作和交流。
测试经理可以经常问自己一些问题,
计划做哪些测试,实际完成了哪些测试,使用了多少用例,其中多少没有通过,管理部门是否有足够的支持,他们是否向你要过测试报告,开发部门的联络是否及时,等等。如果你是测试管理人员,应该可以想到更多的问题。
测试小组,
测试小组有多大的规模,一般取决于项目规模、测试人员与开发人员的比例、项目经理对质量保证的认识和期望等,也取决于你的准确的测试计划。对一些项目来说,最好是在开始阶段就有测试人员有所介入。
如本文一开始所提到的,在测试小组中测试人员必须具备的素质包括,有效的坦率真诚的交流的能力、清晰简明的表达能力、一定的好奇心,但不至于太强,以至于花太多精力去探究一个微小的问题,,不应害怕提出尖锐问题引起麻烦,一定的责任心,注意力能够高度集中,是职业悲观主义者,但不是抱怨和憎恶,。
以下是一些测试的方法和基本工具,
测试方案、测试模型和测试用例
测试就象是做实验一样,实验对于象我这样的理工科毕业生来说真是太熟悉不过了。做实验之前必然有实验的方案、内容和步骤,测试似乎也是同样的。另外,基于测试用例的测试和常见的随机性的测来测去也是完全不同的,尽管习惯于随机性测试的人,如果注意力集中的话,他的头脑里也是有一些测试用例的。
关于测试实验室,进行测试工作首先要争取到尽可能好的环境。如果可能,应该建立测试实验室,实验室包括必要的装备、工具软件,包括测试工具,和各种操作系统平台,保持实验室的实用、整洁,避免他人干扰甚至破坏测试环境。
关于测试跟踪软件,制作一个简单的测试问题跟踪软件,记录测试的结果,将测试发现的问题分类,并对测试发现的问题和模块、开发人员进行关联,有助于分析问题,并可有效记录测试的结果,形成测试报告,并从中找出一些规律性的东西来。因此测试问题跟踪软件还是有一定的价值的。
关于测试自动化,有一定的风险。对一个稳定的系统,甚至可以自己开发自动化软件,而对于正处于快速变形中的软件开发过程,接口、主要功能和支持环境在发展变化中。为测试配置环境也要付出很多的时间。
以下是关于测试的一些技巧和经验,
在制定测试计划的时候,就要考虑到测试的风险,并抉择要执行哪些测试,并放弃哪些测试,测试计划的评审应该让开发人员参与,测试模型的制作应该尽可能贴近用户,或者站在用户的使用立场上来观测软件,此时应该能发现更多的问题。
由于测试发现问题,在解决问题后还要重新测试,因此测试的时间可能会比实际更长一些
识别和注意少数重要的方面,而忽略多数次要的方面,有时候少数的问题足以致命,这些问题将是软件测试结果中重要性最高的错误。
错误的定位有时是很难的,要找出必然发生的前因后果,而不至于因为描述错误而误导开发人员。有时候确实存在错误不能重建的问题。解决办法之一是在错误报告中给予说明。
对错误的描述,应该是准确、完整而简练。因为描述的问题或者不完整的描述会引起开发人员的误解,其后果是可以想见的。
有时有经验的测试人员凭借直觉就可以发现一些问题,这可称为“错误猜测”。
测试人员容易犯2种错误,一是测试人员发生判断错误,将本没有错误的系统行为报告为错误,或者将错误指定了过高的严重级别,或者过高估计了问题的严重性,这样会引起开发人员的不信任,产生一种象“狼来了”一样的效果,二是测试人员将错误的严重性或优先级定得过低,从而产生“测试逃逸”,这样会造成产品质量的风险。以上两种错误应该尽量避免。
最后,我忽然想,测试实际上可以覆盖到硬件,甚至非计算机产品的测试,也许可以相互借鉴。
还有一种很奇特的感想,这种感想使我反而有些困惑不清了。我发现对测试来说,理论和实践的距离好象非常遥远,我先看了一本软件工程的书,然后写下了前面的一半内容,然后我又匆匆翻看了一本美国人的书,叫做《测试流程管理》,然后整理出了本文后一半的内容,该书中有着比本文多得多的各方面的实践经验。歌德说过,理论是苍白的,生命之树常青。我稍稍改变一下,就变成了,理论是苍白的,实践之树常青。也许测试是一种实践性很强的工作,大学教授们一般也不可能热衷于参加测试工作吧。
范文五:软件测试的理论和实践
软件测试的理论和实践
题记:测试是交付成功的优质的产品的保证
我们每个人,不会都是软件测试人员,但都是某些软件的用户。缺省或默认情况下,用户都会觉得买到的软件是没有问题的,一般不会去想这样的软件可能会有问题,用户只要使用这些软件来解决他们需要解决的问题就可以了。当他们发现问题的时候,甚至会感到震惊。存在的问题很多都和测试的成效有关系,一般的软件产品存在的问题确实比较少,但我觉得即使是以前买的正版的金山快译2000都有着一些显而易见的bug。如果测试不充分,那么这些问题会潜伏在软件中,等到用户发现以后,再有开发人员进行维护,改正错误的费用一般是开发阶段的40倍到60倍。
人们对测试存在着一些误区,例如:1测试是想象到可能出现的问题,然后试图验证这些问题。实际上能想象到的只是一部分的情况,随意性太大,还要取决于开发人员的经验,对业务的熟悉程度和他想象到的程度。2让时间有富裕的员工去做一些测试表面上看这体现了管理的效率和灵活性,但实际上也体现了管理者对测试的轻视。测试和测试的人有很大关系。测试工作人员应该是勤奋并富有耐心,善于学习、思考和发现问题,细心有条理,总结问题,如果具备这样的优点,做其它工作同样也会很出色,因此这里还有一个要求,就是要喜欢测试这项工作。如果他是专职的,那么肯定更有经验和信心。国内的小伙子好象都喜欢做程序员,两者工作性质不同,待遇不同,地位不同,对自我实现的价值的认识也不同,这是行业的一个需要改善的问题。如果只是为了完成任务而完成任务,或者发现了几个问题就觉得满意了,这在任何其它工作中都是不行的。3测试是相对简单的工作。实际上并非如此,要真正做好一件事都不容易。测试也有很多相关技术和工具。而对测试的轻视问题,也许要通过痛苦的经历和结果才可能确切体会到。很多专家都在对测试的理论进行深入的探讨和研究。
测试的基本知识
让我们一起快速过一遍:
什么是软件测试:在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复审,是软件质量保证的关键步骤。测试的目标:以较少的用例、时间和人力找出软件中潜在的各种错误和缺陷,以确保系统的质量。从测试的类型来看,测试分为2种:黑盒测试和白盒测试。黑盒测试又称为功能测试或数据驱动测试,把系统看成一个黑盒子,不考虑程序的内在逻辑,只根据需求规格说明书的要求来检查程序的功能是否符合它的功能说明。白盒测试又称为结构测试和逻辑驱动测试,允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例,对程序的逻辑路径进行测试。测试用例由测试输入数据以及与之对应的输出结果组成。测试用例设计的好坏直接决定了测试的效果和结果。从测试实际的前后过程来看,软件测试上是由一系列的不同测试所组成,这些软件测试的步骤分为:单元测试、组装测试(集成测试)、确认测试和系统测试。软件开发的过程是自顶向下的,测试则正好相反,以上这些过程就是自底向上,逐步集成的。
单元测试(模块测试):针对每个模块进行的测试,可从程序的内部结构出发设计测试用例,多个模块可以平行地对立地测试。通常在编码阶段进行,必要的时候要制作驱动模块和桩模块。集成测试:在单元测试的基础上,将所有模块按照设计要求组装成为系统,必须精心计划,应提交集成测试计划、集成测试规格说明和集成测试分析报告。确认测试:验证软件的功能和性能及其它特性是否与用户的要求一致。系统测试:将软件放在整个计算机环境下,包括软硬件平台、某些支持软件、数据和人员等,在实际运行环境下进行一系列的测试。
测试工作的文档主要有:测试计划、测试模型和用例设计或规格说明、测试分析报告等。从软件工程上说,这是属于软件配置的一部分。(我不知道,如果什么报告都没有,只是不断地摆弄执行程序,看到错误和问题就记下来,算不算真正的测试?)
测试需要一定的技术和工具
在用例设计过程中,可以考虑到很多方面,并且也有很多的指导方法和技术。
黑盒测试用例设计包括:
等价类划分:划分等价类--确立测试用例--设计用例边界值分析:通过分析,考虑如何确立边界情况错误推测法:靠经验和直觉来推测程序中可能存在的各种错误,从而有针对性地编写用例。可以列举出可能的错误和可能发生错误的地方,然后选择用例。因果图:通过画因果图,在图上标明约束和限制,转换成判定表,然后设计测试用例。这适合于检查程序输入条件的各种组合情况。
功能图FD:通过形式化地表示程序的功能说明,并机械地生成功能图的测试用例。
白盒测试用例设计包括:
1逻辑覆盖,以程序内在逻辑结构为基础的测试,包括以下5种类型:
1.1语句覆盖:每一条可执行语句至少覆盖一次;1.2判定覆盖(分支覆盖):设计若干个测试用例,运行所测程序,使程序中每个判断的取真分支和取假分支至少执行一次;1.3条件覆盖:设计足够多的测试用例,运行所测程序,使程序中每个判断的每个条件的每个可能取值至少执行一次;1.4判定-条件覆盖:设计足够多的测试用例,运行所测程序,使程序中每个判断的每个条件的所有可能取值至少执行一次,并且每个可能的判断结果也至少执行一次;1.5条件组合测试:设计足够多的测试用例,运行所测程序,使程序中每个判断的所有可能的条件取值至少执行一次;1.6路径测试:设计足够多的测试用例,运行所测程序,要覆盖程序中所有可能的路径。
2基本路径测试
在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例。包括以下5个方面:2.1程序的控制流图:描述程序控制流的一种图示方法。2.2程序环境复杂性:McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数,这是确定程序中每个可执行语句至少执行依次所必须的测试用例数目的上界。2.3导出测试用例2.4准备测试用例,确保基本路径集中的每一条路径的执行2.5图形矩阵:是在基本路径测试中起辅助作用的软件工具,利用它可以实现自动地确定一个基本路径集。
程序的静态分析方法:
1生成各种引用表、静态错误分析
2人工测试:桌前检查、代码评审等
3软件测试工具:包括静态分析工具、动态测试工具、测试数据自动化生成工具、模块测试台、测试合成环境
3.1静态分析工具:语言程序的预处理器、数据库工具、错误分析器和报告生成器。直接扫描所测试的正文,对程序的数据流和控制流进行分析,然后送出测试报告。
3.2动态测试工具:通过选择适当的测试用例,实际运行所测程序,比较实际运行结果和预期结果,发现错误。
3.3测试数据自动化生成工具:包括路径测试数据生成程序、随机测试数据生成程序以及根据数据规格说明生成测试数据
3.4模块测试台是一种专门的测试用例描述语言,负责将输入数据传送到所测试模块中,然后将实际输出结果与在描述测试用例的语言中所表述的期望结果进行比较,发现错误。另外,也包括其它的功能:语句跟踪、动态断句、覆盖度量、用户自定义符号表、内容表和输出格式。
3.5测试合成环境:包括环境模拟程序,代码检查程序,测试文档生成程序,测试执行严整程序,输出比较程序,程序正确性证明程序等,以及各种调试工具。而且还有集成系统,集成了多种工具,如SADAT、Microsoft Test for Windows和PureArtria等。*
测试的管理
作为项目或产品开发的一个必要的组成部分,需要良好的组织和管理。使用软件质量规范,编写和实现测试用例和模型,可以有效地组织测试。
一般的测试工作过程也可以是:计划--配置(必要的软硬件资源下)--开发(构造或配置测试工具、创建测试套件和测试方案库、准备适当的报告工具并记录测试系统如何运转)--测试执行(进行测试、记录测试条件和问题,报告结果)。
测试管理也可以从测试经理和测试小组2个方面去看:
测试经理要管理好团队,很多人认为测试是枯燥乏味的事情,而且似乎低级的事情,所以测试经理应该不断地激励小组成员,为他们争取利益。在时间进度上保证稳步前进。就象赛跑,一开始就加班加点,只会导致极限的过早到来。作为测试经理,应该有足够的质量意识。评价质量风险的方法是"失败模式和效果分析"(Failure Mode and Effect Analysis,FMEA)。这种方法可以允许您在特定的质量风险和结果上映射需求、规范,以及项目小组假设。然后,按照风险级别进行分类,并按序排列。实际上如果能得到充分的资源已是很困难的了,能用好临时的测试人员也已经不错了。一般企业的主管和技术经理都并不怎么真正重视测试工作的意义和价值。也许他们认为临时的投入一次性的强力测试足以发现绝大部分问题,而实际上这对产品的长远发展,以及质量改进都没有太大好处。
测试过程中软件功能可能进行调整和变化,测试发现问题也会导致变化,需要重新的测试。对这些变更也需要进行管理。另外,由于上层管理部门的不重视,必须想办法与之进行清楚而有效的沟通;同开发部门的沟通也非常重要,因为开发和测试在性质上是有些对立的,很容易在相互之间产生一些不必要的矛盾。和开发部门不同的是,一般质量或测试部门和市场或销售部门的立场倒是比较一致的,如果双方都认为高质量的产品是市场战略中重要的品牌战略,彻底的测试对于达到这样的目标来说意义重大。因此,有必要和市场部门保持协作和交流。
测试经理可以经常问自己一些问题:
计划做哪些测试?实际完成了哪些测试?使用了多少用例?其中多少没有通过?管理部门是否有足够的支持?他们是否向你要过测试报告?开发部门的联络是否及时?等等。如果你是测试管理人员,应该可以想到更多的问题。
测试小组:
测试小组有多大的规模,一般取决于项目规模、测试人员与开发人员的比例、项目经理对质量保证的认识和期望等,也取决于你的准确的测试计划。对一些项目来说,最好是在开始阶段就有测试人员有所介入。
如本文一开始所提到的,在测试小组中测试人员必须具备的素质包括:有效的坦率真诚的交流的能力、清晰简明的表达能力、一定的好奇心(但不至于太强,以至于花太多精力去探究一个微小的问题),不应害怕提出尖锐问题引起麻烦,一定的责任心,注意力能够高度集中,是职业悲观主义者(但不是抱怨和憎恶)。
以下是一些测试的方法和基本工具:
测试方案、测试模型和测试用例测试就象是做实验一样,实验对于象我这样的理工科毕业生来说真是太熟悉不过了。做实验之前必然有实验的方案、内容和步骤,测试似乎也是同样的。另外,基于测试用例的测试和常见的随机性的测来测去也是完全不同的,尽管习惯于随机性测试的人,如果注意力集中的话,他的头脑里也是有一些测试用例的。
关于测试实验室,进行测试工作首先要争取到尽可能好的环境。如果可能,应该建立测试实验室,实验室包括必要的装备、工具软件(包括测试工具)和各种操作系统平台,保持实验室的实用、整洁,避免他人干扰甚至破坏测试环境。
关于测试跟踪软件,制作一个简单的测试问题跟踪软件,记录测试的结果,将测试发现的问题分类,并对测试发现的问题和模块、开发人员进行关联,有助于分析问题,并可有效记录测试的结果,形成测试报告,并从中找出一些规律性的东西来。因此测试问题跟踪软件还是有一定的价值的。
关于测试自动化,有一定的风险。对一个稳定的系统,甚至可以自己开发自动化软件,而对于正处于快速变形中的软件开发过程,接口、主要功能和支持环境在发展变化中。为测试配置环境也要付出很多的时间。
以下是关于测试的一些技巧和经验:
在制定测试计划的时候,就要考虑到测试的风险,并抉择要执行哪些测试,并放弃哪些测试;测试计划的评审应该让开发人员参与;测试模型的制作应该
尽可能贴近用户,或者站在用户的使用立场上来观测软件,此时应该能发现更多的问题。
由于测试发现问题,在解决问题后还要重新测试,因此测试的时间可能会比实际更长一些
识别和注意少数重要的方面,而忽略多数次要的方面,有时候少数的问题足以致命,这些问题将是软件测试结果中重要性最高的错误。
错误的定位有时是很难的,要找出必然发生的前因后果,而不至于因为描述错误而误导开发人员。有时候确实存在错误不能重建的问题。解决办法之一是在错误报告中给予说明。
对错误的描述,应该是准确、完整而简练。因为描述的问题或者不完整的描述会引起开发人员的误解,其后果是可以想见的。
有时有经验的测试人员凭借直觉就可以发现一些问题,这可称为"错误猜测"。
测试人员容易犯2种错误:一是测试人员发生判断错误,将本没有错误的系统行为报告为错误,或者将错误指定了过高的严重级别,或者过高估计了问题的严重性,这样会引起开发人员的不信任,产生一种象"狼来了"一样的效果;二是测试人员将错误的严重性或优先级定得过低,从而产生"测试逃逸",这样会造成产品质量的风险。以上两种错误应该尽量避免。
记录激动时刻,赢取超级大奖~点击链接,和我一起参加"2010:我的世界杯Blog日志"活动~