• 空间首页
• 空间管理
• 51Testing软件测试网
• 站点论坛
• 添加我的日志

我的最新日志

• 复测的理由

  2008-7-02

  测试找BUG就像在雷区找地雷。如果你总在同一条路上走来走去，你就找不到许多

  地雷。实际上，这是一条很好的路用来避免地雷。其余的空地对一个现代的软件

  产品要比一个雷区巨大和复杂的多，因此这是比一些小量的路径更多的难以假设

  的问题，可以说，一百，一千或一百万，在不断的重复时，将会发现每个重要的

  BUG.一个小组的测试员可以手动执行数周或数月的测试，但仍不能和在这个区域

  发生在这个产品的事情相比。

  类似于布雷区的说法仅仅是关于测试是一个类似的过程的另一种说法，我们可能

  想要一个更大的例子，而不是一个小的重复了多遍的例子。因此雷区带来的取法

  就是做不同的测试而不是重复相同的测试。

  但是我说的重复相同的测试是什么意思呢？显而易见，没有测试能被准确的重复

  执行，这要比你准确重复执行的更多一些。你可以关闭，但那将总是一小部分。

  作复测就是你第二次运行测试，而且应确保阳光一直照射在你鼠标垫的同一个角

  落吗?可能吧，不要笑，我经历过这样的BUG，一次，阳光照射到鼠标内的一个传

  感器触发了这个BUG.你不能确实什么因素将会影响测试。可是，在你测试时，你

  仍需要一个确定的目标和确定系统理论。你可以很好的重复测试，通过在每个值

  得注意目标和理论，包括：A：你所知道的；B：你能确认的；C：代价太大而不去

  重复的。对于此没有什么是必要处理的。

  因此，通过复测，我的意思是包括在其他测试中覆盖的已知的基础。重复测试就

  是要重复一些之前测试的方面。雷区的启发就是你试着去做一些事情要好于你没

  有做过，然后做一些已经做过的事情。

  如果你不同意这个说法或如果你同意这个说法，都请你读下去，因为...

  这个分析太简单了！事实上，即使测试中的差异是重要和强大的，即使反对重复

  的辩论是有效的，我知道有10个例外。有10个明确的原因，在一些特殊的情况下

  ，复测并不是没有道理的。重复一些测试可能是很重要的。

  使你可以理性的测试有关技术上的原因有：

  1.再充电：一个新问题或旧问题重现的真实的可能性是，可能是被一个现有的特

  殊的测试捕获，或者是旧的测试应用在新的代码基础之上。包括再运行测试来证

  实一个错误，或者当一个特殊的问题或行为可能介入时，在你试着去找到问题时

  更早的连续构建之上的重复测试。也包括在新的操作系统中对同样的软件做原来

  的测试。换句话说，一个疲劳的旧的测试能被改变测试的技术再充电。注意再充

  电不会产生必要的影响意思是，你应该运行相同的旧的测试，仅仅是这么做是理

  性的。

  2.间断：如果你怀疑一个BUG的发现不是一次测试的正确运行能保证的，可能是与

  你在测试中不能控制的一些重要的可变的因素有关。执行一个测试，对你而言，

  正确的就像你已经执行过的那样，可能导致发现的BUG是一直存在但是没有显示出

  来，直到自由的可变因素用一种确定的方式排队。这是相同的原因，对于一个赌

  徒在输掉第一次之后在赌博器前玩了又玩。

  3.再试：如果你不能确信测试再其他时候被正确执行。一个方法就是让所有的测

  试人员根据这个相同的说明检查看是否能得到相同的结果。

  4.转变：如果你要改变一个测试的重要部分并保持其他部分不变。尽管你重复了

  一些测试的原理，测试整体是新的，并且可能会显示新的行为。我变异了一个测

  试，因为尽管我之前覆盖了一些东西，但是并没有做得很好。一个共同转变的形

  式就是使用不同的数据用同样的办法操作产品。变异一个测试和间断或重试之间

  关键的不同就是变异要使改变在你的直接控制之下。变异是有意的，而间断结果

  是因为偶然因素，你重试一个测试是因为偶然因素。

  5.基准：比较之前相同准确测试的执行，可以得到一个执行标准的价值，如果复

  测包括这个执行价值。当一个历史性的测试数据象神化一样被使用时，你应该意

  识到你执行的测试对历史数据是有可比性的。保持测试一致可能不是使结果有可

  比性的唯一方法，但他可能是可用的最好的选择。

  使你可以理性的测试有关商业上的原因有：

  6.便宜的：如果有一些相比新的和不同的测试价值十分便宜的测试，然而，这些

  测试在证明在产品中的信心不是足够的。

  7.重要性：如果一个问题是通过这些测试发现的，可能比通过另外的测试发现的

  可现的BUG有更充分的重要性。产品行为的重要性分类没有必要统一。有时感觉一

  个特殊的问题是难以忍受的，仅仅是因为它已经影响了一个重要的用户一次（一

  个永不让它再次发生的情形）。这没有必要意思就是你必须运行相同的准确的测

  试，发现这个问题正确地事情是十分类似的。注意不要用一个测试的重要性搞乱

  一个问题的重要性。一个测试可能是重要的存在很多原因，即使那些问题发觉的

  并不是危急的。同样，不要犯这些错误：花很多精力在一个看起来可以找到重要

  BUG的测试上，而忽略了其他可能一样好的或者更好的可以发现这类型问题的测试

  。

  8.充足的：如果你做的复测是值得做的。这是一个病毒扫描的争论：对于一个平

  常的用户，一个重复的病毒扫描是可以被认可的，代替了经常的改变病毒测试。

  无论如何，我们可以说明变化因为我们不知道哪些测试是值得做的，或者我们不

  能完成足够的复测。

  9.委托管理的：如果，由于合同，管理布告，规章，你不得不相同的准确的测试

  。无论如何，即使在这些情形下，通常委托管理的测试作为你唯一可执行的测试

  是没有必要的。你可以在不违反委托管理的前提下运行新的测试。

  10.不关心/避免：如果运行测试是因为一些原因而不是为了找BUG，比如为达到某

  训练目的，演示目的（例如一个在客户的观看下，你拼命希望能通过的验收测试

  ），或把系统放在一个特定的状态。如果其中的一个目标在运行测试时是为了避

  免BUG，那么主要的争论就是为了变化的消失。

  我大概用了一百个小时和测试学生和同事争论这个问题，在此期间，我收集了这

  些原因。我的许多同事更喜欢不同的词汇或一个不同的分类原因。我这种做法不

  是什么特别神圣的（除非这些分类将使每个类似的项有更长的列表）。重要的事

  是当我听到一个看起来不在我已经总结好的原因之列，我把它加到这个列表。

  1997年，我开始只有2个原因。在2004年末，我增加到第十个。

  在雷区的应用：一个例子

  Ward Cunningham写过“我相信TDD自动需求免除了类推，因为我们做的研究是为

  了在现有测试中做一个最好的程序表达，而不是最好的测试”

  以下是一些我怎么想到的关于这个的应用：
  你的单元测试可能通过了或没有通过。你记下他们所以他们将在一些违反预期结

  果的事件中失败。所以，你叫他们测试并且，看到他们在测试。

  我们介绍的雷区批判第一次你在单元测试中运行任何给出的测试。第一次运行，

  失败了，对吗？当然，因为它不是TDD，否则。雷区启发了以下问题“变化测试而

  不是重复测试”。

  问题：为什么再次运行？

  回答：“再充电”例外。你再次运行是因为你已经增加了代码使得测试通过，因

  此再次运行测试不是多余的，通过代码的改变，测试的价值已经再次填充。

  问题：在开发期间，除了测试在第一次通过后，为什么不删除？为什么这么麻烦

  的再运行一次？

  回答：几个原因。再仍然应用了一些，因为你可能在开发中偶然中断了，但是它

  要被争论：大多数的单元测试和大多数的时间都失败了，他们中间的一些非常不

  像失败，即使你彻底改变了代码。这里给你第二个原因:例6，便宜的。创建和运

  行测试是很便宜的，同时他们还有一些价值，即使不是很多。对于一些测试，还

  有第三个原因：例7，价值。对于一些好的单元测试，失败的发生将说明一个严重

  的问题。如果你测试的一些东西是特别复杂的，或包括了许多互相影响的子系统

  ，你可能也想重复因为例2，间断。可能有些东西会在43次运行之后失败，因为在

  测试中有一些或然而论的因素。最后，例3，再试。这提醒我们以前可能没有正确

  运行测试。象你从前说过的，ward，有些东西会发出不好的气味仅在你看到测试

  运行了大约100次以后。换句话说，运行测试很多遍的结果，你可能在显示产品的

  缺陷有灵感，他们是一直存在的，但是没有注意到。

  问题：我是一个很好的开发人员，尽管我写了好的测试，但是他们没有失败，因

  为我的代码没有BUG。我有许多测试，并且他们没有失败。投资这样的测试有什么

  意义呢？
  回答:2个潜在的原因。例10，避免/不关心。你可能用文档的形式为将来的开发人

  员建了很多测试，为了减少失败的可能性，你希望他们是正确的（因而象文档一

  样没什么用）。或许你想用你这伟大的软件给客户留下印象，如果测试没有通过

  ，他们可能没什么印象。第二的原因是例9，委托管理的。你用这种方式工作因为

  你同组或经理要求你这样做。除了你用这种委托管理的方式，这与避免有点象，

  实际上，想找到BUG.你在寻找BUG，你只能使用要求的特定的技术来做。

  我们因此可以看到一个相当简单经常复测的TDD单元测试真正的要避免基于雷区的

  争论是有利于改变测试的，因此作为原因我已经引用了。但是TDD不能脱离这种启

  发式的分析，对复测的价值提出疑问总是有道理的，这就是雷区邀请我们做到事

  情。

  查看(33) 评论(0)

