软件测试整理(博彦科技)_第1页
软件测试整理(博彦科技)_第2页
软件测试整理(博彦科技)_第3页
软件测试整理(博彦科技)_第4页
软件测试整理(博彦科技)_第5页
全文预览已结束

下载本文档

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

文档简介

软件生命周期1、 软件生存周期(SystemsDevelopmentLifeCycle)(6阶段):可行性分析与开发项计划(问题的定义及规划)、需求分析、软件设计(概要设计和详细设计)、程序编码、软件测试、运行维护等活动。2、 周期模型:典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型。瀑布模型(WaterfallModel)首先由Royce提出。在该模型中,首先确定需求,并接受客户和SQA小组的验证。然后拟定规格说明,同样通过验证后,进入计划阶段••可以看出,瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样,瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。迭代式模型迭代式模型是是RUP(RationalUnifiedProcess,统一软件开发过程,统一软件过程)推荐的周期模型,也是我们在这个系列文章讨论的基础。在RUP中,迭代被定义为:迭代包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和要使用该发布必需的所有其他外围元素。所以,在某种程度上,开发迭代是一次完整地经过所有工作流程的过程:(至少包括)需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上,它类似小型的瀑布式项目。RUP认为,所有的阶段(需求及其它)都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。迭代和瀑布的区别迭代和瀑布的最大的差别就在于风险的暴露时间上。由于瀑布模型的特点(文档是主体),很多的问题在最后才会暴露出来,为了解决这些问题的风险是巨大的。"在迭代式生命周期中,您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件,这样就可以核实是否已经降低了目标风险。"快速原型模型快速原型(RapidPrototype)模型在功能上等价于产品的一个子集。注意,这里说的是功能上。瀑布模型的缺点就在于不够直观,快速原型法就解决了这个问题。一般来说,根据客户的需要在很短的时间内解决用户最迫切需要,完成一个可以演示的产品。这个产品只是实现部分的功能(最重要的)。它最重要的目的是为了确定用户的真正需求。在得到用户的需求之后,原型将被抛弃。因为原型开发的速度很快,设计方面是几乎没有考虑的,如果保留原型的话,在随后的开发中会为此付出极大的代价。至于保留原型方面,也是有一种叫做增量模型是这么做的,但这种模型并不为大家所接受。上述的模型中都有自己独特的思想,其实现在的软件组织中很少说标准的采用那一种模型的。模型和实用还是有很大的区别的。软件缺陷软件缺陷(Defect),常常又被叫做Bug。所谓软件缺陷,即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义:从产品内部看,缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题;从产品外部看,缺陷是系统所需要实现的某种功能的失效或违背。软件缺陷产生的原因1)需求的不完善定义4)逻辑设计错误7)测试过程不足1)需求的不完善定义4)逻辑设计错误7)测试过程不足5)编码错误 (6)不符合文档编制与编码规定8)规程错误 (9)文档编制错误判断软件缺陷的规则(软件缺陷的类型)(1)软件未达到产品规格说明书(需求)标明的功能(2)软件出现了规格说明书指明不会出现的错误(3)软件功能超出规格说明书指明的的范围(4)软件未达到规格说明书虽未指出但应达到的目标(隐含需求)(5)软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好(6)需要注意的是,测试人员报告Bug时,应该保证Bug是可以重现的(对于有时不可重现的Bug,应当反复测试,直到最终确定Bug的发生场景为止)Bug记录一条Bug记录最基本的应包含:编号、Bug所属模块、Bug描述、Bug级别、发现日期、发现人、修改日期、修改人、修改方法、回归结果等,要有效的发现Bug需参考需求以及详细设计等前期文档设计出高效的测试用例,然后严格执行测试用例,对发现的问题要充分确认肯定,描述的要求高,提供的信息多且准确,然后再向外发布,才能提高提交Bug的质量。软件的缺陷等级(1) 微小的(Minor)。一些小问题如有个别错别字、文字排版不整齐等,对功能几乎没有影响,软件产品仍可使用。(2) —般的(Major)。不太严重的错误,如次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等。(3) 严重的(Critical)。严重错误,指功能模块或特性没有实现,主要功能部分丧失,次要功能全部丧失,或致命的错误声明。(4) 致命的(Fatal)。致命的错误,造成系统崩溃、死机,或造成数据丢失、主要功能完全当开发人员说不是BUG时,你如何应付?如果确实是自己理解错误,则承认错误,没什么大不了;如果是需求不明,请项目经理补充清楚;如果双方理解不一致,且都不能互相说服,则请项目经理判断。软件测试软件质量保证(SQA)软件质量保证是通过确保软件过程的质量,来保证软件产品的质量。软件质量保证人员和开发人员之间具有管理上的严格的独立性,两个小组的管理员都不能越权管理另一组,但都可以向更高层的管理者汇报软件开发中的问题。软件测试软件测试是为了发现程序中的错误而执行程序的过程;但发现错误不是软件测试的唯一目的测试人员在软件开发过程中的任务(1)寻找Bug;(2)避免软件开发过程在的缺陷;(3)衡量软件的品质;(4)关注用户的需求。总的目标是:确保软件的质量。软件测试结束的标准(1)用例全部测试;(2)覆盖率达到标准(3)缺陷率达到标准;(4)其他指标达到质量标准。软件测试活动的阶段和生命周期阶段:单元测试、集成测试、系统测试、验收测试单元测试是对软件中的基本组成单位进行的测试,如一个模块、一个过程等等。它是软件动态测试的最基本的部分,也是最重要的部分之一,其目的是检验软件基本组成单位的正确性。集成测试是在软件系统集成过程中所进行的测试,其主要目的是检查软件单位之间的接口是否正确。系统测试是对已经集成好的软件系统进行彻底的测试,以验证软件系统的正确性和性能等满足其规约所指定的要求,检查软件的行为和输出是否正确并非一项简单的任务,它被称为测试的“先知者问题”。验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集.生命周期:计划、测试设计、用例设计、执行、评估计划:对整个测试周期中所有活动进行规划,估计工作量、风险,安排人力物力资源,安排进度等;设计:完成测试方案,从技术层面上对测试进行规划;实现:进行测试用例和测试规程设计;执行:根据前期完成的计划、方案、用例、规程等文档,执行测试用例;总结:记录测试结果,进行测试分析,完成测试报告。测试用例(TestCase)和测试规程测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。一个测试用例就是测试人员用以测试被测软件的某个特性或特性组合的一组数据,这组数据可能是从用户处得来的实际的一组数据,也可能是测试人员专门设计出来的测试软件某些功能的一组数据。测试规程就是详细的对测试用例设计方法、测试方法、测试工具、测试环境和测试数据进行描述的文档。还可以包括能把某个或某一组测试用例应用到被测软件上完成某项测试的一系列的操作步骤。设计测试用例应当从以下几个方面考虑:边界值、等价类划分、有效/无效值等。测试原则软件开发人员即程序员应当避免测试自己的程序应尽早地和不断地进行软件测试对测试用例要有正确的态度:第一,测试用例应当由测试输入数据和预期输出结果这两部分组成;第二,在设计测试用例时,不仅要考虑合理的输入条件,更要注意不合理的输入条件。人以群分,物以类聚,软件测试也不例外,一定要充分注意软件测试中的群集现象,也可以认为是“80-20原则”。严格执行测试计划,排除测试的随意性,以避免发生疏漏或者重复无效的工作。应当对每一个测试结果进行全面检查。(7)妥善保存测试用例、测试计划、测试报告和最终分析报告,以备回归测试及维护之用。在遵守以上原则的基础上进行软件测试,可以以最少的时间和人力找出软件中的各种缺陷,从而达到保证软件质量的目的。测试目标发现可以通过测试避免的开发风险的规模和来源;实施测试来降低所发现的风险; (3)确定测试何时可以结束;(4)在开发项目的过程中将测试看作是一个标准项目。软件测试的具体内容软件测试主要工作内容是验证(verification)和确认(validation),下面分别给出其概念:验证(verification)是保证软件正确地实现了一些特定功能的一系列活动,即保证软件以正确的方式来做了这个事件(Doitright)确认(validation)是一系列的活动和过程,目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件做了你所期望的事情。(Dotherightthing)1•静态确认,不在计算机上实际执行程序,通过人工或稈序分析来证明软件的正确性:2•动态确认,通过执行程序做分析,测试程序的动态行为,以证实软件是否存在问题。软件测试的对象不仅仅是程序测试,软件测试应该包括整个软件开发期间各个阶段所产生的文档,如需求规格说明、概要设计文档、详细设计文档,当然软件测试的主要对象还是源程序。测试用例设计工作的关键?白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题白盒测试、黑盒测试?白盒测试:已知产品的内部工作过程,可以通过测试证明每种内部操作是否符合设计规格要求,所有内部成分是否经过检查。黑盒测试:已知产品的功能设计规格,可以通过测试证明每个实现了的功能是否符合要求白盒测试,英文是WhiteBoxTesting。又称结构测试或者逻辑驱动测试。利用白盒测试法进行动态测试时,需要测试软件产品的内部结构和处理过程,不需测试软件产品的功能。白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。白盒测试是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。白盒测试常用工具有:Jtest、VcSmith、Jcontract、C++Test、CodeWizard、logiscope。黑盒测试-功能测试-数据驱动测试黑盒测试,英文是BlackBoxTesting。又称功能测试或者数据驱动测试。黑盒测试是根据软件的规格对软件进行的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。软件测试人员以用户的角度,通过各种输入和观察软件的各种输岀结果来发现软件存在的缺陷,而不关心程序具体如何实现的一种软件测试方法。黑盒测试常用工具有:AutoRunner、winrunner、loadrunner。软件验收测试:Alpha测试(a测试)、Beta测试(B测试)、第三方验收测试a测试,英文是Alphatesting。又称Alpha测试.Alpha测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由该系统的程序员或测试员完成。在系统开发接近完成时对应用系统的测试;测试后,仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成,不能由程序员或测试员完成。B测试,英文是Betatesting。又称Beta测试,用户验收测试(UAT)。B测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。当开发和测试根本完成时所做的测试,而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成。软件测试工具(1)软件错误管理工具Bugzilla (2)功能测试工具WinRunner(3)负载测试工具LoadRunner (4)测试管理工具TestDirector文件格式系统有哪几种类型?分别说说win95、win98、winMe、w2k、winNT、winXP分别支持那些文件系统。FAT(FileAllocationTable是“文件分配表”的意思。对我们来说它的意义在于对硬盘分区的管理。FAT16、FAT32、NTFS是目前最常见的三文件系统。Win95:FAT16和FAT32Win98:FAT16,FAT32winMe:FAT16,FAT32w2k:FAT16,FAT32,NTFSwinNT:FAT16/FAT32/NTFSwinXP:FAT16,FAT32,NTFS本地化测试,英文是Localizationtesting。本地化就是将软件版本语言进行更改,比如将英文的windows改成中文的windows就是本地化。本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试,安装/卸载测试,当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量,包含软件

温馨提示

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

评论

0/150

提交评论