软件测试自动化的引入条件
如果你的测试部门有意向引入自动化测试,那么首先要从思想上统一认识。
一、 软件测试自动化的正确认识
1) 自动化测试能大大降低手工测试工作,但决不能完全取代手工测试。完全的自动化测试只是一个理论上的目标,实际上想要达到 100% 的自动化测试,不仅代价相当昂贵,而且操作上也是几乎不可能实现。一般来说,一个 40-60% 的利用自动化的程度已经是非常好的了,达到这个级别以上将过大的增加测试相关的维护成本。
2) 测试自动化的引入有一定的标准,要经过综合的评估,绝对不能理解成测试工具简单的录制与回放过程。实际上,从实现成熟度来说,自动化测试分五个级别:
级别 | 说明 | 优点 | 缺点 | 用法 |
一级 | 录制和回放 | 自动化的测试脚本能够被自动的生成,而不需要有任何的编程知识 | 拥有大量的测试脚本,当需求和应用发生变化时相应的测试脚本也必须被重新录制 | 当测试的系统不会发生变化时,实现小规模的自动化 |
二级 | 录制、编辑和回放 | 减少脚本的数量和维护的工作 | 需要一定的编程知识;频繁的变化难于维护 | 回归测试时,用于被测试的应用有很小的变化 |
三级 | 编程和回放 | 确定了测试脚本的设计,在项目的早期就可以开始自动化的测试 | 要求测试人员具有很好的软件技能,包括设计、开发 | 大规模的测试套件被开发、执行和维护的专业自动化测试 |
四级 | 数据驱动的测试 | 能够维护和使用良好的并且有效的模拟真实生活中数据的测试数据 | 软件开发的技能是基础,并且需要访问相关的测试数据 | 大规模的测试套件被开发、执行和维护的专业自动化测试 |
五级 | 使用动作词的测试自动化 | 测试用例的设计被从测试工具中分离了出来 | 需要一个具有工具技能和开发技能的测试团队 | 专业的测试自动化将技能的使用最优化的结合起来 |
3) 自动化测试能提高测试效率,快速定位测试软件各版本中的功能与性能缺陷,但不会创造性的发现测试脚本里没有设计的缺陷。测试工具不是人脑,要求测试设计者将测试中各种分支路径的校验点进行定制;没有定制完整,即便事实上出错的地方,测试工具也不会发觉。因此,制订全面、系统的测试设计工作是相当重要的。
4) 自动化测试能提高测试效率,但对于周期短、时间紧迫的项目不宜采用自动化测试。推行自动化测试的前期工作相当庞大,将企业级自动化测试框架应用到一个项目中也要评估其合适性,因此决不能盲目的的应用到任何一个测试项目中,尤其不适合周期短的项目,因为很可能需要大量的测试框架的准备和实施而会被拖跨。
5) 实施测试自动化必须进行多方面的培训,包括测试流程、缺陷管理、人员安排、测试工具使用等。如果测试过程是不合理的,引入自动化测试只会给软件组织或者项目团队带来更大的混乱;如果我们允许组织或者项目团队在没有关于应该如何做的任何知识的情况下实施自动化测试,那将肯定会以失败告终。
如果软件企业有意向实施自动化测试,那么应该具备什么样的条件才可以引入自动化测试呢,才可以最大可能的减少引入风险,并能够可持续性的开展下去呢?
二、对企业自身现状的评估分析
第一,从企业规模上来说,没有严格限制。无论公司大小,都需要提高测试效率,希望测试工作标准化,测试流程正规化,测试代码重用化。所以第一要做到的,就是企业从高层CTO开始,直到测试部门的任何一个普通工程师,都要树立实施自动化测试的坚定决心,不能抱着试试看的态度。一般来说,一个这样的软件开发团队可以优先开展自动化测试工作:测试-开发人员比例合适,比如1:1到1:1.5;开发团队总人数不少于10个。当然,如果你的公司只有三五个测试人员,要实施自动化测试绝非易事;不过可以先让一个、两个测试带头人首先试着开展这个工作,不断总结、不断提高,并和层层上司经常汇报工作的开展情况,再最终决定是否全面推行此事。
第二,从公司的产品特征来说,一般开发产品的公司实施自动化测试要比开发项目的公司要优越些。原因很简单,就是测试维护成本和风险都小。产品软件开发周期长,需求相对稳定,测试人员可以有比较充裕的时间去设计测试方案和开发测试脚本;而项目软件面向单客户,需求难以一次性统一,变更频繁,对开发、维护测试脚本危害很大,出现问题时一般都以开发代码为主,很难照顾到测试代码。但决不是说做项目软件的公司不能实施自动化测试,当前国内做项目的软件公司居多,有很多正在推行CMM等级标准,这是好事情;只要软件的开发流程、测试流程、缺陷管理流程规范了,推行自动化测试自然水到渠成。
第三,说说标准化的开发和管理流程。不管是CMM还是ISO,不管是开发流程、测试流程还是缺陷管理流程,这里不能一一阐述,可以参考RUP(Rational Unified Process, Rational 统一过程),可以参考很多业界文献,我只说明一点,也是我们IT从业人员甚至任何从业人员一个很好的工作原则:
a、 把你想做的写下来(计划管理)
b、 按照你写下来的去做(行为管理)
c、 把做的事情记录下来(报告管理)
d、 出现的问题要设法解决(跟踪管理)
在测试流程里,这几个要点都一一有所落实;如果你的软件开发团队据此开发软件,那么完全具备实施自动化测试的条件。当然,也许一些公司的测试管理比较混乱,出了问题不知道谁负责,测试人员或开发人员整日碍
测试阶段 | 描述 | 备注 |
单元测试/组件测试 | 这个测试工作通常是开发人员的职责,很多不同的方法能够被使用,比如"测试先行",它是一个测试框架,开发人员在编写代码前编写不同的单元测试,当测试通过时,代码也被完成了。 | 通过使用正式的单元测试,不仅能够帮助开发人员产出更加稳定的代码,而且能够是软件的整体质量更加的好。 |
集成测试 | 这里的测试工作集中在验证不同的组件之间的集成上。 | 这种类型的测试通常是被测试系统的更加复杂测试的基础,大量的边缘测试被合并以制造出不同的错误处理测试。 |
系统测试 | 这种测试是通过执行用户场景模拟真实用户使用系统,以证明系统具有被期望的功能。 | 这里不需要进行自动化的测试。安装测试、安全性测试通常是有手工完成的,因为系统的环境是恒定不变的。 |
其它两种非常重要的测试 | ||
回归测试 |
回归测试实际上是重复已经存在的测试,通常如果是手工完成的化,这种测试只在项目的结尾执行执行一到两次。 | 这里完全有潜力应用自动化的测试,你能够在每次构建完成后执行自动化的回归测试,以验证被测试系统的改变是否影响了系统的其他功能。 |
性能测试包括以下不同测试形式: - 负载测试 - 压力测试 - 并发测试 -..... |
如果没有自动化的测试工具,你将不能执行通过模拟用户的负载实现的高密集度的性能测试。 |
文章来源于领测软件测试网 https://www.ltesting.net/