bug优先级划分
1.1 问题类型
问题类型分为：BUG、新需求、优化。
1.2 优先级
1.2.1 Blocker（有妨碍的）:即系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。
——严重花屏、内存泄漏；
——用户数据丢失或破坏；
——系统崩溃/死机/冻结；
——模块无法启动或异常退出；
——严重的数值计算错误；
——功能设计与需求严重不符；
——其它导致无法测试的错误,如服务器500错误。
1.2.2 Critical（紧要的）：即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
——功能未实现；
——功能错误；
——系统刷新错误；
——数据通讯错误；
——轻微的数值计算错误；
——影响功能及界面的错误字或拼写错误；
——安全性问题。
1.2.3 Major（严重的）：即界面、性能缺陷、兼容性。
——操作界面错误（包括数据窗口内列名定义、含义是否一致）；
——边界条件下错误；
——提示信息错误（包括未给出信息、信息提示错误等）；
——长时间操作无进度提示；
——系统未优化（性能问题）；
——光标跳转设置不好，鼠标（光标）定位错误；
——兼容性问题。
1.2.4 Minor/Trivial（次要的/不严重的）:即易用性及建议性问题。
——界面格式等不规范；
——辅助说明描述不清楚；
——操作时未给用户提示；
——可输入区域和只读区域没有明显的区分标志；
——个别不影响产品理解的错别字；
——文字排列不整齐等一些小问题。
测试用例优先级划分
测试用例优先级划分 从未有足够的时间做所有我们需要做的事情，这是在软件项目，尤其在测试中的一个普遍的话题。在可用的有限时间内，如何知道你的测试工作做的最好？当应用程序发布时，总会有些遗漏的缺陷没有被发现。对于测试而言，目标是通过改进产品质量使风险减到最小，这可以通过建造一套具体的测试用例来将应用程序按照它的速度完 成等方法实现。 IEEE Standard 610 (1990) 中定义测试用例为： 1. 为一个特定目标而开发一组测试输入，执行条件和的期望结果，例如测试某个程序路径或核实是否满足某个特定的需求。 2.指定输入，预期结果和一组测试项的执行条件的文档(IEEE Std 829-1983)。 当然，你将发现在项目的生命周期里的每一个应用程序的版本上执行你全部的测试用例是很困难的。但是你将如何知道哪个测试用例必须在每一个版本中执行，什么应该被执行，同时如果你有时间的话，什么又可以被执行？ 给你的测试用例划分优先级别 你的应用程序不需要十全十美，但它必须迎合你目标用户的需求和期望。为了了解你项目的期望，你需要确定什么是应用程序中最重要的，目标和风险又是什么。
Sue Bartlett在“How to Find the Level of Quality Your Sponsor Wants”一文中详细的讨论了这个问题，她在文中注解到：“当我们在详细的计划，设计或编码之前沟通质量目标时，我们有一个更好的机会来避免在最后时刻的质量不匹配，那意味着迎合计划，弥补花费并且赢利将有一个更好的成功的机会。” 为了测试计划的目的，在项目版本的进度下，测试执行过程中组织和安排你的测试用例将帮助达到这些目标。作为这种组织的一部分，我们要考虑每一个测试用例的优先级别。根据优先级别分组测试用例将帮助你决定不同类型的版本需要什么样的测试用例，因此计算需要的时间。如果你只有有限的时间，你可以查看什么是最合适。 Ross Collard在"Use Case Testing"一文中说：“测试用例的前10%到15%可以发现75%到90%的重要缺陷”。 测试用例的优先级划分将帮助确定找出了这前10%到15%的测试用例。 如何划分测试用例的优先级别 你曾查看过多少次你的测试用例并且能够很容易的挑选出最重要的一个小的子集？这个答案可能是不经常，停止思考“所有的测试用例都是同等重要”这个问题是非常困难的。当设计测试用例时，分配优先级别是不容易的，并且在项目期间里用例的优先级不一定是静止的。然而，我们可以通过构造一个划分优先级别流程的例子来开始处理划分测试用例优先级别的第一步。让我们假设你刚刚根据功能说明书，用例和其他一些关于应用程序的目标行为和能力的信息源完
Windows环境中组策略处理优先级详解
Windows环境中组策略处理优先级详解 组策略处理和优先级 应用于某个用户（或计算机）的组策略对象(GPO) 并非全部具有相同的优先级。以后应用的设置可以覆盖以前应用的设置。 处理设置的顺序 本节提供有关用户和计算机组策略设置处理顺序的详细信息。有关策略设置处理适合计算机启动和用户登录框架的位置的信息，请参阅以下主题启动和登录中的第3 步和第8 步。 组策略设置是按下列顺序进行处理的： 1.本地组策略对象—每台计算机都只有一个在本地存储的组策略对象。对于计算机或用户策略处理，都会处 理该内容。 2.站点—接下来要处理任何已经链接到计算机所属站点的GPO。处理的顺序是由管理员在组策略管理控制台 (GPMC) 中该站点的“链接的组策略对象”选项卡内指定的。“链接顺序”最低的GPO 最后处理，因此具有最高的优先级。o 3.域—多个域链接GPO 的处理顺序是由管理员在GPMC 中该域的“链接的组策略对象”选项卡内指定的。 “链接顺序”最低的GPO 最后处理，因此具有最高的优先级。 4.组织单位—链接到Active Directory 层次结构中最高层组织单位的GPO 最先处理，然后是链接到其子 组织单位的GPO，依此类推。最后处理的是链接到包含该用户或计算机的组织单位的GPO。 wu 在Active Directory 层次结构的每一级组织单位中，可以链接一个、多个或不链接GPO。如果一个组织单位链接了几个GPO，它们的处理顺序则由管理员在GPMC 中该组织单位的“链接的组策略对象”选项卡内指定。“链接顺序”最低的GPO 最后处理，因此具有最高的优先级。 该顺序意味着首先会处理本地GPO，最后处理链接到计算机或用户直接所属的组织单位的GPO，它会覆盖以前GPO 中与之冲突的设置。（如果不存在冲突，则只是将以前的设置和以后的设置进行结合。） 设置默认处理顺序的例外 设置的默认处理顺序受下列例外情况的影响： GPO 链接可以“强制”，也可以“禁用”，或者同时设置两者。默认情况下，GPO 链接既不强制也不禁用。
bug级别定义及流转说明
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 即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。
DAX的计算组之间的优先级设置
一、前言 在昨天介绍计算组的《PowerBI/DAX的计算组功能是什么？怎么用？》这篇文章中，漏掉了一个比较关键的点，那就是多个计算组作用于同一个度量值时的优先级问题，因此在这篇文章里做补充说明，算是之前那篇文章的后续吧。如果你没看过之前那篇介绍计算组功能的文章，我建议你先去阅读完后再来看本文，因为在这里我不会再去重复的讲解怎么创建计算组、怎么使用计算组的动态数据格式等等内容，我将默认你看过上篇文章。 二、计算组之间的优先级 先来看看下面这张图，将它称呼为图1，下面需要引用这张图，请记住它的名字： 为了方便展示与讲解，我没有把数据透视表弄得很复杂，仅仅是把年份与月份放在了行字段，将销售金额和销售数量放在了值字段，将计算组的计算项都做成了切片器，并且这些切片器都还没有工作。所用的销售金额与销售数量度量值如下： Sales = SUMX('T3销售','T3销售'[T3销售册数]*'T3销售'[T3销售单价]) Volume = SUM('T3销售'[T3销售册数]) ? 1 ? 2 ? 3
现在问题来了，我定义了一个将数值加上100的计算组以及一个能改变数值符号正负的计算组，那么：是先将数值加上一百后再改变符号，还是改变符号后再将数值增加一百？ 想要弄懂上面的计算顺序，那么就先要设置计算组之间的优先级，只有告诉引擎先执行那个计算组才能够得到正确结果。计算组的优先级设置位置如下图： 上图中的红框框起来的行就是计算组优先级的设置地方，可以看到，我将改变数值符号的计算组的优先级设置为了100，你可能会觉得这个数字越大就越是优先执行。其实不是的，应该是数字越小越优先执行，因为它是按照升序排列的，所以数字越大越靠后执行。下面来看一下将数值增加一百的计算组的优先级：
软件质量BUG等级定义
有限公司 软件质量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类－一测试建议，由项目经理决定注销或遗留。
基金优先级、普通级区别
基金(优先级份额、普通级份额) 在庆祝香港回归祖国十周年并成功实行“一国两制”的时刻，6月27日证券专业报纸报道，有创新型封闭式基金通过监管部门的审批，将于两周后正式公开发行。这种“一国两制”的封闭式基金是一个法律主体管理下的分为不同两部分的封闭式基金，划根据预期风险和收益分为优先级份额和普通级份额。两部分资金统一运作，既可以100%，也可按其它比例投资股票，还可以投资股指期货，资金运用比较灵活。 一只基金两级份额 这种封闭式基金的创新性集中表现在它的“一国两制”特点上，即它是一个法律主体管理下的分为不同两部分的封闭式基金。不同部分的划分是以其预期风险和收益为标准的。预期风险和收益均较低的部分为优先级份额；预期风险和收益均较高的部分则为普通级份额。如果一只封闭式基金发行规模为60亿份。为满足不同投资者的需要将其一分为二，即优先级份额（简称××优先）和普通级份额（简称××进取），两者各为30亿份。这种结构方面的突出特点反映他它的名称上，就是分级股票型证券投资基金。 这种分级基金是基金市场细分化的产物。不同投资者的风险偏好，收益预期是不一样的。只愿承担较低风险且预期收益相对较低的保守型投资者适合认购这只基金的优先级。而那些能够承担较大风险且希望获得较高收益的投资者适合认购这只基金的普通级。这只基金认购渠道除上网之外，还有两个主要渠道：优先级像开放式基金一样在相关银行认购；普通级在证券公司营业部认购。 这为发行后上市的交易提供了方便。优先级不上市交易，但在该基金合同生效后每满一年时开放一次，此时投资者方可申购或赎回。开放日为自合同生效之日起每满一年的最后一天。若该日为非工作日，则顺延至下一工作日。这种安排使优先级带上了一点开放式基金的色彩，同时也说明投资者持有份额时间至少为一年。普通级则可象老封闭式基金一样，在证券交易所上市交易。 这只基金两级份额最根本且最重要的区别在于他们不同的分红方式，这是该基金的灵魂。 优先级优先分红 优先级的称谓来自它享有优先分配权。在分红时，首先要按优先级的年基准收益率为之分红，其年基准收益率计算公式为： 年基准收益率=一年期定期存款利率+3%目前，一年期银行定期存款利率为3.06%，这样它的年基准收益率为3.06%+3%=6.06%。如一年期银行存款利率发生变化，则只在每年起始日按中国人民银行公布并执行的一年期银行存款利率调整一次。这里潜伏着一个小小的风险，就是如果银行一年内连续上调利率，其反应滞后。 若整体收益仅满足优先级分红，则普通级份额就不分红。这时优先级有点像定期存款。 若满足优先分红之后，尚有剩余收益，优先级还可以获得其中的1/10。不仅如此，优 先级的优先权还表现在它的累积弥补机制方面。若某年度优先级分红未能达到当年年基准收益率，则下一会计年度的收益首先要用来将该年度的收益补足。 普通级享有较高比例超额收益分配权
BUG级别定义标准
文件编号：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)
报文信息的分类及优先级P134
报文信息的分类及优先级P134 本协议将主站和子站的报文信息按照发送的优先级分为以下几种类型类型优先级说明 1级用户数据1 1）状态量（一次设备工作状态、子站工作状态） 2）子站中产生的突发事件信息或主站的控制命令以及此类报文的 应答 3）上电信息、初试化信息 2级用户数据2 1）测量值有变化的数据 2）子站中产生的需循环发送的(如:测量值)信息,或主站循环发送 的对时命令 3）主站的一般命令及子站的响应,例如复制报告或读取采样值 链路服务级别P90 5．1 本标准方式1采用3级链路服务级别,如图1－3所示 服务级别功能用途S1 发送/无回答由主站向子站发送广播报文 S2 发送/确认由主站向子站发送控制命令、设置参数等S3 请求/响应由主站向子站召唤采样数据或事件信息等图1－3方式1通信采用的链路服务级别 5．1 本标准方式2采用3级链路服务级别,如图1－4所示 服务级别功能用途 S1 发送/无回答由主站向子站发送广播报文、由子站向主站循环发送测量值或由子站向主站主动发送事件信息 S2 发送/确认由主站向子站发送控制命令、设置参数 S3 请求/响应由主站向子站召唤采样数据或事件信息等 图1－4方式2通信采用的链路服务 报文类型及用途 1. 固定帧长报文 仅适用于方式1 1．1由主站发往子站的报文（控制方向） 功能码序号帧类型功能FCV状态 0 发送/确认帧复位通信单元0 1~2 3 发送/确认帧传送数据 1 4 发送/无回答帧传送数据0 5~6 7 复位帧计数位传送数据0 8 9 请求/响应帧召唤链路状态0 10 请求/响应帧召唤1级用户数据 1 11 请求/响应帧召唤1级用户数据 1
BUG生命周期及优先级、严重级划分
黑盒测试用例的设计方法 第一章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、查询错误，数据错误显示；
Bug等级分类定义
不能完全满足系统要求，系统停止运行，系统的重要功能无法运行，系统崩溃或者挂起等导致系统不能继续运行。 修改优先级为最高，该级别问题需要立即修改。 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、其他建议性问题。
飞思卡尔MC9S12XS128单片机中断优先级设置简易教程
本教程试图用最少的时间教你飞思卡尔XS128单片机的中断优先级设置方法和中断嵌套的使用，如果是新手请先学习中断的基本使用方法。 先来看看XS128 DataSheet 中介绍的相关知识，只翻译有用的： 七个中断优先级 每一个中断源都有一个可以设置的级别 高优先级中断的可以嵌套低优先级中断 复位后可屏蔽中断默认优先级为1 同一优先级的中断同时触发时，高地址（中断号较小）的中断先响应 注意：高地址中断只能优先响应，但不能嵌套同一优先级低地址的中断 下面直接进入正题，看看怎么设置中断优先级: XS128中包括预留的中断一共有128个中断位，如果为每个中断都分配一个优先级寄存器的话会非常浪费资源，因此飞思卡尔公司想出了这样一种办法：把128个中断分为16个组，每组8个中断。每次设置中断时，先把需要的组别告诉某个寄存器，再设置8个中断优先寄存器的某一个，这样只需9个寄存器即可完成中断的设置。 分组的规则是这样的：中断地址位7到位4相同的中断为一组,比如MC9SX128.h中 这些中断的位7到位3都为D，他们就被分成了一组。0~F正好16个组。
INT_CFADDR就是上面说到的用来设置组别的寄存器: 我们需要设置某个组别的中断时，只要写入最后8位地址就行了，比如设置SCI0的中断优先级，就写入0xD0。 设置好组别之后，我们就要该组中相应的中断进行设置,设置中断的寄存器为 这其实是一组寄存器，一共有8个，每个都代表中断组中的一个中断。对应规则是这样的：中断地址的低四位除以2 比如还是SCI0，低四位是6，除以二就是3，那么我们就需要设置INT_CFDATA3 往INT_CFDATAx中写入0~7就能设置相应的中断优先级了 拿我本次比赛的程序来举个例子：我们的程序中需要3个中断：PIT0,PORTH,SCI0。PIT0定时检测传感器数值，PORTH连接干簧管进行起跑线检测，SCI0接收上位机指令实现急停等功能。因此中断优先级要SCI0>PORTH>PIT0。 我们先要从头文件中找出相应中断的地址: PIT0【7:4】位为7，选择中断组： INT_CFADDR=0x70;
BUG级别定义标准v1.1
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对于用户造成的影响，风险和可视性。
bug分级及优先级定义
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，很难重现√ 建议类测试人员对软件提出的建议√
实验十四：Qos之端口优先级设置
实验十四：Qos之端口优先级设置 一、理论基础 端口优先级是可以由管理员手工设置的。以太网交换机的端口支持8个优先级。用户可以根据需要设置端口的优先级。默认情况下，交换机将使用端口优先级代替该端口接收报文本身带有的802.1p优先级，从而控制报文可以享有的服务质量。 priority-level的取值范围为0～7。 缺省情况下，端口优先级为0；对于接收的报文，交换机将使用报文接收端口的优先级替换报文的802.1p优先级。 交换机的端口有4个输出队列，队列ID分别为0、1、2、3。交换机支持根据报文的802.1p 优先级或者DSCP优先级把报文放入这4个输出队列中。用户可以通过配置来指定根据哪种优先级将报文入队列。 可以使用下面的命令来指定将报文放入队列时依据的优先级。指定将报文放入队列时依据的优先级: priority-trust { cos | dscp } 缺省情况下，交换机采用802.1p优先级将报文放入相应的输出队列中去。 二、实验案例 端口的优先级的配置 1、实验拓扑结构图：
2、配置说明： 交换机的 E0/1的接口的优先级别设置为1，速率为10Mbps（接PC1） E0/2的接口的速率为20Mbps（接server） E0/3的接口的优先级别设置为7，速率为10Mbps（接PC2） 3、具体配置： [Quidway]int e0/3 [Quidway-Ethernet0/3]priority 7 [Quidway-Ethernet0/3]int e0/1 [Quidway-Ethernet0/1]priority 1 [Quidway]undo port-prioritytrust disable [Quidway]queue-scheduler wrr 1 2 3 31 [Quidway]int e0/3 [Quidway-Ethernet0/3]speed 10 [Quidway-Ethernet0/3]int e0/1 [Quidway-Ethernet0/1]speed 10 [Quidway-Ethernet0/1]int e0/2 [Quidway-Ethernet0/2]line-rate outbound 20 [Quidway]priority-trust cos [Quidway]dis qos cos-local-precedence-map cos-local-precedence-map: cos : 0 1 2 3 4 5 6 7 --------------------------------------------------------------- local-precedence : 2 0 1 3 4 5 6 7 [Quidway]
CMM5定义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的数量如果过多自然
项目优先级评价标准
项目优先级评价标准 在每一个银行中，各有业务部门及管理部门均会有很多对信息技术项目的需求。针对这些需求，首先需要判断的是该项目是否有实施的意义。所有的项目均可以被归类成战略层和战术层项目。 对于战略层项目而言，开项目是否实施主要取决于以下三个方面： 1该项目是否支持了业务上提出的优先等级； 2对于该项目支持的业务案例而言，是否该业务案例带来的正面的有形或无形收益回大于潜在成本； 3是否项目的实施风险与期望的净收益密切相关。 对于战术层项目而言，开项目是否实施主要取决于以下两个方面： 1本项目是否实现了必须满足的规章或业务需求； 2如果不实施该项目是否意味着会对银行当前的运营产生负面影响，这种情形的一个例子是银行当前的技术不再被厂商支持而需要升级。 在某一个项目被确定为需要实施时，银行应该运用一致的效益和风险分析来对项目的优先级进行排序，同时要考虑各项目之间的内在关联性。 对于效益的评估应该考虑下面三方面因素： 1对提高管理信息的贡献度的大小； 2项目总成本的大小； 3该项目每年为银行带来的经济效益。 对于风险的评估应该考虑下面三方面因素，在考虑每一个因素时都应该同时考虑风险发生的可能性及该风险对项目的影响： 1知识和能力，即对所需资源的可获得性（定性和定量的）； 2项目的复杂度； 3项目的技术可行性。 项目的内在联系： 1某一个项目的输入信息是否为其它项目的输出信息；例如很多管理信息类的项目要有业务运营系统提供原始的数据支持，则所需业务运营系统是该管理信息系统的前提； 在国内的银行通常还要考虑的一个因素是行政性指令因素。该因素映在考虑某个具体项目是具体进行考虑。 在项目的成本，利润，风险以及项目间的内在联系等方面的信息确定后，我们可以用下面的逻辑对项目优先级进行排定：
信息系统需求优先级评估方法
信息系统需求优选级评价方法 （初稿） 一、评价指标达成目标 为了贯彻高层对于信息系统评价可量化的精神，资讯科技中心根据当前的实际情况，制定了信息系统评价指标及评价方法，其目的是： 1、与公司整体策略一致，将需求落实到信息功能的实施，制定可量化的标准，便于信 息化项目实施评价； 2、对于信息系统评价指标的计算方法，我们采用多因素加权评分的模式，从整体层面、 不同纬度进行评价，以期与现实情况一致；但在实际执行过程中，我们将采用固定参数分值评估的方法来对现阶段的需求进行管理。 二、评价指标选取原则 信息系统评价是我们未来工作的一个侧重点，因此为了进行评价，必须确定评价指标和建立评价指标体系。科学、合理的评价指标体系是对信息系统进行全面分析和评价的先决条件。信息系统评价指标体系的建立一般遵循以下几个原则： 1、综合性。信息系统是一个复杂的巨系统，其中的各个要素相互联系、相互作用构成系统这一有机的整体，因此指标体系的设置首先要能全面、客观地反映系统的整体状况，要涵盖系统的各个方面，当然这并非说指标越多越好，指标体系如何设置，其数量与层次如何构造也都必须符合系统工程的综合性原则。 2、指导性。任何评价活动都是一种目标驱动的活动，信息系统的评价也不例外，因此评价指标体系的设置必须围绕着评价的目的而展开，这样才能对信息系统的研究和应用具有一定的指导意义，才能为设计信息系统工作的各方面人员提供科学的参考依据。 3、科学性。评价指标体系是理论和实际结合的产物，它是对客观实际的抽象描述。如何在抽象、概括中抓住最重要的、最本质的、最有代表性的，是设计指标体系的关键和难点。对客观实际抽象描述越清楚、越简练、越符合实际，其科学性也就越强。另外，评估的内容也要有科学的规定性，各个指标的概念要科学、确切、要有精确的内涵和外延。
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）其他建议性问题
PE-优先级劣后级合伙人分配模式
转自清科研究中心专栏作者：傅喆 当PE基金遇到”结构化概念” 近期，清科研究中心观测到，一些PE基金开始在基金投资收益模式上进行创新，出现参考信托产品普遍采用的“结构化概念”，将LP分为优先及劣后两个级别。举例说明，有限合伙制PE基金借鉴结构化模式，设置优先、劣后两种级别的LP，出资比例3:1，GP在基金中出资1.0%，每年收取管理费2.2%。 2011年以来，为了适应中国VC/PE市场环境的不断转变以及不同的投资人诉求，我国本土VC/PE投资机构的募资模式及投资风格开始发生快速的改变，逐渐形成了具有“中国特色”的VC/PE发展路径。近期，清科研究中心观测到，一些PE基金开始在基金投资收益模式上进行创新，出现参考信托产品普遍采用的“结构化概念”，将LP分为优先及劣后两个级别。举例说明，有限合伙制PE基金借鉴结构化模式，设置优先、劣后两种级别的LP，出资比例3:1，GP在基金中出资1.0%，每年收取管理费2.2%。投资项目开始退出后，投资收益分配顺序为： 1）先返还优先LP本金，优先LP本金收回后，继续对该类LP分配出资额50.0%的投资收益；
2）返还劣后LP本金； 3）返还GP本金； 4）上述分配完毕后，如还有剩余投资收益，优先、劣后LP 和GP分别按30.0%，45.0%，25.0%分配。
从该结构来看，劣后级LP和基金的GP为优先级LP提供 了“安全垫”，使其可以先行收回投入的本金，并获得出资额50.0%的投资回报。然而，也正是因为提供了“安全垫”，且晚于优先LP 参与投资收益分配，这两类出资人所承担风险加剧，对于投资收益预期也更高，劣后LP在剩余投资收益分配时将获得最大比重，而GP则将以1.0%的出资在剩余投资收益分配时获得其中25.0%的份额。 假设基金规模为5.00亿元人民币，采用上述三类出资人出 资结构，清科研究中心通过计算，分析优先LP、劣后LP和GP 在不同的基金回报情况下各自的投资收益。计算过程涉及以下四类财务指标： 1）基金整体投资回报倍数：即随着所投项目退出，基金 获取的投资回报倍数，不受出资人投资收益分配机制影响； 2）优先LP投资回报倍数：即随着所投项目退出，基金在不同回报水平下，优先LP将获得的投资回报倍数； 3）劣后LP投资回报倍数：即随着所投项目退出，基金在不同回报水平下，劣后LP将获得的投资回报倍数；