2009年06月01日

1. 黑盒、白盒、灰盒测试方法的优缺点,适用范围分别是什么?分别举例进行说明。

白盒测试

优点:

● 迫使测试人员去思考软件的实现;

● 可以检测代码中的每条分支和路径;

● 揭示隐藏在代码中的错误;

● 对代码的测试比较彻底;

● 最优化。

缺点:

● 昂贵;

● 无法检测代码中遗漏的路径和数据敏感性错误;

● 不验证规格的正确性。

黑盒测试

优点:

● 对比较大的代码单元来说,黑盒测试比白盒测试效率要高;

● 测试人员不需要了解实现的细节,包括特定的编程语言;

● 测试人员和编码人员是彼此独立的;

● 从用户的视角进行测试,很容易被理解和接受;

● 有助于暴露任何规格不一致或者有歧义的问题;

● 测试用例可以在规格完成之后马上执行。

缺点:

● 只有一小部分可能的输入被测试到,要测试每个可能的输入流几乎是不可能的;

● 没有清洗的和简明的规格,测试用例是很难设计的;

● 如果测试人员不被告知开发人员已经执行过的用例,在测试数据上会存在不必要的重复;

● 会有很多程序路径没有被测试到;

● 不能直接针对特定程序段测试,该程序段可能隐藏更多错误;

● 大部分和研究相关的测试都是直接针对白盒测试的。

灰盒测试

介于黑盒和白盒测试之间的一种测试。

2. 静态、动态测试方法的优缺点,适用范围分别是什么?分别举例说明。

静态方法是指不运行被测程序本身,仅通过分析或检查源程序的文法、结构、过程、接口等来检查程序的正确性。静态方法通过程序静态特性的分析,找出欠 缺和可疑之处,例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的 查错,并为测试用例选取提供指导。

动态方法是指通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率和健壮性等性能,这种方法由三部分组成:构造测试实例、执行程序、分析程序的输出结果。

3. 手工、自动化测试方法的优缺点,适用范围分别是什么?分别举出实例进行说明。

手工测试方法能够发现更多的缺陷,测试设计不会遗漏问题。

缺点:测试重复频繁的测试,效率低,完全一致性得不到保证。

自动化测试方法的优点:

1、对程序的回归测试更方便。由于回归测试的动作和用例是完全设计好的,期望的结果也是可以预料的,自动运行何以提高测试的效率,缩短测试的时间;

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

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

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

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

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

自动化测试的缺点:不能取代手工测试,只能提高测试的效率,不能提高测试的有效性,不能发现更多的缺陷,对测试设计的依赖性大,不能保证正确性,工具不具有想象力,不具有智能。

使用于:智力含量低,反复频繁重复时,版本相对稳定时,项目中的技术能力达到,有代码编码能力时,进度允许时。

本文转载自:http://www.spasvo.com/html/ceshi/20090518-906.html

1. 以各种借口拒绝单元测试Unit Test,比较常用的是“你没有足够的时间(进行单元测试)”。

2. 尝试单元测试并且立刻开始在自己的博客商鼓吹单元测试和测试驱动开发Test Driven Development的好处。

3. 单元测试一切。为了能够完成单元测试,而将私有private的方法和属性修改为内部internal;为了达到单元测试覆盖率100%而测试getter() 和 setter() 属性(方法)。

4. 无法忍受脆弱的单元测试,在没有弄明白是什么的时候,就匆忙转向“集成测试" integration test。

5. 发现了一种模拟 mocking 框架,并且乐于使用强制语义(strict semantics)。

6. 模拟mock所有可能模拟mocked的对象。

7. 开始真正有效单元测试。

本文转载自:http://www.spasvo.com/html/ceshi/20090519-907.html

2009年03月26日

我们在工作中执行自己的测试用例,没有什么障碍,自己写的,一看就明白是怎么回事。但有时执行别人写的用例时,我们可能就不知所措了,一方面可能不知道该用例检查的是什么功能点,另一方面看到测试用例不知道该怎么去执行,另外大家写作的风格不同,也就会在看与自己风格不同的用例觉得不舒服。

