天行健,君子当自强不息

You have been recommended to join P1

2011-04-20T18:52:00.001+08:00

"Ricky" 推荐您申请P1会籍。

P1是一个专为中国精英人士打造的社交网络平台。

由于我们每天只接受数量极为有限的一批申请人加入，

您需要在P1上认识至少 5 名会员方可加入。

该推荐信仅供私人使用，自发送之日起一个月内有效。

"Ricky" recommends you to apply for a P1 membership.

P1 is a private social network for exceptional members of society.

However, membership is not for everyone, it is very scarce and we only accept a handful people a day. Only if you can show that you have 5 existing connections with our members you will be able to join..

This referral is personal and valid for one month only.

如果以上按钮无法显示，请点击以下链接：If the above button doesn't display, please use link below:

http://www.p1.cn/reg/membership.php?ac=recommend&inviter=998228

这封推荐信是由"Ricky"寄出，如果您不想再收到此类邮件，请点击这里退订。

This recommendation was sent to you by "Ricky"

If you do not wish to receive this email in the future please click here to unsubscribe.

天行健,君子当自强不息

2007-03-01T15:46:00.000+08:00

天行健的博客已经正式搬家, 新的博客基于WordPress2.1.1构建,空间由www.phpnet.us免费提供.
域名是:www.rickyzhu.com

新博客的目标:
创建国内知名的个人测试博客.结交广大热爱测试,有志于从事测试的朋友.

几大国外免费主机托管

2007-02-22T16:57:00.000+08:00

我以为可以彻底抛开和放弃Blogger了,因为之前找到了几家比较好的国外免费主机托管网站, 但是试用这几天给我的第一感受就是一个字: 免费的东西就是不稳定.

前后试用了N多个,包括kingofhosts.com, my-php.net, prehost, awarespace, 9999mb等等,发现所有的免费托管格式几乎千篇一律,引用chinalong兄弟的一句话"不知道他们在搞什么名堂".

连注册的程序几乎都一摸一样,都说中国人喜欢模仿,看来也不完全是这样啊, 另外, 对于网站的管理大都基于统一的模式,而且基本都有快速安装工具,可以快速建立基于WP或者其他主流论坛的能力.这的确可以省去建站所花费的时间,而且支持的空间也超级大,从几十G到几百G多少不一,另外,对于二级域名和顶级域名的支持也是出奇的一致. 真的是让我这样的新手不知如何取舍.

可惜最致命的是对于免费用户的支持都是有限的,而且稳定性没有保证,反反复复折腾吧. 郁闷.看来要想得到稳定可靠的服务和支持还要付出真金白银呐.

真要好好考虑考虑了.

--end

搬家完毕

2007-02-21T10:33:00.000+08:00

本博客已经搬家,请访问基于WordPress的站点http://www.rickyzhu.com查看最新的文章和系列.

另外,感谢这个搬家插件,使我的所有文章都能顺利搬家到新的站点.

--以此纪念在blogspot的三个月--

--end--

基于WP架构的个人网站已经建立

2007-02-19T21:13:00.000+08:00

今天下午,花费了三个小时左右,基于WordPress架构的个人网站rickyzhu.com已经建立完毕.

现在打算把基于Blogger的这个博客移植到www.rickyzhu.com去,发现WP提供很多其他blog站点的导入功能,其中就包括blogger,不过好像目前只支持旧版本的blogger,也就是用blogger账号,而非google帐号登陆的blogger,看来我的这个站点要搬家还要另外想想办法了....

打算把目前这个站点搬过去之后,年后就开始在新的网站开始经营了,欢迎新老朋友过去捧场.个人站点的空间是kingofhosts免费提供托管,由WordPress提供技术架构的.

我申请域名的时候用的是rickyzhu.com,好像rickyzhu.com已经和rickyzhu.kingofhosts.com绑定,并且由kingofhosts提供空间托管,不过www.rickyzhu.com好像指向的是另外一个网站,不知道为什么,在kingofhosts里面好像提供修改的地方,不过已经修改不过了,哪位高手指点一下? 另外,Kingofhosts是一个国外的网站,可能访问的时候时好时坏,不一定有国内付费的空间那么稳定,没办法,穷啊,暂时只能这样了,而且kingofhosts也是提供了一个很简单的页面底部的广告.

--end

新域名得到启用

2007-02-19T12:33:00.000+08:00

Google Blogger的免费域名绑定服务被封之后，我一直在寻找可以免费托管或者免费域名绑定的服务，现在最终有了结果，kingofhosts提供这个功能，而且功能非常全面，最重要的是全免费，提供的服务如下：

Features

KingofHosts has industry leading features that will allow you to build a website above and beyond your competitors, take a look at some of them:

~~1,000mb Disk Space~~ 8,000mb disk space (8gb!)
~~10,000mb Bandwidth~~ 50,000mb bandwidth (50gb!).
NO ADVERTISEMENTS on your pages!
FREE subdomain (yourname.KingofHosts.com)
Easy to use WYSIWYG editor
Full FTP Support
PHP 4 Support
~~1 mySQL database~~ 10 mySQL database's
Instant activation
Domain name support
99.9% Uptime
and MORE...

您不妨试试，现在我的新域名

rickyzhu.com
或者
rickyzhu.kingofhosts.com

两者都是可以的，目前在暂时将她们重定向到目前这个Google的博客。

--end

儿子能独自站立了

2007-02-19T11:30:00.000+08:00

小猪猪的成长之路

2007-02-19T11:27:00.000+08:00

大年初二，小猪猪今天已经满九个月了，可以扶着沙发自己独立行走了，回想起小猪猪的成长经历，从第一声啼哭，第一次主动微笑，第一颗牙齿，第一声爸爸... 一幕一幕仿佛就在眼前，这里把小猪猪每个月有代表性的照片排列在这里，以示留念。

九个月

七个月（脸上还有些湿疹）

六个半月（湿疹比较严重）

六个月

四个月

百日留影

三个月

一个月

第一周

--end

LoadRunner性能数据结果分析连载(引言)

2007-02-15T15:52:00.000+08:00

HP Mercury LoadRunner 是一款功能相当强大的性能测试工具,由三个部分构成, VUGen, Controller以及Analysis. 其中VUGen负责进行脚本录制, Controller是一个总控中心,负责场景的配置,监控器的选取和监控,并选择合适的负载生成器进行执行, Analysis是一个分析模块,主要负责所有执行数据的分析以及报告的生成.
之所以说LoadRunner是强大的性能测试工具,主要是因为VUGen支持大概好几十种主流的协议. 因此支持的被测对象相当广泛,另外Analysis也有超强的功能,提供非常丰富的图表,供测试结束之后分析和定位问题.
我使用Mercury LoadRunner有一年左右,2006年6月通过了LoadRunner的SP考试,并于12月底参加了CPC考试,以2分之差失败. 在这一年之内对Controller和Analysis的使用有一些心得和体会,大概能看懂一些主要的分析图表,包括事务相关的一些图表,所以希望作一个总结,对希望学习和了解LoadRunner的朋友有一些帮助. 因为时间有限,所以初步打算以系列的形式发表. 下次打算介绍Analysis提供图表的概述.

--to be continued

Andy Mckee

2007-02-15T14:13:00.000+08:00

好牛的吉他弹奏.

软件测试自动化之实践

2007-02-14T17:29:00.000+08:00

我之前写过几篇原创的关于自动化测试的思考和总结,今天整理资料的时候发现这篇文档,涉及到实施自动化测试的切入,自动化测试的适应范围,自动化测试的环境,自动化测试的开展,甚至自动化测试的风箱评估等等,这篇文档系统的阐述了这些重要内容,给自动化测试的开展提供了一些理论方面的指导,跟我的前面几篇文档有异曲同工之处,可以做为一个补充和参考.

一、概述

软件测试自动化，从计算机这一庞大学科发展至今，最根本的意义是解决手工劳动的复杂性，成为替代某些重复性行为模式的最佳工具。

二、实施软件测试自动化的理由

1. 提高测试效率和降低测试成本

2. 将重复性强的测试由手工转为可以独立开来自动实现的。

3. 实现快速的回归测试，提高新版本发布的速度和质量，尤其是不能适应目前流行的迭代开发，回归测试频度高、工作量大，人工的测试很难对新的迭代版本作出快速评估。

4. 自动测试可以避免，人工测试容易犯的错误：错误测试、漏测试、多测试和重复测试等

5. 典型的应用，例如多用户并发注册、并发交易请求和并发交易应答，这种情况用人工测试几乎是办不到的，而自动测试却很容易。

6. 对于很常用的功能性边界测试测试，人工测试非常耗费时间，而自动测试很快且准确。

可以说，实施测试自动化是软件行业一个不可逆转的趋势，如果在这个领域走在了前列，无论从企业的核心竞争力还是个人的工作技能来说，都有巨大的优越性。

三、软件测试自动化的引入条件

自动化测试能大大降低手工测试工作，但决不能完全取代手工测试。完全的自动化测试只是一个理论上的目标，实际上想要达到 100% 的自动化测试，不仅代价相当昂贵，而且操作上也是几乎不可能实现。一般来说，一个 40-60% 的利用自动化的程度已经是非常好的了，达到这个级别以上将过大的增加测试相关的维护成本。

测试自动化的引入有一定的标准，要经过综合的评估，绝对不能理解成测试工具简单的录制与回放过程。实际上，从实现成熟度来说，自动化测试分五个级别：

级别	说明	优点	缺点	用法
一级	录制和回放	自动化的测试脚本能够被自动的生成，而不需要有任何的编程知识	拥有大量的测试脚本，当需求和应用发生变化时相应的测试脚本也必须被重新录制	当测试的系统不会发生变化时，实现小规模的自动化
二级	录制、编辑和回放	减少脚本的数量和维护的工作	需要一定的编程知识；频繁的变化难于维护	回归测试时，用于被测试的应用有很小的变化
三级	编程和回放	确定了测试脚本的设计，在项目的早期就可以开始自动化的测试	要求测试人员具有很好的软件技能，包括设计、开发	大规模的测试套件被开发、执行和维护的专业自动化测试
四级	数据驱动的测试	能够维护和使用良好的并且有效的模拟真实生活中数据的测试数据	软件开发的技能是基础，并且需要访问相关的测试数据	大规模的测试套件被开发、执行和维护的专业自动化测试
五级	使用动作词的测试自动化	测试用例的设计被从测试工具中分离了出来	需要一个具有工具技能和开发技能的测试团队	专业的测试自动化将技能的使用最优化的结合起来

自动化测试能提高测试效率，快速定位测试软件各版本中的功能与性能缺陷，但不会创造性的发现测试脚本里没有设计的缺陷。测试工具不是人脑，要求测试设计者将测试中各种分支路径的校验点进行定制,没有定制完整，即便事实上出错的地方，测试工具也不会发觉。因此，制订全面、系统的测试设计工作是相当重要的。

自动化测试能提高测试效率，但对于周期短、时间紧迫的项目不宜采用自动化测试。推行自动化测试的前期工作相当庞大，将企业级自动化测试框架应用到一个项目中也要评估其合适性，因此决不能盲目的的应用到任何一个测试项目中，尤其不适合周期短的项目，因为很可能需要大量的测试框架的准备和实施而会被拖跨。

实施测试自动化必须进行多方面的培训，包括测试流程、缺陷管理、人员安排、测试工具使用等。如果测试过程是不合理的，引入自动化测试只会给项目团队带来更大的混乱。

那么应该具备什么样的条件才可以引入自动化测试呢，才可以最大可能的减少引入风险，并能够可持续性的开展下去呢？

第一，从项目规模上来说，没有严格限制。无论项目大小，都需要提高测试效率，希望测试工作标准化，测试流程正规化，测试代码重用化。所以第一要做到的，就是从公司高层开始，直到测试部门的任何一个普通工程师，都要树立实施自动化测试的坚定决心，不能抱着试试看的态度。一般来说，一个这样的软件开发团队可以优先开展自动化测试工作：测试与开发人员比例合适，比如1：3到1：5，开发团队总人数不少于10个。

第二，从公司的产品特征来说，一般开发产品的项目实施自动化测试要比纯项目开发要优越些。但决不是说做纯项目开发不能实施自动化测试，只要软件的开发流程、测试流程、缺陷管理流程规范了，自动化测试自然水到渠成。

第三，从测试人员个人素质和角色分配来说，除了有高层重视外，还应该有个具有良好自动化测试背景和丰富自动化测试经验的测试主管，不仅在技术方面，更重要的是在今后的自动化测试管理位置起着领导的作用。还要有几个出色的开发经验良好的测试人员，当然也可以是开发工程师，负责编写测试脚本、开发测试框架,还有一些测试执行者，他们要对软件产品业务逻辑相当熟练，配合测试设计者完成设计工作，并在执行自动测试时，敏锐的分析和判断软件缺陷。

综合分析上述三个条件，就可以决定是否推行自动化测试；但是为了减少实施风险，还要预测到其他潜在的风险，做好事先解决问题规避风险的思路。

四、对实施自动化测试的风险分析

资金风险，虽然有些项目具备实施自动化测试的条件，但还是要引入自动化测试后组织结构调整等方面的成本估算是很必要的。

自动化测试对软件功能类型的切入点的风险，开发的产品业务和功能是否需要自动化测试？包括白盒自动化测试、功能自动化测试和性能自动化测试。

软件自动化测试切入方式的风险，一定要将自动化测试与手工测试结合起来使用，不合理的规划会造成工作事倍功半。首先，对于自动化测试率的目标开始是 20/80 （20% 的自动化测试和 80% 的手工测试），当这些目标都实现了，再将自动化测试率提高。

时间估算，在评估完前面几项指标后，需要估算实施测试自动化的时间周期，以防止浪费不必要的时间，减少在人员、资金、资源投入上的无端消耗。虽然到测试自动化步入正轨以后，会起到事半功倍的效果，但前期的投入巨大，要全面考虑各种因素，明确实施计划并按计划严格执行，才能最大限度降低风险。

工作流程变更风险，测试团队乃至整个开发组织实施测试自动化，或多或少会因为适应测试工具的工作流程，带来团队的测试流程、开发流程的相应变更，而且，如果变更不善，会引起团队成员的诸多抱怨情绪；所以应该尽量减少这种变更，并克服变更中可能存在的困难。

五、什么条件下使用自动化测试

一般在这样的条件下使用自动化测试

l 具有良好定义的测试策略和测试计划（知道要测试什么，知道什么时候测试）

l 对于自动化测试你拥有一个能够被识别的测试框架和候选者

l 能够确保多个测试运行的构建策略

l 多平台环境需要被测试

l 拥有运行测试的硬件

l 拥有关注在自动化过程上的资源

如下条件下是宜采用手工测试：

l 没有标准的测试过程

l 没有一个测试什么、什么时候测试的清晰的蓝图

l 在一个项目中，测试责任人是一个新人，并且还不是完全的理解方案的功能性和或者设计

l 整个项目在时间的压力下

l 在团队中没有资源或者具有自动化测试技能的人

六、各测试阶段的自动化测试评估

测试阶段	描　　　　　　　述	备　　　　注
单元测试/ 组件测试	这个测试工作通常是开发人员的职责，很多不同的方法能够被使用，比如"测试先行"，它是一个测试框架，开发人员在编写代码前编写不同的单元测试，当测试通过时，代码也被完成了。	通过使用正式的单元测试，不仅能够帮助开发人员产出更加稳定的代码，而且能够是软件的整体质量更加的好。
集成测试	这里的测试工作集中在验证不同的组件之间的集成上。	这种类型的测试通常是被测试系统的更加复杂测试的基础，大量的边缘测试被合并以制造出不同的错误处理测试。
系统测试	这种测试是通过执行用户场景模拟真实用户使用系统，以证明系统具有被期望的功能。	这里不需要进行自动化的测试。安装测试、安全性测试通常是有手工完成的，因为系统的环境是恒定不变的。
其它两种非常重要的测试
回归测试	回归测试实际上是重复已经存在的测试，通常如果是手工完成的化，这种测试只在项目的结尾执行执行一到两次。	这里完全有潜力应用自动化的测试，能够在每次构建完成后执行自动化的回归测试，以验证被测试系统的改变是否影响了系统的其他功能。
性能测试	性能测试包括以下不同测试形式： - 负载测试 - 压力测试 - 并发测试 -.....	使用自动化的测试工具，通过模拟用户的负载实现的高密集度的性能测试。

--end

LoadRunner的工作原理(第二部分)

2007-02-14T15:10:00.001+08:00

LoadRunner Internal Architecture

This Visio 2002 file is based on LR8.0

application servers under test are placed under stress by
driver processes mdrv.exe (the Multi-threaded Driver Process) and r3vuser.exe which emulate application clients such as Internet Explorer web brower. It performs 3 main actions:
1. cci (C pre-compiling) which creaes a file with ci file, and
2. execute using the driver for the protocol technology being tested.
Runs can be invoked to run "silently" by invoking Mdrv.exe from a Windows batch script.
Mdrv can automatically stop loading Vusers because they communicate with Vusers and monitor CPU usage on Windows Load Generator machines.
A separate JVM is instantiated by each Java-based Vuser on Windows-based machines. Java Vusers are not supported on Unix platforms.
virtual Vusers are invoked as groups (logical collection of virtual users running the same script on a specific load generator machine)
by agents (3,900K magentproc.exe) running as a service or as a process
on load generator client machines.
Each machine hosting agents maintains an Execution Log in a .qtp file.
When logging is enabled, the agent also creates within the results folder a sequential log file for each Vuser (segregated by Vuser group).
During execution, this file is displayed in the view > Show Output window on the LoadRunner Controller machine.
Upon a pre-set delay, the Scheduler running on a Controller machine instructs agents (via Windows port 54345 or dynamic Unix port) to initiate test session scenarios. The Controller (wlrun.exe) sends a copy of scenario files along with the request.
Agents are launched by the Remote Agent Dispatcher process (formerly called Remote Command Launcher (RCL)) on each load generator machine.
Each agent refer to scenario (.lrs) definition files to determine which Vuser groups and scripts to run on host machines.
This means the Controller can be started from a DOS batch (.bat) file (preferrably with a short name on a root drive):
- Including the -Run parameter is the same as manually pressing the "Start Scenario" automatically upon invocation. This is not a good idea because you may have to decide about collating the file from a previous run or want to change the output folder.
- This assumes that the system's environment PATH variable was updated to include where LoadRunner is installed.

The Controller is invoked using parameter values within files in the Windows OS folder (WINNT for Windows 2000 and WINDOWS for Windows XP). The Windows folder is used because LoadRunner is designed to have only one instance of Controller running at a time on a machine.
Some defaults you might want to change:
- In the wlrun7.ini file file [output] section, MaxNumberOfOutputMessages= from 10000 to 100000 for long runs. This limits the number of output messages stored in the database.
- MaxOutputUIRowsToShow limits the amount of messages/errors (lines) displayed in the Controller's Output window.
- In the QTWeb.lrp file within the LoadRunner Program Files dat\protocols folder section [Vugen], add entry MaxThreadPerProcess=5 to limit the number of threads managed by each load generator mdrv.exe process.
Values for DefaultScenarioDir, DefaultScriptDir, DefaultResultDir, and [Recent File List] stored in the wlrun5.ini and wlrun7.dft files updated whenever values are changed within the Controller.
The blocks of actions taken by each Vuser are
defined in Vu scripts created using Loadrunner's VuGen.exe. When this program is invoked, it stores in the Windows folder a comparamui.INI file to save under "[LastTablesUsed]" a history of files and [ParamDialogDates] specified using menu option Insert > New Parameter > Dates.
VuGen stores and retrieves a vugen.ini file in the Windows folder. When using Java, enable additional debug options:
When using 8.0 scripts within VuGen 8.1, add to Vugen.ini:
VuGen opens in LR folder template/qtweb default.cfg and script files.
Vu scripts can be coded to use variable values obtained from parameter files external to the script.
I have a lot more on VuGen here
During a run, execution results are stored to a results folder.
Errors are written to the output.mdb MS Access database. See the ASP page I have written to access this database
Within each results folder, a "Log" folder is automatically created to contain a log file for each group. After a run, to view a log file from within the Controller, click then right-click on a group to select "Show Vuser Log".
As a scenario is run, monitors maintain counters locally on each host.
After a run, the "collate" process takes .eve and .lrr result files and creates in the results folder a temporary .mdb (MS-Access) database.
To prevent errors when processing large result files, use MSDE (Microsoft SQL Desktop Engine). Don't install it from the Add-in folder on the LoadRunner 7.8 CD, which is obsolete SQL7. Download MSDE 2000 Release A which includes MSDE 2000 Service Pack 3a and MDAC 2.7 SP1a for use by Analysis on any Windows machine. Extract the file and share that folder. Open a command window to run a command such as:
Using Windows Explorer, share the Data folder.
Then in Analysis Options > Database tab, use 8.3 names without spaces (indentified with DOS command DIR /X):
1. Input the SAPWD password specified above.
2. Logical Storage location: \\loadclient02\Data (the folder you shared)
3. Physical Storage Location: C:\PROGRA~1\MICROS~1\MSSQL\Data (not C:\Program Files\Microsoft SQL Server\MSSQL\Data)
4. Click "Test parameters". (This takes a few seconds)
The Analysis Module (8,320K analysisu.exe)
generates analysis graphs and reports using data from the .mdb database.
The LoadRunner Results file results_name.lrr from each scenario run -- also called an Analysis document file -- is read by the Analysis program to display Percentile graphs.
By default, the LRReport folder is created in the test analyst's local machine My Documents folder to store Analysis Session files.
They can optionally be formated in HTML.
Their format are controlled by a .tem template file.
Optionally, Mercury's Remote Performance Monitoring (RPM) MS-IIS/ASP web server for LoadRunner 7.8 can be installed on a Windows 2000 server ( but not on a Windows 2003 server) so that
load test results to be viewed using a web browser.
Not pictured is the LoadRunner Tuning Module (a separate $50,000 product).

