发布新日志

  • 怎样度量测试的有效性

    2008-01-13 16:54:40

    Webinar by Rick Craig

    一些常见的衡量标准:

    • 测试中发现的缺陷数
    • 客户发现的缺陷数(分析:80-20分析:对缺陷类型按缺陷个数排序,找出客户发现的最多的20%的缺陷类型--分析客户的关注点是什么?为什么客户能发现这些类型的缺陷,为什么我们没有测试出来?定义改进措施)
    • 客户满意度调查
    • 覆盖率:代码覆盖率、设计覆盖率(可以保证代码与设计相一致、但不能保证需求的正确性)、需求覆盖率(有助于测试设计、可用来度量测试状态、不依赖于代码)
    • 缺陷严重程度、分布情况(80-20分析:对所有模块的缺陷密度进行排序比较,找出缺陷密度最大的20%模块--找出质量最差的模块,采取改进措施)、存在时间、密度
    • Help Desk的求助数

    Defect Removal Efficiency(DRE)=

    Defects found in Testing/(Defects found in Testing + Defects found by Customer)*100%

    这种度量方法的缺陷在于,我们并不知道到什么时候为止客户发现了所有的缺陷;并且它仍然需要考虑严重程度和分布情况的权重

     

  • Five Basic “Stopping” Criteria

    2008-01-13 16:28:01

     By Lee Copeland

    • You have met previously defined coverage goals
    • The defect discovery rate has dropped below a previously defined threshold
    • The marginal cost of finding the “next” defect exceeds the expected loss from that defect
    • The project team reaches consensus that it is appropriate to release the product
    • The boss says, "Ship it!"

  • Webinar--An Introduction to Testing on Agile Projects笔记

    2008-01-13 14:55:09

    by Antony Marcano

     

    Practices people usually mention when they think of Agile:

    l        Test-Driven Development

    l        Extreme Programming

    l        SCRUM

    l        Unit Test, Design Patterns

    l        User Stories

    Doing these practices doesn’t necessarily make you Agile

     

    Manifesto for Agile Software Development

    l        Individuals and interactions over processes and tools

    l        Working software over comprehensive documentation

    l        Customer collaboration over contract negotiation

    l        Responding to change over following a plan

     

     

    Tests are used to

    l        Elicit & clarify requirements

    l        Drive & clarify design

    l        Enable rapid & inexpensive change

    l        Prove feedback that…

    n        Elicit & clarify requirements… and so on

     

    Instead of measuring progress in bug-metrics, measure progress in Working Software!

    Instead of testing outside the iteration, make sure it’s good-enough by the end of the iteration

  • "迭代测试的21个谬论和事实"节选

    2008-01-08 22:27:51

    原作者:Laura Rose  

        谬论:当代码设计的时间超过了时间表的计划,降低测试的时间可以帮助我们重新回到时间表的计划上。
      事实:一般情况代码设计的延误是由于未预料到的困难或者没有按照最开始的设计工作。当我们发现我们低估了项目的复杂性的时候,缩短测试时间是一个糟糕的决定。相反,我们应该保证测试的执行,因为测试的结果是建立在我们低估代码设计的情况上的,测试的效果或许也会被低估。因此我们需要定制更多的测试时间来更正开始的判断,而不是减少测试时间。
      迭代测试增加了测试时间但是并没有延误整个的时间进度,因为在每一个迭代过程中测试过程都是提前开始的。同样,产品的质量决定了需要测试的数量——而不是由时间决定的。例如,如果产品是可靠的,在很多领域都没有发现缺陷,并且测试进行的十分顺利,那么你可以在保证测试数量和测试覆盖率的前提下降低测试的时间。如果产品不够稳定,发现了很多缺陷,那么你需要增加测试的周期直到达到质量标准。请记住,测试并不是项目最耗时的工作。

  • 缺陷跟踪系统中隐藏的信息

    2007-12-24 12:00:12

    来自Dan Minkin
     Hidden Messages, SkickyMinds.com

    翻译:iloveyouso

    缺陷描述和开发人员的注释

    测试人员五花八门的缺陷描述至少说明了几件事情。一是说明了哪些是有经验并且非常自信的测试人员,哪些不够自信。二是说明了哪些模块经常引起错误,以致在字面上很容易看出来,像“开发人员显然可以看到……”“这已经是第三次……”这样的话。这样也可以增加对于某些功能模块存在高风险的判断的把握。

    同样的,开发人员的回复和之后的辩论也能反映出开发人员同测试人员的关系。从语言上能够看出来他们的关系不像所设想的那么好。回复的数量经常是3、4或者5个来回说明或者是缺陷解决的流程没能很好的工作,因此开发团队和测试团队需要改进交流、或者是关于需求还存在一些不明确的地方。

    哪些字段被使用?说明测试人员是否把重点放在了正确的事情上?

    在填写业务上的严重程度的时候比测试的优先级更准确说明了测试人员把重点放在了业务上而不是测试的影响,因此他们的重点对于他们应该扮演的角色来说有时会显得过于狭隘。另一个有趣的现象是在填写功能区域这个字段时,有的测试人员总是填写相同的内容而不是用这个字段来标识一个缺陷是在哪个功能中被发现的。和这些测试人员讨论之后发现他们不理解自己所测试的部分对应着整个的测试工作中的哪个部分。结果,我们用了一些时间对这些测试人员进行培训。

    在我们询问为什么测试参照这个字段很少被使用的时候,我们发现了一个有用的信息:大部分的缺陷是在探索性的测试中被发现的,而不是遵循测试脚本。这一点从一个侧面揭示了外包商测试质量的问题。外包商使用我们提供的测试脚本测试他们的软件(以一种死板、不正确的方式),没有试图做一些操作让软件发生问题。这一点是这个项目一个非常关键的发现。作为改进,我们增加了两个中间阶段的测试,一个针对供应商的测试,另一个针对用户测试。

    小结:

    通过缺陷管理工具查找缺陷数据的时候,下面的几个问题会帮助你了解更多的信息:

    • 我是否已发现了缺陷描述中的主观的部分?工具是否如设想的那样成功的工作?如果没有,为什么?
    • 缺陷字段的选择和使用是否对测试流程是有正面意义的?
    • 谁对工具产生的数据感兴趣?
    • 有没有缺陷报告所没有包含的内容?
    • 缺陷的历史记录是否对于测试流程有作用?
  • The QA Catchall

    2007-12-14 21:31:43

    by Alan S. Koch  Better Software, 译者:iloveyouso

    测试不是QA

    Technical Review不是QA

        在一个QA组织里,可以从下面步骤开始。它们相对容易实现,并且能够实实在在地为质量改进带来好处

    • Agree on common patterns.

    可以考虑计划、规约、代码、用户界面、文档、培训材料或任何其他工件的标准。但同时应当指出它们在什么情况下被应用,并且提供关于如何在必要时对它们进行裁剪的指导。

    • Define consistent practices.

        通常,人们对流程有意识,是因为流程让他们感觉到痛苦。例如,流程可能影响到协作、项目涉众的关系、或某种程度上不能满足团队的需要。也许有人会说“我从来没有碰到一个我喜欢的流程”,这个人很可能使用了很多很好的流程但他自己没有意识到。

        如果不能恰如其分并且贯彻执行大家都认为是对的事情,那么好的流程的价值就丢失了

    • Ensure that standards and processes are used.

        如果发现一个被接受的标准、流程被忽略的时候,值得研究和跟进,因为可能有不同的原因导致这种情况发生,例如:

      •     这个人只是忘记遵循流程和标准。提醒他
      •     这个人不知道标准和流程,或者不知道如何使用它。 改进你的交流和培训方法
      •     标准或流程不适合手上的特定工作。 重新评估裁剪的指导或替代办法
      •     标准或流程对当前情况不够有效或过于累赘。 简化它,让它在满足需求的同时,不会成为障碍

        所有对标准或流程的违背都是一次很好的研究和改善它以便更好地满足团队需要的机会。

    • Hold project retrospectives.

        关键的问题是:哪些地方做的很好,将来我如何复制这些成功;哪些地方做错了,将来我如何避免它。

        敏捷方法推荐在项目的过程中经常地做一些回顾,而不是在项目结束的时候简单地做一次回顾。这样做的好处是:

      •     项目成员都能找到,因为他们都还在这个项目上
      •     类似一个月左右一个阶段的研讨会较容易安排,因为只需要一两个小时,而不是一整天或更长时间
      •     团队成员的经验在他们脑中仍然是“新鲜”的,所以讨论中更容易把所有的经验都包括进来
      •     更重要的是,你可以在项目的余下的时间里把总结出的经验应用上去。
    • Analyze and learn from defect data.

        对于质量改进有用的缺陷数据包括:

      •     什么地方出错了?这不是指症状,而是必须修复的问题所在。例如,“死循环”是一个症状,而“对循环指针步进”是问题所在。
      •     问题是什么时候引入的?问题的根源在开发的具体哪一个阶段?是需求分析的问题么?系统设计阶段?编码?测试?(的确,我们在测试阶段修复缺陷的时候会引入其他的问题)
      •     问题是什么时候被发现的?也许这个缺陷不会立即被修复,但是我们关心的是它在被发现之前存在多久了。
      •     问题是如何被发现的?这个可以成为今后的一个指导性的实践。
      •     这个缺陷的代价是多大?这个数字很可能被低估。确保你考虑到了所有必需的诊断和返工的工作量,包括重新设计、重新编码、重新编译、重新构建、重新测试、重新发布、打补丁、管理缺陷报告、更新状态等等(别忘了无形的代价比如市场上的阻碍)
      •     这是什么类型的问题。

        分析了缺陷数据之后,找出那些经常发生以及代价很大的缺陷,它们是你今后要避免(或至少要尽早发现)的,因为把握好了这些将对质量产生重大的提高和改进。

    • Apply what you learn.

        项目的初始阶段必须包括对之前项目的学习研究。看看过去学到的经验和以前的缺陷历史数据,想想这个项目如何做的和以前的不一样。如果要达到比以前更好的质量,需要做些什么?这必须是项目起始阶段一项明确的任务,否则很容易在开始新项目的匆忙中被忽视。

        质量保证主要是一个学习的过程:学习哪些地方没有做好、如何改进;学习哪些流程工作的很好、它们适用的环境、让它们成为规程;学习对于你承担的每一个项目,如何做的更好。

        任何一个有质量保证的组织都是一个学习型组织,第一步就是如何让质量保证成为工作的一个正常部分。


  • 缺陷的属性

    2007-12-12 15:08:38

        如何完整全面地描述一个缺陷?提交缺陷的时候涉及到哪些属性?我们都用过各种不同的缺陷跟踪工具,它们大多数支持定制的功能。那么,怎样的缺陷描述是比较合理完整的?

        大多数的缺陷报告包括下面一些属性:

    Summary(缺陷摘要):用一句话概要地描述缺陷的现象

    Descrīption(缺陷描述):详细的描述缺陷重现的环境、前置条件、步骤、期望结果、实际结果等。

    owner/assignee(指定的负责人):通常是负责修复该缺陷的开发人员,在有的系统中也支持开发人员修复好缺陷修改其在缺陷跟踪系统中的状态后把它指定(assign)给相关的测试人员。

    status(状态):缺陷当前的状态,常见的分类有open/fixed/closed,有些系统还在open状态之前加上一个submitted状态,表示只是提交了缺陷,可能还需要确认之后才算正式的open的缺陷。

    priority(优先级):通常分为high/normal/low,或者可以加上resolve immediately

    severity(严重程度):可以分为block/critical/major/minor/trival

    found in: 缺陷被发现的版本,通常平时测试的都是一些build,只有正式release出去了,才会在产品环境下由客户发现缺陷。所以这里填的版本信息应该大多是build号,由于数量太多,并且预先很难知道被测的是哪一个build,所以这里使用文本框填写比使用下拉框选择预定义的版本信息要适用。

    fixed in:缺陷被修复的时候由开发人员填写。在使用daily build的团队中,开发人员可以取得当前最新的build号,加1就是下一个build号,用它来反映修复将在哪个build中被包含。在使用svn作为源码控制的开发环境下,可以填写提交修复的revison number,基于它做的build就是将包含修复的build。

    resolution(解决办法):由开发人员修复缺陷的时候填写。解决办法可以包括:Architecture/Code Change/Configuration Change/Database Change,另外可以包括Need Information来把缺陷返回到测试人员那里,也可根据实际情况选择duplicate/Not a defect/Software limitation等解决方案。

    verified in: 反映缺陷的修复在哪个版本被验证了

    attachment(附件):附加的屏幕截图、服务器或客户端日志等相关文件,便于开发人员定位缺陷的原因。

    下面是几个我认为有帮助的缺陷属性:

    Environment:描述缺陷被发现的环境,可分为Development/Test/production,用以区别开发人员开发过程中自己发现的缺陷(通常是一些影响比较大的,比如设计上的缺陷,否则一般都是自行解决,不会提交一个缺陷)、测试人员测试环境下发现的缺陷以及客户在产品环境下发现的缺陷。方便的对测试环境下和产品环境下的缺陷进行区别,对之后的数据统计、测试效率的评定都是很有帮助的。

    Release Note?: 如果缺陷属于software limitation不予修复,或者在当前release不予修复,勾选上Release Note,便于过滤出这样的缺陷,好统一加上release note

    Affects Doc?:如果缺陷发现了设计或需求中的问题,需要修改原始的文档,那么这个属性就很有帮助。

     

  • Four Tips for Technique Seeking

    2007-12-10 15:43:53

    作者:Julie Gardiner,译者:iloveyouso

        我建议你和你的团队学习尽可能多的测试技术、评估它们的可用性、并且将它们应用到工作中来。这里是一些小建议:

        研究你的bug—— James Whittaker,许多关于软件测试书籍的作者,是“研究你的bug”学说的强烈拥护者。看看在production环境中发现的缺陷,研究是什么原因引入了这个缺陷。想想为什么你漏测了它。是因为进度上的压力么?技术上的?理解偏差?如何做能防止它第二次发生?

        防止Boris Beizer所说的杀虫药怪圈——杀虫剂是用来杀灭害虫的化学制剂。然而,如果过度使用杀虫剂,害虫就会对杀虫剂产生抗药性从而导致杀虫剂失去效用。同样的,软件会由于我们一直使用同样的技术构造的相同的测试用例而产生“免疫”性。

        弥补你的知识和经验——知晓一些标准。有许多的测试标准,但是你应该知晓软件组件测试标准——BS7925-2。它描述了测试过程、测试技术以及如何评估它们的有效性。草拟版本是免费的。一些人说阅读标准文档是治疗失眠症的最佳疗法,但是标准的确有它的价值。例如,基于状态转换的测试很适合GUI和WEB页面浏览,边界值测试用于发现围绕处理规则的边界产生的缺陷,决策表是用于测试业务规则的极佳工具,语法分析对于测试输入条件是极好的。所有这些在BS7925-2标准中都有描述。确保你的团队熟悉所有这些。

        学习一些不太知名的技术——我最喜爱的技术是一种叫做“分类树”的技术。BS7925-2里没有讲到它,但是它是一个非常直观和简单的方法。另外一个我喜爱的技术是使用正交矩阵的all-pairs方法。因为这一技术将组合数减少到了一个可以接受的水平,同时最大程度保留了发现缺陷的可能,它在你需要测试输入数据的许多组合——配置、浏览器、操作系统等等时将非常有用。

        阅读书籍像Lee Copeland的A Practitioner’s Guide to Software Test Design以及James Whitaker的How to Break Software。两本书都描述了大量的技术以及如何使用、什么时候使用它们。

        最后,没有任何方法可以替代在工作中的学习。相互提问,为什么一个测试被创建、用到了哪种技术,这样的问题能推动有经验的测试人员改进测试。

        你现在使用了哪些技术?哪些你曾经考虑过?你会研究那些你漏测的bug么?有许多技术需要考虑,我们需要寻找发现缺陷的新方法。

  • 基于反射的UI测试

    2007-11-27 22:26:10

    《.NET Test Automation Recipes A Problem Solution》

    .NET环境提供了许多System.Reflection命名空间的类来在运行时访问和操纵应用程序。使用反射,可以写出轻量级的UI测试。

    使用基于反射的测试技术的优点是快速、容易实现;主要的缺点是它们只适用于纯.NET应用程序,并且不能处理较复杂的测试场景

  • APITesting

    2007-11-18 11:00:49

    《.NET Test Automation Recipes A Problem Solution》

    API testing也叫unit testing, module testing, componenet testing以及element testing。主要的思想是保证软件系统中独立的程序编译块正确地工作,否则软件系统整体不可能正确工作。

    处理静态方法、实例方法和未完成的方法是写轻量级API测试自动化时最重要的三种情况。大多数情况下不会对私有的helper方法进行测试。所有helper方法中的错误都会在测试使用这个helper的方法时暴露出来。但是如果你的确有一个非常复杂的helper方法,你可能会希望为它写出详细的测试用例。

    主要涉及到以下方面:

    • 存储测试用例数据
    • 读取测试用例数据
    • 解析测试用例
    • 将数据转换成合适的数据类型
    • 测试用例结果
    • 将测试用例结果写入日志
    • 将测试用例结果打上时间戳
    • 计算结果汇总
    • 计算测试执行时间
    • 处理空值输入和空值期望结果
    • 处理抛出异常的方法
    • 处理空字符串输入参数
    • 测试用例失败时自动发送E-mail
    • 自动启动测试工具

     

Open Toolbar