无忧测试论坛《每日一帖》6月份精华

来自 http://www.51testing.com 这是论坛版主天网每天提供给测试网友的精神食粮,感谢天网

16 贴【 2004 6 1 】:软件质量

“ 每一个程序都能正确地做某件事,但是这并不是我们想要它作的事情。 ” 这样的软件不能算一个质量好的软件。

我们如何定义软件质量呢?可以从不同的角度来看待软件质量并对其定义,它们有一些共同点:强调软件与得到了清晰描述的功能和性能需求的符合度、明显的文档标准以及被认为是所有专业开发的软件所具备的隐式特征。

ISO9126 从如下几个方面来衡量软件质量:功能性、可靠性、可用性、可维护性、效率、可移植性。

如下三个方面应该尤其被重视:
1 、软件需求是质量测度的基础。需求符合性的缺乏也就是缺乏质量;
2 、特定的过程定义了一套开发标准,用以指导软件开发的方式。如果标准未能遵守,那么缺少质量就几乎是肯定的结论;
3 、除了功能需求等显示的需求外,要对非功能的隐式需求重视(例如,对好的可维护性的期望)。如果软件符合其他显式的需求,但是未能满足隐式需求,软件质量仍然是值得怀疑的。

软件质量是一个多因素的复杂混合,这些因素随着不同的应用和需要它们的用户而变化。测试时需要根据一定的质量标准有针对性的进行测试。

17 贴【 2004 6 2 】系统测试方法之恢复测试

Roger S. Pressman

许多基于计算机的系统必须在一定的时间内从错误中恢复过来,然后继续运行。在有些情况下,一个系统必须是可以容错的,这就是说,运行过程中的错误不能使整个系统的功能都停止。在其他情况下,一个系统错误必须在一个特定的时间段之内改正,否则就会造成严重损失。

恢复测试是通过各种手段,让软件强制性地发生故障,然后来验证恢复是否能正常进行的一种系统测试方法。如果恢复是自动的(由系统本身来进行的),重新初始化、检查点机制、数据恢复和重启动都要进行正确验证。如果恢复是需要人工干预的,那么要估算修复的平均时间是否在可以接受的范围之内。

18 贴【 2004 6 3 】:系统测试方法之安全测试

Roger S. Pressman

任何管理敏感信息或者能够对个人造成不正当伤害的计算机系统都是不正当或非法侵入的目标。侵入包括了范围很广的活动:只是为练习而试图侵入系统的黑客;为了报复而试图攻破系统的有怨言的雇员;还有为了得到非法的利益而试图侵入系统的不诚实的个人。

安全测试用来验证集成在系统内的保护机制是否能够在实际中保护系统不受到非法的侵入。引用 Beizer 的话来说: “ 系统的安全当然必须能够经受住正面的攻击 —— 但是它也必须能够经受住侧面的和背后的攻击。 ”

在安全测试过程中,测试者扮演着一个试图攻击系统的个人角色。测试者可以尝试去通过外部的手段来获取系统的密码,可以使用可以瓦解任何防守的客户软件来攻击系统;可以把系统 “ 制服 ” ,使得别人无法访问;可以有目的地引发系统错误,期望在系统恢复过程中侵入系统;可以通过浏览非保密的数据,从中找到进入系统的钥匙;等等。

只要有足够的时间和资源,好的安全测试就一定能够最终侵入一个系统。系统设计者的任务就是要把系统设计为想要攻破系统而付出的代价大于攻破系统之后得到的信息的价值。

19 贴【 2004 6 4 】:系统测试方法之压力测试

Roger S. Pressman

在较早的软件测试步骤中,白盒和黑盒技术对正常的程序功能和性能进行了详尽的检查。压力测试( Stree Testing )的目的是要对付非正常的情形。在本质上说,进行压力测试的人应该这样问: “ 我们能够将系统折腾到什么程度而又不会出错? ”

压力测试是在一种需要反常数量、频率或资源的方式下运行系统。例如,
( 1 )当平均每秒出现 1 个或 2 个中断的情形下,应当对每秒出现 10 个中断的情形来进行特殊的测试;
( 2 )把输入数据的量提高一个数量级来测试输入功能会如何响应;
( 3 )应当执行需要最大的内存或其他资源的测试用例;
( 4 )运行一个虚拟的操作系统中可能会引起大量的驻留磁盘数据的测试用例。
从本质上来说,测试者是想要破坏程序。

压力测试的一个变种是一种被成为是敏感测试的技术。在有些情况(最常见的是在数学算法中)下,在有效数据界限之内的一个很小范围的数据可能会引起极端的甚至是错误的运行,或者引起性能的急剧下降,这种情形和数学函数中的奇点相类似。敏感测试就是要发现在有效数据输入里可能会引发不稳定或者错误处理的数据组合。

20 贴【 2004 6 5 】:系统测试方法之性能测试

Roger S. Pressman

