【推荐原文】How to Write Better Test Cases

bunny112

原文作者：Dianne L.Runnels
原文出处：http://www.docstoc.com/docs/2551 ... e-Better-Test-Cases
推荐理由：对大家写好测试用例有一定的帮助

http://www.docstoc.com/docs/2551 ... e-Better-Test-Cases

版主注：本文已收录于51testing软件测试杂志第十一期，查看译文请点击：
http://www.51testing.com/html/90/n-96790.html
http://www.51testing.com/html/05/n-96805.html
http://www.51testing.com/html/13/n-96813.html
http://www.51testing.com/html/15/n-96815.html

windone

我做的是嵌入式测试。觉得最重要的就是测试用例的设计了。
很想好好的学习一下。

不知道这部文档有人翻译吗？如果可以的话算上我吧。msn：wangzjj@gmail.com

maocai_wang

如果有译文，可以发我邮箱吗/谢谢,我的邮箱：jerrywmc@qq.com

xueyuhanchen

nothing??

51testing

想翻译的请马上联系我呀,先下载申请表格:http://www.51testing.com/batch.download.php?aid=6647.填好发到我邮箱：jiangyuli@51testing.com

Juix

没有看到文章在那里呀？

junjun19830209

文章呢？？？

没看见啊

fun_nini

表格下载不了

fun_nini

xiazhi799@163.com

vickywong

没有看到内容

cyclone252

我现在做的是单元测试，我觉得这本非常不错，如果哪位高手翻译好了，请发我一份：changkong918@hotmail.com谢谢啦！！！

caueva2006

How to Write Better Test Cases
如何编写更好的测试用例
by Dianne L. Runnels, CQA, CSTE
Interim Technology Consulting
Investing in test cases
投资于测试用例
What is it worth to improve test cases? What risk would impel you to invest in better test cases? As long as they cover the software requirements, isn't that good enough? The answer to these questions is that poor test cases do indeed expose you to considerable risk. They may cover the requirements in theory, but are hard to test and have ambiguous results. Better tests have more reliable results as well as lowering costs in three categories:
为了改进测试用例什么是值得做的？什么风险会促使你投资更好的测试用例？只要测试用例达到了软件的需求，是不是就足够好了呢？答案是劣质的测试用例的确会使你遭受相当大的风险。也许这些测试用例在理论上达到了需求，但是它们难以测试并且产生含糊不清的结果。较好的测试用例具有更加可靠的测试结果，并且可以在以下三方面降低成本：

1.        Productivity - less time to write and maintain cases
生产率——花费较少的时间去编写和维护测试用例
2.        Testability - less time to execute them
易测性——花费较少的时间来执行测试用例
3.        Scheduling reliability- better reliability in estimates
调度的可靠性——在评估中更高的可靠性
This paper describes how to avoid the losses that are inevitable with poor test cases. It will look under the hood of different kinds of test cases and show where and how to build in the quality that controls risk. It will give practical advice on how to improve productivity, usability, scheduling reliability, and asset management. Once you understand the whats and whys of test cases, you can use a checklist of standards, like the one attached as Appendix A, to identify areas of risk and improve your current and future test cases.
本文描述了如何避免因劣质测试用例导致的必然的损失。本文将针对各种不同的测试用例阐明在何处以及如何提高测试用例的质量以控制风险。本文将对如何提高生产率、可用性、调度可靠性和资产管理等方面给出可行的建议。当你明白了什么是测试用例和测试用例编写的理由，你就可以运用一系列的检查标准，比如附录A所列的清单，来识别风险领域和提高当前和将来的测试用例的质量。

