软件测试的缺陷包含哪些元素,有什么主要属性,有什么主要类型
软件测试分类 软件测试是一项复杂的系统工程,从不同的角度考虑可以有不同的划分方法,对测试进行分类是为了更好的明确测试的过程,了解测试究竟要完成哪些工作,尽量做到全面测试。
1,按是否需要执行被测软件的角度 按是否需要执行被测软件的角度,可分为静态测试和动态测试,前者不利用计算机运行待测程序而应用其他手段实现测试目的,如代码审核。
(我认为主要是让测试人员对编译器发现不了的潜在错误进行分析,如无效的死循环,多余的变量等),而动态测试则通过运行被测试软件来达到目的。
2、按阶段划分: 1 单元测试 单元测试是对软件中的基本组成单位进行的测试,如一个模块、一个过程等等。
它是软件动态测试的最基本的部分,也是最重要的部分之一,其目的是检验软件基本组成单位的正确性。
因为单元测试需要知道内部程序设计和编码的细节知识,一般应由程序员而非测试员来完成,往往需要开发测试驱动模块和桩模块来辅助完成单元测试。
因此应用系统有一个设计很好的体系结构就显得尤为重要。
一个软件单元的正确性是相对于该单元的规约而言的。
因此,单元测试以被测试单位的规约为基准。
单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。
2 集成测试 集成测试是在软件系统集成过程中所进行的测试,其主要目的是检查软件单位之间的接口是否正确。
它根据集成测试计划,一边将模块或其他软件单位组合成越来越大的系统,一边运行该系统,以分析所组成的系统是否正确,各组成部分是否合拍。
集成测试的策略主要有自顶向下和自底向上两种。
3 系统测试 系统测试是对已经集成好的软件系统进行彻底的测试,以验证软件系统的正确性和性能等满足其规约所指定的要求,检查软件的行为和输出是否正确并非一项简单的任务,它被称为测试的“先知者问题”。
因此,系统测试应该按照测试计划进行,其输入、输出和其他动态运行行为应该与软件规约进行对比。
软件系统测试方法很多,主要有功能测试、性能测试、随机测试等等。
4 验收测试 验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。
它的测试数据通常是系统测试的测试数据的子集。
所不同的是,验收测试常常有软件系统的购买者代表在现场,甚至是在软件安装使用的现场。
这是软件在投入使用之前的最后测试。
5 回归测试 回归测试是在软件维护阶段,对软件进行修改之后进行的测试。
其目的是检验对软件进行的修改是否正确。
这里,修改的正确性有两重含义:一是所作的修改达到了预定目的,如错误得到改正,能够适应新的运行环境等等;二是不影响软件的其他功能的正确性。
6 Alpha 测试:在系统开发接近完成时对应用系统的测试;测试后,仍然会有少量的设计变更。
这种测试一般由最终用户或其他人员员完成,不能由程序员或测试员完成。
7 Beta 测试:当开发和测试根本完成时所做的测试,而最终的错误和问题需要在最终发行前找到。
这种测试一般由最终用户或其他人员员完成,不能由程序员或测试员完成。
3、按测试方法划分: 1 白盒测试 白盒测试也称结构测试或逻辑驱动测试,是指基于一个应用代码的内部逻辑知识,即基于覆盖全部代码、分支、路径、条件的测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。
“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。
“白盒”法是穷举路径测试。
在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。
贯穿程序的独立路径数是天文数字。
但即使每条路径都测试了仍然可能有错误。
第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。
第二,穷举路径测试不可能查出程序中因遗漏路径而出错。
第三,穷举路径测试可能发现不了一些与数据相关的错误。
白盒测试可以借助一些工具来完成如Junit Framework,Jtest等。
2 黑盒测试 黑盒测试是指不基于内部设计和代码的任何知识,而基于需求和功能性的测试,黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。
黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等,主要用于软件确认测试。
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。
“黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。
实际上测试情况有无穷多个,人们不仅要测试所有...
软件测试中什么是缺陷消除率呢?
这个度量称为缺陷消除率(DRE),其定义为: DRE=测试期间发现的BUG数量(测试期间发现的BUG数量+未发现的BUG数量) 上述公式中,未发现的BUG数量通常等于客户发现的BUG数量(尽管客户也不可能发现所有的BUG)。
所以,分母就是可能发现的BUG数量。
要成功地运用这种度量,还必须清楚许多问题: 必须考虑BUG的严重程度和分布状况。
(有些组织将所有的缺陷同等对待,也即根据各个严重程度等级的比率差不多是恒定的这一原理,不引入严重程度)。
如何才能知道客户什么时候会发现所有的BUG?通常需要观察客户在以前的项目或版本中报告的缺陷的走势,以确定客户发现“绝大多数的”BUG所需要的时间。
如果他们在一年之后还会偶尔发现一个BUG,考试,大提示这个BUG可能并不会对度量造成重大的影响。
在某些应用系统中,特别是拥有较多用户的应用系统中,在几天之内就能报告绝大多数的BUG。
而另外一些拥有较少用户的系统则可能需要花费几个月的时间才能初步确定已经报告了绝大多数的BUG。
软件测试缺陷报告怎么写?有没有什么模版参考参考!
报告软件测试错误的目的是为了保证修复错误的人员可以重复报告的错误,从而有利于分析错误产生的原因,定位错误,然后修正之。
因此,报告软件测试错误的基本要求是准确、简洁、完整、规范。
需要掌握的报告技术归纳如下。
1. 描述 (Description),简洁、准确,完整,揭示错误实质,记录缺陷或错误出现的位置描述要准确反映错误的本质内容,简短明了。
为了便于在软件错误管理数据库中寻找制定的测试错误,包含错误发生时的用户界面(UI)是个良好的习惯。
例如记录对话框的标题、菜单、按钮等控件的名称。
2. 明确指明错误类型:布局、翻译、功能、双字节根据错误的现象,总结判断错误的类型。
例如,即布局错误、翻译错误、功能错误、双字节错误,这是最常见的缺陷或错误类型,其他形式的缺陷或错误也从属于其中某种形式。
3. 短行之间使用自动数字序号,使用相同的字体、字号、行间距短行之间使用自动数字序号,使用相同的字体、字号、行间距,可以保证各条记录格式一致,做到规范专业。
4. UI要加引号,可以单引号,推荐使用双引号UI加引号,可以容易区分UI与普通文本,便于分辨、定位缺陷或错误。
5. 每一个步骤尽量只记录一个操作保证简洁、条理井然,容易重复操作步骤。
6. 确认步骤完整,准确,简短保证快速准确的重复错误,“完整”即没有缺漏,“准确”即步骤正确,“简短”即没有多余的步骤。
7. 根据缺陷或错误类型,选择图象捕捉的方式为了直观的观察缺陷或错误现象,通常需要附加缺陷或错误出现的界面,以位图的形式作为附件附着在记录的“附件”部分。
为了节省空间,又能真实反映缺陷或错误本质,可以捕捉缺陷或错误产生时的全屏幕,活动窗口和局部区域。
为了迅速定位、修正缺陷或错误位置,通常要求附加中英文对照图。
8. 附加必要的特殊文档和个人建议和注解如果打开某个特殊的文档而产生的缺陷或错误,则必须附加该文档,从而可以迅速再现缺陷或错误。
有时,为了使缺陷或错误修正者进一步明确缺陷或错误的表现,可以附加个人的修改建议或注解。
9. 检查拼写和语法错误在提交每条缺陷或错误之前,检查拼写和语法,确保内容正确,正确的描述错误。
10. 尽量使用业界惯用的表达术语和表达方法使用业界惯用的表达术语和表达方法,保证表达准确,体现专业化。
11. 通用UI要统一、准确错误报告的UI要与测试的软件UI保持一致,便于查找定位。
12. 尽量使用短语和短句,避免复杂句型句式软件错误管理数据库的目的是便于定位错误,因此,要求客观的描述操作步骤,不需要修饰性的词汇和复杂的句型,增强可读性。
13. 每条错误报告只包括一个错误每条错误报告只包括一个错误,可以使错误修正者迅速定位一个错误,集中精力每次只修正一个错误。
校验者每次只校验一个错误是否已经正确修正。
软件测试中,Bug的缺陷的优先级和严重程度有没有相对应的关系,还...
更多的是站在软件开发工程师的角度考虑问题,因为缺陷的修正顺序是个复杂的过程,而且软件由于市场的压力必须尽快发布,此时即使缺陷的严重性很高,是否需要修正,优先级不一定高,某个标点符号丢失等,影响软件功能和性能的一般缺陷;3 -一般优先级,则可以参考下面的方法确定:1 –最高优先级,考虑缺陷对用户使用造成的恶劣后果的严重性。
优先级是表示处理和修正软件缺陷的先后顺序的指标,即哪些缺陷需要优先修正,哪些缺陷可以稍后修正,例如,本地化软件的某些字符没有翻译或者翻译不准确的缺陷;3 - 软件一般缺陷,例如,而一些严重性低的缺陷却需要及时处理。
严重性高说明缺陷对软件造成的质量危害性大,需要优先处理,即判断缺陷的严重性要为用户考虑,严重性程度高的软件缺陷具有较高的优先级,例如,软件的某个菜单不起作用或者产生错误的结果,需要全盘考虑。
另一方面,软件缺陷的严重性的判断应该从软件最终用户的观点做出判断,具有较高的优先级。
修正软件缺陷不是一件纯技术问题,有时需要综合考虑市场发布和质量风险等问题,造成数据丢失。
2 – 较严重的缺陷。
一般地,例如,软件的主要功能错误或者造成软件崩溃,数据丢失的缺陷。
2 – 较高优先级,例如,则可以参考下面的方法确定:1 – 非常严重的缺陷,例如,例如,某个控件没有对齐,而严重性低的缺陷可能只是软件不太尽善尽美,可以稍后处理,界面单词拼写错误,但是如果是软件名称或公司名称的拼写错误,则必须尽快修正,因为这关系到软件和公司的市场形象,如果软件缺陷的严重性很低,例如。
例如,如果某个严重的软件缺陷只在非常极端的条件下产生,则没有必要马上解决。
另外;4 – 低优先级,例如,软件的意外退出甚至操作系统崩溃。
但是,严重性和优先级并不总是一一对应。
有时候严重性高的软件缺陷,有些不是纯粹技术问题,而且开发人员更熟悉软件代码,能够比测试工程师更清楚修正缺陷的难度和风险。
缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。
它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式,如果修正一个软件缺陷,需要重新修改软件的整体架构,可能会产生更多潜在的缺陷在软件测试中。
对于缺陷的严重性,如果分为4级。
确定软件缺陷优先级;4 - 软件界面的细微缺陷;对于缺陷的优先性,如果分为4级,甚至不需要处理,本地化软件的某些字符没有翻译或者翻译不准确...
软件测试缺陷报告规范有哪些呢?
1. 描述 (Desciption),简洁、准确,完整,揭示错误实质,记录缺陷或错误出现的位置 描述要准确反映错误的本质内容,简短明了。
为了便于在软件错误管理数据库中寻找制定的测试错误,包含错误发生时的用户界面(UI)是个良好的习惯。
例如记录对话框的标题、菜单、按钮等控件的名称。
2. 明确指明错误类型:布局、翻译、功能、双字节 根据错误的现象,总结判断错误的类型。
例如,即布局错误、翻译错误、功能错误、双字节错误,这是最常见的缺陷或错误类型,其他形式的缺陷或错误也从属于其中某种形式。
3. 短行之间使用自动数字序号,使用相同的字体、字号、行间距 短行之间使用自动数字序号,使用相同的字体、字号、行间距,可以保证各条记录格式一致,做到规范专业。
4. UI要加引号,可以单引号,推荐使用双引号 UI加引号,可以容易区分UI与普通文本,便于分辨、定位缺陷或错误。
5. 每一个步骤尽量只记录一个操作 保证简洁、条理井然,容易重复操作步骤。
6. 确认步骤完整,准确,简短 保证快速准确的重复错误,“完整”即没有缺漏,“准确”即步骤正确,“简短”即没有多余的步骤。
7. 根据缺陷或错误类型,选择图象捕捉的方式
软件测试中,测试报告和缺陷报告区别在哪?有模板吗?
软件测试报告是一个全面性的报告,而缺陷报告只是软件测试报告中有关缺陷部分的报告。
软件测试是软件开发过程中的一个重要组成部分,是贯穿整个软件开发生命周期、对软件产品(包括阶段性产品)进行验证和确认的活动过程。
而测试报告就是把测试的过程和结果写成文档,对发现的问题和缺陷进行分析,为纠正软件的存在的质量问题提供依据,同时为软件验收和交付打下基础。
测试报告应包括:引言(测试目的、测试背景、参与人员、参考文献等)、测试实施概要(测试的环境、测试用例、范围等)、测试结果以及缺陷分析、测试结论等。
...