天行健,君子当自强不息: 一月 2007

2007年1月31日星期三

2007年1月30日星期二

2007年1月29日星期一

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

　　①、沟通能力

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

　　②、移情能力

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

　　③、技术能力

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

　　④、自信心

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

　　⑤、外交能力

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

　　⑥、幽默感

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

　　⑦、很强的记忆力

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

　　⑧、耐心

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

　　⑨、怀疑精神

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

　　⑩、自我督促

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

　　11、洞察力

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

转载自CSDN

--end

[+/-]

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

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

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

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

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

一般来说,这几个部分可以集成于一个平台本身,也可是独立的子系统,通过接口有机的结合起来,其实市场上也有很多商用的产品,比如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年1月27日星期六

[+/-]

老爸的颈椎病有救了

2007年1月21日星期日

[+/-]

世界网站之最

2007年1月20日星期六

[+/-]

Mercury LoadRunner的内部架构

[+/-]

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

第 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

2007年1月19日星期五

[+/-]

Hotel California

关于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年1月18日星期四

[+/-]

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

2007年1月17日星期三

[+/-]

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

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

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

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

2007年1月16日星期二

[+/-]

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

2007年1月15日星期一

[+/-]

网易新闻2006科举大典

[+/-]

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

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个最重要的特性（三）

第 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年1月14日星期日

[+/-]

新域名终于可以访问了

[+/-]

Google域名已经成功绑定

2007年1月13日星期六

[+/-]

我的Google域名捆绑梦破灭了

[+/-]

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

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

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

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

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

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

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

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

--end

[+/-]

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

第一个特性就是前面的那篇<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年1月12日星期五

[+/-]

终于拥有自己的域名了

[+/-]

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

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

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

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

[+/-]

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

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.

[+/-]

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

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年1月11日星期四

[+/-]

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

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年1月10日星期三

[+/-]

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

[+/-]

Best Practices in Software Test Automation

[+/-]

开源测试工具的完整解决方案

开源软件运动正在获得很大成功，正在改变软件业的开发模式、运营方法等，也自然改变着软件测试的方法，借助开源软件测试工具完全可以构造一个完整的测试解决方案，可以极大地提高测试效率，又能大大的降低测试成本。从单元测试、功能测试到性能测试，从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年1月9日星期二

[+/-]

Firefox的几款优秀插件

2007年1月8日星期一

[+/-]

<软件质量控制>读书笔记--合同评审

[+/-]

妈妈亲自织的小帽子

[+/-]

天行健,君子当自强不息

很多朋友问,你用这个标题什么意思? 而且Google上很多博客是用这个名字的. 其实这个是有出处的, 记得最早接触是大学时候,那个时候,我们学生会宣传部负责为校运动会出一些板报,开运动会的时候,放置在操场的周围,用以装饰.

我们的部长是铁院有名的才子,写的一手好毛笔字.其中他做的一块板就是以这个标题命名的,后来自己常常用这句话来激励自己,另外还有一个经常说的,就是:天道酬勤. 很多朋友也拿来用以自我激励(天道酬勤据说最早来自<论语>)

天行健，君子以自强不息；地势坤，君子以厚德载物

出自《易经》.
《周易》曰：天行健，君子以自强不息；地势坤，君子以厚德载物。
上句“天行健，君子以自强不息”流传更广。但两千年来，知者多，能解者少。而且，在学术界仍有不同的解释，目前，似乎还没有公认的正确训解。
周易原文
《易经》第一卦乾乾为天乾上乾下
象曰：天行健，君子以自强不息。潜龙勿用，阳在下也。见龙再田，德施普也。终日乾乾，反复道也。或跃在渊，进无咎也。飞龙在天，大人造也。亢龙有悔，盈不可久也。用九，天德不可为首也。
……
乾元者，始而亨者也。利贞者，性情也。乾始能以美利利天下，不言所利。大矣哉！大哉乾乎！刚健中正，纯粹精也。六爻发挥，旁通情也。时乘六龙，以御天也。云行雨施，天下平也。
君子以成德为行，日可见之行也。潜之为言也，隐而未见，行而未成，是以君子弗用也。君子学以聚之，问以辩之，宽以居之，仁以行之。
第二卦坤坤为地坤上坤下
象曰：地势坤，君子以厚德载物。
……
文言曰：坤至柔，而动也刚，至静而德方，后得主而有常，含万物而化光。坤其道顺乎！承天而时行。积善之家，必有馀庆；积不善之家，必有馀殃。

