重要度和优先度引发的思考

在登bug时一定会看到重要度和优先度这两项，而在写测试case时也能看到这两项
（虽然说不同公司有不同的规则，但是作用都是相同的）
。但是仔细想一想，是否知道如何填写才是正确的呢？它们之间有关系吗？是否可以将二者联系起来？一系列的疑问就会脑中不断的跳出来。

也许bug的
重要度更容易判断，因为根据bug内容能大致直观的判断出它对客户的影响大不大；但是
测试case的重要度就相对来说稍难判断了，由于现在很多测试用例是不能单纯从内容上看出来这条用例可能测试出来什么级别的问题，导致写测试用例时这一项几乎形同虚设
。
（用管理工具的可能不在这种情况之内，因为管理工具本身就需要严格的把测试用例区分出测试级别）

上面说的判断能力是需要长时间的摸索总结才会有的。这方面不但需要测试人员的努力，也需要经过长期对测试case的结果分析才可以。所以这方面不做评价。

现在的测试用例大多都是看它是为了测试什么才来写它的内容，就是根据式样等判断依据来设计用例，
以这种思路来设计测试用例的
结果是：设计出来的用例
模式都一样，
如何如何操作应该如何如何显示。
我们很少甚至不用反向思维的方式去思考。我们测试一个机能，可以先假设这个机能有各种级别的bug，然后针对一个级别，思考如何才能让这个机能出现这种级别的问题，从高级别开始一个级别一个级别的设计。我想这大概也是很多设计者的测试用例中很少有边界值测试及异常测试的原因吧。

以上是个人的一点点想法，期待能抛砖引玉。

下面在网上找了一下对于测试错误类型的分类，跟大家分享一下

定义以下五类测试错误类型:

A类—严重错误，包括以下各种错误：

由于程序所引起的死机,非法退出

死循环

数据库发生死锁

因错误操作导致的程序中断

功能错误

与数据库连接错误

数据通讯错误

B类—较严重错误，包括以下各种错误：

程序错误

程序接口错误

数据库的表、业务规则、缺省值未加完整性等约束条件

C类—一般性错误，包括以下各种错误：

操作界面错误（包括数据窗口内列名定义、含义是否一致）

打印内容、格式错误

简单的输入限制未放在前台进行控制

删除操作未给出提示

数据库表中有过多的空字段

D类—较小错误，包括以下各种错误：

界面不规范

辅助说明描述不清楚

输入输出不规范

长操作未给用户提示

提示窗口文字未采用行业术语

可输入区域和只读区域没有明显的区分标志

E类—测试建议