分类目录归档:软件测试

Kohana 3.1 unittest在phpunit 3.6版本中出错的解决办法

问题1:

modules\unittest\classes\kohana\unittest\tests.php中的$filter = PHP_CodeCoverage_Filter::getInstance();报错

处理办法:

//$filter = PHP_CodeCoverage_Filter::getInstance();
//修改为以下代码
$filter = new PHP_CodeCoverage_Filter();

问题2:

modules\unittest\classes\kohana\unittest\runner.php中的$this->result->collectCodeCoverageInformation( (bool) $collect_cc);报错

处理办法:

//$this->result->collectCodeCoverageInformation( (bool) $collect_cc);
//修改为以下代码
$this->result->getCollectCodeCoverageInformation( (bool) $collect_cc);

完成后就可以使用,上图:

测试管理工具–QC认识

因为我们的开发产品由对公司内部服务转变为对外提供服务,所以在这个阶段,我们遇到了很多问题,对外服务的产品的质量也没有很好的保障,公司最近招了一个QA经理,虽然对我们开发人员来说可能要转变不少做法和观念,但是就像QA经理讲的,其实在这个过程中收获最多的是我们自己,我们由先前的一个编码人员,能够真正的转变为一个IT工程师。
今天QA经理又问我有没有服务器能够安装QC,我先前也没有接触过这东西,所以正好在网上找点资料,让自己也提高下,认识下QC:
QC的前身就是TD,可以叫Quality Centet,下面介绍下QC的功能:

1.Quality Center 有助于维护测试的项目数据库,这个数据库涵盖了应用程序功能的各个方面。设计了项目中的每个测试,以满足应用程序的某个特定的测试需求。要达到项目的各个目标,可将项目中的测试组织成各种特定的组。Quality Center 提供了一种直观、高效的方法,用于计划和 执行测试集、收集测试结果以及分析相关数据。Quality Center 还具有一套完善的系统,用于跟踪应用程序缺陷,通过它,您可以在从初期检测到最后解决的整个过程中严密监视缺陷。将 Quality Center 链接到电子邮件系统,所有应用程序开发、质量保证、客户支持和信息系统人员可以共享缺陷跟踪信息。

2.Quality Center 可以集成 Mercury 测试工具(WinRunner、QuickTest Professional、QuickTest Professional for MySAP.com Windows Client、LoadRunner 和 Visual API-XP)以及第三方和自定义测试工具、需求和配置管理工具。Quality Center 可以无缝地与您选择的测试工具通信,提供一种完整的解决方案,使应用程序测试完全自动化。

3.Quality Center 可指导您完成测试流程的需求指定、测试计划、测试执行和缺陷跟踪阶段。它把应用程序测试中所涉及的全部任务集成起来,有助于确保客户能够得到最高质量的应用程序。

下面有时间我也要学习下。

白盒测试用例设计问题演示

问题:    对这样一段代码:

if (a>2 && b<3 &line;&line; (c>4 && d<5))

statement;

请问,按照各种覆盖方法应该怎么考虑它的测试?

我们这里只给出Condition/Decision Coverage和Modified Condition/Decision Coverage两种覆盖方法的用例设计。