在实时系统和嵌入式系统中,提供符合功能需求但不符合性能需求的软件是不能被接受的。性能测试就是用来测试软件在系统中的运行性能的。性能测试可以发生在各个测试阶段中,即使是在单元层,一个单独模块的性能也可以使用白盒测试来进行评估,然而,只有当整个系统的所有成分都集成到一起之后,才能检查一个系统的真正性能。

性能测试经常和压力测试一起进行,而且常常需要硬件和软件测试设备,这就是说,常常有必要的在一种苛刻的环境中衡量资源的使用(比如,处理器周期)。外部的测试设备可以监测测试执行,当出现情况(如中断)时记录下来。通过对系统的检测,测试者可以发现导致效率降低和系统故障的原因。

21 贴【 2004 6 6 】:回归测试

Roger S. Pressman

每当一个新的模块被当作集成测试的一部分加进来的时候,软件就发生了改变。新的数据流路径建立起来,新的 I/O 操作可能也会出现,还有可能激活了新的控制逻辑。这些改变可能会使原本工作得很正常的功能产生错误。在集成测试策略的环境中,回归测试是对某些已经进行过的测试的某些子集再重新进行一遍,以保证上述改变不会传播无法预料的副作用。

在更广的环境里,(任何种类的)成功测试结果都是发现错误,而错误是要被修改的,每当软件被修改的时候,软件配置的某些方面(程序、文档、或者数据)也被修改了,回归测试就是用来保证(由于测试或者其他原因的)改动不会带来不可预料的行为或者另外的错误。

回归测试可以通过重新执行所有的测试用例的一个子集人工地进行,也可以使用自动化的捕获回放工具来进行。捕获回放工具使得软件工程师能够捕获到测试用例,然后就可以进行回放和比较。回归测试集(要进行的测试的子集)包括三种不同类型的测试用例:
· 能够测试软件的所有功能的代表性测试用例。
· 专门针对可能会被修改影响的软件功能的附加测试。
· 针对修改过的软件成分的测试。

在集成测试进行的过程中,回归测试可能会变得非常庞大。因此,回归测试应当设计为只对出现错误的模块的主要功能进行测试,每当进行一个修改时,就对每一个程序功能都重新执行所有的测试是不实际的而且效率很低的。

22 贴【 2004 6 7 】:测试与调试

测试的目的是显示存在错误,而调试的目的是发现错误或导致程序失效的错误原因,并修改程序以修正错误。调试是测试之后的活动。 [Beizer, 1984] 认为,测试和调试在目标、方法和思路上都有所不同,如下:

1 、测试从一个已知的条件开始,使用预先定义的过程,有预知的结果。调试从一个未知的条件开始,结束的过程不可预计。

2 、测试过程可以实现设计,进度可实现确定。调试不能描述过程或持续时间。

3 、测试是显示错误的行为。调试是推理的过程。

4 、测试显示开发人员的错误。调试是开发人员为自己辩护。

5 、测试能预期和可控。调试需要想象,经验和思考。

6 、测试能在没有详细设计的情况下完成。没有详细设计的信息调试不可能进行。

7 、测试能由非开发人员进行。调试必须由开发人员进行。

23 贴【 2004 6 8 】:系统测试方法之功能测试

功能测试又称正确性测试,它检查软件的功能是否符合规格说明。由于正确性是软件最重要的质量因素,所以其测试也最重要。

基本的方法是构造一些合理输入,检查是否得到期望的输出。这是一种枚举方法。测试人员一定要设法减少枚举的次数,否则测试投入太大。关键在于寻找等价区间,因为在等价区间中,只需用任意值测试一次即可。等价区间的概念可表述如下:记( A , B )是命题 f(x) 的一个等价区间,在( A , B )中任意取 x1 进行测试。如果 f (x1) 错误,那么 f (x) 在整个( A , B )区间都将出错。如果 f (x1) 正确,那么 f (x) 在整个( A , B )区间都将正确。上述测试方法称为等价测试,来源于人们的直觉与经验,可令测试事半功倍。

还有一种有效的测试方法是边界值测试。即采用定义域或者等价区间的边界值进行测试。因为程序员容易疏忽边界情况,程序也 “ 喜欢 ” 在边界值处出错。例如测试平方根函数的一段程序。凭直觉输入等价区间应是( 0 , 1 )和( 1 , +∞ )。可取 x=0 。 5 以及 x=2 。 0 进行等价测试。再取 x=0 以及 x=1 进行边界值测试。

有一些复杂的程序,我们难以凭直觉与经验找到等价区间和边界值,这时枚举测试就相当有难度。

24 贴【 2004 6 9 】:黑盒测试的端口测试模型

端口测试模型侧重于对被测对象的抽象,它阐明的是我们要测试什么。它将被测试者间的共性抽象出来,使测试者和被测者可以最大程度地分离开来。其主要思想是:被测试者可以用测试端口集来表达。测试功能体现在测试端口对外协议(称为端口协议)的实现,对不同系统的测试或对同一系统中不同子系统的测试都表现为对不同端口的测试。端口协议一般是非确定的有限自动机( NFA) ,它可以分解成确定的有限自动机( DFA) 的集合(对应于功能迁移路径集),并可以用结构化语言描述在测试用例中。这样,端口协议的差异就不会影响测试者的内部实现(与被测者的接口除外)。

