目录

Summary摘要

内容

Getting Started with Bug Taxonomy从bug分类开始

Creating Your Own Bug Taxonomy制定你自己的bug分类

Summary摘要

In software testing, bug taxonomy involves defining feature categories and collecting lists of possible bugs in each category. These lists can be used to give inexperienced testers some starting points, to help experienced testers brainstorm new ideas, and to evaluate the completeness of a test case. Using an existing bug taxonomy can be useful, but creating your own is even better.

在软件测试中，bug分类涉及定义要素类别和收集每个类别中可能存在的错误的列表。 这些列表可用于为没有经验的测试人员提供一些起点，帮助经验丰富的测试人员集思广益，并评估测试用例的完整性。 使用现有的bug分类法可能很有用，但创建自己的bug分类法会更好。

内容

As part of the research and development department, my team develops new products. R&D has a halo of innovation and discovery, but as I am sure any of you who work in R&D knows, the relative part of the work where we actually do new things is rather seldom. Even when we develop something new, once the actual work starts, most of it means redoing things we have already done.

作为研发部门的一部分，我的团队开发新产品。 研发具有创新和发现的光环，但我相信在研发部门工作的任何人都知道，我们实际做新事物的工作的相对部分很少。 即使我们开发新的东西，一旦实际工作开始，大部分意味着重做我们已经完成的事情。

Some examples: You develop a new embedded wonder that solves world hunger. The final product must be field-upgradeable to be able to solve the ozone layer depletion on version 2.0, so you need a “FW update” feature. Haven’t we done this beforeSure we did! Any embedded system has it. So once again we are facing the same challenges and (alas) the same bugs. It’s the same situation for the install program, a database module, etc. If it’s not our own team that developed something like it before, some other team did something similar and developed test cases. Yet here we are, inventing the wheel once again.

一些例子：你开发了一个解决世界饥饿的新嵌入式奇迹。 最终产品必须可现场升级才能解决版本2.0上的臭氧层耗尽问题，因此您需要“FW更新”功能。 我们以前没有这样做过吗当然，我们做到了！ 任何嵌入式系统都有它。 因此，我们再次面临同样的挑战和（唉）相同的错误。 对于安装程序，数据库模块等，情况也是如此。如果不是我们自己的团队开发了类似的东西，那么其他团队就做了类似的事情并开发了测试用例。 然而，我们在这里重复发明了轮子。

It’s redundant and inefficient. There should be a way to convey accumulated knowledge between projects, between veteran and new engineers, between teams in your organizations, and even between different companies.

这是多余和低效的。 应该有一种方式来传达项目之间，资深工程师和新工程师之间，组织中的团队之间，甚至不同公司之间的累积知识。

Getting Started with Bug Taxonomy从bug分类开始

One way to share knowledge about testing is through bug taxonomy. As the classification term suggests, the general idea is to define feature categories and collect lists of possible bugs in each category.

分享测试知识的一种方法是通过bug分类。 正如分类术语所暗示的那样，一般的想法是定义要素类别并收集每个类别中可能的错误列表。

These lists can be used to help experienced testers by providing more ideas about what needs testing, to give inexperienced testers a list of things that need to be tested and present product aspects they may have not realized need testing (like specific aspects in performance and usability), and to evaluate the completeness of a test case list by selecting items from the taxonomy list and checking whether they are already covered.

这些列表可用于帮助有经验的测试人员提供更多有关测试需求的想法，为经验不足的测试人员提供需要测试的事项列表，并提供他们可能尚未实现需要测试的产品方面（如性能和可用性） ），并通过从分类列表中选择项目并检查它们是否已被覆盖来评估测试用例列表的完整性。

As an example, here is an excerpt of a list from the book Testing Computer Software, by Cem Kaner, Hung Q. Nguyen, and Jack Falk:作为一个例子，这里是Cem Kaner，Hung Q. Nguyen和Jack Falk的书“计算机软件测试”一书的摘录：

Performance 性能

• Slow program程序慢
• Slow echoing响应慢
• Poor responsiveness反应差
• No type-ahead没有提前信息
• No warning that an operation will take a long time没有警告说操作需要很长时间
• No progress reports无进度 告
• Problems with time-outs超时问题

Some of these items are fairly obvious functionalities that need to be tested, and others will trigger ideas for tests we may have missed.

其中一些项目有相当明显的功能需要测试，而其他项目可能让我们有错失某些测试的想法。

For example, the bug “No warning that an operation will take a long time” triggers a number of validation ideas: Are there any functions in our product that may take a long timeUnder what conditionsDo we provide progress trackingIs the tracking accurateIt can also trigger thoughts about redundant features: Do we provide progress tracking for things that will take a very short time, with the result of a window popping up for split second and going away, leaving the user wondering what just happened/p>

例如，“没有警告操作将花费很长时间”的bug会触发许多验证想法：我们的产品中是否有任何其他可能需要很长时间的功能在什么条件下我们提供进度跟踪吗跟踪准确吗它还可以触发有关冗余功能的想法：我们是否需要为很短时间的事情提供进度跟踪，导致窗口弹出一瞬间并消失，让用户想知道刚刚发生了什么/p>

Another interesting thing to note is that some of the ideas in the list have an expiration date. For example, the type-ahead functionality was a requirement for applications in the first generations of computers, when a fast-typing person would easily overrun the screen update speed. With the latest CPUs, this is usually not an issue.

另一个有趣的事情是列表中的一些想法有一个到期日期。 例如，提前输入功能是第一代计算机中应用程序的要求，当快速输入的人很容易超出屏幕更新速度时。 使用最新的CPU，这通常不是问题。

