关于缺陷流转问题

Archer456

目前正在配置ＴＤ　在ＤＥＦＥＣＴＳ模块中　有ＴＤ默认的一个ＳＴＡＴＵＳ的字段　也就是缺陷状态字段．
问一下　是否各位在使用中　也是使用ＳＴＡＴＵＳ去实现缺陷的流转呢？　
他的过程比较简单可以详细见　我提供附件中的　缺陷管理这一节　它是测试和开发人员同时使用ＳＴＡＴＵＳ字段去流转．
而我考虑如下现截取我写的文档中的部分：
5．1 按缺陷状态
       New：新提交的，这个缺陷报告刚提交到缺陷管理系统或缺陷管理配置库中，还没有做任何的处理和响应。
       Unconfirmed：待确认的，测试人无法认定是否为缺陷待负责人确认。
       Reopened：未解决的，该缺陷曾被处理过，但处理的结果不正确或尚未完全修正。
       Resolved：已解决的，该缺陷已经被处理，而且已经测试组验证确实解决。
       Verified： 已验证的，负责人认可了处理人的处理意见并对缺陷进行了验证。
       Closed：  已关闭的，产品版本发布后对缺陷进行关闭，归档。
5．2 按处理意见   
       Duplicate：重复，该缺陷与已有的重复，将意见置为重复时必须说明与哪个缺陷重复。
Worksforme：需要更多信息，依据缺陷描述无法查找问题的原因并解决，需要更多关于该缺陷的信息。
Invalid：不是问题，该缺陷的描述不是问题
       Wontfix：不修改，该缺陷描述的是问题，但是不修改。
       Remind：保留，该缺陷描述的是问题，但是不能确定是否在该版本中修改。
       Later：以后版本解决，该缺陷描述的是问题，但不在该版本中解决。
       Fixed：已修改，已对此缺陷进行了修改，待测试人员重新返测验证。
6 缺陷管理流程      
       6.1缺陷管理流程,描述了从报告新缺陷后,经过确认,修正,验证到最后被关闭的全过程.这个流程可以概括为以下几个步骤.

第一步,测试人员提交新缺陷,并输入到缺陷跟踪管理系统或缺陷管理配置库中
1缺陷状态置为初始状态”New”
2若测试人员无法确认是否为软件缺陷则将缺陷状态置为”Unconfirmed”        
第二步,测试负责人验证缺陷,并做相应处理
     1 若确认是缺陷,将缺陷状态置为”New”并分配给相关开发人员.
     2 若确认不是缺陷保持”Unconfirmed”状态不变
     3 若无法判定则保持”Unconfirmed”状态不变,咨询更多信息以确认是否为缺陷.
第三步 开发人员查询状态为”New”的缺陷报告,并做相应处理
      1 若发现该”New”状态的缺陷与已有缺陷重复,则置处理意见为”Duplicate”同时于备注中必须指明与哪条重复.
   2若依据缺陷描述无法查找问题原因并解决，需要更多关于该缺陷的信息, ,则置处理意见为” Worksforme”
      3若认为该缺陷不是问题, , 则置处理意见为” Invalid”
      4若认为该缺陷是问题但是不修改, 则置处理意见为”Wontfix”
      5若认为该缺陷描述的是问题，但是不能确定是否在该版本中修改, 则置处理意见为”Remind”
      6若认为该缺陷描述的是问题，但不在该版本中解决, 则置处理意见为”Later”
      7若认为该缺陷描述的是问题并对此缺陷进行了修改，正待测试人员重新返测验证, 则置处理意见为”Fixed”
第四步 测试人员查询缺陷报告并根据开发人员处理意见做出相应处理.
      1 若处理意见为”Duplicate”,则需根据开发人员指明的重复去核实情况
           1.1若确认重复, 则置缺陷状态为 “Verified”
           1.2 若为开发人员误判, ,在备注中更新情况置缺陷状态为”Reopened”
      2 若处理意见为”Worksforme”,则需根据缺陷编号查明为哪条测试用例重新执行用例,同时给出更多详细描述.最后在备注中说明更新情况保持缺陷状态为” Reopened”
      3 若处理意见为” Invalid”则需重新验证该缺陷
           3.1若确认确实不是问题, 认可了处理人的处理意见则置缺陷状态为” “Verified”
           3.2 若确认为开发人员误判,则在备注中说明更新情况保持缺陷状态为” Reopened”
      4 若处理意见为”Wontfix” 则需重新验证该缺陷
           4.1若确认确实是可以不修改的问题, 认可了处理人的处理意见则置缺陷状态为 “Verified”
           4.2若确认为开发人员误判,则在备注中说明更新情况保持缺陷状态为” Reopened”
5 若处理意见为”Remind”和”Later”关于什么版本解决,则需指示上级部门确认
           5.1 若上级部门确认确实不能确定是否在该版本中修改或今后版本解决, 则置缺陷状态为” “Verified”
           5.2 若上级部门确认该缺陷需要在该版本中解决,则在备注中说明更新情况保持缺陷状态为” Reopened”
      6 若处理意见为”Fixed”,则需重新验证是否正确修改
           6.1若缺陷已被正确修改, 则置缺陷状态为” Resolved”
    6.2 若缺陷没有修改正确或完全, 则需在备注中说明哪里还需要进一步修缮并置缺陷状态为” Reopened”
