软件工程实践图书管理系统

软件工程实践报告姓名：吕伟学号：08113441专业：计算机科学与技术班级：计算机科学与技术11-4班设计题目：软件工程实践成员：皇甫飞波（08113438）刘什（08113440）指导教师：赵莹2023年12月31日徐州课程设计指导教师评阅书指导教师评语：成绩：指导教师签字：年月日目录第一章图书管理系统总体规划-----------------------------------------------------------------------1第二章实验一：运用Visio绘制DFD图-----------------------------------------------------------11、顶层及零层数据流图（DFD）----------------------------------------------------------------12、分层数据流图（DFD）-------------------------------------------------------------------------2第三章实验二：UML工具的使用 -----------------------------------------------------------------41、用例图----------------------------------------------------------------------------------------------42、类图 -----------------------------------------------------------------------------------------------73、序列图----------------------------------------------------------------------------------------------74、状态图----------------------------------------------------------------------------------------------85、协作图----------------------------------------------------------------------------------------------96、活动图----------------------------------------------------------------------------------------------9第四章实验三：软件源代码管理---------------------------------------------------------------------101、SVN介绍 -----------------------------------------------------------------------------------------102、SVN软件使用说明 -----------------------------------------------------------------------------11第五章实验四：使用软件测试工具-----------------------------------------------------------------181、Nunit软件测试工具-----------------------------------------------------------------------------181.1TDD的简介----------------------------------------------------------------------------------191.2.NUnit的介绍---------------------------------------------------------------------------------191.2.1Nunit的介绍----------------------------------------------------------------------------191.2.2一些常用属性-------------------------------------------------------------------------221.3如何在.NET中应用NUnit-----------------------------------------------------------------241.4其他的一些核心概念-----------------------------------------------------------------------28TestSuite -----------------------------------------------------------------------------------32Explicit属性----------------------------------------------------------------------------------35ExpectedException属性-------------------------------------------------------------------351.5测试生命周期合约 -----------------------------------------------------------------------362、TestManager软件测试工具-------------------------------------------------------------------382.1TestManager介绍---------------------------------------------------------------------------382.2TestManager具体使用---------------------------------------------------------------------38第一章图书管理系统总体规划对于数据库系统，规划工作是十分必要的。规划的好坏将直接影响到整个图书管理系统的成功与否，数据库设计中的规划阶段的重要任务是建立数据库的必要性及可行性分析，拟定数据库系统在整个图书管理系统的地位。根据图书管理数据库对技术人员和管理人员的水平、数据采集和管理活动以及借阅者的计算机素质的规定；数据库技术对计算机系统的软硬件的规定。决定把数据库管理系统设计成为一个综合的数据库。此数据库涉及所有操作人员的所有活动功能。由于，此图书管理系统应用界面较简朴、功能单一。所以，用一个综合的数据库就能满足图书管理规定，并且实现容易。因此，图书管理系统可以按照用户权限和实现功能的不同分为两部分：外部学生对数据库的查阅访问和内部管理人员对图书记录的管理维护。但是，这两部分都调用的是同一数据库，只但是内部管理人员能实现所有管理功能，而外部学生访问数据库时，一些功能被屏蔽，只能进行查阅。书管理系统的整个应用情况作全面的、具体的调查，拟定图书管理的目的，收集支持系统总的设计目的的基础数据和对这些数据的规定，拟定用户的需求，并把这些写成用户和数据库设计者都可以接受的文档。第二章实验一运用Visio绘制DFD图实验规定： 1．可以采用结构化方法对所选系统进行需求分析； 2．采用Visio绘制系传统的DFD图； 3．提交绘制的图形和实验报告。图书管理系统顶层和第零层DFD图图书管理系统顶层DFD图图书管理系统第零层DFD图图书管理系统分层DFD图图书管理系统第1层DFD图图书管理系统第2层DFD图注：皇甫飞波负责实验一报告的整理和图书管理系统顶层和零层DFD图的绘制；吕伟负责图书管理系统第1层DFD图的绘制；刘什负责图书管理系统第2层DFD图的绘制。实验二UML工具的使用实验规定：1．下载、安装RationalRose、StarUML等工具软件，学习软件使用； 2．绘制用例图、类图、序列图、状态图、活动图等图形针对所选系统进行模型分析和设计。用例图在绘制图书管理系统的用例图之前我们要对其中的角色进行辨认，对一个图书管理系统来说，重要有两种角色：读者和图书管理员。另一方面，在重要角色的基础上，可以辨认出与角色相应的用例，从而画出用例图。与读者相关的过程涉及：借书、还书、图书信息检索、借阅信息查询、个人相关信息查询及修改（如：姓名、性别、年级、专业、家庭住址、联系电话、民族、身份证号、出生日期等），与图书管理员相关的过程的涉及：办理借书、办理还书、图书订购、读者信息管理、图书信息管理以及系统管理。以上分析中，与读者、图书管理员相关的过程构成了本系统的基本用例。图书管理系统基本用例图图书管理模块的用例图图书管理模块涉及与图书相关的一些过程，重要有图书借出、图书的归还、图书信息的检索、图书订购、图书相关信息的管理。读者管理模块的用例图读者管理模块重要涉及与读者有联系的相关的过程。重要有读者增长/删除、修改读者权限及密码、借阅信息查询、个人信息查询及修改、借阅超期/丢失罚款系统管理模块的用例图系统管理模块重要有系统的登录、退出，系统的更新、系统的维护类图序列图借书一般过程的序列图状态图图书管理员使用系统的状态图图书管理员的重要时间流可以有图书管理系统的状态图分析而来，与图书管理员相关的过程涉及：办理借书、办理还书、解除预定，图书预定、图书信息管理（增长/删除书目、图书类别管理、流通情况）、读者信息管理（增长/删除读者、读者权限修改等）协作图借书一般过程的协作图读者刷卡进入图书馆，先查询图书及个人借阅信息，然后去挑选书，挑好书后进入借车程序，图书管理员先检查读者的证件是否合理，如合理则进行借车，读者借完书后，图书管理员要修改读者的借阅信息和库存图书信息。活动图借书一般过程的活动图注：皇甫飞波负责基本用例图以及各模块用例图的绘制；吕伟负责类图和图书管理员使用系统的状态图的绘制；刘什负责借书一般过程的协作图、时序图以及活动图的绘制。实验三软件源代码管理实验规定：1．下载、安装SVN、Trac等工具软件，学习软件使用；2．对所选系统的源代码进行版本管理。1、SVN介绍subversion(简称svn)是近年来崛起的版本管理软件，是cvs的接班人。目前，绝大多数开源软件都使用svn作为代码版本管理软件。使用情况虽然在2023年时Subversion的使用族群仍然远少于传统的CVS，但已有许多开放原码团队决定将CVS转换为Subversion。已经转换使用Subversion的涉及了FreeBSD、ApacheSoftwareFoundation、KDE、GNOME、GCC、Python、Samba、Mono以及许多团队。许多开发团队换用Subversion是由于Trac、SourceForge、CollabNet、CodeBeamer等专案协同作业软件以及Eclipse、NetBeans等IDE提供Subversion的支援整合。除此之外，一些自由软件开发的协作网如SourceF除了提供CVS外，现在也提供专案开发者使用Subversion作为原码管理系统，JavaForge、GoogleCode以及BountySource则以Subversion作为官方的原码管理系统。2023年，绝大多数CVS服务已经改用SVN。CVS已经停止维护。2、SVN软件使用说明注：皇甫飞波负责SVN的下载和安装；吕伟负责图书管理系统源代码的整理和分析；刘什负责运用软件对系统源代码进行软件版本的管理。实验四使用软件测试工具实验规定：1．下载、安装Webstress、NUnit和TestManager等工具软件，学习软件使用； 2．运用NUnit工具软件进行白盒测试用例设计及自动测试； 3．运用Webstress工具软件进行性能自动测试； 4．了解TestManager测试管理工具的使用方法。1、Nunit软件测试工具

