转载:软件测试常用词汇汇总(英文版)
Bugs that are undiscovered or haven't yet been observed are often referred to as latent bugs 没有被发现的或没被观测到的bug就是通常所说的潜在的bug。
If this is as clear as mud, don't worry. Discuss it with your peers in software testing and find out what they think. Listen to others' opinions, test their ideas, and form your own definition. Remember the old question, "If a tree falls in the forest and there's no one there to hear it, does it make a sound?"
假如这些bug如泥浆一样混乱,也别担心。同您所在的软件测试团队成员一起探讨,并得出他们的想法。倾听别人的意见,验证他们的想法,然后形成您自己的观点。记住这个古老的疑问,“假如森林里有一棵树倒下了,但没有人听到,那么它算发出了声音吗?”
Product Specifications Are Never Final
《产品需求规格说明书》永远没有最终版
Software developers have a problem. The industry is moving so fast that last year's cutting-edge products are obsolete this year. At the same time, software is getting larger and gaining more features and complexity, resulting in longer and longer development schedules. These two opposing forces result in conflict, and the result is a constantly changing product specification.
软件开发人员有这样一个问题。软件行业发展速度如此之快,去年正流行的产品,今年就落伍了。同时,软件自身又变得越来越庞大,功能越来越多,越来越复杂,产品的开发周期也越来越长。这两股背道而驰的力量导致了冲突,最后结果就是《产品需求规格说明书》不断的变化。
There's no other way to respond to the rapid changes. Assume that your product had a locked-down, final, absolutely-can't-change-it product spec. You're halfway through the planned two-year development cycle, and your main competitor releases a product very similar to yours but with several desirable features that your product doesn't have. Do you continue with your spec as is and release an inferior product in another year? Or, does your team regroup, rethink the product's features, rewrite the product spec, and work on a revised product? In most cases, wise business dictates the latter.
再也没有更多的办法来应对如此快速的变化。假设您的产品拥有一个固定下来的,最终的,绝对不能改变的《产品需求规格说明书》。您正好处于规划好的两年开发周期的中途,此时您的主要竞争对手发行了一个类似的产品,而且其中几个非常吸引人的功能是您的产品不具备的。您会继续按照您的《产品规格说明书》开发下去,然后在下一年发行一个没有竞争优势的产品吗?或者,重新组织您的开发团队,重新构思产品的功能,重新书写《产品规格说明书》,然后继续这个修订过的产品?大多数情况下,英明的商人都会选择后者。
As a software tester, you must assume that the spec will change. Features will be added that you didn't plan to test. Features will be changed or even deleted that you had already tested and reported bugs on. It will happen. You'll learn techniques for being flexible in your test planning and test execution in the remainder of this book.
作为一名软件测试人员,您必须假定《需求说明书》会变,会让您去测试以前没有规划过的功能。您已经测试并且报告过bug的功能,也有可能会改变甚至删除。这些都会发生。本书后面的章节中,您将会学习到怎样灵活处理测试计划、测试执行当中遇到的这些情况。
Software Testers Aren't the Most Popular Members of a Project Team
软件测试人员不是项目团队中最受欢迎的成员。
Remember the goal of a software tester?
还记得软件测试人员的目标吗?
The goal of a software tester is to find bugs, find them as early as possible, and make sure they get fixed.
软件测试人员的目标就是,寻找bug,尽早发现bug,并且保证bug被修复。
Your job is to inspect and critique your peer's work, find problems with it, and publicize what you've found. Ouch! You won't win a popularity contest doing this job.
您的工作就是去检查并指正您的同事的工作,寻找他们的问题,然后大肆宣扬您发现的问题。哎!做这项工作,可不会让您赢得一项“最受欢迎奖”。
Here are a couple of tips to keep the peace with your fellow teammates:
这里有一些小技巧可以让您和您的同事和平相处。
Find bugs early. That's your job, of course, but work hard at doing this. It's much less of an impact and much more appreciated if you find a serious bug three months before, rather than one day before, a product's scheduled release.
尽早发现bug。当然,那是您的工作,但是做起来就难了。您在三个月前发现一个严重的bug,比在产品发布前一天发现这个bug,产生的影响要小得多而且价值大得多。
Temper your enthusiasm. Okay, you really love your job. You get really excited when you find a terrible bug. But, if you bounce into a programmer's cubicle with a huge grin on your face and tell her that you just found the nastiest bug of your career and it's in her code, she won't be happy.
掌控好您的激情。是的,您十分热爱您的工作。当您发现一个严重的bug时,您会兴奋不已。但是,假如您露着牙齿笑哈哈的跳进一个程序员的小房间,然后告诉她,您发现了在您职业生涯中最糟糕的一个bug,而且这个bug就是她写出来的,她是高兴不起来的。
Don't just report bad news. If you find a piece of code surprisingly bug free, tell the world. Pop into a programmer's cubicle occasionally just to chat. If all you ever do is report bad news, people will see you coming and will run and hide.
不要只报告坏消息。假如您发现一段代码是那样的完美无缺,告诉全世界吧!偶尔拿到程序员的小房间里去谈论。假如您一味的只是报告坏消息,人们看见你就会藏起来了。
Software Testing Is a Disciplined Technical Profession
软件测试是训练有素的技术类职业。
It used to be that software testing was an afterthought. Software products were small and not very complicated. The number of people with computers using software was limited. And, the few programmers on a project team could take turns debugging each others' code. Bugs weren't that much of a problem. The ones that did occur were easily fixed without much cost or disruption. If software testers were used, they were frequently untrained and brought into the project late to do some "ad-hoc banging on the code to see what they might find." Times have changed.
以前人们通常认为软件测试只是事后诸葛。软件产品很小而且不复杂。大部分拥有电脑的人们使用软件都会受到限制。并且,项目团队里的少数程序员可以轮流调试每个人的代码。Bug并不是那么严重的问题。即使出现一个问题也不会需要花很大的成本去修复,也不会造成破坏。假如有软件测试人员在里面工作,通常也是没经过训练的,使得项目没有更多的时间去做“针对代码的随机测试,以期望有所发现。”时代已经变了。
Look at the software help-wanted ads and you'll see numerous listings for software testers. The software industry has progressed to the point where professional software testers are mandatory. It's now too costly to build bad software.
看看软件帮助广告,您会发现里面列出了大量的软件测试人员。软件行业已经进步了,职业软件测试人员已经成为强制需求了。现在做一个糟糕的软件,成本太大了。
To be fair, not every company is on board yet. Many computer game and small-time software companies still use a fairly loose development model usually big-bang or code-and-fix. But much more software is now developed with a disciplined approach that has software testers as core, vital members of their staff.
不过,还要清楚的看到,不是每一个公司都“上船”了。很多电脑游戏和小规模的软件公司仍然使用简单松散的开发模型,比如“大爆炸模型”,“编码与修复模型”。但是更多的软件是通过训练有素的方法开发出来的,他们以软件测试人员为核心,软件测试人员是整个团队的重要成员。
This is great news if you're interested in software testing. It can now be a career choice a job that requires training and discipline, and allows for advancement.
假如您对软件测试产生了兴趣,这是一则伟大的新闻。现在它可以作为一个训练有素,而且打算进步的职业来供选择了
WHAT HAPPENS WHEN YOU MAKE THE WRONG DECISION?
当您做出错误的决策后,会有什么后果?
Remember the Intel Pentium bug described in Chapter 1? The Intel test engineers found this bug before the chip was released, but the product team decided that it was such a small, rare bug that it wasn't worth fixing. They were under a tight schedule and decided to meet their current deadline and fix the bug in later releases of the chip. Unfortunately, the bug was discovered and the rest, they say, is history.
还记得第一章中提到的英特尔奔腾处理器的bug吗?在芯片发布以前英特尔的工程师就发现了这个bug,但开发该产品的团队觉得这个bug是如此之小,如此的罕见,以至于没有必要去修复它。他们当时在紧张的项目进度下,最终还是决定发行芯片,bug留到下一个版本再修复。不幸的是,这个bug被发现了,其它的计划都成已为历史。
In any piece of software, for every "Pentium type" bug that makes the headlines, there could be perhaps hundreds of bugs that are left unfixed because they were perceived to not have a major negative effect. Only time can tell if those decisions were right or wrong.
任何一款软件里,可能都有数百个能够制造头条新闻的“奔腾式”bug,没有被修复,因为他们觉得这些bug都没有重大的负面影响。只有时间才能告诉我们决策的对与错。
When a Bug's a Bug Is Difficult to Say
很难说一个bug究竟什么时候才是bug。
If there's a problem in the software but no one ever discovers it not programmers, not testers, and not even a single customer is it a bug?
假如软件里有一个问题,程序员没有发现它,测试人员也没有发现它,甚至单独的一个用户也没有发现它,所有的人都没有发现它,那么这个问题算是一个问题吗?
Get a group of software testers in a room and ask them this question. You'll be in for a lively discussion. Everyone has their own opinion and can be pretty vocal about it. The problem is that there's no definitive answer. The answer is based on what you and your development team decide works best for you.
你去问一个软件测试团队这样一个问题。您将要参加一场活跃的讨论会。人人都有他们自己的看法,而且都能完美的表达出来。但问题是始终得不出一个最后的答案。您和您的开发团队究竟需要确定一个什么样的作品。
For the purposes of this book, refer back to the rules to define a bug from Chapter 1:
为了实现本书的目的,请参考第一章提到的“定义一个bug的规则“:
The software doesn't do something that the product specification says it should do.
软件没有做《产品需求规格说明书》中规定应该做的事情。
The software does something that the product specification says it shouldn't do.
软件做了《产品需求规格说明书》中规定不应该做的事情。
The software does something that the product specification doesn't mention.
软件做了《产品需求规格说明书》中没提到的事情。
The software doesn't do something that the product specification doesn't mention but should.
软件没有做《产品需求规格说明书》中没提到但应该做的事情。
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.
软件难以理解,难用,速度慢,或者在测试人员看来,软件将会被客户看成是没有格式、不正确的。
Following these rules helps clarify the dilemma by making a bug a bug only if it's observed. To claim that the software does or doesn't do "something" implies that the software was run and that "something" or the lack of "something" was witnessed. Since you can't report on what you didn't see, you can't claim that a bug exists if you didn't see it.
依照这些规则并仔细考察,将会帮助您确定一个bug究竟是不是bug。主张软件做了或没做什么事情就意味着运行了软件,它做的这些事情或者没有做的这些事情就是证据。以后,您就不能报告您没有发现的,您不能说这是一个bug,如果您没有发现它。
Here's another way to think of it. It's not uncommon for two people to have completely different opinions on the quality of a software product. One may say that the program is incredibly buggy and the other may say that it's perfect. How can both be right? The answer is that one has used the product in a way that reveals lots of bugs. The other hasn't.
还有另一种思路。两个人在同一款软件产品质量上,拥有完全不同的看法,这是很正常的。一个人说程序到处是bug不能用,另一个却说它是完美的。怎么可能大家都对呢?原因在于其中一个人使用产品的方法可以发现大部分的bug,而另一个人没有用这样的方法。
Testing Can't Show That Bugs Don't Exist (测试不能说明系统没有bug)
Think about this for a moment. You're an exterminator charged with examining a house for bugs. You inspect the house and find evidence of bugs maybe live bugs, dead bugs, or nests. You can safely say that the house has bugs.
想想这句话。您装满了杀虫剂准备清除屋里的臭虫。您检查屋子并发现了很多臭虫,有活着的,有死的,还有它们的巢穴。你可以确切地说这屋里有臭虫。
You visit another house. This time you find no evidence of bugs. You look in all the obvious places and see no signs of an infestation. Maybe you find a few dead bugs or old nests but you see nothing that tells you that live bugs exist. Can you absolutely, positively state that the house is bug free? Nope. All you can conclude is that in your search you didn't find any live bugs. Unless you completely dismantled the house down to the foundation, you can't be sure that you didn't simply just miss them.
同样的您去了另一个屋子。这次您并没有发现很多的臭虫。您找遍了以前发现臭虫的地方,并没有臭虫出没的征兆。也许您会发现一个刚死去的臭虫或者一个老的巢,但是并没有能证明有活着臭虫存在的痕迹。您能完全肯定的声明这屋里没有臭虫了吗?不,您能做出的结论只是,您搜索的时候没有发现任何活着的臭虫。除非您将这屋翻个底朝天,您就可以说您没有轻易的漏掉它们。
Software testing works exactly as the exterminator does. It can show that bugs exist, but it can't show that bugs don't exist. You can perform your tests, find and report bugs, but at no point can you guarantee that there are no longer any bugs to find. You can only continue your testing and possibly find more.
软件测试就像刚才查臭虫一样。她可以说有bug存在,但不能说没有bug。您可以执行您的测试,然后找到并报告bug,但是您不能保证系统再也找不出bug了。您只能继续您的测试然后可能发现更多的bug。
The More Bugs You Find, the More Bugs There Are
发现的bug越多,那么存在的bug也就越多。
There are even more similarities between real bugs and software bugs. Both types tend to come in groups. If you see one, odds are there will be more nearby.
系统发现的bug和系统仍存在的bug具有某种相似性。同类Bug趋向于成群出现。假如您在某个模块发现一个bug,那么继续在该模块附近发现bug的几率就会更大。
Frequently, a tester will go for long spells without finding a bug. He'll then find one bug, then quickly another and another. There are several reasons for this:
通常情况下,测试人员做了很多检查都没有发现bug。一旦他发现一个bug,那么很快他就会发现另一个,然后又一个bug。之所以是这样,是因为如下几种原因:
Programmers have bad days. Like all of us, programmers can have off days. Code written one day may be perfect; code written another may be sloppy. One bug can be a tell-tale sign that there are more nearby.
程序员有状态不好的时候。像我们一样,程序员也会有休息日。某天编写的代码可能非常完美;另一天编写的代码就可能就比较糟糕。所以一个bug的存在,传递的就是该模块附近还有更多的bug。
Programmers often make the same mistake. Everyone has habits. A programmer who is prone to a certain error will often repeat it.
程序员通常犯同样的错误。人人都有自己的习惯。一名程序员倾向于犯某种类型的错误,他就会经常重复它。
Some bugs are really just the tip of the iceberg. Very often the software's design or architecture has a fundamental problem. A tester will find several bugs that at first may seem unrelated but eventually are discovered to have one primary serious cause.
有些bug真的只是一个表象。很多时候软件设计人员或架构师埋下了一个基础性的问题。一名测试人员刚开始发现几个bug看似都不相关,但最终会发现这些bug其实都由一个主要原因引起。
It's important to note that the inverse of this "bugs follow bugs" idea is true, as well. If you fail to find bugs no matter how hard you try, it may very well be that the feature you're testing was cleanly written and that there are indeed few if any bugs to be found.
还需要特别注意的是“bug群集”现象。假如不管您做了多少努力都没有发现bug,那么说明您测试的这部分可能确实写的好,即使发现bug也是很少的。
Software Testing Is a Risk-Based Exercise (软件测试是基于风险的演练)
If you decide not to test every possible test scenario, you've chosen to take on risk. In the calculator example, what if you choose not to test that 1024+1024=2048? It's possible the programmer accidentally left in a bug for that situation. If you don't test it, a customer will eventually enter it, and he or she will discover the bug. It'll be a costly bug, too, since it wasn't found until the software was in the customer's hands.
假如您决定并不是将所有可能的测试场景都做测试,那您就选择了承担风险。在计算器的例子中,假如您选择不做测试的用例是1024+1024=2048。那么程序员很可能就刚好在这里留下一个bug。假如您不测它,那么这个bug就留到了客户那里,最后被客户发现。这个bug的代价也就放大了,从软件被送到客户手中仍没被发现开始。
This may all sound pretty scary. You can't test everything, and if you don't, you will likely miss bugs. The product has to be released, so you will need to stop testing, but if you stop too soon, there will still be areas untested. What do you do?
这回您可能玄乎了。您不可能完全测试,但不完全测试的话,您又可能会放走bug。产品已经发布了,您需要停止测试,但您立即停止的话,又会有未测试到的部分。那您到底该怎么办?
One key concept that software testers need to learn is how to reduce the huge domain of possible tests into a manageable set, and how to make wise risk-based decisions on what's important to test and what's not.
软件测试人员需要知道的一个关键概念就是,怎样将庞大的测试域精简成可管理的测试集合,以及怎样根据,哪些重要需要被测试,那些不重要可以不测试,来建立起良好的风险决策。
Figure 3.2 shows the relationship between the amount of testing performed and the number of bugs found. If you attempt to test everything, the costs go up dramatically and the number of missed bugs declines to the point that it's no longer cost effective to continue. If you cut the testing short or make poor decisions of what to test, the costs are low but you'll miss a lot of bugs. The goal is to hit that optimal amount of testing so that you don't test too much or too little.
图3.2显示出测试执行的数量和bug发现数量之间的关系。假如您尝试完全测试,那么成本将显著增长,当然放走的bug也会下降到没必要继续进行有效的测试为止。假如您减少测试或者决定只需做少量的测试,那么成本将会很低,但是您放走的bug将会很多很多。总之,目标就是寻找最优的测试数量,这样您才不会过多、或过少的测试。
Figure 3.2. Every software project has an optimal test effort.
图3.2 。每一个软件工程都有一个最优的测试点。