Silverlight单元测试框架

发布时间: 2010-2-03 13:41    作者: 王喆(nasa) [cnblogs]    来源: 51Testing软件测试网采编

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 推荐标签： 测试框架 单元测试

　　微软的silverlight单元测试框架现在已经托管到了MSDN Code Gallery网站上，你可以在上边找到最新的Release版本和一些最新的资料。

　　http://code.msdn.microsoft.com/silverlightut/

　　每当一个开发人员尝试过了测试驱动开发（TDD）就会十分的欣赏这个方式。接下来我将介绍一下如何使用来使用这个框架。

开始单元测试项目

　　配置环境

　　1.下载Silverlight Unit Test VS模板

　　2.下载Silverlight Unit Test Framework Binaries库

　　解压。

　　将里面包含的SilverlightTestProject_CSharp.zip和SilverlightTestProject_VB.zip文件拷贝到（不要再把上述两个.zip文件解压了，不然VS不认）。

　　%userprofile%\Documents\Visual Studio 2008\Templates\ProjectTemplates

　　再将SilverlightTestClass_CSharp.zip以及SilverlightTestClass_VB.zip文件拷贝到：

　　%userprofile%\Documents\Visual Studio 2008\Templates\ItemTemplates

启动VS2008：

　　看一下项目文件：

　　添加一下缺少的DLL引用。

　　配置成功！

　浅析框架

　　这里项目里只有两个文件，让我们来看看

　　App.xaml.cs

private void Application_Startup(object sender, StartupEventArgs e) {     this.RootVisual = UnitTestSystem.CreateTestPage(); }

　　其中UnitTestSystem是Microsoft.Silverlight.Testing命名空间下的一个类，而CreateTestPage()方法将返回一个UIElement。

　　Test.cs

　　很简单就是在里边写测试方法的。

[TestMethod] public void TestMethod() { 　　Assert.Inconclusive(); }

　　改为

[TestMethod] public void TestMethod() { 　　Assert.IsTrue(true); }

　　F5运行。

测试自己的Silverlight项目

　　新建一个Silverlight项目：

　　给MainPage.xaml做简单的修改：

public partial class MainPage : UserControl     {         private string _author;         public string Author { get; set; }         public MainPage()         {             InitializeComponent();         }     }

　　单元测试中添加对其的引用，并可新建立一个class来对其做测试：

　　编写测试方法：