The most extensive effort in preparing to test software is writing test cases. The incentive to build robust test cases is spurred by the likelihood they will be reused for maintenance releases. Over half of all software development is maintenance projects. How can you write quality test cases that will deliver economical testing the first time plus live again as regression tests? Let's get started with the answer by lifting the hood of a test case and looking at what's inside.
在准备软件测试过程中，需要付出最大努力的是编写测试用例。测试用例可以在维护版本中重新使用的可能性激励人们构建健壮的测试用例。超过半数以上的软件开发项目是维护项目。你将如何编写优秀的将在第一时间用于经济测试的用例？让我们通过揭开测试用例的面纱，探索测试用例究竟包含哪些内容来寻找问题的答案，以此开始本文的论述。
Looking inside test cases
深入了解测试用例内部
Elements of test cases
测试用例的构成
For our purposes, a test case is a set of actions with expected results based on requirements for the system. The case includes these elements:
针对我们的目标，测试用例由一系列动作以及基于系统要求的预期结果组成。测试用例包括这些组成：
•The purpose of the test or description of what requirement is being tested
测试目的或测试要求描述
•The method of how it will be tested
如何进行测试的方法
•The setup to test: version of application under test, hardware, software, operating system, data files, security access, time of day, logical or physical date, prerequisites such as other tests, and any another other setup information pertinent to the requirement(s) being tested
测试设置：被测试应用程序的版本，测试中使用的硬件、软件、操作系统、数据文件及安全访问，测试时间，逻辑或物理日期，测试的先决条件如其他测试和与测试要求相关的其他设置信息。
•Actions and expected results, or inputs and outputs
测试行为和预期结果，或者输入和输出。
•Any proofs or attachments (optional)
任何证据或附件（可选）
These same elements need to be in test cases for every level of testing -- unit, integration, system, or acceptance testing. They are valid for functional, performance, and usability testing. The "expected results" standard does not apply to diagnostic or other testing of an exploratory nature. Even diagnostic testing needs the other elements in its cases. However, if the test measures performance that should fall in a range, this is an expected result.每个层次的测试——单元测试、集成测试、系统测试和验收测试的测试用例都需要以上相同的组成。这些组成对功能测试、性能测试和易用性测试都是有效的。“预期结果”的标准并不适用于探索性质的诊断型测试或其他测试。即使是诊断性测试用例也需要其他组成元素。
An alternate description of test cases is that the description, purpose, and setup is the case or
specification. The steps to accomplish it are called a script. Yet another view calls the purpose or description a scenario or use case. These views are all compatible with the quality assessments and improvements suggested in this paper.
测试用例的另一种描述是：描述、目的和设置即为测试用例或测试说明。完成测试用例的步骤被称为脚本。但是，另一种观点把测试目的或描述称为场景或用例。这些观点都与本文提出的质量评估和改善相一致。

（未完，待续）

[ 本帖最后由 caueva2006 于 2010-7-6 18:21 编辑 ]

caueva2006