LoadRunner的工作原理(第一部分)

2007-02-14T15:04:00.000+08:00

Architecture Overview

virtual

real

client

Internet Explorer

Requests from many virtual user clients are generated by "Load Generators" in order to create a load on various servers under test

These load generator agents are started and stopped by Mercury's "Controller" program.

The Controller controls load test runs based on "Scenarios" invoking compiled "Scripts" and associated "Run-time Settings".

Scripts are crafted using Mercury's "Virtual user script Generator" (named "V U Gen"), It generates C-language script code to be executed by virtual users by capturing network traffic between Internet application clients and servers.

With Java clients, VuGen captures calls by hooking within the client JVM.

During runs, the status of each machine is monitored by the Controller.

At the end of each run, the Controller combines its monitoring logs with logs obtained from load generators, and makes them available to the "Analysis" program, which can then create run result reports and graphs for Microsoft Word, Crystal Reports, or an HTML webpage browser.

Each HTML report page generated by Analysis includes a link to results in a text file which Microsoft Excel can open to perform additional analysis.

Errors during each run are stored in a database which can be read using Microsoft Access

Virtual Users (Vusers)

Unlike a WinRunner workstation which emulates a single user's use of a client, LoadRunner can emulate thousands of Virtual Users.

Load generators are controlled by VuGen scripts which issue non-GUI API calls using the same protocols as the client under test. But WinRunner GUI Vusers emulate keystrokes, mouse clicks, and other User Interface actions on the client being tested Only one GUI user can run from a machine unless LoadRunner Terminal Services Manager manages remote machines with Terminal Server Agent enabled and logged into a Terminal Services Client session.

During run-time, threaded vusers share a common memory pool. So threading supports more Vusers per load generator.

The Status of Vusers on all load generators start from "Running", then go to "Ready" after going through the init section of the script. Vusers are "Finished" in passed or failed end status. Vusers are automatically "Stopped" when the Load Generator is overloaded.

No additional license is needed to monitor standard web (HTTP) servers (Apache, IIS, and Netscape).

To use Web Services Monitors for SOAP and XML, a separate license is needed, and vUsers require the Web Services add-in installed with Feature Pack (FP1)

Product Versions

Version 8.1 Feature Pack 4 patch installer LR81FP4P136.exe at 7,786,800 bytes, was signed on January 2, 2007 as file 8.1.4.0 (Build: 1735) is Recorder Version: 1290.

Version 8.1 Feature Pack 4 installer LR81FP4.exe, at 194,644,720 bytes, was signed on December 15, 2006 as file version 8.1.4.0 (Build: 2249) is Recorder Version: 1289. This requires an upgrade to MS.NET 2.0 clients.

Version 8.1 Feature Pack 3 installer LR81FP3.exe, at 116,601,240 bytes, was signed on June 18, 2006 as file version 8.1.3.0 (Build 2085). It installs (as an item on your Start > Program Files) Microsoft WSE (Web Services Enhancements) 2.0 SP3 to deploy security policies for sytems running .NET Framework 1.1.

Version 8.1 became available October 2005. In VuGen it adds a "Workflow View", "Workflow Wizard", and a memory leak which is fixed with a patch downloadable since Dec. 2005. It renames the VuGen "Execution Log" the "Replay Log".

Version 8.0 became available August 2004. It adds "Additional Attributes" to Runtime Settings. It also adds (for additional fee) diagnostics and tuning capabilities, allowing Transaction Breakdown to breakdown transaction times across different servers servicing various transaction layers (web server, Oracle 11i & Peoplesoft 8 app server, database) layers. It separates SQL time in execute, parse, and fetch times.

Version 7.8 Feature Pack 1 added support for Windows XP.

Version 7.8 became available September 2003.

Version 6.5 available June 2000 offered new "TurboLoad" technology -- a completely new replay engine that runs thousands of vusers using a single operating system thread.

Version 6.0 used a separate thread per user, which required almost 10 times more i/o and CPU cycles than 6.5.

Note: Links to documents that used to be here were removed after Mercury Interactive, Inc. lawyers demanded their removal. Page numbers in online pdf files are different (have more pages) than page numbers in the paper document of the same title.

Application Components' Requirements

system requirements

	Process Image Name	V8.0 Img KB	File Size
-	LRLauncherApp.exe	16,288	n/a
Virtual User Generator	VuGen.exe	12,436	2,334,769
Controller with On-Line Monitors	wlrun.exe	13,076	5,681,215
Load Generator Agent	magentproc.exe	3,236
	magentservice.exe		65,536
	mdrv.exe
Analysis	Analysisui.exe	13,132	6,058,496
Tuning Console	protune.exe		3,403,833

Console programs

perl5.8.0.exe	Interpreter	20,535
regtlb.exe	registers the batch automation type library	30,720
sed.exe		55,296
wdiff.exe	Compares text files	197,632

Alex Arbitman's LR 7.8 Footprints.xls reports that to run Web requires __ per process and __ per thread.

Using Windows Remote Desktop Connection

To keep Windows Remote Desktop Connection sessions from timing out during a test, the Terminal Services on each machine should be configured as follows:

Click Start, point to Programs (or Control Panel), Administrative Tools and choose Terminal Services Configuration.
Open the Connections folder in tree by clicking it once.
Right-click RDP-Tcp and select Properties.
Click the Sessions tab.
Make sure "Override user settings" is checked.
Set Idle session limit to the maximum of 2 days instead of the default 2 hours.
Click Apply.
Click OK to confirm message "Configuration changes have been made to the system registry; however, the user session now active on the RDP-Tcp connection will not be changed."

Make sure that when you do this you're not violating one of your corporation's security policies.

Terminal Server only allows two simultaneous connections. To disconnect from a session, do not click "X" on the remote desktop window but click Start and Log Off.

Quality Web Systems: Performance, Security, and Usability (Addison-Wesley Professional; Aug. 2001)

The Web Testing Handbook (S T Q E Pub, Jan. 2001) by Steven Splaine, Stefan P. Jaskiel, Alberto Savoia is a good overview introduction, but does not make you an expert.

Among Common problems installing LoadRunner: Windows 2003 & XP SP2 have a DEP (Data Execution Prevention) feature which prevents VuGen recording. Go to Control Panel, System -> Advanced tab, Performance section "Settings" button Data Execution Prevention tab and add the client program or choose "Turn on DEP for essential windows programs and services only." A reboot is required.

LR Installation and Configuration

here

Disable your anti-virus software (Symantec, McAfee, etc.) before invoking on installers.

Virus Detection engines (such as Hauri versions since May 18) may find that program regtlb.exe (which registers/unregisters type libraries) to contain a "virus" they call "Backdoor.Win32.PoeBot.15872". Automatic repair by the virus remover will break those files.

The LR box comes with two CD's and this installation manual. Separate installation manuals are available for the Controller and Analysis modules.

The Windows CD autostarts to this initial screen for v7.8 and this initial screen for v8.0

The UNIX CD installs only the Load Generator (not the Controller or VuGen) on UNIX machines because the Controller and VuGen only run on Windows machines.

Zero fill machine names to t001, ... t010, etc. The LR Controller sorts machines named t1, t2, ... t10 as t1, t10, t2.

Location of Program Files

adds files in Program Files, Windows folder, and the Windows Registry

If you get a "License violation" message, you need to get from Mercury support a one-day license key to install with.

By default, different versions of LoadRunner are installed to different parts of your hard disk:

LoadRunner 8.1 executable files are installed to file path
"C:\Program Files\Mercury\LoadRunner\bin"

LoadRunner 8.0 "stutters" when it installs to its default file path
"C:\Program Files\Mercury Interactive\Mercury LoadRunner\bin"

Note: Even though 8.0 uses a different folder, folders created by previous versions still need to be removed before its installation.

LoadRunner 7.8 executable files are installed to file path
"C:\Program Files\Mercury Interactive\LoadRunner\bin"

C:\LR78

KB article 11878

For LoadRunner 8.1: C:\PROGRA~\MERCUR~1\LoadRunner\lib
For LoadRunner 8.0: C:\PROGRA~\MERCUR~1\MERCUR~1\lib

To quickly get at this LoadRunner installation folder, create an environment variable named "LR81" so you can use a quick command such as

 cd %lr81%

To get at this folder quickly, I created a batch file named "L.bat" in the cmd's default C:\ root folder containing this:

cd \Program Files\Mercury\LoadRunner\bin

pause

Files in Windows Folders

This path specified is stored under [ProductEnv] as M_ROOT in file wlrun.ini in the C:\WINNT (or C:\Windows) folder.

The C:\WINNT (or C:\Windows) folder also holds the Maintenance Number (MPN) specified during installation, stored as a parameter named "LoadRunner_SerialNumber" (such as 1234-1234567890) in the mercury.ini file.

Start Menu

The LR installer adds links to the most used programs in

> Programs > Mercury Interactive > LoadRunner

However, some programs are installed which are not conveniently listed there, such as
WDiff.exe v1.49 to compare differences between two ASCII text files. It has an accompanying help file

Beginning with v7, LoadRunner prevents software piracy (much like Microsoft began doing with Windows XP) by requiring that a license key be provided within 10 days of installation. Mercury generates its license key based on a host ID generated on each computer. CPT12784.doc

With v7.x, to generate Generate a HostID key (such as "XCCWJU-APBE-BYDS") click down

The key can be obtained before installation from program licidgenerator.exe and (after registration) its lm70.dll from the installation CD folder \lrunner\lm70.nt\bin or \lrunner\setup\lm70.nt\bin.

Sample Apps / Protocols

Running the samples install program populates folder

C:\Program Files\Mercury Interactive\Mercury LoadRunner\

Copy the link location below into the "Program to record:" field:

Protocol	Server	Client Program	Parameter	Notes
Web	WebTours\StartServer.bat	http://localhost:1080/mercuryWebTours
COM/DCOM	(Operating System)	samples\bin\frsui.exe
Winsock	sockfrs.exe	samples\bin\flights.exe	Winsock WinSockWeb
ODBC	(MS Access)	samples\bin\flights.exe	ODBC_Access
CORBA	samples\CorbaSamples\server.cmd & samples\CorbaSamples\server.bat	samples\CorbaSamples\client.cmd & samples\Corbasamples\clientrecord.cmd		Stuart Moncrieff's article on CORBA
RMI	samples\RMISamples\server.cmd & samples\RMISamples\server.bat	samples\RMISamples\client.cmd & samples\RMISamples\clientrecord.cmd

According to CPT11877.doc, JDK 1.5 users need to contact Mercury Support for a patch to each specific LoadRunner version (7.6, 7.8 FP1 or 8.0). Otherwise, you'll get these messages:

Error: Failed to find javac.exe Java Compiler in Path and JDK installation folder in registry. [MsgId: MERR-22981] Error: Failed to compile the Actions.java file. Please add the \bin to the path and try again. [MsgId: MERR-22996] Warning: Extension java_int.dll reports error -1 on call to function ExtPerProcessInitialize [MsgId: MWAR-10485] Error: Thread Context: Call to service of the driver failed, reason - thread context wasn't initialized on this thread. [MsgId: MERR-10176]

The Java sample apps use the "flight32lr" User Data Source with Microsoft Access driver(*.mdb) in the USER DNS table in Data Sources(ODBC) of the VuGen's local machine.

Additionally, the sample Java servers must be operational prior to starting the client. This is done with the "samples\RMISamples\server.cmd":

set lrpath=C:\PROGRA~1\Java\jre1.5.0_02\bin;C:\PROGRA~1\MERCUR~1\MERCUR~1\classes set lrclasspath=C:\PROGRA~1\MERCUR~1\MERCUR~1\classes;C:\PROGRA~1\MERCUR~1\MERCUR~1\classes\srv;C:\PROGRA~1\Java\jre1.5.0_02\lib\rt.jar set flightRmi=%~dp0;%~dp0RmiSamples.zip set classpath=%lrclasspath%;%flightRmi%;C:\PROGRA~1\Java\lib\rt.jar;.;%classpath% set path=%lrpath%;.;%path% cd %~dp0 start java -Djava.security.policy="%~dp0RmiFlights.policy" RmiFlights.Server

Note the location of loadrunner class files I added to the default sample. They are pre-pended to the existing classpath.

Note that there are no spaces in the file path.

The Zip file is equivalent to a JAR file in Unix systems.

Do not delete the black command window because the Java server runs within it.

CORBA and RMI Java clients are invoked with a command for Windows to start the java.exe program. This "samples\RMISamples\client.cmd" file contains:

set lrpath=C:\PROGRA~1\Java\jdk1.5.0_02\bin;C:\PROGRA~1\MERCUR~1\MERCUR~1\classes set lrclasspath=C:\PROGRA~1\MERCUR~1\MERCUR~1\classes;C:\PROGRA~1\MERCUR~1\MERCUR~1\classes\srv;C:\PROGRA~1\Java\jdk1.5.0_02\lib\rt.jar set flightRmi=%~dp0;%~dp0RmiSamples.zip set classpath=%lrclasspath%;%flightRmi%;C:\PROGRA~1\Java\jdk1.5.0_02\lib\rt.jar;.;%classpath% set path=%lrpath%;.;%path% cd %~dp0 start java RmiFlights.main

Note that the RmiFlights.main class file name is passed into java for it to load.

When recording Java with VuGen, a different command — such as the sample clientRecord.cmd — needs to be invoked because VuGen needs to be invoked within the JVM sandbox:

set flightRmi=%~dp0;%~dp0RmiSamples.zip set classpath=%flightRmi%;%classpath% cd %~dp0 start InvokeVugen.exe

The location of the JDK needs to be specified in the Windows PATH environment variable PATH to avoid this message:

Error: Failed to find javac.exe Java Compiler in Path and JDK installation folder in registry. [MsgId: MERR-22981]

VuGen "Java Vusers" can only operate as Single Vuser mode (not multi-vuser).

Instead of web "Start recording", Java VuGen scripts invoke Java functions within the Actions section.
"vuser_init" and "vuser_end" actions are not relevant within Java VuScripts.

Internally, the cjhook.ini file specifies which Java classes can hook in its [EXC_SYSTEM_CL] section. Java classes specified in the [SYSTEM_CL] section are not hooked.

The user.hooks file in LR \bin folder is a general format and cannot be used as-in. It needs to be copied.

Uninstall

To uninstall LoadRunner, you must be logged in with the same Windows userID as was used during original installation! If you use a different userid, the uninstall will delete only the dat folder which contains the "miuninst" file.

Unlike Microsoft Office applications, Mercury has not programmed invididual components to be selectively uninstalled on its own.

Lonely

2007-02-13T17:35:00.000+08:00

一九六九年十月五日出生在加纳。十岁的时候他跟随他母亲、兄弟姐妹一起去了德国。这一去，改变了他的生活，nana学到了很多新的东西。从幼年开始，nana酷爱音乐，他从中学毕业后，当了一名dj。他在很多地方表演，渐渐小有名气。与此同时，他还在两部德国电影中担任配角，因而，nana也可以被称为一名演员。这个时候，他遇到了toni cottura。此人在fun factory大大地有名，参与炮制好几个著名组合：后街男孩、超级男孩、Marky Mark.在与nana合作一段时间之后，tony cottura 和他的搭档离开了fun factory。

歌词：

I am lonely lonely lonely 我是寂寞的寂寞的寂寞的
I am lonely lonely in my life我是寂寞的孤独的在我的生命中
I am lonely lonely lonely 我是寂寞的寂寞的寂寞的
God help me help me to survive! 神救我帮助我生存
Remember first time we met day one 记得那天第一次我们相遇一个小孩在花园里快乐的玩耍
Kids in the garden\' playin\'
games heaven\' fun
Excitin\' and amazin\' havin\'激动和吃惊发现了我的一个真正的朋友
a real friend of mine
Feel my heartbeat and for感觉到当我遇到真正朋友时的心跳
real friend of mine
Face to face and eye to eye脸对脸.眼对眼
Usin\' our hands to buy and supply 用我们的手去卖去供给
Chillin\' is cool from january to june 寒意从一月到六月
And we still stiked together我们像胶水一样粘一起
like the glue
And know the rules 我们知道规则
Forever you and i and believe 我和你都相信它永远是干净的
it was clear
If i ever should fall即使我曾经落下
i could count on you with no fear 我可以依靠你不会害怕
Runnin\' out of time i see who\'s fake 用完所有时间,我看到虚假的孤独没有保护
Alone without protection
from all them snakes 从他们的虚假
All for one one for all i was told 不管我说黑白黄不管年轻或老
Black white yellow no matter
if your young or old
Nana\'s in the house to let you know祖母让你知道
What i see is how i fell and damn 我看到的,我是多么忧伤和失败
I\'m alone我是孤独的

I am lonely lonely lonely 我是寂寞的寂寞的寂寞的
I am lonely lonely in my life 我是寂寞的孤独的在我的生命中
I am lonely lonely lonely 我是寂寞的寂寞的寂寞的
God help me help me to survive! 神救我帮助我生存
Everybody\'s trippin\' on me 所有人牵绊着我
Oh lord come help me please 求上帝来保佑我
I did some bad things in my life 很多不好的事情在我的生命中
Why can\'t you rescue me 为什么你不来拯救我
\'cause you\'ve got all i need 你能做到我所有想要的
I know i got to pay the price 我知道我需要付出代价
Cheppin\' thru the streets at night在夜间穿过大街
after a fuss and fight 在一切慌乱后
Tears in my eyes i\'m a man眼泪在我眼底,我一个人望着光
lookin\' for the light
Dark is the path黑暗已经过去
i know he will rescue me我知道他会来拯救我
The lord is my shepard上帝是我的牧主
i\'m cool despite emergency
Whom shall i fear exept the god只有上帝在我冷的时候不会让我遇到事情时感到害怕
Thank you for the blessin\' a
nd the skils on the mic 谢谢你保佑和赐予我唱歌的能力
Five years we know there\'s no diggity 五年我们知道了那儿没有diggity(不知道这个词什么意思)
Free at last see the light in me 我最后一次看到光
What goes up must come down 什么才是必须做的
I\'ll be around while you 我会在你周围直到死亡
heading towards deathtown 朝（？）前进
Allways look forward hardly 一直努力的向前看决不回头
never look back So many tears and 决不回顾那么多眼泪和毒蛇
the snakes on my jock 当我成为男子汉
Now i\'m riding in my big fat ride 现在我骑着我肥壮的马
Your ass is late so look for the line 你的驴慢所以只能看着线
Nana in the house to let you know 祖母会让你知道
What i see is how我感觉到我的感觉所以让我一个人带回儿
i feel so leave me alone 感觉到我不管
I am lonely lonely lonely我是寂寞的寂寞的寂寞的
I am lonely lonely in my life我是寂寞的孤独的在我的生命中
I am lonely lonely lonely我是寂寞的寂寞的寂寞的
God help me help me to survive!神救我帮助我生存
Knock on my door whom you lookin\' for 敲我的门当你看到梦想的敌人在我的门前
A dream or reality enemies at my door
Eyes i realize 注视着,我发现了,那是梦想我必须定很很高
it\'s fantasize i must be high 想象中一定是高的
So let me live before i die 所以让我生动的度过我剩余的时间
Once again grab the
bottle twist the cap再一次拿起瓶子
To survive your life 去拯救你的生命
is yours my life is mine 是你的我的生活是我的
No emotions in this world full of lies面对这个世界的完美的谎言不要冲动
Step by step and be versatile 一步一步的实现
Love peace and cash爱,和平和死亡
that\'s what is\'s all about那是所有
Alone by yourself than you比你自己更孤独
lack there\'s no doubt about 不要怀疑
I\'m always into something
making moves to improve 只要你归于我,我会证明给你看
What would you do 如果你处在我的位置
if you were in my shoes 你能做什么
Boom a letter oops another suicide(这句实在是不知道怎么翻译)
Meet me for a ride at the boulevard 骑着马和我在林荫道相遇
Nana\'s in the house to let you know 祖母会让你知道,
What i see is how i feel我看到的和我感到的
and damn l\'m alone和我多么的孤独

自动化测试的思考和总结之功利篇

2007-02-10T17:48:00.000+08:00

上周参加公司的自动化测试研讨会，今年的主题是ROI（投资回报），个人感觉这是一个很严肃的话题，也是领导最关心的一个问题。不过谈测试自动化的投资回报似乎并不是一件容易的事情。测试自动化本身是一个需要持续投入的系统工程。他并不像开发过程一样那么容易衡量产出和回报。另外，对于测试自动化的投资回报似乎不应该在一开始提到一个很高的高度。否则对自动化的开展非常不利。

另外，测试自动化并不是简单的把手工的测试转化成自动化的代码或者脚本这么简单的过程，而是要贯穿在产品的生命周期中，进行不断地执行，只有不断地执行，才能得到收益，根据经验，回归测试的自动化测试用例在不考虑被测对象改变带来自动化测试脚本维护的前提下，反复执行4-7轮才能收回成本。如果被测对象本身不是十分稳定，或者缺陷比较多，产品不成熟，这个时候介入测试自动化是非常得不偿失的。

