【IT168 专稿】 如何选择合适的测试用例实现自动化? 对于自动化测试团队而言,容易犯的一个典型的错误是:没有选择恰当的测试用例来实现自动化。 大部分测试自动化项目失败的原因主要归咎于被测试应用程序的快速变化、不恰当的测试用例、不可靠的框架、脚本编程的问题。分析这些问题的根源,我们可以看到,自动化测试必须分阶段逐步开展,而不能局限在某个阶段完成自动化测试。因此,建议自动化测试从选择那些重要的、合适的测试用例开始,然后慢慢地扩展到其他方面。这样会带来较低的维护成本,但是实现更重要的业务价值。 通常需要结合测试用例的复杂度的评估来考虑选择的测试用例以及个数。首先把测试用例按一定的原则分为简单、中等、复杂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、如果测试用例的测试步骤超过了上限控制点(例如25),那么那些额外的超出上限的步骤可以考虑放到另外一个测试用例中。例如,上面的例子中,编号为06的测试用例包含30个步骤,则可标识为“1个复杂的用例 + 1个简单的用例” 4、需要考虑那些被标识为“复杂”而不是“中等”的测试用例是否应该被自动化实现,因为实现过多的复杂的测试用例会给自动化测试带来沉重的负担。
另外,不可忽视的一点是测试工具以及自动化测试工程师的个人技能,这些都会对自动化测试项目能否成功实现有着重大的影响。 在被测试的应用程序中,如果包含了大量的自定义控件、第三方控件,则自动化测试工程师需要付出更多的努力来“对付”这些问题,这是因为大部分的测试工具在这些方面都仅仅提供非常有限的支持。 测试框架设计与工作量评估 针对某个测试工具的测试框架而言,商业的和开源的都有很多,例如QTestWare、SAFFRON、EMOS等。当然也可以自己构建自动化测试框架。这些框架可以节省很多脚本编写、调试和维护等方面的工作量。但是需要注意根据被测试应用程序来进行修改和个性化改造。 框架的一般特点是: 1、在项目中是可移植、可扩展、可重用的。 因此,测试框架的采用与否,设计合理与否都与自动化测试的实现难度、工作量有密切的关系。一般而言,采用合理的测试框架对于减轻自动化测试脚本的编写难度和工作量都有积极的作用。 但是需要注意的是,测试框架需要随着脚本的开发进程不断地更新。如果有很多的脚本在并行开发的话,框架的维护难度也会增大。因此,这些方面也是工作量评估需要考虑的方面。 测试脚本编写工作量的评估 在前面,我们大概介绍了测试用例的选择、框架设计和开发对自动化测试的影响以及工作量的评估。到了脚本开发和调试、执行的阶段,仍然有不少的工作量,例如下表所列的: 我们可以通过分析和评估,然后填写上面表格,从而得到每个脚本的总体成本。 小结 本文略为介绍了一些自动化测试实现过程中可能碰到的问题,以及如何评估这些问题带来的工作量,为自动化测试团队开展自动化测试前对项目实现自动化测试的成本估算提供了一些参考。 总的来说,自动化测试的总体成本计算需要包含以下方面: 1、测试需求收集和分析。 1、《TEST AUTOMATION EFFORT ESTIMATION》 - Babu Narayanan |
|