标签：
怎么提交缺陷？测试过程中都要注意什么？
第一 缺陷截图
理由：
缺陷可能难以重现，而在你再次验证该缺陷前你并不知道这点，所以养成先对缺陷截图的习惯，这样不管啥时候，你都可以对相关人员直观的展示出现过的问题。至少别人不可以否认你说“问题压根不存在”
第二 是否重现
对于发现的缺陷，至少进行2-3次的重复验证。
理由：
1.判断缺陷是否可重现
2.确定重现缺陷需要的最简单步骤
遇到难以重现的缺陷怎么处理？
a) 停止操作，开始记录
尽量回忆之前的操作步骤、操作过程，并记录下来。包括操作环境。所以，个人觉得测试前有必要准备一个记录模版，专门用于记录这类问题。这个有助于后续的缺陷跟踪。
b)判断缺陷的严重性
缺陷虽然难以重现，但是难保该缺陷不出现在用户现场，因此需要估量一下有什么潜在的风险？
1.如果缺陷很严重，那么做上重点标记，多花点时间，尽量重现问题。
2.如果问题比较轻微，比如在用户可接受的范围内，那么可以考虑暂时搁置，把时间用在别的模块的验证测试，等其它模块完成了再回过头来找原因，因为时间有限，不要捡了芝麻丢了西瓜。
说明：难重现的缺陷一定要关注，因为有时候它背后可能潜伏着严重问题
c) 联系相关开发人员一起分析问题
一旦重现，保留现场，联系开发人员进行分析。试想，要是程序后台都有操作记录日志的记录，那是不是问题分析是不是简单多了？
d) 缺陷跟踪
原则上：测试过程中出现的任何异常问题都要提交
实际情况：
1.开发人员和测试人员都无法重现的情况下，提交的缺陷一般是不会被处理的（特别是开发也忙的时候，是不会去排查的），常以“无法重现”或者“无效缺陷”拒绝处理
2.缺陷考核，有些公司对测试人员有考核，比如用户使用产品过程中出现了问题，但是测试如果没提，那就算漏测缺陷，有对应处罚；对开发人员也有考核，比如按严重缺陷数扣钱
那怎么做好呢？
在有考核的情况下，不管是否可重现，直接提交到公用缺陷管理系统
理由：
1.符合原则
2.涉及个人利益，谁想被扣钱或其它处罚呢？？
在无考核的情况下，视缺陷严重程度而决定是否直接提交
1、缺陷等级比较严重，直接提交到公用缺陷管理系统
理由：这个必须要引起重视，难保用户现场就出现了
2、缺陷等级比较一般或轻微，先私下进行文档形式记录，再看情况决定是否提交缺陷管理系统
理 由：不可重现的缺陷可能由于外界环境因素引起的，比如网络不稳定，某一瞬间可能没网络，你恰在这个点进行刷新操作，没刷出内容，这时，你不知道是网络引 起，直接把它当成缺陷了，，站在这个角度看，是不是可以说缺陷实际是不存在呢？你提交了这个缺陷，那就意味着相关人员，如开发人员，要去对这个缺陷进行分 析和关注，这个是要时间投入的
推荐做法：
一般的小问题，文档记录，要是后续重复出现，再考虑把文档中记录的缺陷提交到缺陷管理系统，这样提交的缺陷更具有实际意义。
说明：
提交缺陷管理系统的难重现缺陷应该有个监控周期，一般可以考虑监控2-3个版本，过期还是未重现，可以考虑关闭
第三、是否需求
缺陷是针对需求来说的，如果需求中没有相关说明，有些比较不好确定是否为缺陷的建议如下：
1.如果组织内部有约定，比如提交给需求负责人，则按约定提交(推荐方式)
2.如果组织内没有约定，那以建议的方式提交缺陷。
说明：
建议类缺陷统一提交给产品负责人,好处是，一来和已固定需求分离，避免在开发周期内又新增需求，扰乱计划；二来建议类的是否作为缺陷，是否需要实现，还得产品及其他相关人员进行评审；建议组织内部应该进行约定，比如方式二中，比较不老成的开发可能直接拒绝或把缺陷视为无效缺陷关闭了，而正确做法应该是转需求的。
第四、缺陷的编写
以禅道PSM的创建缺陷为例，截图所示
由上图可知，缺陷一般包含以下元素组成，因为一般我们都是用工具自动化生成数据统计结果的，如果相关元素美填写，那就无法生成相关数据，所以提交前要依据实际项目想清楚要关注哪些元素
-----------------------------------------------------------------------
产品模块：
产品的功能模块，根据模块的缺陷统计，可以看到缺陷的分布情况，那个模块的缺陷比较多，质量较差
所属项目：
一个产品可关联多个项目，一个项目可以有多个版本，每一个版本都拥有自己的缺陷(一般分两部分，一部分是回归测试中未解决的缺陷，一部分是新发现的其它缺陷)
举例：我们公司有做数据库审计类产品，该类产品细分为一体机数据库审计系统，分离式数据库审计系统，一体机数据库审计系统-医疗专版，一体机数据库审计系统-财经专版…等等各种产品，针对每个产品又细分多个版本，一体机数据库审计系统2012Q1版本，一体机数据库审计系统2012Q2版。。。等等各种版本。
影响版本：
项目的完成通过多个小版本的迭代实现
当前指派：
根据缺陷管理，这里一般是指派相关负责人，比如测试经理、项目经理、开发人员。个人比较建议直接指派给直接负责人，直线沟通
缺陷标题：
第一：顺藤摸瓜>见到标题就知道缺陷属于哪个模块的
第二：见名知意>见到标题就知道缺陷描述的是什么
综合这两点：我给的建议书写格式：大模块(-子模块)-问题描述，如下图。
附加好处：缺陷分析时，就算不用工具也可以某个影响版本进行统计，Excel缺陷清单中查找大模块或子模块名称，查看其数目便可以得出缺陷分布情况(前提是组员在提交缺陷时统一遵守约定)，对此也提醒下，模块的划分及名称要适当。
重现步骤:
数据和逻辑分离
好处：
第一：逻辑清晰，易读易懂，因为缺陷是给别人看的。
第二：不因为数据失效而失效。如果数据和逻辑混合:
1.打开数据分析-数据库审计查询
2.输入时间范围：1012-12-22 00：00：00到2012-12-22 59：59：59,10.4.0.6，点击查询
问题：是不是只有这天的ip数据，这个特定的ip才会出现缺陷呢？？（测试验证缺陷，开发验证缺陷，回归验证缺陷），是不是很难说呀
例：如下图
信息要全面，[前提]，[步骤]，[结果]，[期望]，[测试账号]，[缺陷页面地址]，根据实际情况有选择的添加
相关需求：
与bug管理的需求，，这个实际中比较难以做到，一般不填
相关任务：
同上，这个实际中也比较难做到，一般不填
类型/严重程度 :
“类型”这东西有时候真不大好细分，大部分都可看成是设计缺陷，做不到就算了吧，简单就是效率，但是严重程度必须有。
“严重程度”：
第一：分轻重>事分轻重缓急，同样，缺陷是给别人看的，别人更在乎重点，所以建议不要随便给个数字(我们可以把数字和自己定义的严重程度进行对应，在进行缺陷分析时进行缺陷等级统计时，就看这个了)
根据一般的产品管理系统看，缺陷等级分为 五个等级：
1建议 2轻微 3一般 4严重 5致命
至于这些等级对应什么样的缺陷内容，这个不大好说，感觉应该多站在客户角度看待。另一个方面，根据个人经验及其它人的看法，组织内部进行个规范定义。
系统/浏览器：
这个根据具体情况而定，比如要适应多种环境，要同时兼容好几个浏览器，那要把其作为缺陷内容重要部分进行提交，假如只是指定某一浏览器的兼容，那不写也罢。直接在bug重现步骤中添加[操作系统/浏览器] ，省得每次都点击指定
关键词：
附件：
这个挺有用的，比如bug描述中无法放图片时，可放截图，还可以放相关错误信息等
最后
一个缺陷只描述一个或同一类的问题
缺陷优先级
优先级不应该给tester指定，这也是很多缺陷流程制定者容易忽略到的地方——很大一部分原因是流程制定者没有做过项目管理的工作或者学习过项目管理的知识。
为什么这么说呢？
因为Tester只是项目团队的成员之一，对缺陷管理、项目进度和项目风险都不可避免的会“盲人摸象”、“管中窥豹”，只“看”到自己“看”到的那个部分。
一般来说，一个被测系统往往需要多个tester的，而每个tester往往只关注自己发现的缺陷，不大会去了解其他tester所发现的缺陷，那么在这种情况下，他如何能够决定这个缺陷被修复的优先级别呢？！
这里再次强调一次，大家必须了解“Priority”真正的含义和作用——它是给管理者来据此做项目决策的，也就是说，缺陷优先级将直接导致工作安排的优先顺序。PM正是通过参考缺陷优先级来安排开发人员的工作顺序（这甚至能在Project里体现），使得项目风险降低、项目成本降低，解决问题更高效。
其实，这在微软内部就叫做“基于风险的测试”， 也就是指评估测试的优先级，先做高优先级的测试，如果时间或精力不够，低优先级的测试可以暂时先不做。有一个图，横轴代表影响，竖轴代表概率，根据一个软 件的特点来确定：如果一个功能出了问题，它对整个产品的影响有多大，这个功能出问题的概率有多大？如果出问题的概率很大，出了问题对整个产品的影响也很 大，那么在测试时就一定要覆盖到。对于一个用户很少用到的功能，出问题的概率很小，就算出了问题的影响也不是很大，那么如果时间比较紧的话，就可以考虑不 测试。
话说回来，网上有很多自称专家的人在那里大谈特谈所谓的优先级标准，什么“系统死机是高级别，界面错误是低级别”之类。其实这些指的是缺陷的严重级别（Serverity）！
标签：
原文地址：http://www.cnblogs.com/wakey/p/4309242.html