测试用例是指导我们的测试,它的可读性、可操作性非常重要。我们需要的是一看到测试用例,就知道它是测试什么功能点的,并且每个步骤都是可操作的,不希望出现“用户输入很长的名字”这样的描述。

对于测试用例的编写提一些个人的建议。

1、功能划分时,一定要简单、清晰,一个测试用例集就只需要检查一个功能模块。如果包含的功能点太多,会让我们的测试用例比较混乱,降低了可读性。

2、测试用例的划分也要单一,一个测试用例只检查功能点的一种情况。一个用例检查的情况太多,会导致用例的目的不清晰,而且这样组织用例,有利于需求覆盖率的统计。一个功能点我们测试了那些情况,以及哪些功能点我们在重点测试,一目了然。

3、测试用例要有一个简单的目的描述,有助于读者对测试用例的理解。

4、测试用例要有明确的执行前提,包括环境,数据,场景。

5、测试用例的步骤描述要简单、清晰,一步就是一步。比如:第一步,用户登陆;第二步,用户点击“用户信息”;第三步,用户修改姓名为“张&三”;第四步,用户点击保存。这有利于提高用例的可操作性。

6、测试用例的数据要明确,特别是前提数据和要检查的数据。比如,测试准备数据:用户:张三,李四,王二。在排序后用例的预期结果为:李四,王二,张三。这样,用例在执行时,很清晰,有很高的可操作性,执行者对于执行结果是否正确也非常清楚。

提出一些个人的经验、建议,考虑的不是很全,希望大家提出意见和补充。

本文转载自:http://www.spasvo.com/html/ceshi/20090319-804.html

by Mikhail Rakhunov SQAtester.com contributor

1. Test early and test often.

2. Integrate the application development and testing life cycles. You’ll get better results and you won’t have to mediate between two armed camps in your IT shop.

3. Formalize a testing methodology; you’ll test everything the same way and you’ll get uniform results.

4. Develop a comprehensive test plan; it forms the basis for the testing methodology.

5. Use both static and dynamic testing.

6. Define your expected results.

7. Understand the business reason behind the application. You’ll write a better application and better testing scripts.

8. Use multiple levels and types of testing (regression, systems, integration, stress and load).

9. Review and inspect the work, it will lower costs.

10. Don’t let your programmers check their own work; they’ll miss their own errors.

本文转载自:http://www.spasvo.com/html/ceshi/20090318-801.html

2009年03月23日

实施自动测试的目标和意义

1)对于功能已经完整和成熟的软件,每发布一个新的版本,其中大部分功能和界面都和上一个版本相似或完全相同,这部分功能特别适合于自动化测试, 从而可以让测试达到测试每个特征的目的。

2)每日测试的高效率。DCC版本的发布周期往往比较短,也就是开发周期只有短短的几个月,而在测试期间是每天/每2天都要发布一个版本供测试人员测试,一个系统的功能点有几千个上万个,人工测试是非常的耗时和繁琐,这样必然会使测试效率低下。

3)具有一致性和可重复性。由于每次自动化测试运行的脚本是相同的, 所以每次执行的测试具有一致性, 人是很难做到的. 由于自动化测试的一致性,很容易发现被测软件的任何改变。

4)更好的利用资源--周未/晚上。理想的自动化测试能够按计划完全自动的运行, 在开发人员和测试人员不可能实行三班倒的情况下, 自动化测试可以胜任这个任务, 完全可以在周末和晚上执行测试. 这样充分的利用了公司的资源,也避免了开发和测试之间的等待。

5)解决测试与开发之间的矛盾。通常在开发的末期,进入集成测试阶段, 由于每发布一个版本的初期,测试系统的错误比较少,这时开发人员有等待测试人员测试出错误的时间. 事实上在叠代周期很短的开发模式中,存在更多的矛盾, 但自动化测试可以解决其中的主要矛盾。

