精华内容
下载资源
问答
  • 测试方案
    千次阅读
    2021-03-25 16:45:04

    测试方案和测试计划,测试报告几乎都是每个测试人员都必须掌握的。但有时经常搞混,特别是测试方案和测试计划。

    测试方案和测试计划的区别

    方案和计划英文翻译都叫“plan”,但具体的区别:

    什么是测试方案?
      所谓测试方案是指描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案。

    什么是测试计划?
      所谓测试计划是指描述了要进行的测试活动的范围、方法、资源和进度的文档。它主要包括测试项、被测特性、测试任务、谁执行任务和风险控制等。

    测试方案-偏技术:属于技术层面的文档,从技术的角度对测试活动进行规划。主要使用什么技术、什么工具等,即怎么测

    测试计划-偏项目:属于组织管理层面的文档,从组织管理的角度对测试活动进行规划属于技术层面的文档,从技术的角度对测试活动进行规划。主要是目标,时间,人员,资源、环境等,即测什么

    从大的方面讲,测试方案包含测试计划。

    测试方案和测试计划什么时候编写

    测试方案:是在项目立项或者需求分析的时候,这时候你就要考虑产品/项目需要用什么方法测,比如是web、app等,使用的技术不一样;其二,每个阶段使用技术/工具也不一样,更多的是测试经理或领导在项目成立或需求分析阶段编写的,考虑总体的大致方案,每个版本的计划,风险等,这样后面知道需要怎么去进行测试,可以解决一些技术难题。

    测试计划:是在项目执行的时候,更多的是测试带组人员安排并编写,其目的是看看这个版本你需要多少人、什么时候完成,这就是计划。

    测试方案

    测试方案分为大方向,和小方向,大方向是指项目的,小方向是每个版本。

    小方案的测试方案接近测试计划,这个方案是跟项目经理评审,确定要做什么内容,了解项目情况,哪些需要测试,哪些不需要。

    例如:

    最小集测试(入口检查)、可生产性、合入故障(修改点)、功能测试、性能测试、压力测试、兼容性测试、自动化测试、外场测试、其他。

    以上的确认下在这个版本需要测试吗?如果需要,要考虑需要什么技术或工具测试。然后这些安排谁去测试,什么时候测完等等,很接近测试计划,也顺便吧测试计划做了。

    大方向一般内容模板如下(文档是死的,人是活的,根据实际去考虑):

    1	引言	4
    1.1	编写目的	4
    1.2	背景	4
    1.3	预期的读者和阅读建议	4
    1.4	参考文档	4
    2	术语、定义和缩略语	4
    2.1	术语、定义	4
    2.2	缩略语	5
    3	综合描述	5
    3.1	软件功能	5
    3.2	测试需求范围	5
    4	测试风险	6
    5	测试策略	7
    5.1	测试方法	7
    5.2	缺陷管理	8
    6	测试计划	8
    6.1	集成计划	9
    6.2	集成测试进度安排	9
    6.3	测试环境与资源配备	10
    6.3.1	人员配备	10
    6.3.2	测试环境	11
    6.3.3	终端特性	12
    7	测试报告	13

    部分内容如下:

    测试方法:

    集成测试一般采用大爆炸测试&自底向上方法测试

    1.功能测试:测试各功能(含协议、框架、驱动)是否存在问题,集群基本业务是否正常;
    2.性能测试:在特定条件下,使用工具操作,是否出现问题或异常现象;
    3.稳定性测试:跑monkey是否出现问题或异常现象;
    4.疲劳测试:固定几台终端不关机、不重启,一致测试,考察终端承受能力;
    5.压力测试:针对集群业务相关,如集群呼叫、短信收发、集群联系人存储、应用和按钮频繁连续操作等;
    6.异常测试:在特殊场景下测试功能性,如迟后接入、异常操作、低电、业务中断等;
    7.内存测试:使用工具获取应用测内存使用情况,提供研发分析;
    8.并发测试:同时使用两个应用以上(含集群),如公网并发、短消息并发、音乐/视频同时并发;

    测试报告:

    报告名称

    报告内容

    编写者

    接收者

    测试工作日报

    反馈当日测试内容情况,以及测试影响和风险点

    反思测试哪个环节出现遗漏、不足之处,当作经验教训。

    自测人员

    项目经理

    开发经理

    科长

    自测人员

    项目相关人员

    测试工作周报

    反馈工作周进程

    反思测试出现遗漏、不足之处,当作经验教训。

    自测人员

    开发经理

    项目相关人员

    科长

    开发经理

    自测人员

    项目相关人员

    测试工作月报

    反馈工作月度情况,以及缺陷跟踪情况;

    反思测试哪个环节出现遗漏、不足之处,当作经验教训。

    自测人员

    开发经理

    项目相关人员

    科长

    开发经理

    自测人员

    项目相关人员

    测试阶段性报告

    开发经理在达到里程碑(版本发布)前后,自测人员在集成前后,汇报该阶段的主要工作、存在的问题和解决方法/建议、以及风险点等

    开发经理

    自测人员

    科长

    自测人员

    项目相关人员

    测试总结报告

    测试总结

    缺陷跟踪统计

    分析建议

    自测人员

    项目经理

    开发经理

    科长

    自测人员

    项目相关人员

    其他的参照实际公司情况,根据模板或在扩展编写。

    测试计划

    测试计划相对就简单点,遵守5W+1H原则:

    1.what:测什么 --目标

    2.when:什么时候 --时间

    3.where:在哪里测--环境

    4.who:谁测--人员

    5.why:为什么测--目的

    6.how:怎么测--方法

    简单来说:我们的测试目标,这个版本测到什么程度,测试目的是为了商用,还是合入故障验证,测试时间,几个人,几个模块,分多少用例,有什么环境什么资源,用什么方法,什么工具。。。。这些计划安排出来就明显,测过程需要些什么。

    测试报告

    测试报告就是给领导看的,那就把你的内容都安排放里面即可。比如,多少用例,多少人,多少bug,合入故障,解决故障等,最好是数字化图表化,这样领导一看就清楚。这个可以百度搜索模板,有些公司都有属于自己的模板。

    记住,报告开头最明显的是告诉这个版本是否测试通过,这个有通过标准的,看公司怎么定义。

    更多相关内容
  • 蓝牙耳机测试方案.pdf

    2020-05-15 13:18:49
    蓝牙耳机一站式测试方案介绍,测试流程规划,测试技术支持,方便蓝牙耳机制作公司规划产线,评估测试预算,提高产品直通率,降低企业生产成本
  • 软件测试方案模板范文,千里寻找,只求分享给大家!!!
  • 摘要:介绍了用Multisim仿真软件测试门电路延迟时间的方法,提出了三种测试方案,即将奇数个门首尾相接构成环形振荡电路,用虚拟示波器测试所产生振荡信号的周期,计算门的传输延迟时间;奇数个门首尾相接构成环形
  • LED光电测试是检验LED光电性能的重要而且唯一的手段,相应的测试结果是评价和反映当前我国LED产业发展水平的依据。...本文结合最新的LED测试方法的国家标准,介绍了LED的光电性能测试的几个主要方面。
  • 软件测试方案设计

    千次阅读 2020-11-01 10:51:38
    文章目录1、软件框架2、测试方案设计2.1、测试覆盖2.2、功能测试和压力测试2.3、自动化测试2.4、持续集成 1、软件框架 站在软件的角度,一个系统通常可以分为以下四个层次: 应用软件层(app layer)。用户重点自己...

    1、软件框架

    在这里插入图片描述

    站在软件的角度,一个系统通常可以分为以下四个层次:

    • 应用软件层(app layer)。用户重点自己开发的应用代码,例如我们的运动控制器要跑运动控制app,我们的示教器要跑qt用户交互app;
    • 中间软件层(middle layer)。在用户app和os系统之间的软件,一般是一些通用的库文件,比如qt库、算法库;
    • 操作系统层(os layer)。给用户层提供标准os服务的软件,一般包括kernel和驱动部分;
    • 硬件层(hardware layer)。最低层的基本硬件;

    2、测试方案设计

    我们的最终目标是交付给用户高质量可靠地产品,我们希望我们的系统每个角落都是经过严格测试的,我们要在实验室里模拟到用户可能会碰到的各种问题,才能经得起大规模商用后大量用户场景的考验。

    所以我们在设计测试方案时,要考虑到尽可能多的对软件路径进行测试覆盖。

    软件测试和硬件测试对比,有以下难点:

    • 测试对象比较虚幻。对硬件来说有可见的实体;对软件来说如果不了解细节你觉得它只是一个整体,但是当你了解细节以后,就会发现其中有越来越多的软件模块,每个模块都有自己的逻辑,都可能出错都需要被测试;
    • 测试对象非常多。软件的逻辑模块非常多,通常高出硬件模块几个数量级;
    • 测试对象逻辑复杂。对单个模块来说,软件模块可能出现的逻辑状态也是远高于硬件模块的;
    • 逻辑组合非常复杂。最终产品是要把多个模块组合成一个整体的,多个模块组合在一起就是(N x M x …)的复杂度;

    考虑到以上难点后,我们尝试使用以下手段来增加测试的覆盖度。

    2.1、测试覆盖

    上述的四层模型,每一层都为上一层提供服务,下一层的能力肯定是大于上一层的需要,因为上一层的应用用不到下一层所有的功能。

    比如:同一hardware既支持linux os又支持vxworks os,同一linux os既支持运动控制又支持qt应用。

    所以从严格意义上讲,四层的能力模型是一个金字塔型的:
    在这里插入图片描述

    在这种模型下,从任一上层层次来设计测试用例,它都会贯穿测试到下面的层次,但是下面层次都是有覆盖不到的情况:
    在这里插入图片描述
    既然是这种情况,那么是不是可以这样认为:如果已经从底层进行了完全的测试,那么是不是不需要经过上层的测试就能说明底层已经非常稳定?

    答案是否定的。底层自我测试的面可能更广,但是自我测试模拟不了上层带来的场景。

    比如我们针对os层已经做了针对os层的所有测试,这个时候我们还不能说os层完全没问题了。因为设计的测试用例只是尽可能覆盖,但是永远不可能完全模拟到所有真实的使用场景。我们还要经过中间层、应用层的测试完成后,我们才能说os在这种应用的场景中大部分是没问题的。

    所以,一个完备的测试方案,需要在每一层次上设计测试用例,才能形成一个完整的测试覆盖:
    在这里插入图片描述

    2.2、功能测试和压力测试

    上一节描述为了完备的测试覆盖,我们需要在每一层次上设计测试用例。

    那么针对某一层次的测试用例,应该怎么样来设计呢?

    从功能上可以简洁的分为两大类:功能测试和压力测试。

    1、功能测试:

    • 站在使用者的角度,测试提供的所有接口功能是否ok;
    • 还可以进一步对这一层次代码进行单元测试、集成测试,来充分验证代码逻辑;

    2、压力测试:

    • 对提供的基本功能,进行一个时间、空间上的压力验证。例如:正常请求1s 1次,压力请求1s 1000次;正常流量10M,压力流量 100M。只有在测试环境中经过更加严苛的测试,才能经受住实际复杂环境的考验。
    • 对于提供压力的形式也不是一味重载,还需要构造负载剧烈变化的场景。例如:重载、轻载、重载。。。。(随机变化)
    • 如果每一层次都有了自己的测试用例,我们还可以把这些用例组合起来,生成新的压力场景。例如:os层进行压力测试的同时,app层进行功能测试,验证在压力场景下app的功能还是否正常。
    • 使用自动化的方式,大量重复的去跑常规功能测试用例,这本身就是一个很好的压力测试场景。

    对四层模型来说,每一层的功能测试和压力测试有以下特点:

    Layer Function Test Pressure Test App Layer 1、从用户的角度测试所有提供的功能;
    2、单元测试+集成测试,验证代码逻辑; 1、重载压力测试;
    2、轻重载随机变化测试; Middle Layer 一般中间层可能没有源码以库的形式提供,而且用户对它的整个架构理解的也不充分。
    1、如果条件允许,可以让中间层厂商提供对应的报告;
    2、如果资源有限,很多时候也没有对中间层设计专门的测试用例; 依赖对应厂商 OS Layer 1、对OS kernel公共部分的功能测试,比如:cpu、内存。。。;
    2、对OS driver部分的功能测试,比如:网口、USB、存储、显示、input。。。;
    3、单元测试+集成测试,验证代码逻辑; 1、重载压力测试;
    2、轻重载随机变化测试; Hardware Layer 对硬件功能的完备性测试,一般是在产线上进行的:
    1、在硬件大规模量产时,会允许软件还有些bug,但是不允许硬件出现任何的功能性问题,因为硬件基本是不能修改的;
    2、量产时需要提供硬件功能测试软件给产线,来筛选出硬件不良品; 在硬件出厂前,在产线上还需要对硬件进行老化,让每个元器件度过初始震荡期,进入平稳运行期:
    1、提供老化测试软件,对硬件器件施加压力,让她们能迅速老化;
    2、软件能筛选出老化失败的不良品;

    另外从bug发生的故障率来说,用户自己修改的代码出现问题的概率最大。对应在四层模型中,app代码os驱动代码出错的概率最大。

    因为中间层代码、os kernel部分、hardware部分,使用的人一般很多,经过了多个用户的使用和测试后已经暴露出了较多的问题。而app代码和驱动代码基本都是用户自己开发/移植的,出错的概率更大一些。所以这两部分代码需要重点测试,给它们设计更多的测试用例。

    2.3、自动化测试

    从测试用例的数量和软件功能的数量来说,测试用例要大于软件功能的几倍,才能保证软件的质量。

    同时这也带来一个问题,庞大的测试用例,如果用人工来执行,测试周期会非常久。这对bug的发现、bug的修复、版本的快速发布都是不可容忍的。

    在今天这个产品开发周期越来越快的时代,越来越多的用到了自动化测试。如果是纯软件的项目,测试用例的自动化覆盖率应该达到100%;如果是嵌入式项目,测试用例的自动化覆盖率也应该达到80%以上。

    1、自动化测试模型如下:
    在这里插入图片描述

    • 自动化测试pc通过控制通道和被测设备进行连接,可以控制被测设备的行为,一些内部测试用例可以直接这样就能测试。控制通道可能是串口、usb、网口等等;
    • 自动化测试pc通过控制通道和测试仪器/设备进行连接,测试仪器/设备通过数据通道和被测设备进行连接,pc上的测试代码可以操控测试仪器被测设备进行测试。需要挑选支持代码控制的测试仪;
    • 跑在自动化测试pc上的自动化测试代码,一般使用python或者java来开发;

    2、web管理 + 自动化测试:

    在这里插入图片描述
    在自动化测试的进阶阶段,有多套测试方案+多个测试开发人员+多个测试执行人员+多个开发人员,这样复杂的场景下需要一个有效的管理。

    一般使用web来实现这些管理功能:

    • 配置测试方案。测试哪个版本的软件,要测试哪些case,每个测试case的配置;
    • 记录测试事件、测试log、测试结果、自动分析、自动提交bug;
    • 从bug记录上可以找到具体的测试信息;
    • 统计和报表呈现;
    • 权限管理;

    2.4、持续集成

    测试用例自动化的一个重要目的,就是支持持续集成。

    持续集成CI(Continuous integration)是来自于敏捷开发(Agile software development)的一个重要概念。在敏捷开发模式下,我们的产品是迭代式的开发,从最小功能做起,随时修改随时可用。产品随时保持可用的状态,可以随时发布。

    在新的代码合入以后,需要测试在极短的测试时间中,验证代码合入的新功能,以及验证对原来的功能是否有影响。如果不使用自动化测试,人工测试是不可能完成的。
    在这里插入图片描述

    实现了持续集成以后,我们会得到这样的理想场景:

    • 每天开发人员提交完代码,下班以后;
    • 自动编译系统,拉取最新的代码进行编译;
    • 编译完成后自动烧录到被测系统,并启动自动测试;
    • 自动测试完成后,会把测试不过的情况和log邮件发送给前一天有对应代码提交的开发人员;
    • 开发人员上班以后,处理前一天提交的错误,并开发新功能提交代码;
    • 晚上,又是新一轮的自动验证;
    展开全文
  • 测试方案

    万次阅读 多人点赞 2018-06-11 13:43:18
    在项目测试过程中,测试方案制定的好坏,会直接影响到项目的的质量。因此需要制定一份完善的测试方案,那么如何才能制定一份完善的方案呢? 5W1H原则不管在任何场景下,制定计划时5W1H原则都是需要适用的。how:如何...

    在项目测试过程中,测试方案制定的好坏,会直接影响到项目的的质量。因此需要制定一份完善的测试方案,那么如何才能制定一份完善的方案呢?

     

    5W1H原则

    不管在任何场景下,制定计划时5W1H原则都是需要适用的。

    how:如何去测?用什么资源?依据什么?工具如何选型、案例要执行到什么粒度。

    why:为什么要实现这个功能,背景和目的是什么,能给用户或公司带来多大的价值。

    what:我需要做什么?任务的目的是什么?

    when:项目周期多长,开发时间和提交测试时间是什么时候?什么时候需要给用户?测试周期需多长?

    who:项目各个环节的直接责任人、干系人是谁?谁来主导负责?需要多少人力来参与?

    where:相关资源的位置和路径,版本、文档。


    那么具体来讲,测试方案一般包含哪些内容呢?

     

    测试目的

    通常测试目的包含如下几种:

    1. 看测试对象是否满足需求规格说明书,满足目前的要求及未来的发展需求。
    2. 看测试对象业务流程的合理性和正确性。
    3. 看测试对象的功能、兼容、性能、稳定性、安全测试,是否满足要求。

     

    测试参考

    1. 需求文档:需求文档是测试设计和测试的基本依据,从需求文档中挖掘隐含的需求也是测试能力的体现。不过前期需求评审的越仔细,需求的准确性和完整性越高,后期修改和变更的几率就越低。
    2. 交互稿:通常体现了整个功能的业务流程,以及页面跳转关系。
    3. 设计稿:ui设计稿,通常作为UI界面测试的标准。
    4. 系统架构图:
    5. 开发流程图:理解开发的交互逻辑,明确代码输入输出规则,才能进行更精准的测试设计和测试,避免出现测试方向的偏差。具体怎么结合开发流程去丰富测试设计可以看这篇文章:https://blog.csdn.net/alice_tl/article/details/79601697

    还可以是一些参考文献和专业术语解释等等。 


    测试环境

    一般项目中至少存在三套环境,开发环境(DEV)、测试环境(STG)、生产环境(PRD),有的项目中还存在预发布环境。

    测试前要保证环境的连通性,因此要做一些前期准备,比如确认网络的墙是不是通的,测试的数据是不是提前准备好了。

     

    测试平台

    清楚要测试的平台及平台的特性,比如PC有PC的特性,Web和H5有各自的特性,Android和iOS有各自的特性。平台的特性也就决定了各个平台的兼容测试重点是不一样的,问题定位的方法和思路也是不一样的。

     

    测试数据

    提前针对要测试的环境准备数据,避免临时造数据造成不必要的测试时间影响。


    测试案例

     一般会区分前端、后端案例,后端案例一般还包含接口测试脚本。


    测试工具

    相关要用到的工具平台,比如缺陷管理平台、案例平台,接口测试工具Jmeter等。


    测试版本

     测试的版本号,版本下载的地址。


    测试分工

    需要多少个测试人力,是按功能模块划分,还是按照前后端测试来划分。

    如果涉及到跨项目组的协作,那么各个项目组的研发内容,对应的测试分工。以及最下游端到端验收测试的标准。

     

    测试范围

    测试项及指标

    测试项

    执行完成情况

    是否符合标准

    备注

    功能测试

    功能清单

     

     

     

    核心业务流程

     

     

     

    测试案例

     

     

     

    兼容测试

    硬件兼容

     

     

     

    软件兼容

     

     

     

    网络兼容

     

     

     

    数据兼容

     

     

     

    性能测试

    CPU

     

     

     

    内存

     

     

     

    流量

     

     

     

    耗电量

     

     

     

    响应时间

     

     

     

    安全测试

     漏洞、防攻击能力、敏感数据加密处理等

     

     

     

    安装测试

     安装、卸载、本地缓存数据等等

     

     

     

    埋点测试

     

     

     

     

     功能测试内容

    功能测试的方法,不管对于任何平台,软硬件测试,都是通用的。功能测试时除了要覆盖所有的功能清单,所有测试案例以外,也要重点测试核心业务场景和不稳定风险较高的模块。

     

    性能测试内容

    系统的CPU,内存,响应时间,流畅度,流量等。

     

    兼容测试内容

    主要包含硬件、软件、网络、数据四个方面。

     

    稳定性测试内容

    平均无故障时间达到X小时以上(android 8H,ios 2H),过程中身边应用无Force close、ANR、Native Crash,无因身边应用导致的手机freeze、shut down或power cycle。

     

    安全测试内容

    安全测试主要监测程序漏洞和抗攻击能力、敏感数据泄露等。

     

    安装测试内容

    安装测试主要看程序是否能够兼容到各个机型,安装后产生的文件缓存信息等等,以及卸载之后是否有残留文件。

     

    埋点测试内容

    看埋点是否符合产品数据统计的要求,以及埋点的准确性。

     

    测试风险

    可能存在哪些风险,比如测试环境由于各种原因导致无法覆盖到的内容,或者测试环境和生产环境有差异的原因。

    展开全文
  • 自动化测试方案设计和实现

    千次阅读 2020-10-31 16:08:05
    自动化测试方案设计和实现

    编辑推荐:
    本文主要介绍了几种测试类型需求,以及自动化测试方案设计和实现,希望对您的学习有所帮助。

    本文来自于知乎,由火龙果软件Alice编辑、推荐。

    如果对软件测试、接口、自动化、性能测试、测试开发、面试经验交流。感兴趣可以810119819,群内会有不定期的发放免费的资料链接,这些资料都是从各个技术网站搜集、整理出来的,如果你有好的学习资料可以私聊发我,我会注明出处之后分享给大家。

    背景

    为了充分利用云测试平台维护的设备,提升空闲设备使用率,开展自动化测试替代部分回归测试、重复性测试和多设备兼容测试,同时满足如下几种类型的自动化测试需求:

    随机测试(monkey、随机操作指令):

    在多设备执行的基础上完成安装、启动、覆盖安装、monkey 测试 / 随机指令、卸载等一系列操作。

    遍历测试(深度遍历、智能探索):

    在 monkey 测试 / 随机指令的基础上,对执行步骤进行改造,将随机操作替换为 app 内部页面的深度遍历,设计算法策略在一定程度上对被测 app 进行智能探索操作。

    UI 自动化测试(appium):

    在自动化测试框架支持的基础上,提供多设备脚本运行能力,测试开发人员只需要编写符合规则的测试脚本即可以在云测试平台上选择多个设备进行测试,获得测试结果。

    在以上自动化测试的同时,测试报告中需要体现如下内容:

    1.实时生成测试报告、测试结果数据

    2.实时获取设备的日志并有对应的分析结果

    3.可控的自动化测试过程

    4.执行过程中设备页面截图或录制视频

    5.测试结果中设备类型数据分析

    在上面背景说明中,介绍了几种测试类型需求,前两种的设计流程比较简单,也不需要外部人员的参与,第三种测试类型设计比较复杂,后续文章说明也以第三种测试类型为主。

    自动化执行框架设计

    自动化框架

    在 知乎移动端云测试平台实践(二)—— Agent 设计和实现 中自动化框架调研对比和各大云测试平台的使用,选择了在各方面都具有一定优势的自动化测试框架 appium 作为自动化测试的执行控制层,本地启动 appium hub 的方式接收脚本执行请求,这里就不多加赘述了。

    脚本语言和执行框架

    云测试平台是由 Java + kotlin 开发,客户端控制都是基于 Java 实现,这里自然选择 Java 作为脚本语言,后续的脚本、流程说明也是以 Java 语言实现为主,但是在脚本语言选择上这里不是强制要求,同样可以选择Ruby、Python、PHP,、JavaScript 和 C#,只是后续的实现需要平台多做一步兼容而已。

    在脚本执行方面没有使用类似 junit、testng等第三方的运行框架,主要是为了保持在运行过程中对脚本运行的控制和运行数据的交互,如下是脚本运行实现方案:

    1.由平台提供一定限制范围的脚本编写能力

    主要是指运行过程的脚本编写,以及如何提供类似截图、步骤日志、检查点等公用方法,对于 Java 来说可以将一些公共的方法抽象出来放到脚本的父对象中,通过继承将脚本编写能力赋予给脚本本身,Python 也可以统一一个标准的类库,通过引入的方式使用。

    2.运行时由 agent 动态编译编写完成的脚本,反射实例化脚本对象

    运行时处理脚本需要区分动态语言和非动态语言,还是以 Java、Python 为例,由于没有借用第三方的测试框架,触发脚本运行对于 Java 来说需要进行编译,也就是标题中说到的动态编译,然后通过反射实例化对象运行,这里有两个要求,首先脚本编写需要在云测试平台限定的包内,其次脚本运行、继承的方法需要符合约定的规则。对于 Python 来说先将脚本内容以 IO 的方式写到内存中,然后反射通过字符串的形式,导入模块、去模块寻找约定函数执行。

    3.使用反射实例对象运行脚本,并调用实例中的方法和脚本进行数据、强控制交互

    实例化脚本后开始运行脚本,运行前需要将所需要的运行资料注入到实例中,例如: appium 的 appiumDriver,运行同时可以随时调用实例化对象中的约定方法对脚本运行进行控制,比如获取执行步骤、日志、图片,传递参数,控制脚本暂停、运行、停止等交互,这也是为什么没有使用一些第三方框架来触发测试的原因。

    通过上述过程基本上实现了用例到执行的基本过程,如图:在这里插入图片描述
    也就是说只要提供了符合规范的脚本,就可以利用框架的通用性将脚本运行在任何 appium 支持的设备上,在架构上也剥离了自动化测试最关键的工作部分即:脚本编写,也为脚本管理、数据模板结合等用例的功能丰富提供更多可能性。

    流程设计

    如下是脚本自动化测试完整的业务执行方案:在这里插入图片描述
    自动化测试 UI 代码以 git 工程的方式托管在公司的 git 服务器上,在工程基础上编写脚本,调试脚本通过之后合并入 git 工程,在 gitlab 上每一个脚本都会有一个唯一的地址,通过这个地址可以获取到指定脚本,然后通过接口 / 表单的方式提交脚本运行测试,运行完成得到质量报告。

    值得说明一下的是,在自动化测试过程中,公共方法、selenium / appium 公共 page object 等脚本数据会随着自动化测试的深入越发庞大,所以需要图中的公共方法抽取过程,这样带来的好处是由于脚本的抽取、复用会使脚本的编写效率会越来越快。

    如下是脚本执行流程结构图,包含脚本执行的流程和结果收集:在这里插入图片描述
    脚本执行数据、执行交互设计方案:在这里插入图片描述
    这里主要体现的是脚本和运行平台间的数据交互、执行能力交互,比如脚本执行时需要使用到 appium 的 driver,而这个 driver 是通过平台的设备参数来决定的,在运行时平台动态生成 driver 然后通过协议类的方式注入 driver 到脚本内部,运行过程中通过协议类的停止、暂停、等待、销毁等方法进行控制,运行完成后通过协议类获取到运行结果。在脚本需要一些特定的功能时,也可以通过协议类引入接口方法,然后运行平台通过接口代理的方式动态注入实现类的方式实现。

    在实施的过程中发现有两个难点,主要如下:

    类和第三方包引用管理引起的脚本编译问题

    在自动化测试脚本编写过程中,不可避免需要使用一些引入包,比如一些方便的工具类使用包等,对于 JAVA 脚本来讲更新类、包引入等都需要重新编译部署才可以运行使用,测试平台不可能会因为脚本类、包的变化重新编译部署平台,而脚本的编写绝大部分都是类引入的变化,包引入变化的比例很小,所以在类的变化上使用 Java 动态编译技术解决类的动态引入,第三方的包引入更新则通过平台工程的发版提前引入这些包升级完成。

    协议类和包更新的自动化更新过程

    在云平台和脚本工程中间是通过协议类进行数据交互,而定义的这个协议类和包发生之后按照上面的方案来说是需要云平台重新部署才可以的,在实践中发现脚本的能力建设和扩展等都需要通过协议类的修改才能实现,这就决定了这个协议类会频繁的发生变更,所以 Agent 工程中在动态编译前,手动校验了服务器上的协议类版本,如果发现了新版则下载新版的协议类 jar,在动态编译时替换到 -classpath 的协议类版本参数,这样就做到了指定协议类内容的动态更新和自动化部署。

    脚本设计

    在上面提到过 「对于 Java 来说可以将一些公共的方法抽象出来放到脚本的父对象中,通过继承将脚本编写能力赋予给脚本本身」,所以脚本设计分两个模块:

    协议父对象实现在这里插入图片描述
    如图所示父对象中提供了测试驱动 androidDriver、log 日志、checkPoint 检查点、img 截图等脚本能力

    用例子对象编写在这里插入图片描述
    如图所示,实际的脚本继承父对象的能力之后,可以完成编写相关页面测试逻辑、业务逻辑的自动化测试任务

    脚本调试和运行

    平台脚本调试可以通过如下两种方式进行:

    本地调试

    自行使用 main 方法、或者使用单元测试框架调试脚本通过在这里插入图片描述
    然后将主体修改为规定格式的自动化脚本,视情况修改 appiumDriver 引入方式、添加日志记录、截图、检查点等
    在这里插入图片描述
    远程调试

    远程调试需要在云测试平台上申请一台使用设备如图:在这里插入图片描述
    点击图中的按钮,将脚本粘入运行,如下图:
    在这里插入图片描述
    测试报告展示

    报告主要分为如下几个部分

    测试基本信息
    在这里插入图片描述
    主要展示测试过程的 app 基础信息和测试相关的一些信息展示,概况展示脚本所有检查点的通过比例,脚本运行的设备、通过、失败的数据统计,运行概况展示每一个脚本在每一个设备上运行的过程和结果,以脚本和设备为维度,log 链接中会展示详细的脚本运行步骤日志

    检查点概况在这里插入图片描述
    脚本运行的核心结果,主要展示此次自动化测试过程中所有的测试结果

    截图/步骤/异常在这里插入图片描述
    在脚本运行结束后,通过反射的方式获取到脚本用例的详细数据,通过 「截图/步骤/异常」细化展示每一次运行的步骤、图片、和检查结果

    性能图表、过程视频在这里插入图片描述
    在这里插入图片描述
    同时在脚本运行过程中也会通过 appium 框架功能实现设备的网络上下行统计,然后渲染性能数据生成图表并提供视频回放脚本执行过程。

    以上内容希望对你有帮助,有被帮助到的朋友欢迎点赞,评论。

    软件测试是IT相关行业中最容易入门的学科~不需要开发人员烧脑的逻辑思维、不需要运维人员24小时的随时待命,需要的是细心认真的态度和IT相关知识点广度的了解,每个测试人员从入行到成为专业大牛的成长路线可划分为:软件测试、自动化测试、测试开发工程师 3个阶段。

    这里有我整理的一些资料,如果你不想再体验一次自学时找不到资料,没人解答问题,坚持几天便放弃的感受的话,可以加我们在这里插入图片描述

    展开全文
  • SpringBoot - 应用程序测试方案

    千次阅读 2021-05-24 19:59:19
    文章目录PreSpring Boot 中的测试解决方案 Pre 本篇博文我们开始梳理下Spring 提供的测试解决方案。 对于 Web 应用程序而言, 一个应用程序中涉及数据层、服务层、Web 层,以及各种外部服务之间的交互关系时,我们...
  • 软件测试之测试方案

    万次阅读 多人点赞 2019-06-07 13:08:30
    测试方案是从测试的角度去分析或者说分解需求,在方向上明确要怎么测,分析结果就是测试点和测试方法测试方案包含: 1、引言(含a、编写目的;b、预期读者;c、参考资料); 2、测试范围; 3、测试策略...
  • 测试方案包括哪些内容

    千次阅读 2022-04-10 11:11:46
    这部分是讲述测试方案的目的、作用之类的。 项目介绍 对项目进行一个简要的概述,包括哪些用户,不同类型的用户主要操作是什么。 参考文档 包含项目计划、项目软件设计说明书,需求分析和说明书、接口文档等。 术语...
  • 系统测试方案通用版

    千次阅读 2020-09-17 16:44:46
    系统测试方案通用版 ** 1 测试范围 1.1 功能性测试 1.1.1 功能测试 1、 表单提交非空判断: 不输入任何信息直接提交,查看会不会有非空提示,根据提示进行填写(注意查看提示信息是否正确),直到不有提示能够提交...
  • 一份完整测试方案模板

    万次阅读 多人点赞 2020-04-19 10:55:37
    一份完整测试方案模板 文章目录前言整体架构图1.1 编写目的1.2 项目背景1.3 测试目标1.4 测试参考文档1.5 测试提交文档1.6 术语和缩写语2.1 测试配置要求2.2 测试方法2.3 测试数据2.4 测试策略2.4.1 单元测试2.4.2 ...
  • 软件测试 | 测试方案怎么写

    千次阅读 2021-03-25 20:20:40
    测试方案主要包括:测试范围、测试对象、测试模型(测试组网图,测试策略)、测试需求(测试需要准备的东西:环境,工具、数据等)、用例设计等。
  • 性能测试详细测试方案

    万次阅读 多人点赞 2019-08-22 17:46:33
    性能测试详细测试方案 前言 平台XX项目系统已经成功发布,依据项目的规划,未来势必会出现业务系统中信息大量增长的态势。 随着业务系统在生产状态下日趋稳定、成熟,系统的性能问题也逐步成为了我们关注的焦点:...
  • 面试的时候,很多小伙伴都被面试官问过这个问题“测试计划和测试方案有什么区别”? 到底有什么区别呢?我们先好好了解下这两个文档。 一、测试计划 1、测试计划是什么 测试计划是组织管理层面的文件,从组织...
  • 一文搞懂App测试,APP测试方案

    千次阅读 多人点赞 2021-07-31 17:32:40
    测试理论阶段与测试用例设计方法等即适用于WEB产品,也适用于APP产品。 ●理论阶段方法: 等价类 边界值 囚果图 判定表 场景法 流程图 正交法 错误推测法 4.项目阶段适用的测试用例设计方法 ●等价类与边界值组合 ...
  • 摘 要:介绍了用Multisim 仿真软件测试门电路延迟时间的方法,提出了三种测试方案,即将奇数个门首尾相接构成环形振荡电路,用虚拟示波器测试所产生振荡信号的周期,计算门的传输延迟时间;奇数个门首尾相接构成...
  • 测试方案模板

    万次阅读 多人点赞 2019-07-16 09:52:43
    (iwebshop项目)测试方案 (仅供参考) 文档版本控制 文档版本号 日期 作者 审核人 说明 V1.0 2017/11/24 陈.. ...
  • 测试方案的设计及模板

    千次阅读 2019-11-14 16:37:21
    测试方案设计及模板测试方案设计概括xx测试方案_模板1.引言2.测试策略3.测试设计4.测试资源5.输出文档6.修订记录推荐书籍 测试方案设计概括 xx测试方案_模板 1.引言 1.1目的 根据需要实现的需求与软件的设计架构...
  • 系统集成测试方案模板

    热门讨论 2011-10-28 09:44:54
    描述测试的各个阶段(例如,单元测试、集成测试或系统测试),并说明本计划所针对的测试类型(如功能测试或性能测试)。
  • 系统测试方案编写(五)

    千次阅读 2021-01-16 00:38:00
    系统测试方案是站在技术角度上,由测试设计师编写,根据测试计划规定的目标来给定资源限制和一些具体的方法和方案,是对后续测试工程师工作如何开展的技术层面的指导。 内容包括:概述,被测对象,应测特性,不应测...
  • 自动化测试方案

    万次阅读 2021-09-24 09:52:16
    自动化测试体系方案 方案1全编写代码流程 UI自动化: 使用python或java,配合selenium库及pytest框架做UI自动化测试。(通过selenium的webdriver驱动,驱使浏览器) 1. WebDriver API(基于Java、Python) java...
  • 测试方案设计流程指南

    千次阅读 2020-09-07 23:51:28
    一、测试方案设计基本理论 产品分析,产品测试需求分析,测试规格分解分配,特性测试需求分析,特性测试设计,测试设计维护,测试用例设计,测试用例设计维护。 测试特性方案设计任务书 测试特性方案设计任务书包含...
  • 在测试过程中,测试计划,测试策略,测试方案,是比较容易混淆的几个概念。 测试计划 什么是测试计划? 测试计划Testing plan,描述了要进行的测试活动的范围、方法、资源和进度的文档;是对整个信息系统应用...
  • 测试计划和测试方案区别

    万次阅读 多人点赞 2018-07-05 20:25:10
    关于测试计划和测试方案的区别,这里主要从编写目的、定义和层次、编写时间和依据、软件过程、文档内容这五方面来说明,具体内容如下: 一、编写目的 制定测试计划目的:按照所制定的测试计划可以有效的计划、执行...
  • 完整全面介绍基于泰克仪器的电源设计与测试解决方案测试原理、测试内容、测试设备、测试方法
  • 测试方案如何写

    千次阅读 2020-08-05 16:29:48
    测试方案:是描述被测对象需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案。简言之,测试方案是从技术角度对整个测试活动进行规划和控制。 制定测试...
  • 系统测试方案

    热门讨论 2012-07-17 10:32:59
    系统测试方案 目录 1 概述 3 2 测试资源和环境 3 2.1 硬件配置 3 2.2 软件配置 3 2.3 测试数据 3 3 测试策略 3 3.1 功能测试 4 3.2 性能测试 4 3.3 用户界面(UI)测试 4 3.4 安全性与访问控制测试 5 3.5 兼容性...
  • 测试方案包含哪些内容?

    千次阅读 2022-01-26 09:57:35
    经常会有学员问测试方案都有哪些,整个过程其实还是比较懵逼的。因为这个问题比较泛!!! 首先什么是方案?方案是指针对一件事物整体性的提出总体的方针和广度上的解决办法,是为后续的具体项目实施铺平道路。 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,160,569
精华内容 864,227
关键字:

测试方案

友情链接: StripReloc113.zip