文档介绍：软件缺陷描述规范
缺陷基本定义
软件缺陷（Software Defect）：
软件缺陷是对软件产品预期属性偏离现象。它涉及检测缺陷和残留缺陷。
缺陷优先性，分为5级，参照下面办法拟定：
1)最高优先级(Blocker)，例如，软件重要功能错误或者导致软件崩溃，数据丢失缺陷，或顾客重点关注问题,缺陷导致系统几乎不能使用或者测试不能继续，需及时修复。
2)较高优先级(Critical)，例如，影响软件功能和性能普通缺陷，严重影响测试，需要优先考虑；
3)普通优先级(Major)，例如，本地化软件某些字符没有翻译或者翻译不精确缺陷,需要正常排队等待修复；
4)低优先级(Minor)，例如，对软件质量影响非常轻微或浮现几率很低缺陷,可以在开发人员有时间时候再被纠正；
5)最低优先级(Trival),例如，属于优化，可以不做修改问题或暂时无法修复但影响不大问题。
缺陷描述
软件缺陷描述是软件缺陷报告基本某些，也是测试人员就一种软件问题与开发工程师交流最佳机会。一种好描述，需要使用简朴、精确、专业语言来抓住缺陷本质。否则，它就会使信息含糊不清，也许会误导开发人员,因而，对的评估缺陷严重限度和优先级，是项目组全体人员交流基本。
缺陷描述原则：
有效缺陷描述有如下几种原则：
可以重现：在缺陷详细描述中提供精准操作环节，可以让发人员容易看懂；
定位精确：缺陷描述精确，不会引起误解和歧义；
描述清晰：对操作环节描述清晰，易于理解，应用客观书面语，避免使用口语；
完整统一：提供完整、先后统一软件缺陷环节和信息，按照一致格式书写所有缺陷报告，关于缺陷格式参见“缺陷格式”；
短小简洁：通过使用核心词，可以使问题摘要描述短小简洁，又能精确解释产生缺陷现象。如“在新建任务窗口中，选取直接下达，负责人收不到即时消息”中“新建任务窗口”、“直接下达”、“即时消息”等是核心词；
特定条件：许多软件功能在普通状况下没有问题，而是在某种特定条件下会存在缺陷，因此软件缺陷描述不要忽视这些看似细节但又必要特定条件（如特定操作系统、浏览器或某种设立等），可以提供协助开发人员找到因素线索。如“”；
不做评价：在软件缺陷描述不要带有个人观点，对开发软件进行评价。软件缺陷报告是针对产品、针对问题自身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。
缺陷格式：提交一条缺陷后，最佳可以再检查一遍缺陷格式与否有问题。常用格式问题如下：
问题摘要中不能有句号；
问题摘要后不要有空格，直接填写内容；
问题摘要比较长时，可以用“，”分隔；
详细描述中序号背面“.”一定是半角宋体，不是全角符号，并且背面不要再有空格；
详细描述中分号一定要使用全角分号；
详细描述中“->”应统一。应在英文输入法半角状态下输入箭头；
注意缺陷中不要浮现错别字，例如“登陆”应写为“登录”。
缺陷描述常用问题：
问题摘要过长，不够简洁、精确；
问题摘要与详细描述内容不一致；
详细描述不清晰，无法复现；
详细描述冗长，不适当于理解；
缺陷定位不对的；
缺陷级别定位错误；
缺陷类型定位不对的；
不是缺陷。
缺陷管理
缺陷跟踪
缺陷提交人，实时跟踪缺陷状态，对开发人员提出疑问，及时作出回答；
及时更新缺陷状态。
缺陷示例
缺陷优先级会涉及从Critical到Trivial，严重限度级别会涉及从S1到S5。
普通地，严重限度高软件缺陷具备较高优先级，但是严重限度和优先级并不总是一一相应。有时候严重限度高软件缺陷，优先级不一定高，甚至不需要解决，而某些严重限度低缺陷却需要及时解决，反而具备较高优先级。例如，公司名字和软件产品徽标是重要，一旦它们误用了，这种缺陷是顾客界面产品缺陷，并不影响顾客使用。但是它影响公司形象和产品形象，因而这也是优先级高软件缺陷。
普通功能性缺陷较为严重，具备较高优先级，而软件界面类缺陷严重性普通较低，优先级也较低。但事实上，优先级和严重限度是有联系也有区别。严重限度高，必然优先级也要高，但优先级高，严重限度却并非也一定高。
功能性：
1）S1级/Critical
导致系统崩溃：执行正常操作或者误操作后，导致整个系统，或者大某些模块无法正常使用：
问题摘要：为一种子部门设立一种网站签收员，再在人事管理中将该顾客删除，导致程序加载不上
详细描述：
，新建一种部门，为该部门指定一种网站签收员；
“顾客后台管理”，找到该顾客，并将该顾客删除；
，系统提示断开，无法登录系统。
导致死机：执行正常操作或者误操作后，导致死机：
问题摘要：通过地址簿填写各种收信人时