TA的每日心情 | 无聊 2 小时前 |
---|
签到天数: 1052 天 连续签到: 2 天 [LV.10]测试总司令
|
前言
各位同仁好,在这里分享一个几年前,或者说好多年前在某公司开发的测试框架,看过我文章或讲堂的人,会发现里面涉及到的脚本都是用python编写,其实呢,我最早使用的是java,也用了很长一段时间,使用不同的语言,跟所在公司的技术方向,leader喜好,工作性质有关,搞安全的时候,还接触过ruby,perl,甚至汇编,搞性能的时候,啃了C,依稀还记得测试swoole的时候,写过shell脚本….,这么多招式靠啥心法驱动,技巧性编程靠数据结构和算法,软件设计靠设计模式,分层思想,尽量遵循六大原则,无限接近高内聚,低耦合.
这里说明下脚本的概念,当然是我自己的划分,我对所有的轻量级开发(个人完成,代码行一万以内的),技巧性编程,不管是编译型,还是解释执行的语言,统一叫脚本。
开发这款框架的原因,不是个人兴趣,是当时所在公司的形式主义,不是说形式主义不好,也是企业文化的一部分,有正面的积极作用。啥形式主义,公司年会之前,会有各部门负责人,部分骨干的述职报告,这个框架就在报告里面酝酿,因为持续集成,快速迭代比较火嘛,测试部也要向这个方向靠拢,最终成型是在某个大会上,我不记得主题是啥了,反正是请了主要客户来公司考察的时候。
这款测试框架,是借鉴了很久之前网上一款用QTP(水银公司的自动化测试工具)作为驱动的框架,在他的设计思想和用例设计上进行扩展,并用JAVA和selenium进行实现,当然为了便于分享,我又进行了部分重写,切割掉了服务端,简单设计了GUI界面,方便大家使用,理解和扩展。
下面将会按照 设计需求 –> 技术架构 -> 应用场景 -> 使用方法 -> 项目说明 进行讲解。
[项目地址: https://gitee.com/samllpig/auto-test-project]
[运行环境: java version >= 1.8]
设计需求
设计需求很简单,通过测试计划管理测试用例,测试用例管理测试任务和测试数据,最终执行自动化测试,生成测试报告。
测试计划和测试用例的是通过excel进行设计和管理。
技术架构
应用场景
组长负责设计测试计划和测试用例,并按测试任务分配给组员进行编码,组员负责编写测试脚本和调试代码,最终发送给执行人员进行统一编译和执行。
使用方法
第一,设计测试计划,必须按照既定的格式进行编写,如果要进行扩展或改进,需要修改对应的测试计划驱动代码。
字段解释:
执行标志:很简单了,打×就是不执行,打√就是执行。
项目名称:这个根据实际情况进行写了,项目名称最终会自动写到测试报告里面,上图举例的webgoat系统,是owasp的web漏洞靶场系统。
测试用例文件名:这个很重要,一定要和实际的测试用例文件名称一致,因为测试计划驱动代码要根据这个名称定位到要执行的测试用例文件。
sheet页名:重要,实际的测试用例数据加载,就靠这个定位。
描述: 有需要就写写。
版本号:这个版本号会写到测试报告里面。
执行人:这个执行人会写到测试报告里面。
测试地点:测试报告需要。
PC_CPU: 自动化执行的机器配置信息,按实际情况写,测试报告需要。
PC_DISK:自动化执行的机器配置信息,按实际情况写,测试报告需要。
PC_MEM:自动化执行的机器配置信息,按实际情况写,测试报告需要。
PC_OFFICE:自动化执行的机器配置信息,按实际情况写,测试报告需要。
PC_ROBOT:自动化工具版本,自动化执行的机器配置信息,按实际情况写,测试报告需要。
PC_OS:自动化执行的机器配置信息,按实际情况写,测试报告需要。
ModifyVersion: 修改版本号,自动化执行的机器配置信息,按实际情况写,测试报告需要。
第二,设计测试用例,和测试计划一样,必须按照既定的格式进行编写,如果要进行扩展或改进,需要修改对应的测试用例驱动代码。
测试用例包含测试任务和测试数据,以下是测试用例设计样板,同样是以webgoat系统为例,
字段解释: 执行标志:打×就是不执行,打√就是执行。
业务模块_类名: 对应业务名称,对应task的类文件名称。并且类文件中有一个同名的class。需要按业务场景设计类,务必保证和类名称完全相同。
任务名称_方法名:具体task的名称。这个操作是需要自己写代码来实现的。对应于各个类的方法,按业务场景设计类,当然最简单的方法是按照被测系统的模块进行设计,例如:客户信息管理,类名:CustomerInfo,方法(对应这列的任务):toInsert(新增客户)、toModify(修改客户)、toDel(删除)等.
测试数据Sheet名称:数据所在Sheet的名称。每一个条测试用例必须对应一个测试数据。
过滤条件:数据执行条件。仅执行复核此条件的数据。
描述:测试用例名称,例如login,就是登录系统。
测试任务Login和logout,对应的测试数据:
测试任务multiLevelLogin,对应的测试数据:
|
|