阿超：说到测试，大家肯定有不少了解，也保不准有一些误解，我们这个讨论就是要去伪存真，把大家的理解统一到一个水平上。大家知道的“测试方法”有多少？

杂曰：
           Black box Test, White box Test
           Code Coverage, Test Unit Test
           Functional Test, Structural Test
           System Test, Performance Test
           Stress Test, Load Test
           Acceptance Test, Regression Test
           Ad hoc Test, Integration Test
           Alpha/beta Test, Localization/Globalization Test
           Security Test, Accessibility Test, Scenario Test,
           Usability Test,Smoke Test

二柱：这么多！把我都忽悠得有点晕了。看来我国软件测试人才真是大有用武之地了。
小飞：这么多名词，是得学几年的，写程序的方法怎么没有这么多花头？

阿超：咱们还是一个一个来吧。 这么多名词只不过是从各个方面描述了软件测试，并不是说有这么多独立的测试方法，我们把它们分类处理就不难了。

1.1     从测试设计的方法分类
从测试设计的方法来看，我们知道有两类方法：
Black box (黑箱)
White box (白箱)
这是每个接触过软件测试的人都会给出的答案。但是这只是整个软件测试的入门。我们可以跳过去，直接讨论下面的内容。。。

问：我在网上看到有人争论黑箱测试和白箱测试哪一个是另一个的基础，还有那一个更难，那一个更有前途，等等。据说李村数码在搞“灰箱测试”，是不是更高级？能不能简单讲一讲？
阿超：大家都有这些问题么？
杂曰：[略去对此问题热烈的争论500 字]
阿超：听了大家的争论，看来我们的确得花不少时间统一认识.

第一个要注意的问题是，所谓黑箱/白箱，是软件测试设计的方法，不是软件测试的方法！注意“设计”二字。

黑箱：在设计测试的过程中，把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是“Behavioral Test Design”, 从软件的行为，而不是内部结构出发来设计测试。
白箱：在设计测试的过程中，设计者可以“看到”软件系统的的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择。“白箱”并不是一个精确的说法，因为把箱子涂成白色，同样也看不见箱子里的东西。有人建议用“玻璃箱”来表示。

在实际工作中，我们不应画地为牢，严格只用某一种方法来设计测试方法。在实际的测试中，当然是对系统了解的越多越好。所谓“灰箱”的提法，正是这一反映。有些人甚至希望我们全部忘记“箱子”和它们的颜色。

我们并不是要禁止懂得内部构造的人员来进行黑箱测试设计，只不过我们在设计时有意不考虑软件的内部结构。例如：在测试程序内部基本模块的时候（单元测试），我们通常是要求对程序结构非常了解的程序员来设计，这是因为内部模块的“行为”和程序的外部功能并没有直接的关系，而且内部基本模块的“行为”通常没有明确的定义。另一个例子是“可用性测试”，在设计此类测试的时候，我们没必要纠缠于程序的内部结构，而是着重于软件的界面和行为。但是软件可用性测试也需要很多专业知识。这也从一个侧面表明“黑箱”和 “白箱”没有简单的高低之分。

一旦测试用例写出来之后，我们大可以忘了它们是从那种颜色的箱子里出来的，用它就可以了。
1.2     功能测试
以下的测试术语都是主要测试软件的功能。在下表所列的测试中，测试的范围有小到大，测试者也由内到外 – 从程序开发人员（单元测试）到 测试人员，到一般用户（Alpha/Beta 测试）。

1.4     Unit Test单元测试
二柱：我们也试过用单元测试来保证质量，要求每人都要写，在签入代码前必须通过单元测试。但是搞了几个星期就不了了之。

大家七嘴八舌的列举了单元测试的问题：
-       有时单元测试报了错，再运行一次就好了，后来大家就不想花时间改错，多运行几次，有一次通过就行了。
-       单元测试中好多错都和环境有关，在别人的机器都运行不成功。
-       花在单元测试上的时间要比写代码的时间还多
-       单元测试中我们还要测试效能和压力，花了很多时间
-       我们都这么费劲地测了，那还要测试人员干什么？
1.4.1    用VSTS写 单元测试
单元测试的基本构成
           Setup  //设置好环境，准备测试
           Test    // 测试
           Teardown  //打扫战场
例子：我们要写一个银行账户的类，那么它的单元测试应该怎么写？
谁自告奋勇上来表演一下写代码？小飞，好请上台。

小飞写了下面的代码：
定义interface IAccount

实现public class Account : IAccount
{
}

每个函数都使用临时代码

好，现在右键按住Account，就可以看到“Create Unit Tests”的菜单，选中之后，会出来新建Unit Tests的对话框：
每个函数都可以选中是否产生 单元测试。

//解释单元测试的结构

//一个缺省的单元测试

//修改过的单元测试

//运行单元测试

//单元测试的结果

//代码覆盖率
1.4.2    好的单元测试的标准
单元测试应该准确，快速地保证程序基本模块的正确性。下面是验证单元测试好坏的一系列标准：
1.4.2.1    单元测试应该在最低的功能/参数上验证程序的正确性
单元测试应该测试程序中最基本的单元 – 如在C++/C#/Java中的类，在此基础上，可以测试一些系统中最基本的功能点（这些功能点由几个基本类组成），从面向对象的设计原理出发，系统中最基本的功能点也应该由一个类及其方法来表现。单元测试要测试API中的每一个方法，及其每一个参数。
1.4.2.2    单元测试必须由最熟悉代码的人（程序的作者）来写
代码的作者最了解代码的目的，特点，和实现的局限性。所以，没有比作者适合的人选。
问：如果我很忙，能不能让别人代劳单元测试？
答：如果忙到连单元测试都没有时间做，那么你也没有时间写好这个功能。在一些极限编程的方法中，是可以考虑让别人来做单元测试，但是，程序的作者还是要对单元测试负责。

原文转自：http://www.ltesting.net