空间管理您的位置: 51Testing软件测试网 » 子木清风 » 日志

不要追求绝对的公平，红尘之中没有公平而言，人活一世，难得糊涂。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　it is no use doing what you like, you have got to like what you do.

Visual Studio 2005 进行单元测试

上一篇 / 下一篇 2006-12-11 17:34:48 / 天气: 晴朗 / 心情: 高兴 / 精华(3) / 置顶(3) / 个人分类：软件测试技术

查看( 1448 ) / 评论( 5 ) / 评分( 0 / 0 )

每日随笔

每日随笔:今天开始学习如何使用VS进行单元测试，Fighting！！！！！！！！

简介

随着业务的革新和发展，运行它们的系统也需要进行更新。随业务的发展、革新以及与合作伙伴、客户和供应商的结合，这些系统将在复杂性方面持续扩增。

这种复杂性迫使 IT 的领导者们在开发过程中（即，在实现之前）确保质量。有一种方法可使开发人员减少进入 QA 环节的故障数量，即，针对自定义代码严格执行自动化单元测试。在开发过程中强制使用自动化单元测试可为团队成员提供有关如何使用自定义代码的示例（这些示例易于使用并自行记录）。

使用结构化、自动化单元测试面临的挑战之一是完成这些任务所需的代码总数。（测试代码需要使用大量代码！）代码生成的概念（简单定义为“创建软件的软件”）正随着时间的快速推移而逐渐深入到团队 IT 开发之中。有些人认为代码生成有助于缩短“推向市场”策略的时间，强制内部标准/协定，并促进开发过程。

Microsoft 认识到这一需要后提供了一个功能丰富、带有下一代开发平台 Visual Studio 2005 Team System (VSTS) 的代码生成引擎。本文提供针对单元测试代码生成的循序渐进的指导，并深入探讨如何在用例中使用。

重新思考单元测试

请考虑以下情况：您负责为公司生成下一代系统，同时您是较大的开发团队中的一员。您是 UI 开发人员，负责尽可能多地创建 Microsoft ASP.NET/Microsoft WinForms。您依赖“中间层”团队完成其中间层组件 — 这些组件用于执行数据库 CRUD (Create-Retrieve-Update-Delete) 以及与该系统中每个实体相关的业务规则。

经过几周的 UI 开发，您完成了窗体并且收到了中间层开发人员打算向您提交其类库的消息。下面提供一段对话示例，说明我们大多数人在开发过程中都会遇到的一些事情。
UI 开发人员和中间层开发人员间的示例对话

中间层：


“这些对象随时供您使用 — 为此，只需获取 OurSystemBL.dll 的最新版本。”

UI：


“谢谢。您有供我们查看文档吗？”

中间层：


“哈哈！是的，当然有！我们花了很多时间编写它！请查看 Design Document — 噢，请等一等，它还没有完成……（不久之后即可完成！）”

UI：


“您使用 XML 文档了吗？”

中间层：


“在构造函数中，但许多方法都不使用。”

UI：


“显示如何创建、执行并删除对象的示例代码，怎么样？”

中间层：


“我已经附加了一个示例 WinForms 应用程序（从我的工作区），它应该能够提供一些您所需的内容……，虽然它不在 Microsoft Visual SourceSafe 中。”

在考虑如何进行这样有趣的项目之后，您打定了主意，决定检验中间层的单元测试套件。在深入钻研该代码之后，您注意到该窗体有两个未标记的文本框，以及三个标记为 button1、button2 和 button3 的按钮（幸运的话，它们将排列在窗体上）。接下来，在查看与这些按钮相关的事件之后，您认识到这些代码都未经注释，并且数据变量都被命名为 x、y、z。如果幸运，您还会注意到 button1 和 button2 执行该对象的 Save() 方法，而 button3 执行 Delete() 方法。执行时，您会接收到很多 System.Exception 错误，这是因为遗漏了很多配置设置。

这显然是一个特例，我希望多数开发团队不要进行这一试验，下面让我们看一下该方案中“单元测试”遇到的问题：
•

这种形式的单元测试代码不是结构化的：代码充斥到按钮单击事件中并且难以编译。
•

这种形式的单元测试代码记录得不太好。
•

这种形式的单元测试并不基于“已知”为好或坏的数据 — 它完全依赖于输入到那些未标记的文本框的内容。
•

单元测试代码不能自动重复，它基于输入的代码。
•