[TestClass]     public class MyTest     {         //[TestMethod]         //[ExpectedException(typeof(NullReferenceException))]         //public void NullInstance() {         //    MainPage mainpage = null;         //    string author = mainpage.Author;         //}         [TestMethod]         [Description("测试用户名")]         public void VerifyAuthor() {             MainPage page = new MainPage();             page.Author = "nasa";             Assert.IsNotNull(page.Author);             Assert.AreEqual(page.Author, "nasa");         }     }

　　F5运行：

　　也可点击单个的方法查看详情：

　　大家可以直接将自己的sl项目附加进来进行测试，当然在实际的项目中不会这么简单。

总结

　　使用TDD单元测试框架为Silverlight带来了一个更好的测试方案，你不用再一点一点的设置断点跟着程序跑。

　　能充分的进行单元测试，是提高软件质量，降低开发成本的必由之路。如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。

推荐阅读：

JavaFX，Flex和Silverlight横向对比

Silverlight 2单元测试框架

在Silverlight中做单元测试

测试自动化的计划和实施

发布时间: 2011-8-05 14:27    作者: ricky.zhu    来源: 51Testing软件测试网采编

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 推荐标签： 软件测试 自动化测试

　　测试自动化的计划和实施系列文章，最近开始酝酿思路，初步打算分为四个部分来组织，这也是我亲身经历的一个自动化项目的四个阶段，大家可以对号入座，看看你所在的公司或者组织处于自动化实施的哪个阶段？

　　第一个阶段：从无序到有序

　　这个阶段主要是自动化测试的引入，从一开始的无序的自动化测试，摸着石头过河，到慢慢找到一些窍门，其中的关键点/转折点是自动化测试系统或者说自动化测试平台的出现。这个时间大概持续了1年左右。这部分重点介绍如何找到通往有序的方法和思路。

　　第二个阶段：从烦杂到豁然开朗

　　这个阶段主要介绍基于原始的自动化测试系统开发积累到一定程度的问题显现。逐步暴露的问题在这个阶段到了非解决不可的程度，主要的问题是什么？解决的思路是什么？到也是我们自动化测试进展最艰难的时候。希望能对你有所帮助。

　　第三个阶段：从点到面铺开

　　这个阶段主要介绍自动化测试系统和平台的推广，好的平台是推广和大面积使用的前提和保证。如何保证平台在推广过程中能顺利？推广过程中我们遇到了哪些阻力？我们是如何解决这些阻力和克服困的？

　　第四个阶段：收获和ROI

　　这个阶段分析在自动化测试推广以后的一些问题，我们应该如何计算我们的产出和投入，投资回报应该如何计算？ 这个阶段我们会遇到什么问题？ 如何解决？

　　自动化测试的计划和实施第一阶段

　　从自动化测试决策的制定到决定进行实施，这中间有很多工作要做。包括说服你的老板，自动化是一个持续投入的过程，而且初期投入很大，短期内无法看到回报，而且要持续进行投入，不能半途而废，投入的过程中需要各个部门的通力合作，上至包括系统分析师，研发人员特别是研发部门经理，项目经理。下至系统测试部门等等，每个环节都跟自动化测试有着直接和间接的关系。 一旦决定开始进行实施自动化测试，就基本上没有回头的道路，因为前期的巨大的投入，导致如果想要中途终止，那么前期的巨大投入就是严重的资源浪费。

　　开头讲了一点题外话，现在开始介绍实施的第一阶段——从无序到有序。

　　我参与的这个产品的自动化项目开始于二零零三年初，从一开始就缺少经验，我们走过的每一步现在回想起来都是痛苦的经历。因为大家都没有类似的自动化经验，加上团队的每个成员基本上都是开发出身，加上项目进度紧张，缺乏必要的自动化测试理念和自动化测试的相关培训。更严重的事，这个时候，自动化刚刚起步，没有一个自动化的平台支持。 结果是每个工程师把一个单独的自动化测试项目（一个模块）作为一个独立的工具进行开发。结果导致自动化测试用例的混乱，而且无法进行维护。不同工程师开发出来的东西也是千奇百怪。自动化团队的工程师慢慢的失去了耐心和信心，产生了抵触情绪，这个为以后的自动化测试的顺利开展带来了一定的障碍。

　　这个时候的教训就是不能急于求成，不能为了一味的追求速度和效率。自动化团队的经理应该控制项目的节奏，不能妥协于项目的巨大压力。逐步培养自动化开发工程师的兴趣和探索动力。

　　另外就是自动化团队成员没有系统全面的培训和严格的规范约束，即使每个人都有能力开发出来自动化测试脚本，但是却难于维护和执行。这个时候我们就认识到自动化测试平台或者架构的重要性不仅仅在于使得测试脚本的开发更加容易进行，而且可以统一大家的思想和测试脚本的一致性。 在这之前我们对自动化测试平台的认识比较肤浅。

　　在不同的阶段，自动化团队的成员构成也不尽相同。在这个阶段，自动化团队的成员基本上都是自动化开发工程师。就是把手工的测试模块进行脚本化。然后可以自动化进行执行。

　　自动化测试的计划和实施第二阶段

　　第二阶段的副标题：从烦杂到豁然开朗

　　其实这是我们经历的真实的过程，从一开始的没有完整的自动化平台和对平台重要性的认识不足，加上缺乏相关的经验，这个过程可谓吃尽了苦头。这这个阶段，即使有了测试平台的支持，随着脚本技术的进步，我们仍然要为以后的维护和扩展付出很大的代价。

　　这样的痛苦过程经历了大概半年左右的时间，当随着脚本技术的探索思路越来越清晰的时候。其中最关键的里程碑是API概念的提出，就是一个分层的概念。其实也没有多少创意而言，只是在自动化测试概念中提出来，颇有一些不同。

　　自动化测试的被测试对象总是千差万别的，针对不同的测试对象开发不同的API显然不是办法，我们提出了三层API的概念。底层API，针对一些基本的操作，比如界面GUI的操作，封装一些基本的原子操作方法：按钮，下拉框，列表框等。针对服务器的操作，封装一些telnet，执行命令，获返回结果等。针都数据库操作（oracle和mysql分开进行），封装一些查询，提交，连接等原子操作的API。随着业务的不断变化，这些原子操作不需要进行维护，只有在需要的时候进行扩充。原子层之上是逻辑层，这一层的API变化的可能性比较大，对他们进行版本管理，这是一个颗粒相对较大的封装，可以充分一些原子层的操作进行组装。最大限度的重用原子层的代码。最上层就是业务层的操作，这部分的颗粒更大。利用业务层的接口进行组装。需要注意的是，对于每一层的API，接口要进行很好的设计和论证，充分考虑扩充和重用。必要的时候利用变参。

　　上面讲了一些具体实现，这是从技术的实现角度考虑的。另外，平台的开发工作是同步进行的。好的技术实现离不开平台的支撑。还需要重复那句话：好的平台不仅仅使得测试开发变得更加容易，而且可以统一测试开发人员的思想和规范性。

　　平台的东西只做简单介绍，我们平台开发基于Linux，主要语言是前台的Java和后台的Tcl，数据库选的Oracle。整个系统是一个分布式的测试平台，前端是Web浏览器，后端是执行引擎。用户可以直接利用前面说的原子API在平台上书写测试用例，并进行执行。 这是一个很好的IDE。有很多比较强大的功能，包括测试执行，定制，开发，统计。

　　至此，自动化进入了相对来说正规化的阶段。

　　自动化测试的计划和实施第三阶段

　　进入到自动化测试的第三阶段，此时距离当初开始实施自动化测试的决定，两年三个月已经过去了，可见自动化测试的实施不是一蹴而就的，更不可急功近利。第三个阶段的标志是有点到面的全面铺开。

　　自动化测试开展的初期，可以是一个小组，几个人进行小面积的试点，这样投入的成本不是很大，即使失败了，也是可以理解和接受的，而要想取得投资回报或者大面积的试用和推广，前提的试点也是必须的。 但是仅仅靠几个人是不可能把自动化测试做起来的。自动化测试的开发工作是一个持续的过程，又是一个矛盾体。

　　持续的过程体现在：随着回归测试的不断进行，老的功能不断被自动化起来，就有一定的维护工作量，另外，新功能的测试不断完善和稳定，又变成可以进行自动化测试的老功能。所以自动化测试是一个持续进行的过程，另外，又是一个持续改进的过程，随着自动化测试技术的不断成熟和测试业务的不断丰富，以前的老功能的测试用例或者测试脚本也同样需要进行更新和维护。

　　矛盾体体现在两个方面：首先自动化测试的开发和维护本身需要对测试脚本和测试业务有一定的熟悉。实际情况往往并非如此，精通测试业务的测试工程师一般情况下对测试脚本甚至自动化测试一无所知。而对测试开发非常熟悉的自动化测试工程师又不熟悉业务，所以矛盾就这样产生了。另外，从整体来看，自动化测试工程师的数量肯定远远小于手工测试工程师，这样，对业务测试工程师熟悉自动化测试知识，了解测试平台和测试脚本就提出了更高的要求。如果有一半的测试工程师都能熟悉测试脚本，可以试用测试平台进行相关的自动化测试开发，那么可以肯定的说：自动化测试已经成功了一大半。

　　矛盾的另外一个方面是资源的问题。手工测试工程师往往由于测试进度的压力疲于应付，所以对自动化测试平台或者脚本的学习缺少时间，这个时候，测试经理就需要有很好的协调能力，可以从团队内部抽调部分懂开发，学习能力快的测试工程师进行集中的培训，在测试团队内部形成一种自动化测试的氛围，从而引导整个测试团队更好的进行自动化测试的开展。还有一种问题，就是我们在实际操作过程中遇到的，虽然不是典型，不过也应该注意避免这种情况的发生，手工测试工程师有些保守的观念，对自动化测试技术是排斥的。他们错误的认为，自动化测试的开展是对手工测试的冲击，如果所有的feature都被自动化执行了，那么手工测试就被取代了。其实这是一种十分狭隘的心态，至于道理为什么，前面也已经提及了，自动化测试是一个持续的过程。这里就不多说。

　　如果自动化测试可以顺利在一个系统测试团队中开展，并且很好的坚持下去，很快自动化测试的效果和投资回报就能体现出来了。

　　自动化测试的计划和实施第四阶段

　　第四阶段，也是最后一个阶段了。在开始这个阶段之前，还想多说几句，今天又有朋友说他们公司打算实施自动化测试了，开发经理主导的。他们对测试自动化的认识还是停留在自动化测试工具上。只是十分要命的。自动化测试的初衷是要缩短测试周期，出发点是好的，但是步骤明显有问题，测试周期的缩短是可以靠提高测试效率，改进测试方法和引进测试工具来达到的，但是不是决定因素。测试流程的规范才是最根本的，如果一个组织测试流程不规范，想通过引入自动化测试来规范这一流程是很不现实的。

　　好了，现在开始正题。

　　自动化测试的第四阶段是收获和ROI（投资回报）

　　进入这个阶段，基本组织的测试自动化已经步入正轨和良性的发展，随着回归测试的不断深入，自动化测试的投入也初显成效。一方面，通过不断的回归测试，测试的质量得到了一定程度的提高，另外，测试效率也大大提高。同事，因为测试和开发的沟通渠道日益畅通，产品的稳定性和可测性也有了改进。这是一个良性的互动过程。

　　通过不断的测试执行，测试的投资回报这个时候可以进行一些统计。

　　先谈谈投资回报（Return On Investment）

　　ROI不是自动化测试专有的名词， 任何项目都要讲求ROI， 没有事先做过ROI分析的项目都会面临失败的危险

　　ROI是投入总成本和实际获利之间的一个对比率， 如果实际获利大于实际投入总成本， 则本次投资是合算的

　　ROI可以由两方面来计算： 在向某件事投入之前， 先估计一下可以获利多少， 在执行之后再看一看实际获利多少， 前者是用度量的方法来预测， 后者是进行评估。

　　一个简单的自动化测试投资回报率的计算方法

　　自动化测试成本 = 工具软硬件成本 + 脚本开发所耗成本 + （脚本维护成本 X 脚本执行次数） + （脚本执行成本 X 脚本执行次数）

　　手工测试成本 = 测试用例设计开发成本 + （测试用例维护成本 X 测试用例执行次数） + （手工测试执行成本 X 测试用例执行次数）

　　利益 = 手工测试成本 – 自动化测试成本

　　ROI = 利益/自动化测试成本

　　注： 自动化测试的ROI无法显示在测试过程中查找出来的缺陷个数

　　至此，这个系列的原创文章全部结束。

 

忙、累、乱

初次尝试测试管理的工作，什么流程都要制定，什么事情都要安排

所以，这几个月来忙得我都没有时间来51Testing看一下

昨天受了一个打击，就是绩效考评的时候，我被评了B+，而我的另外一个同事（可以说是下属吧）评了A

不过这也是理所当然的，因为我成天杂事一大堆，对项目的测试没有花太长的时间，bug也提交不多

不过，对于好胜心那么强的我来说，总是觉得有点委屈的

唯一值得安慰的是，由我们测试小组拿出去的软件版本基本上都是没有什么问题的，质量是保证的，哇咔咔咔

不过，现在却好像进入了一个迷茫的阶段：我以后的职业道路该怎么走？

自己总是走一步算一步，没有什么规划，现在工作也差不多两年了，这个问题却开始横在我的面前……

 

这是从“超越自我”处转的关于软件发布前需要进行的一些测试，刚好需要这个，就暂时先转过来。

大型软件在正式发布前，通常需要执行Alpha和Beta测试，目的是从实际终端用户的使用角度，对软件的功能和性能进行测试，以发现可能只有最终用户才能发现的错误。

Alpha测试（α测试）是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草稿）等应该在Alpha测试前准备好。

Beta测试（β测试）是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。因而，Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后，才能开始Beta测试。由于Beta测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持产品发行的人员来管理。

由于Alpha和Beta测试的组织难度大，测试费用高，测试的随机性强、测试周期跨度较长，测试质量和测试效率难于保证，所以，很多专业软件可能不再进行Beta测试。随着测试技术的提高，以及专业测试服务机构的大量涌现，很多软件的Beta测试外包给这些专业测试机构进行测试。

α测试和β测试

在软件交付使用之后,用户将如何实际使用程序,对于开发者来说是无法预测的.

α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试. α测试的目的是评价软件产品的FLURPS(即功能,局域化,可使用性,可靠性,性能和支持).尤其注重产品的界面和特色. α测试可以从软件产品编码结束之时开始,或在模块(子系统)测试完成之后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始.

β测试是由软件的多个用户在实际使用环境下进行的测试.这些用户返回有关错误信息给开发者. 测试时,开发者通常不在测试现场.因而,β测试是在开发者无法控制的环境下进行的软件现场应用. 在β测试中,由用户记下遇到的所有问题,包括真实的以及主观认定的,定期向开发者报告. β测试主要衡量产品的FLURPS.着重于产品的支持性,包括文档,客户培训和支持产品生产能力.

只有当α测试达到一定的可靠程度时,才能开始β测试.它处在整个测试的最后阶段.同时,产品的所有手册文本也应该在此阶段完全定稿.

α、β、λ常用来表示软件测试过程中的三个阶段，α是第一阶段，一般只供内部测试使用；β是第二个阶段，已经消除了软件中大部分的不完善之处，但仍有可能还存在缺陷和漏洞，一般只提供给特定的用户群来测试使用；λ是第三个阶段，此时产品已经相当成熟，只需在个别地方再做进一步的优化处理即可上市发行。

其它相关的版本说明：

Trial：试用版，通常都有时间限制，有些试用版软件还在功能上做了一定的限制。可注册或购买成为正式版

Unregistered：未注册版，通常没有时间限制，在功能上相对于正式版做了一定的限制。可注册或购买成为正式版。

Demo：演示版，仅仅集成了正式版中的几个功能，不能升级成正式版。

Lite：精简版。

Full　version：完整版，属于正式版。

开发阶段划分：

α（Alpha）版：内测版，内部交流或者专业测试人员测试用。Bug较多，普通用户最好不要安装。

β（Beta）版：公测版，专业爱好者大规模测试用，存在一些缺陷，该版本也不适合一般用户安装。

γ（Gamma）版：相当成熟的测试版，与即将发行的正式版相差无几。

RC版：Release　Candidate。

RC版。是ReleaseCandidate的缩写，意思是发布倒计时，候选版本，处于Gamma阶段，该版本已经完成全部功能并清除大部分的BUG。到了这个阶段只会除BUG，不会对软件做任何大的更改。从Alpha到Beta再到Gamma是改进的先后关系，但RC1、RC2往往是取舍关系。

Final：正式版。

比较少用的：

Enhance　：增强版或者加强版　属于正式版1

Free　：自由版

Release　：发行版　有时间限制

Upgrade　：升级版

Retail　　：零售版

Cardware　：属共享软件的一种，只要给作者回复一封电邮或明信片即可。（有的作者并由此提供注册码等），目前这种形式已不多见。/　S

Plus　：属增强版，不过这种大部分是在程序界面及多媒体功能上增强。

Preview　：预览版

Corporation　&　Enterprise　：企业版

Standard　：标准版

Mini　：迷你版也叫精简版只有最基本的功能

Premium　：　贵价版

Professional　：　专业版

Express　：　特别版

Deluxe　：　豪华版

Regged　：　已注册版

这是刚才从“beyondwis-zjp”空间里看到的，自己正需要这个，就先转过来了

完善测试工作整个工作内容主要有:

　　1、改善测试流程，形成《测试流程》文档

　　2、规范测试工作，形成《测试规范》文档

　　看上去就只需要上面两个文档就够了，但经详细分析，发现还需要很多相关的需要文档，整理了一下主要有

　　1、《测试申请与反馈表》模板

　　2、《测试计划》模板

　　3、《功能测试测试点》模板

　　这个与测试用例差不多，但不用写得很详细，主要把容易漏掉的测试点写下来

　　4、《BUG严重性等级与优先级定义》文档

　　5、《BUG提交注意事项》文档

　　6、《功能测试报告》模板

　　7、《性能测试计划》模板

　　8、《性能测试指标及相关说明》文档

　　9、《性能测试报告》模板

　　10、《项目测试报告》模板

　　11、《项目资料存档规范》文档

嗯嗯，终于为自己的工作找了一个家。虽然不知道自己能坚持多久，工作了一年半，半年开发（算是混日子），一年软件测试，但始终觉得自己真正的爱好不是这个。不过，干一行爱一行，毕竟现在自己还要靠它吃饭，所以，靠它过日子的每一天，我都得好好地做好它

嗯，最近承受的压力比较大，除了加班之外，还有一部分是因为来了新同事的原因，以后的工作中有了竞争。更要命的是，人家比我早工作一年，但还是我面试她进来的，呵呵，第一次当老大的感觉，但我们现在的测试组还没有老大，只是当时我们部门经理不知道怎么想的，就让我去面试了。所以，我现在的位子还是很矛盾的，模糊的，不知道该怎么定位自己，感觉乱套了。

之前的一年软件测试，都是自己一个人主导干的，从糊里糊涂进来这行，自己摸索着去做，虽然刚开始时被公司的人说过“你真的是刚开始入行的吗？那算你真的很有天分”，但我对于软件测试的概念还是不清晰…所以最后因为杂事太多，对于软件测试根本没有很专业的认识，所以就跳槽了。

现在，来到这个公司，在我之前也一样没有软件测试，所以，我等于是先行者。不过，我之前又没有做过测试管理的工作，现在也只能摸索着去做，希望自己能加油做好。嗯…