黑盒测试：从用户角度出发，根据规格说明设计测试用例，并不涉及程序的内部特性和内部结构，只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例。黑盒测试有两个显著特点：
   （1）黑盒测试与软件的具体实现过程无关，在软件实现的过程发生变化时，测试用例仍然可以用。

   （2）黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间。

    黑盒测试主要是为了发现以下几类错误：

　  1、是否有不正确、遗漏或额外的功能实现？

    2、在接口上，输入是否能正确的接受？能否输出正确的结果？

    3、是否有数据结构错误或外部信息（例如数据文件）访问错误？

    4、性能上是否能够满足要求？

    5、是否有初始化或终止性错误？

  白盒测试：已知程序的内部结构，检查内部操作是否按规定执行。主要对程序细节进行严密检验，针对特定条件和循环设计测试用例，对程序的逻辑路径进行测试。通过在程序的不同点检查程序状态，确定实际状态是否与预期的状态一致。

    白盒测试主要是想对程序模块进行如下检查：

　  1、程序的所有语句至少执行一次。

    2、对所有的逻辑条件都能至少执行一次。

    3、在循环的边界和运行的界限内执行循环体。

    4、测试内部数据结构的有效性，等等。

   从以上可以看出就算执行了完美的黑盒测试也是无法测试程序内部特定部位，另外当规格说明本身有误，也不能发现问题。而白盒测试能对程序的内部特定部位进行覆盖测试，所以黑盒和白盒测试为互补关系，结合起来进行测试用例的设计更为合理。

经验表明，通常在进行单元测试时采用白盒测试方法，集成测试采用灰盒测试方法，系统测试采用黑盒测试方法。

一、目的

        对 BUG 概念、类型划分、 BUG 状态、 BUG 严重程度等内容进行定义和规范，以便进一步指导我们的软件测试工作。

    二、概念

        BUG ：软件中存在的瑕疵，可能会导致系统失效。简单的说就是软件系统中存在的可能导致系统出错、失效、死机等问题的错误或缺陷。

    三、 BUG 的类型划分

    功能类

    A. 重复的功能

    B. 多余的功能

    C. 功能实现与设计要求不相符

    D. 功能使用性、方便性、易用性不够

    界面类

    A. 界面不美观

    B. 控件排列、格式不统一

    C. 焦点控制不合理或不全面

    数据处理类

    A. 数据有效性检测不合理

    B. 数据来源不正确

    C. 数据处理过程不正确

    D. 数据处理结果不正确

    流程类

    A. 流程控制不符和要求

    B. 流程实现不完整

    提示信息类

    A. 提示信息重复或出现时机不合理

    B. 提示信息格式不符和要求

    C. 提示框返回后焦点停留位置不合理

    建议类
 
    A. 功能性建议

    B. 操作建议

    C. 检校建议

    D. 说明建议
 
    性能类

    A. 并发量

    B. 数据量

    C. 压缩率

    D. 响应时间

    常识类

    A. 违背正常习俗习惯的，比如日期 / 节日等

    特殊类

    A. 不符合 OEM 版本或 DEMO 版本特殊要求的

其实，测试用例不是必须的。如果你是一个特别有想法的人，或者在软件测试方面很有天赋，每天都能找到其他人几天时间才能找到的Bug，那么你可以不用测试用例，如果我是Test Manager的话，就会让你做一个Ad-hoc Tester，因为我已经觉得你足够好了，不需要测试用例来指导你了，因为你很有想法，有自己的测试思路。就像陈宏刚博士在Microsoft公司做Tester的时候，就是一个Ad-hoc Tester，因为他有自己的测试思路，他每天找到的Bug比他们小组其他所有Tester测试出来的Bug总和还要多，所以Test manager 根本就不管他，也不给他什么要求，就让他每天测好了。
           
        但是不幸的是，你可能不是这样的人，或者你身上存在着几种情况，就最好使用测试用例。

        1. 你工作不主动，你需要测试用例来催着你去工作；

        2. 你测试时总感觉思维很混乱，或者总感觉有些功能没有测到，而一些功能已经测过好几遍了，这样测试用例能够帮你理清头绪，进行比较系统的测试，不会有太多的重复，也不会让你的测试工作产生遗漏；

        3. 在测试时间紧迫的情况下，你不知道要测什么，或者要先测试那些功能，测试用例这个时候就可以帮你分清重点，因为测试用例写完后一定要标重要程度和优先级，以防止在紧急的情况下有重点的工作。

        4. 你积极的工作状态不能持续，这个时候测试用例又帮你一个大忙，因为测试用例上面操作步骤和预期结果都已经写好了，你根本不用思考，只需要照着上面做就行了。

        5. 测试用例是你工作的见证，也是你每次测试以后向上级汇报的依据，有了测试用例，我知道我这次测试了那些功能，还有那些功能没有测到，对上级是一个交代，也做到了自己心中有数。

        6. 测试用例可以记录你的灵感。如果灵感突发，有一个新颖的测试思路，你可以写成测试用例，或许这个测试用例就是挽救整个软件的重大功臣。

        7. 测试用例有助于不断的改进工作。因为通过测试用例，可以知道哪些测试用例测出Bug的机率比较大，还有那些测试用例需要改进，对我们以后工作的改进提供了依据。

        以上几条如果还不能推动你写测试用例的话，那么只有通过时间来证明了。我现在已经习惯在测试之前写测试用例了，如果测试之前没有测试用例的话，反而觉得不习惯。当然在不同的情况下（比如时间紧迫和有充足的时间的情况），测试用例的写法是不一样的。