如何选择合适的测试用例实现自动化？

对于自动化测试团队而言，容易犯的一个典型的错误是：没有选择恰当的测试用例来实现自动化。

大部分测试自动化项目失败的原因主要归咎于被测试应用程序的快速变化、不恰当的测试用例、不可靠的框架、脚本编程的问题。分析这些问题的根源，我们可以看到，自动化测试必须分阶段逐步开展，而不能局限在某个阶段完成自动化测试。因此，建议自动化测试从选择那些重要的、合适的测试用例开始，然后慢慢地扩展到其他方面。这样会带来较低的维护成本，但是实现更重要的业务价值。

那么如何选择合适的测试用例呢？

通常需要结合测试用例的复杂度的评估来考虑选择的测试用例以及个数。首先把测试用例按一定的原则分为简单、中等、复杂3大类。然后从这3大类的测试用例中按一定的比例来抽取需要实现自动化的用例。

测试用例的复杂度分组可以通过综合分析测试用例包含的测试步骤（操作步骤），以及测试用例所包含的检查点个数来判定，例如可参考下表来分类：

表中规定：

1、如果测试用例中包含的测试步骤个数小于5，检查点个数也小于5，则判定为简单类型的测试用例，对于这类测试用例，可多选择一些用于实现自动化。

2、如果测试用例中包含的测试步骤在5到15个之间，检查点个数在5到10个之间，则判定为中等复杂类型的测试用例，对于这类测试用例，可略选择少一些用于实现自动化。

3、如果测试用例中包含的测试步骤在15到25个之间，检查点个数在10到15个之间，则判定为复杂类型的测试用例，对于这类测试用例，可再略为选择少一些用于实现自动化。
　　

至于选择的比例，则可参考一些项目的经验数值，或者根据项目实际情况自己调整。这种通过测试用例复杂度分组选择的方式来筛选出自动化测试用例比较简单易行，而又不失科学性。因为众所周知，自动化测试脚本的实现难度，在很大程度上取决于测试用例的复杂度，而测试用例的复杂度又在很大程度上取决于测试步骤和检查点的复杂度。

在自动化测试的测试用例范围内，找出每个测试用例的操作数量和验证点的数量，然后画出一个图表来找出平均值，并且定出控制点，这样可以基于被测试应用程序的实际情况而不是仅仅根据行业标准来判断复杂度。

例如下表显示了25个测试用例中每个用例所包含的测试步骤：

根据这个表，可以画出图1所示的复杂度与测试步骤个数的关系图：

图1 复杂度与测试步骤个数的关系图

然后，我们可以基于这个图计算出平均的测试步骤个数是16个，那么以此为基准点，再定出上、下限分别是8和25，则可以这样定义测试用例的复杂度：

简单 ：    ≤  7 个步骤
　中等 ：    ≥  8 个步骤   --  ≤ 16 个步骤
　复杂 ：    ≥  17 个步骤  --  ≤ 25 个步骤

类似的，我们可以再加入检查点的个数，按类似的方法进行计算。

影响测试自动化工作量评估的因素

但是，前面所讲到依据测试步骤和检查点个数来判断测试用例复杂度的方法还是有不少的缺陷，个数仅仅是一种参考，还需要综合考虑其他的方面，例如

1、需要注意每个脚本开发前的工作量也要纳入计算：

(1) 通过手工测试确认操作的正确性。
　(2) 测试数据的选择和生成。
　(3) 脚本模板的创建，例如头信息、步骤注释、抽取公用的脚本函数等。

当然，这些方面的工作量也很大程度上取决于测试用例的测试步骤个数。

2、另外功能的重复性也是判断复杂度和工作量的因素之一。如果测试用例的步骤比较复杂，但是与其他测试用例比较类似，具有功能上的重复性，则也可以标志为“中等”或“低”的复杂度。

3、如果测试用例的测试步骤超过了上限控制点（例如25），那么那些额外的超出上限的步骤可以考虑放到另外一个测试用例中。例如，上面的例子中，编号为06的测试用例包含30个步骤，则可标识为“1个复杂的用例 + 1个简单的用例”

4、需要考虑那些被标识为“复杂”而不是“中等”的测试用例是否应该被自动化实现，因为实现过多的复杂的测试用例会给自动化测试带来沉重的负担。