前一段时间,有人问我在.NET里如何进行TDD开发.这个问题促使我想对NUnit做一个具体的介绍.由于我们大家都知道NUnit是在.NET进行TDD的利器.

假如你已经知道很多关于NUnit的应用,请指出我的不对之处和提出一些建议，使本文更加完善.假如你对NUnit还不是很了解的话,我建议你还是阅读一下.本文分为以下部分:1.1TDD的简介一方面什么是TDD呢?KentBeck在他的<<测试驱动开发>>(Addison-WesleyProfessional,2023)一书中,使用下面2个原则来定义TDD:·除非你有一个失败的自动测试,永远不要写一单行代码.我想第一个原则是显而易见的.在没有失败的自动测试下就不要写代码.由于测试是嵌入在代码必须满足的需求中.假如没有需求,就没有必要实现任何东西.所以这个原则阻止我们去实现那些没有测试和在解决方案中不需要的功能.第二个原则说明了在一个程序中,不应当包含反复的代码.假如代码反复,我想这就是不好的软件设计的象征.随着时间的流逝,它会对程序导致不一致的问题,并且使代码变非常混乱,由于我们时常不会记得反复代码的位置.假如发现代码反复,我想我们应当立即删除代码反复.其实这就涉及到重构了.在这里我就不多讲了.一般来说,测试分为2种类型,一是程序员自己的测试,此外一种是客户的测试.关于客户测试，我推荐一个FIT的框架，非常不错。在这里，我们讲的TDD就是程序员测试.那么什么是程序员测试呢?我认为就是我们常说的单元测试.既然是单元测试,在.NET里势必会用到某些工具,目前最著名恐怕就是我即将介绍的NUnit了,1.2.NUnit的介绍NUnit是一个单元测试框架,专门针对于.NET来写的.其实在前面有JUnit(Java),CPPUnit(C++),他们都是xUnit的一员.最初,它是从JUnit而来.现在的版本是2.2.接下来我所用的都是基于这个版本.NUnit最初是由JamesW.Newkirk,AlexeiA.Vorontsov和PhilipA.Craig,后来开发团队逐渐庞大起来.在开发过程中,KentBeck和ErichGamma2位牛人也提供了许多帮助.看来对于NUnit还真是下了一番力气了.JNUnit是xUnit家族种的第4个主打产品,完全由C#语言来编写,并且编写时充足运用了许多.NET的特性,比如反射,客户属性等等.最重要的一点是它适合于所有.NET语言.1.2.1NUnit的介绍