第五步 开发人员重新查询缺陷状态为”New”(备注中含有更新情况说明的)和” Reopened”的缺陷报告
       1 备注中含更新说明的”New”状态报告,主要有”Worksforme” “Invalid” ”Wontfix” ”Remind” ”Later”被测试组确认仍存在问题的，需要重新根据更新中的说明去修改缺陷.
       2 若缺陷状态为” Reopened”,则需重新修改该缺陷
第六步 上述5个步骤是一个反复叠代直至缺陷被修改或被确认的一个过程.
        当测试组对该版本的程序测试完成后,测试组需要查询缺陷库中缺陷状态为”Resolved”和“Verified”的缺陷报告,在该测试版本发布后对缺陷进行关闭,归档.

Archer456

开发人员和测试人员公用ＴＤ的默认ＳＴＡＴＵＳ字段　有些细节问题不好处理　所以我新添加了　缺陷状态和处理意见两个字段想通过他们去实现
测试人员只能去修改缺陷状态　开发人员只能去修改处理意见　这样更加详细　对一些细节好解释
可目前的问题是　在配置邮件　触发条件和过滤条件　（ＣＯＮＦＩＵＲＥ　ＭＡＩＬ中的ＦＩＥＬＤＳ和ＣＯＮＤＩＴＩＯＮＳ）
ＦＩＥＬＤＳ中　选择的是ＡＳＳＡＦＮＥＤ　ＴＯ．　ＤＥＴＥＣＴＥＤ　ＢＹ　．缺陷状态．处理意见
现在ＣＯＮＤＩＴＩＯＮＳ中我怎么设置过滤条件都有冲突　开发人员该屏蔽掉的没有屏蔽掉收到了自己不需要看的邮件　而测试人员也是
谁研究下在ＣＯＮＤＩＴＩＯＮＳ中　怎么设置过滤条件呢？

还是ＴＤ我设的这两个字段　太过复杂　无法实现呢　只能用默认的ＳＴＡＴＵＳ字段去实现流转缺陷吗？

Archer456

比方说测试人员配置ＣＯＮＤＩＴＩＯＮＳ如下：
ＡＳＳＩＧＮＥＤ　ＴＯ：空
ＤＥＴＥＣＴＥＤ　ＢＹ：测试员姓名
处理意见：全部意见用ＯＲ连接
缺陷状态：ＮＥＷ　ＯＲ　ＲＥＯＰＥＮＥＤ

开发人员配置ＣＯＮＤＩＴＩＯＮＳ如下：
ＡＳＳＩＧＮＥＤ　ＴＯ：开发员姓名
ＤＥＴＥＣＴＥＤ　ＢＹ：空
处理意见：ＮＯＴ（全部意见用ＯＲ连接）
缺陷状态：ＮＥＷ　ＯＲ　ＲＥＯＰＥＮＥＤ

要看懂我写的　缺陷管理流程　才能明白我想让开发人员只收到ＮＥＷ或ＲＥＯＰＥＮＥＤ状态的报告邮件　测试人员呢只对ＮＥＷ或ＲＥＯＰＥＮＥＤ且处理意见有变化的缺陷报告的邮件

现在的冲突是　当缺陷报告由１ＮＥＷ（开发人员新提交）这时候按我的条件　开发人员可以收到该邮件　而测试人员过滤掉了
　　　　　　　　　　　　　２ＮＥＷ　ＤＵＰＬＩＣＡＴＥ　开发人员认为重复改了处理意见为ＤＵＰＬＩＣＡＴＥ　这时候处理意见一变　　　　　　　　　　　　　测试人员收到了该邮件　　开发人员过滤掉了
　　　　　　　　　　　　　３ＲＥＯＰＥＮＥＤ　ＤＵＰＬＩＣＡＴＥ测试人员验证没有重复　改状态为ＲＥＯＰＥＮＥＤ
　　　　　　　　　这时候状态一变　理论上应该开发人员收到该邮件　可是按照这种条件　开发人员被过滤掉了因为处理意见：ＮＯＴ（全部意见用ＯＲ连接）　而测试人员理论上不需要看该邮件　可是却收到了　因为处理意见：全部意见用ＯＲ连接
缺陷状态：ＮＥＷ　ＯＲ　ＲＥＯＰＥＮＥＤ


提示：ＣＯＮＴＩＤＩＯＮＳ这个条件　是与的关系　只有
ＡＳＳＩＧＮＥＤ　ＴＯ：空
ＤＥＴＥＣＴＥＤ　ＢＹ：测试员姓名
处理意见：全部意见用ＯＲ连接
缺陷状态：ＮＥＷ　ＯＲ　ＲＥＯＰＥＮＥＤ你填的条件都满足　才能放行

Archer456

难道没有ＴＤ达人出现吗？
来个大虾帮分析解决下啊