25 贴【 2004 6 10 】:黑盒测试的对象测试模型

对象测试模型注重于测试内容的表达,它 阐明的是如何表达我们的测试内容。它把分散的功能测试单元有机地组合起来,使实际测试更逼近真正的系统测试。其主要思想是:测试内容及测试的实现方法(指对测试数据的处理)可以被封装在一个个的测试对象中。测试对象有三个层次:数据对象、业务对象和事务对象,它们的关系是逐级被包含。简单来说, 数据对象是指业务(或功能)数据的载体,它通常有物理对应,其主要测试内容是一个状态迁移图;业务对象指共同实现一种业务(或功能)的数据对象集合,它一般都只有逻辑对应,其主要测试内容是一个时间追踪图;事务对象是指一组业务相关的业务对象的有序组合,其主要测试内容是业务间的关系图,准确地说是业务结果间的布尔关系图。

26 贴【 2004 6 11 】:黑盒测试的分层设计模型

分层设计模型侧重于黑盒自动测试工具的实现,它阐明的是我们如何设计测试工具。它将测试工具的功能进行抽象和分层,使测试工具的积木化开发现实可行。其主要思想是:测试工具可划分为五个不同的层次,从低到高依次是:端口驱动层、测试执行层、测试表达层、测试管理层、测试设计层。通过规范这五个层次间的接口,可以使按照这个设计模型设计的测试工具或提供相同的接口的其它测试工具无缝地集成在一起,从而实现理想的积木式开发。

27 贴【 2004 6 12 】: QA 的职责

QA 到底应该在企业里起什么作用呢?下面是 QA 职责的总结:

1 、保障软件组织流程体系得到遵守;
2 、促使软件组织过程改进 ;
3 、 指导项目实施流程,;
4 、增加开发活动透明度;
5 、评审项目活动;
6 、审核工作产品;
7 、协助工作产品问题解决;
8 、度量数据采集、分析,提供决策参考;
9 、进行缺陷预防;
10 、实现质量目标。

28 贴【 2004 6 13 】:软件走读

软件走读的目的是为了对软件产品进行评价,软件走读也可以是为给参与走读的人员培训有关软件产品知识而举行,软件走读的主要目的是:
1 )发现软件产品中的软件异常,缺陷、遗漏和自相矛盾的地方,以改进产品并提出可供选择的实现方案;
2 )改进软件产品;
3 )考虑可选项方案的实现方法;
4 )评价与标准和规格的符合性;
5 )进行技术交流,人员培训。

在软件走读中可以指出各种缺陷,例如软件产品中的效率和可读性问题,设计或编码中模块化问题,或者规格书中的可测试问题等等。

要求进行软件走读的软件产品,包括但不限于:
1 )软件需求规格,
2 )软件设计文档,
3 )源代码,
4 )软件测试文档,
5 )软件用户文档,
6 )维护手册,
7 )安装过程

29 贴【 2004 6 14 】: TCL 简介

TCL 是一脚本解释器,具有基本的语言特性,支持整型和字符串变量,支持循环等控制结构;同时它具有灵活的扩展性和跨平台的特性,后者是它最主要的特性。通过 TCL 脚本可以编写测试用例,通过扩展功能,可以扩展你想要的测试动作。最终目的是将测试的自动化和 灵活性(可扩展性)结合在一起。      

     TCL 提供以下接口:
     1 、用户接口
      对用户提供语言特性,如循环、条件判断等控制结构,通过它用户可以灵活的书写测试用例;当然只 提供语言特性远远不够,因为业务千差万别,所以用户需要业务接口,从而完成特定的测试任务。 而业务接口,是通过下面的程序员接口实现。
      2 、程序员接口
       用户可以编写自己命令,它包括用户层(即名字)和实现层(通过 C 语言实现),然后用 TCL 提供的注册 函数登记,以后命令就可灵活的嵌入到脚本中了。

      TCL 测试模型分三部分:
       被测试程序(由开发人员编写) ---- 测试人员应搞清楚程序结构和业务功能,指导扩展命令的设计。
       测试代码(由测试设计人员编写)   --- 通过程序员接口,提供给脚本扩展命令。
       测试用例( TCL 脚本形式,由测试执行人员编写) --- 通过脚本对扩展命令进一步组合。

30 贴【 2004 6 15 】: CMM 的五级简介