Ok,下面正式讲解NUnit.在讲解之前,看看几张图片:

图1

NUnit运营的效果

图2

NUnit运营的此外一个效果

从中我们可以非常容易发现,右边是个状态条,图1是红色的,图2是绿色的.为什么会这样呢?由于假如所有测试案例运营成功,就为绿色,反之假如有一个不成功,则为红色,但也有黄色的.左面的工作域内则是我们写的每一个单元测试.通过上面的图片,我想你对NUnit有个总的了解了.接下来还是分为2个部分,一是NUnit的布局,此外一部分就是它的核心概念.一方面熟悉一下NUnitGUI的布局.让我们更进一步看一下测试运营器窗口的布局。在右边面板的中间，可以看到测试进度条。进度条的颜色反映了测试执行的状态：绿色描述目前所执行的测试都通过黄色意味某些测试忽略，但是这里没有失败红色表达有失败底部的状态条表达下面的状态：状态.说明了现在运营测试的状态。当所有测试完毕时，状态变为Completed.运营测试中，状态是Running:<test-name>(<test-name>是正在运营的测试名称)。TestCases说明加载的程序集中测试案例的总个数。这也是测试树里叶子节点的个数。TestsRun已经完毕的测试个数。Failures

到目前为止，所有测试中失败的个数.Time

显示运营测试时间（以秒计）File主菜单有以下内容：NewProject允许你创建一个新工程。工程是一个测试程序集的集合。这种机制让你组织多个测试程序集，并把他们作为一个组对待。Open加载一个新的测试程序集，或一个以前保存的NUnit工程文献。Close关闭现在加载的测试程序集或现在加载的NUnit工程。Save保存现在的Nunit工程到一个文献。假如正工作单个程序集，本菜单项允许你创建一个新的NUnit工程，并把它保存在文献里。SaveAs允许你将现有NUnit工程作为一个文献保存。Reload强制重载现有测试程序集或NUnit工程。NUnit-Gui自动监测现加载的测试程序集的变化。当程序集变化时，测试运营器重新加载测试程序集。（当测试正运营时，现在加载的测试程序集不会重新加载。在测试运营之间测试程序集仅可以重新加载。一个忠告：假如测试程序集依赖此外一个程序集，测试运营器不会观测任何依赖的程序集。对测试运营器来说，强制一个重载使所有依赖的程序集变化可见。RecentFiles

说明5个最近在NUnit中加载的测试程序集或NUnit工程（这个列表在Windows注册表，由每个用户维护，因此假如你共享你的PC，你仅看到你的测试）。最近程序集的数量可以使用Options菜单项修改，可以访问Tool主菜单。Exit退出。

