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

我的最新日志

• 新人入职(三)

  2008-7-28

  软件缺陷的官方定义

      在开始这部分之前，先需要大家了解一个辅助术语：产品说明书（Product Specification）。产品说明书有时又简称为说明（Spec）或产品说明书（Product Spec），是软件开发小组的一个协定。它对开发的产品进行定义，给出产品的细节、如何做、做什么、不能做什么。这种协定从简单的口头说明到正式的书面文档有多种形式。

      通常软件行业对软件缺陷有如下的5个规则定义，只有至少满足其中一个规则时才称为发生了一个软件缺陷（Software Bug）

  1)        软件未实现产品说明书要求的功能。

  2)        软件出现了产品说明书指明不应该出现的错误。

  3)        软件实现了产品说明书未提及到的功能。

  4)        软件未实现产品说明书虽未明确提及但应该实现的目标。

  5)        软件难以理解、不易使用、运行缓慢或者---从测试员的角度看---最终用户会认为不好。

  为了更好的理解上面的每一条规则，下面我们举计算器的例子进行说明。

      第1条规则很好理解，不用说明了吧：）

      产品说明书可能声称计算器永远不会崩溃、锁死或者停止反应。假如你狂敲键盘使计算器停止接受输入，根据第2条规则，这是一个缺陷。

      假如计算器中除加、减、乘、除外多了一个开平方的功能，但说明书里没有提到这一功能，是雄心勃勃的开发人员自我感觉良好的加入话，根据第3条规则---非常抱歉---这是一个缺陷。这些规格外的功能，虽然有了更好，但同时也会增加测试的工作，甚至可能带来更多的缺陷。从另一个角度来讲，也许我们的客户是故意不在这一个版本当中加入这个功能，希望通过一个升级版本的发布赚取更多的利润，因为他们在这一行业的垄断无人能及……（事实上目前大家所用的软件和硬件产品绝大多数在上市前已经在开发商的库房里封藏有一段时间了，在前期版本的开发成本尚未收回时，新版本是绝对不可能上市的，除非有激烈的市场竞争驱动）

       第4条规则中的双重否定其实是在肯定两类问题。第一类是针对软件产品在各种异常情况下的处理，是属于软件“可靠性”的范畴；另一类是软件产品是否附合其使用平台的操作习惯，是属于软件“易用性”的范畴。二者都属于软件的内部质量。针对前者“可靠性”方面的设计应该考虑让计算器安全的工作到电池完全没电。当计算器电池电量不足的时候，我们可以提示用户及时更换电池或者发出安全警报提示用户继续的操作可能会导致数据丢失，而不是莫名的计算错误或粗暴的强行关机。针对后者“易用性”的考量，设计时应该全面考虑软件运行的操作系统使用习惯和界面风格。针对Windows操作用户来说，一切快捷键的设计是一定要考虑进去的，比如“F1”是用来开启当前应用程序的帮助文档；[Alt+F4]是用来关闭当前活跃的窗口，这些都是Windows操作系统管理的默认方式，我们的软件产品是一定要继承过来；MAC OS的界面风格是很有特点的，我们在MAC环境下设计的产品也一定要附合MAC OS的风格，不要图省事直接把在PC上开发的界面生搬硬套过来，不然会让用户感觉不伦不类，给我们很不专业的印象。诸如此类的要求通常在规格说明书是不会明确的写出来的，但根据第4条规则，如果我们设计的产品做不到，那一样也应记为bug。

  （注）关于软件的内部质量和外部质量会在后面的章节进行讨论

         第5条规则是全面的。软件测试人员是第一个真正使用软件的人，否则，客户就是第一个使用软件产品的人了。如果软件测试员发现某些地方不对劲，无论什么原因，都要认定为缺陷。在计算器的例子中，也许测试员觉得按键太小；也许“=”键布置的位置使其极其不好用按；也许在明亮光线下显示屏难以看清。根据第5条规则，这些都是缺陷。每一个使用过一些软件的人都会对软件的工作方式有自己的意见和想法，要编写令所有用户都满意的软件是不可能的。作为软件测试员，在运用第5条测试规则时应记住下面一点：要全面、最重要的是客观的评价，并非所有测试发现的缺陷都要修改。从另外一个角度来讲，我是很希望大家站在一个end user的角度去测试我们的软件产品的，我们要设想我们可能是一个电脑的初级用户，也可能是一个专业的计算机人员，还可能是苛刻的客户软件验收团队中的一员，更可能是我们公司软件产品强有力的竞争对手。所以我们要记录所有在软件操作流程、功能实现、辅助设计、风格习惯上发现的不尽如人意或者差强人意问题，因为这些很有可能在不久的将来会从你的客户那里反馈回来；即使没有也可能会在更长的一段时间后从软件使用的end user那里传回；如果你所记录的问题从此杳无音讯，也一样要相信自己每一个suggestion存在的理由，它一样在会在你的测试生涯上记录在案。这是每一个测试人员的应该忠实履行的职责。如果在测试实践上止步不前，我们应该尽量的多接触一些其它类似的软件产品的设计理念，先奉行所谓的“拿来主义”，然后通过不断的比较和学习，这样才能有所提高，无论是自身还是对软件产品的理解上。我们应该时刻表现出我们的“专业”与“敬业”，这样才能换得别人的肯定然后才是尊重……

  查看(38) 评论(0)

