VS 测试方法.docx

VS 测试方法.docx

《VS 测试方法.docx》由会员分享，可在线阅读，更多相关《VS 测试方法.docx（35页珍藏版）》请在冰豆网上搜索。

VS测试方法

一VS2010单元测试

在VS2010中，单元测试的功能很强大，使得建立单元测试和编写单元测试代码，以及管理和运行单元测试都变得简单起来，通过私有访问器可以对私有方法也能进行单元测试，并且支持数据驱动的单元测试。

1、建立单元测试项目

1.1、从被测试代码生成单元测试

1）实例：

创建VC#模式下的控制台应用程序，工程名为CUnitTest

2）输入简单的加、减、乘、除函数代码，如下图所示

3）可按如下步骤建立单元测试

（1）在Add方法体内，单击鼠标右键，在菜单中选择"创建单元测试"，

（2）在出现的"创建单元测试"界面中，Add方法被自动勾上，表示要为这个方法创建单元测试代码的基本框架，单击确定按钮

（3）点击确定后，在新建测试项目中，输入需要创建的单元测试的新项目的名称，然后单击"创建"按钮，则自动创建一个新的单元测试代码项目。

（4）在"解决档案资源管理器"中可以看到多了一个"AddTest"项目，可以看出"AddTest"项目引用了被测项目的程序集，和单元测试框架Microsoft.VisualStudio.QualityTools.UnitTestFrame，并且自动产生两个C#代码文件AssemblyInfo.cs和ProgramTest.cs

（5）ProgramTest.cs的代码如下图所示，从图中可以看到，自动产生了一个"ProgramTest"类，并使用[TestClass（）]标识为一个单元测试类，以及一个"AddTest"测试方法，。

并用[TestMethod（）]标识。

（6）ProgramTest.cs代码文件详讲

[TestMethod（）]：

说明了以下代码是一个测试用例

Inta=o;//TODO:

初始化为适当的值

intb=0;//TODO:

初始化为适当的值

这两句是被测函数的输入参数，需要我们去修改它的值,也就是我们输入测试用例的地方。

doubleexpected=0;//TODO:

初始化为适当的值

doubleactual;

      这两句话浅显易懂，前一句话是定义了期望值和对它进行初始化，后一句话是定义了实际值。

默认

Assert.AreEqual（expected,actual）;

Assert在这里可以理解成断言：

在VSTS里做单元测试是基于断言的测试。

默认代码中Assert.Inconclusive表明这是一个未经验证的单元测试。

在实际的程序中可以注释掉。

1.2、添加单元测试项目

（1）另外一种单元测试方法是独立添加单元测试项目，在解决方案中添加一个新的项目，选择项目类型为"测试项目"，

（2）单击确定后，自动产生一个新的单元测试项目，在"解决方案资源管理器"中可看到新添加的测试项目"TestProject2"。

对比"TestProject2"和"AddTest"可发现，"TestProject2"少了对被测试项目程序集的引用，仅仅引用了单元测试框架的DLL"Microsoft.VisualStudio.QualityTools.UnitTestFrame"

2、编写测试方法

单元测试的基本方法是调用被测代码的函数，输入函数的参数值，获取返回结果，然后与预期测试结果进行比较，如果相等则认为测试通过，否则认为测试不通过。

1、Assert类的使用

Assert.Inconclusive（）   表示一个未验证的测试；

Assert.AreEqual（）         测试指定的值是否相等，如果相等，则测试通过；

AreSame（）            用于验证指定的两个对象变量是指向相同的对象，否则认为是错误

AreNotSame（）        用于验证指定的两个对象变量是指向不同的对象，否则认为是错误

Assert.IsTrue（）             测试指定的条件是否为True，如果为True，则测试通过；

Assert.IsFalse（）            测试指定的条件是否为False，如果为False，则测试通过；

Assert.IsNull（）              测试指定的对象是否为空引用，如果为空，则测试通过；

Assert.IsNotNull（）         测试指定的对象是否为非空，如果不为空，则测试通过；

2、CollectionAssert类的使用

用于验证对象集合是否满足条件

StringAssert类的使用