下表按其影响程度从高到低列出了8个影响自动化测试实现的方面，这些方面也是自动化测试工作量评估中不可忽视的因素：

其中可以看到，测试框架对于自动化测试的影响程度是最大的，一个好的测试框架可以让脚本编写、调试和维护变得更加简单。在自动化测试项目开展的前期搭建一个稳健的好用的测试框架，可以让后面的脚本开发事半功倍。

另外，不可忽视的一点是测试工具以及自动化测试工程师的个人技能，这些都会对自动化测试项目能否成功实现有着重大的影响。

在被测试的应用程序中，如果包含了大量的自定义控件、第三方控件，则自动化测试工程师需要付出更多的努力来“对付”这些问题，这是因为大部分的测试工具在这些方面都仅仅提供非常有限的支持。

测试框架设计与工作量评估

针对某个测试工具的测试框架而言，商业的和开源的都有很多，例如QTestWare、SAFFRON、EMOS等。当然也可以自己构建自动化测试框架。这些框架可以节省很多脚本编写、调试和维护等方面的工作量。但是需要注意根据被测试应用程序来进行修改和个性化改造。

框架的一般特点是：

　1、在项目中是可移植、可扩展、可重用的。
　　2、根据被测试应用程序版本的变更能很容易地增减功能。
　　3、尽可能与测试工具是松耦合的关系。
　　4、扩展的错误恢复系统和异常处理，用于捕获那些未被处理的错误，让测试脚本可以顺利地运行。
　　5、提供步骤日志和错误信息，让调试变得简单，让测试结果的报告更加清晰易懂。
　　6、让数据驱动易于实现，让测试数据和脚本的耦合度降低。
　　7、让每次测试运行的范围可以很容易地控制和配置。
　　8、测试自动化组件与测试管理工具、缺陷跟踪工具和配置管理工具轻松整合。

因此，测试框架的采用与否，设计合理与否都与自动化测试的实现难度、工作量有密切的关系。一般而言，采用合理的测试框架对于减轻自动化测试脚本的编写难度和工作量都有积极的作用。

但是需要注意的是，测试框架需要随着脚本的开发进程不断地更新。如果有很多的脚本在并行开发的话，框架的维护难度也会增大。因此，这些方面也是工作量评估需要考虑的方面。

测试脚本编写工作量的评估

在前面，我们大概介绍了测试用例的选择、框架设计和开发对自动化测试的影响以及工作量的评估。到了脚本开发和调试、执行的阶段，仍然有不少的工作量，例如下表所列的：

我们可以通过分析和评估，然后填写上面表格，从而得到每个脚本的总体成本。

前面提到过，测试框架是自动化测试工作量评估中不可忽视的部分，在设计框架时需要考虑工作量，在测试脚本中使用框架时也会有一定的工作量，例如对于关键字驱动（Keyword driven）框架，采用关键字驱动的方法编写脚本会带来不错的效果，但是同时也要注意到构建和使用、维护一个关键字驱动测试框架的工作量是很大的，主要体现在设计和编码上。因此建议不要在小型的项目中使用关键字驱动的方式，尤其是自动化测试工程师的编码水平有限的情况下。

小结

本文略为介绍了一些自动化测试实现过程中可能碰到的问题，以及如何评估这些问题带来的工作量，为自动化测试团队开展自动化测试前对项目实现自动化测试的成本估算提供了一些参考。

总的来说，自动化测试的总体成本计算需要包含以下方面：

　1、测试需求收集和分析。
　　2、框架设计和开发。
　　3、测试用例开发（如果已有的手工测试用例不适用的话）。
　　4、脚本开发。
　　5、整合测试和基线的维护。
　　6、测试管理。

参考资料：

　1、《TEST AUTOMATION EFFORT ESTIMATION》 - Babu Narayanan
　　2、EMOS： http://emos-framework.sourceforge.net/
　　3、QTestWare： http://www.itestware.com/ctest/index.php?option=com_content&view=article&id=88:qtestware&catid=29:qtp&Itemid=37
　　4、SAFFRON：http://www.itestware.com/ctest/index.php?option=com_content&view=article&id=62:webqtp-saffron&catid=35:testing_is_believing