CMM 为企业的软件过程能力提供了一个阶梯式的进化框架,阶梯共有五级。第一级只是一个起点,任何准备按 CMM 体系进化的企业都自然处于这个起点上,并通过它向第二级迈进。除第一级外,每一级都设定了一组目标,如果达到了这组目标,则表明达到了这个成熟级别,可以向下一级别迈进。
第一级、初始级:
      初始级的软件过程是未加定义的随意过程,项目的执行是随意甚至是混乱的。也许有些企业制定了一些软件工程规范,但若这些规范未能覆盖基本的关键过程要求,且执行没有政策、资源等方面的保证时,那么它仍然被视为初始级。
第二级、重复级:
      根据多年的经验和教训,人们总结出软件开发的首要问题不是技术问题而是管理问题。因此,第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程,可重复的过程才能逐渐改进和成熟。可重复级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面;其中项目管理过程又分为计划过程和跟踪与监控过程。通过实施这些过程,从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。
第三级、定义级:        
       在可重复级定义了管理的基本过程,而没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准,并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程,裁剪出与项目适宜的过程,并且按照过程执行。过程的裁剪不是随意的,在使用前必须经过企业有关人员的批准。
第四级、管理级:        
       第四级的管理是量化的管理。所有过程需建立相应的度量方式,所有产品的质量(包括工作产品和提交给用户的最终产品)需要有明确的度量指标。这些度量应是详尽的,且可用于理解和控制软件过程和产品。量化控制将使软件开发真正成为一种工业生产活动。
第五级、优化级:        
      优化级的目标是达到一个持续改善的境界。所谓持续改善是指可以根据过程执行的反馈信息来改善下一步的执行过程,即优化执行步骤。如果企业达到了第五级,就表明该企业能够根据实际的项目性质、技术等因素,不断调整软件生产过程以求达到最佳。

31 贴【 2004 6 16 】: CMM 2 KPA 的目标

CMM 2 级:可重复级
        Requirement Management
        需求管理
        Goal 1  System requiremnets allocated to software are controlled to establish a baseline for software engineering and management use.
        目标 1 :分配到软件部分的系统需求通过建立基线受控。
        Goal 2   Software plans, products, and activities are kept consistent with the system requirements allocated to software.
        目标 2 :软件计划、产品和活动与分配到软件部分的系统需求一致。
       
        Software Project Planning
        软件项目计划
        Goal 1   Software estimates are documented for use in planning and tracking the software project.
        目标 1 :用来计划和跟踪软件项目的软件估计文档化。
        Goal 2   Software project activities and commitments are planned and documented.
        目标 2 :制定了软件项目活动和任务书的计划,并且有文档记录。
        Goal 3   Affected groups and individuals agree to their commitments related to the software project.
        目标 3 :受影响的小组和个人接受和软件项目相关的任务书。

        Software Project Tracking and Oversight
        软件项目跟踪及监控
        Goal 1  Actual results and performances are tracked against the software plans.
        目标 1 :按照软件计划跟踪实际结果和性能。
        Goal 2  Corrective actions are taken and managed to closure when actual results and performance deviate significantly from the software plans.
        目标 2 :当实际的结果和性能严重偏离软件计划时,采取了正确的行动终止这种状况。
        Goal 3  Changes to sofware commitments are agreed to by the affected groups and individuals.
        目标 3 :受影响的小组和个人接受软件任务书的变化。

        Software Subcontract Management
        软件子合同管理
        Goal 1  The prime contractor selects qualified software subcontractors.
        目标 1 :主签约人挑选有资格的子签约人。
        Goal 2  The prime contractor and the software subcontractor agree to their commitments to each other.
        目标 2 :主签约人和子签约人互相接受他们的任务书。
        Goal 3  The prime contractor and the software subcontractor maintain ongoing communications.
        目标 3 :主签约人和子签约人保持持续的沟通。
        Goal 4  The prime contractor tracks the software subcontractor's actual results and performance against its commitments.
        目标 4 :主签约人按照任务书跟踪子签约人的实际结果和效能。

        Software Quality Assurance
        软件质量保证
        Goal 1  Software quality assurance activities are planned.
        目标 1 :制定了软件质量保证计划。
        Goal 2  Adherence of software products and activities to the applicable standards, procedures, and requirements is verified objectively.
        目标 2 :客观地检验软件产品和活动是否符合适用的标准、过程和需求。
        Goal 3  Affected groups and individuals are informed of software quality assurance activities and results.
        目标 3 :软件质量保证的活动和结果通知了受影响的小组和个人。
        Goal 4  Noncompliance issues that cannot be resolved within the software project are addressed by senior management.
        目标 4 :高层管理着手解决在软件项目内部不能解决的不符合项。

        Software Configuration Management
        软件配置管理
        Goal 1  Software configuration management activities are planned.
        目标 1 :制定了软件配置管理活动的计划。
        Goal 2  Selected software work products are identified, controlled, and available.
        目标 2 :选定的软件工作产品是被标识的、受控的和可利用的。
        Goal 3  Changes to identified software work products are controlled.
        目标 3 :被标识的软件工作产品的变化是受控的。
        Goal 4  Affected groups and individuals are informed of the status and content of software baselines.
        目标 4 :软件基线的状态和内容通知受影响的小组和个人。