• 新人入职(二)

  2008-7-28

  软件缺陷是什么

  简单的讲，缺陷是软件开发过程中出现的“瑕疵”，它使得软件实际运行的结果与预期结果不一致。Bug简单的说就是与顾客期望的不符之处，这种不符体现在规约中指定的需求未被实现或者需求根本没有写进规约。于是可以引出一个软件缺陷的一般定义是：程序与规格说明之间的不匹配。（但不要使用这个定义）

  “当且仅当规格说明存在并正确，程序与规格之间的不匹配才是错误。”

      完全遵循一个糟糕的规格说明的程序也是糟糕的，不会是完美的。下面是两个较好的定义：

  l       当程序没有实现其最终用户合理预期的功能需求时，就再现为软件缺陷。

  l       从来就没有对缺陷的绝对定义，也没有对其存在的绝对定义。程序存在缺陷的程度是由程序无  法实现有用功能的程度来测量的。这是基本的人为测量。

          明确的将“人为因素缺陷”排除在他对软件缺陷的定义之外。我们将其视为另一组类型的错误，你也应该这样理解。说服程序员认识到用户界面错误是个错误，或者用户界面错误很重要，或者测试人员有权告诉他一切，可能会更困难。但是客户抱怨严重的人为因素缺陷就像抱怨交通事故一样多。

          作为软件测试员，在不同环境下要用不同的术语描述软件失败时的现象，下面是一些例子：

          缺点(defect)                           偏差(variance)

          故障(fault)                             失败(failure)

          问题(problem)                          矛盾(inconsistency)

          错误(error)                             特殊(feature)

          事件(incident)                          缺陷(bug)

          异常(anomaly)

          上面所列举的只是众多问题术语的一部分，大家在阅读国外这类书籍的时候不要被这些名词搞得头晕目眩，其实从字典里得出它们的翻译几乎是相同的，在日常会话中它们还具有其它含义。针对软件测试人员来说，完全不需要花太多的时间和精力放在区分这些语汇个体差异的工作上面，“该怎么称呼就怎么称呼”。事实上对每一种软件问题的提及方式只是反映出产品/项目小组他们处理整个开发过程的一种模式。他们是谨慎、小心、直接，还是简单生硬……

  这里我仅引用CSQA对“Defect”的定义让大家对国外测试理念来个第一次亲密接触，另外再简单的提一下国内常讨论的“软件失效分类”的方法及其相互关系。

  （注）后面的章节会单独从应用测试技术的角度重新对软件错误进行分类并且讨论。

   

  Defect：

  From the producer's viewpoint, a defect is a product requirement that has not been met, or a product attribute possessed by a product or a function performed by a product that is not in the statement of requirements that define the product. From the customer's viewpoint, a defect is anything that causes customer dissatisfaction, whether in the statement of requirements or not.

   

  软件失效分类：

  l           软件错误（Software error）：

  软件生命周期内的不希望的或不可接受的人为错误，其结果是导致软件缺陷的产生。（可见，软件错误是一种人为过程，相对于软件本身，是一种外部形为。

   

  l           软件缺陷（Software defect）：

  软件缺陷存是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一逗点、多一语句等。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。

   

  l           软件故障（Software fault）：

  软件故障是指软件运行过程中出现的一种不希望或不可以接受的内部状态。譬如，软件处于执行一个多余循环过程时，我们说软件出现故障。此时若无适当措施（容错）加以及时处理，便产生软件失效。显然，软件故障是一种动态行为。

   

  l           软件失效（Software failure）：

  软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果。

   

  综所上述，软件错误是一种人为错误。一个软件错误必定产生一个或多个软件缺陷。当一个软件缺陷被激活时，便产生一个软件故障；同时一个软件缺陷在不同条件下被激活，可能产生不同的软件故障。软件故障如果没有及时的容错措施施加以处理，便不可避免地导致软件失效；同一个软件故障在不同条件下可能产生不同的软件失效。

   

  （注）Bug 的生命周期

  软件缺陷的生命周期可以这样来说明，缺陷由软件开发的相关活动中人的错误而引起的，例如定义需求，设计程序或编写代码时人所犯的错误。错误被嵌入这个人的工作产品（需求文档，设计文档，或代码）中后就成了故障。

  只要故障（fault也常被称为Bug 或defect）存在于工作产品中，它就有可能引起其它的缺陷。例如，如果在需求文档中存在一个未被发现觉的故障，这个故障很可能引起系统设计、程序设计、代码，甚至是用户文档中的一些缺陷。

  缺陷可能直接失效（failure）发生时才被检测到。失效是用户或测试者所观察到的运行结果与预期的不符。在系统测试阶段，测试工程师的目标就是要通过测试引起系统失效，从而揭露和记录下有关的软件缺陷，进而在系统中消除这些缺陷。缺陷的理想生命周期终止于缺陷在静态或动态测试中被发现并修复。

  查看(31) 评论(0)

