营销网站建设设计,网站设计之路,wordpress 搜索框 位置,查询公司水利平台网站1BUG定义 1.1Bug状态
BUG状态标记BUG当前所处的状态#xff0c;是用来处理BUG流程的主要参数#xff0c;JIRA缺陷管理平台有以下一些状态#xff1a;
新增#xff08;New#xff09;#xff1a;测试人员新发现的系统Bug#xff1b;
打开#xff08;Open#xf…1BUG定义 1.1Bug状态
BUG状态标记BUG当前所处的状态是用来处理BUG流程的主要参数JIRA缺陷管理平台有以下一些状态
新增New测试人员新发现的系统Bug
打开Open测试人员通知开发人员需要修改的BUG
修改Modify开发人员正在修改的BUG
固定Fixed开发人员通知测试人员已修复的BUG
跟踪Trace测试人员短时间内很难确定是否已经修复的BUG
已关闭Close测试人员经回归测试后确定已修复的BUG
已否决Rejected被开发人员否决了的BUG
重新打开ReopenBug未被修复重新出现在新的测试版本中
延迟修改Wait因为种种原因需要等待延期修复的Bug。
无效bug现在及以后都不需要改代码的bug;
无效bug处理流程
1 测试理解错误不需要改代码解决的问题开发直接选择解决方式是无效bug算无效bug
2 测试理解正确PRD没有明确说的但是经过产品确认现在以后都不需要解决的问题研发或者产品增加备注然后解决方式为无效bug算无效bug;
3 Prd修改但是测试没有得到通知根据旧prd报的bug开发选择解决结果是无效bug解决方式选择 “需求理解偏差”算无效bug
4 PRD没有写但产品确认需要改bug提给产品/经办人改成产品bug引入阶段改成需求研发改完产品修改bug状态为已完成/已修改不算无效bug
5 体验类优化的问题前端组件不支持算已解决-未解决, 产生原因 外部原因不算无效bug
1.2Bug优先级
紧急
导致产品无法正常运行或需要优先处理的任务
重要
系统崩溃、丢失数据或内存溢出等严重错误
一般
一般性错误
次要
程序功能出现错误但可通过其他手段解决
无关紧要
不影响程序运行的错误如拼写错误等
1.3BUG自测是否应发现
否该缺陷不属于研发自测应发现范畴
是在开发自测用例中在本次所给自测用例可发现范围内属于自测应发现情况
是不在开发自测用例中在冒烟用例集中并未在本次项目/需求所给自测用例内但属于自测应发现范围
1.4缺陷严重程度
1致命错误
致命错误通常有如下情况
1、需求书中的重要功能未实现
2、造成系统崩溃、死机并且不能通过其它方法实现功能
3、常规操作造成程序非法退出、死循环、通讯中断或异常数据破坏丢失或数据库异常、且不能通过其它方法实现功能的。
2严重错误
严重错误通常使系统不稳定、不安全、或破坏数据、或产生错误结果而且是常规操作中经常发生或非常规操作中不可避免的主要问题通常有如下情况
1、重要功能基本能实现但系统不稳定、一些边界条件下操作会导致run-time error、文件操作异常、通讯异常、数据丢失或破坏等错误
2、重要功能不能按正常操作实现但可通过其它方法可实现
3、错误的波及面广影响到其它重要功能正常实现
4、密码明文显示
5、C/S、B/S模式下利用客户端某些操作可造成服务端不能继续正常工作的。
3一般错误
程序的功能运行基本正常但是存在一些需求、设计或实现上的缺陷次要功能运行不正常通常有如下情况
1、次要功能不能正常实现
2、操作界面错误包括数据窗口内列名定义、含义不一致
3、打印内容、格式错误
4、查询错误数据错误显示
5、简单的输入限制未放在前台进行控制
6、删除操作未给出提示
7、数据库表中有过多的空字段
8、因错误操作迫使程序中断
9、找不到规律的时好时坏
10、数据库的表、业务规则、缺省值未加完整性等约束条件
11、经过一段时间运行后系统性能或响应时间会变慢
12、重要资料如密码未加密存放包括配置文件中的密码或其它存在安全性隐患的
13、 硬件或通讯异常发生恢复后系统不能自动正常继续工作需要过多的人工干预才行
14、系统兼容性差与其它支持系统一起工作时容易出错而没有充分理由说明是由支持系统引起的或者由于使用了非常规技术或第三方组件造成不能使用自动化测试 工具进行测试的。
4优化建议
可以提高产品质量的建议包括新需求和对需求的改进以及程序在一些显示上不美观不符合用户习惯或者是一些文字的错误通常有如下情况
1、界面不规范
2、辅助说明描述不清楚
3、输入输出不规范
4、长操作未给用户提示或长操作结束后提示没有消失
5、提示窗口文字未采用行业术语
6、可输入区域和只读区域没有明显的区分标志
7、界面存在文字错误
8、在功能实现方式上如果需求中没有明确定义而没有按常规实现并且不比常规方式实现优越的( 如用户名第一位用数字或特殊字符) 1.5缺陷产生原因
1、 产品需求问题
需求不清晰或错误导致设计目标偏离客户的需求从而引起功能或产品特征上的缺陷
2、 编码错误
程序逻辑问题包括对程序逻辑路径或数据范围的边界考虑不够周全漏掉某些边界条件造成容量或边界错误。
3、 需求变更
4、 关联系统/模块影响分析不足
为考到上下游系统的或内部模块间的相互关联及影响造成的缺陷
5、 第三方工具引起的问题
6、 新技术不熟悉
新技术的采用可能涉及技术或系统兼容的问题事先没有考虑到。
7、 设计错误
系统结构非常复杂而又无法设计成一个很好的层次结构或组件结构结果导致意想不到的问题或系统维护、扩充上的困难即使设计成良好的面向对象的系统由于对象、类太多很难完成对各种对象、类相互作用的组合测试而隐藏着一些参数传递、方法调用、对象状态变化等方面问题
8、 环境问题
系统运行环境复杂包括硬件环境及软件外部依赖环境依赖接口不稳定等因素造成的缺陷
1.6缺陷类型 1. 功能遗漏:
未按需求文档实现功能缺失
2. 程序逻辑错误
需要进行逻辑分析代码修改如循环条件、计算顺序错误、逻辑顺序错误等
3. 程序校验错误4. 界面错误
前端页面排版、显示等交互问题
5. 兼容问题
服务端与前端兼容问题、软件间
6. 用户体验问题/优化提升7. 接口问题
模块接口间调用问题如参数问题
8.性能问题
不满足系统可测量的属性值如、执行时间事务处理速率等缺陷
9. 安全问题10.环境问题
由于设计、编译、运行环境引起的问题
2BUG的生命周期
1、测试人员在测试中发现BUG需要将其添加记录到JIRA中并制定给对应的开发/产品人员进行处理。
2、开发人员修改好BUG后需要在注释框中填写说明信息并将BUG的状态设为“已修正”状态同时开发人员如果认为有的缺陷没有必要修改、无法重现、延期修改等可将其设置为对应的“被拒绝”、“重复的”、“信息不足”、“无法重现”、“延期修改”等状态。
3、开发人员处理完毕BUG后需要测试人员对BUG进行验证验证通过后就把其状态设置为“已关闭”状态若验证不通过则把状态设置为“重现开启”状态。
4、对被置为‘被拒绝’状态的BUG测试人员与开发人员协商后同意关闭则置为‘已关闭’若测试人员不同意关闭则把BUG状态置为“重新开启” 然后开发人员继续修改若不用再修改则置为‘已关闭’若延期处理则置为‘延迟修改’。
5、对被置为“信息不足”状态的BUG需要测试人员补全信息然后重新开启让开发人员继续修复。 3BUG管理规范
合理的BUG流程管理有助于提高整个项目的效率与质量。BUG管理规范要求在BUG提交、BUG分配、BUG处理、BUG验证、BUG跟踪等环节都要进行规范。以下为各个环节的具体规范要求。 3.1BUG提交规范
BUG 描述的清楚与否可以很好的帮助开发人员快速定位、解决问题而且还可以提高测试人员基本测试技能。因此建立标准的BUG描述规范是十分重要、也是十分必要的。 首先清晰的BUG 描述可以帮助开发人员快速定位、解决问题。软件测试部门中员工的水 平各有不一对于 bug 的认知、描述侧重面也会存在不同。因此如同一个问题由不同测试人员描述 bug就有可能会存在描述不一致的问题。这就会造成让开发人员理解不清晰从而延误解决问题的周期。
其次标准的BUG描述可以提供测试人员的基本测试技能。如有新入职员工他可以先从BUG库中查找BUG了解公司产品的整个开发、 研制中产生的问题。 而标准清晰的BUG描述可方便快速的使其尽早、尽快的融入我测试部门。另外对于BUG的追踪验证时 由于是不同测试人员进行验证所以规范的BUG描述可以提高测试人员验证问题的效率。