32 贴【 2004 6 17 】: Logiscope 的功能

LOGISCOPE 是为软件的全面质量控制而开发的强大工具,可以用在编程、测试和维护阶段。 LOGISCOPE 五个模块的功能:
  (1) 阅读器 (Viewer) :以文件调用图 ( 各部件文件之间的关系 ) 及组件调用图 ( 函数和程序间的调用关系 ) 的形式进行可视化应用软件设计。可以在各种各样的抽象级别上分析应用程序,在不同级别上的引导有助于整个应用程序的理解。
  (2) 效果检查器 (ImpactChecker) :允许用户检查使用的资源 ( 文件、函数、用户定义类型、全局变量、结构成员常量 ) 。它有助于我们理解函数间的信息流 ( 参数传递 ) ,以及数据和其它应用程序资源间的关系。
  (3) 规则检查器 (RuleChecker) :软件公司应该定义自己的编程规则和质量目标。这样做的好处是公司编程行为保持一致性、易于维护、提高可靠性、易于移植到其它机器上。我们可以用规则检查器 (RuleChecker) 确立编程标准,保证质量控制。
  (4) 测试检查器 (TestChecker) :实时度量测试覆盖率、显示未覆盖路径原始数据、生成测试报告、帮助管理测试实例。测试检查器 (TestChecker) 和动态分析器 (Dynamic Analyzer) 通过阅读器产生用于应用程序分析的数据。
  (5) 代码检查器 (CodeChecker) :验证应用程序与质量模型的一致性。代码检查器和静态分析器 (Static Analyzer) 通过阅读器 (Viewer) 产生用于应用程序分析的数据。代码检查器 (CodeChecker) 可以使我们尽早发现和修改质量缺陷。这对质量控制尤为重要。

33 贴【 2004 6 18 】: α 测试

α 测试是由一个用户在开发环境下进行的测试,也可以是开发机构枘部的用户在模拟实际操作环境下进行的测试。软件在一个自然设置状态下使用。开发者坐在用户旁边,随时记下错误情况和使用中的问题。这是在受控制的环境下进行的测试, α 测试的目的是评价软件产品的 FLURPS( 即功能、局域化、可使用性、可靠性、性能和支持 ) 。尤其注重产品的界面和特色。 α 测试人员是除开产品开发人员之外首先见到产品的人,他们提出的功能和修改意见是特别有价值的。 α 测试可以从软件产品编码结束之时开始,或在模块(子系统)测试完成之后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程序之后再开始。有关的手册(草稿)等应事先准备好。

34 贴【 2004 6 19 】: β 测试

β 测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。这些用户是与公司签定了支持产品预发行合同的外部客户,他们要求使用该产品,并愿意返回有关错位错误信息给开发者。与 α 测试不同的是,开发者通常不在测试现场。因而, β 测试是在开发者无法控制的环境下进行的软件现场应用。在 β 测试中,由用户记下遇到的所有问题,包括真实的以及主观认定的,定期向开发者报告,开发者在综合用户的报告之后,做出修改,最将软件产品交付给全体用户使用。 β 测试主要衡量产品的 FLURPS 。着重于产品的支持性,包括文档、客户培训和支持产品生产能力。只有当 α 测试达到一定的可靠程度时,才能开始 β 测试。由于它处在整个测试的最后阶段,不能指望这时发现主要问题。同时,产品的所有手册文本也应该在此阶段完全定稿。
    由于 β 测试的主要目标是测试可支持性,所以 β 测试应尽可能由主持产品发行的人员来管理。

35 贴【 2004 6 20 】:面向对象的集成测试

  传统的集成测试,是通过各种集成策略集成各功能模块进行测试,一般可以在部分程序编译完成的情况下进行。而对于面向对象程序,相互调用的功能是散布在程序的不同类中,类通过消息相互作用申请和提供服务。类的行为与它的状态密切相关,状态不仅仅是体现在类数据成员的值,也许还包括其他类中的状态信息。由此可见,类相互依赖极其紧密,根本无法在编译不完全的程序上对类进行测试。所以,面向对象的集成测试通常需要在整个程序编译完成后进行。此外,面向对象程序具有动态特性,程序的控制流往往无法确定,因此也只能对整个编译后的程序做基于黑盒子的集成测试。
   面向对象的集成测试能够检测出相对独立的单元测试无法检测出的那些类相互作用时才会产生的错误。基于单元测试对成员函数行为正确性的保证,集成测试只关注于系统的结构和内部的相互作用。面向对象的集成测试可以分成两步进行:先进行静态测试,再进行动态测试。
   静态测试主要针对程序的结构进行,检测程序结构是否符合设计要求。现在流行的一些测试软件都能提供一种称为 " 可逆性工程 " 的功能,即通过原程序得到类关系图和函数功能调用关系图,例如 International Software Automation 公司的 Panorama-2 、 Rational 公司的 Rose C++ Analyzer 等,将 " 可逆性工程 " 得到的结果与 OOD 的结果相比较,检测程序结构和实现上是否有缺陷。换句话说,通过这种方法检测 OOP 是否达到了设计要求。
   动态测试设计测试用例时,通常需要上述的功能调用结构图、类关系图或者实体关系图为参考,确定不需要被重复测试的部分,从而优化测试用例,减少测试工作量,使得进行的测试能够达到一定覆盖标准。测试所要达到的覆盖标准可以是:达到类所有的服务要求或服务提供的一定覆盖率;依据类间传递的消息,达到对所有执行线程的一定覆盖率;达到类的所有状态的一定覆盖率等。同时也可以考虑使用现有的一些测试工具来得到程序代码执行的覆盖率。
   具体设计测试用例,可参考下列步骤:
1. 先选定检测的类,参考 OOD 分析结果,仔细出类的状态和相应的行为,类或成员函数间传递的消息,输入或输出的界定等。
2. 确定覆盖标准。
3. 利用结构关系图确定待测类的所有关联。
4. 根据程序中类的对象构造测试用例,确认使用什么输入激发类的状态、使用类的服务和期望产生什么行为等。
   值得注意,设计测试用例时,不但要设计确认类功能满足的输入,还应该有意识的设计一些被禁止的例子,确认类是否有不合法的行为产生,如发送与类状态不相适应的消息,要求不相适应的服务等。根据具体情况,动态的集成测试,有时也可以通过系统测试完成。

36 贴【 2004 6 21 】:面向对象的系统测试

通过单元测试和集成测试,仅能保证软件开发的功能得以实现。但不能确认在实际运行时,它是否满足用户的需要,是否大量存在实际使用条件下会被诱发产生错误的隐患。为此,对完成开发的软件必须经过规范的系统测试。换个角度说,开发完成的软件仅仅是实际投入使用系统的一个组成部分,需要测试它与系统其他部分配套运行的表现,以保证在系统各部分协调工作的环境下也能正常工作。  
       系统测试应该尽量搭建与用户实际使用环境相同的测试平台,应该保证被测系统的完整性,对临时没有的系统设备部件,也应有相应的模拟手段。系统测试时,应该参考 OOA 分析的结果,对应描述的对象、属性和各种服务,检测软件是否能够完全 " 再现 " 问题空间。系统测试不仅是检测软件的整体行为表现,从另一个侧面看,也是对软件开发设计的再确认。
   这里说的系统测试是对测试步骤的抽象描述。它体现的具体测试内容包括:
· 功能测试:测试是否满足开发要求,是否能够提供设计所描述的功能,是否用户的需求都得到满足。功能测试是系统测试最常用和必须的测试,通常还会以正式的软件说明书为测试标准。
· 强度测试:测试系统的能力最高实际限度,即软件在一些超负荷的情况,功能实现情况。如要求软件某一行为的大量重复、输入大量的数据或大数值数据、对数据库大量复杂的查询等。
· 性能测试:测试软件的运行性能。这种测试常常与强度测试结合进行,需要事先对被测软件提出性能指标,如传输连接的最长时限、传输的错误率、计算的精度、记录的精度、响应的时限和恢复时限等。
· 安全测试:验证安装在系统内的保护机构确实能够对系统进行保护,使之不受各种非常的干扰。安全测试时需要设计一些测试用例试图突破系统的安全保密措施,检验系统是否有安全保密的漏洞。
· 恢复测试:采用人工的干扰使软件出错,中断使用,检测系统的恢复能力,特别是通讯系统。恢复测试时,应该参考性能测试的相关测试指标。
· 可用性测试:测试用户是否能够满意使用。具体体现为操作是否方便,用户界面是否友好等。
· 安装 / 卸载测试( install/uninstall test )等等。
   系统测试需要对被测的软件结合需求分析做仔细的测试分析,建立测试用例。

37 贴【 2004 6 22 】: TMM 介绍

测试是软件开发的重要过程之一,但是 CMM 没有充分的定义测试,没有提及测试成熟度的概念,没有对测试过程改进进行充分说明,在 KPA 中没有定义测试问题,与质量相关的测试问题如可测性,充分测试标准,测试计划等方面也没有满意的阐述。

   TMM 是受 CMM 模型启发产生的,关注于测试的成熟度模型。它描述了测试过程,是项目测试部分得到良好计划和控制的基础。 TMM 测试成熟度分解为 5 级别,关注于 5 个成熟度级别递增:

    Phase 0 :测试和调试没有区别,初了支持调试外,测试没有其他目的
    Phase 1 : 测试的目的是为了表明软件能够工作
    Phase 2 :测试的目的是为了表明软件不能够能够正常工作
    Phase 3 : 测试的目的不是要证明什么,而是为了把软件不能正常工作的预知风险降低到能够接受的程度
    Phase 4 : 测试不是行为,而是一种自觉的约束 (mental discipline) ,不用太多的测试投入产生低风险的软件上的