Condition/Decision Coverage:
条件                                      结果
a<2   b>3   c<4    d>5                  (a<2 && b>3 &line;&line; (c<4 && d>5)
T     T     T      T                             T
F     F     F      F                             F这个很容易,就不解释了。

odified Condition/Decision Coverage:

基本思路:

表达式可以理解为(a<2 && b>3) &line;&line; (c<4 && d>5);

将表达式的理解为两个组合条件A or B形成的表达式,其中A为(a<2 && b>3),B为(c<4 && d>5);

对这个表达式,当A为F时,B是独立变量;当B为F时,A是独立变量;

则第一步的分析可以围绕A、B进行:
条件                                      结果
(A)       (B)                                A or B
F         T                                    T
T         F                                    F
T         F                                    F
F         F                                    F

其中最后一组取值重复,最终根据这三种取值进一步分析。

5.  第二步的分析,考虑A表达式,A为(a<2 && b>3),当a<2取值为T时,b>3为独立变量;b>3取值为T时,a<2为独立变量;因此,A条件取值为F的MC/DC用例为:
条件
结果
(a<2)       (b>3)                           (A)
T           F                                F
F           T                                F

A条件取值为T的用例为T,T;

6.  第三步的考虑,分析B表达式,B为(c<4 && d>5),同对A的分析,B为T的用例为T,T;B为F的用例为T,F和F,T;

7.    综合4、5、6的分析,最终得出结果:

条件                                      结果
a<2   b>3   c<4    d>5                  (a<2 && b>3 &line;&line; (c<4 && d>5)
T     F     T      T                             T
F     T     T      T                             T
T     F     T      F                             F
F     T     T      F                             F
T     F     T      F                             F
F     T     F      T                             F
T     T     T      F                             T
T     T     F      T                             T

黑盒测试用例设计案例 (转)

【例1】假设现有以下的三角形分类程序。该程序的功能是,读入代表三角形边长的3个整数,判定它们能否组成三角形。如果能够,则输出三角形是等边、等腰或任意三角形的分类信息。图9.11显示了该程序的流程图和程序图。为以上的三角形分类程序设计一组测试用例。

【解】

第一步:确定测试策略。在本例中,对被测程序的功能有明确的要求,即:

(1)判断能否组成三角形;

(2)识别等边三角形;

(3)识别等腰三角形;

(4)识别任意三角形。因此可首先用黑盒法设计测试用例,然后用白盒法验证其完整性,必要时再进行补充。

第二步:根据本例的实际情况,在黑盒法中首先可用等价分类法划分输入的等价类,然后用边界值分析法和猜错法作补充。

等价分类法:

有效等价类

输入3个正整数:

(1)3数相等

(2)3数中有2个数相等,比如AB相等

(3)3数中有2个数相等,比如BC相等

(4)3数中有2个数相等,比如AC相等

(5)3数均不相等

(6)2数之和不大于第3数,比如最大数是A

(7)2数之和不大于第3数,比如最大数是B

(8)2数之和不大于第3数,比如最大数是C

无效等价类:

(9)含有零数据

(10)含有负整数

(11)少于3个整数

(12)含有非整数

(13)含有非数字符

边界值法:

(14)2数之和等于第3数

猜错法:

(15)输入3个零

(16)输入3个负数

第三步:提出一组初步的测试用例,如下表所示:

第四步:用白盒法验证第三步产生的测试用例的充分性。结果表明,上表中的前8个测试用例,已能满足对被测程序图的完全覆盖,不需要再补充其他的测试用例。

软件测试过程模型

针对每个测试级别,将适当的执行如下活动:    一、创建测试策略:

输入:

·   要求硬件和软件组件的详细说明,包括测试工具(测试环境,测试工具数据)。

·   针对测试和进度约束(人员,进度表)所需资源的角色和职责说明

·   测试方法(标准)

·   应用程序的功能性和技术性需求(需求,变更请求,技术性和功能性设计文档)

·   系统无法提供的需求(系统局限)

输出:

·  已批准和签署的测试策略文档,测试计划,测试用例

·  需要解决方案的测试项目(通常要求客户项目的管理层协调)

过程:

·   测试策略是关于如何测试系统XYZ的正式描述,要求开发针对所有测试级别的测试策略。测试小组分析需求,编写测试策略并且和项目小组一起复审计划。

·   测试计划应该包括测试用例和条件,测试环境,与任务相关的测试,通过/失败的准则和测试风险评估。测试进度表将识别所有要求有成功的测试成果的任务,活动的进度和资源要求。

二、创建测试计划/设计

输入:

·   已批准的测试策略文档。

·   如果测试工具适用,自动化测试软件和以前开发的测试脚本

·   作为一种测试的结果(有关测试文档的问题),测试文档中没有说明的问题

·   从概要和详细设计文档(软件设计,代码和复杂的数据)中导出的对软件复杂性和模块路径覆盖的理解

输出:

·   设计时发现的问题反馈给开发人员(软件设计,代码问题)

·   已批准的测试场景,条件和脚本(测试设计,用例和脚本)

·   测试数据

过程:

·   通过复审发布版本的功能需求和准备能够更好的拆分为测试脚本的业务功能逻辑集合,准备测试场景和用例。测试将定义为测试条件,用于测试的数据和期望的结果(数据库更新,文件输出,报告结果等等)。将可能在应用程序中出现的既普通又异常的情况描绘为测试场景。

·   项目开发人员将定义单元测试需求和单元测试的场景/用例。在集成和系统测试之前,开发人员同时也负责执行单元测试用例。

·   在开发人员和客户的协助下,测试小组将开发集成和系统测试的测试场景、用例。验收测试用例将由客户在项目和测试小组的帮助下开发。

·   通过使用测试脚本执行测试场景。脚本将定义用于执行一个和多个测试场景的一系列步骤。测试脚本通常描绘在一般的系统操作中会出现的事务或过程。测试脚本包括用于测试过程或事务的特定数据。测试脚本将覆盖多个测试场景并且包括运行/执行/周期信息。测试脚本映射需求和用于保证任何测试都是在范围内的追溯矩阵。

·   在测试之前,捕捉并且基线化测试数据。这些数据将作为单元和系统测试的基础和在可控的环境下执行系统功能。为了以后的对照,一些输出的数据也被基线化。在回归测试时,基线化的数据用于支持以后的系统维护。

·   为评定应用程序的就绪情况、环境和被测试的数据,应召开测试准备会议。为了指出发本版本的入口标准状态,应创建测试就绪文档。

三、执行测试

输入:

·    已批准的测试文档(测试计划、用例、程序)

·    如果适用测试工具,自动化测试软件和编写好的脚本

·    设计的变更(变更请求)

·    测试数据

·    测试和项目组的可用性(项目人员,测试小组)

·    概要和详细设计文档(需求,软件设计)

·    通过配置/构建人员能够完全转移到测试环境(单元测试过的代码)的开发环境

·    测试就绪文档

·    修订文档

输出:

·    代码的变更(测试修复项)

·    作为一种测试的结果(测试文档问题),测试文档没有说明的问题

·    设计时发现的问题,反馈给开发人员和客户(需求,设计,代码问题)

·    测试事故的正式记录(问题跟踪)

·    为向下一级别转移而准备的基线化包(已测试的源代码和对象代码)

·    测试结果的日志和总结

·    已批准和带有修订测试交付项的签署文档(已更新的交付项)

过程:

·    在执行阶段中应召开Checkpoint 会议。(如果由需要,)每天应召开Checkpoint 会议处理和讨论测试中的问题,状态和活动。

·    通过采用系统的手段跟进测试文档来完成测试的执行。当执行测试程序的每一个包时,为了记录程序的执行和测试程序找出的任何缺陷,应该将问题记录到测试执行日志中。测试程序执行后的输出当作测试结果。

·   为了确定是否可以得到预期的结果,测试结果应该由适当的项目组员评估(,适合于测试的所有级别)。记录并和软件开发经理/程序员讨论所有差异/异常,为了以后的调查和解决应该将它文档化(每个客户可能有不同的记录日志和报告bug/defect的过程,通过Configuration Management (CM)小组校验这些过程)。通过/失败的准则用来确定问题的严重级别,结果记录到测试总结报告中。

·   根据客户的风险评估来定义在系统测试中发现的问题严重级别并记录到他们选择的跟踪工具中。

·   基于问题的严重级别有目的的修复并提交到测试环境中。被修改的问题应进行回归测试并将没有问题的修复项转移到新的基线中。在测试完成后,测试组的成员应准备一份总结报告。总结报告要由项目经理,客户,SQA和/或测试组长复审。

·   在证实达到一个指定的测试级别后,配置经理应根据配置管理计划中的要求整理发布的软件组件并转移到下一个测试级别。软件只有在客户正式验收之后才可以转移到生产环境中。

·   测试小组在复审测试和更新的文档中发现的测试文档的问题。有些问题可能是由于技术性和功能性之间的不一致或修改所造成的。

软件测试理论你知道多少?

软件开发和使用的历史已经留给了我们很多由于软件缺陷而导致的巨大财力、物力损失的经验教训。这些经验教训迫使我们这些测试工程师们必须采取强有力的检测措施来检测未发现的隐藏的软件缺陷。

生产软件的最终目的是为了满足客户需求,我们以客户需求作为评判软件质量的标准,认为软件缺陷( Software Bug )的具体含义包括下面几个因素:

☆ 软件未达到客户需求的功能和性能;

☆ 软件超出客户需求的范围;

☆ 软件出现客户需求不能容忍的错误;

☆ 软件的使用未能符合客户的习惯和工作环境。

考虑到设计等方面的因素,我们还可以认为软件缺陷还可以包括软件设计不符合规范,未能在特定的条件(资金、范围等)达到最佳等。可惜的是,我们中的很多人更倾向于把软件缺陷看成运行时出现问题上来,认为软件测试仅限于程序提交之后。

在目前的国内环境下,我们几乎看不到完整准确的客户需求说明书,加以客户的需求时时在变,追求完美的测试变得不太可能。因此作为一个优异的测试人员,追求软件质量的完美固然是我们的宗旨,但是明确软件测试现实与理想的差距,在软件测试中学会取舍和让步,对软件测试是有百益而无一弊的。

下面是一些软件测试的常识,对这些常识的理解和运用将有助于我们在进行软件测试时能够更好的把握软件测试的尺度。

☆ 测试是不完全的(测试不完全)

很显然,由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素,哪怕是一个极其简单的程序,要想穷尽所有逻辑路径,所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子,比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我们将整个正整数域的数字进行一番测试的话,从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的,即便某一天我们能够穷尽该程序,只怕我们乃至我们的子孙都早已作古了。为此作为软件测试,我们一般采用等价类和边界值分析等措施来进行实际的软件测试,寻找最小用例集合成为我们精简测试复杂性的一条必经之道。

☆ 测试具有免疫性(软件缺陷免疫性)

软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ,测试人员对其采用的测试越多,其免疫能力就越强,寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的,则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。照此推算,软件存在 500 个缺陷时,我们查找一个软件缺陷需要 X 小时,当软件只存在 5 个错误时,我们每查找一个软件缺陷需要 100X 小时。实践证明,实际的测试过程比上面的假设更为苛刻,为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷,因此软件测试应该尽可能的多采用多种途径进行测试。

☆ 测试是 “ 泛型概念 ” (全程测试)

我一直反对软件测试仅存在于程序完成之后。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话,需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷,记住 “ 软件缺陷具有生育能力 ” 。软件测试应该跨越整个软件开发流程。需求验证(自检)和设计验证(自检)也可以算作软件测试(建议称为:需求测试和设计测试)的一种。软件测试应该是一个泛型概念,涵盖整个软件生命周期,这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估(信息系统审计和软件工程监理),即测试本身也应当被测试,从而确保测试自身的可靠性和高效性。否则自身不正,难以服人。

另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件,软件测试是提高产品质量最直接、最快捷的手段,但决不是一个根本手段。
☆ 80-20 原则

80% 的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们,如果你想使软件测试有效地话,记住常常光临其高危多发 “ 地段 ” 。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。

80-20 原则的另外一种情况是,我们在系统分析、系统设计、系统实现阶段的复审,测试工作中能够发现和避免 80% 的软件缺陷,此后的系统测试能够帮助我们找出剩余缺陷中的 80% ,最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷,却无法保证能够发现所有的软件缺陷。

80-20 原则还能反映到软件测试的自动化方面上来,实践证明 80% 的软件缺陷可以借助人工测试而发现, 20% 的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分,因此尚有 5% 左右的软件缺陷需要通过其他方式进行发现和修正。

☆ 为效益而测试

为什么我们要实施软件测试,是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价值和意义。一般说来,在软件测试中我们应该尽量地保持软件测试简单性,切勿将软件测试过度复杂化,拿物理学家爱因斯坦的话说就是: Keep it simple but not too simple 。

☆ 缺陷的必然性

软件测试中,由于错误的关联性,并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的软件缺陷。很多软件缺陷之间是相互矛盾的,一个矛盾的消失必然会引发另外一个矛盾的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何况在缺陷的修复过程中,我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围,选择一个折中的方案或是从非软件的因素(比如提升硬件性能)考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。

☆ 软件测试必须有预期结果

没有预期结果的测试是不可理喻的。软件缺陷是经过对比而得出来的。这正如没有标准无法进行度量一样。如果我们事先不知道或是无法肯定预期的结果,我们必然无法了解测试正确性。这很容易然人感觉如盲人摸象一般,不少测试人员常常凭借自身的感觉去评判软件缺陷的发生,其结果往往是把似是而非的东西作为正确的结果来判断,因此常常出现误测的现象。

☆ 软件测试的意义 - 事后分析

软件测试的目的单单是发现缺陷这么简单吗?如果是 “ 是 ” 的话,我敢保证,类似的软件缺陷在下一次新项目的软件测试中还会发生。古语说得好, “ 不知道历史的人必然会重蹈覆辙 ” 。没有对软件测试结果进行认真的分析,我们就无法了解缺陷发生的原因和应对措施,结果是我们不得不耗费的大量的人力和物力来再次查找软件缺陷。很可惜,目前大多测试团队都没有意识到这一点,测试报告中缺乏测试结果分析这一环节。

结论:

软件测试是一个需要 “ 自觉 ” 的过程,作为一个测试人员,遇事沉着,把持尺度,从根本上应对软件测试有着正确的认识,希望本文对读者对软件测试的认识有所帮助。