用最简单的方法,做最复杂的测试。

Software Testing - SE By Ron Patton - What Is a Bug?

上一篇 / 下一篇  2010-10-08 15:29:58 / 个人分类:Translation

What Is a Bug?

You’ve just read example of what happens when software fails. It can be inconvenient, as when a computer game doesn’t work properly, or it can be catastrophic, resulting in the loss of life. It can cost only pennies to fix but millions of dollars to distribute a solution. In the examples, above, it was obvious that the software didn’t operate as intended. As a software tester you’ll discover that most failures are hardly ever this obvious. Most are simple, subtle failure, with many being so small that it’s not always clear which ones are true failures, and which ones aren’t.

刚刚读到由于软件失效会发生什么后果的例子。当一个计算机游戏不能很好的运行的时候,可能只是让你觉得不太舒服,或者也有可能导致失去生命的惨重后果。也许修复一个问题只要几美分,但是发布一个解决方案却需要花费百万美元。在上面的例子中,很明显软件没有按设想的那样运行。作为一个软件测试员,你会发现大多数的软件错误都不外乎是这种情况。大多数都是简单的,细微的错误,很多都是如此之小以至于根本无法分辨哪些是失效的,哪些不是。

 

Terms for Software Failures

Depending on where you’re employed as a software tester, you will use different terms to describe what happens when software fails. Here are a few:

Ÿ  Defect

Ÿ  Fault

Ÿ  Problem

Ÿ  Error

Ÿ  Incident

Ÿ  Anomaly

Ÿ  Variance

Ÿ  Failure

Ÿ  Inconsistency

Ÿ  Feature

Ÿ  Bug

(There’s also a list of unmentionable terms, but they’re most often used privately among programmers.)

软件故障术语

根据你所在的公司不同,你可能会用不同的术语来描述软件错误的情况。下面列出了一部分:

Ÿ  缺陷

Ÿ  故障

Ÿ  问题

Ÿ  错误

Ÿ  事故

Ÿ  异常

Ÿ  不一致

Ÿ  失效

Ÿ  矛盾

Ÿ  特征

Ÿ  臭虫

(当然,还有一些这里没有提到的术语,不过这些都是程序员私下交流时使用的。)

 

You might be amazed that so many names could be used to describe a software failure. Why so many? It’s all really based on the company’s culture and the process the company uses to develop its software. If you look up these words in the dictionary, you’ll find that they all have slightly different meanings. They also have inferred meanings by how they’re used in day-to-day conversation.

For example,fault,failure, anddefecttend to imply a condition that’s really severe, maybe even dangerous. It doesn’t sound right to call an incorrectly colored icon afault. These words also tend to imply blame: “It’s his fault that the software failed.”

Anomaly,incident, andvariancedon’t sound quite so negative and are often used to infer unintended operation rather than all-out failure. “The president stated that it was a software anomaly that caused the missile to go off course.”

Problem,error, andbugare probably the most generic terms used.

JUST CALL IT WHAT IT IS AND GET ON WITH IT

It’s interesting that some companies and product teams will spend hours and hours of precious development time arguing and debating which term to use. A well-known computer company spent weeks in discussion with its engineers before deciding to rename Product Anomaly Reports (PARs) to Product Incident Reports (PIPs). Countless dollars were spent in the process of deciding which term was better. Once the decision was made, all the paperwork, software, forms, and so on had to be updated to reflect the new term. It’s unknown if it made any difference to the programmer’s or tester’s productivity.

 

So, why bring this topic up? It’s important as a software tester to understand the personality behind the product development team you’re working with. How they refer to their software problems is a tell-tale sign of how they approach their overall development process. Are they cautious, careful, direct, or just plain blunt?

Although your team may choose a different name, in this book, all software problems will be calledbugs. It doesn’t matter if it’s big, small, intended, unintended, or someone’s feelings will be hurt because they create one. There’s no reason to dice words.A bug’s a bug’s a bug.

你可能很吃惊会有这么多名词用来描述一个软件错误。为什么会有这么多呢?实际上这取决于公司的文化和软件开发过程。如果你在词典中查找这些单词,你会发现他们的意思基本相同,但又都有一点点细微的区别。而在日常的使用中,他们又会引申出一些其他含义。

例如,故障失效和缺陷趋向于暗示真的很严重,甚至是危险的情况。把一个图标使用了不正确颜色的问题称为“故障”,听起来就不太妥当了。这些单词还往往意味着责备:“软件的失效是他的错”。

异常、事故和不一致,听起来没有那么负面消极,相对于整个系统的失效来说,这些词只是用来推断系统进行了意外的操作。“罗纳德.里根总统声明导致导弹偏离航程的原因只是一个软件异常”。