6)将烦琐的任务转化为自动化测试。大量重复的测试是非常繁琐的,并且需要消耗大量的人力才能够完成。自动测试能够很好的解决这个问题,不需要繁琐的劳动,不需要大量的人员。

7)增加软件信任度。只有经过大量测试案例测试过的版本才是可靠的,而只有使用自动测试才能够保证在段时间内完成大量的测试案例。

自动测试无法完全代替手工测试

1)不能期望自动化测试去发现更多新的缺陷, 事实证明新缺陷越多,自动化测试失败的几率就越大。发现更多的新缺陷应该是手工测试的主要目的。测试专家James Bach总结得 85%的缺陷靠手工发现,而自动化测试只能发现15%的缺陷。

2)工具本身不具有想象力

工具毕竟是工具,出现一些需要思考、体验、界面美观方面的测试,自动化测试工具无能为力。

3)美观、声音、易用性测试,无法使用自动测试。人的感观方面的:界面的美观、声音的体验、易用性的测试,也只有人来测试。

4)测试很少运行:一个月只运行一次。测试很少运行,对自动化测试就是一种浪费。自动化测试就是让它不厌其烦的、反反复复的运行才有效率。

5)软件不稳定。软件不稳定,则会由于这些不稳定因素导致自动化测试失败。只有当软件达到相对的稳定,没有界面性严重错误和中断错误才能开始自动化测试。

6)涉及物理交互。工具很难完成与物理设备的交互,比如刷卡的测试、打印数据(检查打印格式是否正确)等。

本文转载自:http://www.spasvo.com/html/ceshi/20090316-795.html

获取正确的信息对于很多公司来说都是挑战,而且即使你获得了所需要的文档,但是缺乏你真正需要的信息。我曾经看到过大量的不同质量程度的文档(从优秀的到不可用的),但是我喜欢项目在两个不同的阶段有两种不同的方式组合。

一开始,项目使用XP的方式开展,系统从零开始构建,而我作为测试人员就整天与开发人员和项目主管呆在一起。在那段时间,我学到了关于系统的所有东西,包括内部的细节,即使没有什么文档。

在软件提交给客户后,项目组到了第二阶段,我们从XP转移到更传统的方式,开发人员和BA(业务分析员)写一些粗略的说明书。在初始版本构建完成后,我获得了发布的记录,里面记录了由BA和开发人员写的背景信息。

虽然我在后期阶段才介入,但是接下来的阶段都只有很少的特性被加入,所以我仍然能够很好地工作,因为阅读这些发布记录就已经足以让我了解清楚扩展了什么东西,我应该寻找哪些方面的bug。

在另外一个项目,我是个开发人员,我们只有少得可怜的文档,但是我们会邀请目标用户每隔六周过来用一整周的时间测试我们的系统。在那段时间里,我们每天都修正bug并且讨论哪些功能特性需要在下个迭代周期加入。那个产品的质量出奇的好,而在那个时候RUP和XP对于我们来说还是个未知的名词。

在另外一个项目,我一开始就得到很糟糕的文档,还有不可用的发布记录。开发人员工作在另外一个国家。BA和项目主管忙着在全世界推销正在开发的软件,测试人员则努力尝试弄清楚系统要做什么。

功能测试在几个分开的邮件中有解释,但是有时候内容是互相矛盾的。

在这种没有文档或文档很糟糕的情况下,我通常倾向于请开发人员演示功能特性,而不会强迫他们去写只会包含部分需求信息的糟糕的文档。

这些项目经验告诉我,与其过分关注需求文档,倒不如让项目组的所有成员都紧密地工作在一起,确保你得到成为所测试系统的领域软件测试专家需要的信息。我也同意这种方法可能在航空领域和医疗行业不那么容易生效。

本文转载自:http://www.spasvo.com/html/ceshi/20090317-798.html