• 一个基于风险的测试策略

  2008-6-23

   

  一、介绍

  一个测试策略的开发意味着要和客户在测试试运行时对测试组织和策略的选择方面进行沟通。这个测试策略指

  出测试将怎样被执行。为了使最好地利用时间和资源变为可能，他决定系统的那些部分重点做。这个测试策略

  对于一个有组织的测试方法构成一个重要的基础，对于一个易管理的测试过程作出主要的贡献。

  在运行的时候，试运行的用户将期望系统的一些特殊的品质，并想知道这个版本的系统是否达到他们的需求。

  如果系统在质量上不能满足用户的需求，或仅能达到有限的范围，这就意味着对这个组织有更大的损失，比如

  以后将付出更高的重做的代价或者客户不满意。因此，这种情形对这个机构形成了风险。风险的书面定义是：

  风险就是错误发生时，可能影响到预期损失的可能性错误。

  测试涵盖了在系统质量要求会议上所能洞察到的风险。当质量出现时间估计不足时被接受，例如重新开发。如

  果运行系统对组织意味着很多风险，那么好的测试显而易见的解决办法，相反也是成立的：没有风险就没有测

  试。

  虽然我们以上涉及到的质量和风险属于一般意义的，但是可能有很大的不同取决于实际情况。和客户讨论这个

  是非常重要的，并且用这种方式把客户的意愿转化成将要执行测试的方法。因而，测试策略被导向在测试外露

  的结果和覆盖风险的要求之间找到最好的平衡。为了这个目标，风险被细化到质量特征水平和独立的子系统中

  。为了做成这样，为评估的风险找到一种可能的测试覆盖变得可能。这是一个更高的测试覆盖通常结果在更多

  的测试中。为了在需要的测试覆盖达到这种变化，需要更多的测试技术说明（测试设计技术），提供的每个测

  试覆盖详细说明都是至关重要的。
   
  一个类似的保险单可能阐明关于此问题更多。一个人想要涵盖一个相关的风险，并且最好可能得到一个覆盖该

  风险的适合的保险。这个保险单会支付一笔确定的保险费，如果这个人想支付更少的钱，就要买一个覆盖最低

  的保险。这个结果就是如果没有覆盖的风险发生，他将得不到保险金。另一方面，如果覆盖越大，就要支付更

  多的保险费，因为对这个人来讲有可能一种被保险的情况不会发生。

  二、风险评估
  测试策略基于风险评估。意思就是评估缺陷结果造成的损失，包括系统实施前预先未发现的缺陷和在实施过程

  中发生的缺陷。

  风险评估发生在质量特征和子系统的基础之上。例如，如果系统不够友好，将会发生什么样的负面影响。薪水

  计算模型在薪水系统工作有误的时候将会发生什么损失。

  为了更好的执行评估，应该考虑把风险的各个方面分离：风险＝失败的机会×损失，失败的可能与系统各个部

  分的使用频率和发生错误的可能有关。
  以下列出这些方面：

  使用频率
  一个功能在一天被使用数次所发生一个错误的机会要远远大于一年使用一次。
  错误的可能性
  以下的列表对于评估错误发生的可能性是很有帮助的。它展现了错误易发生的地方。它部分内容是基于H.

  Schaefer, 1996 （幸存于时间和预算的压力之下，在：Conference Proceeding EuroSTAR1996, Amsterdam,

  the Netherlands）：
  复杂的功能；
  完全的新功能；
  （特殊的，频繁的）变更的新功能；
  第一次用特定的工具或新技术来开发的功能；
  在开发过程中，开发功能的程序员被更调动过的；
  功能在有限的时间内实行；
  功能相对平均水平被更频繁的优化过；
  很多缺陷被很着就发现的功能（例如，在早期的发布或更早的回顾过程中）；
  包括很多接口的功能；
  没有经验的程序员；
  用户不足；
  在开发中质量保证不足；
  低水平测试导致质量不足；
  新的开发工具和开发环境；
  庞大的开发小组；
  开发小组沟通不理想（例如，由于地理原因或个人原因）；

  损失
  如果错误自己出现了，对组织将产生什么样的损失。包括修复的代价（包括系统和结果的），放弃收益和丢失

  客户或信心。通常，如果错误影响到其他功能或系统时，损失会增大。在批处理中错误发生的情况下，兴许有

  一种可能性会阻止他们妨碍用户，因此最后的损失将会比类似的在线进程减小。当然，唯一的把握就是错误被

  及时发现。
  因为事情的复杂性，不可能完全的详细客观的估计风险：这是一个全球性的评估。所以对于不能单独被测试经

  理所颁布的测试评估它是重要的。一大批潜心于这个计划的人要作出贡献：客户，用户，开发小组，会计，IT

  审计员等等。这不仅提高了策略的资量，而且有利于不同部门的人更加能意识到风险和扩大测试范围来是这些

  风险用一种更好的办法来变得易处理。

  测试策略的制定者应该意识到用户是评估损失和评价风险时使用频率的最好人选（最终用户，系统经理，和实

  施经理，在线管理），而项目小组人员却最好的评估错误可能性的人（项目经理，设计人员，程序员，项目质

  量成员，测试经理）。

  测试评估的焦点在产品的风险上，或者，换句话说，如果产品不能证明预期的质量，对于组织来讲什么才是风

  险。除此之外，还有项目风险。如果系统必须要在一月一日产出，如果功能说明书被延期太多，如果没有有经

  验的测试人员以使用，或者没有测试组织按时准备好，那么我们就可以称之为项目风险。这些没有在决定测试

  策略时被放在估计中；他们在测试计划中扮演角色。

  开发中的测试策略目的是为了明确在确定可行的范围内，测试以这样一种方式组织工作。
  最重要的问题将被建立；
  问题将在很早的阶段建立；
  最先发现那些需要最多的重做时间的问题；
  资源造成有效的使用；
  最终给出一个正确的质量建议。
  总结如下：
  测试策略的目的在于依靠最低的成本尽可能早的找到最重要的错误。

  实际上，测试策略的制定往往与准备预算是一致的，比如要借助于测试点的分析。被采纳的测试策略结果立即

  转化未测试时间需求和因此产生的测试成本的优点使策略选择易于管理。如果测试可用的时间或多或少是可以

  固定的，就有可能用测试策略组合测试点分析来决定什么在有限的时间下是可以完成的。或许更重要的是在这

  个时候搞清楚哪部分不需要测试，或者不能完全测试，并且因此将会招致什么样的风险。

  3.质量特征
  质量特征我们可以区别分为动态和静态的质量特征。动态质量特征处理一些在信息系统中使用的主要特征，如

  ：安全性、可用性、持续性、可描述性、功能性、友好性、适用性、效率和性能。静态特征与信息系统的本质

  特征和文件有关，从开发者和将来的系统管理者出发考虑，如易管理性，可维护性、连接性、可重用性、便携

  性和可测性。

  4.程序
  在执行测试策略时要区别主要的测试计划和特殊测试阶段的测试计划，如验收测试和系统测试。
  程序要遵循新系统的开发和环境维护。为了后面，最好是在基础程序中做一些少量的变更。
  一个测试策略的制定不是单纯的做一些方法上和形式上的事情。下面的步骤是帮助和指导。对于一个有效合理

  的测试策略，在测试领域中经验丰富和有技术的测试执行者是主要的成功因素。有一点也应该认识到测试策略

  源于重复过程的结果并且和对测试计划有关的其他活动。如果第一次测试策略指出许多必要的测试结果或者一

  个客户无法接受的确定的时间计划，那么测试需要变更。缺乏测试技术相应的结构也会导致测试策略的变更。

  4.1 在主要的测试计划中的策略
  对于一个测试策略在主要的测试计划中的步骤有：
  对质量特征作出决定；
  确定有关了质量特征的重要性；
  归纳质量特征到测试水平。

  4.1.4 步骤1：选择质量特征
  停止客户和其他有关选择质量特征在哪些测试制定的成员的联络应该关注。为了做成这样，一方面要把商业风

  险估计进去，也要把系统需求包括的各方面和关系到信息系统的商业目标，以及计算机中心的方针和标准。这

  些质量特征也被用于在测试执行和完成阶段向客户报告。

  有些质量特征是难以测试的。把系统变得用户友好和通用，那可能是个理想，举例为证，这些理想不能转化为

  可度量的需求。这就是为什么一个真实的部分要被尽可能可度量和明确的描述为有关的质量需求。这也就是质

  量特征要求相关的更多结果在测试中的原因。因为这对于提出不能完成的可能性是没有用的，她应该被决定在

  一个需要做决定的评估结果之前。

  对于非IT人来讲我们的质量特征可能是难以处理的。她在我们给外界合作伙伴翻译时给予帮助。通过找到可说

  明问题可能发生在产品中和可能导致损失的例证来做到。这是明确表达测试策略的最难的部分。

  4.1.2 步骤2：质量特征相关的重要性
  基于步骤1 的结果，决定质量特征的重要性是相互决定的。通过衡量每个质量特征相关的风险，在重要性矩阵

  中作出来。相关重要性通过百分比的形式展示出来。注释不是给出重要性的确切百分比：达到目标在不同质量

  特征相关重要性的概述图表。在矩阵中的图像可帮助评估风险。
  客户被迫作出选择。因此，作为一个指导，我们最少询问5％。百分比的总数可能达不到100％。例如：

  在表中百分比最高的功能性可能惊动读者。这与实际经验是一致的：通常这个特征描述大于50％的重要性。原

  因是通常这些功能使用不正常的系统的风险远远大于运行慢的系统或难于使用的系统。

  4.1.3 步骤3：质量特征归结于测试水平
  为了达到尽可能有效的使用测试开销，测试策略的制定取决于测试水平或将要选择测试的不同质量特征合并的

  测试水平。同样检查也受到主要测试计划和测试策略范围的影响。当测试被使用时，保留部分，检查也包括在

  内。

  通过这种方法，一个项目内不同的测试标准使得平衡。显然，不同的职责保持完整。

  表里的符号+显示测试策略是否要把一个质量特征计入在内。＋＋或＋＋＋表示给指定的测试标准更多的质量特

  征关注。显然一个质量特征对多个测试标准是有效的，但是深度是有所不同的。如果使用规范结构测试技术，

  例如：验收测试，可能会使用之前的测试结果，基于此可以决定测试的浅度。
  图例:
  Insp RQMS 检查需求
  Insp Specs 检查功能详细设计
  Insp Design 检查技术设计
  PT  程序测试
  IT  集成测试
  ST  系统测试
  FAT  功能验收测试
  PAT  产品验收测试

  4.2对于一个测试标准的测试策略
  对于一个明确的测试标准，要执行的测试策略步骤有：
  1.取决于质量特征
  2.测定质量特征相关的重要性
  3.把系统分为子系统
  4.测定子系统相关的重要性
  5.详细说明每个子系统和质量特征的测试重要性
  6.设立使用的测试技术

  对于一个指定的测试标准，策略决定有作为前提和起点的主要测试计划策略。如果一个主要的测试计划，步骤1

  被忽略，并且步骤2被简单快速的执行完毕。然而，所有的步骤在下面执行。

  4.2.1 步骤1：对质量特征作决定
  合作的客户和可能与质量特征相关的其他成员决定关注哪个测试涉及到商业风险。在测试和完成阶段，结果会

  基于质量特征被报告。
  4.2.2步骤2：确定相关质量特征的重要性
  基于步骤1的结果来决定选择质量特征相关的重要性。通过衡量每个质量特征决定要发生的最重要的。通过百分

  比展示在一个衡量的表的相关重要性的列里。为了促使客户作出决定，5％是最小值。

  给出一个功能验收测试的例子：
  4.2.3步骤3：把系统分为子系统
  在这个阶段和接下来的阶段，测试策略被精练更多。这意味着如表中所显示的质量特征和他们相关的重要性因

  为测试技术说明和子系统的合并而破坏，随后开始测试技术说明和单元测试。
  信息系统被分成多个子系统。原因是同样的质量要求对于每个子系统不是有效的。而且，不同的子系统对于组

  织来讲有不同的风险。原则上划分的模块和给的设计文档是一致的。如果偏离了这一点，我们必须清楚的表明

  这样做的动机。例如可供选择的模块是基于风险范围的或者基于开发者发布的命令。如果有一个变更的模型，

  它就要被视为一个分离的子系统。通常子系统和总系统是被区别开来的。这个服务的意图是表明一些质量特征

  仅仅是通过继承测试被有效评估的，测试子系统的一致性。
  在后面的阶段，这些子系统被更细的分为独立的测试单元。例如，在一个后勤系统的子系统，销售可分为报价

  单和订单测试单元。
  4.2.4步骤4：决定子系统的相关重要性
  基于前面步骤的结果，子系统相关的重要性在表中显示。通过衡量每个子系统的风险作出来。和看到客户和相

  关其他人的关于子系统重要性的全局的印象，这不是一个精确百分比的问题。这步可以帮助有这方面疑问的人

  们。

  确定下系统系统中的每个子系统相关的重要性。在表中通过百分比的形式显示相关重要性。

  以下给出一个关于功能验收测试的这方面的例子（基于在主要测试计划中对测试标准的策略）：

  
  4.2.5步骤5：说明每个子系统和质量特征的测试重要性
  最终一个完美的方案由评估质量特征和子系统的重要性组成，例如，一个完美的方案可能认为用户友好是重要

  的，但是它对子系统1是支持的，对子系统3却一点关系也没有。再次强调测试策略决定并非是一个精确的事情

  ：它意味着通过不同子系统相关测试的重要性和质量特征，得到一个印象。这也就是我们为什么选择＋，＋＋

  ，＋＋＋做为标记，而不选其他假拟确定的数学公式。下列的假设对于用户友好和一批指定的子系统是非常重

  要的，在一批程序上做关于用户友好的大的测试才可能会得到数学公式。

  4.2.6步骤6：确定可用的测试技术
  测试策略的最后一步包括在即将测试的已选择的质量特征和子系统集合选择测试规范技术。一个高的重要性意

  味着通过一个高的覆盖率使用技术或使用更多的技术，一个低的重要性意味着使用低的覆盖率技术或使用少的

  技术。

  在选择技术的时候要把不同的其他因素计入成本，以下列出一些：

  被测试的质量特征
  一种技术适用一种或更多的质量特征。有些质量特征可以用一系列技术做最好的测试，其他的用另一种。

  应用领域
  有些技术是专门用来测试用户和系统交互的，另外一些则能更好的用于系统处理。通过一种技术，能发现相关

  的一类型的错误，例如，错误输入检查，错误处理或错误集成。

  测试基础的可用性
  每种技术都是开始于一种确定的测试基础。这可能是功能说明书，技术设计，编码或最终用户的说明书。精确

  的测试基础也与选择技术有关，例如，确定表，伪代码，结构化语言或无结构的文档。

  正式的范围
  不正式的测试技术说明相对于正式的技术，在编写测试用例时，给测试人员更多的自由。

  资源的利用
  技术的实施需要许多特定的资源，根据人和机器的能力。使用资源需要成本做指导。

  必需的知识和技术
  不是每个测试人员都会每种技术。为了使有些技术更好的应用，大量的商业知识是必要的。对于另外一些技术

  ，还需要更多的分析才能。因此，测试人员的知识和技术也影响到技术的选择。
  出于实际的原因，还应该考虑用一系列最少的测试技术规格来覆盖所有选择的测试特征。
  选择测试技术规格应该在早期的测试阶段做好，因为之后测试小组就可以在学习技术上作出恰当的行为，并列

  出必要的清单，或调整某些特殊的情形。
  这个阶段的结果就是用于每个子系统的技术将被详细说明。随意的，特别是一些大的测试项目，这个最后的阶

  段在测试策略执行的稍有些晚，也就是说在准备阶段。作为测试阶段优先执行的一部分是决定的。目的就是使

  最重要的测试尽可能早的执行。

  4.3测试过程的策略
  测试策略提前定好往往在后面的测试阶段会有压力。在这种情况下，测试经理要执行更少的测试或更短的测试

  来与变更的计划保持一致。在最后的开发阶段，主要的结论有：突然有些测试必须被取消或者只能不深入的执

  行。以测试策略为基础，测试经理可以和客户讨论哪些测试可以被取消或者哪些地方可以不深入的测试。通过

  标注哪些测试与评估的风险关联较小（在策略中转化成的重要性），测试经理可以出具一个关于测试之后增加

  的风险的格式一致的报告。所以不去改变步骤1－5是本质的：风险和重要性水平都没有改变。结果就是，当测

  试减少时，在执行系统时会有更多的风险。

  抛开这一点，还有一种情况就是在测试时会出现部分系统包含非常多的错误或非常少的错误。两者都可以使测

  试策略作出调整，也就是说分别增加或减少测试。相反的情形就是在之前的章节讲的风险同样会在执行系统之

  后被保留。可以概括为：
  在发现和改正错误的成本低于关系到发生在产品中错误的成本时，测试应该继续。

  在发现和修改错误的成本要高于测试成本该充当的角色；另外，大量的成本是与运输产品延迟有关的。对于发

  生在产品中的错误也应该被估计到偶然性，因为错误将真的会发生：一个错误将永远不会发生才是没有错误。

  4.4维护的策略
  开发新系统和维护测试策略两者之间，主要的不同是偶然性的错误。维护变化的依据是现有的已做好的信息系

  统。这些变化应该被测试。在维护中，新错误的引入是一个风险，会导致系统质量下降。

  在维护的情况下，这些不同偶然性错误的含义是意味着对于策略而言，子系统相关的重要性可能会改变：一个

  子系统在开发的时候有很高的重要性，在维护的时候可能没有变化。因为在衰退的可能性是这种情况下仅有的

  风险，测试的重要性就更低了。因此，针对测试水平测试策略的开发，可以通过把在这些阶段子系统的概念变

  为改变来修改。为了每个变化要分析系统的哪些部分变异了，哪些部分会因此产生影响，哪些质量特征是有关

  联的。基于风险，对测试每个改变有些不同的可能性：
  一个只针对变化的有限的测试；
  一个对改变的功能的完整的测试；
  改变的功能和相关的功能的一致性测试；

  对系统也要做一个整体的衰退测试。测试的中心是有关系统改变和未改变部分的一致，因为衰退的偶然性是最

  大的。如果测试策略对于一个新开发的系统是可用的，重要性水平归结于子系统的使用。

  处理改变的错误的可能性，在开发的系统和维护的系统之间还有更多的不同。尽管，他们对测试策略开发的技

  术没有影响。例如，不同之处包括：

  测试原则丧失，不完整或不是最新的
  在维护中很频繁的这种情况，导致对测试技术的选择。

  可预测的点对点的维护
  多数维护情况是可预料的，并且可以计划。策略很容易决定这种类型维护的应用。在点对点的维护下，这种情

  况更难，重心是让一个坏掉的产品恢复正常，并且使系统尽快传播出去。一个正式的策略决定要花掉很多时间

  。对于测试策略场景是可用的。如果程序x出错又修复了，该测试什么？对于点对点测试，这些场景支持一个最

  理想的测试。

  5.结论
  信息系统的测试基于组织在系统中体验的的商业风险。测试经理经常设法用一种直觉的方式从风险来做测试覆

  盖。在这篇文中，对于测试策略已定义好的步骤是直接的。这样一个测试策略对于相关成员是一个很好的见识

  ，对于讨论测试深度也是一个合理的根据。

  好的风险评估是这些步骤中的一部分。这是基本的，可以以一致直接的方式认识风险没有被测试经理或测试员

  单独做到。确定包括的人员（用户，客户经理，审计师，工程人员如开发，测试 QA和项目经理）是必要的。实

  际上，风险的讨论和有关的测试策略用这种方式使所有人大开眼见。讨论了测试深度，通过顾客决定的，理论

  可被怎样彻底测试。

  这种逐步定义的测试策略可被用于任何测试阶段（如，系统测试，验收测试），对于一个全部的策略也是一样

  （主要测试计划，包括和调整的所有测试阶段和检查）

  
   

  查看(35) 评论(0)

我的主题

• 国美电器IT部招聘测试工程师 北京
• 自动关联时，为什么没有显示结果呢？
• 遇到这种情况该怎么办？