自动化测试介绍自动化测试(Automated Testing),是指把以人为驱动的测试行为转化为机器执行的过程。实际上自动化测试往往通过一些测试工具或框架,编写自动化测试用例,来模拟手工测试过程。比如说,在项目迭代过程中,持续的回归测试是一项非常枯燥且重复的任务,并且测试人员在每天重复劳动的工作之下,也丝毫得不到成长。此时开展自动化测试就能够帮助测试人员从重复、枯燥的手工测试中解放出来,提高测试效率,缩短回归测试时间。一般来说,自动化测试通常都会跟持续集成系统(比如Jenkins)配合使用。 但在自动化实践过程中,往往会发现理想和现实之间的差距很大。自动化测试的劣势,主要体现在以下几方面:
希望借助自动化流程解决的问题
引入自动化测试的前提条件项目周期长,需求变动不频繁 项目中的某些模块相对稳定,而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试,而变动较大的仍是用手工测试。 自动化测试脚本可重复使用 测试任务手工测试难以实现 做自动化测试需要具备的能力
自动化用例一般在哪个阶段完成一般落后于新功能的手工测试阶段,可以在手工用例执行完成或功能上线后,再去补充自动化的用例。 分层自动化测试在理解分层自动化之前,我们先看一下经典的测试金字塔。
设计自动化用例的原则基本原则
用例设计原则保持Case的独立性通常来说,一个Test Suite下包含了一组相近的或者有关联的Test Cases。而每一个 Test Case 应该只测试一种场景,根据case复杂程度,不同场景同样可大可,可以是某个单元的测试,也可以是端到端的测试(E2E),当然也有特殊的写法比如工作流测试和数据驱动。 Case的独立性有哪些需要关注的点呢? 首先Test Suite内的Cases在执行时不应该相互影响,意思是说当我们有随机的跑其中某个Case或乱序的跑这些Cases时,测试的结果都应该是准确的。Suite level和Directory level同样要注意独立性的问题。系统较为庞杂时,可能会将数百上千的Cases放在一起跑,Robot本身不会规定Case执行的顺序,所以从某种程度上来说同一层级的Cases是随机执行的。很典型的情况就是,测试用例在本地调试时怎么跑怎么过,放到Server上所有Cases一起跑的时候就会Fail,还可能是偶发的,这种情况下就很可能是由于其他Case的痕迹影响到了它,查找问题的根源往往比较耗时。 保持Case的可迁移性Case的可迁移性主要考虑三点 : Case对执行环境的依赖 ; Case对外部设备的依赖;Case对测试对象的依赖。 Case对执行环境的依赖 再举个例子,如果你因为业务需要而修改了测试库源码的话,此时不管是组内其他人还是CI服务器,肯定都会运行失败,这种情况该怎么解决呢?这里提供两个解决方法:
Case对外部设备的依赖 Case对测试对象的依赖 提升Case执行效率不同的case执行时间相距甚远,短则数秒长则持续数天。数秒钟的简单功能测试用例和耗时数天的稳定性测试用例本身是没有什么可比性的。但是我当我们放眼某一个或者某一组case时,我们就需要重视Case的执行效率。不论是敏捷流程还是持续集成都讲究快速的反馈,开发人员能在提交代码后快速的获得测试结果反馈,测试人员能在最短的时间内执行更大范围的测试覆盖,不仅能提高团队的工作效率,也可增强团队的信心。 以使用rf为例,在编写用例时可以通过以下方面来提高用例的执行效率。 1.如果有对执行条件的检查,若检查失败,则尽快退出执行; 自动化用例编写规范命名规范Keyword命名第一个单词应以小写字母作为开头,后面的单词则用大写字母开头。 如:getProjectId, connectDB 常量命名常量的名字应该都使用大写字母,并且指出该常量完整含义。如果一个常量名称由多个单词组成,则应该用下划线来分割这些单词。 如:MAX_CHAR_LENGTH 参数命名参数的命名规范和方法的命名规范相同,请在尽量保证参数名称为一个单词的情况下使参数的命名尽可能明确。如:${account} , ${investorName} 使用TagsRF提供了通过在Settings中设置tags来管理用例的方法。Tag的应用非常的广泛和灵活,比如可以用来做用例筛选、版本管理、统计策略等。 怎么打tag看起来会更便捷?
image
让case具有文档性在考虑Coding Style时我们可以设置一些固定的规则,大家只要按照这个规则来做,实践几次之后Coding Style就会趋于统一. 而考虑将Case写的如同文档一般则需要更多的主观能动性。 敏捷开发(Agile Development)在国内的发展已经越完善,伴随之而来的便是敏捷测试(Agile Testing)。敏捷思想强调以人为核心,在整个开发流程中,只写有必要的文档或尽量少写文档,这也是它与传统的瀑布模型的差别。
需求设计不断的更新,而文档往往不能被很及时的更新,那这样的话怎么才能让测试人员如何快速的掌握某个功能或者产品的需求和当前状态呢? 'Tests as Documentation.' 清晰易懂的用例名在实际的工程中,我们可能会新建一个目录来存储测试点相近的测试用例。每一个Case都对应一个测试点,而用例名则应该概括总结对应测试点的核心内容,这样当我们在浏览一组用例时,仅仅通过用例名就能大致了解里面的测试内容,也方便寻找某个Case。 清晰易懂的用例名在实际的工程中,我们可能会新建一个目录来存储测试点相近的测试用例。每一个Case都对应一个测试点,而用例名则应该概括总结对应测试点的核心内容,这样当我们在浏览一组用例时,仅仅通过用例名就能大致了解里面的测试内容,也方便寻找某个Case。 |
|
来自: liang1234_ > 《自动化测试》