单元测试代码覆盖是未知的 — 用数据指示实际测试的代码量。
•

实现的详细信息不易于在团队成员间进行传播。

输入自动化单元测试

xUnit 框架在 1998 年作为 eXtreme 编程的核心概念引入。它提出了一个有效的机制，有助于开发人员将结构化、有效且自动的单元测试添加常规开发活动中。从那以后，该框架演化为针对自动化单元测试框架的实际标准。
创建自动化单元测试的用例

简单说，自动化单元测试是：
•

结构化的。
•

自行记录的。
•

自动且可重复的。
•

基于已知数据。
•

旨在测试积极和消极操作。
•

非常适合跨不同计算机的测试实现。
•

配置、实现和执行的示例。
xUnit 框架元素

表 2 分析 xUnit 框架以及对应于 Visual Studio 2005 Team System 的 Unit Testing Framework 等价物的基本概念。
表 2. 相应的 xUnit 框架和 VSTS Unit Testing Framework 概念
xUnit 框架概念     VS 2005 等价物（参见下面的属性）     描述

测试


TestMethod


简单说，这些是您的测试。测试预期结果的逻辑，并报告未取得结果（如果有）。请将它看作您的“方法”。

测试装置


TestClass


针对大量测试的一个逻辑分组。请将它看作您的“类”。

测试套件


测试列表 **


针对大量测试装置的一个逻辑分组。请将它看作您的“类库”。

注不需要一个属性。

测试运行器


VS 2005 VSTS Unit Testing Framework


GUI/Console 应用程序负责发现、执行和报告测试结果。Visual Studio 2005 Team System 将作为本文的测试运行器。
测试装置示例

请考虑以下针对 BankAccount 类的类关系图，以及一个示例测试装置 (BankAccountTests.cs)。

图 1. BankAccount 类
示例测试装置： BankAccountTests.cs

using BankAccountDemo.Business;
using Microsoft.VisualStudio.QualityTools.UnitTesting.Framework;
namespace BankAccountDemo.Business.Tests
{
    [TestClass()]
    public class BankAccountTest
    {
        [TestInitialize()]
        public void Initialize()    {
        }
        [TestCleanup()]
        public void Cleanup()   {
        }
        [TestMethod()]
        public void ConstructorTest()   {
            float currentBalance = 500;
            BankAccount target = new BankAccount(currentBalance);
            Assert.AreEqual(currentBalance, target.CurrentBalance,
                "Balances are not equal upon creation");
        }
        [TestMethod()]
        public void DepositMoneyTest() {
            float currentBalance = 500;
            BankAccount target = new BankAccount(currentBalance);
            float depositAmount = 10;
            target.DepositMoney(depositAmount);
            Assert.IsTrue( (currentBalance + depositAmount) >
                            target.CurrentBalance,
               "Deposit not applied correctly");
        }
        [TestMethod()]
        public void MakePaymentTest()   {
            float currentBalance = 500;
            BankAccount target = new BankAccount(currentBalance);
            float paymentAmount = 250;
            target.MakePayment(paymentAmount);
            Assert.IsTrue(currentBalance - paymentAmount ==
              target.CurrentBalance,
                "Payment not applied correctly");
        }
    }
}

主单元测试概念 == 断言

用于该形式单元测试的主要概念是，自动化单元测试是基于“断言”的，即可定义为“事实或您相信为事实的内容”。从逻辑角度看，请考虑该语句“when I do {x}, I expect {y} as a result”。

这可以轻松地翻译为代码，方法是使用 Microsoft.VisualStudio.QualityTools.UnitTesting.Framework 命名空间中可用的三个“断言”类中的任一个：Assert、StringAssert 和 CollectionAssert。主类 Assert 提供用于测试基础条件语句的断言。StringAssert 类自定义了在使用字符串变量时有用的断言。同样，CollectionAssert 类包括在使用对象集合时有用的断言方法。

表 3 显示可用于当前版本 Unit Testing Framework 的断言。
表 3. VSTS Unit Testing Framework 断言
断言类     StringAssert 类     CollectionAssert 类

AreEqual()
AreNotEqual()
AreNotSame()
AreSame()
EqualsTests()
Fail()
GetHashCodeTests()
Inconclusive()
IsFalse()
IsInstanceOfType()
IsNotInstanceOfType()
IsNotNull()
IsNull()
IsTrue()