View菜单有以下内容：Expand一层层扩展现在树中所选节点Collapse折叠现在树中选择的节点ExpandAll递归扩展树中所选节点后的所有节点CollapseAll递归折叠树中所选节点后的所有节点ExpandFixtures扩展树中所有代表测试fixture的节点。CollapseFixtures折叠树中所有代表测试fixture的节点。Properties显示树中现所选节点的属性。Tools菜单由这些项:SaveResultsasXML作为一XML文献保存运营测试的结果。Options让你定制NUnit的行为。现在看看右边，你已经熟悉Run按钮和进度条。这里尚有一个紧跟Run按钮的Stop按钮：点击这个按钮会终止执行正运营的测试。进度条下面是一个文本窗口，在它上方，由以下4个标签：ErrorsandFailures窗口显示失败的测试。在我们的例子里，这个窗口是空。TestsNotRun窗口显示没有得到执行的测试。Console.Error窗口显示运营测试产生的错误消息。这些此消息是应用程序代码使用Console.Error输出流可以输出的。Console.Out窗口显示运营测试打印到Console.Error输出流的文本消息。1.2.2一些常用属性

接下来,我将讲述这个框架如何使用.同时也涉及到一些非常重要的概念,我想其客户属性是非常重要的.在NUnit里,有以下几种属性:Test

FixtureTest下面我将对每种属性一一讲解.TestFixtureAttribute

本属性标记一个类包含测试,当然setup和teardown方法可有可无.(关于setup和teardown方法在后面介绍)

做为一个测试的类,这个类尚有一些限制必须是Public,否则NUnit看不到它的存在.它必须有一个缺省的构造函数,否则是NUnit不会构造它.构造函数应当没有任何副作用,由于NUnit在运营时经常会构造这个类多次,假如要是构造函数要什么副作用的话,那不是乱了.举个例子C#代码using

System;

using

NUnit.Framework;

namespace

MyTest.Tests

{

[TestFixture]

public

class

PriceFixture

{

//

}

}

TestAttribute

Test属性用来标记一个类(已经标记为TestFixture)的某个方法是可以测试的.为了和先前的版本向后兼容,头4个字符(“test”)忽略大小写.(参看)这个测试方法可以定义为:

C#代码public

void

MethodName()

从上面可以看出,这个方法没有任何参数,其实测试方法必须没有参数.假如我们定义方法不对的话,这个方法不会出现在测试方法列表中.也就是说在NUnit的界面左边的工作域内,看不到这个方法.尚有一点就是这个方法不返回任何参数,并且必须为Public.例如:C#代码using

System;

using

NUnit.Framework;

namespace

MyTest.Tests

{

[TestFixture]

public

class

SuccessTests

{

[Test]

public

void

Test1()

{

/**//*

*/

}

}

}

一般来说,有了上面两个属性,你可以做基本的事情了.此外，我们再对如何进行比较做一个描述。在NUnit中，用Assert（断言）进行比较，Assert是一个类，它涉及以下方法：AreEqual，AreSame，Equals，Fail，Ignore，IsFalse，IsNotNull，具体请参看NUnit的文档。1.3如何在.NET中应用NUnit我将举个例子,一步一步演示如何去使用NUnit.第1步.为测试代码创建一个VisualStudio工程。在MicrosoftVisualStudio.NET中，让我们开始创建一个新的工程。选择VisualC#工程作为工程类型，ClassLibrary作为模板。将工程命名为NUnitQuickStart.图4-1是一个描述本环节的VisualStudio.NET。

图4-1:创建第一个NUnit工程第2步.增长一个NUnit框架引用在MicrosoftVisualStudio.NET里创建这个例子时，你需要增长一个NUnit.framework.dll引用，如下：在SolutionExplorer右击引用，然后选择增长引用

NUnit.framework组件，在AddReference对话框中按Select和OK按钮。图4-2描述了这步:

图4-2:增长一个NUnit.framework.dll引用到工程第3步.为工程加一个类.为工程加一个NumbersFixture类。这里是这个例子的代码。C#代码using

System;

using

NUnit.Framework;

namespace

NUnitQuickStart

{

[TestFixture]

public

class

NumersFixture

{

[Test]

public

void

AddTwoNumbers()

{

int

a=1;

int

b=2;

int

sum=a+b;

Assert.AreEqual(sum,3);

}

}

}

第4步.建立你的VisualStudio工程，使用NUnit-Gui测试从程序->NUnit2.2打开NUnit-gui,加载本本工程编译的程序集.为了在VisualStudio.NET中自动运营NUnit-Gui，你需要建立NUnit-Gui作为你的启动程序：在SolutionExplorer里右击你的NunitQuickStart工程。在弹出菜单中选择属性。在显示的对话框的左面，点击ConfigurationProperties夹选择出现在ConfigurationProperties夹下的Debugging。在属性框右边的StartAction部分，选择下拉框的Program作为DebugMode值。按Apply按钮设立NUnit-gui.exe作为StartApplication。，你既可以键入nunit-gui.exe的全途径，也可使用浏览按钮来指向它。图4-3帮助描述本环节:

