BUG提交规范
软件测试BUG提交规范_模板
BUG提交模板和注意事项 一、BUG提交模板 1.现象描述 <详细描述BUG现象> 2.组网环境 <组网图及简要说明：机箱、板卡（型号、序列号和槽位）、测试仪、连接线缆等描述> 注：简单组网环境或一般性BUG情况下，可只简要描述组网环境，无需组网图。 3.版本信息 <被测设备所有组件版本信息> 软件版本： 硬件版本： 芯片版本： CPLD版本： MCU版本： uboot版本： 4.操作步骤 <详细描述发现BUG的操作步骤> 注：说明发现BUG对应用例名称编号或为非用例发现BUG。 5.期望结果 <预期正确的结果> 6.实际结果 <实际不正确的结果> 7.BUG严重性等级 <初步判定BUG的严重性等级>
8.开发确认情况 <开发确认BUG情况描述及确认人> 注：严重等级以上BUG必须要有开发人员确认 9.附件 <包括：组网图、BUG现象截图、操作产生的系统日志等> 注：严重等级以上BUG必须带有附件，一般性BUG则附件可选。 10.备注
XX技术有限公司内部技术规范DKBA04000190-E华为图纸说明规范手册49p
华为技术有限公司内部技术规范 华为图纸说明规范 【最新资料，WORD文档，可编辑修改】
修订声明Revision declaration 本规范拟制与解释部门：华为技术有限公司整机工程部 本规范的相关系列规范或文件：无 相关国际规范或文件一致性：无 替代或作废的其它规范或文件：DKBA 0.400.0190 REV.D 相关规范或文件的相互关系：无 规范号主要起草 部门专家主要评审部门专 家 修订情况 DKBA0.400.0190.V. A基础平台 部：郭天次 00140571结构基础平台部： 肖春秀53994/潘建 军00118387/黄涛 00121968/郑玲 00119690/詹傲芳 62070/朱光胜 67118/郑光明 00115376/邓顺庆 61647 采购认证管理部： 张卫国00174583 供应链管理部物料品 质部： 蒙光忠38711 第一版，整合DKBA0.400.0160结构材料 表示法和DKBA0.400.0002表面处理代 码，增加了对图框各部分内容说明 DKBA0.400.0190.V. B基础平台 部：郭天次 00140571结构基础平台部： 胡邦红00216370 肖春秀53994 潘建军00118387 黄涛00121968 郑玲00119690 詹傲芳62070 朱光胜67118 郑光明00115376 邓顺庆61647 采购认证管理部： 孟庆伟00145066 供应链管理部物料品 质部： 蒙光忠38711 1、增加槽钢和角钢的标注说明； 2、增加表面处理代码：F226、G017、 G018、G161、G226、L015_3、L016、 L017、L226、X009；X226； 3、Film代号含义由“薄膜材料”改为“面 膜” 4、T001的生产质量要求英文版由 DKBA04000065改为DKBA04500067 5、所有“无色化学转化”改为“化学转 化” 6、X127和X202前处理由“锌钝化”改 为“预处理” 7、增加压铸件中1级面的标注说明 8、3.1、4.3、5.1小节增加标题。 9、删除表面处理代码：G016_3、G158_3、 G159_3、L158_3、L159_3 10、热浸涂的生产质量要求由： DKBA0.400.0177改为DKBA0.450.0065
华为钣金设计规范
DKBA 华为技术有限公司企业技术规范 DKBA4031-2003.06 钣金结构件可加工性设计规范 2003-06-30发布2003-07-XX实施 华为技术有限公司发布
目次 前言 (5) 1范围和简介 (6) 1.1范围 (6) 1.2简介 (6) 1.3关键词 (6) 2规范性引用文件 (6) 3冲裁 (6) 3.1冲裁件的形状和尺寸尽可能简单对称，使排样时废料最少。 . 6 3.2冲裁件的外形及内孔应避免尖角。 (6) 3.3冲裁件应避免窄长的悬臂与狭槽 (7) 3.4冲孔优先选用圆形孔，冲孔有最小尺寸要求 (7) 3.5冲裁的孔间距与孔边距 (8) 3.6折弯件及拉深件冲孔时，其孔壁与直壁之间应保持一定的距离8 3.7螺钉、螺栓的过孔和沉头座 (8) 3.8冲裁件毛刺的极限值及设计标注 (9) 3.8.1冲裁件毛刺的极限值 (9) 3.8.2设计图纸中毛刺的标注要求 (9) 4折弯 (10) 4.1折弯件的最小弯曲半径 (10) 4.2弯曲件的直边高度 (10) 4.2.1一般情况下的最小直边高度要求 (10)
4.2.2特殊要求的直边高度 (11) 4.2.3弯边侧边带有斜角的直边高度 (11) 4.3折弯件上的孔边距 (11) 4.4局部弯曲的工艺切口 (12) 4.4.1折弯件的弯曲线应避开尺寸突变的位置 (12) 4.4.2当孔位于折弯变形区内，所采取的切口形式 (12) 4.5带斜边的折弯边应避开变形区 (13) 4.6打死边的设计要求 (13) 4.7设计时添加的工艺定位孔 (13) 4.8标注弯曲件相关尺寸时，要考虑工艺性 (14) 4.9弯曲件的回弹 (14) 4.9.1折弯件的内圆角半径与板厚之比越大，回弹就越大。.. 14 4.9.2从设计上抑制回弹的方法示例 (14) 5拉伸 (15) 5.1拉伸件底部与直壁之间的圆角半径大小要求 (15) 5.2拉伸件凸缘与壁之间的圆角半径 (15) 5.3圆形拉伸件的内腔直径 (15) 5.4矩形拉伸件相邻两壁间的圆角半径 (15) 5.5圆形无凸缘拉伸件一次成形时，其高度与直径的尺寸关系要求 16 5.6拉伸件设计图纸上尺寸标注的注意事项 (16) 5.6.1拉伸件产品尺寸的标准方法 (16)
华为员工行为规范
华为员工行为规范 IMB standardization office【IMB 5AB- IMBK 08- IMB 2C】
员工行为规范一、目的 为体现华为人积极向上的精神面貌，工作期间保持良好的仪表与风度，树立良好的企业形象，特制定本行为规范。 二、适用范围 本规范适用于公司所有员工。 三、细则 u 着装规定 1、员工在上班时间，男士上身不得穿无袖上衣，下身着长裤，或着西装套装；女士着职业套装或正规服装，不得着无袖上衣、超短裙、紧身衣，所有员工均不得着奇装异服；生产部及工程部员工在工作期间必须穿工作服，市场人员、保安及其它外协人员必须着职业服装。 2、上班时间必须正确佩戴工卡，男士用夹子别于左胸前，女士用卡链挂于胸前，不得随意丢置工卡于办公桌及公共场所。 3、男士头发不宜过长，应定期修剪；女士头发不宜过短，都应保持头发的清洁、整齐。 4、女士不宜佩戴过多或夸张的首饰，应以简洁、高雅为标准，不得浓装艳抹，不得涂艳色指甲或留过长指甲。 5、不得穿拖鞋、光脚上班。 u 行为规范 1、办公场所不准吸烟，不准大声喧哗。
2、工作时间打电话不使用免提键，不打私人电话，接听私人电话不得超过3分钟。 3、打电话要长话短说，电话铃响二声后必须接听电话，拿起电话要先说；“你好，华为”，注意语气热情，彬彬有礼。 4、上班时间不做与工作无关的事情，不串岗，不聊天，不随意谈笑，不吃零食。 5、举止庄重，礼貌待人，同事之间交谈要使用文明用语。 四、处罚规定 凡违反上述情况之一，第一次罚款50元，第二次罚款100元，累计三次以上将通报批评，并罚款200元，同时将处罚意见写入员工个人考核意见中。
JIRA bug提交管理规范
Bug提交管理规范 修订历史
目录 1. BUG管理工具介绍 (3) 2. BUG定义 (3) 1. BUG分类 (3) 2. Bug等级 (3) 3. Bug状态 (4) 4. Bug优先级 (4) 3. BUG的生命周期 (4) 4. BUG管理规范 (5) 1) 项目的创建 (5) 项目名称及代号规范 (5) 项目的模块及版本划分规范 (5) 用户角色权限分配规范 (6) 2) BUG提交规范 (6) BUG的报告内容 (6) 主题，即BUG简要描述 (7) 严重程度选择 (7) 优先级选择 (8) 模块及版本选择 (8) 环境 (9) BUG详细描述 (9) 其他规范 (9) 3) BUG分配及处理 (10) BUG的分配 (10) BUG处理 (10) 4) BUG验证及关闭 (10)
1.BUG管理工具介绍 常用的BUG管理工具有JIRA、BugFree、Bugzilla、Mantis、XPWeb等。我们公司采用的是JIAR，JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。 2.BUG定义 1.BUG分类 BUG 就是指系统存的各种缺陷，可以从很多角度对BUG进行分类。 1、从功能方面分，产生BUG的原因大体可以归结为以下四种： A.重复的功能； B.多余的功能； C.功能没有达到设计的要求； D.功能实现与设计要求不相符。 2、从易用性方面分，可以归结为三点： A.界面不美观，控件排列、格式不统一，焦点控制不合理或不全面； B.缺少帮助信息，或者帮助信息不完全； C.功能操作复杂，提示信息不合理，易产生歧义。 3、从安全性方面分，BUG可以划分为以下几类： A.数据有效性检测不合理； B.重要数据在传输中没有加密； C.缺少身份认证机制或认证不合理； D.数据产生缺乏随机性； E．网络安全性：开放端口、服务； F．系统日志、审计。 4、从可靠性方面分，BUG可划分为以下几类： A.数据存贮的可靠性； B.业务处理的可靠性； C．硬件可靠性：如打印机；D.应急处理措施； E．数据备份、恢复。 5、从性能方面考虑，BUG可划分为三种： A．并发量； B．吞吐量； C．响应时间。 6、从兼容性方面考虑，BUG有两种： A．硬件兼容性； B．软件兼容性。 7、从可维护性方面考虑，可划分为两种原因： A．可扩展性； B．方便升级。 2.Bug等级 BUG等级是根据BUG出现在系统中的严重程度来分的，主要定义如下5级： 1级——致命：系统重要功能无法正常使用，系统崩溃；系统设计存在重大隐患；导致用户利益受到重大损失。该级别需要程序员修改。 2级——严重：系统主要功能无法正常实现，系统业务受到严重影响；导致用户利益受到损失。该级别需要程序员修改。 3级——一般：系统次要功能无法实现；主要功能部分失效；系统业务受到影响；导致用户利益受到一定损失。该级别需求程序员修改。
硬件EMC 设计规范1_华为内部资料
本规范只简绍EMC的主要原则与结论，为硬件工程师们在开发设计中抛砖引玉。 电磁干扰的三要素是干扰源、干扰传输途径、干扰接收器。EMC 就围绕这些问题进行研究。最基本的干扰抑制技术是屏蔽、滤波、接地。它们主要用来切断干扰的传输途径。广义的电磁兼容控制技术包括抑制干扰源的发射和提高干扰接收器的敏感度，但已延伸到其他学科领域。 本规范重点在单板的EMC 设计上，附带一些必须的EMC 知识及法则。在印制电路板设计阶段对电磁兼容考虑将减少电路在样机中发生电磁干扰。问题的种类包括公共阻抗耦合、串扰、高频载流导线产生的辐射和通过由互连布线和印制线形成的回路拾取噪声等。在高速逻辑电路里，这类问题特别脆弱，原因很多： 1、电源与地线的阻抗随频率增加而增加，公共阻抗耦合的发生比较频繁； 2、信号频率较高，通过寄生电容耦合到布线较有效，串扰发生更容易； 3、信号回路尺寸与时钟频率及其谐波的波长相比拟，辐射更加显著。 4、引起信号线路反射的阻抗不匹配问题。 一、总体概念及考虑 1、五一五规则，即时钟频率到5MHz 或脉冲上升时间小于5ns，则PCB 板须 采用多层板。 2、不同电源平面不能重叠。 3、公共阻抗耦合问题。 模型： VN1＝I2ZG 为电源I2 流经地平面阻抗ZG 而在1 号电路感应的噪声电压。 由于地平面电流可能由多个源产生，感应噪声可能高过模电的灵敏度或数电 的抗扰度。 解决办法： ①模拟与数字电路应有各自的回路，最后单点接地； ②电源线与回线越宽越好； ③缩短印制线长度； ④电源分配系统去耦。 4、减小环路面积及两环路的交链面积。 5、一个重要思想是：PCB 上的EMC 主要取决于直流电源线的Z 0
禅道bug提交管理规范
禅道Bug提交管理规范 修订历史
目录 目录 (2) 1. 目的 (3) 2. 禅道系统Bug流程图 (4) 3. Bug流程操作及其Bug相关信息解释 (5) 3.1.测试人员发现bug (5) 3.2.测试人员创建Bug (5) 3.3.开发人员设定Bug优先级别并确认Bug (7) 3.4.开发人员解决Bug (8) 3.5.测试人员验证Bug (9)
1.目的 本文档定义了bug管理流程及其bug相关信息内容。 本文档适用范围： ●本文档适用于新产品以及以后新产品的项目。原有项目的bug管理仍然用JIRA系 统进行管理。 ●本文档适用于新产品以及以后新产品的项目相关的测试人员和开发人员。
2. 禅道系统Bug流程图
3. Bug流程操作及其Bug相关信息解释 3.1.测试人员发现bug 3.2.测试人员创建Bug 测试人员登录禅道系统，创建Bug。Bug状态为激活（未确认） 创建Bug页面截图： 页面字段注释： 所属产品：选择发现Bug的产品，必填项。 所属模块：选择发现Bug的对应模块，必填项。 所属项目：选择测试所属的项目。必填项。 影响版本：选择发现bug的版本。必填项。 当前指派：选择指派的开发人员。必填项。 Bug标题：用简单明了的语句说明Bug内容，相当于BUG的中心语句。必填项。 在标题上注明bug出现的频率（稳定出现/经常出现/很少出现/出现一次）重新步骤：重现步骤格式如下。必填项。 [环境]：如果系统/浏览器信息不能够全部说明发现Bug的环境，需要在 重现步骤里详细描述环境信息，以便于开发定位和解决问题。 [步骤]：写明出现Bug的操作步骤，要求简单，去掉与Bug无关的步骤。 [结果]：写明操作的实际结果。
华为员工行为规范定稿版
华为员工行为规范 HUA system office room 【HUA16H-TTMS2A-HUAS8Q8-HUAH1688】
员工行为规范 一、目的 为体现华为人积极向上的精神面貌，工作期间保持良好的仪表与风度，树立良好的企业形象，特制定本行为规范。 二、适用范围 本规范适用于公司所有员工。 三、细则 u 着装规定 1、员工在上班时间，男士上身不得穿无袖上衣，下身着长裤，或着西装套装；女士着职业套装或正规服装，不得着无袖上衣、超短裙、紧身衣，所有员工均不得着奇装异服；生产部及工程部员工在工作期间必须穿工作服，市场人员、保安及其它外协人员必须着职业服装。 2、上班时间必须正确佩戴工卡，男士用夹子别于左胸前，女士用卡链挂于胸前，不得随意丢置工卡于办公桌及公共场所。 3、男士头发不宜过长，应定期修剪；女士头发不宜过短，都应保持头发的清洁、整齐。 4、女士不宜佩戴过多或夸张的首饰，应以简洁、高雅为标准，不得浓装艳抹，不得涂艳色指甲或留过长指甲。
5、不得穿拖鞋、光脚上班。 u 行为规范 1、办公场所不准吸烟，不准大声喧哗。 2、工作时间打电话不使用免提键，不打私人电话，接听私人电话不得超过3分钟。 3、打电话要长话短说，电话铃响二声后必须接听电话，拿起电话要先说；“你好，华为”，注意语气热情，彬彬有礼。 4、上班时间不做与工作无关的事情，不串岗，不聊天，不随意谈笑，不吃零食。 5、举止庄重，礼貌待人，同事之间交谈要使用文明用语。 四、处罚规定 凡违反上述情况之一，第一次罚款50元，第二次罚款100元，累计三次以上将通报批评，并罚款200元，同时将处罚意见写入员工个人考核意见中。
JIRA的BUG编写规范
?一、摘要 ?二、名词解释 ?三、目的 ?四、范围 ?五、Bug编写规范 o 1. 主题 o 2. 描述 o 3. 环境 o 4. 截图 o 5. 其他 ?六、注意事项 一、摘要 本文档主要描述了技术产品部测试人员提交Bug时需要遵守的规范。 二、名词解释
?JIRA JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。 三、目的 规范Bug编写，一方面，可以方便开发人员根据Bug描述快速进行定位问题原因，减少沟通成本，另一方面，可以帮助测试经理、非技术人员、产品经理、开发经理及其他测试人员等了解Bug，第三，可以体现测试团队的专业性、严谨性。 四、范围 该文档适合技术产品部测试人员使用，适合于任何产品和项目。 五、Bug编写规范 1. 主题 为了节约开发阅读Bug时间，同时考虑到开发人员容易通过Bug标题来猜想Bug，所以，Bug标题显得尤为重要。以下为Bug标题编写时需要遵守的规范。1）用简短的语句描述问题，主题文字过多，增加开发阅读Bug时间。2）格式：在什么位置，在什么条件下，做什么操作，操作的结果。 ?在什么位置：问题所在的路径，格式为“XX-页面：”
?在什么条件下：如果问题为兼容性Bug，比如浏览器兼容或者分辨率兼容。格式为“在IE11浏览器下，”，如果Bug不属于兼容性问题，不用加此描述。 ?做什么操作：问题触发的动作，比如：“执行审批通过”。 ?操作的结果：即问题的表象，比如：字段“报送时间”取值不对、报404错误。格式举例：采购中心-招标计划详情：在IE11浏览器下，展开“查看参与人员”，内容错乱。 3）除了第二点描述的格式，对于Bug描述，除了描述实际的结果外，有时候我们会直接描述期望结果，比如，集采销售-招标计划列表：列表字段“填报时间”应该修改为“报送时间”。 4）描述无歧义。Bug描述如果有歧义，开发容易因为改错Bug，导致增加Bug修复成本。 5）涉及界面UI的文字，用双引号标注，比如：集采销售-招标计划列表：列表字段“报送时间”取值错误。 2. 描述
JIRA的BUG管理规范
xxxxxxxxxxxxxxxxxxxxxxxxxx 测试组BUG管理规范
版本历史
目录 1BUG管理工具介绍 (3) 2BUG定义 (3) 2.1BUG分类 (3) 2.2Bug 等级 (4) 2.3Bug 状态 (4) 2.4Bug优先级 (5) 3BUG的生命周期 (5) 4BUG管理规范 (6) 4.1项目的创建 (6) 4.1.1项目名称及代号规范 (7) 4.1.2项目的模块及版本划分规范 (7) 4.1.3用户角色权限分配规范 (7) 4.2BUG提交规范 (7) 4.2.1BUG 的报告内容 (8) 4.2.2问题类型选择 (9) 4.2.3BUG 简要描述 (11) 4.2.4优先级选择 (11) 4.2.5模块及版本选择 (11) 4.2.6BUG 详细描述 (11) 4.2.7其他规范 (12) 4.3BUG分配及处理 (12) 4.3.1BUG 的分配 (12) 4.3.2BUG 处理 (13) 4.4BUG验证及关闭 (13)
1 BUG管理工具介绍 常用的BUG 管理工具有JIRA、BugFree、Bugzilla、Mantis、XPWeb 等。我们公司采用的是 JIAR ，JIRA 是Atlassian 公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。 2 BUG定义 2.1BUG分类 BUG 就是指系统存的各种缺陷，可以从很多角度对BUG 进行分类。 1、从功能方面分，产生BUG 的原因大体可以归结为以下四种： A.重复的功能； B.多余的功能； C.功能没有达到设计的要求； D.功能实现与设计要求不相符。 2、从易用性方面分，可以归结为三点： A. 界面不美观，控件排列、格式不统一，焦点控制不合理或不全面； B .缺少帮助信息，或者帮助信息不完全； C.功能操作复杂，提示信息不合理，易产生歧义。 3、从安全性方面分，BUG 可以划分为以下几类： A.数据有效性检测不合理； B.重要数据在传输中没有加密； C.缺少身份认证机制或认证不合理； D.数据产生缺乏随机性； E.网络安全性：开放端口、服务； F.系统日志、审计。 4、从可靠性方面分，BUG 可划分为以下几类： A.数据存贮的可靠性； B.业务处理的可靠性； C.硬件可靠性：如打印机； D.应急处理措施； E.数据备份、恢复。 5、从性能方面考虑，BUG 可划分为三种： A .并发量； B .吞吐量； C .响应时间。
天华为内部的PCB设计规范
□指示□報告□連絡 發文單位：製造處技術中心發文日期：88.7.12 事由：PCB Layout Rule Rev1.70 -------料號------------------品名規格------------------供應商-------- ALL Mother Boards, ALL CARDS, ALL CD-ROM BOARDS, ALL DVD BORADS, ALL SERVERS (for R&D1, R&D2, R&D4, R&D5, R&D6) 1.問題描述(PROBLEM DESCRIPTION) 為確保產品之製造性, R&D在設計階段必頇遵循Layout相關 規範, 以利製造單位能順利生產, 確保產品良率, 降低因設計 而重工之浪費. “PCB Layout Rule” Rev1.60 (發文字號：MT-8-2-0029)發文後, 尚有訂定不足之處, 經補充修正成“PCB Layout Rule” Rev1.70. PCB Layout Rule Rev1.70, 規範內容如附件所示, 其中分為: (1)”PCB LAYOUT 基本規範”:為R&D Layout時必頇遵守的 事項, 否則SMT,DIP,裁板時無法生產. (2)“錫偷LAYOUT RULE建議規範”: 加適合的錫偷可降低短 路及錫球. (3)“PCB LAYOUT 建議規範”:為製造單位為提高量產良率, 建議R&D在design階段即加入PCB Layout. (4)”零件選用建議規範”: Connector零件在未來應用逐漸廣泛, 又是SMT生產時是偏移及置件不良的主因,故製造希望 R&D及採購在購買異形零件時能顧慮製造的需求, 提高 自動置件的比例. (5)“零件包裝建議規範”:,零件taping包裝時, taping的公差尺 寸規範,以降低拋料率. 負責人：林士棠. 完成日期：88.7.12
Bug定义规范
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定义规范
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的状态
BUG需求提交规范
BUG\需求提交规范 1．客户名称：广州方泰电子（需求） A、问题描述：客户为防止业务飞单，想设置权限隐藏邮件模块客户的发件地址，不让业务员直接接触客户。（客户已设置所有业务必须先建客户资料才允许发邮件） B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)： 4.6版本 C、问题图片： D、解决方案： 2. 客户名称：广州方泰电子（需求） A、问题描述：客户想在客户自定义模块设置一栏，可以统计客户其他自定义几项之和或乘积。 B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)： 4.6版本 C、问题图片：
D、解决方案： 3. 客户名称：茂名腾云电子（需求） A、问题描述：邮箱模块搜索功能太繁琐，需要搜索框默认根据主题、附件名、正文、邮箱账号任一条件搜索！ B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)： 4.6版本 C、问题图片： D、解决方案： 4. 客户名称：茂名腾云电子（需求） A、问题描述：邮箱模块无置顶功能 B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)： 4.6版本 C、问题图片：
D、解决方案： 5. 客户名称：茂名腾云电子（需求） A、问题描述：写邮件时设置提醒功能，到时间能自动提醒，根据提醒链接能查看提醒内容。 B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)： 4.6版本 C、问题图片： D、解决方案： 6. 客户名称：茂名腾云电子（需求） A、问题描述：左侧选择对应客户，选择编辑客户资料时，右侧不能立刻同步客户资料信息。 B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)： 4.6版本 C、问题图片：
华为公司人力资源管理体系
华为公司人力资源管理体系第一章公司人力资源管理的组织体系与运作方式 一、人力资源管理委员会的职责、成员与运作 1、人力资源管理委员会（HRMC）的职责：HRMC负责管理、监督公司级人力资源决策与活动，为业务发展提供支持；同时对人力资源领域的战略问题向EMT提供建议，以支撑公司的增长和公司的战略。 2、人力资源管理委员会的成员： 主任：人力资源总裁 成员：人力资源部主管、各大部门主管、华为大学主管、各大部门干部部主管；根据具体议题需要，邀请有关业务部门代表参加。 秘书机构：人力资源部 3、人力资源管理委员会的运作： 会议频度：每季度一次，可根据需要召开特别会议 二、人力资源管理部工作职责 1.根据公司总体业务发展战略的需要，提出相应的人力资源战略，组织制定全球人力资源政策，并实现对公司全球人力资源业务的管理。通过对人力资源体系与机制的完善与推行，为公司业务正常运作及发展提供人力资源支持，促进公司商业目标的达成。 2.根据公司政策导向，建立和完善公司人力资源管理机制，通过人力资源管理体系的高效和有效运作，促进公司业务顺利开展。 3.根据公司业务发展战略，组织制定中长期人力资源发展规划及政策并实施，确保公司中长期业务发展得到人力资源的有效支持。 4.根据公司业务发展状况，通过制定有效的绩效管理和激励政策并组织实施，提高公司整体竞争力，促进公司可持续发展。 5.建立、完善并推行有利于员工成长的职业发展机制，通过培训、培养和任职资格管理，促进员工能力的提升和人岗匹配。 6.根据行业特征、公司的战略及公司员工总体特性，营造积极向上的工作氛围，建设良好的企业
文化，促进员工与公司关系的和谐和发展。 7.根据公司价值导向，制订薪酬福利政策并实施，提出合理的薪酬结构和新酬标准，对员工进行及时、有效的激励，持续吸引、保留优秀人才和关键员工。 8.基于公司全球化战略，参考国际惯例，结合业务需求，建立并优化海外人力资源管理体系，制订相应政策，以促进国际业务的拓展。 9.根据公司对人力资源体系的要求，建立公司人力资源组织架构、人员体系和干部后备队伍及运作机制，促进人力资源体系的成长满足业务的需要。 第二章管理者的人力资源管理职责 1.人力资源管理不只是人力资源管理部门的工作，而是全体管理者的职责。 2.各部门管理者有责任记录、指导、支持、激励与合理评价下属人员的工作，负有帮助下属人员成长的责任。 3.下属人员才干的发挥与对优秀人才的推荐，是决定管理者的晋升与人事待遇的重要因素。 4.提升员工任职能力:任职资格标准可以为培训提供需求，牵引员工学习；认证复核过程中提出的改进点，用于指导员工制订改进计划、有针对地参加培训及相关锻炼；用于帮助主管合理地分配工作任务、有针对性地对员工进行辅导；为培训机构有针对地组织培训提供参考。 5.在职位管理中 （1）人员选拔与调配：出现职位空缺或根据组织需要进行岗位调配时，优先从已获得职位要求的任职资格的员工中选拔、聘用；对外招聘时，可以参照相关职位的任职资格标准确定聘用标准。 （2）任命管理：任命前，需对拟任命职位的拟任职者进行任职资格审核，任职资格审核未通过者不得上报审批。 （3）员工职级管理：任职资格达标作为员工职级调整的必要条件，原则上未获得相应任职资格等级的员工，职级不得上调。 6.在人力资源规划中：员工任职资格分布，是制订人力资源规划重要依据。 7.在年终评议中：任职资格结果作为年终评议的重要参考依据。 8.在其他方面：如会议参与权、决策权或决策参与权、资源调配权、审批权等。 第三章人员选拔与流动渠道
BUG处理流程规范
BUG提出和处理流程规范 1引言 1. 1目的 提高测试以及产品缺陷修改效率，避免出现搁置和遗漏的缺陷，从而提高产品的质量，降低质量检查和缺陷修改成本 1. 2适用范围 适用于研发部门（Confernece、Flash、监控），质量保证部门 1.3 定义 bug：通过测试检查出的产品缺陷； 新建、打回、已确认、已指派、已解决、已关闭：测试中bug的不同状态，详细信息见本规范第3部分； 1. 4参考资料 无 2 BUG提交和处理规范说明 1、在测试人员提交bug的时候，必须对bug信息进的描述必须详细全面、清晰明确，如果有条 件，需要描述使用的环境，在BUG出现前的具体操作，如果抓图，必须抓取jpg全屏图象，但不能使用BMP格式上传到BUG库中，有抓包文件需要上传BUG库，空间不够需要放到\\192.168.0.254\qa\测试\bug日志目录中，标题以BUG号区分； 2、在测试人员提交bug的时候，必须按具体情况，填写重要级别、出现频率、优先级别三个栏 目，而非测试人员不得对上述信息进行直接改变，如觉得这三个信息填写不恰当，可以在该bug下的注解中提出意见，并“打回”给bug提交人员或质量部经理处，经过确认后修改；
3、开发人员对bug进行处理后的变更状态成“打回”时，或“指派”给产品部门时以及变更成 “已确认”时必须进行必要的描述和说明,在状态变更时，必须要指定具体接收人； 4、开发人员在注解中描述该BUG计划什么时候解决或做其他阐述的时候，要明确写清承诺的 具体版本号，禁止使用“上一版本”、“本版本”、“下一版本”等字样，以免造成误会或混淆； 修改完成的BUG注释中加入相关的确认信息，如“XXX Review并通过。 5、如果已经是“关闭”状态的BUG，测试人员在后期测试中又出现了需要重新打开，重开后 的BUG状态为“打回”，测试人员需要再多一个操作，即“指派”给具体的研发人员。 6、一直处于“打回”状态的BUG，测试人员需要经过两轮（即两个版本）测试后仍然没有重 现的，可以关闭。但是此两轮测试在该BUG中必须有注释，比如：“XX版本（要求有具体版本号）测试没有重现”，当第二轮测试仍没出现时也需要注释一次，即可进行关闭。 3 Mantis Mantis是PHP/MySQL/Web-based缺陷跟踪系统。 其特点： 个人可定制的Email通知功能，每个用户可根据自身的工作特点只订阅相关缺陷状态邮件； 支持多项目、多语言； 权限设置灵活，不同角色有不同权限，每个项目可设为公开或私有状态，每个缺陷可设为公开或私有状态，每个缺陷可以在不同项目间移动； 主页可发布项目相关新闻，方便信息传播； 支持上传文件，提供进一步的bug信息； 支持上传项目文档； 方便的缺陷关联功能，除重复缺陷外，每个缺陷都可以链接到其他相关缺陷； 缺陷报告可打印或输出为CSV格式。支持可定制的报表输出，可定制用户输入域； 有各种缺陷趋势图和柱状图，为项目状态分析提供依据，如果不能满足要求，可以把数据输出到Excel 中进一步分析； 流程定制不方便，但该流程可满足一般的缺陷跟踪。 在提交bug时需要填写相关信息，还可以上传相关文件（如出错的log或者截图等），对于bug添加注释（允许再次更新）。下面是基本信息的介绍 [出现频率] 可重现-- 稳定地能重现 经常-- 比较经常出现 偶尔-- 偶尔出现 不可重现-- 无法重现 N/A -- 其他情况 [严重性] 不合理或别扭-- 使用不方便，吹毛求疵的标准 文本错误-- 文本错误 崩溃死锁-- 导致死机的bug 严重错误-- 导致功能无法正常运行下去
华为新员工培养及管理办法(修订)
华为技术有限公司 管理工程部文件 新员工培养及管理办法（修订） 一、目的 为了使新员工管理规范化和有据可依，特制定本办法；并以此作为公司《试用期员工综合考核实施暂行办法》的补充文件，指导新员工管理工作的具体实施。 二、适用范围 本办法适用于所有新员工。对新员工的管理前三个月为辅导期，同时也是新招员工的试用期，试用期是对新招员工而言，一般为三至六个月，最长不超过六个月；后三个月为跟踪期。具体适用范围的规定见相关的制度和实施细则。 三、指导思想及宗旨 为了使新员工尽快熟悉工作环境，尽快融入华为文化，顺利度过岗前磨合期，本办法将包括一系列相关的制度和管理规定，由干部处根据情况的变化作相应的补充和修订。 四、新员工考核 新员工在辅导期内的考核以月度PBC为主。对于内部调配进来的员工，条件成熟时可直接采用季度PBC考核；而新招进来的员工在试用期期间只填写月度PBC，并进行相应考核。具体考核方法见《管理工程部绩效改进考核实施办法》。 五、思想导师制 思想导师制度是经过实践证明行之有效的人才培养方式。它一方面帮助新员工尽快融入华为文化氛围、熟悉管理工程部工作环境和工作流程，顺利接手工作、进入角色；另一方面，也为公司培养一批训练有素，既是业务骨干、又具备组织领导才能的后备干部队伍。
管理工程部干部处负责思想导师的管理工作，包括指导及检查相关工作、资格审查、激励、新员工实习结束后的评定等。 1、导师任职要求 （1）部门业务骨干或主管，业务联系紧密，工作接触多，有能力对新员工进行业务方面的指导。 （2）认同华为文化，责任心强，心态好，思想作风正派，乐于助人，有能力对新员工进行思想引导。 （3）有较强的计划、组织、管理、沟通能力，善于引导与激励。有能力为新员工制订合理的计划、安排相应的工作任务。 2、导师职责 （1）在思想上给予引导和帮助，引导新员工认同并尽快融入华为文化，严格遵守公司制定的各项规章制度。主动了解并帮助新员工解决工作、学习、生活等方面的困难，使之尽快安定思想，融入工作群体。 （2）通过制订培养计划（内容包括为新员工安排学习和工作的内容），对新员工进行业务指导并传授工作经验、工作方法，提高新员工的工作技能。应注意安排新员工边干边学，工作量要饱满。 （3）对需进行转正答辩的新员工进行辅导，帮助其通过答辩。 3、导师制实施过程与方法 （1）确定导师：新员工进部门第一天，由其所在部门主管从思想导师资源池挑选并指定思想导师，同时反馈给干部部备案。为保证效果，原则上一位导师同时所带新员工不应超过两名。 （2）制订新员工培养目标和月度工作计划：导师被确认后，应尽快与新员工认真沟通，了解其专业知识结构，根据本部门需要和新员工实际情况，与部门主管协商共同为其制定详细计划。三天内以月度PBC的形式明确出新员工培养目标；在第一个月内应使新员工明晰其工作定位及职责。培养计划一式三份，思想导师、新员工和干部部各一份。 （3）进行辅导和沟通：导师在辅导期内对新员工进行指导，一般每周至少应正式沟通一次，其他可在工作之余进行非正式沟通，指出其优点和需改进的地方，帮助其进步。对沟通的情况、反映的问题要有相应的记录。 （4）总结与考核：每个计划月度末，导师和新员工要对计划实施情况进行总结，
bug规范文档
1 测试用例规范
此规范定义了测试用例的属性、级别、撰写以及执行等规范。
1.1 用例级别属性（Keywords）
此字段主要是用来标识用例的级别， 通过对用例的级别定义， 可以使整个测试过程分级 式管理，从而指导测试流程的顺序、突出重点问题、选择性测试，节约了测试成本，同时也 便于更好的表述和分析测试结果。 也是我们定义开始测试标准、 停止测试标准以及回归测试 标准的一个依据。所有的用例将被定义的状态如下： 1、Base（基础，可测用例） 此级别为基础型， 表述了能保证系统可以运行的基本条件， 同时也定义了此安装包可以 进行下一步测试的标准。
如：是否有遗漏功能、安装测试、基本功能点是否没有问题、各项服务是否都是正常运 行、提交制品是否相符等等。
2、Important （重要，可测用例） 此级别为重要型，在完全通过了 Base 类型用例的测试后，首先要测试的用例，这些用 例表述了系统能正常运行的条件和此版本发布必需要满足的条件。 此类型的用例将符合以下 标准之一：
涉及整个功能模块的用例，如果此用例不通过，将导致功能模块不可使用或功能不正常的用例。如： 注册用户、注册服务等等。 能表明某项功能基本满足需求的用例。 涉及到共性问题的用例，如： 发送消息等。 在 release Note 声明解决的 bug。 用户在正常使用中，出现频繁情况的用例。
3、Normal（普通用例） 此级别为普通型， 测试用例的主体。 该类型的用例主要针对在保证系统正常运行的前提
下，对功能行用例进行完善，对功能性用例进行扩展。另外还有测试系统对特殊情况、异常 情况、异常操作情况的处理能力，从细微找出系统漏洞，从而更加完善系统的抗压性和稳定 性。 4、Extend（扩展用例） 此级别为建议型， 该类型用例针对不影响系统正常运行的建议， 力图完善系统现有功能 或提出对系统功能的展望。如：界面显示信息明 确、系统退信的语言规范等
1.2 用例书写规范
1、Test Case Title 命名规则 用例命名时用例应该能够描述出用例的测试目的。 2、Summary 详细信息
Summary 标签，概述了用例的基本情况，应包含以下信息：
测试目的。概述此用例的测试重点和容易出现问题的地方（必写项） 。 前提条件。描述此用例能够执行的基本条件（必写项） 。 测试数据。描述此用例使用的测试素材，包括：输入字符串、大小等数据。 备注。选择填写，可在此项描述用例的测试历史，曾经出现的 bug 等需要表述给测试人员的信息。
3、Steps 设计步骤 此标签为执行用例的主要步骤标签，详细的描述了用例执行的方法步骤和应有的结果。 对此标签的撰写做以下规范：
每一步操作都对应唯一的功能点。避免没有对应功能点的无用步骤，同时也避免一个步骤对应多个功 能点的情况 每一操作步骤的 Expected Result 必须填写。且只能出现描述结果的语言，不能出现描述操作的语言
4、Attachments 附件 此标签为已有的用户添加附件。通过附件可以更加清楚或方便的表述用例内容，如：通 过 Excel 文件批量添加用户、上传本地数据库文件等。