摘 要：本文将介绍VSTS强大的单元测试创建功能和具体实例，结合黑盒测试与白盒测试的测试用例设计方法，有效完成单元测试，在软件研发前期就发现缺陷，从而有力保证软件质量的具体操作方法。
关键词：VSTS；单元测试；缺陷；软件质量
一、 引言
在开始本文之前，我们有必要先探讨几个问题：为什么需要做单元测试？单元测试应该让谁来完成？做单元测试的工具有哪些？
笔者就自己对于单元测试的认识，简单做如下回答：
我们熟知的“软件测试的10大原则”中第一条就是“测试是一个持续进行的过程，而不是一个阶段”，就是说软件测试需要尽早的参与研发投入，V&V模型就很好的为我们描述了这个观点。根据缺陷放大理论，在白盒测试阶段发现BUG是投入成本最低也是最高效的。
51testing的论坛上有一个贴，讨论过这个问题，笔者发现大多数的公司根本不进行白盒测试，或者进行白盒测试的也是开发人员完成的。更为奇怪的是，我在几年前参加的程序员考试竟然也认为应该把单元测试的任务移交给开发人员。
笔者认为，测试人员之所以选择测试，就是因为我们比开发人员更加具有对于缺陷的敏感性，并且对缺陷的认识程度远高于开发人员；另外，开发人员对于自己开发的程序具有很显著的思维定势，单元测试的职责理所应当让测试人员来完成。
单元测试的工具主流的是XUnit，还有C++Test、Insure++、CompuwareDevParterner、Purify、PC-Lint、LogiScope、TestBed等也是很强大的单元测试工具，另外基于Java也有自己的工具：Agitator。此外，笔者曾用高级语言调用TCL编译器，在TCL脚本语言环境创建单元测试用例也是个不错的选择。
二、 VSTS单元测试简介
Team版的VS2005里面包含了完整的Test功能，具体有：Unit Test，WebTest和LoadTest。这一整套的测试基本涵盖了软件开发会使用到的测试功能。
今天要介绍的是VSTS自带的单元测试工具（Unit Test），它最大的好处就是与开发的代码无缝连接，并且能自动创建单元测试环境，能够让不懂编程的测试人员也轻松进行单元测试。
三、 测试实战
下面我们就通过一个实例来具体体验VSTS单元测试。
在测试过程中，将按照如下顺序进行：
被测系统简介->被测试函数分析->测试用例的编写（黑盒/白盒测试方法）->进行单元测试
1. 被测系统简介
被测系统是“快速价格查询系统”，通过选定座位号的两个值，系统自动算出价格（界面如下图）。“座位号”下拉框的可选范围分别为“A”～“F”和“0”～“9”
如上图所示，“应付价格”＝“价格基数”ד座位号权值”
2. 被测试函数分析
我们需要测试的就是权值计算的函数，开发人员在函数申明中是这样描述的：
//权值计算
/// <summary>
/// 如果X是A、F，则靠窗，纵向权值＝1.8
/// 如果X是B、E，则靠中间，纵向权值＝1.2
/// 如果X是C、D，则靠走廊，纵向权值＝0.9
/// 如果Y是0~2，则靠头部，横向权值＝1.6
/// 如果Y是7~9，则靠尾部，横向权值＝0.7
/// 如果Y是3~6，则靠中间，横向权值＝1.1
/// 权值＝纵向权值*横向权值
/// </summary>
/// <param name="x">纵列值</param>
/// <param name="y">横列值</param>
static double position(char x, int y)
{
……
}
3. 测试用例的编写（黑盒测试方法）
也许有人会产生疑问：单元测试怎么可以用黑盒测试方法设计测试用例呢？黑盒测试不是做系统测试的吗？
其实我觉得测试方法都是一家，我们在设计用例的时候要秉承一个原则，那就是：测试是无穷尽的，我们要以尽量少（20％）的测试用例发现尽量多（80％）的缺陷。在设计用例的时候大可以集成天下，只要是为高效发现缺陷的用例设计思路都可以采纳，不必拘泥于特定的条条框框。我们只要把函数具体的实现方式抽象成一个黑盒，即可用黑盒设计思路。
根据开发人员提供的描述，我脑海中即刻浮现出一幅图：
限于篇幅有限，且重点不在于用例设计上，笔者在这里象征性的用划分等价类的方法设计了5个测试用例：
4. 测试用例的编写（白盒测试方法）
白盒测试用例设计方法少不了函数流程图：
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。