Contains()
DoesNotMatch()
EndsWith()
Matches()
StartsWith()



AllItemsAreInstancesOfType()
AllItemsAreNotNull()
AllItemsAreUnique()
AreEqual()
AreEquivalent()
AreNotEqual()
AreNotEquivalent()
Contains()
DoesNotContain()
IsNotSubsetOf()
IsSubsetOf()

这些自动化单元测试用什么运行？

正如前面提到的，xUnit 框架将“测试运行器”的概念定义为应用程序负责：(a) 执行单元测试；(b) 报告测试结果。对于本文，包含 Visual Studio 2005 Team System (VSTS) 的 Unit Testing 引擎作为我们的“测试运行器”。图 2 表示 BankAccountTests.cs 类的执行结果。

图 2. 测试结果窗格：单元测试执行结果

Microsoft Visual Studio 2005 使用源项目的代码模型动态填充该视图。它基于该源代码中的自定义属性动态发现有关该测试套件的信息。表 4 表示最常见的单元测试属性（以及执行的次序）。
表 4. 常见单元测试属性
属性     描述

TestClass()


该属性表示一个测试装置。

TestMethod()


该属性表示一个测试用例。

AssemblyInitialize()


在执行为执行选择的第一个 TestClass() 中的第一个 TestMethod() 之前，执行带有该属性的方法。

ClassInitialize()


带有该属性的方法在执行第一个测试之前调用。

TestInitialize()


带有该属性的方法在执行每个 TestMethod() 之前调用。

TestCleanup()


带有该属性的方法在执行每个 TestMethod() 之后调用。

ClassCleanup()


带有该属性的方法在执行 ALL 测试之后调用。

AssemblyCleanup()


在执行为执行选择的第一个 TestClass() 中的第一个 TestMethod() 之后，执行带有该属性的方法。

Descrīption()


提供关于给定 TestMethod() 的描述。

Ignore()


由于某种原因忽略 TestMethod() 或 TestClass()。

ExpectedException()


当测试特定异常时，如果使用该属性指定的异常不是从实现代码引发，则测试不会失败。
我编写什么类型的测试？

一个方法及其相关测试之间很难有一对一关系。编写自动化单元测试需要开发人员“进行全面思考”，并了解关于对象的所有内容 — 它将如何消耗、使用、处理，以及在任何情况下如何起到积极、消极、非决定性作用。

例如，请考虑一个用于针对数据库中 Customer 项执行 CRUD（创建、检索、更新、删除）功能的典型对象方法。对于该对象的 Load() 方法，要针对以下方案编写测试：
•

构造函数测试 — 确保对象正确加载，带有正确的信息。
•

PositiveLoadScalarTest — 测试数据库中一个 Customer 的成功加载。
•

NegativeLoadScalarTest — 测试一个 Customer 的失败加载，即该 Customer 不在数据库中。
•

PositiveLoadTest — 基于已知数据测试 Customer 的成功加载。
•

NegativeLoadTest — 测试数据库中不存在的 Customer 的失败加载。
•

NegativeValidationTest — 确保验证逻辑正确工作。

这些只是自动化单元测试套件许多用法中的一部分。我曾经听说一个小团队使用单元测试查看针对其组件的已知安全攻击。从宏观的角度来看，单元测试应该明确保证组件的正常使用。具有丰富的测试集将使团队确信您已经准确实现了既定的目标：编写有效的软件。无论自信源自哪里 — 这就是您需要编写的测试。
您测试什么？

从本质上看，这些自动化单元测试非常低级。它们旨在测试下至构造函数、方法调用的对象，甚至是对象上的属性。

关于“公共对私有”的主题在单元测试派系中引发了许多争论。许多人认为单元测试只应该测试对象的公共接口。其他人认为应该测试每个调用 — 包括内部私有方法。VSTS 支持两个单元测试级别。VSTS 通过使用私有访问器或包装类支持私有测试，后者提供基于“私有”方法和属性生成单元测试的功能。

为什么生成代码？

阅读上面的列表后，您可能会想起前面项目的单个对象，并思考：“如果我用“这些”对象进行该操作，就需要编写大量代码！”请考虑开发人员仍编写“单元测试”代码的事实 — 只在不同的窗体（例如，前面提到的 WinForms 示例）上进行。此外，具有可自行记录、可重用的实现示例带来的好处远大于生成更多代码所带来的麻烦。最后，在单元测试中设计更多的环节已证明可以减少质量保证环节中的故障。