图4-3:将NUnit-Gui作为工程的测试运营器第5步.编译运营测试.

现在编译solution。成功编译后，开始应用程序。NUnit-Gui测试运营器出现。当你第一次开始NUnit-Gui，它打开时没有测试加载。从File菜单选择Oprn，浏览NUnitQuickStart.dll的途径。当你加载了测试的程序集，测试运营器为加载的程序集的测试产生一个可见的表现。在例子中，测试程序集仅有一个测试，测试程序集的结构如图4－4所示：

图4-4:测试程序集的测试在NUnit-Gui中的视图按Run按钮。树的节点变为绿色，并且测试运营器窗口上的进度条变绿，绿色代表成功通过。

1.4其他的一些核心概念

上面的例子介绍了基本的NUnit特性和功能.TestFixture,Test,和Assert是3个最基本的特性,我们可以用这些特性进行程序员测试了.但是有的时候,你觉得这3个远远不够,比如有的时候打开一个数据库连接多次,有没有只让它打开一次的方法呢?假如我想把测试分类,应当如何实现呢?假如我想忽略某些测试,又应当如何去完毕呢?不用紧张,NUnit已有这样的功能了.下面我们一一作出回答.SetUp/TearDown属性在初期给的testfixture定义里,我们说testfixture的测试是一组常规运营时资源.在测试完毕之后,或是在测试执行种,或是释放或清除之前,这些常规运营时资源在一拟定的方式上也许需要获取和初始化.NUnit使用2个额外的属性:SetUp和TearDown,就支持这种常规的初始化/清除.我们上面的例子来描述这个功能.让我们增长乘法.C#代码using

System;

using

NUnit.Framework;

namespace

NUnitQuickStart

{

[TestFixture]

public

class

NumersFixture

{

[Test]

public

void

AddTwoNumbers()

{

int

a=1;

int

b=2;

int

sum=a+b;

Assert.AreEqual(sum,3);

}

[Test]

public

void

MultiplyTwoNumbers()

{

int

a

=

1;

int

b

=

2;

int

product

=

a

*

b;

Assert.AreEqual(2,

product);

}

}

}

我们仔细一看,不对,有反复的代码,如何去除反复的代码呢?我们可以提取这些代码到一个独立的方法,然后标志这个方法为SetUp属性,这样2个测试方法可以共享对操作数的初始化了,这里是改动后的代码:

C#代码using

System;

using

NUnit.Framework;

namespace

NUnitQuickStart

{

[TestFixture]

public

class

NumersFixture

{

private

int

a;

private

int

b;

[SetUp]

public

void

InitializeOperands()

{

a

=

1;

b

=

2;

}

[Test]

public

void

AddTwoNumbers()

{

int

sum=a+b;

Assert.AreEqual(sum,3);

}

[Test]

public

void

MultiplyTwoNumbers()

{

int

product

=

a

*

b;

Assert.AreEqual(2,

product);

}

}

}

这样NUnit将在执行每个测试前执行标记SetUp属性的方法.在本例中就是执行InitializeOperands()方法.记住，这里这个方法必须为public，不然就会有以下错误：InvalidSetuporTearDownmethodsignatureExpectedException这里是一个验证这个假设的测试.有的时候,我们知道某些操作会有异常出现,例如,在实例中增长除法,某个操作被0除,抛出的异常和.NET文档描述的同样.参看以下源代码.C#代码[Test]

[ExpectedException(typeof(DivideByZeroException))]

public

void

DivideByZero()

