网站测试自动化系统—收集测试结果

本文涉及的产品
云拨测,每月3000次拨测额度
简介:

在前面的文章执行测试用例里,已经解释了如何通过命令行来编译和执行测试用例,这样我们才有机会通过批处理的方式来将执行测试用例自动化。而我在文章系统应该有的功能里,也讲到了一个完整的自动化系统应该是能够自动收集测试结果的—毕竟我们的远景是,测试人员在晚上下班前将用例执行起来,然后在第二天上午就可以直接看测试报告了。

一般来说,测试报告需要包含以下几个信息:

1.         测试用例的通过率,通过率代表产品的稳定程度,当然这是在排除了测试用例本身的问题引起的测试失败(Test Failure)得到的通过率。前面执行测试用例里提到到的MsTest.exe生成的结果文件.trx文件就已经保存了这个信息,在资源管理器里面双击这个文件,就能看到类似下图的结果:

 

 

在上图里面,可能会有细心的读者发现里面只有3个用例,但是红圈里面标出的文字却说:“6/6 passed”,这是因为这3个用例当中有数据驱动的用例,VSTT把每一行数据都当作一个独立的测试用例。关于数据驱动测试,可以参看我的这篇文章:网站自动化测试系统—数据驱动测试

 

2.         代码覆盖率信息,代码覆盖率告诉测试团队有哪些产品代码没有被覆盖到,没有覆盖到的产品代码意味着有一些用户场景我们没有考虑到,或者说测试覆盖面上有一些漏洞(Testing Hole)。如果是从VSTT用户界面上执行测试用例的话,VSTT已经自动集成了收集代码覆盖率的功能,做法请参看我的文章软件自动化测试—代码覆盖率。在这篇文章里,我将告诉你如何使用命令行做到收集代码覆盖率。

至少有两种方法将收集代码覆盖率的功能整合到自动化测试系统当中,一种是通过直接编辑.testrunconfig文件,这也是我们在VSTT用户界面操作时,VSTT 背地里帮我们做的事情,使用.testrunconfig文件的方法请参考文章执行测试用例

另外一种方法,是更深入的分解,实际上Visual Studio收集代码覆盖率是通过一个叫做VsPerfMon.exe的程序来收集的,这个程序位于C:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Performance Tools(假设VSTT安装在C盘)。当你按照软件自动化测试—代码覆盖率里介绍的步骤执行自动化测试的时候,VSTT背地里做了下面几件事情:

1.         注入用于统计代码覆盖率的代码(instrument),注入的代码在文章软件自动化测试—代码覆盖率里已经有过讲解,这里不再说了。代码注入是通过vsinstr.exe来实现的,下面是使用它进行代码注入最简化的命令(接受任何.Net程序—即.dll.exe文件,是否支持原生C++程序我还没有尝试过):

 

Vsinstr.exe –coverage image.dll

 

Vsinstr.exe除了在程序里面注入代码以外,还要修改程序的符号文件(.pdb文件),之所以这样做,是因为程序被注入代码以后,就不和注入前的符号文件匹配了。使用不匹配的符号文件,将会导致后面浏览代码覆盖率结果时,我们没有办法查看详细的代码覆盖信息即哪些行的代码被覆盖了,哪些代码没有覆盖。符号文件的作用请参考文章Visual Studio调试之符号文件

 

如果要给网站 bin文件夹里面所有的程序执行代码注入操作的话,可以使用下面这个简单的命令来完成:

 

for %f in (*.dll) do vsinstr.exe –nowarn –coverage “%f”

 

for命令的用法,请查看Windows帮助文件里面的批处理一章;%f使用引号括起来是避免%f代码的文件路径包含空格的情况;-nowarn这个参数告诉vsinstr不要输出警告信息了,因为懒得看, :)

 

2.         代码注入完成以后,启动vsperfmon.exe。在整个执行测试用例的过程中,vsperfmon.exe会在后台持续运行,收集代码覆盖率信息。你可能会奇怪,这个程序的名字怎么叫做perfmon?而不是使用什么covermon之类的名字,这是因为vsperfmon.exe本来就是用来做性能测试的,只不过是兼职收集代码覆盖率罢了。

 

启动vsperfmon.exe的命令很简单:

vsperfmon.exe /START:COVERAGE /OUTPUT:result.coverage /CS

 

上面的参数解释一下:

参数

说明

/START:COVERAGE

告诉vsperfmon进行代码覆盖率的收集。

/OUTPUT

保存结果的文件路径,可以是绝对路径或者相对路径,最好将后缀名设置为.coverage,这样你可以直接通过资源管理器里面双击在Visual studio中打开这个文件。

/CS

CSCrossSession的简写。

Session的意思有必要解释一下,Windows Windows 2000以后是一个多用户,多任务的操作系统(不知道NT是不是)。而Windows 95/98/Me不是多用户多任务操作系统,它们只是单用户多任务操作系统。多用户的意思是多个用户可以同时登录同一台主机(通过远程登录系统,mstsc.exe),操作系统会在这多个同时进行独立操作的用户当中执行有效的进程分离。虽然你可以在Windows 95/98/Me设置多个用户,但是这多个用户不能同时登录同一台机器,必须要等另外一个用户注销(LogOff)才能登录这台机器。

 

每个用户登录到Windows操作系统时,WindowsSession(会话)的概念来描述它,一个用户可以有多个Session,例如这个用户可以从物理上直接登录主机,这个Session叫做Console Session;这个用户同时也可以通过远程登录来操作这台主机,这又是另外一个Session

 

之所以要在这里花很大的篇幅去描述Session,是因为如果我们在IIS里面启动网站时,IIS的应用程序池(Application Pool)需要你指定一个用户用于访问数据库、文件系统等资源,这个会话(Session)不会使用控制台会话(Console Session),因此一般来说,即使IIS的应用程序池使用的用户与当前执行测试用例的用户是同一个用户,也是在使用不同的会话。

 

Windows VistaWindows Server 2008以后,大部分Windows服务(当然也包括IIS提供的W3C服务)都是在第0会话(Session 0)当中运行,目的是为了更好地将Windows服务与其他进程分隔开来。而第一个登录Windows VistaWindows Server 2008的用户的会话标识号是1,而不象以前那样是0了。如下图所示:

 

Vista之前,Windows服务(比如运行Asp.Net网站的IISW3C服务)和普通用户的进程(比如vsperfmon.exe)是运行在同一个会话里,两个进程之间交流消息只要用SendMessage或者PostMessage这个API就可以了。

 

但是在Vista之后,由于服务进程和普通用户进程不是在同一个会话里,所以就需要用命名管道(Named Pipeline)等IPC机制来执行交互了。/CS选项就是告诉vsperfmon.exe关注在其他会话里执行的进程的代码覆盖率信息。

 

3.         当所有的测试用例都执行完毕以后,VSTT关闭被测试的进程。因为在收集代码覆盖率信息时,vsperfmon是和被统计的进程直接进行交互的;在保存覆盖率信息时,它需要等被收集的进程关闭以后,才能执行保存操作。如果测试时,你的网站是运行在IIS里的,你需要使用下面的命令关闭IIS

 

iisreset /stop