正如前面所提到的，代码生成是“软件创建软件”的过程。基于可重复的过程创建代码是理想的。例如，一些使用代码生成的较好示例包括：脚本数据、创建表示实体及其在储存库（数据库 CRUD）中存在的对象，或者创建适用于数据维护的 UI 控件。使用代码生成的好处包括：
•

节省时间 — 为什么花几小时/天/周创建一些在几秒/分钟内就可以创建的内容？
•

强制标准/约定— 对于强制您的标准和命名约定而言，没有什么比消除开发中的人员因素并依赖基于“您的”规则的可重复过程更好的了。
•

测试私有方法的功能 — 正如本文前面提到的，Unit Testing Framework 提供使用“私有访问器”类测试私有方法的功能。该代码生成引擎创建与这些访问器类相关的所有“基础代码”。
•

获取现有组件的信息 — 搜索另一个开发人员的组件吗？基于这些组件生成代码可能提供关于该实现以及该对象接口的简明示例。此外，进行设计并在编码之前“清除”其对象的公共接口（例如，通过使用 VS 2005 类设计器）的开发人员将极大地受益于代码生成引擎。

正如您所预期的，自动化单元测试属于“优秀代码生成候选者”。在现有组件中指出一些内容并针对这些自动单元测试生成初始代码难道不是很理想吗？而且不只是保留单元测试框架，还会围绕对象的公共接口生成实现示例吗？将来的 Visual Studio 2005 Team System 用户将拥有该功能以及更多功能！

让我们生成一些代码吧！

本例中，我们将生成本文前面提到的 BankAccount 类的代码。本文的这一部分旨在为您介绍代码生成过程，并重点介绍所提供的功能以及从 VSTS 使用 Unit Testing 引擎的好处。
第 1 步：创建您的实现代码

首先，我们创建一个将用作应用程序的业务层的类库项目。

要在 VS 2005 中创建该库：

1.


启动 Visual Studio 2005 Beta 2。

2.


单击 File | New | Project。

3.


选择您选定的语言 Windows，并选择 Class Library 项目模板。

4.


将 Name 和 Solution Name 设置为 BankAccountDemo.Business，选择一个位置，并单击 OK 来创建该类库。

VS 2005 创建该类后，下一个任务就是创建针对您的项目设计的 BankAccount 类。为此，需要执行以下操作：

1.


在解决方案资源管理器中单击右键，并单击 Delete，从项目中移除该文件并将其从硬盘中删除。

2.


右键单击 BankAccountDemo.Business 项目，然后单击 Add，之后单击 Class。

3.


选择文件名 BankAccount.cs，并单击 Add 创建类文件。

4.


针对 BankAccount.cs 文件对代码进行以下更改。

using System;
using System.Collections.Generic;
using System.Text;

namespace BankAccountDemo.Business
{
    public class BankAccount
    {
        // Properties
        private float _currentBalance;

        public float CurrentBalance
        {
            get { return _currentBalance; }
        }

        // Constructors
        public BankAccount(float initialBalance)
        {
            this._currentBalance = initialBalance;
        }

        // Methods
        public void DepositMoney(float depositAmount)
        {
            this._currentBalance += depositAmount;
        }

        public void MakePayment(float paymentAmount)
        {
            this._currentBalance -= paymentAmount;
        }
    }

}

收藏举报

TAG: 单元测试自动化测试软件测试技术 VS

引用删除 kbl5555 / 2010-01-04 09:58:40: 俺也正在学习。

引用删除 573702881 / 2008-05-06 21:00:59: 高手先生好！以上的MyStack程序的Bug就有劳你了哦！！呵呵！

引用删除 573702881 / 2008-05-06 20:56:59: 下面的程序有什么BUG?
namespace MyStack
{
public class MyStack
{
      private int nextIndex;
      private string[] elements（元素）;
      public static void Main(string[] args)
      {
      }
      public MyStack()
      {
         elements = new string[100];
         nextIndex = 0;
      }
      public void Push(string element)
      {
         elements[nextIndex++] = element;
      }
      public string Pop()
      {
         return elements[--nextIndex];
      }
      public void Delete(int n)
      {
         nextIndex = nextIndex - n;
      }
      public string Top()
      {
         return elements[nextIndex-1];
      }
      public int Size()
      {
         return this.nextIndex;
      }
}


}