2009年03月17日

2009年悄悄地来到了,送走了艰难的、折腾的2008年。人们对2009年会充满更多的期望,9是一个吉祥的数字,天长地久,而且农历是牛年,牛年更牛。

到了2009年,该为软件测试写点什么。顺民意,预测一下2009年国内软件测试的十大热点。

1. 基于云的测试将是新的课题,包括测试方法、技术和工具。而且,云环境下的测试也是减少测试成本的一个途径。

2. 基于Web 2.0/Ajax 的软件测试技术还是热点。Java/Javascript技术变化很快,系统开发框架也是层出不穷。

3. 软件测试自动化也还是热点,包括更多的开源测试工具、自动化测试模型和框架、自动化测试的理论研究等。

4. 移动测试:移动计算、移动应用用来,包括3G的应用,移动测试(包括无线应用系统的测试)将会受到更多的关注,是测试的一个新的增长点。

5. 虚拟技术(如Citrix、微软、VMware的产品)的日益普及,越来越多的测试团队会将虚拟技术应用于测试环境创建、维护和优化,甚至是测试的执行。

6. 安全测试:软件系统安全形势更加严峻,对安全测试会提出更高的要求,软件工具厂商会推出更多的安全测试工具。

7. 软件外包测试:中国软件外包迎来发展良机和挑战,大型的软件外包企业发展更快,小的软件外包企业困难增大、被兼并的可能性增大,软件测试在外包企业得到更好的发展。

8. 测试培训:软件测试培训的竞争将更加激烈,无论宣传还是市场争夺,将会进入白热化的地步。ISTQB将成为2009年国内培训市场的一颗新星。

9. 课程与图书:有越来越多的大学,为研究生和本科生开设“软件测试”课程。软件测试的图书在2008年很热,在2009年热度,可能依旧不减。

10. 测试会议和沙龙:全国性或国际性的软件测试会议会成为新的热点之一,软件测试的沙龙越来越多。

本文转载自:http://www.spasvo.com/html/ceshi/20090309-786.html

实践证明,测试行为并不是游击战,不能指到哪里打到哪里。如同我们修路一样,贯穿几千公里的高速路,可能分若干个工地同时施工,只要前期规划好了路线和其他的标准,就不用担心工程不能很好的对接。我想这种点面结合的施工方法同样适合我们的测试工作。

所谓的点就是某个重要的测试阶段,比如单元测试阶段,系统测试阶段,或者阶段中的阶段,比如制定测试计划和测试方案。所谓的面就是质量管理模型,在这个模型中除了有测试实施的过程,还定义了所有的点的具体标准和行为。

比如我们这个模型是这样的:

需求—规格设计说明书—开发需求—单元测试—-集成测试—-系统测试—-验收测试(上线)

那么这些不通的阶段就是点。其中需求影响这以后的各个阶段,建立起一套规范的需求管理,来指导并约束后续阶段的工作,这就是面。那么如何做好需求管理呢,一方面是做好需求采集,与之有关的人员有市场,客户,产品部门,以后可能研发测试人员也会有新需求或需求改进的提议。不通较色提的需求可能有很大差别,市场人员偏中业务对市场的占有率,因此他们希望新产品有功能独特,新,并且能尽早投入市场,占得先机;客户则注重个人体验,他们会提一些对自己很适用的需求,我们就要来筛选那些是有效需求。(功能越强大越好吗?有些用户可能只用到其中的1/3功能,他就会觉得有2/3的付费是浪费的,这就是质量管理中的心理学。所以说,有效的需求是能满足大部分用户需要的需求);来自开发测试人员的需求可能会偏重技术,我们要分析这是不是由于原始需求不当引起的。

同样,我们要有一份原始需求说明书作为这个阶段的输出。

对于后续阶段的规格说明书,是根据这个需求制定的,在这个阶段的工作基本类似(其他阶段也是一样),即保证此阶段集成了上阶段正确的成果,保证这阶段的工作是对现阶段的正确解读,保证此阶段的输出成果是正确并且是下阶段所需要的。

