在SQL Server2005中查找包含特定字符的存储过程

select p.name, m.definition
from sys.procedures p inner join sys.sql_modules m
on p.object_id = m.object_id
where m.definition like ‘%特定字符%’

测试的过程中在数据库里面找到一张表,还知道一个GET这张表的数据的存储过程,想找一下有没有其他操作这张表的存储过程要怎么办呢?运行上面的存储过程就可以了。例如说某张数据表的名字是“UserRankStatus”,那么就用“UserRankStatus”替换了上面的“特定字符”就好了。这个存储过程是偶然在网上找到,出处是“怡红公子”,也就是我们公司的DBA。世界真小,囧……

用SC(server control)创建服务的时候要注意binpath=后面的空格

这个问题以前就遇到过,今天又碰到了,很有必要记录下来,Windows Server有一个SC(server control)的命令,可以实现创建服务,改变服务状态等功能,但是在创建服务的时候,有一个参数是binpath,顾名思义就是可执行文件的路径了。我一开始这样配置:

C:\Users\junhuachen>sc create “SOA” binpath=”D:\MagusTestEnv\SOA\MySpace.PlatformServices.WindowsService.exe”
Continue reading “用SC(server control)创建服务的时候要注意binpath=后面的空格”

测试用例的重用

跟测试工程师打交道最多的可能就是测试用例了,先设计出一些测试用例,然后这些测试用例要经过评审,之后要执行这些测试用例,完了以后还有可能需要对这些测试用例进行更新。测试用例的重用是一个很有必要的活动。那怎么重用呢?很多人可能第一时间想到了一些测试管理工具能帮上忙,例如Quality Center,Test Link;又或者是一些保存测试用例的工具,例如Word,Excel。

不过这些东西真的能帮助我们重用测试用例么?我想未必。测试用例的重用,应该是测试用例里面的设计思想的重用,而不是具体某个测试用例的,因为对于功能测试的测试用例来说,大多数的测试用例都跟某个具体的被测应用有想到大的关联性,例如要测试一个博客编辑器,对于MySpace的博客编辑器和facebook的博客编辑器来说,它们的主要功能是相似的,都有发表博客,编辑博客,修改博客等……但是由于这是两个不同公司的产品,他们的具体功能或者UI是完全不一样的,所以拿到的两套测试用例,也应该是不一样的。如果分别提取出测试用例的核心思想(就是那些可以重用的部分),应该能看到很多的共同点,或许会有这么一条共同的用例思想。
Continue reading “测试用例的重用”

ASP.NET中配置文件web.config的优先级

web.config是ASP.NET的默认配置文件名,一般来说每个ASP.NET站点的根目录都会有一个web.config,因为在VS里面建立站点的时候会一同生成的。其实在一个站点的不同的目录中可以各自有各自的web.config文件,如果一个站点中的不同的目录都有web.config,那么他们之间的关系是什么?哪个web.config的优先级会高呢?顺序如下:
(1) 如果在当前页面所在目录下存在web.config 文件,查看是否存在所要查找的结点名称,如果存在返回结果并停止查找。
(2) 如果当前页面所在目录下不存在web.config 文件或者web.config 文件中不存在该结点名,则查找它的上级目录,直到网站的根目录。
Continue reading “ASP.NET中配置文件web.config的优先级”

LINQ查询操作中的类型关系

最近在测试中,想尝试用LINQ来简化一下测试的代码,初步学习了一下LINQ,个人感觉需要认真理解查询操作中的类型关系,在阅读MSDN文档后写下了本文,主要参考MSDN讲述理解查询操作中的类型关系,还有对C# 3.0的一个新的关键字var的理解。

首先有一段LINQ查询表达式的代码

List ret = AccountGateway.AccountLiteProvider.GetOnlineUsers(1, 10000);
var query = from onlineUser in ret
			where (onlineUser.UserId > 1301000200)
			select onlineUser.UserId;
foreach(int iUser in query)
{
	Console.WriteLine(iUser.ToString());
}

Continue reading “LINQ查询操作中的类型关系”

用route命令修改路由表来阻止本机访问特定IP的主机

场景:在本地有一台代理服务器,这台服务器会定时检查部署在远程的服务器的状态,如果检测到某台服务器是工作异常的,那么该台服务器就会被移除到生产服务器列表;如果过了一段时间,程序发现原来工作异常的服务器已经恢复正常,那么该服务器就会被重新添加到生产服务器列表中。那些被检测服务器的IP是以配置文件的方式记录。

测试的一个关键点:某台服务器Down了以后被代理服务器剔除出生产列表,如果这个台服务器恢复正常以后,代理服务器上的监控能否检测到该服务器已恢复正常,并且把该服务器添加到生产服务器列表中。

限制:1. 我没有远程服务器的管理员权限,甚至无法登陆到那些远程服务器;2. 没有处于测试状态的服务器,全部服务器都是线上生产服务器。
Continue reading “用route命令修改路由表来阻止本机访问特定IP的主机”

自动化测试中需要避免“诡异”的测试脚本

什么是“诡异”的测试脚本呢?就是这个脚本在多次运行的情况下,测试结果并非每次都是一致,例如运行10次,有9次是通过的,有1次是失败的,那么这个测试究竟算是通过呢,还是失败呢?答案是:It depends

在某些情况下,那一次失败,的确抓住了程序的某个BUG。原因可能是:

  • 程序在运行一段时间后会出错
  • 程序会出错,但错误不是每次都发生
  • 在某些特殊输入下把错误暴露出来

但是在某些情况下,那1次失败的测试其实只是告诉测试的人,你写了一个“诡异”的测试脚本,实现了一个诡异的测试(Flakey Test)。不幸的是,导致一个自动化测试的行为变得诡异的原因实在太多太多。下面是一些常见的:

  • 竞争条件
  • 测试数据选择不当
  • 测试的前置条件不受控

当发现一个诡异的自动化测试脚本,必须要下决心去改掉它:

  • 使用一些常见有效的用例设计模式,例如“准备,执行,断言(Arrange, Act, Assert)”
  • 使用MOCK技术

总之,当出现一个诡异的测试(Flakey Test)的时候,总是很郁闷的,但是为了以后不要遇到更大的郁闷,我们要尽早发现并且改掉那些诡异的测试。