如何进行测试自动化的成本估算

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

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

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

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

　　通常需要结合测试用例的复杂度的评估来考虑选择的测试用例以及个数。首先把测试用例按一定的原则分为简单、中等、复杂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、在项目中是可移植、可扩展、可重用的。

原文转自：http://www.ltesting.net