Quality of test cases
测试用例的质量
There is a misconception that quality of writing is subjective, like looking at a painting, where beauty is in the eye of the beholder. In fact, quality of writing is objective and measurable. It is simple to set up an objective checklist, like the one in Appendix A, of the structural elements of test cases -- purpose, method, setup, inputs and outputs. Then walk though each case. Is the element there or not? In addition to their structure, the cases must also meet these standards of quality:
对于编写测试用例的质量存在一个误解，即编写质量是受主观控制的，就像看一部绘画作品，作品的美存在于观赏者的眼中。事实上，编写质量是客观的和可以估量的。建立像附录A中所示的客观的检查清单是一件简单的事，该清单包含了测试用例的结构性元素——目的、方法、设置、输入和输出。然后查看每条测试用例，是否具有这些元素？测试用例除了具备这种结构以外，还必须满足以下质量标准：
Accurate. They test what their descriptions say they will test.
准确性。按照测试描述进行测试。
Economical. They have only the steps or fields needed for their purpose. They don't give a guided tour of the software.
经济性。仅包含测试目的所需的步骤或字段，并不包括软件的使用说明。
Repeatable, self standing. A test case is a controlled experiment. It should get the same results every time no matter who tests it. If only the writer can test it and get the result, or if the test gets different results for different testers, it needs more work in the setup or actions.
可重现性，自立式。测试用例是一种对照试验。无论是谁进行测试都应该得到相同的结果。如果仅编写人员可以测试并得到结果，或者如果不同测试人员所得到的测试结果不一样，就需要对测试设置或测试行为进行更多的探讨。
Appropriate. A test case has to be appropriate for the testers and environment. If it is theoretically sound but requires skills that none of the testers have, it will sit on the shelf. Even if you know who is testing the first time, you need to consider down the road -- maintenance and regression.
适合性。测试用例必须适合测试人员和测试环境。如果测试用例只是理论上合理，但是其要求的技术测试人员都不具备，那么该测试用例只能待在架子上（无法执行）。即使你知道谁将首先进行测试，你也必须考虑之后的维护和回归测试由谁进行测试。
Traceable. You have to know what requirement the case is testing. It may meet all the other standards, but if its result, pass or fail, doesn't matter, why bother?
可追溯性。你必须清楚测试要求是什么。测试用例可能满足其他所有标准，但是如果测试结果是通过的还是失败的，都无关紧要，为何还要如此费力地编写测试用例呢？
Self cleaning. Picks up after itself. It returns the test environment to the pre-test state. For example, it doesn't leave the test system set at the wrong date. Automated scripts may call other scripts to do this. Don't confuse this standard with being destructive. Tests should be destructive, including trying to break a simulated production environment in controlled, repeatable ways.
自我清理能力。执行完之后自我恢复。使测试环境返回到测试前状态。例如，不允许在错误日期下设置测试系统。自动化脚本可以调用其他脚本来完成此任务。请不要把此标准与破坏性相混淆。测试应该是破坏性的，包括试图通过可控的、可重复的方式破坏模拟的生产环境。
These standards are also objective and measurable. They could also be added to your checklist. Someone who knows the requirements and application under test could fill out the checklist as part of a peer review. Compliance with some of the standards can't be known until after testing, but they are all measurable. This is an especially helpful exercise for new test writers to see where they consistently miss one of the elements, or don't meet a standard.
这些标准都是客观的和可估量的，可以添加到检查清单中。了解测试要求及被测试应用程序的人员可以核对该检查清单，作为检查测试用例的一部分。只有在测试之后才能知道测试用例符合其中一些标准，但所有标准都是可估量的。这对于新测试用例编写人员找出他们在什么地方总是缺失用例的其中一个元素或者不符合其中一个标准，是一个很有用的运用。

（未完，待续）

[ 本帖最后由 caueva2006 于 2010-7-7 09:26 编辑 ]

caueva2006

Format of test cases
测试用例的格式
What does a test case look like? They seem to fall into three major groups: step-by-step, matrix, and automated script. While the automated script will run as an online document, there is no assumption that the other two must be paper-based. They, too, might be online. Let's look at each of the formats:
测试用例看起来是什么样的？测试用例似乎可以分成三种主要类型：分步型、矩阵型和自动化脚本。虽然自动化脚本当作在线文档运行，但并不认为其他两种类型是基于纸质的，它们可以也可以是在线的。让我们来看看每种格式：
Step-by-step. Figure one shows what the basics of this format looks like. A complete view of this format, in a template with other test elements is displayed as Appendix B.
分步型。图1显示了此格式外观上的基本要素。包括其他测试要素的此格式的完整视图的模板如附录B所示。
Step        Action        Expected Result
1        Enter new name and address. Press <OK>.         Displays screen 008 new name details.
2        Fill all blanks with natural data. Make screen grab. Press <OK>.        Displays screen 005 maintenance.
3        Click on <Inquiry> button.        Displays screen 009 inquiry details.
4        Enter name from screen grab. Press <OK>.        Displays screen 010 record detail.
5        Compare record detail with screen grab.        All details match exactly.
Figure 1 - Detail of step-by-step test case
Matrix or table. Figure two shows what the basics of this format looks like. A complete view of the format, in a template with other test elements is displayed as Appendix C.
矩阵或表格。图2显示了此格式外观上的基本要素。包括其他测试要素的此格式的完整视图的模板如附录C所示。

Figure 2 - Detail of matrix test case
Automated script. Figure three shows what this format looks like.
自动化脚本。图3显示了此格式的外观。