(启动iis的命令时iisreset /start

 

如果你没有安装IIS,但是你会发现在VSTS直接按下F5运行网站时,网站照样能运行,那是因为VSTS自带了一个支持Asp.NetWeb服务器WebDev.WebServer.EXE。这个程序保存在文件夹C:\Program Files\Common Files\microsoft shared\DevServer\9.0(假设你的系统盘是C,并且安装的是VSTS 2008版本)里面。

 

当你在VSTS里面运行网站的时候,Visual Studio采用下面的命令启动网站:

Webdev.webserver /path:<网站的物理路径> /port:<网站的端口> /vpath:/

 

如果是使用webdev.webserver运行网站的话,在命令行关闭这个程序的命令是(实际上是干掉这个程序):

taskkill /im WebDev.WebServer.EXE

 

4.          VSTT执行下面的命令关闭vsperfmon.exevsperfmon.exe将搜集到的代码覆盖率保存到指定的文件当中。

 

vsperfmon.exe /shutdown

 

备注:vsperfmon.exe默认情况下只能收集同一个用户运行的进程的代码覆盖率信息,如果你是将asp.net网站放在iis里面进行测试,默认情况下,运行这个网站的应用程序池(application pool)的用户是NetworkService,这种情况下,要么用vsperfmon.exe/USER选项指定NetworkService这个用户。要么将应用程序池的用户改成执行vsperfmon.exe的那个用户。

基本上一个测试自动化系统讲的差不多了,下一篇讲如何复用现有的自动化测试代码自动生成测试用例。

未完待续……


本文转自 donjuan 博客园博客,原文链接: http://www.cnblogs.com/killmyday/archive/2010/04/06/1705494.html  ,如需转载请自行联系原作者


相关文章
|
14天前
|
测试技术 C语言
网站压力测试工具Siege图文详解
网站压力测试工具Siege图文详解
23 0
|
29天前
|
设计模式 安全 测试技术
【软件设计师备考 专题 】系统实施:程序设计和系统测试
【软件设计师备考 专题 】系统实施:程序设计和系统测试
64 0
|
1月前
|
运维 Prometheus 监控
构建高效自动化运维系统的关键策略
【2月更文挑战第30天】随着云计算和微服务架构的兴起,现代IT运维环境变得愈加复杂多变。为保持业务连续性、提高响应速度并降低成本,企业亟需构建一个高效的自动化运维系统。本文将深入探讨自动化运维系统构建过程中的关键策略,包括工具和技术选型、流程优化、监控与告警体系搭建以及持续集成/持续部署(CI/CD)实践,旨在为读者提供一个清晰的构建蓝图和实用的实施建议。
|
4天前
|
消息中间件 网络协议 物联网
如何入门做物联网系统压测?
【4月更文挑战第18天】物联网系统在架构、网络模式、通信协议等方面与传统的互联网系统有所区别。因此,传统的性能测试方法不能直接套用到物联网系统中。
59 13
如何入门做物联网系统压测?
|
30天前
|
jenkins 测试技术 持续交付
现代软件测试中的自动化工具与挑战
随着软件开发领域的不断发展,自动化测试工具在测试过程中扮演着越来越重要的角色。本文将探讨现代软件测试中自动化工具的应用及面临的挑战,旨在帮助开发人员和测试人员更好地理解和应对自动化测试中的问题。
|
1月前
|
人工智能 运维 监控
构建高性能微服务架构:现代后端开发的挑战与策略构建高效自动化运维系统的关键策略
【2月更文挑战第30天】 随着企业应用的复杂性增加,传统的单体应用架构已经难以满足快速迭代和高可用性的需求。微服务架构作为解决方案,以其服务的细粒度、独立性和弹性而受到青睐。本文将深入探讨如何构建一个高性能的微服务系统,包括关键的设计原则、常用的技术栈选择以及性能优化的最佳实践。我们将分析微服务在处理分布式事务、数据一致性以及服务发现等方面的挑战,并提出相应的解决策略。通过实例分析和案例研究,我们的目标是为后端开发人员提供一套实用的指南,帮助他们构建出既能快速响应市场变化,又能保持高效率和稳定性的微服务系统。 【2月更文挑战第30天】随着信息技术的飞速发展,企业对于信息系统的稳定性和效率要求
|
14天前
|
敏捷开发 监控 测试技术
深入探索软件测试中的自动化边界
【4月更文挑战第10天】 在现代软件开发过程中,自动化测试已成为提升效率、确保质量的关键手段。然而,随着技术的不断进步和项目需求的多样化,确定自动化的合理边界成为测试工程师面临的重要问题。本文将探讨如何界定自动化测试的有效范围,包括成本效益分析、风险评估与技术选型等方面,并提出一种基于风险和回报权衡的自动化测试策略。
11 0
|
14天前
|
测试技术 Linux Apache
网站压力测试工具webbench图文详解
网站压力测试工具webbench图文详解
11 0
|
16天前
|
Web App开发 搜索推荐 测试技术
网站速度测试
【4月更文挑战第8天】网站速度测试
12 2
|
16天前
|
测试技术
深入理解软件测试中的自动化边界
【4月更文挑战第7天】 在追求快速交付和质量保证的双重压力下,软件测试领域正经历着从手工到自动化的转变。本文旨在探讨自动化测试的有效边界,即哪些场景适合自动化,以及如何界定这些边界以优化测试策略。通过对自动化测试优势、挑战及适用性的分析,文章为读者提供了一个清晰的框架,用于评估和实施自动化测试。

热门文章

最新文章