要点：需要一个web工具来记录和跟踪Bug。

状态：在一个项目或者系统中需要定义Bug的状态，方便测试和开发工程师的交流，以下是几种状态的定义：

  Open ：bug已经提出但是下一步动作还没有开始，

  Waiting For PAR ：所有的开发和测试工程师都确定这个Bug是有效的，但是PAR还没有创建，（注：PAR指的是记录问题的一个Project Action Report，相同的或者一个version的问题可以分配一个PAR号）

  PVCS : Bug已经log到PAR上了并且在PVCS上做好了记录，（注：这里所说的PVCS是一种功能强大的配置管理工具）

  Closed ：决定或修改所有的部门都已经同意并且执行了，此时Bug可以closed。

职责分配：当logging或者editing一个Bug, 团队里面改变状态所需要分配的任务状态：
 
  Development：1.当Bug创建或者修改后开发工程师评估Bug和创建PAR
               2.当测试工程师评估和回应开发工程师的回应时，和开发工程师回应下一个修改动作时。
 
  V&V：1.当测试工程师创建和修改Bug时，或者测试工程师有一些其它的动作（eg：改变脚本，重运行脚本，开始根据PAR修改脚本）
       2.当开发工程师评估和回应测试工程师为这个Bug作的下一个修改动作

  Other：当开发或测试组人员不在，由其它相关部门人员为Bug作的修改进行回应。

注：此种方案适宜于开发和测试工程师不在一起的情况。当然如果成员在一起的话也可以用此方案，使之流程化，方便配置管理。

 

MC/DC(修订的条件/判定覆盖)(Modified Condition Decision Coverage)准则是一种实用的软件结构覆盖率测试准则, 已被广泛地应用于软件验证和测试过程中.

condition 和 decision 的概念:

if A or B and C then

Statement;

else

Statement2;

A,B,C都是一个条件,而(A or B and C)叫一个Decision,如果是判定覆盖的话只需两个case就能覆盖,就是让这个decision为true和false各一次就能达到即为 0 1 1 , 0 1 0

如果是MC/DC的话就得四个case,而且只比条件数目多一个而已,怎么计算的呢?

定义: 在每个判定中的每个条件都曾独立的影响判定的结果至少一次, (独立影响意思是在其他的条件不变的情况下,改变一个条件);

总结一句:每个条件对结果都独立起作用

比如A对结果起作用的话, B 必须为 false, C必须为 true -- 1 0 1 和 0 0 1, 这样结果就独立受A的值影响.

同理如果B对结果独立起作用的话,A必须为false, C必须为 true, 两种情况B为true,false各一. 即为 0 1 1 和 0 0 1

而C独立对结果起作用的话就是让(A or B) 为 true, 为了减少case, 上面的case 已经含有这样的case了,我们就取A为false,B为true, 这样c独体起作用的case为: 0 1 1 和 0 1 0

可以看出每个条件各走了一次true和false, 这样三个变量条件就会有六个case, 我们看出其中里面还有两个是重复的,

序号a b c output

A 1 1 0 1 1

2 0 0 1 0

B 3 0 1 1 1

4 0 0 1 0

C 5 0 1 1 1

6 0 1 0 0

case 2 和case 4重复, case 3 和case5 重复,这样去掉两个 剩四个case,我们发现我们的判定里面的条件数为N个, 那么这个判定就需要N+1个case,不信你试试!