还是有点不同的,举个例子来说吧,软件测试是对结果的保证,是出现结果的前提条件。评测是对结果的分析,建立在测试之后的。
比如手机测试里3G下载速度要求达到100K/s,我在软件测试时发现没达到这个速度,所以我要报告问题,让开发解决这个下载速度问题,然后速度达到要求了,测试过程结束。
评测的时候,发现该手机速度可以达到100K/s,甚至能够达到150K/s,那我说这手机表现超过其他手机,性能非常好,可以说评测是对软件一个综合评价的过程。
软件评测师和软件测试工程师的区别
软件评测师是要经过考试,考试过了之后才能算是评测师
软件工程师是指做软件测试这个岗位,就称之为软件测试工程师,并不需要什么考试,只要能胜任这个工作。软件评测师的考试是有难度的,你也可以把软件评测师做为软件测试的一个高点就像软件架构师可以作为软件开发的一个高点。
软件测试费用标准,一个系统软件测试收费标准
亲,系统软件测试收费现在还未没有国家统一标准。各个单位根据实际情况,或参考行业收费情况自己制定。一般来说,根据系统软件类型不同,收费模式也不同。有按代码行数计算的,有按功能点计算的,或两者结合的。但代码行数计算的,分嵌入式编程语言、非嵌入式有所区别。功能点,也分大功能点,小功能点 。有的时候按几级菜单来计算。嵌入式语言测试一行代码按50元收费。另外还要考虑软件的重要程度,乘以相应的系数。考虑到一个测试项目,需要从测试需求分析,计划,设计、执行、总结等一系过程,不管系统大小,测试一般会有一个门槛价格,一般3万吧。我说的这些费用,都是都是国家认可的第三方测评中心的数据。一般公司测试收费情况,不在其中。因为有些软件本来投资总成本也不超过3万,不可能光测试费用就3万。希望这些对你有所帮助。
最近在自学软件测试 可是《软件评测师教程》里面有些内容实在看不懂 比如白盒测试什么什么的 怎么办??
软件评测师跟软件测试工程师是有区别的,在一般的企业当中,一般都是招聘软件测试工程师的。只有在一些软件评测中心,才会招软件评测师。软件测试工程师所要必备的基本条件包括:linux和windows系统的基本命令和搭建知识;数据库知识(sql语句、数据库架构、PLSQL的使用),主要针对于oracle、sybase、sqlserver等主流数据库;测试用例的设计、测试思路和测试方法;主流测试工具的掌握,自动化测试工具(qtp、selenium),性能测试工具(loadrunner、webrunner)。关于白盒测试,真正的是要懂代码的人才会使用的测试方法,在一般的项目中运用的也很少,所以对于初学者,只要懂得其原理就可以了。学习的话可以网上搜对应的书籍,都是入门级别的,也可以看看视频来学习。
有什么软件来评测电脑性能?
360硬件大师,原鲁大师,国人都爱用,但是也是相对不靠谱的软件。
下边推荐一些国际上比较出名的软件。
整机类测试软件
LavalysEverest和SiSoftSandraPro是目前使用最多的两款软件,它们分别有各自不同的特点和使用方法。
LavalysEVEREST,也就是以前著名的AIDA32,是一个测试软硬件系统信息的工具,它可以详细的显示出PC每一软件提高电脑性能个方面的信息。支持上千种(3400+)主板和上百种(360+)显卡,支持对并口/串口/USB这些PNP设备的检测,支持对各式各样的处理器和内存的侦测。EVEREST有HomeEdition和Professional两个版本。其中Professional是收费的商业版本,HomeEdition则是免费软件。相比Professional,HomeEdition只是少了数据分析和数据库连接功能,而在硬件检测方面,HomeEdition没有任何缩水。
相比EVEREST,SiSoftSandraPro更侧重于系统分析与评测,它有超过30种以上的测试项目,主要包括CPU、Drives、CD-ROM/DVD、Memory、SCSI、APM/ACPI、鼠标、键盘、网络、主板、打印机等。
SiSoftSandraPro在硬件信息检测上没有EVEREST细致和繁多,但却可以得到各种硬件的大致性能。因此这两款软件经常一起使用,EVEREST取得系统软硬件的详细信息,SiSoftSandraPro则了解系统性能所处的水平。
稳定性测试软件
Superπ
顾名思义,Superπ是一款用来计算圆周率的软件,但它更多的被用于测试CPU速度和系统的稳定性。由于运行圆周率计算时需要大量的系统资源,且CPU一直处于高负荷运行,因此即使你的系统运行一天的Word、Photoshop都没有问题,而运行Superπ也不一定能通过。
使用方法:选择你要计算的位数(一般采用104万位),点击开始就可以了。性能上,运算所需要的时间越短越好;稳定性上,以没有出现任何错误为判断依据。
Prime95
和Superπ类似,Prime95也是利用不停计算函数来达电脑测试软件到测试系统稳定性的目地,只不过它计算的是梅森质数。不过Prime95的测试环境非常苛刻,即使能在Superπ中顺利通过419万次测试的系统,也不见得能在Prime95中熬过1分钟。因此很多玩家用Prime95来测试超频后的CPU,并以此作为超频成功的证据。
Prime95的使用也很简单,从官方网站下载最新版本安装运行,点击菜单栏“Option(选项)”中的“CPU”即可对测试进行设置。在这里,用户可以设置测试的时间、测试所使用的内存容量、测试的起始和结束时间,以及CPU的型号、实际频率以及缓存等信息。
设置好后点击“Option(选项)/TortureTest(稳定性测试)”开始启动测试。由于Prime95的系统稳定性测试消耗的系性能测试工具统资源并不多,用户可以在测试期间进行其它操作,这时Prime95会在系统托盘中生成一个红色的图标,代表测试正在顺利进行着,如果这个图标的颜色在测试还没有结束之前就变成黄色了,说明测试失败,你的系统没有达到Primr95所要求的稳定性。Prime95默认的测试时间为12小时,如果通过12小时的测试,那说明系统稳定;如果能通过24小时以上的测试,那么这个系统就基本不会因为稳定性而出现故障。
Prime95同样也有性能测试功能。只要选择“Option(选项)/Benchmark(性能测试)”就可以对系统性能进行测试,测试以运算一定函数量所花费的时间作为标准,耗时越少说明系统性能越强。
PassMarkBurnInTestProfessional
与Superπ和Prime95不同,PassMarkBurnInTe计算机性能测试软件stProfessional是一款专业的系统可靠性和稳定性测试工具,它通过对CPU、硬盘、声卡、显卡(2D/3D)、打印机、内存、串口、网络、磁带机、并口以及计算机系统与其它外围设备的持久运行,来测试系统是否稳定,可以说非常的全面。
测试时,首先在软件界面中点击菜单“Configuration/Testdutycycles”选择测试项目,一些测试项目,如CD-RW/DVD(光驱)、Printer(打印机)、USB等,需要准备有满容量的光盘、打印纸和USB等必须设备,我们可以不进行选择。
选择好测试项目后可以在“Testpreferences”中对每个项目进行微调,并可以将此配置保存为文件(Saveconfigas)在需要时载入(LoadConfig)。完毕后选择菜单“Test/Starttestrun”运行测试,屏幕上出现很多个窗口,可以看到各个设备的实时运行情况。测试运行一段时间后请按下“Stop”按钮,停止测试,在主界面的ResultSheet中就会出现测试结果,看是否有错误。
CPU测试软件
WCPUID、CPU-Z、Intel官方CPU检测软件(IntelProcessorIdentificationUtility)
内存测试软件
MemTest、Memtest86+
注意:Memtest86+的安装和使用和其它内存测试软件有些不同,因为它不能在Windows下运行。不过还是有四种方式可以运行此程序,分别为ISO引导盘、Linux下使用的bin文件、USB启动盘使用的EXE文件和软盘引导制作包(官方网站:)
硬盘测试软件
硬盘测试方面,有很多软件可供使用,包括系统自带的工具,硬盘厂商提供的电脑性能测试软件下载专用软件以及第三方软件,如HDTune、DriverHealth等。
光驱测试软件
常用的软件有NeroInfoTool和NeroCD-DVDSpeed
显卡测试软件
RivaTuner、3DMark系列
显示器测试软件
NokiaMonitorTest
电源测试
OCCT(OverClockCheckingTool的缩写)
注意:OCCT不能独立工作,必须配合MotherboardMonitor5(以下简称MBM5)、SpeedFan或者ASUSPCProbe才能为用户提供一分完美的电源质量报告。
备注:笔记本电脑电脑测试软件常用的有:电池测试软件PassMarkBatteryMon和BatteryEater;键盘测试软件PassMarkKeyBoardTest;综合测试软件MobileMark2002
互联网公司的软件测试工程师们都在干什么?
引言
软件测试成为最近 IT 行业的“香饽饽”,引得很多人对软件测试跃跃欲试。可是软件测试的门槛并不低,
对于没有软件测试经验的新人而言,如何尽快转入测试工作中去呢?
了解软件测试都做些什么,具体过程是怎么进行的,可以有助于对软件测试进行初步了解,尽快进入测试工
作角色。但是关于软件测试的工作流程,各种现有书籍和文章往往都描述的非常复杂,充斥着不少测试术语
,使测试初学者望而生畏。
现在让我们换一种角度看看典型的软件测试是如何进行的,暂且把软件测试过程看作一场大戏,主角就是测
试工程师,按照时间顺序记录软件测试工程师一天的工作场景(假设正常工作时间 9:00 到 18:00 )。
测试大戏开演
时间:
9:00
工作场景:
启动工作计算机,查看收到的电子信件。
画外音:
查看收到的电子邮件(哇塞,这么多电子邮件!),理解当天的测试工作的内容和要求。
测试工程师至少配置两台计算机:其中一台是日常工作用,例如,收发电子邮件等。另外还有一台软件测试
用的计算机。
时间:
9:10
工作场景:
回复电子邮件。
画外音:
回复电子邮件。如果对于安排的测试任务和要求存在任何疑问,请在回复电子邮件时列举出来。如果任务明
确,回信中可以简单的说明理解测试任务了,按照测试任务要求进行测试。(正好今天有一封电子邮件分配
了测试任务 A ,而且任务明确,测试文档等完整。)
电子邮件有不同的优先级,任务非常紧迫的电子邮件应该优先处理,尽快回复。(面对多封邮件保持镇定,
分清哪些邮件需要马上回复)
并非全部的电子邮件都需要回复(抄送给自己的邮件和一般通告等不需要回复)
时间:
9:25
工作场景:
启动用于测试的计算机
根据测试要求配置操作系统、安装要测试的软件
根据测试用例执行测试任务 A 。
画外音:
测试一般需要按照测试指导文档和测试用例进行。(软件测试可不是盲目的乱测一气的呀!)
很多软件的测试要求在一个“干净”的计算机上测试(提示:干静的计算机是仅安装了操作系统,没有安装
其他应用程序的计算机)。
在进行正式测试前,需要阅读测试文档,明确测试任务(这些测试文档你找到了吗?是最新的测试文档吗?
)。
时间: 11:00
工作场景:
执行软件测试,书写软件测试 Bug 报告
画外音:
按照测试要求,尽量多找出软件的 Bug 。(什么破软件,能找出这么多 Bug ! 反过来想,软件如果没有
Bug ,我们测试工程师不就失业了吗!)
根据发现的软件 Bug ,按照客户要求写出每个 Bug 的报告(要书写明白,否则客户事后会要求你重写,很
费时间,也影响公司的测试质量,是否很没有面子?)
时间:
11:30
工作场景:
报告测试执行中的遇到了问题
画外音:
如果测试用例的步骤不明确或者测试的软件不能成功安装,无法进行下面的测试,应该及时向测试负责人报
告,等待答复后进行测试。(重大问题,切莫瞒报,也别主观想当然地猜测!)
如果某些测试步骤不明确,但是可以暂时跳过,请向测试负责人报告,并且继续进行下面的测试。(灵活处
理,合理利用时间,时间就是金钱!)
时间:
12:00
工作场景:
查收和回复新邮件,新邮件又来了一个新的测试任务 B ,而且要求紧急处理。
暂停测试任务 A ,进行测试任务 B 。
画外音:
测试过程中,要主要定时查看是否有新邮件,特别是那些要求非常紧急的任务。(重要任务一定要优先处理
,否则就是工作失职)
如果新任务比较紧急,应该中断当前的测试,接着执行新任务。(为什么计划总是没有变化快,可是现实就
是这样。)
时间: 12:30
工作场景:
午餐、休息
画外音:
阳光、午餐、休息,美!(禁止在办公室玩任何电子游戏,办公室不是娱乐场所!)
时间:13:30
工作场景:
查收和回复新邮件
画外音:
真幸运,没有其他新任务。
继续上午的任务 B 。
时间:14:30
工作场景:
完成新任务 B ,向测试负责人提交任务 B 的测试结果
画外音:
完成任何任务后,需要向测试负责人发送任务完成的电子邮件。(这一点很重要的,否则你做的工作再多,
测试负责人也不一定很清楚)
提交任务的电子邮件中,应该写明任务是否全部完成,存在什么问题,测试结果存放在什么计算机的哪个目
录中。(想象测试负责人需要你提交哪些内容,最好在一封信中交待明白,完整,清楚,条理分明)
时间:
14:40
工作场景:
发送测试任务 A 不能按期完成的电子邮件
画外音:
由于执行了新测试任务 B ,使得测试任务 A 不能按时完成,应该及早向测试负责人发送电子邮件。(如果
你不主动说无法按时完成任务 A ,测试负责人就默认为你能够按时完成。而如果到了完成任务的最后期限
,而你突然向测试负责人说任务还没有完成,那么我可以很负责任地告诉你:测试负责人将会很生气,后果
很严重!)
得到测试负责人的答复后,继续执行测试任务 A 。
如果客户要求必须当天完成测试任务 A ,可能要做好加班准备(苦恼 … )。或者请测试负责人将一部分
任务分解给其他测试人员执行(呵呵,谢谢兄弟们拉我一把 ... )。
时间:14:50
工作场景:
继续执行测试任务 A 。
画外音:
寻找软件 Bug (这是主要任务之一)
书写 Bug 测试报告(这也是主要任务之一)
时间:
15:30
工作场景:
查收和回复新邮件
画外音:
没有新电子邮件,呵呵!(最不喜欢在测试工作中,经常有邮件来骚扰!)
继续执行测试任务 A 。
时间:
17:00
工作场景:
参加测试小组内部会议
画外音:
经常在测试过程中,测试小组内部会召开短暂的会议。(交流很重要的,倾听和发言一个都不能少)
会议内容一般是测试过程中遇到的问题,以及可能的解决办法,也包括测试进度是否与测试计划保持一致。
时间:
17:30
工作场景:
发送当天任务完成情况的电子邮件
画外音:
当天任务完成情况的报告应该在下班前尽早发送给测试负责人,以便得到及时回复。
总结当天测试任务完成的情况(全部完成还是部分完成)
测试遇到的需要测试负责人或者问题客户帮助解决的问题(遇到问题一定要反映,不要什么问题都自己扛!
)
给出当天处理 Bug 的数量、类型和存放位置(确保测试负责人能很容易的找到这些测试结果吗?)
时间:17:45
工作场景:
整理当天的测试文档,
做好备份
个人总结
画外音:
备份当天的测试结果(有备无患!)
总结测试遇到的问题和学习的新知识(好好学习,天天向上!)
准备第二天的测试任务(未雨绸缪)
时间: 18:00
工作场景:
下班
画外音:
如果不需要加班,按时回家,爽!
测试大戏背后的故事
上面的测试场景描述基本上反映了软件测试工程师的工作情形,但是由于测试工作的复杂性、琐碎性、变化
性,实际测试过程将是不断变化的。
测试的变化性
对于软件本地化等外包测试,测试过程和测试要求因不同客户而异,即使相同客户的不同项目,也会有些变
化。另外,测试所用的测试计划、测试用例、测试 Build 版本经常变化。这是对测试工程师需要面对和正
确处理的工作挑战。
多任务同时处理
软件测试工程师在一天的工作时间里,可能需要做多件事情(例如,测试负责人可能中间会安排新的任务)
,正常测试过程经常被中断,对此需要有相应的心理准备。
及时交流
测试过程很少是一帆风顺的,特别是不熟悉的新软件,或者测试用例没有表达清楚。这时除了自己学习和思
考,还需要向测试组的其他同事请教。如果问题仍然没有解决,请及时向测试负责人反映情况,寻求帮助(
提示:测试负责人积累了软件测试经验,一般问题都可以搞定,但是测试负责人也不是万能的,他们也有很
多不能解决的问题,但是他们有“杀手锏” — 向客户的测试负责人寻求帮助,由于源语言是客户开发的,
客户才是万能的!)。
电子邮件是主要的交流方式
测试过程不要一味地在测试计算机上做下去,要经常在日常工作用计算机查看和回复电子邮件,以免耽误了
更重要的任务。除了电子邮件之外,也可以打电话和即时网络交流工具( MSN 等),或者面对面与同事交
流(提示:对于复杂的问题,与其来回发送多封电子邮件还说不明白,还不如打个电话或者面对面交谈更有
效)。
软件测试基本理论?
软件测试概念:通过各种手段和测试工具,判断软件系统是否能够满足预期期望。
从软件开发的过程按阶段划分有
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、从是否关心内部结构来看
(1)白盒测试:又称为结构测试或逻辑驱动测试,是一种按照程序内部逻辑结构和编码结构,设计测试数据并完成测试的一种测试方法。
(2)黑盒测试:又称为数据驱动测试,把测试对象当做看不见的黑盒,在完全不考虑程序内部结构和处理过程的情况下,测试者仅依据程序功能的需求规范考虑,确定测试用例和推断测试结果的正确性,它是站在使用软件或程序的角度,从输入数据与输出数据的对应关系出发进行的测试。
(3)灰盒测试:是一种综合测试法,它将“黑盒”测试与“白盒”测试结合在一起,是基于程序运行时的外部表现又结合内部逻辑结构来设计用例,执行程序并采集路径执行信息和外部用户接口结果的测试技术。
2、从是否执行代码看
(1)静态测试:指不运行被测程序本身,仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。
(2)动态测试:是指通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率、正确性和健壮性等性能指标。
3、从开发过程级别看
(1)单元测试:又称模块测试,是针对软件设计的最小单位----程序模块或功能模块,进行正确性检验的测试工作。其目的在于检验程序各模块是否存在各种差错,是否能正确地实现了其功能,满足其性能和接口要求。
(2)集成测试:又叫组装测试或联合,是单元测试的多级扩展,是在单元测试的基础上进行的一种有序测试。旨在检验软件单元之间的接口关系,以期望通过测试发现各软件单元接口之间存在的问题,最终把经过测试的单元组成符合设计要求的软件。
(3)系统测试:是为判断系统是否符合要求而对集成的软、硬件系统进行的测试活动、它是将已经集成好的软件系统,作为基于整个计算机系统的一个元素,与计算机硬件、外设、某些支持软件、人员、数据等其他系统元素结合在一起,在实际运行环境下,对计算机系统进行一系列的组装测试和确认测试。
在系统测试中,对于具体的测试类型有:
(1)功能测试:对软件需求规格说明书中的功能需求逐项进行的测试,以验证功能是否满足要求。
(2)性能测试:对软件需求规格说明书的功能需求逐项进行的测试,以验证功能是否满足要求。
(3)接口测试:对软件需求规格说明中的接口需求逐项进行的测试。
(4)人机交互界面测试:对所有人机交互界面提供的操作和显示界面进行的测试,以检验是否满足用户的需求。
(5)强度测试:强制软件运行在异常乃至发生故障的情况下(设计的极限状态到超出极限),验证软件可以运行到何种程序的测试。
(6)余量测试:对软件是否达到规格说明中要求的余量的测试。
(7)安全性测试:检验软件中已存在的安全性、安全保密性措施是否有效的测试,
(8)可靠性测试:在真实的或仿真的环境中,为做出软件可靠性估计而对软件进行的功能(其输入覆盖和环境覆盖一般大于普通的功能测试)
(9)恢复性测试:对有恢复或重置功能的软件的每一类导致恢复或重置的情况,逐一进行的测试。
(10)边界测试:对软件处在边界或端点情况下运行状态的测试。
(11)数据处理测试:对完成专门数据处理功能所进行的测试。
(12)安装性测试:对安装过程是否符合安装规程的测试,以发现安装过程中的错误。
(13)容量测试:检验软件的能力最高能达到什么程度的测试。
(14)互操作性测试:为验证不同软件之间的互操作能力而进行的测试。
(15)敏感性测试:为发现在有效输入类中可能引起某种不稳定性或不正常处理的某些数据的组合而进行的测试。
(16)标准符合性测试:验证软件与相关国家标准或规范(如军用标准、国家标准、行业标准及国际标准)一致性的测试。
(17)兼容性测试:验证软件在规定条件下与若干个实体共同使用或实现数据格式转换时能满足有关要求能力的测试。
(18)中文本地化测试:验证软件在不降低原有能力的条件下,处理中文能力的测试。
4、从执行过程是否需要人工干预来看
(1)手工测试:就是测试人员按照事先为覆盖被测软件需求而编写的测试用例,根据测试大纲中所描述的测试步骤和方法,手工地一个一个地输 入执行,包括与被测软件进行交互(如输入测试数据、记录测试结果等),然后观察测试结果,看被测程序是否存在问题,或在执行过程中是否会有一场发生,属于比较原始但是必须执行的一个步骤。
(2)自动化测试:实际上是将大量的重复性的测试工作交给计算机去完成,通常是使用自动化测试工具来模拟手动测试步骤,执行用某种程序设计语言编写的过程(全自动测试就是指在自动测试过程中,不需要人工干预,由程序自动完成测试的全过程;半自动测试就是指在自动测试过程中,需要手动输入测试用例或选择测试路径,再由自动测试程序按照人工指定的要求完成自动测试)
5、从测试实施组织看
(1)开发测试:开发人员进行的测试
(2)用户测试:用户方进行的测试
(3)第三方测试:有别于开发人员或用户进行的测试,由专业的第三方承担的测试,目的是为了保证测试工作的客观性
6、从测试所处的环境看
(1)阿尔法测试:是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试
(2)贝塔测试:是用户公司组织各方面的典型终端用户在日常工作中实际使用贝塔版本,并要求用户报告
扩展资料
软件测试的内容:
1 得到需求、功能设计、内部设计说书和其他必要的文档
2 得到预算和进度要求
3 确定与项目有关的人员和他们的责任、对报告的要求、所需的标准和过程 ( 例如发行过程、变更过程、等等 )
4 确定应用软件的高风险范围,建立优先级、确定测试所涉及的范围和限制
5 确定测试的步骤和方法 ── 部件、集成、功能、系统、负载、可用性等各种测试
6 确定对测试环境的要求 ( 硬件、软件、通信等 )
7 确定所需的测试用具 (testware) ,包括记录 / 回放工具、覆盖分析、测试跟踪、问题 / 错误跟踪、等等
8 确定对测试的输入数据的要求
9 分配任务和任务负责人,以及所需的劳动力
10 设立大致的时间表、期限、和里程碑
11 确定输入环境的类别、边界值分析、错误类别
12 准备测试计划文件和对计划进行必要的回顾
13 准备白盒测试案例
14 对测试案例进行必要的回顾 / 调查 / 计划
15 准备测试环境和测试用具,得到必需的用户手册 / 参考文件 / 结构指南 / 安装指南,建立测试跟踪过程,建立日志和档案、建立或得到测试输入数据
16 得到并安装软件版本
17 进行测试
18 评估和报告结果
19 跟踪问题 / 错误,并解决它
20 如果有必要,重新进行测试
21 在整个生命周期里维护和修改测试计划、测试案例、测试环境、和测试用具
参考资料:百度百科-软件测试
转载请注明出处51数据库 » 软件测试评测 软件测试和软件评测有什么不同