好了,点面模型的思路就是这样的,至于每个点怎么来建设,仁者见仁,智者见智吧。

本文转载自:http://www.spasvo.com/html/ceshi/20090311-790.html

2009年03月13日

1、搭建独立的软件测试环境有利于重现开发环境无法重现的BUG。这样说也许会显得抽象,我们不妨举个简单的例子来说明:某个软件系统由模块A、B、C组成(对应开发人员A、B、 C)。起初开发人员比较偷懒,不想重新搭建独立的测试环境(特别是搭建过程比较复杂的情况下),而是让测试人员连到他们各自的开发机器上分别测试他们各自负责的模块。各自的模块功能很正常,但一旦整合作为一个系统向用户提供功能时,就不一定正常了,有可能在模块A录入的数据在模块B查询不到,或是模块间的接口有问题等。除此以外,还可能有其他因素妨碍开发环境重现BUG。总之,搭建一个与典型用户环境配置一致的测试环境是有效测试的重要前提。

2、搭建独立的测试环境便于开发人员并行地修复BUG。如果对开发环境进行测试,开发人员要修复BUG必须先重现BUG,然后修改相关代码,并进行程序调试。而在测试人员还未测试完系统前,开发人员是不能对程序进行修改、更新。只有等测试人员测试完后才能进行BUG修复(现实中也有这样的情况:测试员还未测试完开发人员就更新修复部份BUG的程序。这种做法比较危险,开发人员若修复得不好可能会导致程序无法运行,势必影响测试进度)。串行的工作方式也很耗费时间,甚至影响进度。正确的做法应该搭建独立的测试环境,测试人员提出BUG后开发人员在开发机上重现并修复,并验证修复后的效果,两种环境互不干扰。

3、搭建独立的测试环境可以验证安装软件的全过程。即进行安装测试,用以检查安装文件是否有错漏,软件在指定的操作系统下能否正常安装,各种配置项是否有错漏等。

4、搭建独立的测试环境可以避免环境被破坏导致测试无法进行的意外。如果选择开发环境来进行测试,开发人员进行某项误操作后发生系统崩溃或者系统不能正常运行的意外,此时测试工作也不得不停止。
本文转载自:http://www.spasvo.com/html/ceshi/20090310-789.html

白盒测试技术中的逻辑覆盖

一个或者多个条件组成一个判定,一个程序中可以有多个判定。

首要的是建立一个二维的真值表,各列为判定和条件,各行为每组值的T或者F。

1、语句覆盖

为了暴露程序中的错误,至少每个语句应该执行一次。

这也是最弱的逻辑覆盖标准咯。

2、判定覆盖

每个判定的每种可能结果都要执行一次。

建立判定表以后,要保证每种判定的结果中都包含了T和F,才满足判定覆盖。

3、条件覆盖

不但每个语句需要执行一次,而且判定表达式中的每个条件都要取到可能的结果。

建立判定表以后,要保证每种条件的结果中都包含了T和F,才满足条件覆盖。

4、判定/条件覆盖

使得每个判定以及每个判定中的每个条件都取到可能的结果。

建立判定表以后,要保证每个判定结果包含T和F,而且每种条件的结果包含T和F。

也就是综合了上面的条件覆盖和判定覆盖。

5、条件组合覆盖

使得每个判定中的条件的各种组合至少出现一次。

也就是说,先把程序中的条件列出来,排列组合,写出所有的可能性,看有没有那组值同时满足这些排列组合。

6、路径覆盖

每条可能的路径都至少执行一次。

就是看源程序中的判断,都有哪些组合,比如T ,FF,FT,等等,看看哪个满足包含了所有的组合。

因为这些不同的组合就代表了程序中执行的不同路径。

】本文转载自:http://www.spasvo.com/html/ceshi/20090305-782.html