测试优先级 与 重点测试的讨论

高优先级 - 必须测试

中优先级 - 应该测试，只有在测试完所有 高优先级 项后才进行测试

低优先级 - 可能会测试，但只有在测试完所有 高优先级 和 低优先级 项后才进行测试

 

 

重点测试的部分：同一个优先级中需要重点测试的部分

 

 

用户要求的功能都是必须测试的。

如果按软件需求这么大的点来划分测试的优先级，那么24个需求都是高优先级，所以测试优先级只能在测试需求的层面来划分。

………………………………………………………………………………………………………………………………………………

说明：

  测试优先级是决定哪些测试需求在这个阶段必须执行（高级），哪些次之（中级），哪些再次之，甚至可以不执行（低级），也就是说，测试优先级是解决测与不测的问题。而重点测试是在如果决定执行测试需求的情况下，对它的重视程度（比如，一个功能关联到很多其它的功能，那么对它的重视程度肯定高）。

   重点测试 与 测试优先级没有必然的联系。重点测试只是在某一个优先级中必须重视的部分。

一篇测试测试需求文档包含很多测试需求。测试优先级首先划分出某个阶段必须测试的需求，可以延缓测试的需求，可以不测试的测试需求，然后，在各级中各自中挑选出重点测试的测试需求，这个就是我的基本想法。

  优先级的确定的依据，一个是根据软件需求优先级的说明来参考，如果没有，就只有测试人员自己根据对系统的认识来辨别了。

我认为，用户要求实现都是必须测试的，也就是优先级高的（除非软件需求标明了用户的这个要求优先级较低）。现在我们的软件需求上没有标明优先级，也就看不出明确的优先级，虽然我们也可以自己来确定一下这个软件需求的优先级，但考虑到此次的软件需求也并不多，所以没有必要来划分，所有的软件需求都做为高优先级来处理。

一个软件需求对应多个测试需求，有些测试需求是在第一阶段必须测试的，有些不是。现在从测试需求这一层来划分优先级。

因为用户要求的就是必须测试的，所以，就算是一个单据上增加一个字段，对这个字段的测试也是高优先级。原因很简单，如果这个字段是用户必须用到的，但是我们提供的这个字段无效，对用户来说那就是一个很大的bug了。所以在高优先级中可能会看到一些看起来很不起眼的测试用例，但必须测试到。

当划分好优先级之后再划分出重点测试的部分，重点测试的部分是复杂度比较高的部分，出现错误的几率比较大的地方，象那些只添加一个字段这样不起眼的测试需求就被划分到非重点测试的部分中去了。