测试自动化在很大程度也依赖于被测对象或者被测设备的稳定性，系统的设计应该考虑到可测试性，Design for Test。测试自动化越早加入到产品的开发周期，成功的机会越大。
关于测试自动化的效果衡量不是简单的发现了多少缺陷，其实自动化测试并不能比手工测试发现更多的缺陷，如果要发现更多的缺陷，一定要进行必要的手工测试。自动化测试的效果或者投资回报可以通过其他一些方法进行衡量，比如节省的测试人力成本，可以通过统计手工测试的时间，自动化测试的开发时间，自动化测试的执行之间，执行次数，刨去维护时间，进行计算得到。另外，还可以从回归测试能加快产品的发布时间上进行衡量。

最后，关于产品的自动化程度，究竟多少比例的产品需要被自动化，这个取决于产品本身，以及这个产品本身可以被自动化的程度有关系，还要考虑自动化所需要花费的代价。一般来说，不是所有的测试用例都需要自动化，也不是所有的测试用例都能够自动化。据个简单的例子，有一个测试用例，需要重新启动机房里面一台服务器，常规来说，是不能也不需要自动化。但是有没有可能自动化呢？肯定有，不过肯定不会为了这个自动化这个测试用例而去花费巨大的代价开发一个机器人帮你完成这个任务。当然这是一个极端的例子。目的是告诉大家，不是所有的测试用例都需要自动化，也不是所有的用力都能自动化。衡量的依据是不同产品和代价得多少。

--end

二十世纪最狂妄的演讲

2007-02-09T10:57:00.000+08:00

埃里森，甲骨文公司CEO，是当今仅次于盖茨的第二富翁。不过，也有人网上和他开玩笑，以下是网上流传的他在耶鲁大学2000年毕业典礼上的致词(可以肯定这不是真的)。

　　耶鲁的毕业生们，我很抱歉一一如果你们不喜欢这样的开场。我想请你们为我做一件事。请你一一好好看一看周围，看一看站在你左边的同学，看一看站在你右边的同学。请你设想这样的情
况：从现在起5年之后，10年之后，或30年之后，今天站在你左边的这个人会是一个失败者
右边的这个人，同样，也是个失败者。而你，站在中间的家伙，你以为会怎样?一样是失败者。失败的经历。失败的优等生

说实话，今天我站在这里，并没有看到一千个毕业生的灿烂未来。我没有看到一千个行业的一千名卓越领导者。我只看到了一千个失败者。你们感到沮丧。这是可以理解的。为什么，我，埃里森，一个退学生，竟然在美国最具声望的学府里这样厚颜地散布异端?我来告诉你原因。因为，

我，埃里森，这个行星上第二富有的人，是个退学生，而你不是。因为比尔·盖茨，这个行星上最富有的人一一就目前而言一一是个退学生，而你不是。因为艾伦，这个行星上第三富有的人，也退了学，而你没有。再来一点证据吧，因为戴尔，这个行星上第九富有的人一一他的排位还在不断上升，也是个退学生。而你，不是。

　　……你们非常沮丧。这是可以理解的。

　　现在，让我打击你一下。我要相当诚挚地指出：你们的文凭不是白拿的。你们中的大多数，我猜，已经在这里花费了四五年时光，你们将以各种方式在未来使用你所学的东西。你们已经确立了好的工作习惯。你们已经建立了能帮你沿这条路前进的人际网。你们已经将自己这辈子与“治疗”这个词建立了一种联系。一切很好。因为事实上，你们需要这些。

　　你们将来需要这些有用的工作习惯。你将来需要这种“治疗”。你需要它们，因为你没辍学，所以你永远不会成为世界上最富有的人。哦，当然，你可以，也许，以你的方式进步到第10位，第 11位，就像史蒂夫·鲍尔默，但，我没有告诉你他在为谁工作，是吧?根据记载，他是研究生时辍的学，开化得稍晚了些。

　　现在，我猜想你们中间很多人，也许是绝大多数人，正在琢磨，“我能做什么?我究竟有没有前途?”当然没有。太晚丁，你们已经吸收了太多东西，以为自己懂得太多。你们再也不是19岁了。你们有了“内置”的帽子，哦，我指的可不是你们脑袋上的学位帽。

　　嗯……你们已经非常沮丧啦。这是可以理解的。所以，现在可能是讨论实质的时候啦一一绝不是为了你们，2000年毕业生。你们已经被报销，不予考虑了。我想，你们就偷偷摸摸去干那年薪20万的可怜工作吧，在那里，工资单是由你两年前辍学的同班同学签字开出来的。事实上，我是寄希望于眼下还没有毕业的同学。我要对他们说，离开这里。收拾好你的东西，带着你的点子，别再回来。退学吧，开始行动。我要告诉你，一顶帽子一套学位服必然要让你沦落……就像这些保安马上要把我从这个讲台上撵走一样必然……(此时，Oracle CEO被带离了讲台)

人物介绍：
姓名：拉里.埃里森（Larry·Ellison），俄罗斯移民的美国犹太人后裔
年龄：57岁，出生于1944年曼哈顿
婚史：曾经历过3次婚姻
学历：读过三所大学，伊利诺斯大学、芝加哥大学、西北大学，后辍学
人生目标：击败微软，成为世界最大的软件企业是我的一大目标。我成功并不重要，重要的是其他所有人都失败了，那时我才是真正的成功。
惊人手笔：
1、他曾经想花2000万美元购买一架俄罗斯米格战斗机，令美国海关手足无措。
2、开着一架意大利产战斗机在太平洋上空和别人进行模拟空战。
3、因冒险玩命多次住进医院：上大学踢球时弄断过鼻梁骨，在夏威夷冲浪时扭伤过颈骨，还有一次因骑车摔断过肘骨。
4、拥有一架拆除武器的意大利产‘马尔切蒂S.211’型战斗机。

如何判断一个字符串是否为数字或日期?

2007-02-08T16:12:00.000+08:00

转自Eygle大侠的一篇文章,感受颇深:

这就是区别.

高手遇到问题,总是说:自己写一个吧!
新手遇到问题,总是问:这个怎么实现?

-------------------------------

昨天有一个朋友在MSN上问，如何判断一个字符串是否为数字?
我说，写一个函数吧。于是给出了一个例子:

SQL> CREATE OR REPLACE FUNCTION is_number (parmin VARCHAR2)
2 RETURN NUMBER
3 IS
4 val NUMBER;
5 BEGIN
6 val := TO_NUMBER (NVL (parmin, 'a'));
7 RETURN 1;
8 EXCEPTION
9 WHEN OTHERS
10 THEN
11 RETURN 0;
12 END;
13 /
Function created.

SQL> select is_number('a') from dual;

IS_NUMBER('A')
--------------
0

SQL> select is_number('0.998') from dual;

IS_NUMBER('0.998')
------------------
1

SQL> select is_number('9999999999999999') from dual;

IS_NUMBER('9999999999999999')
-----------------------------
1

今天，这个朋友在MSN上又问：如何判断一个字符是否是日期?
我说，再写一个函数吧。

补注:由于session的语言设置会影响日期的输出格式，所以时间被转换为字符可能有多种形式。
以下这个函数只能满足部分情况，仅供参考。

SQL> CREATE OR REPLACE FUNCTION is_date (parmin VARCHAR2)
2 RETURN NUMBER
3 IS
4 val DATE;
5 BEGIN
6 val := TO_DATE (NVL (parmin, 'a'), 'yyyy-mm-dd hh24:mi:ss');
7 RETURN 1;
8 EXCEPTION
9 WHEN OTHERS
10 THEN
11 RETURN 0;
12 END;
13 /

Function created.

SQL> select is_date('a') from dual;

IS_DATE('A')
------------
0

SQL> select is_date('2004-05-05') from dual;

IS_DATE('2004-05-05')
---------------------
1

SQL> select is_date('2004/01/01') from dual;

IS_DATE('2004/01/01')
---------------------
1

SQL> select is_date('01/01/04') from dual;

IS_DATE('01/01/04')
-------------------
1

SQL> select is_date('01-jan-04') from dual;

IS_DATE('01-JAN-04')
--------------------
1

这两者是何其相似啊！

参考原文

--end

天堂里没有忧愁--沉痛悼念丽丽

2007-02-03T14:27:00.000+08:00

为什么??这究竟是为什么??

昨天看到曾勇发的短信,"丽丽昨天上吊自杀了",我真的不敢相信自己的眼睛.
活泼可爱的丽丽,自从毕业之后就一直没能见过一面,去年她来过一次深圳
我们最近的时候相隔竟然不到一公里,而因为行程,居然没有见着,想不到...

一直都记得她那铜铃般灿烂的笑声,可是以后再也听不到了,这究竟为什么...

祝福丽丽在天堂能得到她的幸福....

丽丽,一路走好~~

五四六零上的部分留言:以此来纪念曾经的活泼可爱的丽丽

留言者：张皓

惊闻噩耗,内心涌动着震痛的酸楚!
可从上午至今,一直没有落泪,难以面对的事实使我精神麻木!
但现在,看着这行行思念和祝福,泪水夺眶而出!

她将所有的快乐播撒给了我们,然后在那天悄悄的走开!
然而在红尘寂寂的生活中,我想我居然并没有时常想起她,只会独自的享受"开心果"的开心.真的,现在,今天,明天
请记住她,请记住那天!
并请加上永远的

留言者：陈艳琴

丽丽，很久没有你的消息，没想到有了，确实这样一个令人难以置信的噩耗，我真的真的希望这只是个玩笑，从知道这个噩耗到现在，脑子里全是你的笑容，你的声音，你的一切的一切...，好想再陪你去逛步行街，帮你参考衣服，好想再陪你聊天，哪怕是一次也行。可事实确是这么的残酷，我们要永远的失去你，永远也见不到你......只能默默的祝福你，祝福你在那个世界里，内心能象你的笑容一样灿烂、开心。

留言者：董玉华

流过泪以后，还有一个小时才到下班时间，我换好衣服走出来，早退，实在不能再呆在单位，遇到同事都低头，怕人看见自己的眼睛红红，沿海边走了一站路，吹吹海风希望能清醒点，先坐车去了夫的单位，路上就想吐，没有缘由地。
到了他单位，门卫奇怪地看着我，我说进去找人，工程机所的×××，然后进去，正是他们下班的时候，每个人匆匆忙忙地走过，我呆呆地，没有人注意到我，穿过第一栋楼的大厅，他站在那等我，看到他，我泪水又下来......
他问：是不是真的？会不会是弄错了啊?
我也宁愿相信这不是真的，张帆在电话里失声痛哭，我也哭。
前段时间她还说有空来青岛玩，我也说我全程陪伴的，而这个，也是她许给我的空头承诺。
眼泪流干心被掏空........

留言者：黄刘华

我不知道用什么做留言主题，好像脑袋空白似的。我也不想说祝福她在天国，因为宁愿她现在还在人世，哪怕是痛苦的活着。抑郁症不是常人所能够理解的，所以大家一定要珍重眼前人，而且如果谁觉得很郁闷的话，如果旁边没人可说，那多打电话骚扰同学吧，所有的人都喜欢被关心的感觉，能被打电话骚扰也是一种幸福。

谢谢伟光，新运能发起这个捐款号召

留言者：熊英

我没有心情也没有力气了,我总不能相信,你就这样永远的离开了我们,永远!

天堂是什么模样,祈祷你在天堂不再不快乐,不再没有人陪你说话,你现在应该知道了是不是和梦中一样,那里应该没有痛苦没有烦恼.

你blog最后的链接是"查无此人",时间是2006年11月11日,你离开的时间是2007年2月1日,没有人知道你承受多少痛苦,你把关于你的一切永远的永远的带走了......

我知道,每个人都会离开这个世界的,可是你离开的方式是这么壮烈.

我们再也联系不到你了,再也不知道另一个世界你的喜怒哀乐了.

留言者：尹雪辉

惊闻噩耗传来，不禁悲痛万分，熊英脸上依然挂着泪水。
正如伟光所言，彭丽选择了她自己的道路，我们惟有送上自己的祝福。
脑海里，彭丽的音容笑貌历历在目。毕业后，大家各赴前程，和彭丽也只见过2面。一次彭丽来上海进修，一次在长沙母校重逢。
给女友电话，告之彭丽的事情，女友大声叫着，不会吧，这么一个爱笑的女孩，这么一个开朗的女生，就这么走了？虽然只有一面之缘，餐桌上，那清朗略带腼腆的笑容给每个人留下深刻的印象。
而我，也始终无法接受这样的现实。在长沙，也就2，3个月之前，彭丽站在铁道校区大门口等待我们。仍然感受着只属于她的那种温柔，那种温暖。笑着，望着……
我们始终无法走进彭丽的思维，就像一个正常人来考虑这样的事情一样，而她还是去了。但那动人的笑容，会浮现在眼前。生命啊，何其重，何其轻？
愿她的天堂，像她一样，充满欢笑，充满阳光。
我们也会把你的笑容珍藏，在每年的今日，再和你一起共享。

留言者：高洪霞

天堂里没有烦恼，你的笑容永远灿烂，你是我们心中永远可爱的女孩，你是天使，一起走过的日子是彼此心中永远珍藏的角落。。。

留言者：薛_云志^

真不敢相信，那么开朗的lily居然会以这种方式离开人间...

一段时间没见她上网，一直以为年底工作忙。没想到却是这样的一个消息...

msn上，有一个名字，永远也无法上线了...

lily的照片还在下面，那笑容还是很灿烂...

lily走好，天国一切平安。

留言者：周新运

今天接到噩耗，我们的小开心果彭丽昨晚去世。大致情形是丽丽患上了抑郁症，然后...
逝者已经远去，留下的只是无尽的伤痛。
现在最痛苦莫过于丽丽的父母和亲人。
丽丽的父母都是农民，丽丽是他们家经济上的主力。我们所能做的也就是奉献自己的绵薄之力，代丽丽孝敬一下丽丽的爸妈。
我和伟光商量后，打算这样做。
伟光设立一个帐号，大家往这个帐号上面汇过去，汇总了之后，由伟光等人做代表送给丽丽的爸妈。具体的帐号信息稍后伟光会公布出来。
此外，由于一时联系不上很多同学，请知道这个消息的同学给身边的同学转发通知一下，大家齐伸手，谢谢大家。

自动化测试的思考和总结之工具利器篇

2007-02-01T22:23:00.000+08:00

谈到自动化测试,自然离不开自动化测试工具. 其实自动化测试和自动化测试工具还有很大的差别,不过很多人提起来自动化测试就想到自动化测试工具,其实是不全面的，更有人提到自动化测试就想到QTP,LoadRunner,Test Manager,那就更是片面的了。

自动化测试工具是开展自动化测试的必备利器，就好像你要进行性能测试自动化，但是缺少工具。传统的方法比如压力测试是号召大伙某个固定的时间，登陆某台测试对象或者测试设备进行同时测试。这在现在看来是有些不切实际，而且实际的测试效果往往因为无法有效组织或者无法模拟实际情况大打折扣。而利用自动化测试工具就可以很好的满足这样的需求，最简单的就是模拟500用户并发测试web服务器的性能。

不单单性能测试，往往功能测试自动化也是这样的，只是性能测试表现得更加明显罢了。功能测试自动化如果能有效的利用自动化测试工具，有的时候可以收到事半功倍的效果。

简单的分析到这里，关于测试工具的一个很全面地总结，可以参考前面的一篇日志。

--to be continued

软件测试工程师面试题

2007-02-01T18:11:00.000+08:00

在51上看到这个帖子,挺有感触的,就转过来了.

以前做过测试,有志于从事测试,目前正在从事测试或者将来要从事测试的朋友都来问问自己 ,这些问题如果问到我应该怎么回答.

软件测试工程师面试题

01. 为什么要在一个团队中开展软件测试工作？

02. 您是否了解以往所工作的企业的软件测试过程？如果了解，请试述在这个过程中都有哪些工作要做？分别由哪些不同的角色来完成这些工作？

03. 您是否了解以往所工作的企业的软件开发过程？如果了解，请试述一个完整的开发过程需要完成哪些工作？分别由哪些不同的角色来完成这些工作？（对于软件测试部分，可以简述）

04. 您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？

05. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）

06. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

07. 测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？

08. 您认为做好测试计划工作的关键是什么？

09. 您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

10. 您认为做好测试用例设计工作的关键是什么？

11. 请以您以往的实际工作为例，详细的描述一次测试用例设计的完整的过程。

12. 您以往的工作中是否曾开展过测试用例的评审工作？如果有，请描述测试用例评审的过程和评审的内容。

13. 您以往是否曾经从事过性能测试工作？如果有，请尽可能的详细描述您以往的性能测试工作的完整过程。

14. 您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

15. 您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？

16. 在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

-end

CPC考试居然差点没过

2007-01-31T08:54:00.000+08:00

LoadRunner CPC考试居然没过, 68分,没有把我郁闷坏.

本来以为顶多能考四五十分,谁成想差那么2分,加油吧,下次一定要过了,否则浪费了考试的费用4,500千快,白花花的银子呐.

不过据51的老师们说,2007年的考试全部改成选择题,跟SP考试一样,当场出结果,难度可能降低了,没有挑战,那样岂不是没有多少含金量了,这是Mercury(美科利)被HP并购之后的对认证考试的最初的影响吧,天知道以后会不会全部并入HP的认证系统哪? (HP有什么认证好像没太听说过,知道的朋友给介绍介绍?)

--end

庆祝自己升级51系统测试版版主

2007-01-30T13:03:00.000+08:00

经过努力,于今日升级为51testing系统测试版斑竹一职.
就职演说就免了,还是要发表一下感言:

首先感谢51各位老师特别是水老师和蒋老师的信任,我一定不辜负两位老师的信任.
在我做斑竹期间,我一定坚持弘扬51tesging一贯的对软件测试的专业精神,努力学习,提高自己.
在技术上和管理上争取有更大的进步,为51testing的发展和中国的软件测试事业贡献自己的力量.

首先技术上要不断否定自己,反思自己,总结自己, 学习国内外先进的测试经验和测试理论知识,自己总结特别是创作一些优秀的文章并与广大的网友分享,一起提高,一起进步.
管理上,要加强管理方面的学习,兢兢业业,做好日常的版块的管理工作.

希望得到各位的及时监督.

谢谢了哈.

--end

好的测试工程师应具备的素质

2007-01-29T13:28:00.000+08:00

人是测试工作中最有价值也是最重要的资源，没有一个合格的、积极的测试小组，测试就不可能实现。然而，在软件开发产业中有一种非常普遍习惯，那就是让那些经验最少的新手、没有效率的开发者或不适合干其他工作的人去做测试工作。这绝对是一种目光短浅的行为，对一个系统进行有效的测试所需要的技能绝对不比进行软件开发需要的少，事实上，测试者将获得极其广泛的经验，他们将遇到许多开发者不可能遇到的问题。

　　①、沟通能力

　　一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术（开发者）和非技术人员（客户，管理人员）的交流能力。既要可以和用户谈得来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。而和开发者谈相同的信息时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成员必须能够同等地同用户和开发者沟通。

　　②、移情能力

　　和系统开发有关的所有人员都处在一种既关心又担心的状态之中。用户担心将来使用一个不符合自己要求的系统，开发者则担心由于系统要求不正确而使他不得不重新开发整个系统，管理部门则担心这个系统突然崩溃而使它的声誉受损。测试者必须和每一类人打交道，因此需要测试小组的成员对他们每个人都具有足够的理解和同情，具备了这种能力可以将测试人员与相关人员之间的冲突和对抗减少到最低程度。

　　③、技术能力

　　就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试小组的某个成员作出了一个错误的断定，那么他们的可信度就会立刻被传扬了出去。一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要做到这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程有较深入的理解，从开发人员的角度正确的评价测试者，简化自动测试工具编程的学习曲线。

　　④、自信心

　　开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。

　　⑤、外交能力

　　当你告诉某人他出了错时，就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于“赢了战争却输了战役”。

　　⑥、幽默感

　　在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。

　　⑦、很强的记忆力

　　一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的。因为许多新出现的问题和我们已经发现的问题相差无几。

　　⑧、耐心

　　一些质量保证工作需要难以置信的耐心。有时你需要花费惊人的时间去分离、识别和分派一个错误。这个工作是那些坐不住的人无法完成的。

　　⑨、怀疑精神

　　可以预料，开发者会尽他们最大的努力将所有的错误解释过去。测式者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。

　　⑩、自我督促

　　干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才能够使自己每天正常地工作。

　　11、洞察力

　　一个好的测试工程师具有“测试是为了破坏”的观点，捕获用户观点的能力，强烈的质量追求，对细节的关注能力。应用的高风险区的判断能力以便将有限的测试针对重点环节.

转载自CSDN

--end

自动化测试的思考和总结之平台利器篇

2007-01-29T12:50:00.000+08:00

上周休了一周的假, 在医院照顾老爸
这周继续自动化测试的思考系列,今天谈谈平台建设.

自动化测试一般来说,随着产品的不同,都会有不同的测试架构和测试平台,稳定和合适的平台对于一个产品的自动化测试来说,相对来说相当重要,有了合适的载体和工具,自动化测试就能很好的扩容和执行.

一般来说,自动化测试的平台包含以下一些方面:

测试管理部分--管理不同产品,不同版本的测试用例
测试执行部分--执行测试用例
测试维护部分--测试用例的维护,版本控制等
测试资源部分--测试资源特别是实验室资源的管理
测试调度部分--测试的调度,控制和执行中心

一般来说,这几个部分可以集成于一个平台本身,也可是独立的子系统,通过接口有机的结合起来,其实市场上也有很多商用的产品,比如Mercury的QC(Quality Center, Test Director的后续版本)就覆盖了其中的测试管理,测试执行等, Rational的Test Manager覆盖了另外一些部分等等.

