net自动化测试之道API测试-存储测试用例

Storing Test Case Data

存储测试用例数据

Problem

You want to create and storeAPI test case data in a simple text file.

 问题

我们想在简单文本文件中创建和存储API 测试用例数据，这该如何实现呢？

Design

Use a colon-delimited textfile that includes a unique test case ID,one or more input values,

and one or more expectedresults.

设计 

创建一个包含测试用例ID（唯一），一个或多个输入，一个或多个期望结果的文本文件，用例ID、输入和期望结果直接用冒号隔开。

解决方案

0001:ArithmeticMean:2 48:4.6667

0002:ArithmeticMean:1 5:3.0000

0003:ArithmeticMean:1 2 4 8 1632:10.5000

 

Comments

 

When writing automatedtests,you can store test case data externally to the test harness or

you can embed the data insidethe harness.In general,external test case data is preferable

because multiple harnesses canshare the data more easily,and the data can be more easily

modified.Each line of the filerepresents a single test case.Each case has four fields separated

by the‘:’character—test caseID,method to test,test case inputs separated by a single blank

space,and expected result. Youwill often include additional test case data,such as a test case

title,description,andcategory.The choice of delimiting character is arbitrary  for the most

part.

 注解

当写自动测试程序时，我们可以将测试用例数据存储在测试套件外部，也可以将数据嵌入到套件中。通常，存储在外部更可取，因为多个套件可以更容易共享测试用例，并且测试用例更容易修改。文本文件中每一行代表一个简单的测试用例，每个测试用例有四个字段，分别是测试用例ID、被测方法的名称、输入、预期结果，每个字段使用冒号分隔。多个输入直接用空格分隔。通常，一个用例还包括其他字段，如用例标题，描述和类别。大多数情况下，分隔字符的选择是随意的。 

Just make sure that you don’tuse a character that is part of the inputs or expected values.

For instance,the coloncharacter works nicely for numeric methods but would not work well

when testing methods with URLsas inputs because of the colon that follows“http”.In many

lightweight test-automationsituations,a text file is the best approach for storage because of

simplicity.Alternativeapproaches include storing test case data in an XML file or SQL table.

Weaknesses of using text filesinclude their difficulty at handling inherently hierarchical data

and the difficulty of seeing spurious controlcharacters such as extra<CR><LF>s.

只要确保我们使用的字符不是输入或预期结果的一部分。例如，在测试输入是数值的方法的时候，使用冒号分隔没什么问题，但是如果输入是URL就会有问题，因为”http”后面用到了冒号。在很多轻量级自动化测试中，文本文件是最好的存储测试用例的方式，因为它简单。但在处理固有的分级数据和识别欺骗性控制字符（如额外的<CR><LF>）时这种方式就很难实现。可选方式有XML文件或者SQL表。

The preceding solution hasonly three test cases,but in practice you’ll often have thou-

sands.You should take intoaccount boundary values(using input values exactly at,just below,

and just above the definedlimits of an input domain),null values,and garbage(invalid)val-

ues.You’ll also create caseswith permuted(rearranged)input values like

0002:ArithmeticMean:15:3.0000

0003:ArithmeticMean:5 1:3.0000

在上面的解决方案中，只用了三个测试用例，但是实际中，我们可以要有数千各测试用例。我们应该考虑输入的边界值（使用输入域定义中的上边界和下边界）、空值、无效值。我也将创建如下的包括无用的输入的测试用例：

0002:ArithmeticMean:1 5:3.0000

0003:ArithmeticMean:5 1:3.0000 

Determining the expectedresult for a test case can be difficult.In theory,you’ll have a

specification document thatprecisely describes the behavior of the method under test.Of

course,the reality is thatspecs are often incomplete or nonexistent.One common mistake

when determining expectedresults,and something you should definitely not do,is to feed

inputs to the method undertest,grab the output,and then use that as the expected value.This

approach does not test the method;itjust verifies that you get the same(possibly incorrect)

output.This is an example ofan invalid test system.

为一个测试用例确定预期结果是一件难事。理论上，我们会获得一份描述了被测方法的行为的详细文档。但是，现实中详细的文档通常都是会完成的或者根本不存在。一种普遍的错误做法是输入方法参数获得输出结果，然后以此输出结果作为预期结果。这种方法绝对不可取。这不是在测试方法，仅仅是验证用同样的输入获得了同样的输出。这是一个无效测试系统的例子。 

During the development of yourtest harness,you should create some test cases that delib-

erately generate a failresult.This will help you detect logic errors in your harness.For example:

0004:ArithmeticMean:15:6.0000:deliberate failure

在开发测试套件的过程中，我们应该创建一些特意导致失败的测试用例以帮助我们检测测试套件中的逻辑错误。例如0004:ArithmeticMean:1 5:6.0000:deliberate failure 

In general,the term APItesting is used when the functions or methods you are testing are

stored in a DLL.The term unittesting is most often used when the methods you are testing are

in a class(which of course maybe realized as a DLL).The terms module testing,component

testing,and element testingare more general terms that tend to be used when testing functions

and methods not realized as aDLL.

通常，我们在测试存储在DLL中的函数或方法的时候，使用API测试术语；在测试类中的方法（当然可能被作为一个DLL）时，使用单元测试术语；模块测试、组件测试、元素测试更多的时候是在测试非DLL的方法或函数时使用。