{

int

zero

=

0;

int

infinity

=

a/zero;

Assert.Fail("Should

have

gotten

an

exception");

}

除了[Test]属性之外,DivideByZero方法有此外一个客户属性:ExpectedException.在这个属性里,你可以在执行过程中捕获你盼望的异常类型,例如在本例就是DivideByZeroException.假如这个方法在没有抛出盼望异常的情况下完毕了,这个测试失败.使用这个属性帮助我们写程序员测实验证边界条件(BoundaryConditions).Ignore属性

由于种种因素,有一些测试我们不想运营.当然,这些因素也许涉及你认为这个测试还没有完毕,这个测试正在重构之中,这个测试的需求不是太明确.但你有不想破坏测试,不然进度条可是红色的哟.怎么办?使用Ignore属性.你可以保持测试,但又不运营它们.让我们标记MultiplyTwoNumbers测试方法为Ignore属性:C#代码[Test]

[Ignore("Multiplication

is

ignored")]

public

void

MultiplyTwoNumbers()

{

int

product

=

a

*

b;

Assert.AreEqual(2,

product);

}

运营测试,现在产生了下面的输出(在图5-1显示):

图5-1:在一个程序员测试中使用Ignore属性

Ignore属性可以附加到一个独立的测试方法,也可以附加到整个测试类(TestFixture).假如Ignore属性附加到TestFixture,所有在fixture的测试都被忽略.TestFixtureSetUp/TestFixtureTearDown

有时,一组测试需要的资源太昂贵.例如,数据库连接也许是一个关键资源,在一个testfixture的每个测试中,打开/关闭数据库连接也许非常慢.这就是我在开始提到的问题.如何解决?NUnit有一对类似于前面讨论的SetUp/TearDown的属性:TestFixtureSetUp/TestFixtureTearDown.正如他们名字表白的同样,这些属性用来标记为整个testfixture初始化/释放资源方法一次的方法.

例如,假如你想为所有testfixture的测试共享相同的数据库连接对象,我们可以写一个打开数据库连接的方法,标记为TestFixtureSetUp属性,编写此外一个关闭数据库连接的方法,标记为TestFixtureTearDown属性.这里是描述这个的例子.C#代码using

NUnit.Framework;

[TestFixture]

public

class

DatabaseFixture

{

[TestFixtureSetUp]

public

void

OpenConnection()

{

//open

the

connection

to

the

database

}

[TestFixtureTearDown]

public

void

CloseConnection()

{

//close

the

connection

to

the

database

}

[SetUp]

public

void

CreateDatabaseObjects()

{

//insert

the

records

into

the

database

table

}

[TearDown]

public

void

DeleteDatabaseObjects()

{

//remove

the

inserted

records

from

the

database

table

}

[Test]

public

void

ReadOneObject()

{

//load

one

record

using

the

open

database

connection

}

[Test]

public

void

ReadManyObjects()

{

//load

many

records

using

the

open

database

connection

}

}

TestSuite

TestSuite是testcase或其他testsuite的集合.合成(Composite),模式描述了testcase和testsuite之间的关系.

参考来自NUnit的关于Suite的代码SuiteAttributeC#代码namespace

NUnit.Tests

{

using

System;

using

NUnit.Framework;

public

class

AllTests

{

[Suite]

public

static

TestSuite

Suite

{

get

{

TestSuite

suite

=

new

TestSuite("All

Tests");

suite.Add(new

OneTestCase());

suite.Add(new

Assemblies.AssemblyTests());

suite.Add(new

AssertionTest());

return

suite;

}

}

}

}

Category属性

对于测试来说，你有的时候需要将之分类，此属性正好就是用来解决这个问题的。

你可以选择你需要运营的测试类目录，也可以选择除了这些目录之外的测试都可以运营。在命令行环境里/include和/exclude来实现。在GUI环境下，就更简朴了，选择左边工作域里的CatagoriesTab，选择Add和Remove既可以了。在上面的例子上做了一些改善，代码如下：C#代码using

System;

using

NUnit.Framework;

namespace

NUnitQuickStart

{

[TestFixture]

public

class

NumersFixture

{

private

int

a;

private

int

b;

[SetUp]

public

void

InitializeOperands()

{

a

=

1;

b

=

2;

}

[Test]

[Category("Numbers")]

public

void

AddTwoNumbers()

{

int

sum=a+b;

Assert.AreEqual(sum,3);

}

[Test]

[Category("Exception")]

[ExpectedException(typeof(DivideByZeroException))]

public

void

DivideByZero()

{

int

zero

=

0;

int

infinity

=

a/zero;

Assert.Fail("Should

have

gotten

an

exception");

}

[Test]

[Ignore("Multiplication

is

ignored")]

[Category("Numbers")]

public

void

MultiplyTwoNumbers()

{

int

product

=

a

*

b;

Assert.AreEqual(2,

product);

}

}

NUnit-GUI界面如图5-2：图5-2:使用Catagories属性的界面Explicit属性本属性忽略一个test和testfixture，直到它们显式的选择执行。假如test和testfixture在执行的过程中被发现，就忽略他们。所以，这样一来进度条显示为黄色，由于有test或testfixture忽略了。

例如：C#代码[Test,Explicit]

[Category("Exception")]

[ExpectedException(typeof(DivideByZeroException))]

public

void

DivideByZero()

{

int

zero

=

0;

int

infinity

=

a/zero;

Assert.Fail("Should

have

gotten

an

exception");

}

为什么会设计成这样呢？因素是Ingore属性忽略了某个test或testfixture，那么他们你再想调用执行是不也许的。那么万一有一天我想调用被忽略的test或testfixture怎么办，就用Explicit属性了。我想这就是其中的因素吧。ExpectedException属性

盼望在运营时抛出一个盼望的异常，假如是，则测试通过，否则不通过。参看下面的例子：C#代码[Test]

[ExpectedException(typeofInvalidOperationException))]

public

void

ExpectAnException()

{

int

zero

=

0;

int

infinity

=

a/zero;

Assert.Fail("Should

have

gotten

an

exception");

}

在本测试中，应当抛出DivideByZeroException，但是盼望的是InvalidOperationException，所以不能通过。假如我们将[ExpectedException(typeof(InvalidOperationException))]改为[ExpectedException(typeof(DivideByZeroException))]，本测试通过。1.5测试生命周期合约

假如记得testcase的定义,其中一个属性是测试的独立性或隔离性.SetUp/TearDown方法提供达成测试隔离性的目的.SetUp保证共享的资源在每个测试运营前对的初始化,TearDown保证没有运营测试产生的遗留副作用.TestFixtureSetUp/TestFixtureTearDown同样提供相同的目的,但是却在testfixture范围里,我们刚才描述的内容组成了测试框架的运营时容器(testrunner)和你写的测试之间的生命周期合约(life-cyclecontract).

为了描述这个合约,我们写一个简朴的测试来说明什么方法调用了,怎么合适调用的.这里是代码:C#代码using

System;

using

NUnit.Framework;

[TestFixture]

public

class

LifeCycleContractFixture

{

[TestFixtureSetUp]

public

void

FixtureSetUp()

{

Console.Out.WriteLine("FixtureSetUp");

}

[TestFixtureTearDown]

public

void

FixtureTearDown()

{

Console.Out.WriteLine("FixtureTearDown");

}

[SetUp]

public

void

SetUp()

{

Console.Out.WriteLine("SetUp");

}

[TearDown]

public

void

TearDown()

{

Console.Out.WriteLine("TearDown");

}

[Test]

public

void

Test1()

{

Console.Out.WriteLine("Test

1");

}

[Test]

public

void

Test2()

{

Console.Out.WriteLine("Test

2");

}

}

当编译和运营这个测试,可以在System.Console窗口看到下面的输出:

FixtureSetUp

SetUp

Test

1

TearDown

SetUp

Test

2

TearDown

FixtureTearDown

可以看到,SetUp/TearDown方法调用在每个测试方法的前后.整个fixture调用一次TestFixtureSetUp/TestFixtureTearDown方法.

2、TestManager软件测试工具2.1TestManager介绍使用IBMRationalClearQuest测试管理IBMRationalClearQuest的V7.0发布版本宣布了一个重大的策略转移，就是将IBMRational方法应用到测试管理中。在这个版本之前，测试管理的功能是由IBMRationalTestManager提供的，它包含为质量保证（QA）组织进行的测试计划、测试执行和测试结果分析。2.2TestManager具体使用图1：CQTM测试脚本对话框安装ClearQuest并创建的数据库

图2：IBMRationalClearQuest测试项目配置在创建的测试用例和计划之前，需要完毕一个安装和配置工作，这个工作只需做一次。必须提供ClearQuest的核心信息，例如存放测试资产的地方。资产注册资产注册将会保管的所有资产。包含所有测试计划，以及其中的测试用例。它还包含的所有测试套件，以及的IBMRationalManualTester、IBMRationalFunctionalTester和IBMRationalPerformance的文献位置。它还会包含的所有测试结果。图3：配置属性创建配置图4：完毕配置和配置属性的创建测试计划在下一个部分，将会创建多层次测试。一个测试计划是一组测试用例的组合结构。测试用例是特定的测试或者验证，需要在的系统上执行。因此，在创建了测试计划之后，需要把测试用例插入到这些测试计划中。最后，将会把之前章节创建的配置和测试用例结合起来。一个单独的测试用例是一个抽象的概念，在这个测试用例中仅定义了需要测试什么。将配置和测试用例结合起来后，就创建了一个已配置的测试用例，这样就不仅能表达要测试什么，还能表达在哪里测试（在哪个平台或者配置）。创建测试计划测试计划的第一步是创建一个测试计划来控制的所有测试用例。组织测试计划和测试用例的方法有很多种。与其在这里阅读测试计划组织结构的长长的讨论过程，还不如使用非常大众化的功能分解结构，来为应用程序的各种功能区域创建子测试计划。通过使用这个结构，的测试计划体系结构将会符合的应用程序体系结构。图5：ClearQuest支持层次化测试计划创建测试用例在创建了测试计划结构之后，下一步是将测试计划和测试用例结合。测试用例定义了每一个计划在系统上执行的确认。（查看图6。）图6：关联测试计划和测试用例关联测试脚本和测试用例测试计划和测试用例显示了逻辑上的测试计划。可以把测试计划想象成一张需要运营的测试用例的列表。但是如何运营这些测试呢？如何才干知道测试运营成功还是失败呢？可以在Execution标签获得答案。可以使用Execution标签将的测试用例连接到一个实际的测试脚本。测试脚本会显示出测试成功或者失败。ClearQuestTestManager支持在IBMRationalFunctionalTester、IBMRationalManualTester和IBMRationalPerformanceTester测试自动化工具中创建的测试脚本的执行．它还支持Test和PerformanceToolPlatform，或者TPTP兼容性测试，例如TPTPJUnit测试。RationalFunctionalTester是一个基于脚本的回归测试工具，它能以脚本形式捕获应用程序中用户的行为，以用于之后的回归和系统验证。RationalManualTester是一个手动测试和执行工具。可以使用它捕获运营在应用程序上的测试脚本环节和行为。它会在运营测试的时候自动输入并验证数据。RationalPerformanceTester是一个帮助评价系统响应基于Web和公司资源计划（ERP）应用程序时间的工具。它可以在系统发布之前，模拟的系统上并发用户的活动，并测量响应时间，显示性能和瓶颈。创建文献途径一方面要告知ClearQuest测试的文献途径，才干将的测试脚本和测试用例结合起来。这个工作仅需要做一次。在这个环节之后，所有的测试用例都应当可以根据提供的文献途径访问脚本。（查看图7。）根据下列属性，反复以上环节创建一个文献途径：文献途径名称：ManualTesterTests文献途径：C:CQTMTestScriptsManualTesterManualTesterScripts测试日记途径：C:CQTMTestScriptsManualTesterManualTesterLogs图9：文献途径告知ClearQuest去哪里寻找测试自动化脚本在测试脚本和测试用例之间建立关联现在ClearQuest已经知道了的脚本是什么，按照下列环节将RationalFunctionalTester和RationalManualTester脚本和的测试用例关联起来（查看图8）：图8：测试脚本和测试用例的关联ViewExistingOrder测试脚本已经和ViewExistingOrderStatus测试用例关联。（的记录ID是：CQTST00000047，也也许不同。）测试执行为了更具一般合用性，假设没有安装任何测试脚本执行工具，例如RationalManualTester或者RationalFunctionalTester。这就是为什么下一章节合用于执行一个真实的测试。一方面，运营一个测试用例，然后创建一个测试用例套件。的第一步，（忽略是如何执行的测试）是将配置和测试用例关联起来。（查看图9。）关联配置和测试用例测试用例是抽象的工件。一个测试用例代表了需要测试的东西，但是一个测试用例自身并不能执行。一个测试用例只有当将它和特定的配置关联起来时，它才干执行。在这个教程中已经创建了两个配置，因此的下一步工作是将测试用例邦定到这两个配置。图9：的测试计划过程已经完毕，配置好的测试用例已经准备就绪安排测试迭代进度可以把配置想象成定义在哪里运营一个测试用例。在ClearQuest中，同时要定义什么时间运营一个测试用例。什么时间运营一个测试用例叫做迭代。（查看图12。）假如熟悉IBMRationalUnifiedProcess®，或者RUP®，那么就不会对这里的迭代概念感到陌生。RationalTestManager的用户也对迭代概念比较熟悉。一个迭代的目的是具体说明在什么时间点上，或者在开发的什么阶段，一个测试用例可以被运营。图10：迭代对于这个重要的环节来说，运营或者执行一个测试的实际过程出奇的简朴。右键点击配置的测试用例，然后选择Execute选项。需要安装好自动化工具才干执行一个配置好的测试用例。假如没有安装这个工具，执行选项是不可用的。测试执行不也许来自所有的ClearQuest客户端。Windows和Web客户端不能执行任何脚本文献。Lin