Using test types
使用测试类型
Best uses for each type of case
每种用例类型的最佳使用
The most productive uses for step-by-step cases are:
Step-by-step
分步型用例最富有成效的使用是：
• One-off test cases, each one different
一次性测试用例，用例的每一步都不一样
• Business scenario goes from screen to screen
从一个屏幕到另一个屏幕的业务场景
• Many processing rules
许多处理规则
• GUI interfaces
图形用户界面（Graphical User Interface）
• Input and output hard to represent in a matrix
很难用矩阵来表示的输入和输出
Step-by-step cases do not necessarily need to have a key press level of detail as shown in Figure 1. The action steps can be at a higher level, such as: open "my account" page, search for transactions in a date range, note the range: ______ , print report, forward report, and so forth.
分步型用例不一定需要如图1所示的具体到按键说明层次的详细步骤。用例中的行为步骤可以是更高层次的，例如：打开“my account”页面，在某个日期范围内搜索事务，指出范围：______，打印报表，转发报表等等。
Matrix. The most productive uses for matrix cases are:
矩阵。矩阵用例最富有成效的使用是：
• Many variations of filling out a form, same fields, different values, input files
填写表格要用到很多变量，相同的字段，不同的值和输入文件。
• Same inputs, different platforms, browsers, configurations
相同输入，不同平台、浏览器和配置。
• Character based screens
基于屏幕的字符
• Input and outputs best represented in a matrix
输入和输出以矩阵表示最佳
Nearly any test can be represented in a matrix, but the question to decide is whether a matrix is the best way to test. It is most important that the matrix be supported by a description, setup, and how to record results for the test. It may be obvious to the writer how to test the matrix, but without more guidance the tester could flounder.
几乎任何测试都可以用矩阵来表示，但是要解决的问题是矩阵是否是用于测试的最好方式。最重要的是描述、设置和如何记录测试结果支持用矩阵表示。如何测试矩阵，对于编写人员来说是显而易见的，但是对于测试人员来说，如果没有更多的指导，将是毫无头绪的。
A variation of the matrix is a list of inputs. It can be inserted in a step-by-step test or stand as a matrix with the explanatory elements of the test.
矩阵的变量是输入列表。它可以插入分步型测试中，或者作为带有测试的解释性要素的矩阵
Automated scripts. A decision to use automated testing software is more related to the project and organization doing the testing than to what is being tested. There are some technical issues that must be met, varying from tool to tool, but most applications can find a technical fit. The project management must understand that writing automated cases takes longer than manual tests because the manual tests must be still be written first. When the interface is stable, then the tests can be recorded. The real payback of automated testing comes in the maintenance phase of the software lifecycle. Then the scripts can be executed repeatedly, even unattended, for great savings in testing time.
自动化脚本。使用自动化测试软件的决策更多地与进行测试的企业和组织有关，而与要测试的产品不相关。根据不同的工具，必须满足不同的技术问题，但是多数应用程序可以找到适合的技术。项目管理层必须明白编写自动化用例要比编写手工测试用例花更多时间，因为手工测试用例必须先编写。当界面稳定时，测试可以记录下来。自动化测试的真正回报体现在软件生命周期的维护阶段。此时脚本也可以重复执行，甚至无人参与，可以节省大量测试时间。
The management must provide someone to program in the tool language, such as C++ or Visual Basic. Simple scripts can be recorded by most test analysts, but more powerful scripts, often utilizing custom functions and objects, must be written by programmers. A team can be put together with several people doing the ordinary record/playback scripting and one person doing the programming.
管理部门必须配备人员用诸如C++和Visual Basic等语言进行编程。简单脚本可以由多数测试分析员进行录制，但是许多功能强大的脚本，常常使用自定义函数和对象，则必须由编程人员来编写。一个组里可以由一些人做脚本的录制和回放工作，一个人进行编程。

Comparisons to the other types of test cases apply to record and playback, or data driven scripts. Besides record/playback scripts, automated tools are used for performance and load testing. They may use manual step-by-step cases or matrixes which detail how automated tools will be used to create virtual users, launch transaction scripts, monitor performance, and other activities.
与其他测试用例类型相比较，此用例类型适用于录制和回放脚本，或数据驱动脚本。除了录制/回放脚本，自动化工具还用于性能和负载测试。可以使用手工分步型用例或矩阵来详细说明如何使用自动化工具创建虚拟用户、启动事务脚本、监控性能及其他活动。

(未完，待续)

[ 本帖最后由 caueva2006 于 2010-7-9 18:56 编辑 ]

caueva2006

本人已将此文翻译完，有需要的可以留下邮箱，以便把译文发给您。