因为这些商业工具相对来说,价格比较昂贵,而且对具体产品的适应能力等方面的考虑,不一定适合所有的公司,因此我们自己开发了自己的相应的系统.

测试执行平台:我们的测试执行平台其实覆盖了测试执行部分,测试维护部分和测试调度部分,是一个很强大的平台,从最初的1.0版本,到现在的2.1.1版本,基本可以支持我们公司的绝大多数的产品,另外测试管理的部分也有一些涉及,但是相对来说比较薄弱,特别是版本管理部分,目前是通过和测试管理工具的接口来实现的,我们正在改进这些薄弱的环节.

测试资源平台:我们也有一个自己开发的资源管理平台,可以预定实验室的各项资源,并用于测试,目前我们在测试执行平台预留了资源的相关接口.这部分跟具体的产品联系比较密切.

总体来说,下面这个图能详细说明这些部分之间的一个关系和接口.

下图是我们自己的测试执行平台的架构:

其中
ATS: automated testing system
LRMS: lab resource management system
TMS: test management system
(转载请注明出处)

--to be continued

老爸的颈椎病有救了

2007-01-27T21:09:00.000+08:00

这几天一直在医院，老爸的颈椎病经过确证，是脊髓型颈椎病，椎间盘突出压制到中枢神经，导致四肢麻木，严重束缚感。对比两个月前在老家做的MRI（磁共振），已经压迫到第3/4/5脊椎，如果不及时解除压迫，很有可能导致全身瘫痪。

颈椎病一般分为三种类型，这种是最严重的，而且是唯一一种不能通过按摩或者其他保守疗法治疗的颈椎病。幸好是比较及时动了手术。不过，这种手术虽然目前已经比较成熟，还是存在很大的风险。手术主要是通过把颈椎挪开，然后植入钢板，在从其它部位取一块骨头垫上，等彻底融合之后就可以达到手术目的。手术费用主要是材料费比较贵（我老爸用的进口钢板，25，3000元，如果用国产的钢板，大概可以节省10，000多元，不过因为制作工艺，可能会影响到以后进食），其他费用不高，手术费用+药费+住院费用应该在10，000元左右。

今天是手术后第三天了，老爸的手和脚已经恢复差不多了，只是头部还暂时不能移动，而且三个月之内不能随意转动头部，否则可能导致进一步的麻烦。

我们的手术室在深圳平乐骨伤科医院脊柱外科做的，虽然这是二级甲等医院，但是总体来说，骨科的技术力量还是比较雄厚的。而且服务都还不错。我们是冲着这医院口碑不错的想法过去试试的，结果果然没有让我们失望。医院的前任院长郭春园是一位传奇式的医生，有点精神领袖的意味。

--end

世界网站之最

2007-01-21T16:47:00.000+08:00

1、世界上最长的网站，号称已经18.939 kilometers 了，不相信，就进去看看。
不过如果你不是很闲的话，建议你乘坐电梯，否则，哈哈。。。自己看看就知道了。

http://worlds-highest-website.com/

2、世界上最小的网站。进来看看吧。
http://www.guimp.com/home.html

--end

Mercury LoadRunner的内部架构

2007-01-20T20:49:00.000+08:00

Mercury LoadRunner的内部工作原理和架构。

以前看到过这个Mr Wilson的介绍，看来他对很多的工具和技术(不仅仅是LoadRunner)都有很深入地研究。

--end

Oracle Database 10g为数据库管理员提供的20个最重要的特性（四）

2007-01-20T11:34:00.000+08:00

第 4 周
高速的导出/导入：Oracle Data Pump

利用 Oracle Database 10g 实用工具数据移动得到了很大的提高。

迄今为止，导出/导入工具集仍是跨多个平台转移数据所需劳动强度最小的首选实用工具，尽管人们常常抱怨它速度太慢。导入只是将每条记录从导出转储文件中读出来，然后使用常见的 INSERT INTO 命令将其插入到目标表中，因此导入可能是个很慢的过程，这一点并不让人感到吃惊。

进入 Oracle Data Pump，Oracle Database 10g 中的导出/导入工具包的更新更快的同类工具，它被设计来成倍地加速这个过程。

Data Pump 反映了整个导出/导入过程的彻底革新。它不是使用常见的 SQL 命令，而是应用专用 API 来以更快得多的速度加载和卸载数据。在我的测试中，我看到导出性能比在直接模式下提高了 10-15 倍，导入过程性能提高了 5 倍。此外，与使用导出实用工具不同，它还能够只取出特定类型的对象（如过程）。

Data Pump 导出

这个新的实用工具称为 expdp，以和原来的导出 exp 区分开。在本例中，我们将用 Data Pump 来导出一个大表 CASES，大小约为 3GB。Data Pump 在服务器端使用文件处理来创建和读取文件；因此，目录作为位置使用。在这种情况下，我们将使用文件系统 /u02/dpdata1 来保存转储文件。

create directory dpdata1 as '/u02/dpdata1';
grant read, write on directory dpdata1 to ananda;

接下来，我们将导出数据：

expdp ananda/abc123 tables=CASES directory=DPDATA1
dumpfile=expCASES.dmp job_name=CASES_EXPORT

让我们来分析该命令的各个部分。用户 ID/口令组合、表和转储文件参数的意义是显而易见的。与原来的导出不同，文件是在服务器（不是客户端）上创建的。位置由目录参数值 DPDATA1 指定，它指向之前创建的 /u02/dpdata1。这个进程还在目录参数指定的位置上创建一个日志文件（同样在服务器上）。默认地，这个进程使用一个名称为 DPUMP_DIR 的目录；因此可以创建它来代替 DPDATA1。

注意上面的参数 job_name，这是个特殊的参数，在原来的导出中没有。所有的 Data Pump 工作都通过作业来完成。Data Pump 作业 — 与 DBMS 作业不同 — 只是服务器进程，它代表主进程处理数据。主进程（称为主控制进程）通过高级队列 (AQ) 来协调这项工作；它通过在运行期内创建的一个特殊的表（称为主表）来实现这个目的。在我们的例子中，如果您在 expdp 运行时检查用户 ANANDA 的模式，您将注意到一个表 CASES_EXPORT 的存在（对应参数 job_name）。当 expdp 结束时，这个表被丢弃。

导出监控

当 Data Pump Export (DPE) 运行时，按 Control-C；它将阻止消息在屏幕上显示，但不停止导出进程本身。相反，它将显示 DPE 提示符（如下所示）。进程现在被认为处于“交互式”模式：

Export>

这种方法允许在这个 DPE 作业上输入几条命令。要查看概要，在提示符下使用 STATUS 命令：

Export> status
Job:CASES_EXPORT
Operation:EXPORT                      
Mode:TABLE                       
State:EXECUTING                   
Degree: 1
Job Error Count: 0
Dump file:/u02/dpdata1/expCASES.dmp
bytes written =  2048

Worker 1 Status:
State：EXECUTING                   
Object Schema:DWOWNER
Object Name:CASES
Object Type:TABLE_EXPORT/TBL_TABLE_DATA/TABLE/TABLE_DATA
Completed Objects: 1
Total Objects: 1
Completed Rows: 4687818

记住，这只是状态显示。导出在后台工作。要继续在屏幕上查看消息，从 Export> 提示符下使用命令 CONTINUE_CLIENT。

并行操作

您可以通过 PARALLEL 参数为导出使用一个以上的线程来显著地加速作业。每个线程创建一个单独的转储文件，因此参数 dumpfile 应当拥有和并行度一样多的项目。您可以指定通配符作为文件名，而不是显式地输入各个文件名，例如：

expdp ananda/abc123 tables=CASES directory=DPDATA1
dumpfile=expCASES_%U.dmp parallel=4 job_name=Cases_Export

注意 dumpfile 参数拥有一个通配符 %U，它指示文件将按需要创建，格式将为 expCASES_nn.dmp，其中 nn 从 01 开始，然后按需要向上增加。

在并行模式下，状态屏幕将显示四个工作进程。（在默认模式下，只有一个进程是可见的。）所有的工作进程同步取出数据，并在状态屏幕上显示它们的进度。

分离访问数据文件和转储目录文件系统的输入/输出通道是很重要的。否则，与维护 Data Pump 作业相关的开销可能超过并行线程的效益，并因此而降低性能。并行方式只有在表的数量多于并行值并且表很大时才是有效的。

数据库监控

您还可以从数据库视图获得关于运行的 Data Pump 作业的更多信息。监控作业的主视图是 DBA_DATAPUMP_JOBS，它将告诉您在作业上有多少个工作进程（列 DEGREE）在工作。另一个重要的视图是 DBA_DATAPUMP_SESSIONS，当它与上述视图和 V$SESSION 结合时将给出主前台进程的会话 SID。

select sid, serial#
from v$session s, dba_datapump_sessions d
where s.saddr = d.saddr;

这条指令显示前台进程的会话。更多有用的信息可以从警报日志中获得。当进程启动时，MCP 和工作进程在警报日志中显示如下：

kupprdp:master process DM00 started with pid=23, OS id=20530 to execute -
SYS.KUPM$MCP.MAIN('CASES_EXPORT', 'ANANDA');

kupprdp:worker process DW01 started with worker id=1, pid=24, OS id=20532 to execute -
SYS.KUPW$WORKER.MAIN('CASES_EXPORT', 'ANANDA');

kupprdp:worker process DW03 started with worker id=2, pid=25, OS id=20534 to execute -
SYS.KUPW$WORKER.MAIN('CASES_EXPORT', 'ANANDA');

它显示为数据泵操作启动的会话的 PID。您可以用以下查询找到实际的 SID：

select sid, program from v$session where paddr in
(select addr from v$process where pid in (23,24,25));

PROGRAM 列将对应警报日志文件中的名称显示进程 DM （为主进程）或 DW （为工作进程）。如果一个工作进程使用了并行查询，比如说 SID 23，您可以在视图 V$PX_SESSION 中看到它，并把它找出来。它将为您显示从 SID 23 代表的工作进程中运行的所有并行查询会话：

select sid from v$px_session where qcsid = 23;

从视图 V$SESSION_LONGOPS 中可以获得其它的有用信息来预测完成作业将花费的时间。

select sid, serial#, sofar, totalwork
from v$session_longops
where opname = 'CASES_EXPORT'
and sofar != totalwork;

列 totalwork 显示总工作量，该列的 sofar 数量被加和到当前的时刻 — 因而您可以用它来估计还要花多长时间。

Data Pump 导入

不过，数据导入性能是 Data Pump 真正出色的地方。要导入先前导出的数据，我们将使用

impdp ananda/abc123 directory=dpdata1 dumpfile=expCASES.dmp job_name=cases_import

导入进程的默认行为是创建表和所有相关的对象，然后在表已存在时产生一个错误。如果您想把数据添加到一个现有的表中，您可以在上述命令行中使用 TABLE_EXISTS_ACTION=APPEND。

和使用 Data Pump 导入一样，在进程中按 Control-C 将进入 Date Pump Import (DPI) 的交互模式；同样，提示符是 Import>。

处理特定对象

您是否有过只需要从一个用户导出特定的过程，以在一个不同的数据库或用户中重新创建这些过程的情况？与传统的导出实用工具不同，Data Pump 允许您只导出特定类型的对象。例如，以下命令让您只导出过程，而不导出其它任何东西 — 不导出表、视图、甚至函数：

expdp ananda/iclaim directory=DPDATA1 dumpfile=expprocs.dmp include=PROCEDURE

要只导出一些特定的对象 — 比如说，函数 FUNC1 和过程 PROC1 — 您可以使用

expdp ananda/iclaim directory=DPDATA1 dumpfile=expprocs.dmp
include=PROCEDURE:"='PROC1'",FUNCTION:"='FUNC1'"

这个转储文件充当了源对象的一个备份。您甚至可以用它来创建 DDL 脚本，以供之后使用。一个称为 SQLFILE 的特殊参数允许创建 DDL 脚本文件。

impdp ananda/iclaim directory=DPDATA1 dumpfile=expprocs.dmp sqlfile=procs.sql

该指令在 DPDATA1 指定的目录中创建一个名称为 procs.sql 的文件，并将对象的脚本包含在导出转储文件中。这种方法帮助您快速地在另一个模式中创建源对象。

利用参数 INCLUDE 允许您从转储文件中定义要包含或排除的对象。您可以使用子句 INCLUDE=TABLE:"LIKE 'TAB%'" 来仅导出那些名称以 TAB 开头的表。类似地，您可以使用结构 INCLUDE=TABLE:"NOT LIKE 'TAB%'" 来排除所有名称以 TAB 开头的表。作为另一种选择，您可以使用 EXCLUDE 参数来排除特定的对象。

通过外部表，Data Pump 还可以用来传输表空间；它非常强大，能够即时地重定义并行方式，将更多的表添加到一个现有的进程中等等（这超出了本文的范围；关于更多详细信息，请参考 Oracle Database Utilities 10g Release 1 10.1）。以下命令显示Data Pump 导出实用工具提供的所有参数的列表：

expdp help=y

类似地，impdp help=y 将显示 DPI 中的所有参数。

当 Data Pump 作业在运行时，您可以通过在 DPE 或 DPI 提示符下发出 STOP_JOB 来暂停它们，然后用 START_JOB 来重起它们。这个功能在您空间不足和想在继续执行之前进行修改时非常方便。

--end

Hotel California

2007-01-19T13:56:00.000+08:00

关于Eagles的“Hotel California”，的介绍几乎多到泛滥。从六七十年代摇滚乐的繁荣上升时期以来,数不清的人们被这首绝世佳作深深地打动.有些乐队不但多产，而且精品甚多,Eagles也是这样，但是正因为这首“加州旅馆”太过出色,以至人们只记得Eagles是唱"加州旅馆"的乐队。在九天音乐有整整一张cd，全是“加州旅馆”的不同版本的演绎。但是总归最最动人的，最最经典的,还是Eagles自己演绎的Unplugged版本，只有吉他，鼓声伴奏。步入中年的 Eagles，光芒四射的舞台，唯一被人们记住的“Hotel California”，歌词里如同宿命般断言:你永远也离不开“Hotel California”，了，Eagles的终生成就，似乎只有这首“Hotel California”，霜华染鬓，怕见人去，不如帘儿底下，静静听人欢笑。灯影车流中，穿越喧嚣繁华，“热闹是他们的，我什么也没有。”现场歌迷们的喝彩声浪里，是不被真正理解的Eagles的寂寞。借用中国的一句古语“成也萧何、败也萧何”，可能是《Hotel California》太成功了，以后，The Eagles再也没有创作出超过《Hotel California》的作品。或许是听众们太苛刻了，他们对这首歌曲近乎于崇拜的喜爱已使他们忽略了The Eagles其他的单曲。更有甚者，传说The Eagles到日本举行演唱会，演唱会第一支曲子就安排的是Hotel California，但演唱完了这首曲子之后,音乐会就走了近一半的人。

the eagles(老鹰乐队)

　　On a dark desert highway.
　　Cool wind in my hair.
　　Warm smell of colitas rising
　　Up through the air Up ahead in the distance.
　　I saw a shimmering light
　　My head grew heavy and my sight grew dim
　　I had to stop for the night
　　There she stood in the doorway
　　I heard the mission bell
　　And I was thinking to myself

　　This could be heaven or this could be hell
　　Then she lit up a candle
　　And she showed me the way
　　There were voices down in corridor
　　I thought I heard them say... ...
　　Welcome to the Hotel California
　　Such a lovely place (such a lovely face)
　　There's plenty of rooms at the
　　Hotel California
　　Any time of year you can find it here

　　Her mind is Tiffany-twisted
　　She got the Mercedes-Benz
　　She got a lot of pretty,
　　Pretty boys that she calls friends
　　How they dance in the courtyard
　　Sweet summer sweat
　　Some dance to remember
　　Some dance to forget
　　So I called up the captain
　　Please bring me my wine
　　He said we haven't had that spirit
　　Here since nineteen sixty nine
　　And still those voices are

　　Calling from far away
　　Wake you up in the middle of the night
　　Just to hear them say... ...
　　Welcome to the Hotel
　　California Such a lovely place
　　(such a lovely face)
　　They livin'it up at the Hotel California
　　What a nice surprise bring your alibis
　　Mirrors on the ceilling
　　The pink champagne on ice

　　And she said we are all just prisoners
　　Here of our own device
　　And in the master's chambers
　　They gathered for the feast
　　They stab it with their steely knives
　　But they just can't kill the beast

　　Last thing I remember,
　　I was running for the door
　　I had to find the passage back
　　To the place I was before
　　Relax said programmed to receive
　　You can check out any time you like
　　But you can never leave

download it

--end

自动化测试的思考和总结之天下三分篇

2007-01-19T12:43:00.000+08:00

对于自动化测试的组织划分,一般来说,在企业内部,有两种结构: 隶属于系统测试部门或者专门的自动化测试部门.

我所经历的自动化测试部门,就经过这么一波三折的过程,首先始于系统测试部门的一个team,专门为这个产品的系统测试服务,自动化也就仅仅局限于这个产品的系统回归测试. 随着自动化程度的不断提高和管理层的重视,自动化测试也逐步发展壮大,服务的部门也从仅仅是系统测试部门的回归测试拓展到集成测试,单元测试等等. 服务的产品也从单一的产品扩大到整个公司的产品. 这是一个必然的过程. 专门的自动化测试部门有利于从整个公司的角度协调各种资源,所以是必然的.

在自动化测试独立成单独的部门,角色一般是这样:有一个经验丰富的自动化经理,负责全局的统筹和管理. 对于不同的产品或者不同的系统有资深的自动化测试专家/自动化测试主管, 下面会有专门的自动化测试工程师,对自动化测试工程师甚至资深自动化测试专家要求首先有过开发经验,并且有一定的测试经验,做过手工测试,这个必须的,另外,对相关的产品要比较熟悉. 另外对资深自动化测试专家要求对被测系统的架构有全面和深刻的理解. 另外可能还有一些自动化测试工程师或者测试工程师, 来执行相关的自动化测试用例. 这些测试工程师要求对系统要相当了解,可以从手工测试部门抽调过来,也可以本身就属于系统测试部门, 这样就是一个虚拟的泛自动化测试部门.

有了组织结构,就可以进行自动化测试了吗,当然不, 首先自动化测试需要以来很多的因素,自动化测试平台就是其中一个,下节重点介绍自动化测试的平台建设.

--to be continued

自动化测试的思考和总结之天时地利篇

2007-01-18T13:39:00.000+08:00

昨天谈到自动化适合的产品,今天简单聊聊何时开始引入自动化最有效.

自动化测试的建设不是一蹴而就的,首先自动化测试的发展依赖于手工测试.
一般来说,手工测试进展到比较成熟的阶段,公司有完整的手工测试流程,相应的手工测试工程师具有一定的编程经验或者脚本开发经验,这个时候引入自动化测试才会比较有效.

相反,如果一个公司或者一个产品基本的手工测试都很不完善和规范,测试的质量也得不到保证,更谈不到测试的覆盖率,这个时候贸然的想通过实行自动化来提高测试的质量或者测试的效率.失败的机会就会非常大了.

完善的自动化测试流程和规范不是简单的几个文档就能解决问题的,而是要把这种流程或者规范彻底贯彻到每个测试工程师身上. 测试用例如何写? 产品规格说明书更新及时不及时?有没有符合本公司的测试管理系统? 测试报告能不能按时提交?等等一系列问题,不是简单停留在是否存在几篇文档或者开几次会议就能解决的问题.

现在国内我知道好多朋友所在的公司,看到自动化测试不错,可以提高效率,节省人力,老板就拍脑袋也要搞自动化,好像搞了自动化测试,公司的测试水平就能提高一个台阶,产品的质量就能得到保证. 其实他完全没有看到自动化测试的另外一面. 另外,居然还有人理解我引入了几个自动化测试工具WinRunner, QTP, LoadRunner, 我就是自动化测试了. 大错特错了.
关于测试工具和自动化测试的话题,后面会有讨论.

一个公司或者一个产品在引入自动化测试之前,一定要进行详细和客观的评估.

--to be continued

自动化测试的思考和总结之有的放矢篇

2007-01-17T13:10:00.000+08:00

对于自动化测试适合的产品,或者更精确到哪些测试测试适合做自动化,已经被广泛的讨论过.总体来说, 有如下一些:

1. 首先是回归测试,这是勿庸置疑的.
利用自动化来进行回归测试,不仅可以把测试工程师从枯燥无味的繁琐测试中解脱出来,而且可以腾出更多的时间设计更多更好的测试用例,提供测试的覆盖率和测试的质量.
2. 其次是部分性能测试
对于一些性能测试,比如系统容量或者系统并发用户的测试,因为资源的限制,利用手工测试有很大的困难,有时候条件也不允许,充分利用一些自动化性能测试工具,就可以很好的完成测试目的.
3. 还有就是利用手工很困难或者根本无法完成的.
有的时候,需要进行一些压力测试,离开工具可能比较困难,这个时候就可以发挥自动化的长处.
4. 还有就是产品趋于稳定,变化小,这样的产品更适合与自动化,我们就曾经在一个产品很不完善的时候进入到自动化,结果耗费了巨大的人力,最后产品变化了,自动化测试脚本和测试用例重用性不好,基本全废了. 其实这也需要产品和软件本身应该满足一些可测性要求. 并在前后的版本之间保持接口的统一. 细节来说,就是配置哪怕是基本的日志都必须满足一定的规范. 否则自动化测试进展起来就比较困难.