38 贴【 2004 6 23 】:软件测试自动化的概念

软件测试自动化,是一项让计算机代替测试人员进行软件测试的技术。他可以让测试人员从繁琐和重复的测试活动中解脱出来,专心从事有意义的测试设计等活动。如果采用自动比较技术,还可以自动完成测试用例执行结果的判断,从而避免人工比对存在的疏漏问题。设计良好的自动化测试,在某些情况下可以实现 “ 夜间测试 ” 和 “ 无人测试 ” 。在大多数情况下,软件测试自动化可以减少开支,增加有限时间内可执行的测试,在执行相同数量测试时节约测试时间。

软件测试自动化通常借助测试工具进行。测试工具可以进行部分的测试设计、实现、执行和比较的工作。通过运用测试工具,可以达到提高测试效率的目的。所以测试工具的选择和推广使用应该给予重视。部分的测试工具可以实现测试用例的自动生成,但通常的工作方式为人工设计测试用例,使用工具进行用例的执行和比较。

软件测试自动化的设计并不能由工具来完成,必须由测试人员进行手工设计,但是在设计是却必须考虑自动化的特殊要求,否则无法实现利用工具进行用例的自动执行。为此,就必须在测试的设计和内容的组织方面采取一些特殊的方法。

对于软件测试自动化的工作,大多数人都认为是一件非常容易的事。其实,软件测试自动化的工作量非常大,而且也并不是在任何情况下都适用,同时软件测试自动化的设计并不比程序设计简单

39 贴【 2004 6 24 】:自动化测试的优点

通过自动化测试,可以使某些任务提高执行效率。除此之外,还有其它优点:

① 对程序的回归测试更方便。这可能是自动化测试最主要的任务,特别是在程序修改比较频繁时,效果是非常明显的。由于回归测试的动作和用例是完全设计好的,测试期望的结果也是完全可以预料的,将回归测试自动运行,可以极大提高测试效率,缩短回归测试时间。

② 可以运行更多更繁琐的测试。自动化的一个明显的好处是可以在较少的时间内运行更多的测试。

③ 可以执行一些手工测试困难或不可能进行的测试。比如,对于大量用户的测试,不可能同时让足够多的测试人员同时进行测试,但是却可以通过自动化测试模拟同时有许多用户,从而达到测试的目的。

④ 更好地利用资源。将繁琐的任务自动化,可以提高准确性和测试人员的积极性,将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试,仅适合于手工测试,将可自动测试的测试自动化后,可以让测试人员专注于手工测试部分,提高手工测试的效率。

⑤ 测试具有一致性和可重复性。由于测试是自动执行的,每次测试的结果和执行的内容的一致性是可以得到保障的,从而达到测试的可重复的效果。

⑥ 测试的复用性。由于自动测试通常采用脚本技术,这样就有可能只需要做少量的甚至不做修改,实现在不同的测试过程中使用相同的用例。

⑦ 可以让产品更快面向市场。自动化测试可以缩短测试时间,加快产品开发周期。

⑧ 增加软件信任度。由于测试是自动执行的,所以不存在执行过程中的疏忽和错误,完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后,软件的信任度自然会增加。

总之,通过较少的开销获得更彻底的测试,提高软件质量,这是测试自动化的最终目的。

40 贴[ 2004-6-25 ]:自动化测试中常见的问题

在软件测试自动化的实施过程中会遇到许多问题,以下是一些比较普遍的问题:

① 不现实的期望。一般来说,业界对于任何新技术的解决方案都深信不疑,认为可以解决面临的所有问题,对于测试工具也不例外。但事实上,如果期望不现实,无论测试工具如何,都满足不了期望。

② 缺乏测试实践经验。如果缺乏测试的实践经验,测试组织差,文档较少或不一致,测试发现缺陷的能力较差,那么首先要做的是改进测试的有效性,而不是改进测试效率。只有手工测试积累到一定程度,才能做好自动化测试。

③ 期望自动测试发现大量的新缺陷。测试第一次运行时最有可能发现缺陷。如果测试已经运行,再次运行相同的测试发现新缺陷的概率就小得多。对回归测试而言,再次运行相同的测试只是确保修改是正确的,并不能发现新的问题。

④ 安全性错觉。如果自动测试过程没有发现任何缺陷,并不意味着软件没有缺陷。可能由于测试设计的原因导致测试本身就有缺陷。

⑤ 自动测试的维护性。当软件修改后,通常也需要修改部分测试,这样必然导致对自动化测试的修改。在进行自动化测试的设计和实现时,需要注意这个问题,防止自动化测试带来的好处被高维护成本所淹没。

⑥ 技术问题。商业的测试工具也是软件产品,并不能解决所有问题,通常在某些地方还会有欠缺。测试工具都有适用范围,要很好的利用它,对使用者进行培训是必不可少的。

⑦ 组织问题。自动测试实施并不简单,必须有管理支持及组织艺术。

41 贴【 2004 6 27 】:测试自动化的限制

