“.Net软件测试自动化之道”

久闻此书大名，终于在上个星期把它从图书馆里借了出来。看后感觉前半部分对测试人员来说还是不错的，但是后面部分过于倾向代码开发，比较适合做白盒测试，单元测试。整体上要求读者有一定的开发能力，但是测试人员也可以把它作为一本了解开发人员如何做测试的参考书。

术语

test harness 测试套件

test suite 测试组

SUT(System Under Test)、AUT(Application under Test)、IUT(Implementation Under Test)待测程序

Console application 控制台程序

精华

自动化测试技术是为了补充其他测试的不足，比如手工测试，测试驱动开发，基于模型的测试，开源测试框架，商业测试框架等等，而不是替代这些测试。软件测试自动化相比于手工测试的5个优点（SAPES）

1.更快的速度（Speed）

2.更高的准确性（Accuracy）

3.精度（Precision）

4.效率（Efficiency）

5.更有利于测试者提升自身技能（Skill-Building）

文中作者提出了“轻量级的自动化测试”的概念，认为轻量级的自动化与开源测试框架和商业框架相比，没有那么陡峭的学习曲线，与商业自动化测试框架相比，轻量级的自动化测试花费相对便宜并且很容易定制。与开源测试框架相比，轻量级的自动化测不会有太多版本更新和bug修复，从而更为稳定。最大的优点是可以调动测试者的主观能动性－轻量级的自动化测试积极鼓励编写有创造性的测试程序，而商业框架和开源框架常常限制你只需编写框架支持良好的那些测试类型。它唯一的缺点是不太容易维护。

第一部分  Windows应用程序测试

第一章  API测试

API(Application Programming Interface)测试的自动化是软件测试自动化最基本的一种类型。从本质上说，API测试是用来验证组成软件的那些单个方法的正确性，而不是测试整个系统本身。API测试也被称位单元测试(Unit Testing)，模块测试(Module Testing)，组件测试(Component Testing)以及元件测试(Element Testing)。从技术上说，这些术语是有很大区别，但是在日常应用中，你可以认为他们大致具有相同的意思。它们背后的思想就是，必须确定系统中每个单独的模块工作正常，否则，这个系统作为一个整体不可能是正确的。

手工测试一个API的步骤：

创建一个小的程序，

把待测的类copy到测试程序中，

针对待测方法硬编码（hard-coding）一些输入值，

运行这个存根程序（stub program）以得到实际的输出结果，

然后通过肉眼来比较实际的结果是否与预期的结果一致，

从而决定测试是否通过。

自动化测试API的步骤：

1）存储用于测试用例的数据存储测试用例数据的文件

a－独立于测试套件

b－文件中的每一行代表一个单独的测试用例，每个测试用例基本字段为：测试用例ID，待测方法，测试用例输入以及期望结果。每个字段用统一的字符分开，如“：”

c－文件格式可以采用文本文件或XML格式甚至SQL表。对于轻量级的自动化测试程序来说，出于简单性的考虑，文本文件是最好的数据存储方法。

2）读入测试用例数据一般通过while循环语句遍历测试用例文件文件的每一行，将数据读入。路径最好用相对路径。

3）解析测试用例采用类似spit的方法，把分隔符作为输入传给它，然后把返回值存入一个字符数组。

4）把数据转换为合适的类型

5）判定测试用例通过与否

6）记录测试用例结果把测试用例ID和测试结果写到一个独立于测试程序的简单文本文件中

7）给测试用例结果加上时间戳可以把时间戳加到测试结果的文件名中

8）通过计算对测试结果进行总结通过简单的整数计数器，计算测试用例的通过与否

9）获得测试运行的总时间

10）注意验证输入为空或期望值为空的情况

11）处理“方法抛出异常”的情况

12）处理输入参数为空字符串的情况

13）编写程序使得测试用例失败时发送警告邮件

第2章 基于反射的UI测试（Reflection-Based UI Testing）

第3章 基于Windows的UI测试

第4章 测试套件设计模式

测试用例数据的存储方式

a－平面型的存储结构（flat storage）：纯文本文件

b－层次结构（hierarchical）：XML文件

c－关系型（relational）：SQL数据

测试处理数据的两种基本方式是流方式（streaming）和缓存方式（buffered）,用伪代码表示如下：

streaming

循环开始

     从外部存储读入单个测试用例

     把测试用例数据解析成输入值和期望值

     调用待测组件

     判断测试用例结果

     把测试用例结果保存到外部存储

循环结束

buffered

循环开始    //1.读入所用测试用例    

        从外部存储把单个测试用例读入内存

循环结束

循环开始    //2.运行所有测试用例

     从内存中读入单个测试用例

     把测试用例数据解析成输入值和期望值

     调用待测组件

     判断测试用例结果

     把测试用例结果写入内存中的数据结果

循环结束

循环开始    //3.保存所有测试结果

     把测试用例结果从内存写入到外部存储

循环结束

streaming处理模型比buffered模型更为简单，因此它通常是最好的选择。但是，在下面情况下，应该考虑使用buffered处理模型。

1.如果待测系统涉及文件输入输出，通常我们希望尽量减少测试套件的文件操作。如果需要对性能进行监测，那就尤为如此。

2.如果需要对测试用例输入进行预处理（例如，从不同的数据存储读出测试用例数据并进行过滤）或者延迟对测试用例结果的处理（例如，为了聚合不同类型的测试用例结果），这种情况下，让数据保存在内存中以便于处理通常是更为方便的方法。

接下的几节分别介绍了如下组合的具体的实现方法，个人倾向于使用文本文件存储数据并采用streaming模型因为其的简单，不过有时也会视需要选择其他的。

1）文件文件存储并采用streaming模型

2）文件文件存储并采用buffered模型

3）XML文件存储数据并采用streaming模型

4）XML文件存储数据并采用buffered模型

5）SQL存储数据并采用streaming模型

6）SQL存储数据并采用buffered模型

第2部分 Web应用程序测试

第5章 请求－响应测试

第6章 基于教本的Web UI测试

第7章 底层的Web UI测试

第8章 Web Service测试

第3部分 数据测试

第9章 SQL存储过程测试

第10章 排列与组合

第11章 ADO.NET测试

第12章 XML测试

由于第2部分和第3部分本人接触的不多，就不介绍了。不过第10章的排列与组合介绍了如何通过排列组合生成测试数据的思路值得参考。