另外,无论针对任何产品的自动化测试,都会存在一些普遍的问题:
1. 自动化测试不会比系统测试发现更多的bug,或者说自动化测试更重要的是帮助快速验证产品经过更新或者修改之后的质量.如果要发现更多的潜在问题,必须进行手工测试.
2.对于频繁变化的产品,自动化测试的维护成本很高,这点反复强调,就是因为我们在这方面走过很多弯路,往事不堪回首啊~~
3.通过自动化测试没有发现缺陷并不能代表说一定没有缺陷存在,没有权限的系统或者产品是不存在的.
4.自动化测试对环境的依赖远远大于手工测试对环境的依赖,针对自动化测试的环境问题,因为牵涉到的问题比较多,后面打算专门讨论这个问题.

自动化测试的思考和总结之开篇

2007-01-16T13:02:00.000+08:00

自己从事自动化测试三年了,经历了很多的波折和教训,当然也积累了些许的经验,很久以来一直有想法把这些内容系统的记录下来,对自己来说,轻装上阵,更好的探索以后的自动化怎么走;对别人来说,也算提个醒,哪些错误最容易犯, 需要避免什么样的误区.
最近看了很多的论坛文章,感觉大家都很茫然,测试怎么做, 刚入行的, 在这个行业打拼了几年的,大家对前途都没有太多的目标,也许只能好好反省自己的过去,总结一下自己过去犯过的错误,回过头去,才能更好的认识前面的路.
罗嗦了这么多,现在开篇,本文打算以系列的形式连载,主要都是自己的经验和教训的回顾,所以有时候想到哪儿就说到哪里,不会刻意去组织很美的文字,不过我会尽量使文章能表达我的意思. 这个系列目前大致想分为几个大的部分:

自动化测试的适合产品
何时引入自动化
自动化测试的组织结构
自动化测试的平台建设
自动化测试的支持和维护
自动化测试和自动化测试工具
自动化测试的管理保证
自动化测试和回归测试

下次着重讲讲自动化测试的适合产品.

--to be continue

网易新闻2006科举大典

2007-01-15T13:50:00.000+08:00

读了一年的网易新闻
年终了
就像大学例行的期末考试

从童试
院试
乡试
会试
到殿试

排艰辛
过五关
一切尽在恶搞中

请参考科举大典
看看你是否需要补考?
能否毕业

疑,我怎么成了诗人聊.

--end

一些软件测试概念的标准定义(下篇)

2007-01-15T10:53:00.000+08:00

test documentation. (IEEE) Documentation describing plans for, or results of, the testing of a system or component, Types include test case specification, test incident report, test log, test plan, test procedure, test report.

test driver. (IEEE) A software module used to invoke a module under test and, often, provide test inputs, control and monitor execution, and report test results. Syn: test harness.

test incident report. (IEEE) A document reporting on any event that occurs during testing that requires further investigation.

test item. (IEEE) A software item which is the object of testing.

test log. (IEEE) A chronological record of all relevant details about the execution of a test.

test phase. (IEEE) The period of time in the software life cycle in which the components of a software product are evaluated and integrated, and the software product is evaluated to determine whether or not requirements have been satisfied.

test plan. (IEEE) Documentation specifying the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, responsibilities, required, resources, and any risks requiring contingency planning. See: test design, validation protocol.

test procedure. (NIST) A formal document developed from a test plan that presents detailed instructions for the setup, operation, and evaluation of the results for each defined test. See: test case.

test report. (IEEE) A document describing the conduct and results of the testing carried out for a system or system component.

test result analyzer. A software tool used to test output data reduction, formatting, and printing.

testing. (IEEE) (1) The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component. (2) The process of analyzing a software item to detect the differences between existing and required conditions, i.e. bugs, and to evaluate the features of the software items. See: dynamic analysis, static analysis

testing, acceptance. (IEEE) Testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. Contrast with testing, development; testing, operational.

testing, alpha []. (Pressman) Acceptance testing performed by the customer in a controlled environment at the developer's site. The software is used by the customer in a setting approximating the target environment with the developer observing and recording errors and usage problems.

testing, assertion. (NBS) A dynamic analysis technique which inserts assertions about the relationship between program variables into the program code. The truth of the assertions is determined as the program executes.

testing, beta []. (1) (Pressman) Acceptance testing performed by the customer in a live application of the software, at one or more end user sites, in an environment not controlled by the developer. (2) For medical device software such use may require an Investigational Device Exemption [IDE] or Institutional Review Board [IRB] approval.

testing, boundary value. A testing technique using input values at, just below, and just above, the defined limits of an input domain; and with input values causing outputs to be at, just below, and just above, the defined limits of an output domain. See: boundary value analysis; testing, stress.

testing, branch. (NBS) Testing technique to satisfy coverage criteria which require that for each decision point, each possible branch [outcome] be executed at least once. Contrast with testing, path; testing, statement. See: branch coverage.

testing, compatibility. The process of determining the ability of two or more systems to exchange information. In a situation where the developed software replaces an already working program, an investigation should be conducted to assess possible comparability problems between the new software and other programs or systems.

testing, exhaustive. (NBS) Executing the program with all possible combinations of values for program variables. Feasible only for small, simple programs.

testing, functional. (IEEE) (1) Testing that ignores the internal mechanism or structure of a system or component and focuses on the outputs generated in response to selected inputs and execution conditions. (2) Testing conducted to evaluate the compliance of a system or component with specified functional requirements and corresponding predicted results. Syn: black-box testing, input/output driven testing. Contrast with testing, structural.

testing, integration. (IEEE) An orderly progression of testing in which software elements, hardware elements, or both are combined and tested, to evaluate their interactions, until the entire system has been integrated.

testing, interface. (IEEE) Testing conducted to evaluate whether systems or components pass data and control correctly to one another. Contrast with testing, unit; testing, system. See: testing, integration.

testing, mutation. (IEEE) A testing methodology in which two or more program mutations are executed using the same test cases to evaluate the ability of the test cases to detect differences in the mutations.

testing, operational. (IEEE) Testing conducted to evaluate a system or component in its operational environment. Contrast with testing, development; testing, acceptance; See: testing, system.

testing, parallel. (ISO) Testing a new or an altered data processing system with the same source data that is used in another system. The other system is considered as the standard of comparison. Syn: parallel run.

testing, path. (NBS) Testing to satisfy coverage criteria that each logical path through the program be tested. Often paths through the program are grouped into a finite set of classes. One path from each class is then tested. Syn: path coverage. Contrast with testing, branch; testing, statement; branch coverage; condition coverage; decision coverage; multiple condition coverage; statement coverage.

testing, performance. (IEEE) Functional testing conducted to evaluate the compliance of a system or component with specified performance requirements.

testing, qualification. (IEEE) Formal testing, usually conducted by the developer for the consumer, to demonstrate that the software meets its specified requirements. See: testing, acceptance; testing, system.

testing, regression. (NIST) Rerunning test cases which a program has previously executed correctly in order to detect errors spawned by changes or corrections made during software development and maintenance.

testing, statement. (NIST) Testing to satisfy the criterion that each statement in a program be executed at least once during program testing. Syn: statement coverage. Contrast with testing, branch; testing, path; branch coverage; condition coverage; decision coverage; multiple condition coverage; path coverage.

testing, storage. This is a determination of whether or not certain processing conditions use more storage [memory] than estimated.

testing, stress. (IEEE) Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements. Syn: testing, boundary value.

testing, structural. (1) (IEEE) Testing that takes into account the internal mechanism [structure] of a system or component. Types include branch testing, path testing, statement testing. (2) Testing to insure each program statement is made to execute during testing and that each program statement performs its intended function. Contrast with functional testing. Syn: white-box testing, glass-box testing, logic driven testing.

testing, system. (IEEE) The process of testing an integrated hardware and software system to verify that the system meets its specified requirements. Such testing may be conducted in both the development environment and the target environment.

testing, unit. (1) (NIST) Testing of a module for typographic, syntactic, and logical errors, for correct implementation of its design, and for satisfaction of its requirements. (2) (IEEE) Testing conducted to verify the implementation of the design for one software element; e.g., a unit or module; or a collection of software elements. Syn: component testing.

testing, usability. Tests designed to evaluate the machine/user interface. Are the communication device(s) designed in a manner such that the information is displayed in a understandable fashion enabling the operator to correctly interact with the system?

testing, volume. Testing designed to challenge a system's ability to manage the maximum amount of data over a period of time. This type of testing also evaluates a system's ability to handle overload situations in an orderly fashion.

traceability matrix. (IEEE) A matrix that records the relationship between two or more products; e.g., a matrix that records the relationship between the requirements and the design of a given software component. See: traceability, traceability analysis.

usability. (IEEE) The ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component.

validation. (1) (FDA) Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specifications and quality attributes. Contrast with data validation.

validation, verification, and testing. (NIST) Used as an entity to define a procedure of review, analysis, and testing throughout the software life cycle to discover errors, determine functionality, and ensure the production of quality software.

verification, software. (NBS) In general the demonstration of consistency, completeness, and correctness of the software at each stage and between each stage of the development life cycle. See: validation, software.

Oracle Database 10g：数据库管理员提供的20个最重要的特性（三）

2007-01-15T08:33:00.000+08:00

第 3 周
名字中包含了什么？：改善的表空间管理

表空间管理得到了重大的改进，这可以归因于一个 sparser SYSTEM、为用户定义一个默认表空间的支持、新的 SYSAUX、甚至重命名

您曾经多少次因用户在 SYSTEM 表空间中创建了非 SYS 和 SYSTEM 的段而伤透脑筋？

在 Oracle9i Database 之前，如果在创建用户时没有指定默认表空间，那么它将默认为 SYSTEM 表空间。如果用户在创建一个段时没有显式地指定一个表空间，那么这个段将在 SYSTEM 中创建—前提是用户在 SYSTEM 表空间中拥有配额（要么显式地授予，要么通过系统权限 UNLIMITED TABLESPACE 来授予）。Oracle9i 允许 DBA 为所有未用显式的临时表空间子句创建的用户指定一个默认的临时表空间，从而减少了这个问题。

在 Oracle Database 10g 中，您可以类似地为用户指定一个默认表空间。在数据库创建期间，CREATE DATABASE 命令可以包含子句 DEFAULT TABLESPACE 。在创建之后，您可以通过发出以下命令来使一个表空间变成默认表空间

ALTER DATABASE DEFAULT TABLESPACE ;

未用 DEFAULT TABLESPACE 子句创建的所有用户将以作为它们的默认表空间。您可以在任何时候通过这个 ALTER 命令来改变默认表空间，从而允许您在不同的节点上将不同的表空间指定为默认表空间。

重要注意事项：拥有旧的表空间的所有用户的默认表空间都被修改为，即使有些表空间是为某些用户显式指定的。例如，假定用户 USER1 和 USER2 的表空间分别是 TS1 和 TS2 — 它们是在用户创建期间显式指定的。数据库当前的默认表空间是 TS2，但之后，数据库的默认表空间变为 TS1。即使 USER2 的默认表空间是显式指定为 TS2 的，它也将变为 TS1。小心这种边界效应！

如果在数据库创建期间没有指定默认表空间，它将默认为 SYSTEM。但您如何才能知道现有的数据库的默认表空间是哪一个？发出以下查询：

SELECT PROPERTY_VALUE
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME = 'DEFAULT_PERMANENT_TABLESPACE';

DATABASE_PROPERTIES 视图显示默认表空间之外，还显示一些非常重要的信息 — 例如默认临时表空间、全局数据库名、时区等。

非必要模式的默认表空间

几种模式（如智能代理用户 DBSNMP、数据挖掘用户 ODM）与用户操作不直接相关，但对数据库完整性仍很重要。这些模式中的一些曾经用 SYSTEM 作为它们的默认表空间 — 这是在 SYSTEM 表空间内对象增殖的又一个原因。

Oracle Database 10g 引进了一个新的称为 SYSAUX 的表空间，它用来保存这些模式的对象。这个表空间是在数据库创建期间自动创建的，并在本地进行管理。唯一允许修改的是数据文件的名称。

这种方法在 SYSTEM 损坏需要完整的数据库恢复时，为恢复提供支持。SYSAUX 中的对象可以被恢复为任意正常的用户对象，同时数据库本身保持运行。

但如果您想将 SYSAUX 中的这些模式中的一些转移到一个不同的表空间中时，该怎么办？例如，考虑 LogMiner 使用的对象，这些对象的大小经常增长，直到最终填满表空间。出于可管理性的原因，您可能考虑将它们转移到它们自己的表空间中。但实现这一目的的最好的方法是什么？

作为一个数据库管理员，了解转移这些特殊对象的正确过程对您而言是很重要的。幸运的是，Oracle Database 10g 提供了一个新的视图使要凭猜测来做的工作形象化。这个视图，V$SYSAUX_OCCUPANTS，列出了表空间 SYSAUX 中的模式的名称、它们的说明、当前使用的空间，以及如何转移它们。（参见表 1。）

注意 LogMiner 如何被清楚地显示为占用 7,488 KB 的空间。它归模式 SYSTEM 所有，而要转移对象，您需要执行打包的过程 SYS.DBMS_LOGMNR_D.SET_TABLESPACE。不过，对于 STATSPACK 对象，这个视图推荐使用导入/导出方法；而对于流，没有转移过程 — 因而您不能容易地将它们从 SYSAUX 表空间中转移出来。列 MOVE_PROCEDURE 默认显示 SYSAUX 中存在的几乎所有工具的正确的转移过程。也可以逆向使用转移过程来使对象回到 SYSAUX 表空间中。

重命名一个表空间

在数据仓库环境中（典型地，对于数据中心体系结构），在数据库之间传输表空间是很常见的。但源数据库和目标数据库必须不存在拥有相同名称的表空间。如果存在两个拥有相同名称的表空间，则目标表空间中的段必须转移到一个不同的表空间中，然后重新创建这个表空间— 这个任务说起来容易做起来难。

Oracle Database 10g 提供了一个方便的解决方案：您可以用以下命令来简单地重命名一个现有的表空间（SYSTEM 和 SYSAUX 除外） — 无论是永久表空间还是临时表空间：

ALTER TABLESPACE  RENAME TO ;

这个功能还将应用在存档过程中。假定您有一个按范围分区的表，用于记录销售历史数据，每个月的这个分区位于按这个月份命名的一个表空间中 — 例如，1 月份的分区命名为 JAN，并位于一个名称为 JAN 的表空间中。这样您就拥有了一个将信息保留 12 个月的策略。在 2004 年 1 月，您将能够存档 2003 年 1 月的数据。大致的操作流程类似于以下操作：

利用 ALTER TABLE EXCHANGE PARTITION 从分区 JAN 中创建一个独立的表 JAN03。
将表空间重命名为 JAN03。
为表空间 JAN03 创建一个可传输表空间集。
将表空间 JAN03 重新命名为 JAN。
将空的分区交换回表中。

第 1、2、4 和 5 步很简单，并且不会过度地消耗资源（如重做和撤消空间）。第 3 步只是拷贝文件并只为 JAN03 输出数据字典信息，这也是个非常轻松的过程。如果您需要恢复之前存档的分区，这个过程也非常简单，您只需要将相同的过程反过来就行了。

Oracle Database 10g 在处理这些重命名的方式上相当智能化。如果您重命名作为 UNDO 或默认临时表空间的表空间，这可能产生混淆。但数据库将自动调整必要的记录来反映这种变化。例如，将默认表空间的名称从 USERS 修改为 USER_DATA 将自动修改视图 DATABASE_PROPERTIES。在修改之前，查询：

select property_value from database_properties
where property_name = 'DEFAULT_PERMANENT_TABLESPACE';

返回 USERS。在运行下面的语句之后

alter tablespace users rename to user_data;

上述查询返回 USER_DATA，因为所有对 USERS 的引用都被修改为到 USER_DATA。

修改默认临时表空间的情况一样。甚至修改 UNDO 表空间的名称也将触发 SPFILE 中的变化，如下所示：

SQL> select value from v$spparameter where name = 'undo_tablespace';

VALUE
--------
UNDOTBS1

SQL> alter tablespace undotbs1 rename to undotbs;

Tablespace altered.

SQL> select value from v$spparameter where name = 'undo_tablespace';

VALUE
--------
UNDOTBS

结论

在最近的几个 Oracle 版本演变的过程中，对象处理得到了稳定的增强。Oracle8i 引进了表从一个表空间到另一个表空间的转移，Oracle 9i Database R2 引进了列重命名，现在 — 在最新的版本中 — 表空间自身的重命名成为可能。这些增强显著地减轻了数据库管理员的任务 — 特别是在数据仓库或数据中心环境中。

--end

新域名终于可以访问了

2007-01-14T15:26:00.000+08:00

新域名终于可以访问了，不过暂时只能通过代理，代理的设置可以参考这篇文章

一些常用的免费日本和韩国代理列在下面：

　免费韩国代理服务器列表

　　165.228.128.10：3128

　　59.10.72.198：8080

　　125.248.206.194：8080

　　125.243.249.194：8080

　　210.107.249.50：3128

　　210.107.249.50：3124

　　210.180.39.92：8080

　　210.102.99.71：38466

　　免费日本代理服务器列表

　　58.80.207.41：3128

　　133.1.16.172：3127

　　150.65.32.66：3124

　　203.178.133.2：3128

　　203.178.133.10：3128

　　203.178.133.2：3124

　　203.178.133.3：3127

　　203.178.133.10：3124

高兴之余，也要show一下第一次成功访问的截图，再次只想说两句话：

谁让你生在中国！

I am back!

--end

Google域名已经成功绑定

2007-01-14T15:09:00.000+08:00

昨天晚上折腾了大半天，利用Blogger提供的主机绑定服务把新域名给绑定了，不过始终还是不能访问我的新域名:www.rickyzhu.com

一度尝试搜索一个国外的免费主机托管服务网站，找到了很多，也成功在kingofhosts.com上注册并进行了域名托管，似乎有些地方设置不对，而且web上进行文件上传功能似乎很弱，还是观望一下看。下面是kingofhosts提供的一些功能，看样子还不错。

KingofHosts has industry leading features that will allow you to build a website above and beyond your competitors, take a look at some of them:

~~1,000mb Disk Space~~ 5,000mb disk space (5gb!)
~~10,000mb Bandwidth~~ 50,000mb bandwidth (50gb!).
NO ADVERTISEMENTS on your pages!
FREE subdomain (yourname.KingofHosts.com)
Easy to use WYSIWYG editor
Full FTP Support
PHP 4 Support
~~1 mySQL database~~ 10 mySQL database's
Instant activation
Domain name support
99.9% Uptime
and MORE...

没有强制广告，5GB的空间，50GB的带宽，支持MYSQL数据库和二级域名，似乎看起来不错，如果实在不行，就仔细研究研究这个吧。

今天在DNS的设置页面把CNAME设置成ghs.google.com. （似乎后面多了一个点), 很快，在万网上就可以查到我的网站的IP地址，先是托管成功，只是还访问不了，万恶的社会~~

您好！经查询，贵网站:www.rickyzhu.com 不是由中国万网提供主机服务贵网站IP地址为： 64.233.179.121

看来果真验证了之前的说法：参考月光博客的一篇文章。

尝试一下代理吧！

--end

我的Google域名捆绑梦破灭了

2007-01-13T14:37:00.000+08:00

昨天还在说，我的新域名估计两天后启用，看来似乎不那么现实了。

以下转载: Google的免费主机玩完啦

今天发现，我前几天刚使用Google免费Bloger托管服务绑定的一个域名，今天发现其已经IP无法访问，但是通过代理服务器却访问正常，因此我怀疑，Google Blogger仅仅发布数天的新服务：Blogger Custom Domains，可能已经被封了IP。

　　主要原因是这个IP：64.233.179.121，所有绑定的域名都指向这个IP，因此这个IP总有一天会被屏蔽掉，只是我没想到这一天会这么快到来。

　　下面是我Trace这个IP的结果，可以看到，访问到202.97.35.49这个IP后就无法继续访问了。

202.97.35.49这个IP又是何方神圣呢？通过查询得知是“中国电信骨干路由器”。下面是查询的截图，这下明白了吧。

当然，我通过韩国或日本的代理服务器访问我绑定的域名，一切正常，直接访问就无法连接。看来大家还是购买自己的主机吧，免费的好东东我们中国人还是用不了滴，还是通过FTP发布到自己主机上更为保险一些啦。

看来我又要破费了。55555~~~~，真命苦啊。

--end

这三年自动化测试的思考和总结（原创）

2007-01-13T14:32:00.001+08:00

搞自动化测试也有三年的时间了，最近总感觉没有多少提高，进步不大。不像最初的两年，总能接触到很多新的知识，进步也快。我也在思索这个问题和造成问题的根本原因，很多方面影响。当初开始的时候是一穷二白，所以有点点进展也算是很令人高兴和激动人心的，现在总在思索要怎么发展，怎么改进。似乎国内的自动化测试发展很慢，这跟很多公司的管理层有很大关系的，另外，公司的大环境也决定整个的自动化测试的成败。我私下认为，国内的管理者大多眼光没有那么长远，急功近利。恰恰相反，自动化测试又是一个需要长期投入的过程，而且不容易出成效的系统工程，这也难怪国内的自动化测试发展慢。还是从最初做自动化这一路走来开始总结一下吧：

初次接触自动化测试应该是2003年了，我们公司实施了自动化测试，一个有多年的自动化测试经验的老板带领我们做,目标明确，也得到了管理程的鼎力支持。进展虽然比较慢却也比较顺利。

我们经历了几个比较大的阶段，从当初的第一种模式（隶属于系统测试部门），到后来独立出一个公司级别的自动化测试部门，一直到现在覆盖了公司几大产品。中间我们也走了很多的弯路。