测试自动化可以带来非常明显的收益,但也有其限制,主要有:
  1. 不能取代手工测试
  2. 手工测试比自动测试发现的缺陷更多
  3. 对测试质量的依赖性极大
  4. 测试自动化不能提高有效性
  5. 测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱,所以维护会受到限制,从而制约软件的开发。
  6. 工具本身并无想像力
       
   另外,人工测试比测试工具更优越的另一个方面是可以处理意外事件。虽然工具也能处理部分异常事件,但是对真正的突发事件和不能由软件解决的问题就无能为力。

42 贴【 2004 6 28 】:什么是应首先被自动化的测试?

软件测试的自动化过程是一个渐进的过程,并不需要一开始就对所有的测试进行自动化,这通常也是不现实的。如何选择首先被自动化的测试成了最先遇到的问题。

    有些测试,完全没有必要进行自动化,因为自动化它们所需的时间比手工运行它们全部的次数所需的时间总和还长。例如,手工运行一个测试要 10 分钟,而且一般每个月运行 1 次,那么一年需要 120 分钟。但如果自动化这测试需要 10 小时,那么这个测试需要连续不断运行 5 年才能收回成本。

    有些测试,虽然执行的时间不长,但过程繁琐,需要执行的动作非常多。比    如,一个运行 10 分钟的测试,可能需要击键 150 次,打开 4 ~ 5 个窗口,切换操作。如果将其自动化,可以提高可靠性,也是值得的。

    对软件进行的功能性测试,是测试软件系统在做什么。这些测试可以明确的知道应该在什么情况下输入什么,会有什么样的输出。这样的测试是非常容易被自动化的,也能从自动化中获得较大的收益。

    对软件进行的性能测试,包括在不同的系统负载下进行的测试。这些测试需要采用工具辅助完成,非常适合进行自动化。

      如果在测试中,运行 10% 的测试需要花费 90% 的时间,那么将这 10% 的测试自动化是值得的。

      以下列出了选择首先进行自动化时要考虑的因素:
      非常重要的测试
      涉及范围很广的测试
      对主要功能的测试
      容易自动化的测试
      很快有回报的测试
      运行最频繁的测试

      应该注意避免一口气自动化太多的测试。太多的工作导致参与人员工作积极性下降,可维护性下降,增加工作的风险。寻找可快速制胜的测试,尽快让大家看到工作成果,有助于获得更多的工作支持。

43 贴【 2004 6 29 】:工具的选择:创建还是购买

在评估了商业市场后,你可能会发现在你的限制之内没有符合你需求的工具。这时需要考虑是否自行开发自己的工具,还是等待市场上出现满足要求的新工具。

   自行开发新工具有以下特点:
  1 、它将是最合适你的需求的
  2 、可以在工具中补偿被测软件缺乏的可测试性
  3 、工具可以假设很了解被测程序,因而减少了实现测试自动化所需的工作
  4 、在文档、帮助和培训方面可以不用提供很好的支持
  5 、工具可能具有某些典型的问题,如结构、可扩展性等
  6 、用户界面不友好

   商业工具有以下特点:
  1 、获得一个指定功能和性能标准的工具的费用可能比自行开发一个工具的成本 要低
  2 、在文档、帮助和培训方面必须提供良好的支持
  3 、工具通常应该很有吸引力
  4 、即使使用一个商业工具,可能无法完全避免建立自己的工具

   但即使决定自行开发测试工具,也不要试图生产一个可以广泛使用的商业工具。

44 贴【 2004 6 30 】:自动化脚本之线性脚本

线性脚本是录制手工执行的测试用例得到的脚本。这种脚本包含所有用户的键盘和鼠标输入。如果仅使用线性脚本技术,每个测试用例可以通过脚本完整地被回放。线性脚本中也可能包括比较,比如检查某个窗口是否弹出。

   手工运行 10 分钟的测试用例,可能需要 20 分钟到 2 个小时才能完成测试自动化的工作。因为录制的脚本需要维护,尤其是增加部分内容后的维护和测试需要花费很多时间。而且自动化以后的测试执行的时间会大于 10 分钟。

   线性脚本有以下的优点:
  1 、不需要深入的工作或计划
  2 、可以加快开始自动化
  3 、对实际执行操作可以审计跟踪
  4 、用户不必是编程人员
  5 、提供良好的(软件或工具)的演示

   线性脚本适用于以下情况:
  1 、演示或培训
  2 、执行量较少,且环境变化小的测试
  3 、数据转换,如将数据从 Notes 数据库中转换到 EXCEL 表格中

   线性脚本有以下缺点:
  1 、过程繁琐
  2 、一切依赖于每次捕获的内容
  3 、测试输入和比较是 “ 捆绑 ” 在脚本中的
  4 、无共享或重用脚本
  5 、线性脚本容易受软件变化的影响
  6 、线性脚本修改代价大,维护成本高
  7 、非常容易受意外事件的影响,引起整个测试失败