诠释一：
《易经》中认为：
乾为马，坤为牛。
用马来象征天。
故，天行健，就不难理解，骏马以形容自强不息；坤为牛，以牛来诠释人之品德。
有些古句是不需要详细解释的，关键在于个人的体味。

诠释二：
《易经》曰：天行健，君子以自强不息；地势坤，君子以厚德载物。“天行健”与“地势坤”失去了对称，怎回事儿？
据帛书《周易》，“干”为“键”，“天行健”乃“天行键”，“键”乃“干”之古字，而“键”又训为“健”，串在一起：
天，行矣，干（键）。干，健也。
据帛书《周易》，“坤”为“川”，“势”乃“执”，“地势坤”乃“地执川”， “川”乃“坤”之古字，而“川”又训为“顺”，串在一起:
地，执也，坤（川）。坤，顺也。
“地”也有“原初的肯定性的强力”， “执”执力为“势”，所以“地执坤”变成了“地势坤”。 “执”执持、执守；“势”“势力”、 “形势”，坤之义大矣哉。
人参赞天地化育，参入“存在者之整体”，又能“复”，而得以“见天地之心”。天、地、人，三才而两之，中道而行，何惑之有？
天行矣，干。干，健也。君子以自强不息。
地执也，坤。坤，顺也。君子以厚德载物。

诠释三：
“天行健”出自《周易》：“天行健，君子以自强不息”（乾卦）、“地势坤，君子以厚德载物”（坤卦）。
意谓：天（即自然）的运动刚强劲健，相应于此，君子应刚毅坚卓，发愤图强；大地的气势厚实和顺，君子应增厚美德，容载万物。
译为：君子应该像天宇一样运行不息，即使颠沛流离，也不屈不挠；如果你是君子，接物度量要像大地一样，没有任何东西不能承载。

--end

[+/-]

Another Day in Paradise

菲尔·柯林斯(Phil Collins)于1951年出生于英国伦敦，童年时代就酷爱戏剧和音乐。出道时他只是一个乐队的鼓手，80年代初才正式开始个人发展。 1989年推出的专辑《郑重其事（But Seriously）》获得了巨大的成功，柯林斯也因此赢得了1990年度美国音乐奖的最佳摇滚艺术家奖和格莱美最佳个人专辑、最佳单曲、最佳流行男歌手 3项大奖。

<Another day in paradise >是菲尔·柯林斯1990年的力作之一，荣居排行榜冠军数周，从而奠定了菲尔在西洋流行歌坛“抒情才子”的宝座地位。歌中描写了一个流离失所、无处过夜的女子向过路人求救却遭拒绝的一幕，是一首具有很强现实主义的歌曲。歌中唱到：

“你能看到她脸上的皱纹，
你可以想像她在那里已很久，
或许她曾被迫四处漂流，
因为她找不到安身之所。”

菲尔说：相比之下，我们就像生活在天堂一样，而帮助这些可怜的人，只是我们应该做，而且也能够做到的事情。

柯林斯嗓音浑厚、充满激情，深受歌迷喜爱。更为可贵的是，在他近30年的艺术生涯中，他已从一名鼓手成长为集作词、作曲、演唱、演奏、制作为一身的摇滚艺术家。

天堂里的另一天(Another Day in Paradise)歌词

She calls out to the man on the street，
“Sir, can you help me?
It's cold and I've nowhere to sleep，
Is there somewhere you can tell me?”

