我在实际工作中,经常度量第一个数据,原因如下1、缺陷率(缺陷数量/规模):很好度量,用于开发过程中,如果使用了bug管理系统的话,这个数据能很轻易得出,例如我们公司使用的JIRA系统,目的在于:一方面作为对开发人员的考核,另一方面用于分析开发过程的bug原因分析及预防。2、缺陷密度(发布缺陷数/总缺陷数):我把他叫缺陷密度,用于产品发布后,产品进入维护阶段,主要有两个来源,一是客户自己发现,二是在维护中开发人员发现。主要用于分析产品发布的过程改进,如果这个数据过大,说明我们的放行标准过低,如果这个数很低,说明我们的放行标准过高,事实发布后是允许存在bug的,那么如何改进发布放行,就必须用这个数据来度量,我目前只找到这个方法:)3、根据缺陷率及缺陷密度进行分析统计,以得出在整个开发过程中基于测试和评审的粒度!4、可能跟我们公司的项目有关系,我们的生命周期是一直存在到维护中的,如果生命周期到交付客户就结束,那么这个度量项意义真的不大,大家可以自己斟酌!
软件缺陷度量方法简述
1.原则上来讲,我们更希望一种规范化开发的体系来规正这个命题,不需要为此伤脑筋。但在里程碑或计划的截止时间点能结束测试对大多数的软件项目仅仅是一种期望,而不是既定的现实。理想的情况下,我们可以严格执行计划,然后在计划要求的deadline或者里程碑点上提交交付件,以确认该里程碑是否达到要求,是否可以进行下一阶段的工作——但正如前提所言,这个仅仅是理想情况
2.现在让我们现实一点。我们为什么会有这样的问题(一个软件如何确定测试结束点)?往往就是因为我们不知道何时可以结束一个软件的测试。不管教科书上如何说明一个软件只要还在生命周期内,就无法结束测试,但现实要求我们在某一个时间点上,结束对软件某一阶段的测试。那么,这个问题实际上就已经转化为确定该阶段测试的结束点的方法了。这个方法可能是一种规范,一套流程,一些交付件,一些评审,一些由统计学原理得出的收敛曲线或者仅仅只是一些确认而已。而个人认为,无论这个方法是何种形式的,其基本的要求就是能达成一种协议,确认该协议生效——那么这个阶段的测试就结束了,至于这个点在什么时间,我想就是完成所有要求的这些确认的时间而已。
在软件消亡之前,如果没有测试的结束点,那么软件测试就永无休止,永远不可能结束。软件测试的结束点,要依据自己公司具体情况来制定,不能一概而论!个人认为测试结束点由以下几个条件决定::
1.基于“测试阶段”的原则:
每个软件的测试一般都要经过单元测试、集成测试、系统测试这几个阶段,我们可以分别对单元测试、集成测试和系统测试制定详细的测试结束点。每个测试阶段符合结束标准后,再进行后面一个阶段的测试。举个例子来说:单元测试,我们要求测试结束点必须满足“核心代码100%经过Code Review”、“功能覆盖率达到100%”、“代码行覆盖率不低于80%”、“不存在A、B类缺陷”、“所有发现缺陷至少60%都纳入缺陷追踪系统且各级缺陷修复率达到标准”等等标准。集成测试和系统测试的结束点都制定相关的结束标准,当然也是如此。
2.基于“测试用例”的原则:
测试设计人员设计测试用例,并请项目组成员参与评审,测试用例一旦评审通过,后面测试时,就可以作为测试结束的一个参考标准。比如说在测试过程中,如果发现测试用例通过率太低,可以拒绝继续测试,待开发人员修复后再继续。在功能测试用例通过率达到100%,非功能性测试用例达到95%以上,允许正常结束测试。但是使用该原则作为测试结束点时,把握好测试用例的质量,非常关键。
3.基于“缺陷收敛趋势”的原则:
软件测试的生命周期中随着测试时间的推移,测试发现的缺陷图线,首先成逐渐上升趋势,然后测试到一定阶段,缺陷又成下降趋势,直到发现的缺陷几乎为零或者很难发现缺陷为止。我们可以通过缺陷的趋势图线的走向,来定测试是否可以结束,这也是一个判定标准。
4.基于“缺陷修复率”的原则:
软件缺陷在测试生命周期中我们分成几个严重等级,它们分别是:严重错误、主要错误、次要错误、一般错误、较小错误和测试建议6种。那我们在确定测试结束点时,严重错误和主要错误的缺陷修复率必须达到100%,不允许存在功能性的错误;次要错误和一般错误的缺陷修复率必须达到85%以上,允许存在少量功能缺陷,后面版本解决;对于较小错误的缺陷修复率最好达到60%~70%以上。对于测试建议的问题,可以暂时不用修改。
5.基于“验收测试”的原则:
很多公司都是做项目软件,如果这种要确定测试结束点,最好测试到一定阶段,达到或接近测试部门指定的标准后,就递交用户做验收测试。如果通过用户的测试验收,就可以立即终止测试部门的测试;如果客户验收测试时,发现了部分缺陷,就可以针对性的修改缺陷后,验证通过后递交客户,相应测试也可以结束。
6.基于“覆盖率”的原则:
对于测试“覆盖率”的原则,个人觉的只要测试用例的“覆盖率”覆盖了客户提出全部的软件需求,包括行业隐性需求、功能需求和性能需求等等,只要测试用例执行的覆盖率达到100%,基本上测试就可以结束。如“单元测试中语句覆盖率最低不能小于80%”、“测试用例执行覆盖率应达到100%”和“测试需求覆盖率应达到100%”都可以作为结束确定点。如果你不放心,非得要看看测试用例的执行效果,检查是否有用例被漏执行的情况,可以对常用的功能进行“抽样测试” 和“随机测试”。对于覆盖率在单元测试、集成测试和系统测试,每个阶段都不能忽略。
7.基于“项目计划”的原则:
大多数情况下,每个项目从开始就要编写开发和测试的Schedule,相应的在测试计划中也会对应每个里程碑,对测试进度和测试结束点做一个限制,一般来说都要和项目组成员(开发,管理,测试,市场,销售人员)达成共识,团队集体同意后制定一个标准结束点。如果项目的某个环节延迟了,测试时间就相应缩短。大多数情况下是所有规定的测试内容和回归测试都已经运行完成,就可以作为一个结束点。很多不规范的软件公司,都是把项目计划作为一个测试结束点,但是如果把它作为一个结束点,测试风险较大,软件质量很难得到保证。
8.基于“缺陷度量”的原则:
这个原则也许大家用的不是很多,了解比较少。我们可以对已经发现的缺陷,运用常用的缺陷分析技术和缺陷分析工具,用图表统计出来,方便查阅,分时间段对缺陷进行度量。我记得以前zhuzx在这个论坛上提出过缺陷分析技术这个问题,我不再重复讲述。我们也可以把 “测试期缺陷密度”和 “运行期缺陷密度”作为一个结束点。当然,最合适的测试结束的准则应该是“缺陷数控制在一个可以接受的范围内”。比如说:一万行代码最多允许存在多少个什么严重等级的错误,这样比较好量化,比较好实施,成为测试缺陷度量的主流。
9.基于“质量成本”的原则:
一个软件往往要从“质量/成本 /进度”三方面取得平衡后就停止。至于这三方面哪一项占主要地位,就要看是什么软件了。比如说是:人命关天的航天航空软件,那还是质量重要些,就算多花点钱、推迟一下进度,也要测试能保证较高质量以后才能终止测试,发布版本。如果是一般的常用软件,由于利益和市场的原因,哪怕有bug,也必须得先推出产品,没办法呀。一般来说,最主要的参考依据是:“把找到缺陷耗费的代价和这个缺陷可能导致的损失做一个均衡”。具体操作的时候,可以根据公司实际情况来定义什么样的情况下算是“测试花费的代价最划算、最合理”,同时保证公司利益最大化。如果找到bug的成本比,用户发现bug的成本还高,也可以终止测试。
10.基于“测试行业经验”的原则:
很多情况下,测试行业的一些经验,也可以为我们的测试提供借鉴。比如说测试人员对行业业务的熟悉程度,测试人员的工作能力,测试的工作效率等等都会影响到整个测试计划的执行。如果一个测试团队中,每个人都没有项目行业经验数据积累,拿到一个新的项目,自然是一头雾水,不知道从何处开始,测试质量自然不会很高。因此通过测试者的经验,对确认测试执行和结束点也会起到关键性的作用
以下哪一项不是满足软件测试退出准则的条件
1.基于“测试阶段”的原则:
每个软件的测试一般都要经过单元测试、集成测试、系统测试这几个阶段,我们可以分别对单元测试、集成测试和系统测试制定详细的测试结束点。每个测试阶段符合结束标准后,再进行后面一个阶段的测试。举个例子来说:单元测试,我们要求测试结束点必须满足“核心代码100%经过Code Review”、“功能覆盖率达到100%”、“代码行覆盖率不低于80%”、“不存在A、B类缺陷”、“所有发现缺陷至少60%都纳入缺陷追踪系统且各级缺陷修复率达到标准”等等标准。集成测试和系统测试的结束点都制定相关的结束标准,当然也是如此。
2.基于“测试用例”的原则:
测试设计人员设计测试用例,并请项目组成员参与评审,测试用例一旦评审通过,后面测试时,就可以作为测试结束的一个参考标准。比如说在测试过程中,如果发现测试用例通过率太低,可以拒绝继续测试,待开发人员修复后再继续。在功能测试用例通过率达到100%,非功能性测试用例达到95%以上,允许正常结束测试。但是使用该原则作为测试结束点时,把握好测试用例的质量,非常关键。
3.基于“缺陷收敛趋势”的原则:
软件测试的生命周期中随着测试时间的推移,测试发现的缺陷图线,首先成逐渐上升趋势,然后测试到一定阶段,缺陷又成下降趋势,直到发现的缺陷几乎为零或者很难发现缺陷为止。我们可以通过缺陷的趋势图线的走向,来定测试是否可以结束,这也是一个判定标准。
4.基于“缺陷修复率”的原则:
软件缺陷在测试生命周期中我们分成几个严重等级,它们分别是:严重错误、主要错误、次要错误、一般错误、较小错误和测试建议6种。那我们在确定测试结束点时,严重错误和主要错误的缺陷修复率必须达到100%,不允许存在功能性的错误;次要错误和一般错误的缺陷修复率必须达到85%以上,允许存在少量功能缺陷,后面版本解决;对于较小错误的缺陷修复率最好达到60%~70%以上。对于测试建议的问题,可以暂时不用修改。
5.基于“验收测试”的原则:
很多公司都是做项目软件,如果这种要确定测试结束点,最好测试到一定阶段,达到或接近测试部门指定的标准后,就递交用户做验收测试。如果通过用户的测试验收,就可以立即终止测试部门的测试;如果客户验收测试时,发现了部分缺陷,就可以针对性的修改缺陷后,验证通过后递交客户,相应测试也可以结束。
6.基于“覆盖率”的原则:
对于测试“覆盖率”的原则,个人觉的只要测试用例的“覆盖率”覆盖了客户提出全部的软件需求,包括行业隐性需求、功能需求和性能需求等等,只要测试用例执行的覆盖率达到100%,基本上测试就可以结束。如“单元测试中语句覆盖率最低不能小于80%”、“测试用例执行覆盖率应达到100%”和“测试需求覆盖率应达到100%”都可以作为结束确定点。如果你不放心,非得要看看测试用例的执行效果,检查是否有用例被漏执行的情况,可以对常用的功能进行“抽样测试 ”和“随机测试”。对于覆盖率在单元测试、集成测试和系统测试,每个阶段都不能忽略。
7.基于“项目计划”的原则:
大多数情况下,每个项目从开始就要编写开发和测试的Schedule,相应的在测试计划中也会对应每个里程碑,对测试进度和测试结束点做一个限制,一般来说都要和项目组成员(开发,管理,测试,市场,销售人员)达成共识,团队集体同意后制定一个标准结束点。如果项目的某个环节延迟了,测试时间就相应缩短。大多数情况下是所有规定的测试内容和回归测试都已经运行完成,就可以作为一个结束点。很多不规范的软件公司,都是把项目计划作为一个测试结束点,但是如果把它作为一个结束点,测试风险较大,软件质量很难得到保证。
8.基于“缺陷度量”的原则:
这个原则也许大家用的不是很多,了解比较少。我们可以对已经发现的缺陷,运用常用的缺陷分析技术和缺陷分析工具,用图表统计出来,方便查阅,分时间段对缺陷进行度量。我记得以前zhuzx在这个论坛上提出过缺陷分析技术这个问题,我不再重复讲述。我们也可以把 “测试期缺陷密度”和 “运行期缺陷密度”作为一个结束点。当然,最合适的测试结束的准则应该是“缺陷数控制在一个可以接受的范围内”。比如说:一万行代码最多允许存在多少个什么严重等级的错误,这样比较好量化,比较好实施,成为测试缺陷度量的主流。
9.基于“质量成本”的原则:
一个软件往往要从“质量/成本/进度”三方面取得平衡后就停止。至于这三方面哪一项占主要地位,就要看是什么软件了。比如说是:人命关天的航天航空软件, 那还是质量重要些,就算多花点钱、推迟一下进度,也要测试能保证较高质量以后才能终止测试,发布版本。如果是一般的常用软件,由于利益和市场的原因,哪怕有bug,也必须得先推出产品,没办法呀。一般来说,最主要的参考依据是:“把找到缺陷耗费的代价和这个缺陷可能导致的损失做一个均衡”。具体操作的时候,可以根据公司实际情况来定义什么样的情况下算是“测试花费的代价最划算、最合理”,同时保证公司利益最大化。如果找到bug的成本比,用户发现bug 的成本还高,也可以终止测试。
10.基于“测试行业经验”的原则:
很多情况下,测试行业的一些经验,也可以为我们的测试提供借鉴。比如说测试人员对行业业务的熟悉程度,测试人员的工作能力,测试的工作效率等等都会影响到整个测试计划的执行。如果一个测试团队中,每个人都没有项目行业经验数据积累,拿到一个新的项目,自然是一头雾水,不知道从何处开始,测试质量自然不会很高。因此通过测试者的经验,对确认测试执行和结束点也会起到关键性的作用。
有关软件的一些问题!我也知道问题多 !尽量解答还有加分!不差分!属于保险行业应用软件
1、首先:是“金领保险行销系统”,而不是“金邻保险行销系统”噢。
2、能肯定的是:一定不是硬件问题。无所谓台式和笔记本。
3、“2000系统缺少了什么运行环境?”,对,一定是你的运行环境有问题。
解决方案:由于不能看到你的机器,所以无法完全判断错误的原因,但你可以参考我以下的解决方案,定能解决:
1、首先查看你的IE浏览器版本是否是“ie6.0sp2”,如果不是,那么请马上更新至IE6.0SP2
2、如果更新至IE6.0SP2后仍然不行,那么请您装Windows2000sever版本的系统,而不是"windows2000"
我想知道EDA的发展前景和EDA开发的优缺点
*****电子设计自动化,现在设计硬件电路,估计都得用到EDA方法,EDA方法包括两个方面:设计模式和设计工具。
*****现代设计模式一般就是自顶向下的过程。先分析需求包括功能与性能两大指标;然后按功能划分子模块,接着分块实现,具体就是用各种元器件和专业集成块拼接实现。到这逻辑电路基本实现,需要用设计工具验证你设计的合理性,可以用VHDL语言在maxplus这一进行EDA开发必须的软件仿真及硬件仿真环境下验证。
*****可以说,任何与只能控制有关的电子产品,其中都会用到用EDA设计的模块,甚至是整个产品本身。当然,要真正成为一位熟练工人,或是优秀学徒,都需要个人的兴趣作为动力,个人的耐心和细心作为支柱。其实你说的缺点也就在这里面,这一行业显得比较专业,你选了这一行业,你的择业面就相当窄了些,找不到合适工作的危险性就相当较大。好好考虑吧,要是足够自信的话,那就勇敢的选择自己喜爱的,不计较它的优缺点!
*****祝你好运!一位同行师兄路过...
参考资料:自己琢磨的。
请高手指点一下; 衣柜材料的环保标准具体是怎么定的? 密度板与飞林板的优缺点?
一般的是E1级、一百克排量≥5毫克
最好的是E0级、 一百毫克排量≤5毫克
一块标准红砖的尺寸是多少?标准重量有规定没有?
标砖尺寸是240*115*53,
重量与材质和砖的密度有关,理论上,红砖,表观密度约1800kg/m 3 ( 混凝土表观密度约2300kg/m 3 )也就是一块红砖重量约等于2.63kg
转载请注明出处51数据库 » 软件缺陷密度标准 究竟什么是缺陷密度