用于比较字符串。

StringAssert.Contains

StringAssert.Matches

StringAssert.tartWith

3、数据驱动的单元测试

数据驱动的单元测试是指单元测试的输入数据遍历一个数据源的所有行。

从数据源的没一行读入数据并传入给测试方法使用

3.1、ACCESS数据驱动单元测试

1）打开测试视图窗口，选择测试视图

2）在测试视图窗口中选择需要配置成数据驱动方式的单元测试方法，然后按F4，打开单元测试的属性窗口

3）编辑"数据连接字符串"属性，在"属性"窗口中单击该属性，然后单击省略号（…）。

这将打开"选择数据源"对话框，其中列出了若干个可能的数据源，包括ODBC、MicrosoftSQLServer和MicrosoftAccess。

选择一个数据源后将打开一个特定于该数据源类型的对话框；可以使用此对话框配置该数据源的连接属性。

配置完数据连接后，连接字符串会作为"数据连接字符串"的值出现。

此字符串还会作为单元测试方法的一个属性存储起来

4）在这个界面中，选择一个Acess表data.mdb,单击"确定"按钮完成设置，回到"单元测试属性"窗口。

可以看到数据源的已经设置好。

5）在建立与数据源的连接之后，可以选择一个数据表。

当您单击"属性"窗口的值列中的下拉列表时，将会列出所连接的数据库中的表。

从此列表中选择的表就是在运行单元测试时将检索其中的行的表。

与"数据连接字符串"等其他属性一样，"数据表名称"也会作为单元测试方法的一个属性存储起来。

6）在"数据访问方法"，请选择"顺序"或"随机"；默认值为"顺序"。

此设置表示从数据源的表中检索记录的顺序。

    可以看到，在测试方法前面已经添加了一行：

7）数据源的使用

通过TestContext类的DataRow和DataConnection属性将数据提供给正在运行的单元测试。

下面为使用TestContext类的DataRow属性来读入数据行

8）Acess数据源中的表为

3.2、读取Excel的方法：

1）在桌面新建一个txt文件，更改文件名为data.dsn

2）选中"数据库连接字符串"，单击右边列的按钮，更改数据源为MicrosoftODBC数据源，点击"确定"按钮

3）选择使用连接字符串，点击生成

4）选择Excel数据源的驱动程序，点击"下一步"

5）选择data.dsn为数据源保存文件，一直选择"下一步"。

6）在弹出的选择工作簿中，选择用例的输入文件data.txt,点击"确定"

7）选择用例所在的Sheet页，选择"完成"

8）数据源的使用代码

4、单元测试的运行

单元测试的运行有两种方式：

调试和运行。

可以像调试普通代码一样对单元测试代码进行调试，当然也可以直接运行，单元测试的结果将在"测试结果"界面中展示，双击测试结果，可以得到测试结果的详细信息。

单元测试的代码覆盖率可以在"代码覆盖率结果"界面中展示。

5、附加测试属性

"附加测试属性"。

默认都是被注释掉的，只要我们取消注释就可以使用了。

这个功能的加入，很大程度上是为了增加测试的灵活性。

具体的属性有：

[ClassInitialize（）]在运行类的第一个测试前先运行代码

[ClassCleanup（）]在运行完类中的所有测试后再运行代码

[TestInitialize（）]在运行每个测试前先运行代码

[TestCleanup（）]在运行完每个测试后运行代码

如在执行测试时，将测试执行时间输入到日志中，代码如下

二VS2010测试解读-读懂那些文件们

VisualStudio是我喜爱的一个开发IDE，从VS2003开始，到VS2005，再到VS2008，再到最新的VS2010。

每一个版本的改进都是让人兴奋的，每一次使用新版本后，哪怕是Beta版，都不愿意再回到老版本。

最新发布的VS2010有很多创新的功能，对测试提供了大力的支持。

本文就一一解析这些新功能，让大家能够体会到VS2010的创新，具体的感受还要大家在使用过程中仔细感受。

VS2010是一个集成的开发环境（IDE），大部分的操作都能通过界面的操作完成，通常你不需要了解文件的细节。

