等价类划分

　　是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.

　　 1) 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

　　有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.

　　无效等价类:与有效等价类的定义恰巧相反.

　　设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.

　　2）划分等价类的方法:下面给出六条确定等价类的原则.

　　①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.

　　②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.

　　③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.

　　④在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.

　　⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）.

　　⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.

　　3）设计测试用例:在确立了等价类后,可建立等价类表,列出所有划分出的等价类:

　　 输入条件 有效等价类 无效等价类
　　... ... ...
　　... ... ...

　　 然后从划分出的等价类中按以下三个原则设计测试用例:

　　①为每一个等价类规定一个唯一的编号.

　　②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.

　　③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.

边界值分析法

　　边界值分析方法是对等价类划分方法的补充.

（1）边界值分析方法的考虑:

　　长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

　　使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

（2）基于边界值分析方法选择测试用例的原则:

　　1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.

　　2）如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.

　　3）根据规格说明的每个输出条件,使用前面的原则1）.

　　4）根据规格说明的每个输出条件,应用前面的原则2）.

　　5）如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.

　　6）如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.
  
　　7）分析规格说明,找出其它可能的边界条件.

错误推测法

　　基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

因果图方法

　　前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）.
　　因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

　　利用因果图生成测试用例的基本步骤:

　　(1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符.

　　(2) 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系,画出因果图.

　　(3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件.

　　(4) 把因果图转换为判定表.

　　(5) 把判定表的每一列拿出来作为依据,设计测试用例.

　　从因果图生成的测试用例（局部,组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.

　　前面因果图方法中已经用到了判定表.判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.

　　判定表通常由四个部分组成.

　　条件桩（Condition Stub）:列出了问题得所有条件.通常认为列出得条件的次序无关紧要.

　　动作桩（Action Stub）:列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.

　　条件项（Condition Entry）:列出针对它左列条件的取值.在所有可能情况下的真假值.

　　动作项（Action Entry）:列出在条件项的各种取值情况下应该采取的动作.

　　规则:任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列.

　　判定表的建立步骤:（根据软件规格说明）

　　①确定规则的个数.假如有n个条件.每个条件有两个取值（0,1）,故有 种规则.

　　②列出所有的条件桩和动作桩.

　　③填入条件项.

　　④填入动作项.等到初始判定表.

　　⑤简化.合并相似规则（相同动作）.

　　B. Beizer 指出了适合使用判定表设计测试用例的条件:

　　①规格说明以判定表形式给出,或很容易转换成判定表.

　　②条件的排列顺序不会也不影响执行哪些操作.

　　③规则的排列顺序不会也不影响执行哪些操作.

　　④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则.

　　⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要.

软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程，其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的类型。

1 数据和数据库完整性测试

数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。
数据库完整性原即：
主码完整性：主码不能为空；
外码完整性：外码必须等于对应的主码或者为空。
数据合理性指数据在数据库中的类型，长度，索引等是否建的比较合理。
在项目名称中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确定可以支1持测试的工具和技术。

比如，有两张表：部门和员工。部门中有部门编号，部门名称，部门经理等字段，主码为部门编号；员工表中有员工编号，员工所属部门编号，员工名称，员工类型等字段，主码为员工编号，外码为员工所属部门编号，对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空，他就违反主码完整性原则。如果某个员工所属部门的编号为##，但是##在部门编号中确找不到，这就违反外码完整性原则。
员工类型如下定义：0：职工，1：职员，2：实习生。但数据类型为Int，我们都知道Int占有4个字节，如果定义成char(1).就比原来节约空间。

2 白盒测试

白盒测试是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试

2.1 静态白盒测试

利用眼睛，浏览代码，凭借经验，找出代码中的错误或者代码中不符合书写规范的地方。比如，代码规范中规定，函数必须为动宾结构。而黑盒测试发现一个函数定义如下：
Function NameGet(){
….
}
这是属于不符合开发规范的错误。
有这样一段代码:
if (i<0) & (i>=0)
…
这段代码交集为整个数轴，IF语句没有必要
I=0;
while(I>100){
J=J+100;
T=J*PI;
}
在循环体内没有I的增加,bug产生。

2.2 动态白盒测试

利用开发工具中的调式工具进行测试。比如一段代码有4个分支，输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。
看一段代码
if(I<0){
P1
}else{
P2
}
在调试中输入I=-1,P1程序段通过， P2程序段未通过，属于动态黑盒测试的缺陷

3.功能测试

功能测试指测试软件各个功能模块是否正确，逻辑是否正确。
对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面 (GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。
比如一个对电子商务系统，前台用户浏览商品-放入购物车-进入结账台，后台处理订单，配货，付款，发货，这一系列流程必须正确无误的走通，不能存在任何的错误。

4.UI测试

UI测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等等
用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化，易操作性测试。UI测试比较主观，与测试人员的喜好有关
比如：页面基调颜色刺眼；用户登入页面比较难于找到，文字中出现错别字，页面图片范围太广等都属于UI测试中的缺陷，但是这些缺陷都不太严重。
 
5.性能测试

性能测试主要测试软件测试的性能，包括负载测试，强度测试，数据库容量测试，基准测试以及基准测试

5.1负载测试

负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。
在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
比如，在B/S结构中用户并发量测试就是属于负载测试的用户，可以使用webload工具，模拟上百人客户同时访问网站，看系统响应时间，处理速度如何？

5.2强度测试

强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。
实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
比如：一个系统在内存366M下可以正常运行，但是降低到258M下不可以运行，告诉内存不足，这个系统对内存的要求就是366M。

5.3数据库容量测试

数据库容量测试指通过存储过程往数据库表中插入一定数量的数据，看看相关页面是否能够及时显示数据。
数据库容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录，计算相关页面的调用时间。
比如，在电子商务系统中，通过insert customer 往user表中插入10 000数据，看其是否可以正常显示顾客信息列表页面，如果要求达到最多可以处理100 000个客户，但是顾客信息列表页面不能够在规定的时间内显示出来，就需要调整程序中的SQL查询语句；如果在规定的时间内显示出来，可以将用户数分别提高到20 000 , 50 000, 100 000进行测试。

5.4基准测试

基准测试与已知现有的系统进行比较，主要检验是否与类似的产品具有竞争性的一种测试。
如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据，你可以测试你这套系统，看看哪些地方比用友财务系统好，哪些地方差？以便改进自己的系统，也可为产品广告提供数据。

5.5竞争测试

软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。比如：一台机器上即安装您的财务系统，又安装用友财务系统。当CPU占有率下降后，看看是否能够强过用友财务系统，而是自己的系统能够正常运行？

6. 安全性和访问控制测试

安全性和访问控制测试侧重于安全性的两个关键方面：
应用程序级别的安全性，包括对数据或业务功能的访问
系统级别的安全性，包括对系统的登录或远程访问。

6.1应用程序级别的安全性

可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户消息（包括财务数据），而“用户二”只能看见同一客户的统计数据。
比如B/S系统，不通过登入页面，直接输入URL,看其是否能够进入系统？

6.2系统级别的安全性

可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。
比如输入管理员账户，检查其密码是否容易猜取，或者可以从数据库中获得？

7.故障转移和恢复测试

故障转移和恢复测试指当主机软硬件发生灾难时候，备份机器是否能够正常启动，使系统是否可以正常运行，这对于电信，银行等领域的软件是十分重要的。
故障转移和恢复测试可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。
恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。一定要注意主备定时备份
比如电信系统，突然主机程序发生死机，备份机器是否能够启动，使系统能够正常运行，从而不影响用户打电话？

8.配置测试

又叫兼容性测试。配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。（如浏览器版本，操作系统版本等）
下面列出主要配置测试

8.1浏览器兼容性

测试软件在不同产商的浏览器下是否能够正确显示与运行；
比如测试IE，Natscape浏览器下是否可以运行这套软件？

8.2操作系统兼容性

测试软件在不同操作系统下是否能够正确显示与运行；
比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件？

8.3硬件兼容性

测试与硬件密切相关的软件产品与其他硬件产品的兼容性，比如该软件是少在并口设备中的，测试同时使用其他并口设备，系统是否可以正确使用.
比如在INTER,舒龙CPU芯片下系统是否能够正常运行？
这样的测试必须建立测试实验室，在各种环境下进行测试。

9.安装测试

安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如，进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。
安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装，安装代码提供安装一些程序能够运行的基础数据。

10.多语种测试

又称本地化测试，是指为各个地方开发产品的测试，如英文版，中文版等等，包括程序是否能够正常运行，界面是否符合当地习俗，快捷键是否正常起作用等等，特别测试在A语言环境下运行B语言软件（比如在英文win98下试图运行中文版的程序），出现现象是否正常。
本地化测试还要考虑：
l 当语言从A翻译到B，字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”，翻译到英文版本中为 “View advertisement”可能影响页面的美观程度
l 要考虑同一单词在各个国家的不同意思，比如football在英文中为足球，而美国人使用中可能理解为美式橄榄球。
l 要考虑各个国家的民族习惯，比如龙个美国中被理解邪恶的象征，但翻译到中国，中国人认为为吉祥的象征。

11.文字测试

文字测试测试软件中是否拼写正确，是否易懂，不存在二义性，没有语法错误；文字与内容是否有出入等等，包括图片文字。
比如：“比如，请输入正确的证件号码！”何谓正确的证件号码，证件可以为身份证，驾驶证，也可为军官证，如果改为“请输入正确的身份证号码！”用户就比较容易理解了。

12.分辨率测试

测试在不同分辨率下，界面的美观程度,分为800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率，而在其他分辨率下也都能可以运行。

13.发布测试

主要在产品发布前对一些附带产品，比如说明书，广告稿等进行测试

13.1说明书测试

主要为语言检查，功能检查，图片检查
语言检查：检查说明书语言是否正确，用词是否易于理解；
功能检查：功能是否描述完全，或者描述了并没有的功能等；
图片检查:：检查图片是否正确

13.2宣传材料测试

主要测试产品中的附带的宣传材料中的语言，描述功能，图片

13.3帮助文件测试

帮助文件是否正确，易懂，是否人性化。最好能够提供检索功能。

13.4广告用语

产品出公司前的广告材料文字，功能，图片，人性化的检查

14 文档审核测试

文档审核测试目前越来越引起人们的重视，软件质量不是检查出来的，而是融进软件开发中来。前置软件测试发越来越受到重视。请看一个资料：

文档审核测试主要包括需求文档测试，设计文档测试，为前置软件测试测试中的一部分。

14.1需求文档测试

主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现；

14.2设计文档测试

测试设计是否符合全部需求以及设计是否合理。

总结

据美国软件质量安全中心2000年对美国一百家知名的软件厂商统计，得出这样一个结论：软件缺陷在开发前期发现比在开发后期发现资金，人力上节约90%；软件缺陷在推向市场前发现比在推出后发现资金，人力上节约90%。所以说软件的缺陷应该尽早发现。不是所有的软件都要进行任何类型的软件测试的，可以根据产品的具体情况进行组装测试不同的类型

1 生产随机数列
第一种方法
randomize'更新反回的数据
funcation rand(k)
n=int((k-1)*rnd+1)
rand=n
end funcation

第二种方法
n=randomnumber.value(1,255)

2  当运行到表中的某一行，自动导出表中的所有数据
row=datatable.getcurrentrow
if row="5" then
  datatable.export("d:\data.xml")
end if

3
webedit("txtpass").setsecure"sdsdf...."
如果参数化密码，可以直接在数据表中写入未加密的密码，它会自动识别，即不用把setsecure改为set

4　如果弹出对话框就获取上面提示信息并与表中的信息对比，不统一证明弹出的提示出错,主要用来验证
if browser("web_name").dialog("dialog_name").exist(1) then'如果不出现=false
     error_message=browser("web_name").dialog("diaglog_name").static("用户密码错误!".getRoproperty("text")
　　　if error_message<>(datatable.value("error_info"))then
         msgbox(error_message)
      end if
     browser("web_name").dialog("diaglog_name").close
  end if
这里我总结了两点技巧：
　　一是：对于dialog中，虽然提示信息对象名称是"用户密码错误"，但如果信息对象名称是“该用户不存在”，不用更改会自动识别，我想主要是录制第一遍时，“用户密码错误”只是让运行时能找到这个控制，而不管它是什么内容，因为在对象仓库中，text不是决定该对象的属性
    二是：如果对于提示信息比较长的，可以用mid(error_message,n,m)取一部份特征提示信息进行验证，这样我想可以节省处理时间，又可以避免长度以及空格等字符的处理

5  datatable.value("num")只在global形式下的一种省略形式；完整形式是:
datatable.value("num",dtlocalsheet)

-----向某一列的单元格赋值:
datatable.value("column_name",dtlocalsheet)="nanjing"

-----取得某一行具体值：
datatable.setcurrentrow(n)
msgbox(datatable.getsheet("global").getparameter("column_name").Rawvalue)
或者kk=datatable.Rawvalue("column_name","action1")

----在run-time时，动态添加表格与数据
kk=datatable.addsheet("sheet_name").addparameter("column_name","value").name;

7   wintreeview一些操作
选择一个条目:wintreeview.select(item)'根是0
根的名称：wintreeview.getitem(0)

8   数据库检查点模块:
sub database_check
set con=createobject("adodb.connection")
con.open "Descrīption=IBM_ODBC;DRIVER=SQL Server;SERVER=IBM;UID=sa;"&_
                 "PWD=123456;APP=Quick Test Pro;WSID=IBM;DATABASE=IBM_table"
'access方式:con.open "DRIVER={Microsoft Access Driver (*.mdb)};DBQ=d:\test.mdb"
'Orocle方式:con.open "DRIVER={Oracle in OraHome92};SERVER=CESHI;UID=CND_TEST;PWD=CND;DBQ=CESHI;DBA=W;APA=T;EXC=F;XSM=Default;FEN=T;QTO=T;FRC=10;FDL=10;LOB=T;RST=T;GDE=F;FRL=Lo;BAM=IfAllSuccessful;MTS=F;MDI=Me;CSR=F;FWC=F;PFC=10;TLO=O;"
set record=createobject("adodb.recordset")
sql="select*from ibm_one_table"
record.open sql,con
DO
if(record("ibm_table_column")="kai")then'//查找表格中有多少kai
num=num+1;
end if
record.movenext
loop until record.eof=true
record.close
set record=nothing
con.close
set con=nothing
end sub

9   换行符
    vbcr----chr(13)回车符// vblf----chr(10)换行符
    vbcrlf----chr(13)+chr(10)结合//type(chr(13)就相当于按了一上键盘上的enter

10  Run from step有两种方式：
在Keyword View模式会从本步骤运行到所有action结束
在expert view模式仅会将本action运行结束

11  由于对象属性原因，无法识别对象
-----对于对象属性是变化的，可以参数化/或者用正则表达式
-----报匹配多个对象错误，可以spy查看对象，添加一个该对象另一个唯一标识属性
-----有时可以删除对象的变化的属性来解决识别问题
------对于多个完全相同的对象，可以采用添加index,location,createtime等特殊属性来识别
　　(index:按照程序源码，绘制对象的先后标识对象，所以与其它相同对象是相互依赖，当其它对象发生
　　变化后，原先的所有对象index属性要发生变化，开始是0；如index:=0;
        location：根据对象的位置进行确定，从上到下，从左到右;
　　CreateTime：按照对象被浏览器打开的先后标识对象)
------另外换一种思维方式，采取等效的方法；比如用键盘代替鼠标或用操作系统本身特性去解决问题

12  对系统文件的操作
-------从系统的文件中获取信息及删除文件
  get_file_infor("c:\she.mpg")
   function get_file_infor(url)
    dim fso,f
    set fso=createobject("scrīpting.filesystemobject")
    set f=fso.getfile(url)
    f.name:f.size:f.type:f.datacreated'///获取文件信息
    fso.deletefile(url)'/////删除文件
   end function
--------获取文件夹里所有文件信息
get_folder_infor("c:\kai")
function get_folder_infor(folder)
dim fso,f,f1,n
set fso=createobject("scrīpting,filesystemobject")
set f=fso.getfolder(folder)
set fc=f.files
for each f1 in fc
select case f1.name
case"kai.mpg","she.mpg","dd.mp3"'//检查文件夹里是否含有这些文件
end select
next
end function

13   等待某个对象出现方法
y=......waitproperty("visible",true,10000)

14   防程序中断方法
On error resume next
On error goto handle

15  数组的应用:
name=array(1,2,"aa","bb")
name(2)="aa"
16  正则表达式应用模板
进行日期YYYY-MM-DD的格式检查　:
Function RegExpTest(patrn, strng)
  Dim regEx, Match, Matches      ' Create variable.
  Set regEx = New RegExp         ' Create a regular expression.
  regEx.Pattern = patrn         ' Set pattern.
  regEx.IgnoreCase = True         ' Set case insensitivity.
  regEx.Global = True         ' Set global applicability.
  Set Matches = regEx.Execute(strng)   ' Execute search.
  For Each Match in Matches      ' Iterate Matches collection.
    RetStr = RetStr & "Match found at position "
    RetStr = RetStr & Match.FirstIndex & ". Match Value is '"
    RetStr = RetStr & Match.Value & "'." & vbCRLF
  Next
  RegExpTest = RetStr
End Function
date_pattern="^((((19|20)(([02468][048])|([13579][26]))-02-29))|((20[0-9][0-9])|(19[0-9][0-9]))-((((0[1-9])|(1[0-2]))-((0[1-9])|(1\d)|(2[0-8])))|((((0[13578])|(1[02]))-31)|(((01,3-9])|(1[0-2]))-(29|30)))))$"
result_message=RegExpTest(date_pattern, inputbox("请你输入要检查的时间："))'用其它正则表达式更改此处
Select case result_message
Case ""
         msgbox("你输入的日期格式与标准不匹配")
case else  MsgBox(result_message)
end select

17   返回一个字符串在另一字符串中的位置
instr(string1,string2)

18   有时回放出现找不到对象时，可能不是由于你的代码问题，而是由于你的操作系统等设置问题；
举例说明1：
比如：你录制一个选择磁盘中的文件动作
会录制为：
.winlistview("  ").drap 46,99
.winlistview("  ").draponitem "she.mp3"
下次录制的时候，如果你的系统文件改为不显示扩展名，下次执行的时候，QTP就找不到she.mp3，只能找到she;
举例说明2：
有时由于不同操作系统以及不同的ie，导致有些窗口不能识别，比如在2000下弹出的网页对话框的标题是：
“web对话框",而在2003上是”网页对话框"

19  "is+*"类型function
isarray'是否是数组
isconnected'判断QTP是否连接到TD
isdate'是否是合法的日期类型
isempty'判断是否初始化
isNull'判断是否为空值
isNumeric'判断是否是数字型
isobject'判断是否一个功能对象
isready'判断设备是否准备就绪
isRootFolder'是否是根目录

20 Action之间的参数传递
例如:在Action1中，有如下代码:
out_str="This is out_string"
RunAction "Action2",oneIteration,out_str
在Acton2中，在其step->Action Properties中的，input参数栏，加入out_str后,
msgbox(parameter("out_str"))，就能正确显示参数了　

21 Wscrīpt.Shell的一些应用
set WshShell =CreateObject("Wscrīpt.Shell")
WshShell.SendKeys "{ENTER}"　　　　　'模拟键盘进行操作
WshShell.AppActivate "Calculator"             '启动应用程序

22 获取对象属性名称用法:
GetRoProperty----从应用程序界面上获取对象属性（即，是脚本运行时，获取的对象动态属性值）
           例如：获取对象库中index属性值，似乎只能用GetToProperty,因为应用程序界面上对象没有该属性，只是QTP为识别该对象创立的描述属性；
GetToproperty----从对象库中描述对象的属性，静态值
GetToProperties----获取用于标识对象的属性集；对于这个集合，有count等属性方法

23 FireEvent的使用-
可以对一个对象进行更复杂的操作
如:FireEvent("onfocus")   '使一个控件获取焦点
     FireEvent("ondblclick")  '实现双击/也可以在事件设定中针对该对象事件响应　　

24 模板的应用
-----新建一个文本，输入一些新建Action时常包含的信息，然后保存为ActionTemplate.MST文件,
　并复制到QTP/dat目录下；这样每次新建action都会包含固定的信息了;
例如:
'-------------------脚本说明---------------
'产品版本:      __Build(  )
'测试员:
'编写日期:
'测试功能:
'脚本类型:
'被测试对象初始状态:
'进展程度:
'基本思路:
'主要功能函数:
'历史修改:
'没解决的问题:
'--------------------脚本内容-------------

25 在对象库中，两个对象有时不能通过更改属性或命名来达到两个对象完全一致的替换；
在web-mod项目中，我在对象库里添加了一个自动含有index标识属性的对象，然后每次通过SetToproperty来改变
index值，对对象进行数据驱动，使其操作另一个对象，但脚本始终操作原先index属性值的对象;后来，把该对象
删除掉，重新添加一个不自动含有index标识属性的该类对象，然后，手工添加，index标识属性，后来脚本能正常 工作了，可见两次的对象属性完全一致，但形成方式不一样，导致的结果往往也不一样;

26 childobject的应用
childobject可以返回界面上满足条件的对象集合，而且与对象库里是否有这些对象无关，这就可以简化对象库；
返回的对象集合的count方法可以返回对象个数，这就可以通过下标对单个对象进行操作；在出现index标识对象时
可以进行运用
如:Set m_WinCheck=Descrīption.Create()
      m_WinCheck("nativeclass").Value="Button"
      set All_WinCheck=Window("").Dialog("").Childobject(m_WinCheck)
      n=All_WinCheck.Count()
     for i=0 to n-1
      All_WinCheck(i).Set "ON"
     next
再加三个

27 Create Log File:

Dim LOGFile, fso, MyFile

LOGFile="C:\Log.txt"
Set fso = CreateObject("scrīpting.FileSystemObject")
    If fso.FileExists(LOGFile) = False Then
           Set MyFile = fso.CreateTextFile(LOGFile, True)
           MyFile.Close
    end if
Set MyFile = fso.OpenTextFile(LOGFile, 8, True)
MyFile.WriteLine("")
MyFile.WriteLine(" " & Cstr(Now) & " ---------------------------------------------------------")
MyFile.WriteLine("LOG Information!")
MyFile.Close
28 数据输入输出方法
数据输入输出的方法：
1  ExecuteFile"e:\kk.vbs"
2  Environment.LoadFromFile("e:\k.xml")
3  Datatable.ImportSheet/Import
4  GetData from DataBase
5  Datatable autofill
6  Action input/output
7  Use GetxxProperty to get data from Object
8  Use Some Function to Product data

1. 获取本机所有本地与网络打印机属性：

strComputer = "."
Set ōbjWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colInstalledPrinters =  objWMIService.ExecQuery ("Select * from Win32_PrinterDriver")

PrtNameArray = Array ()
ReDim PrtNameArray (colInstalledPrinters.Count-1)
i = 0
For each objPrinter in colInstalledPrinters
 PrtNameArray(i) = objPrinter.Name
 i = i + 1
Next

Reference from Microsoft.com (scrīpt Center)

strComputer = "."
Set ōbjWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colInstalledPrinters =  objWMIService.ExecQuery _
    ("Select * from Win32_PrinterDriver")

For each objPrinter in colInstalledPrinters
    Wscrīpt.Echo "Configuration File: " & objPrinter.ConfigFile
    Wscrīpt.Echo "Data File: " & objPrinter.DataFile
    Wscrīpt.Echo "Descrīption: " & objPrinter.Descrīption
    Wscrīpt.Echo "Driver Path: " & objPrinter.DriverPath
    Wscrīpt.Echo "File Path: " & objPrinter.FilePath
    Wscrīpt.Echo "Help File: " & objPrinter.HelpFile
    Wscrīpt.Echo "INF Name: " & objPrinter.InfName
    Wscrīpt.Echo "Monitor Name: " & objPrinter.MonitorName
    Wscrīpt.Echo "Name: " & objPrinter.Name
    Wscrīpt.Echo "OEM Url: " & objPrinter.OEMUrl
    Wscrīpt.Echo "Supported Platform: " & objPrinter.SupportedPlatform
    Wscrīpt.Echo "Version: " & objPrinter.Version
Next

2. 获取网络打印机属性

Reference from QTP Help (Windows scrīpt Host)

Set WshNetwork = Wscrīpt.CreateObject("Wscrīpt.Network")
Set ōDrives = WshNetwork.EnumNetworkDrives
Set ōPrinters = WshNetwork.EnumPrinterConnections
Wscrīpt.Echo "Network drive mappings:"
For i = 0 to oDrives.Count - 1 Step 2
   Wscrīpt.Echo "Drive " & oDrives.Item(i) & " = " & oDrives.Item(i+1)
Next
Wscrīpt.Echo
Wscrīpt.Echo "Network printer mappings:"
For i = 0 to oPrinters.Count - 1 Step 2
   Wscrīpt.Echo "Port " & oPrinters.Item(i) & " = " & oPrinters.Item(i+1)
Next

On Error Resume Next
strComputer = "localhost"
Set ōbjWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_PerfRawData_PerfOS_Memory",,48)

For Each objItem in colItems
msgbox objItem.AvailableBytes
Next
Set ōbjWMIService = Nothing
Set colItems = Nothing

Abs(number) 取得数值的绝对值。  
Asc(String) 取得字符串表达式的第一个字符ASCII 码。  
Atn(number) 取得一个角度的反正切值。  
CallByName (object, procname, usecalltype,[args()]) 执行一个对象的方法、设定或传回对象的属性。  
CBool(expression) 转换表达式为Boolean 型态。  
CByte(expression) 转换表达式为Byte 型态。  
CChar(expression) 转换表达式为字符型态。  
CDate(expression) 转换表达式为Date 型态。  
CDbl(expression) 转换表达式为Double 型态。  
CDec(expression) 转换表达式为Decimal 型态。  
CInt(expression) 转换表达式为Integer 型态。  
CLng(expression) 转换表达式为Long 型态。  
CObj(expression) 转换表达式为Object 型态。  
CShort(expression) 转换表达式为Short 型态。  
CSng(expression) 转换表达式为Single 型态。  
CStr(expression) 转换表达式为String 型态。  
Choose (index, choice-1[, choice-2, ... [, choice-n]]) 以索引值来选择并传回所设定的参数。  
Chr(charcode) 以ASCII 码来取得字符内容。  
Close(filenumberlist) 结束使用Open 开启的档案。  
Cos(number) 取得一个角度的余弦值。  
Ctype(expression, typename) 转换表达式的型态。  
DateAdd(dateinterval, number, datetime) 对日期或时间作加减。  
DateDiff(dateinterval, date1, date2) 计算两个日期或时间间的差值。  
DatePart (dateinterval, date) 依接收的日期或时间参数传回年、月、日或时间。  
DateSerial(year, month, day) 将接收的参数合并为一个只有日期的Date 型态的数据。  
DateValue(datetime) 取得符合国别设定样式的日期值，并包含时间。 
Day(datetime) 依接收的日期参数传回日。  
Eof(filenumber) 当抵达一个被开启的档案结尾时会传回True。  
Exp(number) 依接收的参数传回e 的次方值。  
FileDateTime(pathname) 传回档案建立时的日期、时间。  
FileLen(pathname) 传回档案的长度，单位是Byte。  
Filter(sourcearray, match[, include[, compare]])  搜寻字符串数组中的指定字符串，凡是数组元素中含有指定字符串，会将它们结合成新的字符串数组并传回。若是要传回不含指定字符串的数组元素，则 include 参数设为False。compare 参数则是设定搜寻时是否区分大小写，此时只要给TextCompare 常数或1 即可。  
Fix(number) 去掉参数的小数部分并传回。  
Format(expression[, style[, firstdayofweek[, firstweekofyear]]]) 将日期、时间和数值资料转为每个国家都可以接受的格式。  
FormatCurrency(expression[,numdigitsafterdecimal [,includeleadingdigit]]) 将数值输出为金额型态。numdigitsafterdecimal 参数为小数字数，includeleadingdigit 参数为当整数为0 时是否补至整数字数。  
FormatDateTime(date[,namedformat]) 传回格式化的日期或时间数据。  
FormatNumber(expression[,numdigitsafterdecimal [,includeleadingdigit]]) 传回格式化的数值数据。Numdigitsafterdecimal 参数为小数字数，includeleadingdigit 参数为当整数为0 时是否补至整数字数。  
FormatPercent(expression[,numdigitsafterdecimal [,includeleadingdigit]]) 传回转换为百分比格式的数值数据。numdigitsafterdecimal 参数为小数字数,includeleadingdigit 参数为当整数为0 时是否补至整数字数。  
GetAttr(filename) 传回档案或目录的属性值。  
Hex(number) 将数值参数转换为16 进制值。
Hour(time) 传回时间的小时字段，型态是Integer。  
Iif(expression, truepart, falsepart) 当表达式的传回值为True 时执行truepart 字段的程序，反之则执行falsepart 字段。  
InStr([start, ]string1, string2) 搜寻string2 参数设定的字符出现在字符串的第几个字符，start 为由第几个字符开始寻找，string1 为欲搜寻的字符串，string2 为欲搜寻的字符。  
Int(number) 传回小于或等于接收参数的最大整数值。  
IsArray(varname) 判断一个变量是否为数组型态，若为数组则传回True，反之则为False。 
IsDate(expression) 判断表达式内容是否为DateTime 型态，若是则传回True，反之则为False。  
IsDbNull(expression) 判断表达式内容是否为Null，若是则传回True，反之则为False。  
IsNumeric(expression) 判断表达式内容是否为数值型态，若是则传回True，反之则为False。  
Join(sourcearray[, delimiter]) 将字符串数组合并唯一个字符串，delimiter 参数是设定在各个元素间加入新的字符串。  
Lcase(string) 将字符串转换为小写字体。  
Left(string, length) 由字符串左边开始取得length 参数设定长度的字符。  
Len(string) 取得字符串的长度。  
Log(number) 取得数值的自然对数。  
Ltrim(string) 去掉字符串的左边空白部分。  
Mid(string, start[, length]) 取出字符串中strat 参数设定的字符后length 长度的字符串，若length 参数没有设定，则取回start 以后全部的字符。  
Minute(time) 取得时间内容的分部分，型态为Integer。  
MkDir(path) 建立一个新的目录。  
Month(date) 取得日期的月部分，型态为Integer。 
MonthName(month) 依接收的月份数值取得该月份的完整写法。  
Now() 取得目前的日期和时间。  
Oct(number) 将数值参数转换为8 进制值。  
Replace(expression, find, replace) 将字符串中find 参数指定的字符串转换为replace 参数指定的字符串。  
Right(string,length) 由字符串右边开始取得length 参数设定长度的字符。  
RmDir(path) 移除一个空的目录。  
Rnd() 取得介于0 到1 之间的小数，如果每次都要取得不同的值，使用前需加上Randomize 叙述。  
Rtrim(string) 去掉字符串的右边空白部分。  
Second(time) 取得时间内容的秒部分，型态为Integer。  
Sign(number) 取得数值内容是正数或负数，正数传回1，负数传回-1，0 传回0。  
Sin(number) 取得一个角度的正弦值。  
Space(number) 取得number 参数设定的空白字符串。 
Split(expression[, delimiter]) 以delimiter 参数设定的条件字符

 

 

 

 

Abs 函数：返回数的绝对值。  
Array函数：返回含有数组的变体。 
Asc 函数：返回字符串首字母的 ANSI 字符码。
Atn 函数：返回数值的反正切。  
CBool函数：返回已被转换为 Boolean 子类型的变体的表达式。  
CByte函数：返回已被转换为字节子类型的变体的表达式。  
CCur 函数：返回已被转换为货币子类型的变体的表达式。  
CDate函数：返回已被转换为日期子类型的变体的表达式。  
CDbl函数：返回已被转换为双精度子类型的变体的表达式。  
Chr 函数：返回与指定的 ANSI 字符码相关的字符。  
CInt 函数：返回已被转换为整形子类型的变体的表达式。  
CLng 函数；返回已被转换为Long子类型的变体的表达式。  
Cos 函数：返回角度的余弦。   C
reateObject函数：创建并返回对“自动”对象的引用。
CSng函数：返回已被转换为单精度子类型的变体的表达式。
CStr函数：返回已被转换为字符串子类型的变体的表达式。
Date函数：返回当前系统日期。
DateAdd 函数：返回的日期已经加上了指定的时间间隔。
DateDiff 函数：返回两个日期之间的间隔。
DatePart 函数：返回给定日期的指定部分。
DateSerial函数：返回指定年月日的日期子类型的变体。
DateValue 函数：返回日期子类型的变体。
Day 函数：返回日期，取值范围为 1 至 31。
Eval 函数：计算表达式并返回结果。
Exp 函数：返回 e （自然对数的底） 的多少次方。
Filter函数：根据指定的筛选条件,返回含有字符串数组子集的、下限为 0 的数组。
Fix 函数：返回数的整数部分。
FormatCurrency 函数：返回的表达式为货币值格式，其货币符号采用系统控制面板中定义的。
FormatDateTime 函数：返回的表达式为日期和时间格式。
FormatNumber 函数：返回的表达式为数字格式。
FormatPercent 函数：返回的表达式为百分数（乘以 100）格式，后面有 % 符号。
GetObject 函数：返回从文件对“自动”对象的引用。
GetRef 函数：返回对能够绑定到一事件的过程的引用。
Hex 函数：返回一字符串，代表一个数的十六进制值。
Hour函数：返回表示钟点的数字，取值范围为 0 至 23。
InputBox函数：在对话框中显式一提示，等待用户输入文本或单击按钮，并返回文本框的内容。
InStr函数：返回一个字符串在另一个字符串中首次出现的位置。
InStrRev函数；返回一个字符串在另一个字符串中出现的位置，但是从字符串的尾部算起。

VBS启动QTP并自动运行：

Set qtApp = CreateObject("QuickTest.Application") 
qtApp.Launch 
qtApp.Visible = True
qtApp.Open "C:\Test1"
qtApp.Test.Run

wsh键值表
键          参数
退格键      {BACKSPACE}、{BS}或{BKSP}
BREAK       {BREAK}
CAPS LOCK   {CAPSLOCK}
DEL或DELETE{DELETE}或{DEL}
下箭头      {DOWN}
END         {END}
ENTER       {ENTER}或~
ESC         {ESC}
HOME        {HOME}
INS或INSERT{INSERT}或{INS}
左箭头      {LEFT}
NUM LOCK    {NUMLOCK}
PAGE DOWN   {PGDN}
PAGE UP     {PGUP}
PRINT SCREEN{PRTSC}
右箭头      {RIGHT}
SCROLL LOCK{SCROLLLOCK}
TAB         {TAB}
上箭头      {UP}
F1、F2、F3...{F1}、{F2}、{F3}Q

只需要输入操作窗口、对象以及列表索引即可操作：

Function SelectDropdownItem (win, obj, index)
   Window(win).WinObject(obj).Click 1,1

   Set WshShell = CreateObject("Wscrīpt.Shell")
   For i=1 to index
      WshShell.sendKeys "{DOWN}"
   Next
      WshShell.sendKeys "{ENTER}"
   Wait (1)
   Set WshShell = nothing
End Function

SelectDropdownItem.zip
(2007-12-28 16:46:52, Size: 391 B , Downloads: 0)

V&V   Vevification&Validation     验证&确认

测试用例名：PEOJECT —ST—001

                    系统名称   测试阶段   测试编号

Incident      事故    

Summary   总结

TIR    test incident report    测试事故报告

TST  TEST SUMMARY REPORT 测试总结报告

SQAP   SOFTWARE QUALITY ASSURENCE PLAN 软件质量保证计划

SVVP  SOFTWARE Vevification&Validation  PLAN 软件验证和确认计划

VTP   Vevification  TEST PLAN验证测试计划

MTP    MAIN TEST PLAN主确认计划

DTP  DETAIL TEST PLAN详细确认测试计划

TDS   TEST DESIGN SPECIFICATION 测试设计规格说明书

TDS  TEST DESIGN SPECIFCATION 测试设计规格说明

TCS  TEST CASE SPECIFICATION 测试用例规格说明

TPS TEST PROCESS SPECIFCATION 测试步凑规格说明

TC   TEST CASE 测试用例

VTR  Vevification TEST REPORT验证测试报告

TPS TEST PEOCESS SPECIFICATION 测试步凑规格说明

TW TEST WARE 测试件

 

OTHER DETAILS：

Acceptance Testing－－可接受性测试
一般由用户/客户进行的确认是否可以接受一个产品的验证性测试。

actual outcome－－实际结果       
被测对象在特定的条件下实际产生的结果。

Ad Hoc Testing－－随机测试       
测试人员通过随机的尝试系统的功能，试图使系统中断。

algorithm－－算法       
（1）一个定义好的有限规则集，用于在有限步骤内解决一个问题；（2）执行一个特定任务的任何操作序列。

algorithm analysis－－算法分析       
一个软件的验证确认任务，用于保证选择的算法是正确的、合适的和稳定的，并且满足所有精确性、规模和时间方面的要求。

Alpha Testing－－Alpha测试       
由选定的用户进行的产品早期性测试。这个测试一般在可控制的环境下进行的。

analysis－－分析       
（1）分解到一些原子部分或基本原则，以便确定整体的特性；（2）一个推理的过程，显示一个特定的结果是假设前提的结果；（3）一个问题的方法研究，并且问题被分解为一些小的相关单元作进一步详细研究。

anomaly－－异常       
在文档或软件操作中观察到的任何与期望违背的结果。

application software－－应用软件       
满足特定需要的软件。

architecture－－构架       
一个系统或组件的组织结构。

ASQ－－自动化软件质量（Automated Software Quality）
使用软件工具来提高软件的质量。

assertion－－断言       
指定一个程序必须已经存在的状态的一个逻辑表达式，或者一组程序变量在程序执行期间的某个点上必须满足的条件。

assertion checking－－断言检查       
用户在程序中嵌入的断言的检查。

audit－－审计       
一个或一组工作产品的独立检查以评价与规格、标准、契约或其它准则的符合程度。

audit trail－－审计跟踪       
系统审计活动的一个时间记录。

Automated Testing－－自动化测试       
使用自动化测试工具来进行测试，这类测试一般不需要人干预，通常在GUI、性能等测试中用得较多。

Backus-Naur Form－－BNF范式       
一种分析语言，用于形式化描述语言的语法

baseline－－基线       
一个已经被正式评审和批准的规格或产品，它作为进一步开发的一个基础，并且必须通过正式的变更流程来变更。

Basic Block－－基本块       
一个或多个顺序的可执行语句块，不包含任何分支语句。

basis test set－－基本测试集       
根据代码逻辑引出来的一个测试用例集合，它保证能获得100%的分支覆盖。

behaviour－－行为       
对于一个系统的一个函数的输入和预置条件组合以及需要的反应。一个函数的所有规格包含一个或多个行为。

benchmark－－标杆/指标/基准       
一个标准，根据该标准可以进行度量或比较。

Beta Testing－－Beta测试       
在客户场地，由客户进行的对产品预发布版本的测试。这个测试一般是不可控的。

big-bang testing－－大锤测试/一次性集成测试       
非渐增式集成测试的一种策略，测试的时候把所有系统的组件一次性组合成系统进行测试。

Black Box Testing－－黑盒测试       
根据软件的规格对软件进行的测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。

bottom-up testing－－由低向上测试       
渐增式集成测试的一种，其策略是先测试底层的组件，然后逐步加入较高层次的组件进行测试，直到系统所有组件都加入到系统。

boundary value－－边界值       
一个输入或输出值，它处在等价类的边界上。

boundary value coverage－－边界值覆盖       
通过测试用例，测试组件等价类的所有边界值。

boundary value testing－－边界值测试       
通过边界值分析方法来生成测试用例的一种测试策略。

Boundry Value Analysis－－边界值分析       
该分析一般与等价类一起使用。经验认为软件的错误经常在输入的边界上产生，因此边界值分析就是分析软件输入边界的一种方法。

branch－－分支       
在组件中，控制从任何语句到其它任何非直接后续语句的一个条件转换，或者是一个无条件转换。

branch condition－－分支条件       

branch condition combination coverage－－分支条件组合覆盖       
在每个判定中所有分支条件结果组合被测试用例覆盖到的百分比。

branch condition combination testing－－分支条件组合测试       
通过执行分支条件结果组合来设计测试用例的一种方法。

branch condition coverage－－分支条件覆盖       
每个判定中分支条件结果被测试用例覆盖到的百分比。

branch condition testing－－分支条件测试
通过执行分支条件结果来设计测试用例的一种方法。

branch coverage－－分支覆盖       
通过测试执行到的分支的百分比。

branch outcome－－分支结果       
见判定结果（decision outcome）

branch point－－分支点       
见判定（decision）

branch testing－－分支测试       
通过执行分支结果来设计测试用例的一种方法。

Breadth Testing－－广度测试       
在测试中测试一个产品的所有功能，但是不测试更细节的特性。

bug－－缺陷

第121贴【2004－10－14】：常见测试术语三

capture/playback tool－－捕获/回放工具       
参考capture/replay tool

Capture/Replay Tool－－捕获/回放工具       
一种测试工具，能够捕获在测试过程中传递给软件的输入，并且能够在以后的时间中，重复这个执行的过程。这类工具一般在GUI测试中用的较多。

CASE－－计算机辅助软件工程（computer aided software engineering）
用于支持软件开发的一个自动化系统。

CAST－－计算机辅助测试       
在测试过程中使用计算机软件工具进行辅助的测试。

cause-effect graph－－因果图       
一个图形，用来表示输入（原因）与结果之间的关系，可以被用来设计测试用例。

certification        －－证明       
一个过程，用于确定一个系统或组件与特定的需求相一致。

change control－－变更控制       
一个用于计算机系统或系统数据修改的过程，该过程是质量保证程序的一个关键子集，需要被明确的描述。

code audit        －－代码审计       
由一个人、组或工具对源代码进行的一个独立的评审，以验证其与设计规格、程序标准的一致性。正确性和有效性也会被评价。

Code Coverage－－代码覆盖率       
一种分析方法，用于确定在一个测试套执行后，软件的哪些部分被执行到了，哪些部分没有被执行到。

Code Inspection－－代码检视       
一个正式的同行评审手段，在该评审中，作者的同行根据检查表对程序的逻辑进行提问，并检查其与编码规范的一致性。

Code Walkthrough－－代码走读       
一个非正式的同行评审手段，在该评审中，代码被使用一些简单的测试用例进行人工执行，程序变量的状态被手工分析，以分析程序的逻辑和假设。

code-based testing－－基于代码的测试       
根据从实现中引出的目标设计测试用例。

coding standards－－编程规范       
一些编程方面需要遵循的标准，包括命名方式、排版格式等内容。

Compatibility Testing－－兼容性测试       
测试软件是否和系统的其它与之交互的元素之间兼容，如：浏览器、操作系统、硬件等。

complete path testing        －－完全路径测试       
参考穷尽测试（exhaustive testing）

completeness－－完整性       
实体的所有必须部分必须被包含的属性。

complexity        －－复杂性       
系统或组件难于理解或验证的程度。

Component－－组件       
一个最小的软件单元，有着独立的规格

Component Testing－－组件测试       
参考单元测试

computation data use－－计算数据使用       
一个不在条件中的数据使用。

computer system security－－计算机系统安全性       
计算机软件和硬件对偶然的或故意的访问、使用、修改或破坏的一种保护机制。

condition－－条件       
一个不包含布尔操作的布尔表达式，例如：A
condition coverage－－条件覆盖       
通过测试执行到的条件的百分比。

condition outcome－－条件结果       
条件为真为假的评价。

configuration control－－配置控制       
配置管理的一个方面，包括评价、协调、批准、和实现配置项的变更。

configuration management－－配置管理       
一套技术和管理方面的原则用于确定和文档化一个配置项的功能和物理属性、控制对这些属性的变更、记录和报告变更处理和实现的状态、以及验证与指定需求的一致性。

conformance criterion－－ 一致性标准       
判断组件在一个特定输入值上的行为是否符合规格的一种方法。

Conformance Testing－－ 一致性测试       
测试一个系统的实现是否和其基于的规格相一致的测试。

consistency        －－ 一致性       
在系统或组件的各组成部分和文档之间没有矛盾，一致的程度。

consistency checker－－ 一致性检查器       
一个软件工具，用于测试设计规格中需求的一致性和完整性。

control flow－－控制流       
程序执行中所有可能的事件顺序的一个抽象表示。

control flow graph－－控制流图       
通过一个组件的可能替换控制流路径的一个图形表示。

conversion testing－－转换测试       
用于测试已有系统的数据是否能够转换到替代系统上的一种测试。

corrective maintenance－－故障检修       
用于纠正硬件或软件中故障的维护。

correctness        －－正确性       
软件遵从其规格的程度。

correctness        －－正确性       
软件在其规格、设计和编码中没有故障的程度。软件、文档和其它项满足需求的程度。软件、文档和其它项满足用户明显的和隐含的需求的程度。

coverage        －－覆盖率       
用于确定测试所执行到的覆盖项的百分比。

coverage item－－覆盖项       
作为测试基础的一个入口或属性：如语句、分支、条件等。

crash－－崩溃       
计算机系统或组件突然并完全的丧失功能。

criticality－－关键性       
需求、模块、错误、故障、失效或其它项对一个系统的操作或开发影响的程度。

criticality analysis－－关键性分析       
需求的一种分析，它根据需求的风险情况给每个需求项分配一个关键级别。

cyclomatic complexity－－循环复杂度       
一个程序中独立路径的数量。
data corruption－－数据污染       
违背数据一致性的情况。

data definition－－数据定义       
一个可执行语句，在该语句上一个变量被赋予了一个值。

data definition C-use coverage－－数据定义C-use覆盖       
在组件中被测试执行到的数据定义C-use使用对的百分比。

data definition C-use pair－－数据定义C-use使用对       
一个数据定义和一个计算数据使用，数据使用的值是数据定义的值。

data definition P-use coverage－－数据定义P-use覆盖       
在组件中被测试执行到的数据定义P-use使用对的百分比。

data definition P-use pair－－数据定义P-use使用对       
一个数据定义和一个条件数据使用，数据使用的值是数据定义的值。

data definition-use coverage－－数据定义使用覆盖       
在组件中被测试执行到的数据定义使用对的百分比。

data definition-use pair        －－数据定义使用对       
一个数据定义和一个数据使用，数据使用的值是数据定义的值。

data definition-use testing－－数据定义使用测试       
以执行数据定义使用对为目标进行测试用例设计的一种技术。

data dictionary－－数据字典       
（1）一个软件系统中使用的所有数据项名称，以及这些项相关属性的集合。（2）数据流、数据元素、文件、数据基础、和相关处理的一个集合。

data flow analysis－－数据流分析       
一个软件验证和确认过程，用于保证输入和输出数据和它们的格式是被适当定义的，并且数据流是正确的。

data flow coverage－－数据流覆盖       
测试覆盖率的度量是根据变量在代码中的使用情况。

data flow diagram－－数据流图       
把数据源、数据接受、数据存储和数据处理作为节点描述的一个图形，数据之间的逻辑体现为节点之间的边。

data flow testing－－数据流测试       
根据代码中变量的使用情况进行的测试。

data integrity－－数据完整性       
一个数据集合完全、正确和一致的程度。

data use－－数据使用       
一个可执行的语句，在该语句中，变量的值被访问。

data validation－－数据确认       
用于确认数据不正确、不完整和不合理的过程。

dead code－－死代码       
在程序操作过程中永远不可能被执行到的代码。

Debugging－－调试       
发现和去除软件失效根源的过程。

decision－－判定       
一个程序控制点，在该控制点上，控制流有两个或多个可替换路由。

Decision condition－－判定条件       
判定内的一个条件。

decision coverage－－判定覆盖       
在组件中被测试执行到的判定结果的百分比。

decision outcome－－判定结果       
一个判定的结果，决定控制流走哪条路径。

decision table－－判定表       
一个表格，用于显示条件和条件导致动作的集合。

Depth Testing－－深度测试       
执行一个产品的一个特性的所有细节，但不测试所有特性。比较广度测试。

design of experiments－－实验设计       
一种计划实验的方法，这样适合分析的数据可以被收集。

design-based testing－－基于设计的测试       
根据软件的构架或详细设计引出测试用例的一种方法。

desk checking－－桌面检查       
通过手工模拟软件执行的方式进行测试的一种方式。

diagnostic－－诊断       
检测和隔离故障或失效的过程。

dirty testing－－肮脏测试       
参考负面测试（negative testing）

disaster recovery－－灾难恢复       
一个灾难的恢复和重建过程或能力。

documentation testing        －－文档测试       
测试关注于文档的正确性。

domain－－域       
值被选择的一个集合。

domain testing－－域测试       
参考等价划分测试（equivalence partition testing）

dynamic analysis－－动态分析       
根据执行的行为评价一个系统或组件的过程。

Dynamic Testing－－动态测试       
通过执行软件的手段来测试软件。
embedded software－－嵌入式软件       
软件运行在特定硬件设备中，不能独立于硬件存在。这类系统一般要求实时性较高。

emulator－－仿真       
一个模仿另一个系统的系统或设备，它接受相同的输入并产生相同的输出。

End-to-End testing－－端到端测试       
在一个模拟现实使用的场景下测试一个完整的应用环境，例如和数据库交互，使用网络通信等。

entity relationship diagram－－实体关系图       
描述现实世界中实体及它们关系的图形。

entry point        －－入口点       
一个组件的第一个可执行语句。

Equivalence Class－－等价类       
组件输入或输出域的一个部分，在该部分中，组件的行为从组件的规格上来看认为是相同的。

equivalence partition coverage－－等价划分覆盖       
在组件中被测试执行到的等价类的百分比。

equivalence partition testing－－等价划分测试       
根据等价类设计测试用例的一种技术。

Equivalence Partitioning－－等价划分       
组件的一个测试用例设计技术，该技术从组件的等价类中选取典型的点进行测试。

error－－错误       
IEEE的定义是：一个人为产生不正确结果的行为。

error guessing－－错误猜测       
根据测试人员以往的经验猜测可能出现问题的地方来进行用例设计的一种技术。

error seeding－－错误播种/错误插值       
故意插入一些已知故障（fault）到一个系统中去的过程，目的是为了根据错误检测和跟踪的效率并估计系统中遗留缺陷的数量。

exception－－异常/例外       
一个引起正常程序执行挂起的事件。

executable statement－－可执行语句       
一个语句在被编译后会转换成目标代码，当程序运行是会被执行，并且可能对程序数据产生动作。

Exhaustive Testing－－穷尽测试       
测试覆盖软件的所有输入和条件组合。

exit point－－出口点       
一个组件的最后一个可执行语句。

expected outcome－－期望结果       
参考预期结果（predicted outcome）。
failure－－失效       
软件的行为与其期望的服务相背离。

fault－－故障       
在软件中一个错误的表现。

feasible path－－可达路径       
可以通过一组输入值和条件执行到的一条路径。

feature testing－－特性测试       
参考功能测试（Functional Testing）

FMEA－－失效模型效果分析（Failure Modes and Effects Analysis）
可靠性分析中的一种方法，用于在基本组件级别上确认对系统性能有重大影响的失效。

FMECA－－失效模型效果关键性分析(Failure Modes and Effects Criticality Analysis)
FMEA的一个扩展，它分析了失效结果的严重性。

FTA－－故障树分析(Fault Tree Analysis)
引起一个不需要事件产生的条件和因素的确认和分析，通常是严重影响系统性能、经济性、安全性或其它需要特性。

functional decomposition－－功能分解       
参考模块分解（modular decomposition）

Functional Specification        －－功能规格说明书       
一个详细描述产品特性的文档。

Functional Testing－－功能测试       
测试一个产品的特性和可操作行为以确定它们满足规格。
glass box testing－－玻璃盒测试       
参考白盒测试（White Box Testing）

IEEE－－美国电子与电器工程师学会（Institute of Electrical and Electronic Engineers）

incremental testing－－渐增测试       
集成测试的一种，组件逐渐被增加到系统中直到整个系统被集成。

infeasible path－－不可达路径       
不能够通过任何可能的输入值集合执行到的路径。

input domain－－输入域       
所有可能输入的集合。

inspection－－检视       
对文档进行的一种评审形式。

installability testing－－可安装性测试       
确定系统的安装程序是否正确的测试。

instrumentation－－插装       
在程序中插入额外的代码以获得程序在执行时行为的信息。

instrumenter－－插装器       
执行插装的工具

Integration Testing－－集成测试       
测试一个应用组合后的部分以确保它们的功能在组合之后正确。该测试一般在单元测试之后进行。

interface－－接口       
两个功能单元的共享边界。

interface analysis－－接口分析       
分析软件与硬件、用户和其它软件之间接口的需求规格。

interface testing－－接口测试       
测试系统组件间接口的一种测试。

invalid inputs－－无效输入       
在程序功能输入域之外的测试数据。

isolation testing－－孤立测试       
组件测试（单元测试）策略中的一种，把被测组件从其上下文组件之中孤立出来，通过设计驱动和桩进行测试的一种方法。

Job－－工作       
一个用户定义的要计算机完成的工作单元。

job control language－－工作控制语言       
用于确定工作顺序，描述它们对操作系统要求并控制它们执行的语言。

LCSAJ－－线性代码顺序和跳转（Linear Code Sequence And Jump）
包含三个部分：可执行语句线性顺序的起始，线性顺序的结束，在线性顺序结束处控制流跳转的目标语句。

LCSAJ coverage－－LCSAJ覆盖       
在组件中被测试执行到的LCSAJ的百分比。

LCSAJ testing－－LCSAJ测试       
根据LCSAJ设计测试用例的一种技术。

Load Testing－－负载测试       
通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。

logic analysis－－逻辑分析       
（1）评价软件设计的关键安全方程式、算法和控制逻辑的方法。（2）评价程序操作的顺序并且检测可能导致灾难的错误。

logic-coverage testing－－逻辑覆盖测试       
参考结构化测试用例设计（structural test case design）

maintainability－－可维护性       
一个软件系统或组件可以被修改的容易程度，这个修改一般是因为缺陷纠正、性能改进或特性增加引起的。

maintainability testing－－可维护性测试       
测试系统是否满足可维护性目标。

modified condition/decision coverage－－修改条件/判定覆盖       
在组件中被测试执行到的修改条件/判定的百分比。

modified condition/decision testing        －－修改条件/判定测试       
根据MC/DC设计测试用例的一种技术。

Monkey Testing－－跳跃式测试       
随机性，跳跃式的测试一个系统，以确定一个系统是否会崩溃。

MTBF－－平均失效间隔实际（mean time between failures）
两次失效之间的平均操作时间。

MTTF－－平均失效时间        （mean time to failure）
第一次失效之前的平均时间

MTTR－－平均修复时间（mean time to repair）
两次修复之间的平均时间

multiple condition coverage－－多条件覆盖       
参考分支条件组合覆盖（branch condition combination coverage）

mutation analysis－－变体分析       
一种确定测试用例套完整性的方法，该方法通过判断测试用例套能够区别程序与其变体之间的程度。
Negative Testing－－逆向测试/反向测试/负面测试       
测试瞄准于使系统不能工作。

non-functional requirements testing－－非功能性需求测试       
与功能不相关的需求测试，如：性能测试、可用性测试等。

N-switch coverage－－N切换覆盖       
在组件中被测试执行到的N转换顺序的百分比。

N-switch testing－－N切换测试       
根据N转换顺序设计测试用例的一种技术，经常用于状态转换测试中。

N-transitions－－N转换       
N＋1转换顺序

operational testing－－可操作性测试       
在系统或组件操作的环境中评价它们的表现。

output domain－－输出域       
所有可能输出的集合。
partition testing－－分类测试       
参考等价划分测试（equivalence partition testing）

path－－路径       
一个组件从入口到出口的一条可执行语句顺序。

path coverage－－路径覆盖       
在组件中被测试执行到的路径的百分比。

path sensitizing－－路径敏感性       
选择一组输入值强制组件走一个给定的路径。

path testing－－路径测试       
根据路径设计测试用例的一种技术，经常用于状态转换测试中。

performance testing－－性能测试       
评价一个产品或组件与性能需求是否符合的测试。

portability testing－－可移植性       
测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。

Positive Testing－－正向测试       
测试瞄准于显示系统能够正常工作。

precondition－－预置条件       
环境或状态条件，组件执行之前必须被填充一个特定的输入值。

predicate－－谓词       
一个逻辑表达式，结果为‘真’或‘假’。

predicate data use－－谓词数据使用       
在谓词中的一个数据使用。

program instrumenter－－程序插装       
参考插装（instrumenter）

progressive testing－－递进测试       
在先前特性回归测试之后对新特性进行测试的一种策略。

pseudo-random－－伪随机       
看似随机的，实际上是根据预先安排的顺序进行的。
QA－－质量保证（quality assurance）
（1）已计划的系统性活动，用于保证一个组件、模块或系统遵从已确立的需求。（2）采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。

QC－－质量控制（quality control）
用于获得质量需求的操作技术和过程，如测试活动。

Race Condition－－竞争状态       
并行问题的根源。对一个共享资源的多个访问，至少包含了一个写操作，但是没有一个机制来协调同时发生的访问。

recovery testing－－恢复性测试       
验证系统从失效中恢复能力的测试。

regression analysis and testing－－回归分析和测试       
一个软件验证和确认任务以确定在修改后需要重复测试和分析的范围。

Regression Testing－－回归测试       
在发生修改之后重新测试先前的测试以保证修改的正确性。

release－－发布       
一个批准版本的正式通知和分发。

reliability－－可靠性       
一个系统或组件在规定的条件下在指定的时间内执行其需要功能的能力。

reliability assessment－－可靠性评价       
确定一个已有系统或组件的可靠性级别的过程。

requirements-based testing－－基于需求的测试       
根据软件组件的需求导出测试用例的一种设计方法。

review－－评审       
在产品开发过程中，把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。

risk－－风险       
不期望效果的可能性和严重性的一个度量。

risk assessment－－风险评估       
对风险和风险影响的一个完整的评价。
safety－－（生命）安全性       
不会引起人员伤亡、产生疾病、毁坏或损失设备和财产、或者破坏环境。

safety critical－－严格的安全性       
一个条件、事件、操作、过程或项，它的认识、控制或执行对生命安全性的系统来说是非常关键的。

Sanity Testing－－理智测试       
软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考冒烟测试

SDP－－软件开发计划（software development plan）
用于一个软件产品开发的项目计划。

security testing－－安全性测试       
验证系统是否符合安全性目标的一种测试。

security.－－（信息）安全性       
参考计算机系统安全性（computer system security）

serviceability testing－－可服务性测试       
参考可维护性测试（maintainability testing）

simple subpath－－简单子路径       
控制流的一个子路径，其中没有不必要的部分被执行。

simulation－－模拟       
使用另一个系统来表示一个物理的或抽象的系统的选定行为特性。

simulation－－模拟       
使用一个可执行模型来表示一个对象的行为。

simulator－－模拟器       
软件验证期间的一个设备、软件程序、或系统，当它给定一个控制的输入时，表现的与一个给定的系统类似。

SLA－－服务级别协议（service level agreement）
服务提供商与客户之间的一个协议，用于规定服务提供商应当提供什么服务。

Smoke Testing－－冒烟测试       
对软件主要功能进行快餐式测试。最早来自于硬件测试实践，以确定新的硬件在第一次使用的时候不会着火。

software development process－－软件开发过程       
一个把用户需求转换为软件产品的开发过程。

software diversity－－软件多样性       
一种软件开发技术，其中，由不同的程序员或开发组开发的相同规格的不同程序，目的是为了检测错误、增加可靠性。

software element－－软件元素       
软件开发或维护期间产生或获得的一个可交付的或过程内的文档。

software engineering－－软件工程       
一个应用于软件开发、操作和维护的系统性的、有纪律的、可量化的方法。

software engineering environment－－软件工程环境       
执行一个软件工程工作的硬件、软件和固件。

software life cycle－－软件生命周期       
开始于一个软件产品的构思，结束于该产品不再被使用的这段期间。

SOP－－标准操作过程（standard operating procedures）
书面的步骤，这对保证生产和处理的控制是必须的。

source code－－源代码       
用一种适合于输入到汇编器、编译器或其它转换设备的计算机指令和数据定义。

source statement－－源语句       
参考语句（statement）
specification－－规格       
组件功能的一个描述，格式是：对指定的输入在指定的条件下的输出。

specified input－－指定的输入       
一个输入，根据规格能预知其输出。

spiral model        －－螺旋模型       
软件开发过程的一个模型，其中的组成活动，典型的包括需求分析，概要设计，详细设计，编码，集成和测试等活动被迭代的执行直到软件被完成。

SQL－－结构化查询语句（structured query language）
在一个关系数据库中查询和处理数据的一种语言。

state－－状态       
一个系统、组件或模拟可能存在其中的一个条件或模式。

state diagram－－状态图       
一个图形，描绘一个系统或组件可能假设的状态，并且显示引起或导致一个状态切换到另一个状态的事件或环境。

state transition－－状态转换       
一个系统或组件的两个允许状态之间的切换。

state transition testing        －－状态转换测试       
根据状态转换来设计测试用例的一种方法。

statement－－语句       
程序语言的一个实体，是典型的最小可执行单元。

statement coverage－－语句覆盖       
在一个组件中，通过执行一定的测试用例所能达到的语句覆盖百分比。

statement testing－－语句测试       
根据语句覆盖来设计测试用例的一种方法。

Static Analysis－－静态分析       
分析一个程序的执行，但是并不实际执行这个程序。

Static Analyzer－－静态分析器       
进行静态分析的工具。

Static Testing－－静态测试       
不通过执行来测试一个系统。

statistical testing－－统计测试       
通过使用对输入统计分布进行分析来构造测试用例的一种测试设计方法。

stepwise refinement－－逐步优化       
一个结构化软件设计技术，数据和处理步骤首先被广泛的定义，然后被逐步的进行了细化。

storage testing－－存储测试       
验证系统是否满足指定存储目标的测试。

Stress Testing－－压力测试       
在规定的规格条件或者超过规定的规格条件下，测试一个系统，以评价其行为。类似负载测试，通常是性能测试的一部分。

structural coverage－－结构化覆盖       
根据组件内部的结构度量覆盖率。

structural test case design－－结构化测试用例设计       
根据组件内部结构的分析来设计测试用例的一种方法。

structural testing－－结构化测试       
参考结构化测试用例设计（structural test case design）

structured basis testing－－结构化的基础测试       
根据代码逻辑设计测试用例来获得100％分支覆盖的一种测试用例设计技术。

structured design－－结构化设计       
软件设计的任何遵循一定纪律的方法，它按照特定的规则，例如：模块化，有顶向下设计，数据逐步优化，系统结构和处理步骤。

structured programming－－结构化编程       
在结构化程序开发中的任何包含结构化设计和结果的软件开发技术。

structured walkthrough－－结构化走读       
参考走读（walkthrough）

stub－－桩       
一个软件模块的框架或特殊目标实现，主要用于开发和测试一个组件，该组件调用或依赖这个模块。

symbolic evaluation－－符号评价       
参考符号执行（symbolic execution）

symbolic execution－－符号执行       
通过符号表达式来执行程序路径的一种静态分析设计技术。其中，程序的执行被用符号来模拟，例如，使用变量名而不是实际值，程序的输出被表示成包含这些符号的逻辑或数学表达式。

symbolic trace－－符号轨迹       
一个计算机程序通过符号执行是经过的语句分支结果的一个记录。

syntax testing－－语法分析       
根据输入语法来验证一个系统或组件的测试用例设计技术。

system analysis－－系统分析       
对一个计划的或现实的系统进行的一个系统性调查以确定系统的功能以及系统与其它系统之间的交互。

system design－－系统设计       
一个定义硬件和软件构架、组件、模块、接口和数据的过程以满足指定的规格。

system integration－－系统集成       
一个系统组件的渐增的连接和测试，直到一个完整的系统。

System Testing－－系统测试       
从一个系统的整体而不是个体上来测试一个系统，并且该测试关注的是规格，而不是系统内部的逻辑。

technical requirements testing－－技术需求测试       
参考非功能需求测试（non-functional requirements testing）

test automation－－测试自动化       
使用工具来控制测试的执行、结果的比较、测试预置条件的设置、和其它测试控制和报告功能。

test case－－测试用例       
用于特定目标而开发的一组输入、预置条件和预期结果。

test case design technique－－测试用例设计技术       
选择和导出测试用例的技术。

test case suite－－测试用例套       
对被测软件的一个或多个测试用例的集合。

test comparator－－测试比较器       
一个测试工具用于比较软件实际测试产生的结果与测试用例预期的结果。

test completion criterion－－测试完成标准       
一个标准用于确定被计划的测试何时完成。

test coverage－－测试覆盖       
参考覆盖率（Coverage）

test driver－－测试驱动       
一个程序或测试工具用于根据测试套执行软件。

test environment－－测试环境       
测试运行其上的软件和硬件环境的描述，以及任何其它与被测软件交互的软件，包括驱动和桩。

test execution－－测试执行       
一个测试用例被被测软件执行，并得到一个结果。

test execution technique－－测试执行技术       
执行测试用例的技术，包括手工、自动化等。

test generator－－测试生成器       
根据特定的测试用例产生测试用例的工具。

test harness－－测试用具       
包含测试驱动和测试比较器的测试工具。

test log－－测试日志       
一个关于测试执行所有相关细节的时间记录。

test measurement technique－－测试度量技术       
度量测试覆盖率的技术。

Test Plan－－测试计划       
一个文档，描述了要进行的测试活动的范围、方法、资源和进度。它确定测试项、被测特性、测试任务、谁执行任务，并且任何风险都要冲突计划。

test procedure－－测试规程       
一个文档，提供详细的测试用例执行指令。

test records－－测试记录       
对每个测试，明确的记录被测组件的标识、版本，测试规格，和实际结果

test report－－测试报告       
一个描述系统或组件执行的测试和结果的文档。

Test scrīpt－－测试脚本       
一般指的是一个特定测试的一系列指令，这些指令可以被自动化测试工具执行。

Test Specification－－测试规格       
一个文档，用于指定一个软件特性、特性组合或所有特性的测试方法、输入、预期结果和执行条件。

test strategy－－测试策略       
一个简单的高层文档，用于描述测试的大致方法，目标和方向。

test suite－－测试套       
测试用例和/或测试脚本的一个集合，与一个应用的特定功能或特性相关。

test target－－测试目标       
一组测试完成标准。

testability－－可测试性       
一个系统或组件有利于测试标准建立和确定这些标准是否被满足的测试执行的程度。

Testing－－测试       
IEEE给出的定义是：1）一个执行软件的过程，以验证其满足指定的需求并检测错误。2）一个软件项的分析过程以检测已有条件之间的不同，并评价软件项的特性。

thread testing－－线程测试       
自顶向下测试的一个变化版本，其中，递增的组件集成遵循需求子集的实现。

time sharing－－时间共享       
一种操作方式，允许两个或多个用户在相同的计算机系统上同时执行计算机程序。其实现可能通过时间片轮转、优先级中断等。

top-down design－－由顶向下设计       
一种设计策略，首先设计最高层的抽象和处理，然后逐步向更低级别进行设计。

top-down testing－－自顶向下测试       
集成测试的一种策略，首先测试最顶层的组件，其它组件使用桩，然后逐步加入较低层的组件进行测试，直到所有组件被集成到系统中。

traceability－－可跟踪性       
开发过程的两个或多个产品之间关系可以被建立起来的程度，尤其是产品彼此之间有一个前后处理关系。

traceability analysis－－跟踪性分析       
（1）跟踪概念文档中的软件需求到系统需求；（2）跟踪软件设计描述到软件需求规格，以及软件需求规格到软件设计描述；（3）跟踪源代码对应到设计规格，以及设计规格对应到源代码。分析确定它们之间正确性、一致性、完整性、精确性的关系。

traceability matrix－－跟踪矩阵       
一个用于记录两个或多个产品之间关系的矩阵。例如，需求跟踪矩阵是跟踪从需求到设计再到编码的实现。

transaction－－事务/处理       
（1）一个命令、消息或输入记录，它明确或隐含的调用了一个处理活动，例如更新一个文件。（2）用户和系统之间的一次交互。（3）在一个数据库管理系统中，完成一个特定目的的处理单元，如恢复、更新、修改或删除一个或多个数据元素。

transform analysis－－事务分析       
系统的结构是根据分析系统需要处理的事务获得的一种分析技术。
trojan horse－－特洛伊木马       
一种攻击计算机系统的方法，典型的方法是提供一个包含具有攻击性隐含代码的有用程序给用户，在用户执行该程序的时候，其隐含的代码对系统进行非法访问，并可能产生破坏。

truth table－－真值表       
用于逻辑操作的一个操作表格。

Unit Testing－－单元测试       
测试单个的软件组件，属于白盒测试范畴，其测试基础是软件内部的逻辑。

Usability Testing－－可用性测试       
测试用户使用和学习产品的容易程度。

validation－－确认       
根据用户需要确认软件开发的产品的正确性。

verification－－验证       
评价一个组件或系统以确认给定开发阶段的产品是否满足该阶段开始时设定的标准。

version－－版本       
一个软件项或软件元素的一个初始发布或一个完整的再发布。

volume testing－－容量测试       
使用大容量数据测试系统的一种策略。

Walkthrough－－走读       
一个针对需求、设计或代码的非正式的同行评审，一般由作者发起，由作者的同行参与进行的评审过程。

waterfall model－－瀑布模型       
软件开发过程模型的一种，包括概念阶段、需求阶段、设计阶段、实现阶段、测试阶段、安装和检查阶段、操作和维护阶段，这些阶段按次序进行，可能有部分重叠，但很少会迭代。

White Box Testing－－白盒测试       
根据软件内部的工作原理分析来进行测试。

国内近年来关于软件测试的问题和讨论越来越活跃。但从总体上说交流软件测试技术的多，而探讨软件测试方法的少。这里的“技术”指的是具体的战术问题，比如说如何使用某种工具来解决某一特定测试问题，或者某一类型软件有哪些测试手段等等。而这里的“方法”指的是宏观的战略问题，或者叫方法论，这包括从软件测试的概念或理念，到企业软件质量控制体系；从软件测试的过程，到测试团队的设置及其职责的界定等等。

    作为测试人员，热衷于“技术”讨论和交流是一件可喜可贺的事。从中可以感觉到软件测试在中国迅速发展的开端和潜力。但是作为企业的管理决策者，是否也应该以同样的热情来思考“方法”问题呢？特别是当一个软件企业的软件测试从无到有，或者当企业已有一定的软件测试的投入，但发现其实效并不显著，甚至由于测试的引入而带来了新的管理上的混乱。这个时候方法论的思考，更有利于发现问题的根源。即便是一个基层的测试人员，当积累了一定的技术经验后，也应该不时从日常的具体工作中走出来，在一个较高层次上进行回顾总结和借鉴，并试着提出一些优化和改进的措施，这无论对专业上还是对事业上的成长都是非常有意义的。

    微软在软件测试方面有很多值得一提的经验，在此我想以我个人的体会和思考，同大家一同进行一些探讨。这里有一点须要特别说明，尽管微软的方法已被微软的实践多次证明是成功的，非常有效的，但这并不意味着这些方法在中国的软件企业中有广泛的可行性。一种方法是否可行还受到很多其他因素的影响，比如企业类型（微软是生产平台软件和通用软件产品的企业），企业管理体制，企业文化等等。所以我的目的只是给大家一些思路和借鉴。

    两类经典的软件测试方法 在具体介绍微软的软件测试方法之前，我想首先从概念，或理念的层面上来理解究竟甚么是软件测试，目的是从中导出微软测试方法的理论根源。传统上认为软件测试的方法从总体上分为两类。第一类测试方法是试图验证软件是“工作的”，所谓“工作的”就是指软件的功能是按照预先的设计执行的；而第二类测试方法则是设法证明软件是“不工作的”。提出第一类方法的代表人物是软件测试领域的先驱Dr. Bill Hetzel（代表论著《The Complete Guide to Software Testing》），他曾于1972年6月在美国的北卡罗来纳大学组织了历史上第一次正式的关于软件测试的论坛。他首先在1973年给软件测试一个这样的定义：“就是建立一种信心，认为程序能够按预期的设想运行。Establish confidence that a program does what it is supposed to do. ”后来在1983年他又将定义修订为：“评价一个程序和系统的特性或能力，并确定它是否达到预期的结果。软件测试就是以此为目的的任何行为。 Any activities aimed at evaluating an attribute or capability of a program or system. ”在他的定义中的“设想”和“预期的结果”其实就是我们现在所说的用户需求或功能设计。他还把软件的质量定义为“符合要求”。

    第一类测试可以简单抽象地描述为这样的过程：在设计规定的环境下运行软件的功能，将其结果与用户需求或设计结果相比较，如果相符则测试通过，如果不相符则视为Bug。这一过程的终极目标是将软件的所有功能在所有设计规定的环境全部运行，并通过。在软件行业中一般把第一类方法奉为主流和行业标准。1990年的IEEE/ANSI标准将软件测试进行了这样的定义：“就是在既定的状况条件下，运行一个系统或组建，观察记录结果，并对其某些方面进行评价的过程。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 (IEEE/ANSI, 1990 [Std 610.12-1990]”这里所谓“既定的状况”也可理解为需求或设计。

    尽管如此，这一方法还是受到很多业界权威的质疑和挑战。代表人物是Glenford J. Myers（代表论著《The Art of Software Testing》）。他认为测试不应该着眼于验证软件是工作的，相反应该首先认定软件是有错误的，然后去发现尽可能多的错误。他还从人的心理学的角度论证，将 “验证软件是工作的”作为测试的目的，非常不利于测试人员发现软件的错误。于是他于1979年提出了他对软件测试的定义：“就是以发现错误为目的而运行程序的过程。The process of executing a program or system with the intent of finding errors.” 这就是软件测试的第二类方法，简单地说就是验证软件是“不工作的”，或者说是有错误的。他甚至极端地认为，一个成功的测试必须是发现Bug的测试，不然就没有价值。这就如同一个病人（假定此人确有病），到医院做一项医疗检查，结果各项指标都正常，那说明该项医疗检查对于诊断该病人的病情是没有价值的，是失败的。我并不完全同意这一看法。第二类软件测试方法在业界也很流行，受到很多学术界专家的支持。大家熟悉的Ron Patton在《软件测试》（ 中文版由机械工业出版社出版，具说此书是目前国内测试新手入门的经典教材）一书的第10页，有一个明确而简洁的定义：“软件测试员的目标是找到软件缺陷，尽可能早一些，并确保其得以修复。”有些软件企业以Bug数量来作为考核测试人员业绩的一项指标，其实就是接受了这样的方法。

    两类方法的优劣对比 虽然软件测试总的目的是为了软件产品的质量，但很明显这两类测试方法在具体目标、或指导思想上截然相反。由此也决定了它们在思路、过程和测重点上有很大的差别，并各有利弊的。第一类测试方法以需求和设计为本，因此有利于界定测试工作的范畴，更便于部署测试的侧重点，加强针对性。这一点对于大型软件的测试，尤其是在有限的时间和人力资源情况下显得格外重要。而第二类测试方法与需求和设计没有必然的关联，如果计划管理不当，测试活动很容易丢失重点，走入歧途。第一类测试方法可以与软件的架构和软件开发的计划相配合，使软件测试活动逐层次的展开，从而使软件的功能和质量有计划地逐步完善和提高（关于测试的层次问题，我会在今后的讨论中专门介绍）。第二类测试方法不具备这种过程的渐进性。第一类测试方法的缺点是缺乏灵活性，不利于测试人员主观能动性的发挥，正像Myers先生所说，不容易找到软件的错误（Bug）。而这方面正是第二类测试方法的长处。 微软的策略 正是因为认识到两类测试方法各有利弊，微软在软件测试活动中将两类方法结合起来，以第一类测试方法为基础和主要线索，阶段性地运用第二类测试方法。 微软的第一类测试 微软的第一类测试总体上说分为三个步骤进行：审核需求和设计—〉设计测试—〉实施运行测试。前文已述，第一类测试是以需求和设计为本来验证软件的正确性。大家很自然的想到，需求和设计本身也有正确性的问题。依据不正确的需求和设计不可能开发出正确的软件产品，测试也将是徒劳的。因此验证需求和设计是微软进行第一类测试的第一步。有必要指出的是，这里所说的需求和设计具体说来它一般包括：（1）由项目经理根据用户要求（信息来源于市场部门，用户支持部门等等）而编写的需求文本（Requirement Specification）；（2）由项目经理根据需求文本而编写的功能设计文本（Functional Design Specification）；（3）由开发人员根据功能文本而编写的实施设计文本（Implementation Design Specification）。微软的测试人员要参与所有这些文本的审核。作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性。同时这种审核对于测试人员也是一种热身活动，使他们尽早地进入技术和业务状态。第二步，测试人员要根据已审核通过的需求和设计编制测试计划，设计测试用例。在前面提到的三种文本中，功能设计文本是主要依据。原因很简单，这类测试关心的是软件是否能正确地实现功能，而不是这些功能如何被具体实施的。从这里大家可以看出这是典型的“黑盒测试”。确实微软的测试主要是从用户角度进行的黑盒测试。这一步的完成就意味着“测试计划”和“测试用例设计”两个文本的完成。“测试计划” 文本主要阐述测试的范畴、领域、方法、工具、资源和计划时间表等等。“测试用例设计”文本要列出测试用例、每个用例的设置、执行步骤和预期结果。测试的这两个文本也要被项目经理和开发人员审核。这样经过各种相互的审核，大家对项目形成了基本的共识。第三步的实施运行测试是整个开发过程中最长最复杂的一个阶段。从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。这包括编写自动化测试程序、反复运行自动化测试程序，也包括阶段性执行手动测试用例。这一阶段的测试必须在周密的计划下进行，在前面我已提到，这正是第一类测试的特点和长处。这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。从测试的过程来看，总是先运行或执行简单用例，然后再复杂用例；先验证单一的基本功能，再综合的端到端的功能；先发现解决表面的，影响面大的Bug，再深层的，不容易重现的Bug。因此随着项目开发和测试的进程，产品的功能不断完善，质量不断提高。这里有一点要特别指出，有很多测试用例是要反复运行的，特别是基本的自动化测试每一天，每一个Build上都要运行。尽管这些测试大多数情况下都是通过的，很少再发现新的Bug，但其价值是显而易见的，就是为了防止质量回归。可见Myers的理论在这里是不适用的。这一阶段测试人员还有一项繁琐但却很重要的工作，就是对已有的测试用例的维护。比如通常以下两种情况下要新增一些测试用例，一是对于当初测试设计不周全的领域，二是对于外部的Bug（比如从Beta客户报告来的），没有被现有测试用例所覆盖。当产品的功能设计出现更改时（在微软这是常事），所涉及的测试用例当然也要相应地修改。 微软的第二类测试 微软的第二类测试是阶段性的，常常根据需要而带有随机性和突击性。对于这类测试，在微软有一个专门的名称：“Bug Bash（Bug大扫除）”。 Bug Bash通常发生在项目开发各阶段（微软叫里程碑）的末期，比如Beta版发布前，划出一个专门的时间段（通常1-3天），在这期间所有参与项目的人员，集中全部精力，运用各方面的知识，尽全部智慧来搜寻项目的Bug。这是一个非常有意思的活动，但要组织好这样的活动并非易事。一般有以下要点：（1）尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益；（2）要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug；（3）为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。（4）可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。微软的第二类测试除了Bug Bash外，经常还有一些专业性的测试，最典型的是针对安全性攻击测试。一般会邀请公司内部，或业界的专家来搜寻产品的安全漏洞。 以上我从传统软件测试概念的角度，介绍了微软的策略和两类传统测试方法的具体做法，及其侧重点。这其实仅仅是一个基础，一个很原始的基础。软件测试在微软软件产品开发中的作用、地位远不是这些原始的方法所能达到的，也不是传统软件测试概念所函盖的。微软在软件测试方面有很多特有的做法，和概念上的突破，比如“软件测试的信息服务功能”、“以用户为中心的宏观质量体系”、“分级测试”、“项目的质量管理系统”、“Bug三方会审”、“测试自动化”和“软件测试的软硬件—部门、团队、人和基础设施”等等。这些我会在以后的讨论中分专题进行介绍。

    测试何时结束? 在按计划结束的那一天结束！ 我这个答案你听了一定不满意。但这个答案告诉你微软所依据的最基本的原则，这就是计划。在我前面介绍微软的第一类测试时我提到“测试计划”，这个“测试计划”实际上就是要回答测试的投入问题，包括人力资源、时限和过程。确定测试计划有这么几个依据：1）产品的功能。功能的量和复杂性直接影响测试的工作量；2）质量标准，有公司的标准、行业的标准、市场反馈的标准和客户要求的标准等；3）以往的经验，有以往的产品的经验，也有个人的经验。这一“测试计划”还要被项目的各方（开发，项目管理）审核通过，从而在整个产品部门形成一种共识，这种共识最终被纳入项目总体计划的一部分。对于第二类测试，它也是总项目总体计划的一部分，而且量也是可知的。一般地说在每个里程碑都会有几个分专题的“Bug Bash”，每次历时1-3天。在微软的项目计划书中总有那么一天，叫做“测试完成日 Test Complete Day”。它标志着所有计划的测试活动已全部完成，所有被发现的Bug被全部解决，并被测试所验证（有一些会因为某些原因被研究决定推迟解决）。 对于以上的分析你也许仍然不满意：难道微软的计划总能按期完成吗？当然不是，逾期的情况时常会有。几乎可以肯定，项目的实际执行与预先的计划一定会有或多或少的差距。微软会在项目过程中采取一些方法来感知这种差距，比如bitter提到的代码“覆盖率”分析和bug数量的变化趋势分析等。目的是为了尽早地发现差距，重新评估和修订计划。这样计划可以变化，但测试总是在计划结束的那一天结束。 

    对于TL_geong提到的随机测试造成收敛的缺陷趋势出现严重的发散现象，在微软也有。通常Bug Bash会产生超乎寻常数量的Bug。一般我们认为，产生Bug的量越大越好。因为，如果产生Bug的数量少，你很难判断是因为产品的质量确实很高，还是Bug Bash做得不彻底。而且事实往往是后者。 那么对Bug Bash所产生的大量Bug该怎么办？在微软，我们有“Bug Triage （测试，开发和项目管理，三方会审）”的制度。对于每个Bug，经过会审后不外乎有以下三中归宿（总体上来说）： （1）被确认为“缺陷性”Bug，这样的Bug必须交开发人员解决，然后由原发现人验证。 （2）被调整为非“缺陷性”Bug，不用开发人员作任何更改，但必须将问题纳入产品用户文档，明确向用户解释，并告诉用户如何避免和应对。比如这里举一个假想的例子：产品的某个功能在系统内存严重不足的情况下，会暂时停止工作，并生成很多不易被用户理解的警告信息。这显然是个Bug（按微软的标准），正确的应该是，首先软件不应该完全停止工作，其次不应该多次警告，第三，警告信息应简明易懂，并给用户以措施和建议。但是考虑到，一方面这种情况在用户实际使用产品时发生的机率很低，而另一方面，从开发角度，解决这个问题有很大的技术难度，影响面也太大。这种情况下会把这个Bug改为“文本性”Bug，也就是要求文本遍写人员将这一情况作一技术性解释，并建议用户不要将此产品同其他消耗大量内存的软件同时使用。这类的Bug在Bug Bash中很常见，因为大家在这种测试活动中思维方式比较超常。 （3）被完全否定，立刻关闭，不再纠缠。这类的情况在Bug Bash中也很常见。因为参与Bug Bash人并不都很了解产品功能的准确用法，误报是难免的。尽管对这类问题没有直接的后续措施，但这些信息仍然是有一定价值的，因为将来用户中的新手很可能会犯同样的毛病，而产品支持部门如果预先有这样的经验，就能及时准确地提供帮助。所以这些信息要保存在Bug的管理库中，以备将来产品支持部门查询。 经过这样的会审，筛选，如果（1）（2）类Bug，特别是（1）类Bug仍然很多，那测试部门很可能需要重新论证原先的测试计划和测试用例设计，看是否需要增加测试用例。必要时还要尽早提出更改项目总体计划和发布日期。 大量Bug的出现也许不是件愉快的事，但和把这些Bug留给用户相比，代价要小得太多了。总之对于产品的Bug，要相对待身体的疾病一样，切末讳疾忌医。

    微软的软件测试方法（二） 我在前一篇“微软的软件测试方法”中介绍了微软的两类基本测试方法，其基本思想大家应该是比较熟悉的，因为它们还只是传统的软件测试方法的综合。所以单从形式上，它并没有体现出对传统框架的突破。但是从另一个层面来考察微软软件测试时，你会对一些基本的事实感到惊讶。比如，“微软的测试人员和开发人员数量大致相等或略多”，“微软的产品成本中测试大约占40%以上”等等。人们会有疑问，仅仅是作为功能验证和搜寻Bug的测试能消耗这么大量的资源吗？有必要付出如此大的代价吗？应该有理由相信，微软作为一个软件企业，其每一份投入都是有意义的，因此也可断定微软在软件测试方面的努力一定超出传统测试方法的范畴。

    历史回顾 为了更好的理解微软件测试在方法和理念上的突破，我想首先回顾一下软件开发和软件测试的发展历史，并从中揭示其必然性。Edward Kit 在他的畅销书“Software Testing In The Real World : Improving The Process（1995， ISBN: 0201877562）”中将整个软件开发历史分为三个阶段：

    第一个阶段是60年代及其以前，那时软件规模都很小、复杂程度低，软件开发的过程随意。开发人员的Debug过程被认为是唯一的测试活动。其实这并不是现代意义上的软件测试，当然一阶段也还没有专门测试人员的出现。

    第二个阶段是70年代，这个阶段开发的软件仍然不复杂，但人们已开始思考开发流程问题，并提出“软件工程Software Engineering”的概念。但是这一阶段人们对软件测试的理解仅限于基本的功能验证和Bug搜寻，而且测试活动仅出现在整个软件开发流程的后期，虽然测试由专门的测试人员来承担，但测试人员都是行业和软件专业的入门新手。

    第三个阶段是80年代及其以后，软件和IT行业进入了大发展。软件趋向大型化。与之相应，人们为软件开发设计了各种复杂而精密的流程和管理方法（比如CMM和MSF），并将“质量”的概念融入其中。软件测试已有了行业标准（IEEE/ANSI ），它再也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。软件测试已成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。 测试与开发的融合 在这一历史发展过程中，最值得注意的是测试与开发流程融合的趋势。人们对这种融合也许并不陌生。比如测试活动的早期展开，让测试人员参与用户需求的验证，参加功能设计和实施设计的审核。再比如测试人员与开发人员的密切合作，随着开发进展而逐步实施单元测试、模块功能测试和系统整合测试。的确这些都是测试与开发融合的表现形式，而且初期的融合也只反映在这个层次上。

    90年代以后，软件的规模和复杂程度迅速提高，这种形式上的融合也迅速走向更深层次，更具实际意义。具体地说这种融合就是整个软件开发活动对测试的依赖性。传统上认为，只有软件的质量控制依赖于测试，但是现代软件开发的实践证明，不仅软件的质量控制依赖于测试，开发本身离开测试也将无法推进，项目管理离开了测试也从根本上失去了依据。在微软，测试的确有这样的地位和作用。这就是为什么微软在软件测试上有如此大的投入。 开发对测试的依赖 现代软件开发，特别是大型软件开发通常会遇到以下两个问题： （1） 在开发初期，如何能够展开大规模团队，群体齐头并进，而同时保持开发的有序性。从而有效利用资源，缩短开发周期。（2） 在开发后期，如何解决深层次的Bug，如何面对设计更改，而能够保证产品的质量不出现或少出现回落。 对于小型简单的软件，这两个问题也存在，但不突出，而且容易解决。但对于复杂的大型软件的开发，这两个问题常常会成为难以逾越的障碍。 通常大型项目的功能丰富，但架构、层次也会相当复杂。稳妥的开发方式是，一次投入少量的人员，逐层开发，逐层稳定。但这种方式显然资源利用率低，开发周期长，不能满足现代软件和IT行业高速发展、瞬息万变的需要。因此大型项目需要大型团队。在微软，产品开发团队（主要包括开发、测试和项目管理）一般都有百人以上规模，有些产品甚至上几千人（Windows2000的开发部门曾有3000多人）。这样大规模的人力资源作用在一个动态的，内部相互联系的系统中，若没有有效的协同，其混乱是不可避免的。试想，有两个开发人员，分别在开发两个不同的功能模块，其相互有依赖关系。为了相互协调，他们可以随时进行当面讨论。如果这种关系发生在五个开发人员和五个功能模块之间，这种协调就只能通过定期的会议来进行。而一个大型项目，会有许许多多这样的关系，而且很多时候这种关系有着不确定性和不可预见性。当一个开发人员编写一段新的代码或对已有代码进行改动和调整时，他（或她）常常无法确定，或无法完全确定究竟有哪些相关的模块会受到影响，以及在什么请况下这种影响会带来什么结果。因为系统的复杂性已远远超出了人的逻辑思维、技能和经验所能力及的范畴。因此这种传统的协调手段是远不能满足需要的。

   在微软，这种协调是通过测试来实现的。具体来说就是：每日建造+自动化测试。关于每日编译和自动化测试，我将来会作专门介绍，这里简单的说就是每天都建造一个新版本，每个版本都要运行通过一定量的自动测试用例，以检验当天工作的质量。这里所说的质量当然有一般意义上质量的概念，但同时它也反映项目在开发过程中的整体协调性。 自动测试的最大优点在于它的高度可重复性。一个理想的自动测试系统能够让人随时、方便和迅速的运行大量的测试用例。因此一个开发人员可以通过检查当天的自动测试结果来分析前一天代码的质量（事后检查），也可以在当天存入代码前，先运行自动测试以进一步确保存入代码的质量（事前检查）。 在微软，每日建造都是在午夜开始，完成后紧接着就是全面的自动测试，到早晨上班时间之前就会把结果自动通过e-mail等方式发送出来。开发人员上班后的第一件事往往就是检查测试结果。如果没有问题就会开始新的工作。如果有测试有用例没有通过，开发人员则必须协同测试人员一起立刻找出原因，解决后才能开始新的代码。有时一个小的失误会引起大面积的测试用例失败，很大一部分开发团队会受到影响。为尽量避免这种情况，要求开发人员在存入代码之前先在自己的个人建造版本上运行一定量的自动测试，全部通过后在存入。如开发人员没有按照这样的要求，而擅自存入质量不高的代码而造成大量测试失败，这种不负责任的行为是要受到严厉批评的。

    从这一过程可以看出，开发人员依赖测试来保证开发工作的质量，使开发整体地协调地向前推进。 当开发进入后期阶段，尽管项目已总体成型，开发人员也会不时遇到一些技术上的挑战。比如一些Bug的解决涉及对项目深层次结构的调整；再比如由于客户反馈的意见造成设计的修改。每一次这样的修改和调整事实上都是对一个稳定系统的破坏，如果处理不当往往一个Bug的修改会生成很多新的Bug，就像一系列联锁的恶性循环。很多项目工期的延误都是这样造成的。要避免或至少将这种破坏减少到最低限度，开发人员首先需要知道这种破坏的影响面。在这里单靠开发人员自身的逻辑思维、技能和经验是远远不够的，自动测试再一次成为一种有效的工具。往往开发人员会制定不止一个方案，对每个方案上都运行一遍同样一套自动测试用例，然后比较结果，选出最佳方案。自动测试在这方面所起的作用不仅在产品的开发过程中，它还延续到产品发布后。产品支持部门在为客户提供应急解决方案时也要依赖自动测试。 管理对测试的依赖 在微软，软件项目管理的主要线索就是Bug的管理，其中最直接具体的管理活动就是“Bug三方讨论会（Bug Triage）”。会议一般由项目管理Program Manager（简称PM）来主持，有开发人员和测试人员参加（所以叫三方会议）。会上对每个新生成的Bug进行讨论，并决定（1）是否接受这个Bug；（2）Bug的严重级别和优先级别；（3）Bug由谁来负责，是由测试提供进一步详细信息，还是交由开发人员解决，以及大致的解决方案等等。会议还要对老的Bug检查解决进度。这种讨论会常常会发生争论，要求测试人员具有足够的技术基础和用户经验，来捍卫产品的质量。可以说项目开发到了某一阶段后就是由这种Bug的管理所驱动的。这其中的原动力来自测试。 项目管理中一项非常重要但也十分困难的工作是衡量项目的进度，包括判断项目的状态，确定项目是否能预期完成。这方面，测试提供了两个非常重要的参数，一个是Bug数量的趋势，另一个是测试结果的趋势。 Bug趋势就是将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势，到项目中后期被解决Bug数曲线会趋于上升，而新生Bug数曲线应下降，到项目最后，两条曲线都趋向于零。PM会持续观察这张图表，确保项目健康发展，同时通过分析预测项目Bug趋于零的时间。在一定的历史经验的基础上分析使用这一图表会得到很多有价值的信息，比如说，可分析开发和测试在人力资源的配比上是否恰当，可以分析出某个严重的Bug所造成的项目质量的波动。 每天的自动测试结果同样可以形成类似的图表。它同样非常有助于了解当前项目的质量状况，开发测试进度。 由测试产生的这些数据不仅在项目开发过程中为项目管理提供有效的依据，而且也是产品通过发布的必要条件。在微软，每个产品都要经过评审才能通过发布。前面介绍的几个图表是发布评审的重要内容，如果从图表中发现临评审前还出现过较大的质量波动，评审人员一定会对此提出质疑。 因此软件项目管理依赖软件测试提供其基本的管理素材。 可以说，现代大型软件开发过程中开发和管理对测试的依赖性是测试与开发流程融合的一个根本因素。从另一个角度看，测试与开发流程融合决不仅仅是简单的时间上的同步，更不是双方空间上的接近，而是这种内在的依存关系的外在表现。开发对测试的这种依赖性对测试和测是人员提出了更高的要求。在理念上，软件测试已远不仅仅只是软件功能的验证和Bug的搜寻；在具体方法上，自动测试和测试工具的使用已成为基本的要求。在微软，测试不仅使用一些通用的工具，每一个产品还有专门开发的专用工具库，测试的代码量常常超过项目本身的代码量。 一个软件企业要提高其软件开发的能力，特别是针对大型软件的大规模的快速开发能力，在测试方面对传统理念和方法进行突破是必要的。微软的实践就是一个很好的印证。

今天看了51testing Blogs上的很多关于QTP的一些文章，发现很多的文章写的都不错，于是自己手也有点痒了，虽然知道自己写作的能力实在不堪入目，就当是写给自己看的啦，呵呵！

同时也给自己鼓励一下，目标就在远方，只要自己肯坚持，脚踏实地，离目标一定会越来越近的！