日历
| |||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | ||||||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 | |||
| 12 | 13 | 14 | 15 | 16 | 17 | 18 | |||
| 19 | 20 | 21 | 22 | 23 | 24 | 25 | |||
| 26 | 27 | 28 | 29 | 30 | 31 | ||||
搜索标题
最新来客
音乐欣赏
统计信息
- 访问量: 330
- 日志数: 6
- 建立时间: 2007-12-31
- 更新时间: 2008-02-15
RSS订阅
我的最新日志
-
搭建TCL测试环境
2008-2-15
TCL搭建测试环境第一步：
获取TCL8.3的安装包并进行安装（安装时一定要选取lib库）
第二步：
利用VC建立Win32 Console Application工程,工程名为Test
第三步：
向工程里添加被测代码 *.h和*.cpp
第四步：
添加TCL扩展指令代码
#include "stdafx.h"
#include "CounterTest.h"
#include "tcl.h"
#include "test.h"
int TclEx_Instrution(ClientData clientData,Tcl_Interp * interp,int argc, char* argv[])
{
return TCL_OK;
}
第六步：
定义TCL解释器：在Test.Cpp中定义解释器
//定义解释器
Tcl_Interp* MyInterp;
第七步：
创建并初始化TCL解释器
//创建tcl解释器
MyInterp = Tcl_CreateInterp();
//初始化tcl解释器
Tcl_Inin(MyInterp);
第八步：
向解释器注册扩展指令（自定义的外部TCL扩展指令）
Tcl_CreateCommand(MyInterp,"Instrution",TclEx_Counter,NULL,NULL);
第九步：
执行外部TCL脚本（通过函数Tcl_EvalFile()执行TCL脚本）
int rCode;
char sscrīpt[255];
//CString sscrīpt;
while(1)
{
//通过嵌入集成测试框架的Tcl解释器MyInterp，运行外部传入的tcl脚本
printf("请输入要执行的TCL脚本文件名:\n");
scanf("%s",&sscrīpt);
rCode = Tcl_EvalFile(MyInterp,(char *)sscrīpt );
if (TCL_OK != rCode )
{
printf("There are errors in your Tcl File\n");
}
else
{
printf("Testing Succeed!\n");
}
第十步：
添加Tcl头文件和库文件，并设置相应的头文件和库文件的路径
在VC下[Project]->[Add To Project]->[File]菜单中添加tcl.h和tcl.lib
在VC[Tool]->[Option]->[Directories]菜单中分别设置头文件和库文件的路径
第十步：
实现扩展指令
扩展指令的编写思路如下：
第一步：
检查参数个数
第二步：
将参数分别解析出来，赋值给传入的参数和预期的输出结果
第三步：
调用被测函数
第四步：
进行结果比较，输出比较结果
好了，大功告成。TCL测试框架就搭建好了，运行一下，试试！
-
测试工程师的十二最
2008-2-08
测试工程师最开心的事:发现了一个很严重的bug,特别是那种隐藏很深,逻辑性的错误.偶第一次发现这种问题的时候,听到上司和开发人员的表扬时,高兴的就想扭pp.不过现在慢慢矜持些了,呵呵.
测试工程师最提心吊胆的事:版本release出去后,客户发现了很多或很严重的bug.经过紧张的系统测试之后,好不容易可以轻松一下了,却又陷入了每天担心正在做验收或使用的客户一封邮件或一个电话说产品有问题.碰到好些的老板还会比较乐观的看这样的问题,最惨的就是有些人一顿臭骂,之前的辛苦,加班全部都给抹杀了.
测试工程师最憎恨听到的话: "为什么这个bug没有在测试的发现呢?"这句话经常是客户发现bug后,老板对测试人员的质问.当然这里排除那种很明显的错误.其实谁都知道bug是不可能全部发现的,这句话其实也是客户对大头,大头对小兵一级一级问下来的.除了希望测试人员警惕之外,还有更多的是一种"踢猫"的行为.对于这句话,偶第一次听到这句话的反映是"我们怎么可能发现所有的bug呢",后来变成"制造bug的人不是我们,是开发",到现在的"让我查查我的日志,问问开发这个bug的原因,为什么我们会没有找到,下次我们会怎样"的回复.
测试工程师最郁闷的事: "刚才那个版本打包打错了,你们要重测".新版本来了,马上投入紧张的测试,希望能够多找些bug.没想到辛苦了可能大半天,开发人员说打包打错了,你重测吧.这种情况虽然可以通过规范流程之类的办法控制发生的机率,但人总会犯错,多少而已.碰到这样,你除了提醒开发部门下次注意,你除了重测没有太多办法.
测试工程师最不想面对的事:在测试晚期或最新的版本里发现了以前一直存在的问题,特别是当问题很严重时决定到底报不报bug.报吗,开发人员肯定会问以前有没有这个问题,不报吗,客户发现更惨.毕竟客户或老板的责备比开发部门或主管的责备轻许多,最后还是会报到bug库里的.
测试工程师最不想做的事:申请版本推迟发布.由于在版本发现了太多的问题,觉得产品不能达到发布的，建议公司推迟发布产品.这时虽然大家都知道产品有问题,尽管你自己也不希望这样,但谁都觉得你是一个制造麻烦的人,毕竟市场的压力很大呀.
测试工程师最丢人的事:辛苦的发现了一个bug,居然是该配的参数没有配等一些自己的失误造成的.有些该注意的地方居然测试时忘了,找出的问题给开发人员一顿臭扁,无比丢人啦.
测试工程师最怕的事:一天,甚至几天都没有发现一个bug!经过一段时间的bug高峰期后,有段时间会发现bug数量的减少,最可怕的就是一天都没有发现一个bug.偶有时会难过的吃饭都没心情.搞得偶的开发朋友说了一句最让人吐血的话:"要不要我在代码里放几个bug给你呀,hoho"
测试工程师最伤心的事:每年的调薪,发bonus或发股票时,测试工程师总比开发工程师少.偶有一同事在调薪的第二天就申请转开发,说测试太没前途了.
测试工程师最有力的保护方法:把你认为是bug的问题都提交到一个正式的,可以追踪的地方(一般来说是bug库).有时总会碰到一些很小的或是很难判断的问题,犹豫一定是否要报,特别是一些UI的问题.有时问开发人员,他们可能会轻描淡写的回复你导致你没有report它.但多年的经验一定要报,了解bug流程走向的人都知道,后面还有人verify,还有开发经理判断,如果不是bug,自然他们会回复,会写明原因.说白了,出了问题也不是你的事情.当然一开始经验不足时会收到一些白眼球,但慢慢经验多了,对系统熟悉了,自然这种情况会少些.人也可以从一些问题中发现自己的弱点.但如果不报,那天客户提出来,你除了懊悔还要面对指责,严重的炒鱿鱼.
测试工程师最任重道远的事:测试驱动开发.碰到这种开发模式的项目,既是测试扬眉吐气的机会,也是可能会陷你于深渊的恶潭.你就必须打起十二分的精神.等于你在引导开发,有什么问题一定要提出来,否则你就等着被盲目的牵着鼻子走了.
测试工程师最期待的事:测试能够越来越受重视,测试工程师的考核越来越合理.
-
SQLSERVER中创建存储过程实例及讲解
2008-1-15
SQLSERVER中创建存储过程实例及讲解-(1)创建存储过程和调用存储过程:
创建语法:
CREATE PROCEDURE<过程名>[:版本号]
[@<参数名><参数类型>[=<默认值>][OUTPUT]……]
[WITH RECOMPILE|ENCRYPTION|RECOMPILE,ENCRYPTION]
AS
其中:版本号是可选的整数,它用于将有相同名字的存储过程编为不同的组.在执行时可选版本,但创建时一次只能创建一个版本;OUTPUT选项用于给调用者的值;RECOMPILE为重编译选项.它要求每次执行都要进行对过程重编译和优化,并创建新的查询计划;ENCYPTION为加密选项;
例如:建立并调用一个不带参数的存储过程如下:
CREATE PROCEDURE 全部学生
AS SELECT * FROM 学生
GO
EXEC 全部学生
建立并调用一个带参数的存储过程如下:
CREATE PROCEDURE 学生查询1
@SNAME VARCHAR(8),@SDEPT VARCHAR(20)
AS SELECT * FROM 学生 WHERE 姓名=@SNAME AND 所在系=@SDEPT
GO
EXEC 学生查询1 '张三','计算机系'
或: EXEC 学生查询1 @SNAME='张三',@SDEPT='计算机系'
(2)删除存储过程:
DROP PROCEDURE<存储过程名组> -
Robot进行数据库的并发测试
2008-1-15
Robot进行数据库的并发测试来源：51testing第一步：创建演示程序：打开SQL SERVER查询分析器，在SQL SERVER测试数据库中执行下列脚本（脚本执行操作：创建表testtable，并插入一条记录；创建存储过程test）：
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[Test]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [dbo].[Test]
GO
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[testtable]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[testtable]
GO
CREATE TABLE [dbo].[testtable] (
[testid] [int] NULL ,
[counts] [int] NULL
) ON [PRIMARY]
GO
insert into testtable (testid,counts) values (1,0)
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_NULLS ON
GO
CREATE Procedure dbo.Test
as
declare @count int
begin tran TEST
select @count=counts from testtable where testid=1
update testtable set counts=@count+1
if (@@error >0) begin
rollback tran TEST
end else begin
commit tran TEST
end
GO
SET QUOTED_IDENTIFIER OFF
GO
SET ANSI_NULLS ON
GO
第二步：创建测试脚本：在Robot中新建VU脚本，输入以下内容：
#include
{
push Timeout_scale = 200; /* Set timeouts to 200% of maximum response time */
push Think_def = "LR";
Min_tmout = 120000; /* Set minimum Timeout_val to 2 minutes */
push Timeout_val = Min_tmout;
ser=sqlconnect("server","sa","888","192.168.0.99","sqlserver");
set Server_connection = ser;
push Think_avg = 0;
sync_point "logon";
sqlexec ["sql_1000"] "testdb..test";
sqldisconnect (ser);
}
说明：
ser=sqlconnect("server","sa","888","192.168.0.99","sqlserver")
sa为数据库用户名，888为sa密码，192.168.0.99数据库IP地址
以上三项按实际的测试数据库设置更改，其他两项不用修改
sqlexec ["sql_1000"] "testdb..test"
testdb为新建存储过程test所在的数据库，按实际的数据库修改
第三步：执行测试：运行上一步创建的脚本（运行时自动创建Suite），在Run Suite窗口中的“Number of users”上输入20。运行完脚本，打开数据库查看counts的数值。把counts值改为零多次运行脚本，观察每次运行后counts的结果。
测试说明
（1）、测试示例程序的目的是，存储过程test每执行一次，表testtable中的counts字段增加
（2）、第三步的测试可以发现每次执行后counts结果并不相同，而且不等于20，这说明这个程序是在并发时是问题的。
（3）、将存储过程中的select @count=counts from testtable where testid=1修改为select @count=counts from test
编辑：qiuqiu 责任编辑：ppzhuhui -
UML
2008-1-11
统一建模语言UML
软件工程领域在1995年至1997年取得了前所未有的进展,其成果超过软件工程领域过去15年来的成就总和。其中最重要的、具有划时代重大意义的成果之一就是统一建模语言(UML:Unified Modeling Language)的出现。
在世界范围内,至少在近10年内,UML将是面向对象技术领域内占主导地位的标准建模语言。采用UML作为我国统一的建模语言是完全必要的:首先,过去数十种面向对象的建模语言都是相互独立的,而UML可以消除一些潜在的不必要的差异,以免用户混淆;其次,通过统一语义和符号表示,能够稳定我国的面向对象技术市场,使项目根植于一个成熟的标准建模语言,从而可以大大拓宽所研制与开发的软件系统的适用范围,并大大提高其灵活程度。
统一建模语言（UML）是用来对软件密集系统进行描述、构造、视化和文档编制的一种语言。
首先，也是最重要的一点，统一建模语言融合了Booch、OMT和OOSE方法中的概念，它是可以被上述及其他方法的使用者广泛采用的一门简单、一致、通用的建模语言。
其次，统一建模语言扩展了现有方法的应用范围。特别值得一提的是，UML的开发者们把并行分布式系统的建模作为UML的设计目标，也就是说，UML具有处理这类问题的能力。
第三，统一建模语言是标准的建模语言，而不是一个标准的开发流程。虽然UML的应用必然以系统的开发流程为背景，但根据我们的经验，不同的组织，不同的应用领域需要不同的开发过程。举个例子来说，开发错综复杂的软件是非常有趣的工作，但开发这种软件与构造严格实时的航空电子系统是大不一样的，后者是性命攸关的大事。因此我们首先把精力集中在设计通用的元模型上（统一不同方法的语义），其次是建立通用的表示法（提供对这些语义的形象化的表达）。虽然UML的开发者们将继续倡导从用例驱动到体系结构为中心最后反复改进、不断添加的软件开发过程，但实际上设计标准的开发流程并不是非常必要的。
UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。
面向对象技术和UML的发展过程可用上图来表示,标准建模语言的出现是其重要成果。在美国,截止1996年10月,UML获得了工业界、科技界和应用界的广泛支持,已有700多个公司表示支持采用UML作为建模语言。1996年底,UML已稳占面向对象技术市场的85%,成为可视化建模语言事实上的工业标准。1997年11月17日,OMG采纳UML 1.1作为基于面向对象技术的标准建模语言。UML代表了面向对象方法的软件开发技术的发展方向,具有巨大的市场前景,也具有重大的经济价值和国防价值。
标准建模语言UML的内容
首先,UML融合了Booch、OMT和OOSE方法中的基本概念,而且这些基本概念与其他面向对象技术中的基本概念大多相同,因而,UML必然成为这些方法以及其他方法的使用者乐于采用的一种简单一致的建模语言;其次,UML不仅仅是上述方法的简单汇合,而是在这些方法的基础上广泛征求意见,集众家之长,几经修改而完成的,UML扩展了现有方法的应用范围;第三,UML是标准的建模语言,而不是标准的开发过程。尽管UML的应用必然以系统的开发过程为背景,但由于不同的组织和不同的应用领域,需要采取不同的开发过程。
作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分。
(1) UML语义 描述基于UML的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的最佳表达方法所造成的影响。此外UML还支持对元模型的扩展定义。
(2) UML表示法 定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。
标准建模语言UML的重要内容可以由下列五类图(共9种图形)来定义:
·第一类是用例图,从用户角度描述系统功能,并指出各功能的操作者。
·第二类是静态图(Static diagram),包括类图、对象图和包图。其中类图描述系统中类的静态结构。不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)。类图描述的是一种静态关系,在系统的整个生命周期都是有效的。对象图是类图的实例,几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。一个对象图是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统某一时间段存在。包由包或类组成,表示包与包之间的关系。包图用于描述系统的分层结构。
·第三类是行为图(behavīor diagram),描述系统的动态模型和组成对象间的交互关系。其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常,状态图是对类图的补充。在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。
·第四类是交互图(Interactive diagram),描述对象间的交互关系。其中顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系。除显示信息交换外,合作图还显示对象以及它们之间的关系。如果强调时间和顺序,则使用顺序图;如果强调上下级关系,则选择合作图。这两种图合称为交互图。
·第五类是实现图( Implementation diagram )。其中构件图描述代码部件的物理结构及各部件之间的依赖关系。一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。它包含逻辑类或实现类的有关信息。部件图有助于分析和理解部件之间的相互影响程度。
配置图定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的依赖性。在节点内部,放置可执行部件和对象以显示节点跟可执行软件单元的对应关系。
从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求;其次根据需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的行为。其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包含包)、对象图、组件图和配置图等五个图形,是标准建模语言UML的静态建模机制。其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言UML的动态建模机制。因此,标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。