软件缺陷的优先级
严重性和优先级是表征软件测试缺陷的两个重要因素,它影响软件缺陷的统计结果和修正缺陷的优先顺序,特别在软件测试的后期,将影响软件是否能够按期发布与否。
对于软件测试初学者而言,或者没有软件开发经验的测试工程师,对于这两个概念的理解,对于它们的作用和处理方式往往理解的不彻底,实际测试工作中不能正确表示缺陷的严重性和优先级。
这将影响软件缺陷报告的质量,不利于尽早处理严重的软件缺陷,可能影响软件缺陷的处理时机。
什么是缺陷的严重性和优先级严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程度,即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。
在软件测试中,软件缺陷的严重性的判断应该从软件最终用户的观点做出判断,即判断缺陷的严重性要为用户考虑,考虑缺陷对用户使用造成的恶劣后果的严重性。
优先级是表示处理和修正软件缺陷的先后顺序的指标,即哪些缺陷需要优先修正,哪些缺陷可以稍后修正。
确定软件缺陷优先级,更多的是站在软件开发工程师的角度考虑问题,因为缺陷的修正顺序是个复杂的过程,有些不是纯粹技术问题,而且开发人员更熟悉软件代码,能够比测试工程师更清楚修正缺陷的难度和风险。
缺陷的严重性和优先级的关系缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。
它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。
一般地,严重性程度高的软件缺陷具有较高的优先级。
严重性高说明缺陷对软件造成的质量危害性大,需要优先处理,而严重性低的缺陷可能只是软件不太尽善尽美,可以稍后处理。
但是,严重性和优先级并不总是一一对应。
有时候严重性高的软件缺陷,优先级不一定高,甚至不需要处理,而一些严重性低的缺陷却需要及时处理,具有较高的优先级。
修正软件缺陷不是一件纯技术问题,有时需要综合考虑市场发布和质量风险等问题。
例如,如果某个严重的软件缺陷只在非常极端的条件下产生,则没有必要马上解决。
另外,如果修正一个软件缺陷,需要重新修改软件的整体架构,可能会产生更多潜在的缺陷,而且软件由于市场的压力必须尽快发布,此时即使缺陷的严重性很高,是否需要修正,需要全盘考虑。
另一方面,如果软件缺陷的严重性很低,例如,界面单词拼写错误,但是如果是软件名称或公司名称的拼写错误,则必须尽快修正,因为这关系到软件和公司的市场形象。
处理缺陷的严重性和优先级的常见错误正确处理缺陷的严重性和优先级不是件非常容易的事情,对于经验不是很丰富的测试和开发人员而言,经常犯的错误有以下几种情形:第一,将比较轻微的缺陷报告成较高级别的缺陷和高优先级,夸大缺陷的严重程度,经常给人“狼来了”的错觉,将影响软件质量的正确评估,也耗费开发人员辨别和处理缺陷的时间。
第二,将很严重的缺陷报告成轻微缺陷和低优先级,这样可能掩盖了很多严重的缺陷。
如果在项目发布前,发现还有很多由于不正确分配优先级造成的严重缺陷,将需要投入很多人力和时间进行修正,影响软件的正常发布。
或者这些严重的缺陷成了“漏网之鱼”,随软件一起发布出去,影响软件的质量和用户的使用信心。
因此,正确处理和区分缺陷的严重性和优先级,是软件测试人员和开发人员,以及全体项目组人员的一件大事。
处理严重性和优先级,既是一种经验技术,也是保证软件质量的重要环节,应该引起足够的重视。
如何表示缺陷的严重性和优先级缺陷的严重性和优先级通常按照级别划分,各个公司和不同项目的具体表示方式有所不同。
为了尽量准确的表示缺陷信息,通常将缺陷的严重性和优先级分成4级。
如果分级超过4级,则造成分类和判断尺度的复杂程度,而少于4级,精确性有时不能保证。
具体的表示方法机可以使用数字表示,也可以使用文字表示,还可以数字和文字综合表示。
使用数字表示通常按照从高到底或从低到高的顺序,需要软件测试前达成一致。
例如,使用数字1,2,3,4分别表示轻微、一般、较严重和非常严重的严重性。
对于优先级而言,1,2,3,4可以分标表示低优先级、一般、较高优先级和最高优先级。
如何确定缺陷的严重性和优先级通常由软件测试人员确定缺陷的严重性,由软件开发人员确定优先级较为适当。
但是,实际测试中,通常都是由软件测试人员在缺陷报告中同时确定严重性和优先级。
确定缺陷的严重性和优先级要全面了解和深刻体会缺陷的特征,从用户和开发人员以及市场的因素综合考虑。
通常功能性的缺陷较为严重,具有较高的优先级,而软件界面类缺陷的严重性一般较低,优先级也较低。
对于缺陷的严重性,如果分为4级,则可以参考下面的方法确定:1 – 非常严重的缺陷,例如,软件的意外退出甚至操作系统崩溃,造成数据丢失。
2 – 较严重的缺陷,例如,软件的某个菜单不起作用或者产生错误的结果; 3 - 软件一般缺陷,例如,本地化软件的某些字符没有翻译或者翻译不准确; 4 -软件界面的细微缺陷,例如,某个控件没有对齐,某个标点符号丢失等;对于缺陷的优先性,如果分为4级,则可以参考下面的方法确定:1 –最高优先级,例如,...
测试能证明软件没有任何缺陷么
原则1——测试显示缺陷的存在,但不能证明系统不存在缺陷。
测试可以减少软件中存在未被发现缺陷的可能性,但即使测试没有发现任何缺陷,也不能证明软件或系统是完全正确的。
2)原则2——穷尽测试是不可能的。
由于有太多的输入组合、有太多的路径,而且时间是有限的,无法做到完全的测试(100%测试覆盖率)。
通过运用风险分析和不同系统功能的测试优先级,来确定测试的关注点,从而替代穷尽测试。
3)原则3——测试尽早介入。
软件项目一启动,软件测试就应开始,也就是从项目启动的第一天开始,测试人员就应参与项目的各种活动和开展对应的测试活动。
测试工作进行得越早,软件开发的劣质成本就越低,并能更好地保证软件质量。
例如,在代码完成之前,可以进行各种静态测试,主导或积极参与需求文档、产品规格说明书等的评审,将问题消灭在萌芽阶段。
4)原则4——缺陷集群性。
版本发布前进行测试所发现的大部分缺陷和软件运行失效是由于少数软件模块引起的。
一段程序中发现的错误数越多,意味着这段程序的质量越不好。
错误集中发生的现象,可能和程序员的编程水平、经验和习惯有很大的关系,也可能是程序员在写代码时情绪不够好或不在状态等。
如果在同样的测试效率和测试能力的条件下,缺陷发现得越多,漏掉的缺陷就越多。
这也就是著名的Myers 反直觉原则:在测试中发现缺陷多的地方,会有更多的缺陷没被发现。
假定测试能力不变,通过测试会发现产品中90%的缺陷。
如果在模块A 发现了180 个缺陷,在模块B 发现了45 个缺陷,意味着模块A 还有20 个缺陷没被发现,而模块B 只有5个缺陷未被发现。
所以,对发现错误较多的程序段,应进行更深入的测试。
软件测试时问我在生活中哟哦你过得软件有什么缺陷,我应该怎么回答...
所以有问题,有不明白的地方让用户早提,否则到最后大家都很被动。
第二:重点评审需求中不明确的功能模块和存在分歧的模块,对于不明白的地方一定要弄懂,因为需求是软件开发的源头。
第三:对于一些重点模块和用户业务常用的模块,要重点评审,比如说我以前做无线POS机的系统,“销售”这个功能当然是重重之重了。
你看看SAP的研发精要中人家是怎么做的:①自我测试,要求开发人员在完成自已负责的模块后,马上进行测试,消除模块内部的错误;②相互测试,要求开发人员之间测试对方的模块,由于不同开发人员的思维、开发方式的不同,对方会很容易找到一些自已很难发现的问题;③代码检查,通常是由资深开发人员及开发经理来进行,从模块功能、性能、可用性、编码规范、模块集成性等角度进行全面检查。
这一工作会在系统实现的各个阶段定期进行。
SAP还提供了如CATT等辅助测试工具。
第五:测试人员最好能做到交叉测试,因为测试人员毕竟考虑问题产生思维定势,能做到交叉测试,最好了。
第六:要尽可能模拟用户的真实使用环境,进行测试。
第七:在测试阶段要弄到用户的真实数据进行测试,因为有一些Bug,只有用用户的真实数据才能测试出来,测试人员自己造一些数据是测试不出来的。
这一点我在测试欧莱雅系统的时候深有体会。
第八:要做好各个阶段的评审,比如代码评审,设计评审,测试用例评审,最后发布产品阶段的评审。
因为评审是预防软件缺陷的一个重要的手段了。
第九:要做好性能测试。
另外,补充一点:不要把测试阶段和发布阶段的版本弄错了。
软件缺陷的分类标准
1.缺陷标识(Identifier): 缺陷标识是标记某个缺陷的一组符号。
每个缺陷必须有一个唯一的标识。
2.缺陷类型 (Type): 缺陷类型是根据缺陷的自然属性划分的缺陷种类。
3.缺陷严重程度 (Severity) :缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
4.缺陷优先级(Priority): 缺陷的优先级指缺陷必须被修复的紧急程度。
5.缺陷状态(Status) :缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
6.缺陷起源(Origin) :缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。
7.缺陷来源(Source): 缺陷来源指引起缺陷的起因。
8.缺陷根源(Root Cause): 缺陷根源指发生错误的根本因素。
F- Function :影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。
并且设计文档需要正式的变更。
如逻辑,指针,循环,递归,功能等缺陷。
A- Assignment: 需要修改少量代码,如初始化或控制块。
如声明、重复命名,范围、限定等缺陷。
I- Interface: 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。
C- Checking: 提示的错误信息,不适当的数据验证等缺陷。
B Build/package/merge :由于配置库、变更管理或版本控制引起的错误。
D- Documentation: 影响发布和维护,包括注释。
G- Algorithm :算法错误。
U-User Interface:人机交互特性:屏幕格式,确认用户输入,功能有效性,页面排版等方面的缺陷。
P-Performance:不满足系统可测量的属性值,如:执行时间,事务处理速率等。
N-Norms:不符合各种标准的要求,如编码标准、设计符号等。
软件测试错误严重程度1.Critical:不能执行正常工作功能或重要功能。
或者危及人身安全。
2.Major:严重地影响系统要求或基本功能的实现,且没有办法更正。
(重新安装或重新启动该软件不属于更正办法)3.Minor:严重地影响系统要求或基本功能的实现,但存在合理的更正办法。
(重新安装或重新启动该软件不属于更正办法)4.Cosmetic:使操作者不方便或遇到麻烦,但它不影响执行工作功能或重要功能。
5.Other:其它错误。
同行评审错误严重程度1.Major:主要的,较大的缺陷2.Minor:次要的,小的缺陷 1.Resolve Immediately:缺陷必须被立即解决。
2.Normal Queue:缺陷需要正常排队等待修复或列入软件发布清单。
3.Not Urgent:缺陷可以在方便时被纠正。
1.Submitted: 已提交的缺陷2.Open :确认“提交的缺陷”,等待处理3.Rejected: 拒绝“提交的缺陷”,不需要修复或不是缺陷4.Resolved :缺陷被修复5.Closed :确认被修复的缺陷,将其关闭 1.Requirement:在需求阶段发现的缺陷2.Architecture:在构架阶段发现的缺陷3.Design:在设计阶段发现的缺陷4.Code:在编码阶段发现的缺陷5.Test:在测试阶段发现的缺陷 1.Requirement: 由于需求的问题引起的缺陷2.Architecture: 由于构架的问题引起的缺陷3.Design: 由于设计的问题引起的缺陷4.Code: 由于编码的问题引起的缺陷5.Test: 由于测试的问题引起的缺陷6.Integration: 由于集成的问题引起的缺陷
关于软件测试的问题。
大家帮帮忙。
。
。
谢谢
一、判断题(每题1分,12 分,正确的√,错误的╳) 1.软件测试的目的是尽可能多的找出软件的缺陷。
(对) 2.Beta 测试是验收测试的一种。
(错) 3.验收测试是由最终用户来实施的。
(错) 4.项目立项前测试人员不需要提交任何工件。
(错) 5.单元测试能发现约80%的软件缺陷。
(错) 6.代码评审是检查源代码是否达到模块设计的要求。
(错)7.自底向上集成需要测试员编写驱动程序。
(错)8.负载测试是验证要检验的系统的能力最高能达到什么程度。
(错)9.测试人员要坚持原则,缺陷未修复完坚决不予通过。
(对)10.代码评审员一般由测试员担任。
(错) 11.我们可以人为的使得软件不存在配置问题。
(错) 12.集成测试计划在需求分析阶段末提交。
(对) 二、不定项选择题(每题2 分,10分) 1.软件验收测试的合格通过准则是:(A\B\C\D)A. 软件需求分析说明书中定义的所有功能已全部实现,性能指标全部达到要求。
B. 所有测试项没有残余一级、二级和三级错误。
C. 立项审批表、需求分析文档、设计文档和编码实现一致。
D. 验收测试工件齐全。
2.软件测试计划评审会需要哪些人员参加?(A\B\D) A.项目经理 B.SQA 负责人 C.配置负责人 D.测试组 3.下列关于alpha 测试的描述中正确的是:(B\D) A.alpha 测试需要用户代表参加 B.alpha 测试不需要用户代表参加 C.alpha 测试是系统测试的一种 D.alpha 测试是验收测试的一种 4.测试设计员的职责有:(A\B\C) A.制定测试计划 B.设计测试用例 C.设计测试过程、脚本 D.评估测试活动 5.软件实施活动的进入准则是:(A) A.需求工件已经被基线化 B.详细设计工件已经被基线化 C.构架工件已经被基线化 D.项目阶段成果已经被基线化 其实答不对也没有什么关系的,主要交流的时候,你能有自已的见解就可以了。