但是读懂这些文件，能帮助你更好的理解整个测试框架，以便使用一些高级的测试功能和做一些自定义的扩展。

首先我们来看看一个典型的解决方案，通常放啊

在这个解决方案里面，我们有以下一些重要的文件和项目：

1）应用程序项目（被测试的应用，开发人员负责）

2）测试项目（测试人员负责）

3）*.testsettings文件；

在VS2010中，自动产生两个，一个是TraceAndTestImpact.testsettings用于调试的测试设置，另外一个本地缺省的测试设置。

VS2008只有本地缺省设置。

多说两句*.testsettings，这是运行测试的环境参数和运行参数，包括以下内容：

a）用例运行前后执行的脚本

b）是否启用数据分析（代码覆盖率，测试影响分析，模拟网络，录制视频，智能跟踪等等）很多功能都是VS2010独有的，

c）运行机器是本机还是远程机器

d）测试超时时间等

VS2010增强了测试监控功能，例如智能跟踪（IntelliTrace）和视频录制（VideoRecoder），测试影响分析（TestImpact）等等

4）*.vsmdi文件，用于管理测试用例的列表（TestList）.

*.vsmdi文件是管理TestList的，在VS2010中虽然支持，但是不推荐使用了。

主要原因是*.vsmdi非常不灵活，很难集中维护。

取而代之的是更加自然的测试分类（TestCategory）：

通过给每个测试用例设置标签，运行的时候通过标签选择需要运行的测试用例。

为了兼容问题，VS2010还是支持*.vsmdi。

下面是*.vsmdi的一些基本格式。

其内容基本上包括一个树状内容的TestList列表，各个节点通过ParentListID相连，其中包括一个特殊根节点。

另外，在每个TestList中，一个TestLink代表一个测试用例，TestLink的ID是通过测试方法名，测试类名和包名等，通过MD5计算而得（而非任意值），我以前就写过一个程序，自动生成*.vsmdi文件。

运行测试

写好测试用例就可以运行，CtrlF5,就这么简单，能够得到测试用例运行的结果。

很容易在IDE看到，测试结果，那么如何读懂后面的文件呢？

一次测试运行结果的目录：

我们一步一步来解释。

重要的文件有*.trx文件.

在多说两句，运行结果目录。

其中有In,Out和每个TestCase的详细结果。

VS2010测试功能学习（四）-TestImpactAnalysis（TIA）

TestImpactAnalysis是VisualStudio2010测试部分新增加的一个功能，我也不知道该如何翻译其中文名，那就简单点儿，按字面翻译为“测试影响分析”，以下简称为TIA。

那么啥是TIA呢？

简单地说，就是根据产品代码变化自动分析出受影响的测试用例，它既适用于自动测试用例，也是适用于手动测试用例。

注意：

目前TestImpactAnalysis只针对ManagedCode。

     那么这个功能有什么实用价值呢？

对于我所在的开发团队而言，其价值可老大了。

我们所开发的产品规模比较大、功能比较稀碎，并且是多人合作开发。

为了保证产品的质量，我们为产品编写了大量的自动化测试用例（>5000），同时还有少部分的手动测试用例（<200）。

为了保证每次产品代码Check-in的质量，在我们开发过程规范中明确指出：

每次checkin代码之前，必须执行所有相关的自动化测试用例，并全部通过之后才能checkin。

这样做的初衷是为了防止regression缺陷的发生，但问题是如何找到“相关的测试用例”呢？

如果运行所有的自动化测试用例，大概需要8+小时。

仅为了一小的修改就要去华8个小时执行测试用例，显然是不值得。

所以我们所采用的方法是将测试用例分类：

集成测试用例、功能测试用例和单元测试。

其中，集成测试用例数量最少（5~8%），覆盖了最最基本用户功能；单元测试覆盖数量较大（30%），但运行速度很快；功能测试用例覆盖绝大多数一般功能和一些边界条件，其数量大运行时间最长（60~65%）。

根据这三个分类，我们选择为每个checkin执行所有的集成测试和单元测试用例。

这样做的好处是：

覆盖了最基本的产品，同时运行时间不是很长。

     上述方案仅是一种折中的选择，其不足之处也是显而易见的：