He walks on, doesn't look back,
He pretends he can't hear her,
Starts to whistle as he crosses the street,
Seems embarrassed to be there.

Oh, think twice,
It's another day for you and me in paradise.
Oh, think twice,
It's just another day for you,
You and me in paradise,
Just think about it.

She calls out to the man on the street,
He can see she's been crying,
She's got blisters on the soles of her feet,
She can't walk, but she's trying.

Oh lord, is there nothing more anybody can do,
Oh lord, there must be something you can say.

You can tell from the lines on her face,
You can see that she's been there.
Probably been moved on from every place,
Because she didn't fit in there.

Oh, think twice,
It's another day for you and me in paradise.
Oh, think twice,
It's just another day for you,
You and me in paradise,
Just think about it.

你可以从下面的地址下载

--end

2007年1月7日星期日

[+/-]

洗牙的痛苦

2007年1月6日星期六

[+/-]

<软件质量保证>--软件质量保证部件概述

[+/-]

Linux中几个不常用但是很有用的命令

2007年1月5日星期五

[+/-]

超库的web2.0网站netvibes.com

[+/-]

羽毛球最近严重退步!

[+/-]

Je m'appelle Helene-我名叫伊莲

Je m'appelle Helene(我名叫伊莲)-法国连续25周冠军单曲。歌词大意是:Hélène 是个常在杂志电视里露面的明星,但她认为自己只是一个叫Hélène 的普通女孩,她的生活也有乐有悲，她只想找到自己的爱，找到属于自己的简单的爱，使她忘记风光背后的寂寞与痛苦，唱出了一个女孩子对平静幸福生活的渴望。

　　法国人对艺术的期许，是举世有目共睹的，法语歌曲在近年大放异彩，尤其是法语流行歌曲第一代言人Hélène 「伊莲」清纯健康的外型，低沈浪漫的嗓音，不仅风靡了整个欧洲大陆，从巴黎到东京，从台湾、香港到中国，也弥漫在一股「伊莲」旋风里。“伊莲”是法国音乐界近25年来炙手可热的代名词，法语歌曲代言者。她低沈浪漫的嗓音配合法文的咬字嚼音，体验超乎想像的音乐美感。她在法国当地的地位，如同我们听见“邓丽君”般，其歌词中带有法式生活哲学以及民谣式曲风营造出歌曲的耐听。

Je m’appelle Hélène
Hélène Rollès

Hélène
Je m’appelle Hélène
Je suis une fille
Comme les autres

Hélène
J’ai mes joies mes peines
Elles font ma vie
Comme la votre

Je voudrais trouver l’amour
Simplement trouver l’amour

Hélène
Si mes nuits sont pleines
De rêves de poémesJe n’ai rien d’autre

Et même
Si j’ai ma photo Dans tous les journaux Chaque semaine
Personne Ne m’attend le soir
Quand je rentre tard
Personne ne fait battre mon coeur
Lorsque s’eteignent les projecteurs

Et même
Quand à la télè Vous me regardez
Sourire et chanter
Personne Ne m’attend le soir
Quand je rentre tard
Personne ne fait battre mon coeur
Lorsque s’eteignent les projecteurs

Hélène
Et toutes mes peines
Trouveront l’oubli Un jour ou l’autre

Quand je trouverai l’amour
Quand je trouverai l’amour
Quand je trouverai l’amour
Quand je trouverai l’amour

中文歌词

伊莲
我叫伊莲
一个很普通的女孩

伊莲
我也有快乐和悲伤
有喜怒哀乐的生活

我只想找到简单的爱情
属于我的爱情

伊莲
我盼望夜里诗歌和美梦的陪伴
那样我会别无所求

每星期报纸上都会有我的照片
你却从没留意
只剩下我一颗破碎的心
和偷偷的哭泣

每天在电视里
你都微笑着轻唱歌曲
我只有更难受的心
和更深的哭泣

我的悲伤终会埋藏于记忆深处
只要我找到简单的爱情
属于我的爱情

可以到这里下载这只专辑