软件测试一般bug分类

测试用例首先来自于对于需求的分析，是否能为测试挑选最合适或最关键的需求，关系到项目的成败。

思考方法1：正反面思考法

为每个测试需求至少编制两个测试用例：正面测试用例& 负面测试用例

正面测试用例：用于证明该需求已经满足； 负面测试用例：反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求

基本流：是经过用例的最简单的路径

备选流：在某个特定条件下执行

前置条件是执行用例之前必须存在的系统状态，后置条件是用例一执行完毕后系统可能处于的一组状态。

针对不同的被测项目(或程序,软件),可能都有不同的方式.因为项目不同,可能遍写的用例的覆盖程序,详细程序等都不同.评审指标也不同.
    好的用例可以使测试完整,完善,提高项目质量.
    有时候,"以偏概全"未必是坏事.用例的评审,除了按基本业务流过一遍后,最重要的应该结合项目的风险(系统,安全,应用风险)等,对用例进行审核

测试用例的优先级别

首先，你必须确定什么是你优先级别的类型和其暗示着什么。就我们的目的来说， 我们将用一个假设开始，那就是我们可能发现的缺陷的严重程度和那些相应测试用例的优先级别之间是平行的。

1 –小版本确认测试（Build Verification Tests (BVTs)：也叫做“冒烟测试”，一组你想先运行的以确定这个给出的小版本是否可以测试的测试用例。如果你不能访问每一个功能区域或执行其他测试用例依赖的基本操作，那么在执行这个优先的测试用例之前，试图做其他任何的测试都是没有意义的，因为他们大多数肯定要失败。

2 – 高（Highs）：最常执行以保证功能性是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合。

3 – 中（Mediums）：这是使给出的功能区域或功能变得更详细，检查功能的多数方面包括边界，错误和配置测试的测试用例

4 – 低（Lows）：这是通常最少被执行的测试用例。但这并不意味着这些测试都不重要，只是说他们在项目的生命期间里不是常常被运行，例如GUI，错误信息，可用性，压力和性能测试。

我们将测试用例分成4类：BVTs，高，中和低。现在的问题是将测试用例分到不同的优先级别里。毕竟，优先级别将指出哪些测试用例被认为是需要更频繁的执行的，哪些又不是。