net自动化测试之道API测试-引言

1 API测试
1.1 引言
The most fundamental type of software test automation is automated API(Application
Programming Interface)testing.API testing is essentially verifying the correctness of the
individual methods that make up your software system rather than testing the overall system
itself.API testing is also called unit testing,module testing,component testing,and element
testing.Technically,the terms are very different,but in casual usage,you can think of them as
having roughly the same meaning.The idea is that you must make sure the individual build-
ing blocks of your system work correctly;otherwise,your system as a whole cannot be correct.
API testing is absolutely essential for any significant software system.Consider the Windows-
based application in Figure 1-1.This StatCalc application calculates the mean of a set of
integers.Behind the scenes,StatCalc references a MathLib.dll library,which contains meth-
ods named ArithmeticMean(),GeometricMean(),and HarmonicMean().
API（应用程序接口）测试是最基本的软件测试自动化类型。API测试不是测试整个系统，它本质上是验证组成系统的某个方法的正确性。API测试又叫单元测试、模块测试、组件测试、元素测试。严格地说，这几个术语是完全不同，但是在非正式使用的时候，我们可以认为他们大致表达同一个意思。API测试的基本思想是：必须保证构建系统的单个模块可以正常工作，否则整个系统就不能正常工作。API测试对于任何有意义的软件系统来说无疑都是重要的，例如图1-1显示的windows应用程序。这个名为StatCalc的应用程序用于计算一系列整数的平均值。StatCalc引用了一个包含ArithmeticMean(),GeometricMean(),and HarmonicMean()方法的MathLib.dll。

The goal is to test these three methods,not the whole StatCalc application that uses them.
The program being tested is often called the SUT(system under test),AUT(application under
test),or IUT(implementation under test)to distinguish it from the test harness system.The
techniques in this book use the term AUT.
我们的目标是测试这三个方法，不是使用这几个方法的StatCalc应用程序。被测程序通常被称为SUT，AUT或IUT，为了与测试套件系统区分。在本书中我们使用AUT表示被测程序。
The methods under test are housed in a namespace MathLib with a single class named
Methods and have the following signatures:
这几个方法在MathLib命名空间的Methods类中，他们的签名如下：
namespace MathLib
{
public class Methods
{
public static double ArithmeticMean(params int[]vals)
{
//calculate and return arithmetic mean
}
private static double NthRoot(double x,int n)
{
//calculate and return the nth root;
}
public double GeometricMean(params int[]vals)
{
//use NthRoot to calculate and return geometric mean
}
public static double HarmonicMean(params int[]vals)
{
//this method not yet implemented
}
}//class Methods
}//ns MathLib
Notice that the ArithmeticMean()method is a static method,GeometricMean()is an
instance method,and HarmonicMean()is not yet ready for testing.Handling static methods,
instance methods,and incomplete methods are the three most common situations you’ll deal
with when writing lightweight API test automation.Each of the methods under test accepts a
variable number of integer arguments(as indicated by the params keyword)and returns a type
double value.In most situations,you do not test private helper methods such as NthRoot().
Any errors in a helper will be exposed when testing the method that uses the helper.But if you
have a helper method that has significant complexity,you’ll want to write dedicated test cases
for it as well by using the techniques described in this chapter.
注意到方法ArithmeticMean()是一个静态方法，GeometricMean()是一个实例方法，HarmonicMean()还没实现。在写轻量级API测试自动化的时候，处理静态方法、实例方法、未实现的方法是最普遍的情形。在这里，每个被测方法都接收一个整型的变量和返回一个double类型的值。很多时候，我们不需要测试私有的辅助性的方法，像此处的NthRoot()方法。因为辅助性方法的任何错误都会在测试引用辅助性方法的时候暴露。但是，如果辅助性方法非常复杂，我们也应该为方法编写单独的测试用例，通过本章节介绍的技术测试它。
Manually testing this API would involve creating a small tester program,copying the
Methods class into the program,hard-coding some input values to one of the methods under
test,running the stub program to get an actual result,visually comparing that actual result with an expected result to determine a pass/fail result,and then recording the result in an
Excel spreadsheet or similar data store.You would have to repeat this process hundreds of
times to even begin to have confidence that the methods under test work correctly.A much
better approach is to write test automation.Figure 1-2 shows a sample run of test automation
that uses some of the techniques in this chapter.The complete program that generated the
program shown in Figure 1-2 is presented in Section 1.15.
手工测试API步骤通常是这样的：创建一个小的测试程序，将Methods类复制到这个测试程序中，硬编码一些输入参数值到某个被测方法中，运行这个桩程序获取实际的结果，目测对比实际结果与预期结果确定测试是通过还是失败，然后将测试结果记录到excel表中或其他类似的数据存储文档中。我们将重复这个过程上百次，即使我们确信被测方法是正确的。一种更好的方法是自动测试。图1-2显示了运行一个简单的自动化测试程序的结果，该测试程序使用了本章技术的部分技术。完成的程序在1.16节展现。
Test automation has five advantages over manual testing:
?Speed:You can run thousands of test cases very quickly.
?Accuracy:Not as susceptible to human error,such as recording an incorrect result.
?Precision:Runs the same way every time it is executed,whereas manual testing often
runs slightly differently depending on who performs the tests.
?Efficiency:Can run overnight or during the day,which frees you to do other tasks.
?Skill-building:Interesting and builds your technical skill set,whereas manual testing is
often mind-numbingly boring and provides little skill enhancement.
。。。。。。
The following sections present techniques for preparing API test automation,running API
test automation,and saving the results of API test automation runs.Additionally,you’ll learn
techniques to deal with tricky situations,such as methods that can throw exceptions or that
can accept empty string arguments.The following sections also show you techniques to man-
age API test automation,such as programmatically sending test results via e-mail.
接下来的将介绍准备API自动测试、运行API自动测试程序、保存API自动测试结果的技术。另外，你将会学到处理复杂场景的技巧，如抛出异常的方法、接收空字符参数的的情形。我们在接下来的章节中也会介绍管理API自动测试程序的技巧，如使用email自动发送测试结果。

=======

在这里需要解释下硬编码

指的是在软件实现上，把输出或输入的相关参数（例如：路径、输出的形式或格式）直接硬编码在源代码中，而非在运行时期由外界指定的设置、资源、数据或格式做出适当回应。一般被认定是种反模式或不完美的实现，因为软件受到输入数据或输出的格式改变就必需修改源代码，对客户而言，改变源代码之外的小设置也许还比较容易。

但硬编码的状况也并非完全只有缺陷，因某些封装需要或软件本身的保护措施，有时是必要的手段。除此之外，有时候因应某些特殊的需求，制作出简单的应用程序，应用程序可能只会运行一次，或者永远只应付一种需求，利用硬编码来缩短开发的时间也是一种不错的决策。