目前我们有一个比较完善的自动化测试平台，测试管理和测试执行是分开进行的。我们构建了一系列独立于产品的基本函数库和大量的产品相关的业务函数库，系统测试工程师或者自动化测试工程师可以利用这些函数库去构造自动化测试用例，然后利用平台去执行。

我们还把Mercuy（现在的HP Mercury）的几大产品都集成到了我们的自动化测试平台，QTP, WR 和LR。可以从我们的自动化测试平台去调用这些工具去执行相关的功能或者性能测试。

近一年以来，我们的自动化似乎进展并不大，除了提供更多的业务函数和维护基本的函数库，在架构上并没有太多的改动，系统测试工程师似乎也习惯了我们的这种思路和平台，从朱少民老师的《功能测试自动化的投入和产出》这篇文章，我看到了其中几个框架的投入产出比，我想我们应该属于第四种－framework structure，基于数据驱动的也许不太适于我们公司的这些产品（流程更新频繁，稳定度不高）。

至于以后的自动化应该怎么发展，我想可能是需要认真思考的问题的。

--end

Oracle Database 10g:为DBA提供的最佳前20位的特性（二）

2007-01-13T11:27:00.000+08:00

第一个特性就是前面的那篇<Oracle10g中如何追踪数据操作历史>
从本周开始，陆续介绍这20位特性，敬请留意。

Oracle Database 10g:为 DBA 提供的最佳前 20 位的特性第 2 周

第 2 周
还要多长时间？：回滚监视

为用户提供对回滚操作时间的准确评估

我们还在这地方吗？还要多长时间？

听起来熟悉吗？这些问题可能是您在前往孩子们最喜爱的主题公园的路上，从汽车后座上提出来的，并且经常是不断地、越来越频繁地提出来。您不想告诉他们还确切需要多长时间吗 — 或者更简单些，您自己知道答案吗？

同样，在回滚长期运行的事务时，经常会有些用户不停地询问相同的问题。这些问题是合理的，因为该事务进行了锁定，正常的处理经常受到回滚进程的影响。

在 Oracle 9i Database 及更低的版本中，您可以执行查询

SELECT USED_UREC
FROM V$TRANSACTION;

该语句返回由当前事务所使用的重做记录的数量，而如果重复地执行该语句，将会显示连续减少的数值，因为回滚进程在其处理过程中会释放重做记录。随后您可以通过对一段间隔进行快照来计算其速率，然后推断出评估结束时间的结果。

虽然在视图 V$TRANSACTION 中有一个名为 START_TIME 的列，但该列只显示整个事务的起始时间（也就是在回滚执行之前）。因此，除了推断，您没有办法知道回滚实际上是在什么时间执行的。

事务回滚的扩展统计信息

在 Oracle Database 10g 中，这种操作很简单。当事务回滚时，事件被记录在视图 V$SESSION_LONGOPS 中，该视图显示长期运行的事务。用于回滚，如果进程耗时超过六秒，则记录出现在该视图中。在回滚执行以后，您可能会隐藏所查看的监视屏幕并执行以下的查询：

select time_remaining
from v$session_longops
where sid = <sid of the session doing the rollback>;

既然您意识到这个视图 V$SESSION_LONGOPS 的重要性，就让我们来看它必须提供的其他信息。该视图在 Oracle Database 10g 的预览版中提供，但没有捕获关于回滚事务的信息。为了以一种易读的方式显示所有的列，我们将使用由 Tom Kyte 在 AskTom.com 中所描述的 PRINT_TABLE 函数。此过程简单地以表格方式而不是常用的行方式来显示列。

SQL> set serveroutput on size 999999
SQL> exec print_table('select * from v$session_longops where sid = 9')
SID : 9
SERIAL#                       : 68
OPNAME                        :Transaction Rollback
TARGET                        :
TARGET_DESC                   :xid:0x000e.01c.00000067
SOFAR                         : 20554
TOTALWORK                     : 10234
UNITS                         :Blocks
START_TIME                    :07-dec-2003 21:20:07
LAST_UPDATE_TIME              :07-dec-2003 21:21:24
TIME_REMAINING                : 77
ELAPSED_SECONDS               : 77
CONTEXT                       : 0
MESSAGE                       :Transaction Rollback:xid:0x000e.01c.00000067 :
10234 out of 20554 Blocks done
USERNAME                      ：SYS
SQL_ADDRESS                   :00000003B719ED08
SQL_HASH_VALUE                : 1430203031
SQL_ID                        :306w9c5amyanr
QCSID                         : 0

注意，此处显示对行的所有更改，即使删除并重新插入行时也是如此。VERSION_OPERATION 列显示对该行执行的操作 (Insert/Update/Delete)。完成这些操作不需要历史表或额外的列。

让我们仔细检查这些列中的每一列。在会话中可能会有超过多个长期运行操作 — 特别是因为视图中包含以前的会话中所有长期运行操作的历史。列 OPNAME 显示该记录用于“事务回滚”，这为我们指出了正确的方向。列 TIME_REMAINING 显示所评估的剩余时间秒数，这在前面已经描述过，而列 ELAPSED_SECONDS 显示到目前为止所消耗的时间。

那么该表如何提供对剩余时间的评估呢？可以在列 TOTALWORK 中找到线索，该列显示要完成的“工作”总量，还有 SOFAR 显示到目前为止已经完成了多少工作。工作的单位显示在列 UNITS 中。在本例中以数据块为单位；因此，到目前为止已经回滚了 20,554 个数据块中共计 10,234 个数据块。此操作到目前为止已消耗了 77 秒。因此，剩余数据块将消耗：

77 * ( 10234 / (20554-10234) ) ˜ 77 秒

但您不必利用这种方法来获得该数值，它已经清楚地显示出来了。最后，列 LAST_UPDATE_TIME 显示有关当前视图内容的时间，这将用于加强您对结果的解释。

SQL 语句

另一部分重要的新信息是正在被回滚的 SQL 语句的标识符。在早先，SQL_ADDRESS 和 SQL_HASH_VALUE 用于获取正在被回滚的 SQL 语句。新的列 SQL_ID 对应于视图 V$SQL 的 SQL_ID，如下所示：

SELECT SQL_TEXT
FROM V$SQL
WHERE SQL_ID = <value of SQL_ID from V$SESSION_LONGOPS>;

该查询返回所回滚的语句，因此提供了额外的校验以及 SQL 语句的地址和散列值。

并行实例恢复

如果 DML 操作是并行操作，则列 QCSID 显示并行查询服务器会话的 SID。在并行回滚事件中，如实例恢复以及随后的故障事务恢复期间，经常用到该信息经常。

例如，假设在大型的更新期间，实例异常关闭。当实例启动时，发生故障的事务被回滚。如果启用了用于并行恢复的初始化参数值，则回滚并行地而不是串行地发生，如同它发生在常规事务回滚中一样。下一步的任务是评估回滚进程的完成时间。

视图 V$FAST_START_TRANSACTIONS 显示为回滚故障事务所产生的事务。类似的视图 V$FAST_START_SERVERS 显示对回滚进行处理的并行查询服务器的数量。这两个视图都在以前的版本中提供，但显示事务标识符的新列 XID 使得联接更方便了。在 Oracle9i Database 以及更低的版本中，您必须通过三列（USN — 重做段号，SLT — 重做段中的存储区号，SEQ — 序列号）来联接视图。其父集显示在 PARENTUSN、PARENTSLT 和 PARENTSEQ 中。在 Oracle Database 10g 中，您只需将其联接到 XID 列，其父 XID 由直观的名称表示：PXID。

最有用的信息部分来自于 V$FAST_START_TRANSACTIONS 视图中的列 RCVSERVERS。如果发生并行回滚，则该列中显示并行查询服务器的数量。您可以查看该列，了解启动了多少并行查询进程：

select rcvservers from v$fast_start_transactions;

如果输出是 1，则事务正在由 SMON 进程进行串行回滚 — 显然这是完成工作的一种不充分的方法。您可以将初始化参数 RECOVERY_PARALLELISM 的值改为除 0 或 1 以外的值，重新启动实例进行并行回滚。随后您可以执行 ALTER SYSTEM SET FAST_START_PARALLEL_ROLLBACK = HIGH，按 CPU 数量的 4 倍创建并行服务器。

如果上述查询的输出显示不是 1，则正在进行并行回滚。您可以查询同一视图 (V$FAST_START_TRANSACTIONS) 来获得父事务和子事务（父事务 id — PXID，而子事务 id — XID）。XID 还可用于联接此视图与 V$FAST_START_SERVERS，以获得其他详细信息。

结论

总之，当在 Oracle Database 10g 中回滚长期运行的事务时 — 无论是并行实例恢复会话还是用户执行的回滚语句 — 您所需做的一切就是查看视图 V$SESSION_LONGOPS 并评估还需要多少时间。

现在，如果能预测到达主题公园的时间就好了！

--end

终于拥有自己的域名了

2007-01-12T17:43:00.000+08:00

自从去年的blogger告别beta之后, 前一阵子又推出了一项新功能:域名捆绑.

这对于很久以来就渴望拥有自己域名的特别象我这样又懒于维护一大堆文件的用户来说,无疑十分兴奋.

今天注册了一个自己的域名,59块大洋/年. 找了半天,心仪的域名都被别人抢走了,只能将就了. 不过还要等一天之后才能生效.

ricky.com.cn, ricky.com, ricky.net 都被注册走了.

只能选rickyzhu.com了.

在blogger上进行简单的设置即可把原来的老域名重定向到这个新域名了:

首先把域名坐CNAME设置到ghs.google.com,然后再控制台那,选择设置->发布->自定义域,添上域名即可.

看看blogger的官方网站对这个新功能的描述:

The new version of Blogger now supports using a custom domain for serving your blog. If you already own a domain named, say, mysite.com and want your blog to be served at that address instead of at a blogspot.com address, we can host your blog on that domain for you ― for free. Your old Blog*Spot address will forward to your new custom domain, so the switch will be seamless for your readers.

Of course, FTP publishing is still available if you'd like to do your own hosting, but using a custom domain gives you a ton of advantages:

Simpler to set up. You don't have to muck around with FTP paths and file names.
Fast publishing. There's no waiting for files to upload to a hosting provider.
Drag-and-drop template editing. You can use the new Blogger's new template features.
Access control. If you'd like, only let people you choose read your blog.

Using Blogger's custom domains is a simple way to start serving your blog on your own domain without having to deal with the hassle of transferring the files to a separate web host.

看来这个周末应该可以用上新域名了. 呵呵.

--end

如何挑选适合你的自动化测试工具

2007-01-12T14:43:00.000+08:00

任何工具没有最好的,只有最适合的. 自动化测试工具也是如此. 针对不同的公司,不同的应用,如何挑选最适合自己的自动化测试工具?

下面的几点也许可以作为你的参考.

List of points on which the new automation tool for functional and

regression testing is evaluated:

1. Ability to Identify all controls i.e. support Custom controls

2. Number of controls supported - Windows, IE, Netscape, .Net, Java

3. Number of OS Lang supported - English, Japanese, French etc.,

4. Number of DBs supported - MSSQL, Oracle, DB2 etc, [Execution of

Simple queries, Sprocs, Resultset, etc]

5. Number of environments supported - win32, web

6. Ability to read write from different sources [db, txt, word, excel,

reg etc.,]

7. Should have good error handling mechanism.

8. Dependencies on hardware/software - any new hardware/software to be

installed.

9. Ability to run with out the software being installed on each and

every machine.

