缺陷的优先级和严重性定义
我们可以简单地将软件缺陷的严重性划分为4个等级，如表11-1所示。
1.严重性（Severity）
严重性说明
1 严重缺陷。系统无法满足基本的商业要求且没有便捷可用的工作区。性能、功能或使用方面严重不达标
2 一般缺陷。系统能够满足商业要求。有快捷方便的工作区可供使用。性能、功能或使用方面并不是严重不达标
3 微小缺陷。微小修改，希望提出建议，最好能够修正，但不是必需的。在发布准确性或实用性方面不会产生重大影响
2．优先级（Priority）
小组中使用的主观对任务和工作项排定优先次序评级。与严重性结合在一起来评定可见度、变更、风险修复等。（A "subjective" rating used by groups to prioritize tasks and work items.
A combination of Severity with the visibility, workarounds, fix risk, etc... subjective importance）（1）优先级0（Priority 0）
?这类软件缺陷必须在24小时之内被解决（These bugs need to be resolved within 24
hours）：
?问题导致了中断或者阻止了产品的正常版本编译（Issues that break or prevent a
product build）
?问题导致了阻止了BVT和其他测试自动化的运行（Issues that prevent BVTs and
other test automation）
?问题导致了无法成功构建国内和全球文档（Issues that keep production from
successfully building Domestic and International Doc Builds）
?由于粗心丢失内容，如文档文件、命名空间（Unintentionally dropped out content, e.g.
doc file, namespace）
（2）优先级1（Priority 1）
?这类软件缺陷必须修复然后才能发布产品或者才能达到用户体验所包含的最主要
目标（Bugs that must be fixed in order to ship the product or achieve UE's top/main
goals）：
?高法律风险；地域相关；版权，商标，准许法令（High Legal risk; Geopolitical,
Copyright, Trademark, Consent Decree）
?高风险编码实践（High risk security coding practices）
?问题导致了对客户和/或本公司的重大影响（Issues with significant impact on
customers and/or the company）
?对用户/产品关键的用于描述场景的新文档和/或新特性（New documentation for
scenarios and/or new features that are crucial to customers and/or the product）
?辅助访问主题的元数据的变更；搜索，属性F1和索引问题（Metadata changes to help
access topics; search, attributes, F1 and indexing issues）
?在目标命名空间中的代码样例/代码片段（Code samples/snippets in targeted
namespaces）
?过多从参考文档到概念性文档的引用（More linking of reference docs to conceptual
docs ）
?在顶层页面/节点发现的问题，例如在首页，门户上发现的问题（Issue found on top
level pages/node,e.g., homepage, portal）
?在大标题上存在的问题（Issue appears in a large number of topics through out the doc
set）
?技术性的不正确的内容（Technically incorrect content）
（3）优先级2（Priority 2）
?软件缺陷应该被修复（Bugs that should be fixed）：
?对客户和产品不是那么关键性的场景或者特性（Scenarios or features that are not
crucial to customers or the product）
?从先前版本来的内容修复（Fixing content from previous releases）
?非目标命名空间中代码样例/代码片段（Code samples/snippets in non targeted
namespaces）
?在中等级页面/节点中发现的缺陷（Bug found in mid level pages/nodes）
?在小标题上存在的问题（Bug appears in a significant number of topics through out the
doc set）
（4）优先级3（Priority 3）
?如果修复这个缺陷会比较好（Bugs that would be good to fix）：
?目录问题（Table of Contents issues）
?先前版本中未完成的文档（Incomplete documentation from previous releases）
?重写或重新格式化原本正确的文档，为了让它更清晰，更容易阅读（Rewriting or
reformatting correct content to make it clearer, easier to read）
?在视觉上影响到用户但是但不影响阅读（Issues that visually impacts the customer but
won't affect the readability or use of the topic）
?最佳实践修复（Best practice fixes）
?代码样例/代码片段（Code samples/snippets）
?在低级的页面中/节点中发现的问题（Issues found in low level pages/nodes）
?被阅读很少的主题（Issues found in a small number of topics）
（5）优先级4（Priority 4）
?如果修复这个缺陷我们的工作就算是达到精细的程度，这种问题比较细小，可以被推迟
处理（Bugs that would be nice to fix, are trivial and can be postponed）：
?在文档中藏得比较深的问题（Issues buried in the docs）
?仅在一个话题中有的问题（Issues found in only one topic ）
?对用户影响比较小的问题（Issues with low to no customer impact）
?如果要修复这个问题导致的本地化的投入要比对用户的获益高得多（Issues with a high
localization cost versus customer gain）
C语言运算符的结合性分析 吴琼( 鄂州大学计算机系, 湖北鄂州) C 语言与其他高级语言相比, 一个显著的特点就是其运算符特别丰富, 共有34 种运算符。C 语言将这34 种运算符规定了不同的优先级别和结合性。优先级是用来标识运算符在表达式中的运算顺序的, 在求解表达式的值的时候, 总是先按运算符的优先次序由高到低进行操作, 可是, 当一个运算对象两侧的运算符优先级别相同时, 则按运算符的结合性来确定表达式的运算顺序。 运算符的结合性指同一优先级的运算符在表达式中操作的组织方向, 即: 当一个运算对象两侧运算符的优先级别相同时, 运算对象与运算符的结合顺序, C 语言规定了各种运算符的结合方向( 结合性) 。大多数运算符结合方向是“自左至右”, 即: 先左后右, 例如a- b+c, b 两侧有- 和+两种运算符的优先级相同, 按先左后右结合方向, b 先与减号结合, 执行a- b 的运算, 再执行加c 的运算。除了自左至右的结合性外, C 语言有三类运算符参与运算的结合方向是从右至左。即: 单目运算符, 条件运算符, 以及赋值运算符。关于结合性的概念在其他高级语言中是没有的, 这是C语言的特点之一,特别是从右至左结合性容易出错, 下面通过几个具体的运算符来剖析C 语言运算符的结合性。 若a 是一个变量, 则++a 或a++和- - a 或a- - 分别称为前置加或后置加运算和前置减或后置减运算, 且++a 或a++等价于a=a+1, - - a 或a- - 等价于a=a- 1, 即都是使该变量的值增加1 或减少1。由此可知, 对一个变量实行前置或后置运算, 其运算结构是相同的, 但当它们与其他运算结合在一个表达式中时, 其运算值就不同了。前置运算是变量的值先加1 或减1, 然后将改变后的变量值参与其他运算, 如x=5; y=8; c=++x*y; 运算后, c 的值是48,x 的值是6,y 的值是8。而后置运算是变量的值先参与有关运算, 然后将变量本身的值加1 减1, 即参加运算的是该变量变化前的值。如x=5; y=8; c=x++*y;运算后, c 的值是40,x 的值是6, y 的值是8。值得注意的是, 前置、后置运算只能用于变量, 不能用于常量和表达式, 且结合方向是从右至左。如当i=6 时, 求- i++的值和i 的值。由于“- ”(负号) “++”为同一个优先级, 故应理解为- (i++), 又因是后置加, 所以先有- i++的值为- 6, 然后i 增值1 为7, 即i=7。 例1 main() {int a=3,b=5,c; c=a*b+++b; printf ( “c=%d”, c);} 要得出c 的值, 首先要搞清+++的含义。++运算符的结合方向是自右向左的, 如果将表达式理解为:c=a*b+(++b);实际上C 编译器将表达式处理为:c=(a*b++)+b, 因为C 编译器总是从左至右尽可能多地将若干个字符组成一个运算符, 如i+++j 等价于(i++)+j。接下来是解决a*b++的问题, 因为++运算符的运算对象只能是整型变量而不能是表达式或常数, 所以a*b++显然是a*(b++)而非(a*b)++, 因此整个表达式就是c=(a*(b++))+b。 例2 main() { int i=1,j; j=i+++i+++i++; printf( “i=%d,j=%d\n”, i,j);} 例3 main() { int i=1,m; m=++i+++i+++i; printf( “i=%d,m=%d\n”, i,m);}
Bug说明文档2015年6月25日
修订历史记录 （A-添加，M-修改，D-删除）
目录 1.简介 (4) 1.1.编写目的 (4) 1.2.文档范围 (4) 1.3.预期读者 (4) 2.BUG优先级(PRIORITY) (4) 2.1.I MMEDIATE（立刻）——P1 (4) 2.2.U RGENT（紧要、优先）——P2 (4) 2.3.V ERY H IGH(高度重视)——P3 (5) 2.4.H IGH（重视）——P4 (5) 2.5.N ORMAL（正常）——P5 (5) 2.6.L OW（稍缓）——P6 (5) 3.BUG严重程度(SEVERITY) (5) 4.BUG状态及流转 (6) 4.1.B UG状态及说明 (6) 4.2.B UG状态流转方式 (7) 5.BUG内容 (8)
1. 简介 1.1. 编写目的 本文档主要确定bug优先级、bug严重程度、bug流转方式、bug内容。 1.2. 文档范围 Bug优先级和bug严重程度的定义，bug流转方式和bug内容的确定。 1.3. 预期读者 本文档阅读人员包括项目经理、开发人员、测试人员以及其他相关人员。 2. Bug优先级(Priority) 优先级大致分为6个级别P1~P6，P1~P6分别为： Immediate（立刻）、Urgent （紧要、优先）、Very High（高度重视）、High（高度重视）、Normal（正常）、Low （稍缓）。 2.1. Immediate（立刻）——P1 即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。2.2. Urgent（紧要、优先）——P2 即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。
C++的优先级 优先级操作符结合性 1 :: 左 2 . -> [] () 左 3 ++ -- ~ ! - + & * () sizeof new delete castname_cast
符号功能 + 单目正 - 单目负 * 乘法 / 除法 % 取模 + 加法 - 减法 下面是一些赋值语句的例子，在赋值运算符右侧的表达式中就使用了上面的算术运算符： Area=Height*Width; num=num1+num2/num3-num4; 运算符也有个运算顺序问题，先算乘除再算加减。单目正和单目负最先运算。取模运算符(%)用于计算两个整数相除所得的余数。例如： a=7%4; 最终a的结果是3，因为7%4的余数是3。 那么有人要问了，我要想求它们的商怎么办呢？ b=7/4; 这样b就是它们的商了，应该是1。 也许有人就不明白了，7/4应该是1.75，怎么会是1呢？这里需要说明的是，当两个整数相除时，所得到的结果仍然是整数，没有小数部分。要想也得到小数部分，可以这样写7.0/4或者7/4.0，也即把其中一个数变为非整数。 那么怎样由一个实数得到它的整数部分呢？这就需要用强制类型转换了。例如：a=(int) (7.0/4); 因为7.0/4的值为1.75，如果在前面加上(int)就表示把结果强制转换成整型，这就得到了1。那么思考一下a=(float) (7/4);最终a的结果是多少？ 单目减运算符相当于取相反值，若是正值就变为负值，若是负数就变为正值。单目加运算符没有意义，纯粹是和单目减构成一对用的。 三、逻辑运算符 逻辑运算符是根据表达式的值来返回真值或是假值。其实在C语言中没有所谓的真值和假值，只是认为非0为真值，0为假值。 符号功能 && 逻辑与 || 逻辑或 ! 逻辑非 当表达式进行&&运算时，只要有一个为假，总的表达式就为假，只有当所有都为真时，总的式子才为真。当表达式进行||运算时，只要有一个为真，总的值就为真，只有当所有的都为假时，总的式子才为假。逻辑非(!)运算是把相应的变量
有限公司 软件质量BUG等级定义 版本<1.1>
修订历史记录
1、对Bug严重程度的分级 缺陷级别定义 A类――致命BUG 包括以下各种错误： 1．由于程序所引起的死机,非法退出。 2．程序死循环。 3．数据库发生死锁。 4．与数据库连接错误。 5．主要功能没有实现。 6．因错误操作导致的程序中断。 B类――严重BUG 包括以下各种错误： 1.程序错误但不影响系统和其它程序运行的。 2.程序接口错误。 3.数据库的表、业务规则、缺省值未加完整性等约束条件。 4.次要功能没有实现或间接发生的（经过几步不相关操作后发生的）导致主要需求不 能实现。 5.主要界面的文字错误等。 6.功能错误。 C类—一般性错误 包括以下各种错误： 1．非主要操作界面错误（包括数据窗口内列名定义、含义是否一致） 2．间接发生的（经过几步不相关操作后发生的）导致次要需求不能正常实现。 3．打印内容、格式错误 4．简单的输入限制未放在前台进行控制 D类—较小错误 包括以下各种错误：不影响软件的功能，但影响软件的品质。 1．界面不规范 2．辅助说明描述不清楚 3．输入输出不规范 4．长操作未给用户提示 5．提示窗口文字未采用行业术语 6．可输入区域和只读区域没有明显的区分标志 E类—测试建议 测试人员从测试角度对软件提出的合理化的改进建议，由项目经理决定是否采纳。 2、对Bug现在程度的分级
每次出现：出现概率100%； 经常出现：出现概率大于20%； 很少出现：出现概率小于20%； 出现一次：在整个测试工作中只出现一次。 3、测试人员对软件的评估 测试人员对软件的评估主要依据测试计划中所制定的输出准则和最后遗留的Bug状况。 A类－－致命Bug，一般认为发布的软件中不允许存在。 B类－－严重Bug，每一万行代码中允许遗留2－3条。 C类－一般性Bug，每一万行代码中允许遗留3－6条。 D类－一较小Bug，由项目经理决定注销或遗留。 E类－一测试建议，由项目经理决定注销或遗留。
优先级从上到下依次递减，最上面具有最高的优先级，逗号操作符具有最低的优先级。 所有的优先级中，只有三个优先级是从右至左结合的，它们是单目运算符、条件运算符、赋值运算符。其它的都是从左至右结合。 具有最高优先级的其实并不算是真正的运算符，它们算是一类特殊的操作。()是与函数相关，[]与数组相关，而－>及.是取结构成员。 其次是单目运算符，所有的单目运算符具有相同的优先级，因此在我认为的真正的运算符中它们具有最高的优先级，又由于它们都是从右至左结合的，因此*p++与*(p++)等效是毫无疑问的。 接下来是算术运算符，*、/、%的优先级当然比+、－高了。 移位运算符紧随其后。 其次的关系运算符中，< <= > >=要比 == !=高一个级别，不大好理解。 所有的逻辑操作符都具有不同的优先级（单目运算符出外，！和~） 逻辑位操作符的"与"比"或"高，而"异或"则在它们之间。 跟在其后的&&比||高。 接下来的是条件运算符，赋值运算符及逗号运算符。 在C语言中，只有4个运算符规定了运算方向，它们是&&、| |、条件运算符及赋值运算符。 &&、| |都是先计算左边表达式的值，当左边表达式的值能确定整个表达式的值时，就不再计算右边表达式的值。如 a = 0 && b; &&运算符的左边位0，则右边表达式b就不再判断。 在条件运算符中。如a?b:c；先判断a的值，再根据a的值对b或c之中的一个进行求值。 赋值表达式则规定先对右边的表达式求值，因此使 a = b = c = 6;成为可能。 初——单——算，关——逻，条——赋——逗 断句如上。怎么记忆呢？ 我是这样记忆的：“”内表示运算符的简称。 “初”次“单”独找你“算”账，（因为你和关羽有仇） “关”羽带着兵巡“逻”（因为你躲了起来） 你跑到别处了，隐姓埋名，“挑”着“豆腐”卖。（当了卖豆腐的）：豆腐——实际上是“赋”“逗” ?2009-4-8 15:43 ?回复 我是这样记得: 一个自称黑的初学者连编程都不会还算什么黑客，把自己关起来反思吧，逻辑都没有条理，因为你不认真学！还找理由说因为天赋不够，真逗``
文件编号：TDdoc-bug 杭州网阔信息科技有限公司 BUG级别定义标准 拟制部门：测试部 版本号：V1.6.0 修改日期：2015-05-24 版本修改记录 版本号修改描述作者日期
目录 一、主要分类 (4) 二、主要内容 (4) 1.依据优先级分类标准 (4) 1.1定义 (4) 1.2.分类标准 (4) 1.1.1 紧急................................................................................. 错误！未定义书签。 1.1.2 高..................................................................................... 错误！未定义书签。 1.1.3 中..................................................................................... 错误！未定义书签。 1.1.4 低..................................................................................... 错误！未定义书签。 2.依据严重程度分类标准 (5) 2.1 定义 (5) 2.2.分类标准 (5) 2.2.1 紧急................................................................................. 错误！未定义书签。 2.2.2 非常高............................................................................. 错误！未定义书签。 2.2.3 高..................................................................................... 错误！未定义书签。 2.2.4 中..................................................................................... 错误！未定义书签。 2.2.5 低..................................................................................... 错误！未定义书签。 2.3注意事项 (6) 三、错误分类具体说明条例 (6) 3.1文案错误 (6) 3.2图片错误 (6) 3.3链接错误 (7) 3.4前后模块不一致 (7) 3.5需求问题 (7) 3.6实现与需求不符 (7) 3.7功能性错误 (7) 3.8出现调试代码 (8) 3.9页面格式错误 (8) 3.10关联性错误 (8) 3.11程序性能低下 (8) 3.12缺少容错性处理 (8) 3.13配置问题 (8) 3.14兼容性问题 (8) 3.15校检错误 (9) 3.16程序引起的安全问题 (9) 3.17功能易用程度低 (9) 3.18遗留问题 (9) 3.19暂时无法实现技术问题 (9) 3.20数据流 (9)
黑盒测试用例的设计方法 第一章BUG生命周期 对BUG处理 开发负责人：对每条BUG进行分配，标注处理意见，给定优先级。问题分配时，应可能将咨询类、理解错误类等问题处理掉，而不是直接打开，分配给开发人员。有可能是需求问题，分配给需求人员。把状态置为：Open或者Rejected. 开发人员：分析BUG，写出问题原因，修改BUG；实行BUG优先原则，严重程度高优先修改，修改完成后，把BUG状态置为：Fixed.
测试人员：对修改问题进行验证后，验证通过后把BUG状态置为：Closed；验证不通过，把BUG状态置为：Reopen。 第二章严重级别划分 Urgent：致命错误 致命错误通常有如下情况： 1、需求书中的重要功能未实现； 2、造成系统崩溃、死机,并且不能通过其它方法实现功能； 3、常规操作造成程序非法退出、死循环、通讯中断或异常，数据破坏丢失或数据库异常、且不能通过其它方法实现功能的。 Very High：严重错误 严重错误通常使系统不稳定、不安全、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的主要问题，如： 1、重要功能基本能实现，但系统不稳定、一些边界条件下操作会导致run-time error、文件操作异常、通讯异常、数据丢失或破坏等错误； 2、重要功能不能按正常操作实现，但可通过其它方法可实现； 3、错误的波及面广，影响到其它重要功能正常实现； 4、密码明文显示； 5、C/S、B/S模式下，利用客户端某些操作可造成服务端不能继续正常工作的。 High：一般错误 程序的功能运行基本正常，但是存在一些需求、设计或实现上的缺陷；次要功能运行不正常，如： 1、次要功能不能正常实现； 2、操作界面错误（包括数据窗口内列名定义、含义不一致）； 3、打印内容、格式错误； 4、查询错误，数据错误显示；
不能完全满足系统要求，系统停止运行，系统的重要功能无法运行，系统崩溃或者挂起等导致系统不能继续运行。 修改优先级为最高，该级别问题需要立即修改。 1、系统崩溃； 2、导致程序重启、死机或者非法退出； 3、关键功能不能实现使得后续工作无法进行； 4、死循环； 5、数据丢失或异常。 高级问题： 严重的影响系统要求或基本功能的实现，且没有更正方法（重新安装或重新启动该软件不属于更正方法）。使系统不稳定、或破坏数据、或产生错误结果、或部分功能无法执行，而且常规操作中经常发生或非常规操作中不可避免的主要问题，系统无法满足主要的业务要求，性能、功能或可用性严重降低。 修改优先级为高，该级别需要程序员尽快修改。 1、功能不符合需求、实现不正确； 2、数据计算错误； 3、程序接口错误； 4、误操作迫使程序中断或者报错。 中级问题： 系统可以满足业务要求，系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。 修改优先级为中，该级别需要程序员修改。 1、数据长度不一致； 2、内容或格式错误； 3、响应速度较慢； 4、提示不正确但输出结果正确； 5、操作界面错误（包括数据窗口内列名定义、含义是否一致）； 6、简单的输入限制未放在前台进行控制； 7、虽然正确性不受影响，但系统性能和响应时间受到影响。
使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方面等需要完善的小问题。 修改优先级为低，该级别需要程序员修改或不修改。 1、界面不规范； 2、辅助说明描述不清楚； 3、输入输出不规范； 4、长时间的操作未给用户提示； 5、提示用语不规范； 6、可输入区域和只读区域没有明显的区分标志； 7、必填项与非必填项没有加以区别； 8、界面不能及时刷新，影响功能实现； 9、功能模块名称、标题等不一致； 10、界面、网页、图片出现错别字。 建议优化： 希望提出的建议进行但不强制进行的修改。不会给发布的准确性或可用性带来任何严重影响。 修改优先级为低，该级别需要程序员修改或不修改。 1、各种提示框信息使用不统一； 2、界面显示或描述建议； 3、光标跳转设置不好，光标定位错误； 4、其他建议性问题。
BUG级别定义标准
目录 一、主要分类 (3) 二、主要内容 (3) 1.依据优先级分类标准 (3) 1.1定义 (3) 1.2.分类标准 (3) 1.1.1 Urgent等级 (3) 1.1.2 High等级 (3) 1.1.3 Medium等级 (3) 1.1.4 Low等级 (3) 2.依据严重程度分类标准 (3) 2.1 定义 (3) 2.2.分类标准 (4) 2.2.1 Blocker等级 (4) 2.2.2 Major等级 (4) 2.2.3 Normal等级 (4) 2.2.4 Minor等级 (4) 2.2.5 Trivial等级 (4) 2.3注意事项 (4) 三、错误分类具体说明条例 (5) 3.1文案错误 (5) 3.2图片错误 (5) 3.3链接错误 (5) 3.4前后模块不一致 (5) 3.5需求问题 (5) 3.6实现与需求不符 (6) 3.7功能性错误 (6) 3.8出现调试代码 (6) 3.9页面格式错误 (6) 3.10关联性错误 (6) 3.11程序性能低下 (6) 3.12缺少容错性处理 (7) 3.13配置问题 (7) 3.14兼容性问题 (7) 3.15校检错误 (7) 3.16程序引起的安全问题 (7) 3.17功能易用程度低 (7) 3.18遗留问题 (8) 3.19暂时无法实现技术问题 (8) 3.20数据流 (8)
一、主要分类 BUG类型标准主要分两类： 依据优先级分类。 依据严重程度分类。 二、主要内容 1.依据优先级分类标准 1.1定义 优先级：指一个BUG相对于其他BUG对于公司的影响，解决的及时性。 1.2.分类标准 1.1.1Urgent等级 ?系统无法工作 ?测试无法继续正常工作 ?特殊情况：如重要客户（项目重要性） 1.1.2High等级 1.1.3Medium等级 1.1.4Low等级 2.依据严重程度分类标准 2.1定义 严重程度：指一个BUG对于用户造成的影响，风险和可视性。
c/c++运算符的优先级和结合性 内容导读：遍历了15个级别之后，让我们再来总结一下。其中我们可以看出这样两个规律：规律一、按照操作数个数来区分，一元运算符高于二元运算符，二元运算符高于三元运算符; 规律二、按照运算符的作用来区分，级别最高的是那些不是严格意义上的运算符，次之是算术运算... 遍历了15个级别之后，让我们再来总结一下。其中我们可以看出这样两个规律： 规律一、按照操作数个数来区分，一元运算符高于二元运算符，二元运算符高于三元运算符; 规律二、按照运算符的作用来区分，级别最高的是那些不是严格意义上的运算符，次之是算术运算符，位移运算符，关系运算符，位运算符，逻辑运算符，赋值运算符。 此外还有两特别的地方需要注意： 一、同为关系运算符，但==和!=的级别低于其它四个; 二、第2组与第13组的操作符是右结合的，其它的都为左结合; 通过分类我们大大减少了需要记忆的内容，遇到使用操作符的时候，我们只需想想它们是什么类型的运算符就可以确定它们之间的相对优先级，从而避免一些不必要的错误。 ====================================================================== =================== 提起运算符的优先级，很多了解c++的过来人都会想：这有什么难的？不就是谁的优先级高就算谁么。确实如此，运算符的优先级不是一个大问题，但对于一个初学者来说，却经常容易在上面迷糊与犯错。而对于一个了解c++的人来说，我相信也会偶尔在上面摔倒，不信就继续往下读。 “优先级高的先运算”带来的困惑 c++中运算符的优先级有一张表，表里把运算符进行了分类，这张表是不需要死记硬背的，只要有个大致的轮廓就ok了。例如应该记住最低优先级是逗号运算符，其次是赋值运算符，再其次是三目运算符。而关系运算符的优先级高于逻辑运算符（不包括逻辑非运算），算术运算符的优先级高于关系运算符，象++和﹣﹣的优先级比前面几个都高，但最高的要属（）了。知道这些后，你的脑海里一定有一条准则了：优先级高的先运算。那么下面看一个例子： intx=1,y=0; !x&&x+y&&++y;
Bug分级及优先级定义 文档编号：{文档编号} 当前版本号：0.1 最初发布日期：2013-4-5 最新修订日期：2013-6-21 公司名称：深圳市海亚科技发展有限公司 地址：深圳市龙岗区宝龙工业城诚信路8号亚森创新科技产业园办公楼9楼邮编：518000
版本历史 版本/状态作者起止日期备注 0.1 揭亮华2013-4-5 0.2 揭亮华2013-6-21 添加blocker级bug严重程度
第1章文档介绍 (4) 1.1 文档目的 (4) 1.2 文档范围 (4) 1.3 读者对象 (4) 1.4 参考资料 (4) 1.5 术语表 (4) 第2章 Bug严重程度分级 (5) 第3章 Bug优先级划分 (8) 第4章 Bug修改优先级划分 (9)
第1章文档介绍 1.1 文档目的 确定Bug严重程度分级以及优先级划分 1.2 文档范围 Bug严重程度和优先级划分定义 1.3 读者对象 研发中心 1.4 参考资料 序号文档名称版本1 1.5 术语表 序号术语解释 1.数据数据库内的数据。我们的班级管理系统有用到数据库管理班级、学生、教师、试卷、成绩等信息，白板软件也有用到数据库管理软件用户 2.内存泄漏内存泄漏也称作“存储渗漏”，用动态存储分配函数动态开辟的空间，在使用完毕后未释放，结果导致一直占据该内存单元。直到程序结束 3.漏洞系统中的安全缺陷。软件或协议的具体实现或系统安全策略上存在的缺陷，从而可以使攻击者能够在未授权的情况下访问或破坏系统
第2章 Bug严重程度分级 BUG类型BUG现象举例0级1级2级3级4级5级 功能类软件崩溃、死机√ 功能设计与需求规格说明书不一致,实现0-50% √ 功能设计与需求规格说明书不一致,实现51%-80% √ 功能设计与需求规格说明书不一致,实现81%-99% √ 数据类数据丢失√ 获取数据的路径不符要求,但操作成功√边界值未做限制√ 数据存储、读取、处理错误√ 内存泄漏√ 电脑资源使用过高√ 长时间事务处理,无提示√ 界面类安装、卸载界面图片文字的错误√ 公司名称、软件名称、版权、版本文本、图片信息错误√ 进入软件不做操作就能发现的文字、颜色、图形错误√ 进入软件需要一步操作才能发现的文字、颜色、图形错误√ 进入软件需要两步操作才能发现的文字、颜色、图形错误√ 进入软件需要两步以上操作才能发现的文字、颜色、图形 错误 √软件UI与设计不一致√ 界面设计不规范,没有考虑易用性问题√ 信息类提示信息不正确√必填信息无提示√必要操作无提示信息√ 安全类一般用户正常使用就能发现的软件漏洞√ 程序员深入分析后才能发现的软件漏洞√用户权限问题√ 随机类随机产生的软件崩溃bug，很难重现√ 随机产生的软件功能性bug，很难重现√ 建议类测试人员对软件提出的建议√
按照CMM5中定义的规范： 致命是严重影响产品的BUG，比如操作手册的错误，需求的错误等。 严重是产品中使功能无法实现的BUG，比如某个功能无法运行，GUI长时间僵死没有响应。 一般是某个BUG的发生，只影响了一个功能，而其他功能可以正常运行。提示就是一些GUI的问题，或者友好性的问题。 执行的bug是最严重的，即优先级1的bug，除此之外所有导致应用程序崩溃掉的bug也列入到优先级1中；[url=javascript.:;] 其他[/url]功能性bug列入比较严重的bug的队伍，即优先级2； 界面上的bug列为一般的，即优先级3 实践过程中推行的就是这种bug分级制度。这种分级制度比较主观，使用到一个bug优先级划分文档中列出的优先级1的bug特征： 优先级1类的bug还应该包括功能严重不符合产品说明书这种类型的bug a) 应用程序某个模块功能未实现（包括整个模块不能运行） b) 用户的信息被破坏或者丢失 c) 可重现的不可避免的崩溃，死锁 d) 功能和性能急剧衰退 e) 严重的内存泄漏 f) 导致功能无法正常使用的UI设计（UI响应迟缓） g) 其他 的确，这些bug优先级划分很明确，让人一目了然并且觉得很有道理，可是拿到实际中一用，麻烦开始来了。因为某些描述仍然不够详细，含混不清的描述诸如“功能和性能急剧衰退”，碰到这种描述，不同的人会有不同的理解，而不同的理解必然会带来各种各样的问题。因此，笔者在实践中逐渐摒弃了这种做法，并开始逐步推广笔者自己刚才提到的粗放式bug优先级划分方法。 对于该划分方法，笔者还需要进一步的说明。笔者刚才提到的“严重影响测试执行的bug”其实也是指系统的基本功能或者核心功能，比如新建编辑删除功能中，对于同样是信息为保存到[url=javascript.:;]数据库[/url]——即新建后记录未添加到数据库，编辑后记录未更新，删除后数据仍然存在于数据库中——这时候笔者仅仅将新建功能的该bug置于优先级1中，编辑删除bug则置于优先级2中。这种方法与很多正统的方法很不一致，因为在很多划分方法中“信息未保存”都是优先级1的bug。但是笔者自认为这样做是有理由的：当新建功能发生该类型bug而编辑删除功能正常时，编辑删除功能仍然无法测试或者实现（因为没有数据啊），这在客户的江渡看来会直接视为新建编辑删除功能均未实现。新建功能正常而编辑或者删除功能失效，则不会影响到其他功能的使用（当仅编辑功能失效的时候，新建和删除功能并不会受到影响），测试人员仍然进行新建删除功能的[url=javascript.:;]功能测试[/url]，客户依然可以使用新建和删除功能。 当然，笔者使用上面的划分方式还有其他的原因——基于bug管理和测试开发工作的顺利推进。读者可能会注意到，使用上面的bug划分方式会减少优先级1的bug的数量，笔者这样做是因为笔者在bug管理中推介的方式是优先级1的bug不允许推迟到下一个工作日修改。试想，如果优先级1的bug的数量如果过多自然
BUG严重级别定义 及描述 1. 严重问题 严重问题：阻碍开发或测试工作的问题。修改优先级为最高，该级别问题需要立即修改。 1）系统崩溃 2）导致程序重启,死机或非法退出 3）死循环 4）数据丢失或异常 5）数据通讯错误 2. 高级问题 高级问题：系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。 修改优先级为高，该级别需要程序员尽快修改。 1）功能不符合用户需求 2）数据计算错误 3）业务流程错误 4）程序接口错误 5）因错误操作迫使程序中断 6）系统可被执行，但操作功能无法执行（含指令） 7）功能项的某些项目（选项）使用无效（对系统非致命的）
8）功能实现不完整，如删除时没有考虑数据关联 9）功能的实现不正确，如在系统实现的界面上，一些可接受输入的控件点击后无作用， 对数据库的操作不能正确实现。 10）安全问题 3. 中级问题中级问题：系统可以满足业务要求，系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。 修改优先级为中，该级别需要程序员修改。 1）数据长度不一致 2）内容或格式错误 3）响应时间较慢 4）功能性建议 5）提示信息不太准确 6）操作界面错误（包括数据窗口内列名定义、含义是否一致） 7）简单的输入限制未放在前台进行控制 8）虽然正确性不受影响，但系统性能和响应时间受到影响 9）不能定位焦点或定位有误，影响功能实现 10）增删改功能，在本界面不能实现，但在另一界面可以补充实现 4. 低级问题 低级问题：界面、性能缺陷 修改优先级为低，该级别需要程序员修改或不修改
1）界面不规范 2）辅助说明描述不清楚 3）输入输出不规范 4）长时间操作未给用户提示 5）提示窗口文字未采用行业术语 6）可输入区域和只读区域没有明显的区分标志 7）必填项与非必填项应加以区别 8）滚动条无效 9）键盘支持不好，如在可输入多行的字段中，不支持回车换行 10）界面不能及时刷新，影响功能实现 5. 建议意见建议意见：希望提出的建议以及建议进行但不强制进行的修 改。不会给发 布的准确性或可用性带来任何严重影响。修改优先级为低，该级别需要程序员修改或不修改。 1）各种提示框信息使用不统一,未采用行业术语 2）界面显示或描述建议 3）光标跳转设置不好，鼠标（光标）定位错误 4）其他建议性问题
下面是C语言中所使用的运算符的优先级和结合性： 优先级运算符结合性 (最高) () [] -> . 自左向右 ! ~ ++ -- + - * & sizeof 自右向左 * / % 自左向右 + - 自左向右 << >> 自左向右 < <= > >= 自左向右 == != 自左向右 & 自左向右 ^ 自左向右 | 自左向右 && 自左向右 || 自左向右 ?: 自右向左 = += -= *= /= %= &= ^= |= <<= >>= 自右向左 (最低) , 自左向右 还有指针运算符、sizeof运算符、数组运算符[]等等 一、赋值运算符 赋值语句的作用是把某个常量或变量或表达式的值赋值给另一个变量。符号为‘=’。这里并不是等于的意思，只是赋值，等于用‘==’表示。 注意：赋值语句左边的变量在程序的其他地方必须要声明。 得已赋值的变量我们称为左值，因为它们出现在赋值语句的左边；产生值的表
达式我们称为右值，因为她它们出现在赋值语句的右边。常数只能作为右值。例如： count=5; total1=total2=0; 第一个赋值语句大家都能理解。 第二个赋值语句的意思是把0同时赋值给两个变量。这是因为赋值语句是从右向左运算的，也就是说从右端开始计算。这样它先total2=0;然后total1=total2;那么我们这样行不行呢？ (total1=total2)=0; 这样是不可以的，因为先要算括号里面的，这时total1=total2是一个表达式，而赋值语句的左边是不允许表达式存在的。 二、算术运算符 在C语言中有两个单目和五个双目运算符。 符号功能 + 单目正 - 单目负 * 乘法 / 除法 % 取模 + 加法 - 减法 下面是一些赋值语句的例子，在赋值运算符右侧的表达式中就使用了上面的算术运算符：
BUG定义规范Revision History
1.目的 对BUG概念、BUG提交和验证、BUG状态、BUG严重程度等内容进行定义和规范，以便进一步指导我们的测试工作 2.概念 BUG:软件中存在的瑕疵，可能会导致软件失效。简单的说就是软件系统中存在的可能导致系统出错、失效、死机等问题的错误或缺陷 3.BUG管理工具 以Quality Center 9.0为提交、跟踪等工具 4.BUG提交和验证要求 以QC中的字段为准 提交时必选字段有：摘要，跟踪类型，检测者，检查日期，计划关闭版本，可重现，分 派给，严重程度，状态，描述 验证后，需要修改字段：关闭于版本，关闭日期，状态BUG描述模板如下： [问题概要]: [重现步骤]: 步骤1. 步骤2. [隔离分析]: [期望结果]: [重现概率]: [Test Case No.]:（若没有用例，则标注‘NA’，若是地区版本上的问题，则标注地区名称） [Test Case]:（若没有用例，则标注‘NA’，若是地区版本上的问题，则标注地区名称） QC中优先级和严重程度的区别：优先级由软件开发人员填写，严重程度由测试人员填写 计划关闭版本定义： 有2重含义：1.由测试人员填写当前发现bug的版本号；2.开发人员必须在此版本上修改 5.BUG验证 开发人员必须提供修改此bug会涉及到的功能点列表，并将此信息填写到bug描述中。 测试人员除验证此bug外，还需要将开发列出的功能点逐一验证，同时写入自己考虑到的功能点验证情况 来自需求和测试自己提交的问题，测试人员都需要验证，并填写测试结果，其中来自自己的bug，若验证通过，则修改状态为“关闭”；来自需求人员的bug，则修改状态为“验证完毕”，由需求人员来关闭（适用于胜算组）。 6.BUG状态流程 在正在BUG生命周期中，可能会经历很多状态，如：新建、提交验证、已关闭、重新打开、已挂起、重复提交等。 新建：新发现的问题 提交验证：开发修改bug后，会将状态变为提交验证，让测试工程师来执行验证操作已关闭：测试工程师经过验证后，发现此问题已经被修复，则修改状态为已关闭
BUG等级划分方法 一、四级的划分方式： 1.BUG等级划分建议： 目前project上的BUG严重程度分为五个等级，按照CMM5中定义的规范，BUG严重等级可分为3-5个等级，由于我们公司的CMM水平还处于初级阶段，将BUG等级划分过细不符合我们当前的CMM水平，同时也不利于测试人员对BUG等级的精确划分。根据我们公司的情况，同时参照其它中小公司的等级划分标准，建议将BUG等级划分四个等级，分别为致命、严重、一般、提示。 ● 致命(可对应目前BUG体系中的“非常严重”)： 致命性问题主要为：系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。 具体基本上可分为： ○严重花屏 ○内存泄漏 ○用户数据丢失或破坏 ○系统崩溃/死机/冻结 ○模块无法启动或异常退出 ○严重的数值计算错误 ○功能设计与需求严重不符 ○其它导致无法测试的错误 ● 严重(可对应目前BUG体系中的“严重”) 严重性问题主要为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。 具体基本上可分为： ○功能未实现 ○功能错误
○系统刷新错误 ○语音或数据通讯错误 ○轻微的数值计算错误 ○系统所提供的功能或服务受明显的影响 ● 一般(可对应于目前BUG体系中的“普通”) 一般性问题主要为：界面、性能缺陷 具体基本上可分为： ○操作界面错误(包括数据窗口内列名定义、含义是否一致) ○边界条件下错误 ○提示信息错误(包括未给出信息、信息提示错误等) ○长时间操作无进度提示 ○系统未优化(性能问题) ○光标跳转设置不好，鼠标(光标)定位错误 ● 提示(可对应于目前BUG体系中的“轻微及建议”) 提示性问题主要为：易用性及建议性问题 具体基本上可分为： ○ 界面格式等不规范 ○ 辅助说明描述不清楚 ○ 操作时未给用户提示 ○ 可输入区域和只读区域没有明显的区分标志 ○ 个别不影响产品理解的错别字
BUG严重级别定义及描述 1. 严重问题 严重问题：不能完全满足系统要求，系统停止运行，系统的重要部件无法运行，系统崩溃或挂起等导致系统不能继续运行。 修改优先级为最高，该级别问题需要立即修改。 1. 系统崩溃 2. 导致程序重启,死机或非法退出 3. 死循环 4. 数据丢失或异常 5. 数据通讯错误。 6. 硬件故障，系统悬挂 2. 高级问题 高级问题：严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题，系统无法满足主要的业务要求，性能、功能或可用性严重降低。 修改优先级为高，该级别需要程序员尽快修改。 1. 功能不符合用户需求 2. 数据计算错误 3. 业务流程错误 4. 程序接口错误 5. 因错误操作迫使程序中断； 6. 系统可被执行，但操作功能无法执行（含指令）； 7. 功能项的某些项目（选项）使用无效（对系统非致命的）； 8. 功能实现不完整，如删除时没有考虑数据关联； 9. 功能的实现不正确，如在系统实现的界面上，一些可接受输入的控件点击后无作用，对数据库的操作不能正确实现。 3. 中级问题 中级问题：系统可以满足业务要求，系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。 修改优先级为中，该级别需要程序员修改。 1. 数据长度不一致
2. 内容或格式错误 3. 响应时间较慢 4. 功能性建议 5. 提示信息不太准确 6.操作界面错误（包括数据窗口内列名定义、含义是否一致）； 7.简单的输入限制未放在前台进行控制； 8.虽然正确性不受影响，但系统性能和响应时间受到影响； 9.不能定位焦点或定位有误，影响功能实现； 10.增删改功能，在本界面不能实现，但在另一界面可以补充实现。 4. 低级问题 低级问题：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题 修改优先级为低，该级别需要程序员修改或不修改。 1.界面不规范； 2.辅助说明描述不清楚； 3.输入输出不规范； 4.长时间操作未给用户提示； 5.提示窗口文字未采用行业术语； 6.可输入区域和只读区域没有明显的区分标志； 7.必填项与非必填项应加以区别； 8.滚动条无效； 9.键盘支持不好，如在可输入多行的字段中，不支持回车换行； 10.界面不能及时刷新，影响功能实现。 5. 建议意见 建议意见：希望提出的建议以及建议进行但不强制进行的修改。不会给发布的准确性或可用性带来任何严重影响。 修改优先级为低，该级别需要程序员修改或不修改。 1. 各种提示框信息使用不统一,未采用行业术语 2. 界面显示或描述建议 3. 光标跳转设置不好，鼠标（光标）定位错误； 4. 其他建议性问题。
Bug定义规范 1、bug类型的划分 功能类： 1、重复的功能 2、多余的功能 3、功能实现与设计要求不符合 4、功能使用性、方便性、易用性不够 5、功能未实现 界面类： 1、界面不美观 2、控件排列、格式不统一 3、焦点控制不合理或不全面 数据处理类： 1、数据有效性检测不合理 2、数据来源不正确 3、数据处理过程不正确 4、数据处理结果不正确 流程类： 1、流程控制不符合要求 2、流程实现不完整 提示信息类： 1、提示信息重复或出现时间不合理 2、提示信息格式不符合要求 3、提示框返回后焦点停留位置不合理 建议类： 1、功能性建议 2、操作建议 3、检校建议 4、说明建议 2、bug等级定义 Level 1-致命的bug：100%程序崩溃、重启、死机，自动退出，用户数据丢失，缺少主要功能。 1、程序无法正常使用，在正常操作流程中（特别是操作步骤不复杂，用户很容 易就用到）出现崩溃、死机现象 2、100%导致用户数据丢失的问题 3、被测试数据系统频繁崩溃，程序出错，使功能不能继续使用 4、性能与需求不一致 5、系统资源引发性能问题 6、系统配置引发错误 7、安全性问题
Level 2-严重的bug：所产生的问题导致系统瘫痪，重要功能未实现，严重影响用户使用的问题，关键用户需求未实现或软件功能与需求严重不符。 1、功能与需求不一致，或功能未实现 2、功能有错误 3、数据传输有错误 4、安装与卸载有问题 Level 3-一般的bug：所产生的问题会导致系统部分功能不正常，虽然产生的问题严重，但不影响下一步的测试，严重的界面提示问题。 1、功能有错误，但不影响使用 2、重要界面的显示问题 3、内存泄露导致某些功能无法正常使用，释放内存重启后系统恢复正常 4、复现率较低的死机、重启问题，步骤多用户不易操作到 5、边界条件出错 Level 4-轻微的bug：轻微界面显示问题，对用户使用无影响的问题。 1、微小功能问题，如闪烁中间界面、界面刷新慢 2、轻微的界面显示错误，界面设计不规范，交互不友好 3、消息、提示信息不准确 4、用户可以接受，对功能不影响 5、某些次要功能，在进行某些很特殊的操作后某些功能不能正常响应 Level 5-建议性bug：功能运作正常，可是有改进的空间，建议性问题所产生的问题不会导致系统任何问题。 1、可以忽略不计的问题，对用户使用没有任何影响，但有改进空间 2、软件设计有问题 3、文档不完整或不准确 4、其他建议性问题 3、BUG状态 （初始状态） 1、已提交：测试人员员发现BUG后提交到BUG管理系统中的状态。 2、已修改：开发人员在修改了BUG后提交到BUG管理系统中的状态。 3、不修改：程序员或产品人员根据需求分析、概要设计、详细设计说明书等经过考虑后决定对BUG不进行修改。其BUG的状态为不修改，需要说明理由。 4、延迟：根据目前项目进程或计划等情况，暂时延期的状态 5、待讨论：需要进行讨论后才能决定是否需要修改的BUG的状态。 6、已验证：已经解决的并经过测试员复测的BUG的状态。 7、关闭：完全解决了，只供以后备查的状态 8、重新打开：重新出现在新的版本中，重新打开以前关闭的BUG的状态