问题、错误和臭虫可能是最通用的术语了。

 

它是什么就叫它什么,然后继续就是了。

很有趣的是一些公司和开发团队,往往会在开发前期花费数小时去争论该用哪一个术语。一个知名计算机公司花了数周时间去和工程师讨论,最后决定把《产品异常报告》改名为《产品事故报告》。数不清的美元花费在决定哪一个术语更好的讨论过程中。一旦有了结论,需要更新受到该新术语影响的所有文档、软件和表单等资料。不知道这样做是否让程序员和测试员的工作效率有了什么不同。

 

那么,为什么提到这个话题呢?作为一个软件测试员,很重要的一点就是你要明白你所一起工作的产品开发小组成员之间是存在个性差异的。如何提出软件问题是如何处理整个软件开发过程的信号标志。是不是谨慎的、仔细的、直接的,或是生硬的?

无论你的团多选择使用什么名称,在这本书里,所有的软件问题都将被称为bugs。不论它是大的、小的、预料中的、意外的,或是因为某人制造了这个问题而伤害到他的感情。没有必要为了过分的斟酌词语。一个错误的错误的错误。

 

Software Bug: A Formal Definition

Calling any and all software problemsbugsmay sound simple enough, but doing so hasn’t really addressed the issue. Now the wordproblemneeds to be defined. To keep from running in circular definitions, there needs to be a definition description of what a bug is.

 

软件缺陷的官方定义

把所有的软件问题都成为缺陷,听起来很简单,但是这样做确实没有定位问题。措辞问题现在必须定义清楚。为了防止循环定义,我们必须确切地定义bug

 

First, you need a supporting term:product specification. A product specification, sometimes referred to as simply as aspecorproduct spec, is an agreement among the software development team. It defines the product they are creating, detailing what it will be, how it will act, what it will do, and what it won’t do. This agreement can range in form. from a simple verbal understanding, an email, or a scribble on a napkin, to a highly detailed, formalized written document. In Chapter 2, “The Software Development Process,” you will learn more about software specifications and the development process, but for now, this definition is sufficient.

For the purposes of this book and much of the software industry, asoftware bugoccurs when one or more of the following five rules is true:

1.     The software doesn’t do something that the product specification says it should do.

2.     The software does something that the product specification says it shouldn’t do.

3.     The software does something that the product specification doesn’t mention.

4.     The software doesn’t do something that the product specification doesn’t mention but should.

5.     The software is difficult to understand, hard to use, slow, or---in the software tester’s eyes---will be viewed by the end user as just plain not right.

首先,你需要一个支撑的术语:《产品规格说明书》。《产品规格说明书》有时简称为《说明书》或者《产品说明书》,这是软件开发团队的共同协议。具体定义正在开发的软件将是什么样子、如何行动、会做什么和不会做什么。协议可能以以下形式出现,从一个简单的口头约定、一封邮件,或者写在餐巾纸上的草稿,到一份非常详细的正式的书面文档。在第二章“软件的开发过程”中,你将学到更多关于《软件规格说明书》和软件开发过程的东西,但是目前,这个定义已经足够了。

针对本书的目的和软件业的大多数观念,当以下的一个或多个规则成立时,一个软件的bug就出现了:

1.     软件没有做《产品规格说明书》中要求做的一些事情。

2.     软件做了《产品规格说明书》中要求不该做的一些事情。

3.     软件做了《产品规格说明书》中没有提到的一些事情。

4.     软件没有做《产品规格说明书》中没有特岛但是应该做的一些事情。

5.     软件难以理解、使用不便、运行速度慢,或者---在软件测试员眼里---同样在最终用户看来显然是不正确的。

 

To better understand each rule, try the following example of applying them to a calculator.

The specification for a calculator probably states that it will perform. correct addition, subtraction, multiplication, and division. If you, as the tester, receive the calculator, press the + key, and nothing happens, that’s a bug because of Rule #1. If you get the wrong answer, that’s also a bug because of Rule #1.

The product spec might state that the calculator should never crash, lock up, or freeze. If you pound on the keys and get the calculator to stop responding to your input, that’s a bug because of Rule #2.

Suppose that you receive the calculator for testing and find that besides addition, subtraction, multiplication, and division, it also performs square roots. Nowhere was this ever specified. An ambitious programmer just threw it in because he felt it would be a great feature. This isn’t a feature---it’s really a bug because of Rule #3. The software is doing something that the product specification didn’t mention. This unintended operation, although maybe nice to have, will add to the test effort and will likely introduce even more bugs.