10.Ability to interact with other interfaces [software's] - API's

11.Should be easy to learn and use.

12.Operational constraints - cost\support\training.

13.Tool should have good reference for its acceptance.

14.Tool should have backward compatibility.

15.Tool should be pluggable to standard test frameworks available in

the industry.

16.Ability to Analyze results, generate report and send it across.

[Even though it falls under framework.]

已经大致圈定了一些供应商和一些候选工具,针对不同的测试工具和厂商进行考察?

你还在听他们的sales滔滔不绝的给你宣传他们的工具吗?缺少一个衡量的标准吗?

看看下列一些问题他们如何回答,就知道如何决定了.

List of Questions to the tool vendors.

1.What does this tool do?

2.What are the benefits of using this tool?

3.How can this tool solve my problems?

4.Which of my current problems can and can't this tool help with?

5.Will you demonstrate your tool using our tests on our site?

6.What environment is needed to run this tool?

7.How much disk space does it use?

8.What influence do tool users have on future development of the tool?

9.Can tests be re-run in debug mode within the tool?

10.What is the market share of this tool?

11.How do you define market share?

12.Why is this tool better than other similar tools?

13.What proportion of tools sold is providing real benefits to the

organizations, which bought them?

14.What will I have to do to be sure to succeed with this tool?

15.What local support is available?

16.Training, consultancy, help desk, Service Level Agreement for

resolution of problems, technical expertise in our area?

17.What effort is needed in-house by us to support the tool?

18.What test-planning standards need to be in place to gain real

benefits from using this tool?

19.What features are included to ease the learning curve for the tool?

20.How do other sites usually work with the tool?

21.Is there a user group/Forum/Seminar, and can I attend the next

meeting?

22.Can you give me the names of reference sites

23.Can I meet with at least two users who are achieving real benefits

using this tool?

24.How many versions have been released in the past year?

25.Do you release a defect list with the product?

26.How many known defects are there in the tool currently?

27.What kind of tailoring / customization is possible for this tool?

28.What extensions / add-ons / in-house routines have other users

built?

29.How does this tool integrate with other tools?

30.How long will it take to achieve real payback from this tool?

31.Can you help me estimate how much effort will be involved in

implementing this tool in my organization?

--end

一些软件测试概念的标准定义(上篇)

2007-01-12T13:21:00.000+08:00

audit. (1) (IEEE) An independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria. See: functional configuration audit, physical configuration audit. (2) (ANSI) To conduct an independent review and examination of system records and activities in order to test the adequacy and effectiveness of data security and data integrity procedures, to ensure compliance with established policy and operational procedures, and to recommend any necessary changes. See: computer system audit, software audit.

boundary value. (1) (IEEE) A data value that corresponds to a minimum or maximum input, internal, or output value specified for a system or component. (2) A value which lies at, or just inside or just outside a specified range of valid input and output values.

boundary value analysis. (NBS) A selection technique in which test data are chosen to lie along "boundaries" of the input domain [or output range] classes, data structures, procedure parameters, etc. Choices often include maximum, minimum, and trivial values or parameters. This technique is often called stress testing. See: testing, boundary value.

branch coverage. (NBS) A test coverage criteria which requires that for each decision point each possible branch be executed at least once. Syn: decision coverage. Contrast with condition coverage, multiple condition coverage, path coverage, statement coverage. See: testing, branch.

bug. A fault in a program which causes the program to perform in an unintended or unanticipated manner. See: anomaly, defect, error, exception, fault.

cause effect graph. (Myers) A Boolean graph linking causes and effects. The graph is actually a digital-logic circuit (a combinatorial logic network) using a simpler notation than standard electronics notation.

cause effect graphing. (1) (NBS) Test data selection technique. The input and output domains are partitioned into classes and analysis is performed to determine which input classes cause which effect. A minimal set of inputs is chosen which will cover the entire effect set. (2) (Myers) A systematic method of generating test cases representing combinations of conditions. See: testing, functional.

code inspection. (Myers/NBS) A manual [formal] testing [error detection] technique where the programmer reads source code, statement by statement, to a group who ask questions analyzing the program logic, analyzing the code with respect to a checklist of historically common programming errors, and analyzing its compliance with coding standards. Contrast with code audit, code review, code walkthrough. This technique can also be applied to other software and configuration items. Syn: Fagan Inspection. See: static analysis.

code review. (IEEE) A meeting at which software code is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Contrast with code audit, code inspection, code walkthrough.

code walkthrough. (Myers/NBS) A manual testing [error detection] technique where program [source code] logic [structure] is traced manually [mentally] by a group with a small set of test cases, while the state of program variables is manually monitored, to analyze the programmer's logic and assumptions. Contrast with code audit, code inspection, code review. See: static analysis.

coverage analysis. (NIST) Determining and assessing measures associated with the invocation of program structural elements to determine the adequacy of a test run. Coverage analysis is useful when attempting to execute each statement, branch, path, or iterative structure in a program. Tools that capture this data and provide reports summarizing relevant information have this feature. See: testing, branch; testing, path; testing, statement.

crash. (IEEE) The sudden and complete failure of a computer system or component.

criticality. (IEEE) The degree of impact that a requirement, module, error, fault, failure, or other item has on the development or operation of a system. Syn: severity.

cyclomatic complexity. (1) (McCabe) The number of independent paths through a program. (2) (NBS) The cyclomatic complexity of a program is equivalent to the number of decision statements plus 1.

error. (ISO) A discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition. See: anomaly, bug, defect, exception, and fault

error guessing. (NBS) Test data selection technique. The selection criterion is to pick values that seem likely to cause errors. See: special test data; testing, special case.

error seeding. (IEEE) The process of intentionally adding known faults to those already in a computer program for the purpose of monitoring the rate of detection and removal, and estimating the number of faults remaining in the program. Contrast with mutation analysis.

exception. (IEEE) An event that causes suspension of normal program execution. Types include addressing exception, data exception, operation exception, overflow exception, protection exception, and underflow exception.

failure. (IEEE) The inability of a system or component to perform its required functions within specified performance requirements. See: bug, crash, exception, fault.

fault. An incorrect step, process, or data definition in a computer program which causes the program to perform in an unintended or unanticipated manner. See: bug, defect, error, exception.

quality assurance. (1) (ISO) The planned systematic activities necessary to ensure that a component, module, or system conforms to established technical requirements. (2) All actions that are taken to ensure that a development organization delivers products that meet performance requirements and adhere to standards and procedures. (3) The policy, procedures, and systematic actions established in an enterprise for the purpose of providing and maintaining some degree of confidence in data integrity and accuracy throughout the life cycle of the data, which includes input, update, manipulation, and output. (4) (QA) The actions, planned and performed, to provide confidence that all systems and components that influence the quality of the product are working as expected individually and collectively.

quality assurance, software. (IEEE) (1) A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements. (2) A set of activities designed to evaluate the process by which products are developed or manufactured.

quality control. The operational techniques and procedures used to achieve quality requirements.

review. (IEEE) A process or meeting during which a work product or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include code review, design review, formal qualification review, requirements review, test readiness review. Contrast with audit, inspection. See: static analysis.

risk. (IEEE) A measure of the probability and severity of undesired effects. Often taken as the simple product of probability and consequence.

risk assessment. (DOD) A comprehensive evaluation of the risk and its associated impact.

software review. (IEEE) An evaluation of software elements to ascertain discrepancies from planned results and to recommend improvement. This evaluation follows a formal process. Syn: software audit. See: code audit, code inspection, code review, code walkthrough, design review, specification analysis, static analysis

static analysis. (1) (NBS) Analysis of a program that is performed without executing the program. (2) (IEEE) The process of evaluating a system or component based on its form, structure, content, documentation. Contrast with dynamic analysis. See: code audit, code inspection, code review, code walk-through, design review, symbolic execution.

test. (IEEE) An activity in which a system or component is executed under specified conditions, the results are observed or recorded and an evaluation is made of some aspect of the system or component.

testability. (IEEE) (1) The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met. (2) The degree to which a requirement is stated in terms that permit establishment of test criteria and performance of tests to determine whether those criteria have been met.

test case. (IEEE) Documentation specifying inputs, predicted results, and a set of execution conditions for a test item. Syn: test case specification. See: test procedure.

test case generator. (IEEE) A software tool that accepts as input source code, test criteria, specifications, or data structure definitions; uses these inputs to generate test input data; and, sometimes, determines expected results. Syn: test data generator, test generator.

test design. (IEEE) Documentation specifying the details of the test approach for a software feature or combination of software features and identifying the associated tests. See: testing functional; cause effect graphing; boundary value analysis; equivalence class partitioning; error guessing; testing, structural; branch analysis; path analysis; statement coverage; condition coverage; decision coverage; multiple-condition coverage.

掌握有效测试软件的方法与技术(二)

2007-01-12T11:01:00.000+08:00

4. 企业的测试策略
4.1 理念：
u 企业的主要目的是获取利润，降低测试成本也是盈利的一种方式。
u 用较低的代价实现有效的测试，不应为了追求完美的测试而不失一切代价。
4.2 如何合理地减少测试工作量
u 减少冗余的测试
白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。
在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。
u 减少无价值的测试
无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来只要测试一个典型的输入就行了，如果有人在此区间测试了100次，那么其中99次就是无价值的。
u 如何“偷工减料”
有一些“短、平、快”的项目，经费本来就少，用户对质量要求也马马虎虎。为了能多挣一点钱，开发方不得不采用“偷工减料”的方式来降低测试代价。偷工减料的途径无非就是减少测试的内容和频度。但不能砍得太狠，否则软件拿不出手。基本方法是找出软件中需要优先测试的部分（见下表），其它次要部分可以忽略或将来再测试。
u “偷工减料”方法的测试优先级：
哪些功能是软件的特色？
哪些功能是用户最常用的？
如果系统可以分块卖的话，哪些功能块在销售时最昂贵？
哪些功能出错将导致用户不满或索赔？
哪些程序是最复杂、最容易出错的？
哪些程序是相对独立，应当提前测试的？
哪些程序最容易扩散错误？
哪些程序是全系统的性能瓶颈所在？
哪些程序是开发者最没有信心的？
4.3 测试何时结束
u 基于测试用例的规则
u 基于“测试期缺陷密度”的规则
u 基于“运行期缺陷密度”的规则
4.4 测试奖励机制
u 根据缺陷的危害程度，把奖金分等级。每个新缺陷对应一份奖金，把奖金发给第一个发现该缺陷的人。奖金额要适当，太低了人们不感兴趣，太高了会让项目破产的。

5. 测试规范
5.1 测试流程
u 第一步：制定测试计划。该计划被批准后转向第二步。
u 第二步：设计测试用例。该用例被批准后转向第三步。
u 第三步：如果满足“启动准则” ，那么执行测试。
u 第四步：撰写测试报告。
u 第五步：消除软件缺陷。如果满足“完成准则”，那么正常结束测试。
5.2 测试启动准则
u 同时满足以下条件，允许开始测试：
（1）测试计划已经制定并且通过了审批；
（2）测试用例已经设计并且通过了审批；
（3）被测试对象已经开发完毕并等待测试。
5.3 测试完成准则
u 对于非严格系统可以采用“基于测试用例”的准则。同时满足以下条件允许结束测试：
（1）功能性测试用例通过率达到100％；
（2）非功能性测试用例通过率达到90％时。
u 对于严格系统，应当补充“基于测试期缺陷密度”的规则：
（3）相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m。例如n大于10，m小于等于1。
6. 软件系统的主要测试内容及技术
6.1 接口与路径测试
u 数据一般通过接口输入和输出，所以接口测试是白盒测试的第一步。每个接口可能有多个输入参数，每个参数有“典型值”、“边界值”、“异常值”之分，所以输入的组合数可能并不少。根据接口的定义，可以推断某种输入应当产生什么样的输出。输出包括函数的返回值和输出参数。如果实际输出与期望的输出不一致，那么说明程序有错误。白盒方式的接口测试和黑盒方式的功能测试，其方法十分相似。
u 一个函数体内的语句可能只有十几条，但逻辑路径可能有成千上万条。想遍历测试几乎是不可能的，不测试或者胡乱找几条路径测试却又不行。
u 对于非严格系统而言，在分析路径方面化费很多精力是不值得的。我认为在构造接口测试的同时已经建立了测试路径。因为每一种输入将产生唯一的输出，输入与输出之间的路径也是唯一的。由于接口测试中的输入是有代表性的，因此相应的路径也具有代表性，不用得着费煞苦心地去找测试路径。
u 路径测试的检查表
数据类型、变量值、逻辑判断、循环、内存管理、文件I/O、错误处理
u 由于接口测试是枚举的，有可能漏掉某些状况，导致一些重要的路径没有被测试。预防措施有：
观察是否有程序语句从来没有被执行过。如果发生在这种情况，要么是程序有错误，存在无用的代码；要么是接口测试不充分，漏掉了一些路径。
要特别留意函数体内的错误处理程序块（如果存在的话），这是最易被人疏忽的路径，隐患最多。

6.2 功能测试
u 功能测试的基本方法是构造一些合理输入（在需求范围之内），检查输出是否与期望的相同。如果两者不一致，即表明功能有误。也有例外的情况，如《需求规格说明书》中的某个功能写错了，而实际上软件的功能却是正确的，这时要更改的是《需求规格说明书》。
u 功能测试看起来比较简单，只要看得懂《需求规格说明书》，谁都会做。难点在于如何构造有效的输入。由于输入空间通常是无限的，穷举测试显然行不通。那么随便输入一些东西，碰运气行不行？
u 功能测试有两种比较好的测试方法：等价划分法和边界值分析法。
等价划分是指把输入空间划分为几个“等价区间”，在每个“等价区间”中只需要测试一个典型值就可以了。等价划分法来源于人们的直觉与经验，可令测试事半功倍。
“缺陷遗漏在角落里，聚集在边界上”。边界值测试法是对等价划分法的补充。如果A和B是输入空间的边界值，那么除了典型值外还要用A和B作为测试用例。
例如测试函数。凭直觉，等价区间应是（0, 1）和（1, +∞）。可取典型值x=0.5以及x=2.0进行“等价划分”测试。再取 x=0以及x=1进行“边界值”测试。
6.3 健壮性测试
u 健壮性是指在异常情况下，软件还能正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力。
u 容错性测试通常构造一些不合理的输入来引诱软件出错，例如：
（1）输入错误的数据类型。如“猴”年“马”月。
（2）输入定义域之外的数值。如上海人常说的“十三点”
u 粗暴一些方式俗称“大猩猩”测试法。除了不能拳打脚踢嘴咬外，什么招术都可以使出来。例如在测试客户机－服务器模式的软件时，把网络线拔掉，造成通信异常中断。
u 恢复测试重点考察一下几项：
（1）系统能否重新运行；
（2）有无重要的数据丢失；
（3）是否毁坏了其它相关的软件硬件。
6.4 性能测试
u 性能测试即测试软件处理事务的速度，一是为了检验性能是否符合需求，二是为了得到某些性能数据供人们参考（例如用于宣传）。
u 有时人们关心测试的“绝对值”，如数据送输速率是每秒多少比特。有时人们关心测试的“相对值”，如某个软件比另一个软件快多少倍。
u 在获取测试的“绝对值”时，我们要充分考虑并记录运行环境对测试的影响。例如网络环境、计算机主频，总线结构和外部设备都可能影响软件的运行速度。
u 性能测试的一些注意事项：
不要试图让人拿着钟表去测时间，应当编写一段程序用于计算时间以及相关数据。
应当测试软件在标准配置和最低配置下的性能。
为了排除干扰，应当关闭那些消耗内存、占用CPU的其它应用软件（如杀毒软件）。
不同的输入情况会得到不同的性能数据，应当分档记录。例如传输文件的容量从100K到1M可以分成若干等级。
由于环境的波动，同一种输入情况在不同的时间可能得到不同的性能数据，可以取其平均值。
6.5 用户界面测试
u 绝大多数软件拥有图形用户界面。图形用户界面的测试重点是正确性、易用性和视觉效果。在评价易用性和视觉效果时，主观性非常强，应当考虑多个人的观点。
6.6 信息安全测试
u 信息安全性（security）是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。
u 信息安全性测试有如下步骤：
（1）为非法入侵设立目标，例如“盗窃某个文件”或“更改数据库记录”等。
（2）邀请（或悬赏）一些人扮演黑客，让他们想尽办法入侵系统，实现“目标”。
（3）如果有人成功了，请他详述入侵的过程。别忘了给予奖励。
6.7 压力测试
u 压力测试也叫负荷测试，即获取系统能正常运行的极限状态。了解“极限”是很有价值的，例如潜艇下潜极限深度…。
u 压力测试的主要任务是：构造正确的输入，使劲折腾系统却让它刚好不瘫痪。
u 压力测试的一个变种是敏感测试。在某种情况下，微小的输入变动会导致系统的表现（如性能）发生急剧的变化。敏感测试目的是发现什么样的输入可能会引发不稳定现象。
6.8 可靠性测试
u 可靠性是指在一定的环境下、在给定的时间内、系统不发生故障的概率。由于软件不像硬件那样可以“加速老化”，按此定义，软件可靠性测试可能会花费很长时间。
u 比较实用的办法是，让用户使用该系统，记录每一次发生故障的时刻。计算出相邻故障的时间间隔，注意要去掉非工作时间。这样我们可以方便地统计出不发生故障的“最小时间间隔”、“最大时间间隔”和“平均时间间隔”。其中“平均时间间隔”会让人们大体了解到系统“可靠”的程度。
6.9 安装 / 反安装测试
u 安装 / 反安装测试的目的：避免“大风浪都挺过来了，却在阴沟里翻了船”
u 目前市面上有非常流行的、专门制作安装/反安装程序的一些工具，如Install Shelled。制作安装/反安装程序不再是件难事，关键是不要麻痹大意。主要测试工作：
（1）至少在标准配置和最低配置两种环境下测试；
（2）如果有安装界面，应当尝试各种选项，如选择“全部”、“部分”、“升级”等。

--end

掌握有效测试软件的方法与技术(一)

2007-01-11T13:50:00.000+08:00

1. 测试的常识与道理

1.1 你真的懂测试吗

u 编程大师说：没有错误的程序世间难求。（《编程之道》）

u 你在学校里学过测试吗？（读到博士可能也不懂测试）

u 你所在的企业重视测试吗？（小公司程序员的技能更加全面）

u 临时抱佛脚行吗？你以为有文档模板就会测试了吗？

u 如果不懂得有效地进行测试，你不仅得不到功劳，也没人欣赏你的苦劳，你拥有最多的将只是疲劳。

u 职业软件工程师应当掌握需求开发、系统设计、编程、测试、维护所有技能。

1.2 测试的目的是什么

u 测试的目的是为了发现尽可能多的缺陷，不是为了说明软件中没有缺陷。

u 推论：成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。

u 千万不要将“测试”与“演示”混为一谈。例如科研鉴定会。

u 如果产品通过了严格的测试，大家不要不吭气，应当好好地宣传一把。

1.3 一些常识和经验之谈

u 测试能提高软件的质量，但是提高质量不能依赖测试。

u 测试只能证明缺陷存在，不能证明缺陷不存在。“彻底地测试”难以成为现实，要考虑时间、费用等限制，不允许无休止地测试。我们应当祈祷：软件的缺陷在产品被淘汰之前一直没有机会发作。

u 测试的主要困难是不知道如何进行有效地测试，也不知道什么时候可以放心地结束测试。

u 每个开发人员应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据（所以项目需要独立测试人员）。

u 80-20原则：80％的缺陷聚集在20％的模块中，经常出错的模块改错后还会经常出错

u 测试应当循序渐进，不要企图一次性干完，注意“欲速则不达”。

2. 测试的分类与比较

u 问题1：有了“黑盒”测试为什么还要“白盒”测试？

– 黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原因。

– 白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。

u 问题2：由于单元测试要写测试驱动程序，非常麻烦，能否等到整个系统全部开发完后，再集中精力进行一次性地单元测试呢？

– 如果这样做，在开发过程中，缺陷会越积越多并且分布得更广、隐藏得更深，反而导致测试与改错的代价大大增加。最糟糕的是无法估计测试与改错的工作量，使进度失去控制。因此为图眼前省事而省略单元测试或者“偷工减料”，是“得不偿失”的做法。

u 问题3：如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？集成测试是否多此一举？

– 要把N个单元集成一起肯定靠接口耦合，这时可能会产生在单元测试中无法发现的问题。例如：数据通过不同的接口时可能出错；几个函数关联在一起时可能达不到预期的功能；在某个单元里可以接受的误差可能在集成后被扩大到无法接受的程度。所以集成测试是必要的，不是多此一举。

u 问题4：在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试?

– 不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系统。再者，单元测试和集成测试通常由开发小组执行。根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的，但不能作为成果已经通过测试的依据。

u 问题5：既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？

– 首先是“信任”问题。对于合同项目而言，如果测试小组是开发方的人员，客户怎么能够轻易相信“别人”呢? 所以当项目进行系统测试之后，客户再进行验收测试是情理之中的事。否则，那是客户失职。

– 不论是合同项目还是非合同项目，软件的最终用户各色各样（如受教育程度不同、使用习惯不同等等）。测试小组至多能够模仿小部分用户的行为，但并不具有普遍的代表性。

u 问题6：能否将系统测试和验收测试“合二为一”？

– 系统测试不是一会儿就能做完的，比较长时间的用户测试很难组织。用户还有自己的事情要做，他们为什么要为别人测试呢？即使用户愿意做系统测试，他们消耗的时间、花费的金钱大多比测试小组的高。

– 系统测试时会找出相当多的软件缺陷，软件需要反反复复地改错。如果让用户发现“内幕”，一是丢脸，二是会吓跑买主。所以还是关起门来，先让测试小组做完系统测试的好。

3. 测试人员的组织

3.1 了解开发人员的测试心理

u 测试的目的是找出尽可能多的缺陷。所以测试是“破坏性”的，而开发却是“建设性”的。开发人员总是喜欢欣赏程序的成功之处，而不愿看到失败之处。让开发者去做“蓄意破坏”的测试，就象杀自己的孩子一样难以接受。

u 开发者对自己的程序印象深刻，并总以为是正确的（自信是应该的）。倘若在设计时就存在理解错误，或因不良的编程习惯而流下了隐患，他本人很难发现这类错误.

u 开发者对自己的程序的功能、接口十分熟悉，他自己几乎不可能因为使用不当而引发错误，这与大众用户的情况不太相似，所以测试自己的程序不具备典型性。

u 结论：开发人员应当测试自己的程序，这是他分内的工作。但是开发人员在测试自己的程序时，很难做到客观、公正，所以自我测试不具有说服力。

3.2 如何组织测试人员：应当视企业的人力资源而定

u 条件特别好的公司，可以为每一个开发人员分配一名独立的测试人员。这样的测试人员职业化程度很高，可以完成单元测试、集成测试和系统测试工作，能够实现开发与测试同步进行。

u 条件比较好的公司，可以设置一个独立的测试小组，该测试小组轮流参加各个项目的系统测试。而单元测试、集成测试工作由项目的开发小组承担。

u 条件一般的公司，养不起独立的测试小组。单元测试、集成测试工作由项目开发小组承担。当项目进展到系统测试阶段，可以从项目外抽调一些人员，加上开发人员，临时组织系统测试小组。

u 条件比较差的公司，也许只有一个项目和为数不多的一些开发人员。那么就让开发人员一直兼任测试人员的角色，相互测试对方的程序。如果人员实在太少了，只好让开发者测试自己的程序，有测试总比没有测试好吧！

3.3 避免开发人员与测试人员产生矛盾

u 开发人员的注意事项：

不要敌视测试人员。要理解测试的目的就是发现缺陷，是测试人员的工作职责。不要以为测试人员吃饱了没事干，存心找茬。

不要轻视测试人员，别说人家技术水平差，不配搞开发只好搞测试。

u 测试人员的注意事项：

发现缺陷时不要嘲笑开发人员，别说他的程序真臭、到处是Bug。

在开发人员压力太大时或心情不好时不要火上浇油，发现缺陷时别大声嚷嚷。

u 请留意另一种极端：如果测试人员与开发人员的关系非常好，可能会导致在测试的时候“手下留情”，这对项目也是一种伤害。

--to be continue

火车票不涨价，我们咋就受益了？

2007-01-10T21:35:00.000+08:00

铁道部新闻发言人王勇平１０日透露，２００７年铁路春运各类旅客列车票价一律不上浮，以后春运也将不再实行票价上浮制度。

王勇平说，今年春运，铁路部门在各类旅客列车中均不再实行票价上浮，这一票价政策实行后将会使数千万旅客直接受益。

２００６年春运铁路火车票票价上浮情况为：春节前１月２１日至２７日、春节后１月３１日起，硬座票价上浮１５％，其他席别上浮２０％。但以农民工、高校学生为主要客流的临时旅客列车票价没有上浮。

王勇平说，目前铁路运输能力仍很紧张，尤其在春运期间有的线路和方向无法全面满足旅客的出行需求。铁路部门将克服困难，全力挖潜扩能、精心组织调度，尽最大能力缓和运力与需求的矛盾，努力为旅客过一个愉快祥和的春节创造较好的旅行环境。

他同时呼吁，旅客应妥当安排出行时间，合理选择交通工具，尽可能避开客流高峰期出行。铁路部门届时将及时向社会发布旅客流向和运力配置的有关信息。

２００７年全国铁路春运方案显示，在２月３日至３月１４日的４０天春运里，预计铁路将发送旅客１．５６亿人次，较去年增长４．３％，客流高峰将超过历年春运。

来自网易新闻

这是怎么了，不涨价我们就受益了，那以前没涨价之前，我们难道是受到优惠了？？？

Best Practices in Software Test Automation

2007-01-10T13:35:00.000+08:00

What are Best Practices?

Best practices are guidelines and advice on the best way to do something; collected over time and based on experience with previous projects. Best practices in an organization should come from the bottom of the organization up, rather than being mandated by management. These best practices might even differ from organization to organization, but certain key factors are present in successful organizations and projects. Discussed in this article are twelve of the most important practices that can assist you in ensuring successful implementation of functional test automation on your projects and in your organization.

Best Practice 1: Know your objective

There are many good reasons for doing test automation.

Test automation can save time, make testing easier, and improve the testing coverage. It can also help keep testers motivated; I can list a page of other benefits that can be derived from doing functional test automation. However, it is not likely that your organization will need to do all these things at the same time. Different groups typically have different hopes and ideas of what they want test automation to offer them. These need to be stated, or else disappointment is likely.

A clear objective to work towards during test automation is highly important. It provides us with a compass heading towards which planning and implementation will be directed. Eventually, the results of the test automation implementation will be compared against the original objective to establish whether we did reach our goal or not.

Mistakes made...

· "Test automation is the answer to our testing problems"

Test automation assists in the testing process, and can therefore provide value to a test team. Certain benefits can be derived, but we need to know and understand exactly what they are without having false expectations or hopes. Automation is not a replacement for an inadequate test process or an inefficient test team. Address the testing problems prior to embarking on a costly test automation implementation. Automation's objective is definitely not to solve all testing problems in existence.

· "Since we have limited time to test, let's use test automation."

Test automation takes 3 to 128 times longer to implement than manual testing, and therefore it should be properly planned to achieve the expected benefits. If time is of the essence, consider adding more resources to the test process (this also has limited benefits, and might not always be a solution) rather than embarking on the lengthy process of implementing test automation. Functional test automation is definitely not a quick solution to a test project in distress. Multiple other solutions are better suited to address this need.

Best Practice 2: Test Automation requires a manual test process

"Success in test automation requires careful planning and design work, and it's not a universal solution. ... automated testing should not be considered a replacement for hand testing, but rather as an enhancement." (James Bach [pg. vii] in his foreword: Software Testing with Visual Test 4.0, Thomas Arnold II, IDG Books Worldwide Inc. Foster City, CA.: 1996. ISBN 0-7645-8000-0.)

The words of James Bach and many others are quite clear on this subject. Test automation will not give you a correct testing process or methodology. It will not enforce a methodology or process. Test automation merely supports the test process; it will not replace the manual test process.

Mistakes made ...

· "We need to implement testing in our projects. Let's buy a tool and automate the testing."

You can script to your heart's content, if you do not have a proper manual test process in place the benefits of test automation will never be seen. It will only assist you in doing the incorrect process a lot faster. Test automation merely assists and enhances the test process itself. Ensure that a proper test methodology is implemented before attempting to add test automation.

· "We can just add the test automation to our current test process and start automating our current test scripts."

Test Automation requires test cases to support the automation process. If my test cases do not incorporate the all-important logon to the SUT (system under test), the automation script will need a lot of manual intervention, and would therefore be more manual than automated. The current test process might have to be changed, or adapted, to be implemented for the tool suite selected. Review and adapt the test process to ensure maximum benefit is realized from the tool suite to be used in your test process.

Best Practice 3: The earlier the involvement in the Software Development Life Cycle (SDLC) the greater the benefits

We all know how testing has its own phases aligned with the phases of the SDLC. The earlier testing gets involved in the life cycle of the project the better. Many articles have been written on this subject, and it holds true. Since test automation supports the testing process, the test team can get involved very early in the life cycle of a project. If the test team uses a test automation tool suite, they will most likely have a requirements management tool or test management tool included in the suite. These tools can assist the test team in various ways from an early stage in the development life cycle, even before a line of code is developed.

The more mature techniques and methods of test automation are closely tied to the testing methodology being used. An early start to the test life cycle, at the start of the development project life cycle, is vital to achieving the best results, and ensuring maximum return on investment.

Mistakes made…

· "The test automators cannot get involved in the project before the developers release the first build."

A software development project does not start with code development. Since functional test automation is also a development project, as we will discuss in Best Practice 9, it follows the same phases as a software development project and does not start at the coding phase. Proper planning and design are essential to the success of the functional test automation implementation, and need to be conducted hand-in-hand with the test life cycle.

· "Testing is only a single phase in the SDLC and therefore testers and test automation only need to be part of the project for the testing phase."

This 'prehistoric' misconception in the IT industry has been proven one of the major reasons for bad software quality.

Best Practice 4: Test Automation is a fulltime effort

When people are allowed to work on test automation on their own time, or as a back burner project whenever the test schedule allows, test automation becomes a sideline effort. Test Automation does not get the time and focus it needs.

Getting into automated testing requires preparing not only yourself, but also your company and environment. This requires focus and dedicated resources.

Mistakes made…

· "We have a test automation tool. Can the test team see if they can use it?"

It is clear that the expectation and an understanding of test automation is lacking. I can guarantee that the tool implementation will not be successful, and would result in almost no benefit to the test team. The test team is usually confronted with manual test work for development projects that does not meet the code delivery date for testing. The test automation implementation would probably be of the capture-record-and-playback form, and therefore the benefit would be low.

Test Automation will require training for the staff involved with it. Time is required to design and implement the architecture. Referring to the development nature of functional test automation implementation, the team will have to learn a new skill set. Test automation implementation requires dedication and focus to ensure success. In this instance, it is better to not implement test automation than to allocate ad hoc time for experimentation.

Best Practice 5: Select the correct product or suite of products

Buying the wrong tool is listed as one of the major challenges in test automation, because - no matter what kind of process, methodology, or organisation you have - if the tool is not a good technical and business fit, it will not be used.

We know that a good process and organisation are also essential for test automation. However, if the tool will not function at a basic level, the people who should use the tool, and thereby gain the benefit from the tool, will not use it.

Unfortunately, too few people do adequate research before buying a test tool. Adequate research includes defining a set of tool requirements based on what the intended users of the tool need to accomplish, developing a set of evaluation criteria by which candidate tools will be judged, and taking the experience of other people who have used the tools into consideration.

Select a tool that will allow you to implement automated testing in a way that conforms to your long-term testing strategy and test methodology.

Mistakes made…

· "A vendor demonstrated a tool to us and it seems as if the tool will add value. I think we should buy it."

Take time to define the tool requirements in terms of technology, process, applications, people skills, and organisation. Then look at multiple tool vendors and select the right fit for your circumstances. A good idea would be to do a proof of concept project with the tool that best fits your criteria.

· "We purchased the whole suite of tools from the vendor, but are only using the functional test automation tool."

Test Automation tools are expensive, and to justify the Return On Investment (ROI) it is normally not effective and efficient to use only the functional test automation tool in the product suite. Other benefits can be derived from using the full suite of products; for example, proper defect management, metric reporting on test status, etc. Purchase what you need, or use what you have fully.

· "The yearly license fees are so expensive we cannot afford to use the tool suite any more."

Too often test automation tools end up as 'shelf-ware' because of the cost of the licenses compared to the benefit derived. Refer to mistake two above for one of the reasons why the ROI is not being realised. Before signing the purchase order, be aware of the impact of annual licensing fees.

Best Practice 6: Get executive management commitment

Test automation can yield very substantial results, but requires a substantial commitment to be successful. Do not start without commitments in all areas, the most important being executive management.

'Thomas R. Arnold II, VP at ST Labs, Inc., sums it up fairly well:
"I would like to say up front ... that no test automation tool is a silver bullet. Automation takes time, effort, and commitment from all involved, including an understanding from management about the realities of what automation can and cannot do." ' 1

Management support is needed in designing and deploying test processes that will support the effective use of test tools, reinforce the role and use of automated test tools in the organisation, and allow time for tools to be integrated in the testing process.

Without management support, the entire test automation effort is at risk. If management does not - clearly and consistently - show their support for test automation, people will be less inclined to show interest in using the tools. This is a major concern, especially considering that overcoming the learning curve of some tools requires dedication.

Perhaps the greatest challenge seen in management support is balancing the high expectations of tool benefits against the time, effort, and discipline it takes to implement the tool. Management may become impatient about the lack of tool progress and shift their support to other initiatives.

Mistakes made…

· "We thought these tools were going to solve your testing problems."

When making the case to management for acquiring test tools, present the challenges as well as the benefits. Make sure that management understand their influence on how others will accept automated test tools.

· "We purchased a tool for you 3 months ago, and yet we cannot see any benefits in the project."

Communicate to management from the start that it takes time and planning to build a firm foundation of people, processes, and the right tools. Keep management informed of tool progress, and any issues that arise.

Best Practice 7: Select the appropriate technique/s for the project

As maturity levels improve in the functional test automation field, we see a decrease in cost for test automation implementations, and an increase in benefits derived for the project or organisation.

The increase in maturity levels has provided us with more mature techniques for implementing test automation. These techniques vary from the simplest record-and-playback to the most mature, viz., keyword or action based. These techniques each have their own benefits and drawbacks, appropriate for certain specific circumstances.

During a small data conversion project, a few lookup data tables' contents in the old system need to be compared to the new lookup data tables' contents after the batch conversion. If this can be done via the enquiry functions of both systems, the fastest method might be record-and-playback. This is a once off test of the conversion, and writing specific scripts to do this might take longer than the record-and-playback method. In terms of cost and timing, the record-and-playback technique would be the most appropriate for this project. This is one of the few instances where I would suggest using the record-and-playback technique; most of the time the benefits of this technique are few compared to the more mature techniques like data-driven and keyword test automation.

It is important to know, and be able to use, multiple techniques appropriately. If we do not use the various techniques when appropriate, our test automation will not provide us with the benefits we are aiming for.

Mistakes made…

· "Record-and-playback is sufficient for our needs."

The benefits of this simplistic technique are few, and its application is widely misused. More mature techniques are available with exponentially more benefits in terms of ease of use, cost saving, and time saving if implemented correctly.

· "We have created our test cases for the project and are approaching the release of the first build. Can we implement keyword test automation before the end of the project."

Keyword test automation is a very advanced test automation technique, and is closely tied to the testing methodology being used for the project. The preparation work for implementing keyword test automation requires more time than some other techniques. The framework needs to be established, and test design needs to support the method. I would not suggest implementing the method from scratch at this late stage of the project.

Best Practice 8: Do not attempt to automate all tests

Test Automation does not work well for all situations or tests. Some tests are better left for manual execution. If a test will not be repeated more than three times, it is probably not a good candidate to automate. It takes a lot longer to automate a test than to execute it manually. The benefit of the automated tests is linked to how many times it would be repeated. For example, multiple builds, or testing on multiple platforms, or executing the same test for multiple data sets.

Software that is tested manually will be tested with a randomness that helps find bugs in more varied situations. Since a software program usually will not vary, automated testing may not find some bugs that manual testing will. Automated software testing is never a complete substitute for manual testing.

Proper analysis needs to be done to identify the correct test cases to automate to ensure ROI for the effort. How to select tests for automation is a subject on its own, but the following suggestions can be helpful:

1. Perform a proof-of-concept (POC) on a cross section of test cases for the system to determine technical applicability and return on investment (ROI) metrics.

2. Perform an ROI analysis for each testing regimen to select automation candidates.

3. Perform a risk analysis on the automation candidates to prioritise what should be automated first.

If the tests selected for functional test automation are identified and prioritised, the test cases with the best potential to provide benefit will be automated first. If time constraints affect the test automation delivery, at least we know the largest possible benefit would be derived.

Mistakes made…

· "It was so much fun that we automated all the tests."

It might have been fun, but the ROI was definitely not optimal. Time spent on automation of certain tests would never be recovered. A general rule of thumb would be never to automate more than 60% of your test cases to ensure maximum benefit with the lowest investment cost.

Best Practice 9: Manage the automation as a development project

Test Automation development is a software development process, although it is seldom treated that way. Following software development practices can make the difference between the success and failure of an automated testing project.

We need to run test automation projects just as we do our other software development projects. The following pertains to test automation projects, and is true for development projects:

· Projects need developers dedicated to developing test automation.

· Test automation automates a task in which the programmer is probably not an expert. Therefore, expert testers should be consulted and provide the requirements.

· Test automation benefits can be seen if we design our approach before we start coding.

· Test automation code needs to be tracked and safeguarded. Therefore, we need to use source code management.

· Test automation will have bugs. Therefore, we need to plan to track them, and test for them.

· Users will need to know how to use it. Therefore, we need user documentation.

The type of work done during test automation is software code development, and since these are programs, they must be managed in the same way that application code is managed.

Mistakes made…

· "When the code is complete, give it to the testers so they can implement test automation."

Why would we follow a phased approach to software development, but not with test automation script development? We should enforce the same stringent processes and phases on test automation scripters as on developers… and the scripts need to be tested.

· "You don't need to follow all the phases of the software development life cycle with test automation."

The fact that we are writing software to test software, and not to perform some business scenario, does not mean the method is different. What is important for the one is important for the other; both are software development projects.

Best Practice 10: Use the correct resources

One area consistently missed by organisations desiring to automate testing is the staffing issue.

Automated testing is different from other types of testing:

1. Most tools use procedural languages to create their scripts.

2. These tools are very similar to IDEs (Integrated Development Environments).

3. Debugging scripts is the same as debugging traditional software.

…and therefore, resources are going to need:

· academic-level knowledge of procedural coding languages,

· basic knowledge of coding practices and procedures, and

· in-depth knowledge and practical experience with the tool being used for the test automation.

Because of this and because 'record-and-playback' (which generally does not require learning the back-end scripting) is not a valid way to automate most tests, the use of these tools becomes like that of a development effort. Given that such is the case, there must be support within the organisation to realise this and hire staff accordingly, as well as giving the necessary time for the development.

To accomplish this, a Test Automation Tool Specialist, or similar, position must be created, and staffed with at least one senior-level programmer. It does not really matter in what languages the programmer is proficient; what is important is that this person must be capable of designing, developing, testing, debugging, and documenting code.

Test Automation is a combination of testing and development. To mentor and teach your team and resources, use consultants as appropriate to bootstrap your effort. Learn as much as possible from theses consultants to enable you to avoid the stumbling blocks, and proceed successfully with your automation effort after they depart.

Mistakes made…

· "We sent our testers on a test automation course, and they still can't implement proper test automation scripts."

Learning the test tool Integrated Development Environment (IDE) does not make you a good scripter. A 3-day course will not teach you programming principles. Mentoring by a developer can accelerate the learning process. Add a person to the test team who is a test scripter. This person should be comfortable working with code, and be able to take the basic test designed by a test analyst and convert it into an automated script.

· "The testers did attend the vendor training."

The vendor training will train your staff in the product. Teaching someone Microsoft's development studio will not make them a code writer or programmer. The person will merely know how to use the IDE to write code. It is going to require more than just vendor training to turn your staff into test automators. I suggest hiring a test automation consultant to assist with getting the test team out of the starting block. The consultant can train and mentor your staff, and teach them how to avoid the most common pitfalls. Start the team with simple basic scripting concepts, and add complexity later.

Best Practice 11: Develop for maintenance

Without proper automation architecture planning and design the test team will soon find itself with hundreds or thousands of test scripts, thousands of separate run result files/logs, and the combined work of maintaining the existing scripts for various versions of the system, as well as creation of new scripts for new enhancements. Soon they will find themselves with a maintenance nightmare.

To avoid the maintenance problems that so many organisations succumb to, the following pointers can help:

· Create a reusable architecture.

· Develop generic, cross application initialisation and configuration parameters.

· Create reusable, cross application functions.

· Design test scripts by assembling components.

Avoid the creation of disposable automation through proper planning and design of your test automation implementation.

Mistakes made…

· "We did not design with maintenance in mind."

If you did not start your test automation with a design for maintenance, you have probably already become a victim of the maintenance nightmare. Review your current scripts and determine what amount of script/code snippets can be reused if you implement a different approach (maintenance focused). If the amount of rework is large, it might be better to restart your effort with the correct approach in mind.

· "No standards were followed in script creation."

This will also result in difficulty during the maintenance phase; or if the resource that created the scripts leaves for greener pastures. Coding and scripting standards allow for ease of maintenance for the whole team. Different people can understand each other's scripts with ease, and when someone leaves the team it is not the end of the world. When test automators return to scripts that they have not worked on for a while it is also easier to understand what they did the first time round. This leads to a reduction in script maintenance time.

Start to implement standards and good coding practices for the test automators or scripters in your project/organisation. It is never too late to start with this practice.

Best Practice 12: Review and improve implementation process after each project

Development practices suggest having 'post-mortems' at the end of a project. This holds true for the test automation project as well. The following information will surface during a 'post-mortem':

· New ways to deal with specific issues that were discovered during the project may be suggested.

· Experiences gained will provide insight into changes required for the current process or architecture in use.

· Ideas may emerge that may enhance and make the current process more efficient.

· Metrics to be reviewed may provide valuable information for the enhancement of processes.

· Further training or mentoring needs may emerge.

Use the information from the 'post-mortem' to learn and adapt your processes and best practices to gain maximum benefit from your test automation implementation.

Mistakes made…

· "We are still implementing test automation in the same manner as we did on our first test automation project in the organisation."

It is clear that the team/organisation is not learning from its experiences. Learning from our experiences allows us to change our ways for the better, adapt processes for maximum benefit, and make life easier for ourselves. The test team needs to review what works for them and what does not, and adapt their methods to improve for future projects.

· "What benefits did we derive from this automation effort."

This should be easy to answer if we followed Best Practice 1: Know your objective. We set out with a goal in mind and, while we implemented the test automation, we worked towards our goal. At the end of the project, we should know if we achieved what we set out to do. If we cannot answer, it is time to implement Best Practice no. 1.

Conclusion

Once you determine your company profile, perfect your processes, establish test specialists, give the team members appropriate testing tools, and follow the best practices laid out in this article; your company can realise the benefits of automated software testing. When compared to manual testing, properly applied automation will result in higher quality products, lower risk to your company, faster approval, and decreased time to market.

The higher level you reach on the automated software testing maturity ladder, the more benefits you will realise. Whatever level you choose, however, keep in mind a major lesson of the past few decades: No matter what tools you buy, your largest investment by far will be in the processes and people you put in place to use those tools.

Use the best practices as specified by those who have travel-led the path to successful test automation implementation, and adapt these practices to fit your organisation's individual needs by learning from your test automation implementation.

By Henk Coetzee

--end

开源测试工具的完整解决方案

2007-01-10T13:13:00.000+08:00

开源软件运动正在获得很大成功，正在改变软件业的开发模式、运营方法等，也自然改变着软件测试的方法，借助开源软件测试工具完全可以构造一个完整的测试解决方案，可以极大地提高测试效率，又能大大的降低测试成本。从单元测试、功能测试到性能测试，从Web页面测试到VoIP/Telephony等一些多媒体应用的测试，直至测试的管理平台和缺陷跟踪系统，能覆盖整个测试工作领域。

1. 测试模型：见开源软件测试模型，阐述了开放源码软件测试模型框架以及环境、元素和技术等。

2. 单元测试工具：JUint (大家太熟悉了）- see: http://www.junit.org/index.htm
针对各种语言（C/C++/C#, PHP, SQL ） Cactus， Cgreen, Check, CppTest, NUnit, NUnitForms , PHPUnit, SQLUnit, ...还有针对各种对象(HTTP, XML, Database, ) 进行的单元测试：HttpUnit, XMLUnit, DBUnit, ObjcUnit, SIPUnit, ...Mockrunner用在J2EE环境中进行应用程序的单元测试,不仅支持Struts actions, servlets，过滤器和标签类还包括一个JDBC和一个JMS测试框架，可以用于测试基于EJB的应用程序。

3. Web 功能测试 : 要数 Selenium，see: 强大的Web开源测试工具—Selenium
再结合 Ant, EMMA 一起使用就更完美了， see：使用 EMMA 测量测试覆盖率
又如：Canoo WebTest,
功能测试工具很多，可以发现多达几十个：http://www.opensourcetesting.org/functional.php

4. Java 客户端，可以使用 Abbot， see: http://abbot.sourceforge.net/doc/overview.shtml
Abbot是一个用来测试Java GUIs的框架, 用简单的基于XML的脚本或者Java代码，就可以开始一个GUI.

5. 性能测试，著名的有 Jmeter 和 OpenSTA，使用都很方便
Jmeter可以完成针对静态资源和动态资源（ Servlets, Perl脚本, Java对象, 数据查询s, FTP服务等）的性能测试。 Jmeter 可以结合 Badboy 来使用，录制测试脚本。
性能测试工具很多，可以访问 http://www.opensourcetesting.org/performance.php

6. 数据库测试： DBMonster, DBProbe, OraRep, phpMyAdmin
OSDL Database Test Suite, 是根据Linux开发人员需要而开发的测试框架中数据库测试工具套件，具有很好的实用价值。 see: http://www.osdl.org/lab_activities/kernel_testing/osdl_database_test_suite/
More: http://dbcommander.sourceforge.net/

7. 多媒体(VoIP/Vedio)、IP电话等测试Ethereal, AuthTool, ... SIPp, Sofia SIP, ... Seagull, ... Asterisk - the Open Source PBX，X-Lite
其中经常使用的有：Ethereal, SIPp 和 Seagull。而Asterisk 不仅可以作为测试工具，还可以构造企业内部电话网络。
更多的还有：http://voipsa.org/Resources/tools.php

8. 网络安全性测试
#1 Nessus : Premier UNIX vulnerability assessment tool
#2 Wireshark : Sniffing the glue that holds the Internet together
#3 Snort : A Everyone's favorite open source IDS
#4 Netcat : The network Swiss army knife
还有许多网络监控工具，pls visit: http://www.slac.stanford.edu/xorg/nmtf/nmtf-tools.html

9. 缺陷跟踪
Bugzilla一款不错的软件缺陷管理工具
Mantis是一款基于WEB的软件缺陷管理工具，配置和使用都很简单，适合中小型软件开发团队

10. 测试平台
TestMaker (solve functionality, scalability and performance of services)- http://www.pushtotest.com/
Eclipse Test & Performance Tools Platform (TPTP 4.3)

11. Reference
http://www.eclipse.org/tptp/
http://sourceforge.net/search/?type_of_search=soft&words=Test+Tool
http://www.opensourcetesting.org
http://testingfaqs.org/
http://www.pushtotest.com/
http://www.openqa.org/
http://www.aptest.com/webresources.html

注：测试自动化可以做到90％或更高，但也不能完全代替手工测试。

参考：
"Test Automation Snake Oil" (James Bach, http://www.satisfice.com/articles/test_automation_snake_oil.pdf )
"Automation Myths" (M. N. Alam, http://www.benchmarkqa.com/PDFs/automation_myths.pdf )
"When Should a Test Be Automated?" (Brian Marick, http://www.stickyminds.com/r.asp?F=DART_2010 )

转载朱少民老师的博客<软件测试和质量专栏>

--end

如何利用Google Analysis优化你的网站

2007-01-10T10:32:00.000+08:00

免费注册并利用Google Analysis分析并优化你的网站,有助于提高网站的访问量.

今天Google Blog上推出了一篇这样的文章,仔细阅读了一下,发现以前对这个工具的理解还不够彻底.

自从上个月在Blogger上注册自己的博客以来,通过Analysis分析,先后有过几次访问的高峰.

1. 在51testing上发表并回复了一些帖子,并在后面留下了博客地址,结果访问量增加很厉害,说明51的朋友很关心技术,另外从一个侧面反映现在软件测试行业发展很快.
2. 在eygle的blog上留了几次言,结果来自eygle的访问量也有稳定的增加, eygle的博客一直人气比较旺, :)
3. 我把自己的博客地址提交到google以后,来自google的搜索用户一直很多,多数是一些技术问题,比如sed,软件测试发展,质量保证,tcl语言等等,说明技术是真正吸引用户来源的真正力量.
4. 还有就是google的博客,最早引用了一篇google的blog,结果来自这个blog的访问一直断断续续,呵呵,说明google blog的更新速度有待提高,这也是很多人诟病googlechinablog的一个原因. 呵呵, 我这是典型的因祸得福.

先说这么多. 以后继续增加宣传;多充实内容. 两手都要抓,两手都要硬.

--end

Firefox的几款优秀插件

2007-01-09T13:32:00.000+08:00

Firefox之所以能不断抢占IE的市场,并且得到越来越多人的喜爱的原因之一是有一系列功能强大和丰富多彩的插件,我已经脱离IE的振营,改投Firefox两个月之久了,现在给大家推荐几款我日常用的最多的插件:

1. GUtil!
首先要说的,就是这个集成了所有Google服务的GUtil!插件,有点类似于一键上网,基本上所有Google提供的服务,都可以以最快的方式访问,这对于象我这样的Google迷来说,无疑是个好消息.

2. MailMan
提供包括Gmail, MSN和Yahoo,以及自定义pop3邮箱的实时查看和收信. 别提多方便, 另外还有一些常用的工具都可以集成进来,比如写字板,记事本,计算器,MSN等等. 另外提供了一个方便的本地天气预报功能,可谓天下气象尽在掌握.

3. IETab
有些网站因为设计的局限,可能兼容性并不是那么好,如果要想完全脱离IE,进入Firefox,有时候还有些迫不得已. 现在好了,有了IETab,这个问题彻底解决,用IE的内核在firefox中打开你想打开的网站.

4. DownThemAll!
这又是一款我超级稀饭的插件, 可以从当前页面中把所有的文件通通下载下来,文件的格式可以自己定义,比如所有的.mp3, .doc, .htm, .jpg或者之类的. 另外还可以支持正则表达式. 真可谓"只有想不到,没有做不到",超级稀饭!!

5. FireFTP
另外一款我超稀饭的插件,以前安装了一些远程下载工具和ftp工具,不是因为license就是太慢,而且经常过期,实在不方便,自从有了FireFTP,就可以把本机的所有FTP工具卸载, 滚蛋去吧. FireFTP, FireFTP, FireFTP,不要给其他的FTP工具任何机会!!... (此处省略200字)

6. FoxyTunes
内嵌的播放器,可支持广泛的类型,rm,mp3,wmv等等,还是那句话,只有想不到,没有做不到.

今天就先介绍这么多,还有其他一些比较好的插件, fasterfox, adblock plus等等,如果你善于发现,就去这里找找吧. 祝你好运~

--end

<软件质量控制>读书笔记--合同评审

2007-01-08T21:54:00.000+08:00

如何区别两个合同评审阶段：
建议草案评审。这个阶段评审最终建议草案及其基础：顾客的需求文档，顾客对需求的详细解释，费用与资源评估，同合伙商和分包商已有的合同等。
合同草案评审。这个阶段在后续谈判其达成的理解和建议的基础上评审合同草案。

每个合同评审阶段的目标：
建议草案评审目标如下：

已经考察了完成项目的替代途径。
已经明确顾客与软件公司之间关系的正式方面。
开发风险的识别。
已经充分估计项目资源和进度。
对公司完成项目的能力的考察。
合伙商和分包商参与的确定。
专有权利的确定和保护。

合同草案评审目标如下：

合同草案中没有留下未澄清的问题
在建议之后达成的所有理解正确的文档化。
没有将任何“新“的更改，补充或者遗漏放到合同草案中。

为进行正确的重大合同评审，应当遵守下列指南：

合同评审应该是建议编制进度安排的一部分。
合同评审因该有一个小组执行。
应当制定合同评审组的组长。

一些小的对内项目也应该进行合同评审：
在内部顾客和内部开发者之间维持的松散关系增加了项目失败的可能性。这种倾向可通过确定草案编制的适当规程和应用针对外部合同评审的相同指南而降低。
(待续)

--end