所选择的测试用例固定不便、不准确，虽然保证了最基本产品功能不会被破坏，但往往不能发现checkin代码对其它功能影响。

但在过去，这也是无奈的选择。

TIA功能的出现就大大改善了这种情况，它可以帮助我们更精确的从所有测试用例中找出受到代码变化影响的测试用例。

      在VisualStudio2010中，启用TIA的方法非常简单，首先打开你的测试工程，然后选择Test–>EditTestSettings–>Local（local.testsettings），再在TestSettings对话框中选择DataandDiagnostics–>TestImpact，如下图所示：

     然后，需要重新编译编译整个测试工程，并执行所有的测试用例，以生成TIA所需要的基线数据。

通过Test–>Windows–>TestImpactView打开TestImpactView窗口，如下图所示。

在没有任何代码改变情况下，窗口中会显示"Notestsareimpacted“。

     但是，当你改变了任何产品代码、保存并编译，然后刷新一下TestImpactView窗口，它就会列出来所有受影响的测试用例，选择任何一个测试用例，它还会显示是那些方法被改变影响了这个测试用例，如下图所示。

我改变了产品代码中的ExchangeCurrency方法的代码，那么覆盖这段代码的测试用例就被挑选出来。

     其实，TIA并不是啥特神奇的功能，它实际上是利用了代码覆盖（codecoverage）找出了每个测试用例所覆盖到的所有方法调用，生成基线数据，将这些数据保存在工程路径下的testimpactdata.sdf文件中，据此来计算每次代码修改的影响。

.sdf是SQLServerCompact数据库文件，可以在ServerExploer中代开，如下图所示，它一共包含了4张表，有了这些数据我们也可以用它来扩展自己的功能。

     上述所展示的TestImpactAnalysis功能，仅是VisualStudio客户端的功能，其实在TFS服务器端也提供了TIA。

具体使用方法，将在以后的博客中介绍。

遗憾之处:

在使用了一段时间之后，我发现TIA还是有一个让我感觉非常遗憾的地方，那就是不支持自动执行所选测试用例。

例如：

当我准备一个shelve-set在正式Checkin之前，我会将它提交给TFS的Build系统来编译并执行所有的测试用例。

在这个过程中，TFS端的TIA可以帮助分析出出受代码变化影响（affected）的测试用例，但却无法让Build系统只执行这些受影响的测试用例。

     下面的链接是MSDN上，关于TIA的介绍，供大家进一步参考吧，今天就到这里了，呵呵!

本文来自CSDN博客，转载请标明出处：

VS2010测试功能学习（五）-GatedCheck-in（TFS）

严格意义上讲，GatedCheck-in（门控式签入，呵呵，这是我自己的翻译，英文名很好理解，但翻译起来真难啊！

最近发现了GatedCheck-in的官方翻译因该是-封闭签入，感觉挺别扭的没俺翻译的好，呵呵！

）不应该算是测试的一部分，它是TeamFoundationServer（以下简称为TFS）提供的一种代码checkin（签入，这是最常见到的对checkin的翻译，在本文中还是直接使用其英文，因为这是在平常开发中最常使用的称呼）的方式，即在代码checkin之前，先将提交的代码更改与现有代码进行merge，然后对merge后的代码进行Build，如果Build成功则checkin，否则就会报错并且不checkin所提交的代码。

     表面上看是与测试没有关系，但实际上它和测试以及产品质量的关系还是蛮大的。

因为毕竟代码checkin是整个开发过程中发生最为频繁的操作，每次check-in代码的质量直接影响着日常的开发活动。

对于绝大多数的开发团队来说，checkin代码前不仅要保证编译通过，同时还要最大限度的保证新代码不会破坏已有的功能，也就是要执行测试用例去验证。

GatedCheck-in中提到的“Build成功”，实际上包含两部分内容：

编译成功和测试用例执行成功。

     启用GatedCheck-in功能的方法是很简单的，只需要在BuildDefintion的Trigger标签页中选择“GatedCheck-in”，例如：