• 用人之道

  2008-7-22

     去过庙的人都知道，一进庙门，首先是弥陀佛，笑脸迎客，而在他的北面，则是黑口黑脸的韦陀。但相传在很久以前，他们并不在同一个庙里，而是分别掌管不同的庙。
  　　弥乐佛热情快乐，所以来的人非常多，但他什么都不在乎，丢三拉四，没有好好的管 理账务，所以依然入不敷出。而韦陀虽然管账是一把好手，但成天阴着个脸，太过严肃， 搞得人越来越少，最后香火断绝。
  　　佛祖在查香火的时候发现了这个问题，就将他们俩放在同一个庙里，由弥乐佛负责公 关，笑迎八方客，于是香火大旺。而韦陀铁面无私，锱珠必较，则让他负责财务，严格把 关。在两人的分工合作中，庙里一派欣欣向荣景象。
  　　其实在用人大师的眼里，没有废人，正如武功高手，不需名贵宝剑，摘花飞叶即可伤 人，关键看如何运用。
  

  查看(9) 评论(0)

• 一日不作、一日不食

  2008-7-22

  馬祖創建叢林之後，百丈折衷大、小乘戒律,制定禪院清規。百丈革除了乞食的生活制度，規定禪院上下均力，一齊勞動。他發揚了馬祖平常心是道，行住坐臥都修禪的思想,將禪學運用於勞動實踐，百丈禪師躬身實踐「一日不作，一日不食」的農禪生活，每日除了領眾修行外，也親執勞役，勤苦工作，甚至連日常瑣事也不肯假手弟子。一直到禪師老年之際，他仍是堅持要親身從事粗重的工作。弟子們不忍心禪師已經一把年紀了還上山擔柴、下田耕作，便將他工作用的農具藏起來了。百丈禪師知道了便以堅決的口吻說︰「我無德勞人，人生在世，若不親自勞動，豈不成為廢人。」並真的便不吃飯了。弟子們不得已，只好將農具還給禪師。這時，百丈又歡喜地和大家下田、吃飯、生活。「一日不作、一日不食」成為禪院的精神，而百丈禪師成為叢林的楷模.百丈禪師「一日不作，一日不食」的精神，可謂給那些高空放言的論禪者一個棒喝。參禪不一定要絕棄生活，在生活事務中處處充滿禪機，即使是挑水、種田的勞動工作，都涵蘊著深深的體悟境地。對真正的禪者而言，並不只在打坐念佛、經典文字中求領悟，天地萬物、人生事務中亦處處是禪機。至於俗世中那些大玩語言邏輯錯亂，藉此欲避去正規修行的「假禪者 」，當以百丈禪師之事自我深思之。

  查看(8) 评论(0)

• 新人入职(一)

  2008-7-22

  一位新员工入职的第一天，她一连串的问了我下面这几个问题：

  软件测试是做什么的→测试的产物是什么→如何定义这些bug(产物) →为什么会有这么多的bug→那测试的目标是什么→测试过程中应该遵守哪些规则→我们是做质量工作的，质量的定义又是什么→QA与QC具体的工作内容是什么→QA与QC又有什么差异呢→我应该如何成为一名优秀的测试工程师。

  这里大多涉及到一些软件测试的基本概念，后来整理了一下，写了个小小的培训资料，一一解答。

  什么是软件测试

      软件测试是以发现软件的缺陷为目的而运行或分析软件的过程。

      尽管这个定义很简单，有几点仍然值得进一步详细说明。“过程”这个词是用于强调测试是一组有计划的、有序的活动。如果我们将快速测试视为经过精心设计的，比无计划的测试方法能更快地发现软件缺陷的一种系统化的测试方法的话，“过程”就显得尤为重要。

      根据以上的定义，测试既包括“分析”软件也包括“运行”软件。与分析软件开发中的各种产品相关的测试活动被称为静态测试。静态测试包括代码审查、走查和桌面检查。相比之下，与运行软件有关的测试活动叫做动态测试。静态测试和动态测试相互补充，各自包含特有的缺陷检测方法。

  查看(132) 评论(0)