The fourth rule may read a bit strange with its double negatives, but its purpose is to catch things that were forgotten in the specification. You start testing the calculator and discover when the battery gets weak that you no longer receive correct answers to your calculations. No one ever considered how the calculator should react in this mode. A bad assumption was made that the batteries would always be fully charged. You expected it to keep working until the batteries were completely dead, or at least notify you in some way that they were weak. Correct calculations didn’t happen with weak batteries, and it wasn’t specified what should happen. Rule #4 makes this a bug.

Rule #5 is the catch-all. As a tester you are the first person to really use the software. If you weren’t there, if would be the customer using the product for the first time, If you find something that you don’t feel is right, for whatever reason, it’s a bug. In the case of the calculator, maybe you found that the buttons were too small. Maybe the placement of the = key made it hard to use. Maybe the display was difficult to read under bright lights. All of these are bugs because of Rule #5.

为了更好的理解每一个规则,尝试以下离子:把这些规则运用到计算器上。

一个计算器的《说明书》可能会声明它能够执行正确的加法、减法、乘法和除法。如果你作为测试员去测试这个计算器,当你按下加号键的时候,什么都没有发生,那么这是规则一描述的bug。如果你得到了错误的答案,那也是规则一描述的bug

《产品说明书》可能会声明计算器应该从不死机,死锁或者停止工作。如果你连续敲击按键,并且使得计算器停止响应你的输入,那是规则二描述的bug

假设你测试一个计算器,并且发现计算器除了加法、减法、乘法和除法以外还能执行平方根运算。没有哪个地方定义过这个功能。一个有抱负的程序员只是觉得这是一个强大的功能,所以把它加了进来。这不是一个功能---这完全就是规则三描述的bug。软件做了产品说明书没有提到的一些事情。这个未计划的操作,哪怕也许它是好,增加了测试的工作量,甚至可能引进更多的bugs

规则四读起来可能有点奇怪,这里有一个双重否定,但是它的目的是捕获那些在说明书中被遗漏的东西。在你开始测试计算器的时候发现当计算器电池能量快耗尽的时候,计算器就再也不能得到正确的答案了。没有人考虑到,计算器该如何应对电池能量不足的情况。一个糟糕的假设就是,电池总是被充满电的。你希望计算器会继续正常工作直到电池耗尽,或者至少以某种方式提醒你电池能量不足了。当电池能量不足的时候计算器是得不到正确结果的,这种情况时不应发生的。规则四描述了这个bug

规则五是包罗万象。作为一个测试员,你是第一个实际使用这个软件的人。假如没有你,客户将会是第一个使用该软件的人。如果你发现了一些你觉得不太对的地方,那就是一个bug。在计算器的例子中,也许你觉得按键太小。也许“=”键的位置不合理导致使用困难。也许显示屏太亮导致看不清。这些都是规则五描述的bugs

 

NOTE

Every person who use a piece of software will have different expectation and opinions as to how is should work. It would be impossible to write software that every user thought was perfect. As a software tester, you should keep this in mind when you apply Rule #5 to your testing. Be thorough, use your best judgment, and, most importantly, be reasonable. Your opinion counts, but, as you’ll learn in later chapters, not all the bugs you find can or will be fixed.

 

These are greatly simplified examples, so think about how the rules apply to software that you use every day. What is expected, what is unexpected? What do you think was specified and what was forgotten? And, what do you just plain dislike about the software?

This definition of a bug covers a lot of ground but using all five of its rules will help you identify the different types of problems in the software you’re testing.

注意

每一个使用软件的人,对于软件该如何工作都有不同的预期和看法。想要开发一个人人都觉得完美的软件是不太可能的。作为一个软件测试员,当你应用规则五的时候你应该时刻牢记这点。彻底地利用你的判断力,而且最重要的是要合理。你的看法会被接纳,但是,正如你将在以后章节中学到的,不是所有的bugs都会被修复。

 

这里是一些被大大简化的例子,所以想想你如何把这些规则运用到你日常使用的软件中去。什么是期望的,什么是不期望的?你觉得需要的东西哪些已被指定,哪些被遗漏了?以及软件的哪些方面显然是你不喜欢的?

这些bug的定义覆盖的很广,但是运用上面提到的这五个规则,将帮助你在软件测试工作中之别不同类型的问题。


TAG: Bug edition Edition PATTON Patton Ron RON second software Software Testing testing bug

 

评分:0

我来说两句

日历

« 2024-03-18  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 17860
  • 日志数: 46
  • 建立时间: 2010-08-18
  • 更新时间: 2010-10-11

RSS订阅

Open Toolbar