我定义了自己的一个Build叫做“DogfoodBuild”，它的定义如下图所示：

     在设置了"GatedCheck-in"选项后，如果你要进行任何对此BuildDefinition定义的Workspace包含的代码进行Checkin操作（从VSIDE或者在Cmd窗口中使用tfcheckin命令），系统都会弹出下面的对话框，它提示用户当前进行的操作属于GatedCheck-in，需要的对所提交的代码更改进行Build验证（validation），只有验证通过才能将代码更改checkin，否则将被退回。

     选择“BuildChanges”按钮，Build验证请求将被提交到TFS服务器端进行验证，验证的内容包括：

编译代码和执行自动化测试用例。

如果验证成功，则会弹出下面的对话框，提示用户验证成功并且已将代码checkin到Sourcecontrol。

其中：

ViewChangeset：

通过这个链接可以查看到checkin的代码changeset的详细信息；

ReconcileWorkspace：

由于checkin是发生在服务器端，你本地的代码变化还没有被同步，通过这个链接来帮助你解决本地代码与刚刚checkin最新代码的同步；

DogfoodBuild：

DogfoodBuild是我所创建和使用的BuildDefinition，通过这个链接可以查看到本次Build和Check-in操作的详细信息；

特别提醒：

默认创建的BuildDefinition定义中只验证了提交代码改变（shelve-set）的是否能够成功编译，并没有执行自动化测试用例。

如果要允许自动化测试用例，则需要在BuildDefinition中将"FailBuildOnTestFailure"设置为True，如下图所示。

这样测试用例运行的结果，将决定Build的结果。

Postscript

无意中发现有人为VisualStudio2008实现了一个类似的于GatedCheck-in的工具- TFSCheck-inValidationTool（

本文来自CSDN博客，转载请标明出处：

VS2010测试功能学习（六）-RollingBuild（TFS） 

如同我在《VS2010测试功能学习（五）-GatedCheck-in》一文中所介绍的GatedCheck-in功能一样，RollingBuild其实也是TeamFoundationServer（以下简称为TFS）提供的对check-in代码进行编译和验证的方式，虽然并不和测试直接相关，但它却是保证产品质量和团队协同工作的重要功能。

     RollingBuild，我把它翻译为“滚动生成”，即当TFS检测到在它所监控的范围内有任何新的代码变化被checkin的时候，它就启动对最新的代码库（codebase）进行Build验证。

之所以称之为“滚动”，因为它是在一个Build验证操作完成后再去探测有没有新的checkin发生，对Build验证期间发生的checkin，会被积累到下一个Build验证。

     配置RollingBuild的步骤很简单，只要在BuildDefinition的Trigger标签页中选择“Rollingbuilds”即可，如下图所示。

"Buildnomoreoftenthanevery minutes.”选择用来控制Rollingbuilds的频率。

     这里需要再强调一下RollingBuild的重要意义。

RollingBuild看似只是一个自动生成代码的功能，但实际上它起着协调整个开发团队、时刻监控代码库质量、以及尽早暴露产品问题的作用。

因为RollingBuild时刻都在不停的运转着，对于任何代码checkin它都保持着警觉，会去自动验证编译是否成功，自动化测试用例是否都能通过。

它就像一个不知疲倦的“代码守护者”一样监控着代码库，第一时间发现其中的任何问题，将问题通知给整个团队，从而避免了问题的积累和拖延。

这非常符合敏捷开发中“今日问题今日解决，不要拖到以后”的原则，它帮你最早的发现问题、报告问题，开发团队则应该建立制度要及时响应RollingBuild所报告的问题，把它作为Priority=0/1的问题去对待和解决。

     那么TFS的如何告知Build的结果呢？

TFS2010提供了以下几种途径来通知Build的状态：

方法一：

邮件方式。

在ProjectAlerts对话框中（TeamExplorer中右键选择指定的工程）可以配置需要相应Build事件的email地址，如下图所示，为工程Dev10Dogfood配置了当有任何Build完成后，发送通知邮件到整个团队的邮件组。

但这个方法我还没有实验成功，可能是因为邮件系统的配置问题，:

（

方法二：

VS2010中提供了一个TeamFou