Creating Your Own Bug Taxonomy制定你自己的bug分类

Although I am familiar with a number of taxonomy lists, I never really used them. I tried, but I admit I did not try too hard. So on one hand, I believe taxonomy lists are a good idea, but on the other hand, it can be inconvenient to use them.

虽然我熟悉许多分类法列表，但我从未真正使用它们。 我试过了，但我承认我没有太努力。 所以一方面，我认为分类列表是一个好主意，但另一方面，使用它们可能不方便。

The mindset and thought process of whoever wrote the list is not necessarily (more likely: necessarily not) identical to your way of thinking. The result is that items you’d expect to find under a certain category appear in a category that does not make sense to you. Take an example from the list above. The list developers decided to put “No progress reports” under Performance. I’d expect to see it under the heading User Experience. The language used to describe items, which by the nature of these lists must be terse and concise, also may sometimes be difficult for you to understand.

编写清单的人的心态和思维过程不一定（更可能：必然不是）与你的思维方式相同。 结果是，您希望在特定类别下找到的项目出现在对您没有意义的类别中。 从上面的列表中举例说明。 列表开发人员决定在Performance下添加“No progress reports”。 我希望在用户体验标题下看到它。 用于描述项目的语言，由于这些列表的性质必须简洁明了，有时您可能很难理解。

The result is that to reap the benefit from a taxonomy list for a specific product aspect, you must read large parts of the list, filter out many entries that are irrelevant to your product, and accept that you won’t understand some of the entries—a dubious experience.

结果是，要从特定产品方面的分类列表中获益，您必须阅读列表的大部分内容，过滤掉与您的产品无关的许多条目，并接受您不会理解某些条目  – 一个可疑的经历。

So we have a good idea, but it was implemented in a way that is hard to use. Should we just give up on it/p>

所以我们有一个好主意，但它是以一种难以使用的方式实现的。 我们应该放弃它吗/p>

I don’t think so. One option that I know from experience works well is to develop your own lists for things you encounter repeatedly. Because you wrote the list, the organization will make sense and the language will be clear to you. This increases the likelihood you will use the list on your projects.

I have one such list, prepared a long time ago, outlining aspects of API testing. Every now and then, when I learn or discover a new API coverage item, I add it to the list. No, I will not share this list, for the reason above: that it is written in a format I understand but will not be immediately clear to others. When I do share it, I personally walk through it with the recipients to make sure they understand it. For me, this list is very valuable, and I’ve used it numerous times. I also know of other lists created by others in my company for their own needs.

我有一个这样的列表，很久以前准备的，概述了API测试的各个方面。 我偶尔会在学习或发现新的API覆盖项目时将其添加到列表中。 不，我不会分享这个列表，原因如上：它是以我理解的格式编写的，但不会立即被其他人清楚。 当我分享它时，我亲自与收件人一起浏览，以确保他们理解它。 对我来说，这个清单非常有价值，而且我已经多次使用过它。 我也知道我公司其他人根据自己的需要创建的其他列表。

This anecdotal evidence does not qualify as a rigorous statistical survey, but I do think it points to a possible direction: Bug taxonomy works, but it can work better if you developed the taxonomy list yourself.

这个轶事证据不符合严格的统计调查，但我认为它指出了一个可能的方向：Bug分类法有效，但如果您自己开发分类法列表，它可以更好地工作。

You develop such a list by collecting details over time. You can do this by yourself or as a group, but if you choose the latter, I recommend you invite not only testers, but also developers and product managers, to contribute ideas. You can even take a deep breath, go over published lists, and extract ideas that are relevant to your situation. Even if you won’t find anything directly reusable, it is very likely to trigger some ideas.

您可以通过收集详细信息来开发此类列表。 您可以自己或作为一个小组来完成此任务，但如果您选择后者，我建议您不仅邀请测试人员，还邀请开发人员和产品经理提供想法。 您甚至可以深呼吸，查看已发布的列表，并提取与您的情况相关的想法。 即使您不会发现任何可直接重复使用的内容，也很可能触发一些想法。

Michael Stahl is a SW Validation Architect at Intel. In this role, he defines testing strategies and work methodologies for test teams, and sometimes even gets to test something himself – which he enjoys most. Michael presented papers in SIGiST Israel, STARWest, EuroStar and other international conferences, and is teaching SW Testing in the Hebrew University in Jerusalem. Before starting his career in testing in 2000, Michael worked at Intel’s manufacturing facility in Jerusalem, Israel, as a chip-level test engineer. 

Michael Stahl是英特尔的软件验证架构师。 在这个角色中，他为测试团队定义了测试策略和工作方法，有时甚至可以自己测试一些东西 – 这是他最喜欢的。 Michael在SIGiST Israel，STARWest，EuroStar和其他国际会议上发表论文，并在耶路撒冷的希伯来大学教授SW测试。 在2000年开始测试之前，Michael曾在以色列耶路撒冷的英特尔制造工厂担任芯片级测试工程师。

Michael is an executive board member of the Israeli Test Certification Board (ITCB), holds a full Advanced ISTQB Certification, and chairs ITCB’s advisory board. Some of Michael’s presentations and papers are available on www.testprincipia.com.

Michael是以色列测试认证委员会（ITCB）的执行董事会成员，拥有完整的ISTQB高级认证，并担任ITCB顾问委员会主席。 迈克尔的一些演讲和论文可在www.testprincipia.com上找到。