天道酬勤,学无止境

Python自动化测试的完整流程,看完才知道原来这么简单

前言:

1.自动化测试流程图:

Python自动化测试的完整流程,看完才知道原来这么简单

第一步:制定好测试计划

我们在准备展开自动化测试之前,最好是先制定好测试计划,明确测试对象、测试目的、测试的项目内容、测试的方法、测试的进度要求,并确保测试所需的人力、硬件、数据等资源都准备充分。制定好测试计划后,下发给用例设计者。

第二步:分析好测试需求

测试用例设计者根据测试计划和需求说明书,分析测试需求,设计测试需求树,以便用例设计时能够覆盖所有的需求点。一般来讲,基于Web功能测试需要覆盖一下几个方面:

页面链接测试,确保各个链接正常;
页面控件测试,确保各个控件可靠;
页面功能测试,确保各项操作正常;
数据处理测试,确保数据显示准确、处理精确可靠;
模块业务逻辑测试,确保各个业务流程畅通。

第三步:设计好测试用例

通过分析测试需求,设计出可以覆盖所有需求点的测试用例,从而形成专门的测试用例文档。由于不是所有的测试用例都能用自动化来执行,所以需要将能够执行自动化测试的用例汇总成自动化测试用例。必要时,要将登陆系统的用户、密码、产品、客户等参数信息独立出来形成测试数据,便于脚本开发。

第四步:搭建好测试环境

自动化测试人员在用例设计工作开展的同时即可着手搭建测试环境。因为自动化测试的脚本编写需要录制页面控件,添加对象。测试环境的搭建,包括被测系统的部署、测试硬件的调用、测试工具的安装盒设置、网络环境的布置等。

第五步:编写好测试脚本

根据自动化测试用例和问题的难易程度,采取适当的脚本开发方法编写测试较薄。一般先通过录制的方式获取测试所需要的页面控件,然后再用结构化语句控制脚本的执行,插入检查点和异常判定反馈语句,将公共普遍的功能独立成共享脚本,必要时对数据惊醒参数化。当然还可以用其他高级功能编辑脚本。脚本编写好了之后,需要反复执行,不断调试,知道运行正常为止。脚本的编写和命名要符合管理规范,以便统一管理和维护。

第六步:分析出测试结果、记录好测试中出现的问题

应该及时分析自动化测试结果,建议测试人员每天抽出一定时间,对自动化测试结果进行分析,以便尽早地发现缺陷。如果采用开源自动化测试工具,建议对其进行二次开发,以便与测试部门选定的缺陷管理工具紧密结合。理想情况下,自动化测试案例运行失败后,自动化测试平台就会自动上报一个缺陷。测试人员只需每天抽出一地你该时间,确认这些自动上报的缺陷,是否是真实的系统缺陷。如果是系统缺陷就提交开发人员修复,如果不是系统缺陷,就检查自动化测试脚本或者测试环境。

第六步:跟踪测试BUG

测试记录的BUG要记录到缺陷管理工具中去,以便定期跟踪处理。开发人员修复后,需要对此问题执行回归测试,就是重复执行一次该问题对应的较薄,执行通过则关闭,否则继续修改。如果问题的修改方案与客户达成一致,但与原来的需求有所偏离,那么在回归测试前,还需要对脚本进行必要的修改和调试。

受限制的 HTML

  • 允许的HTML标签:<a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • 自动断行和分段。
  • 网页和电子邮件地址自动转换为链接。

相关推荐
  • 看完这篇,测试用例常见的坑你一定能躲掉!
    1、测试用例是什么? 测试用例的设计就是如何覆盖所有软件表现出来的状态,即在满足输入/输出的一组条件下,软件运行时一系列有次序的、受控制的状态变化过程。 2、设计用例是否有必要? 将测试内容记录下来,避免了在执行的时候部分测试点被遗漏,另外也便于用例评审,用例总结,对后期测试工作起到改进作用,因此,测试用例必须要写,颗粒度可以视情况而定,针对测试人员少,上线时间紧的项目,可做思维导图载出测试点。 3、如何写测试点? 根据需求及设计交互稿,先列功能点,后扩展功能点为测试点(作为测试的标题),有必要的时候借助产品、开发、后端的力量,保证用例的覆盖度、学会借力。 测试点(注:这里不是测试用例,用例一般都比较详细,开发不一定会花费很多时间去做自测)写完后,可发给开发做自测,部分遗漏点可以在测试时进行记录与补充。 4、设计用例的益处? 设计用例的过程可以更深刻的理解需求,熟悉各功能点,保证尽可能全的覆盖到各测试点,也便于用例评审。 5、测试用例有哪些测试方法? 等价类划分法,边界值法,功能图法、错误推测法、因果图法、场景法。 6、如何保证用例的覆盖度? 首先一定要熟悉需求,需求分析,拆解非常重要,需要熟悉过程中,不理解或者有疑问的地方,一定要找产品进行及时沟通,确定结果,其次项目开发过程中,每期的测试用例都要不短总结,学会总结,尽可能的保证少漏,其实这个与测试。 思维密切相关,工作经验的积累
  • 【转】Backtrader 教程 — 量化投资原来这么简单(1)
    都说Python可以用于量化投资,但是很多人都不知道该怎么做,甚至觉得是非常高深的知识,其实并非如此,任何人都可以在只有一点Python的基础上回测一个简单的策略。 Backtrader是一个基于Python的自动化回溯测试框架,作者是德国人 Daniel Rodriguez,是一个易懂、易上手的量化投资框架。今天我们就来试试用Backtrader进行简单的量化策略回溯。 当然,第一篇文章将会使用最简单的投资策略给大家起个头。通过学习这一篇文章,你将能学会以下这个简单的量化策略: 买入:五日价格移动平均线(MA5)和十日价格移动平均线(MA10)形成均线金叉(MA5上穿MA10)原理:最近处于涨势 卖出: 五日价格移动平均线(MA5)和十日价格移动平均线(MA10)形成均线死叉(MA10下穿MA5)原理:最近处于跌势 这个策略真的有用吗?普通人可能要炒一辈子股才能发现它的实际作用,而使用Python进行量化验证,则能迅速得到答案。 1.准备 开始之前,你要确保Python和pip已经成功安装在电脑上,如果没有,请访问这篇文章:超详细Python安装指南 进行安装。 Windows环境下打开Cmd(开始—运行—CMD),苹果系统环境下请打开Terminal(command+空格 输入Terminal),准备开始输入命令安装依赖。 当然,我更推荐大家用VSCode编辑器
  • 因为“测试能力单一”面试被拒,测试工程师何去何从?
    最近公司有几位同事打算离职出去看看其他机会,几轮面试下来感觉很好,最终却没有收到offer。这几位同事都有好几年工作经验,测试经验丰富,也参与过大型项目的测试,在测试用例设计、测试流程把控、测试执行等方面做得非常好,和面试官交流的时候都非常流畅,但最终的反馈是“测试能力单一”。 测试能力单一为什么不受欢迎呢?先听我分享一下个人经历: 记得几年前,公司内部有个孵化项目,一周一个迭代,需要在三个月内上线。当时我负责这个项目的测试,项目开动前我就列出了详细的测试计划、人力安排,冒烟测试、回归测试、自动化方案、线上巡检等等。 各种测试角色紧密配合,按照我这个计划,感觉产品质量是不会有问题的!然而当我把这个“天衣无缝”的计划拿给Boss看时,Boss看完立刻表扬了我,然后打回了我的计划,原因是这样做时间周期太长,人力投入成本大,Boss需要的是在人力财力有限的情况下,支撑项目快速迭代。 因此,现在的市场需要的是有全栈测试能力的工程师。 软件测试的本质是交付高质量的软件产品,产品的质量与时间、成本、需求范围存在着制约关系,每个Boss都希望投入低、实现更多的功能,又能尽快上线。 想要这三个方面都兼顾,一句话总结开来就是:用更少的人力在更短的时间内hold住更多的功能迭代。那么最直接的就是一人身兼多职,你既要懂测试流程,又要会自动化,还具备专项测试能力,就是我们所说的全栈测试工程师。
  • 测试职业发展、高级测试需要知道哪些、P6测试需要知道什么、测试的知识点、测试自我提升、测试圣经
    转载自 https://testerhome.com/topics/16354 阅后感: 1、文章很多使用的经验让人受益匪浅、例如游戏测试那一段,不被当时的测试主流和所谓的方法禁锢住、而是另辟蹊径,像极了我以前听到的故事,一个测试测出了火箭有问题,没有人相信他发现的问题,后来出事了领导想起来有人汇报过,于是去问他原因,毕竟火箭那么大,测试不可能发射个火箭来测试。后来测试说,他把火箭的每个零件都进行了单独的测试,知道发现有个识别用的零件不能分辨星光和日光,所以认为零件有故障(道听途说,并不清楚是否有这样的事,但是这股想办法去测试的劲儿一定是极好的) 2、本人工作也有5年左右了,还是个p5,想晋升为p6高级测试,一个是因为公司的晋升机制、晋升标准不明确,一个是因为自己也不清楚p6到底需要啥技能,有些时候会比较焦虑,因为想不通。很简单、于是我去各个面试app去看别人的招聘要求、去百度p6测试知识脉络图(没啥收获)、去csdn上搜索高级测试、职业晋升。于是搜索到了这篇文章,得到了两个关于P6高级测试需要的东西、第一个是如果没有什么知识脉络,自己没有一个系统的目标,那就多看书!比如看看shell、看看docker、看看js、看看http协议。不要因为别人说高级测试只需要掌握4个点,就只去学4个点,而是你去多读书,然后你会发现有些公司可能要这几个点,有些公司要那几个点,都在你看过的书里
  • 软件开发中需要专职的 QA 吗
    以下为文章原文:http://www.iteye.com 这个文章必然是有争议的,我在我的微博上讨论过很多次了,每次都是很有争议的。对于不同的观点,有争论总是一件好事,这样可以引发大家的思考。所以,对于我的这篇博文,如果你赞同我的观点,我会感到高兴;如果你会去认真地深入思考,我也会高兴;如果你反对,没关系,可以讨论。在此之前,我想先说明一下我观点里的这个“专职QA”是怎么定义的:很多公司成立的专门做测试的技术人员,仅测试不开发。这些 QA 对于软件开发技术并不熟悉,甚至不懂。我之前供职过的公司几乎都有专职的QA团队(专职的测试人员)。自从在上个公司,我的开发团队在一个项目上被QA部门搞得一团糟后,我就越来越怀疑专职QA存在的意义。我的观点不一定对,但请让我鲜明地表达一下——企业不需要全职的QA,甚至不需要QA这一专职角色或部门。因为,不懂开发的人必然做不好测试,就像不懂开发的研发经理必然管不好研发团队一样。现在,我越来越觉得Dev应该应该是做测试最合适的人选,而这也必然是未来的趋势(因为我已经看到了中国程序员的进步,相比起10年前,今天的程序员已经是非常全面了,再来十年,必然证明我的观点是对的)。一、两篇文章在我正在展开说明之前,我想先引用两篇文章。一篇是《On testers and testing》(点击查看中文翻译)。本文的作者Sriram Krishnan是一名程序员
  • 阿里小蜜新一代智能对话开发平台技术解析
    导读:本次分享的内容是“新一代智能对话开发平台”(Dialog Studio),中文名叫对话工厂,是小蜜家族中的一个做多轮任务型对话开发产品,目标是以平台的方式赋能更多开发者,让所有的对话者能创造自己的多轮对话机器人。大概分为四个部分,主要包括:为什么做平台?“新一代”对话开发平台“一站式”对话开发平台业务应用▌1. 为什么做平台首先给大家举个例子:机器人:您好,这里是114移车热线,您的车挡住了出行,请您移下车好吗?车主:哦,哪个车子啊?机器人:车牌是浙A,尾号是29,请问是您的车吗?车主:啊,什么情况?机器人:这手机登记的是您的号码,您能去看一下吗?车主:什么号码,我,你再说一遍机器人:车牌是浙A,尾号是29,请问是您的车吗?车主:哦,是我的,我打个电话机器人:那请您移一下车好吗?车主:嗯这是一个政务场景上114移车的 case,这个场景是用我们“对话工厂”开发的机器人实现的。114移车 case 只是一个我们真实生活中很小的一个点,还有很多的业务是需要对话机器人来帮助人类解决各种各样的问题,或者减少人类客服成本。比如说在政务的其他领域,我们希望机器人能帮助人来查社保、查医保、查公积金等;在电商领域,我们希望机器人能帮助做售后的客服,帮助消费者来开发票、催发货、查物流等;在电信领域,我们希望机器人能引导用户查话费、查流量等。但是创造一个对话机器人的门槛是非常高的,做一个
  • 最强大脑.带你全面认识软件测试
    一.前言:软件测试的IEEE定义:使用人工或自动的手段来运行或测量软件系统的过程,目的是检验软件系统是否满足规定的需求,并找出与预期结果之间的差异。软件测试的发展趋势:A.测试工作将进一步前移。软件测试不仅仅是单元测试、集成测试、系统测试和验收测试,还对需求的精确性和完整性的测试技术、对系统设计的测试技术将成为新的研究热点。B.软件架构师,开发工程师,QA人员,测试工程师将进行更好的融合C.测试职业将得到更充分的尊重。E.测试外包服务将快速增长,和软件开发外包一样,软件测试外包将成为全球化的趋势。在软件测试的工作当中, 测试人员要了解项目需求内容,从用户的角度提出自己的测试看法; 测试人员要编写合理的测试计划并与项目整体计划有机地整合在一起; 测试人员要编写覆盖率高的测试用例;测试人员要认真仔细的实施测试工作,并提交测试报告以供项目参考;测试人员要进行缺陷跟踪和分析。那么今天一菲和大家谈谈软件测试的具体需要了解的内容有哪些?二.正文1.问:你在测试中发现了一个 bug ,但是开发经理认为这不是一个 bug ,你应该怎样解决。答:首先,将问题提交到缺陷管理库里面进行备案。然后,要获取判断的依据和标准:根据需求说明书、产品说明、设计文档等,确认实际结果是否与计划有不一致的地方,提供缺陷是否确认的直接依据;如果没有文档依据,可以根据类似软件的一般特性来说明是否存在不一致的地方
  • 2021最新基于Python自动化软件测试面试题大全(含答案)
    1、什么是兼容性测试?兼容性测试侧重哪些方面? 兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行,即是通常说的软件的可移植性。 兼容的类型,如果细分的话,有平台的兼容,网络兼容,数据库兼容,以及数据格式的兼容。 兼容测试的重点是,对兼容环境的分析。通常,是在运行软件的环境不是很确定的情况下,才需要做兼容。根据软件运行的需要,或者根据需求文档,一般都能够得出用户会在什么环境下使用该软件,把这些环境整理成表单,就得出做兼容测试的兼容环境了。 2、我现在有个程序,发现在 Windows 上运行得很慢,那么怎么辨别是程序存在的问题还是软硬件系统存在的问题? 检查系统是否有中毒的特征。 检查软件/硬件的配置是否符合软件的推荐标准。 确认当前的系统是否是独立,即没有对外提供什么消耗 CPU 资源的服务。 如果是 C/S 或者 B/S 结构的软件,需要检查是不是因为与服务器的连接有问题,或者访问有问题造成的。 在系统没有任何负载的情况下,查看性能监视器,确认应用程序对 CPU/内存的访问情况。 3、测试的策略有哪些? 黑盒/白盒,静态/动态,手工/自动,冒烟测试,回归测试,公测(Beta测试) 4、描述测试用例设计的完整过程? 需求分析 + 需求变更的维护工作。 根据需求得出测试需求。 设计测试方案,评审测试方案;方案评审通过后,设计测试用例,再对测试用例进行评审。 5
  • 高级运维工程师的打怪升级之路
    人生就像一场游戏,这场游戏给我们带来了的许多困难,但是我们为了梦想,为了家人,为了自己不断奋斗着,努力工作。 今天就让我带着大家一起回顾高级运维工程师打怪升级之路。 运维工程师在刚入行阶段是一很苦逼的,可能干着修电脑、掐网线、搬机器的活,显得没地位!时间也很碎片化,各种零碎的琐事围绕着你,也很难体现个人价值,渐渐的对行业很迷茫,觉得没什么发展前途。 这些枯燥无味工作的确会使人匮乏!技术是枯燥无味的,这些基本工作并非是多余的,这些经验会对后期的运维工作带来一定的帮助。所以在这个时期一定要保持积极向上的心态,持续的学习,争取找一个更锻炼人的工作! 职业发展 技术专家 发展规划:初中级工程师 -> 高级工程师 -> 架构师 -> 专家 适宜人群:比较喜欢挑战,热爱技术,有较强钻研精神,在某一领域有深入的理解,性格比较内向。 技术管理 发展规划:初中级工程师 -> 高级工程师 -> 主管/经理 -> 总监 -> CTO(首席技术官) 适宜人群:技术知识面广,有一些管理思维,善于交际,表达沟通能力强,经常关注行业内动态和主流技术。 初级 主要工作 修电脑,设备巡检 服务器上下架 网络服务部署 网站平台搭建与维护 1、Linux基础 刚开始阶段需要熟悉Linux操作系统安装,目录结构、启动流程等。 2、系统管理 主要学习Linux系统,生产环境中基本都在字符界面完成工作
  • 测试思想-测试流程简述
    测试过程(以下左图)与测试阶段(或类型)(以下右图) 图-1 说明: 1. 以上左图描述的通用软件测试过程。右图描述的是具体的测试活动阶段,按不同的测试阶段分可分单元测试、集成测试、确认测试、系统测试、验收测试,回归测试,冒烟测试等测试类型。 2. 回归测试是指修改了旧代码后,重新进行测试以确认缺陷的修复,及修改没有引入新的错误或导致其他代码产生错误。软件开发的各个阶段都会进行多次回归测试。 3. 冒烟测试(也叫提交测试),正式测试前对软件主业务流程和主功能进行验证与确认,确保后续测试能正常进行的测试。现状:一般是在新版本提交前,进行正式测试前的进行冒烟测试 4. 右边的每个测试活动阶段,可以按左侧的测试过程进行,文档评审,测试计划、测试设计、测试执行、测试总结等(可根据实际情况对测试过程进行适度裁剪) 5. 左边的和右边两幅图进融入软件开发过程中,就产生了以下将说到的各种测试模型 6. 阶段(类型)细分:如下图 测试过程和开发过程协作(典型模型举例说明) W模型为例 图-2 说明: 1. 其中系统设计也叫概要设计。 2. 软件需求评审,主要是评审软件需求规格说明书、主要依据是产品需求文档 3. 系统设计评审,主要是评审系统架构设计等,主要依据系统概要设计说明书 4. 详细设计评审,主要是评审详细的设计,比如接口设计是否合理,主要依据详细设计说明书 ps:现实状况是,一般的公司
  • 互联网测试校招系列1:赢在测试岗位
    大家好,我是财哥,本篇为大家带来互联网测试岗位校招系列第一篇:测试岗位的选择。关于选择职业这件事情,我想先用两个词语来引题:战略和战术。战略:指的是决定或者选择做什么事情;而战术:指的是该如何做一件事情。这两个概念非常重要,举个例子:当冬天来临的时候,我们会面临保暖的问题。关于保暖这个选择,你会是穿一件羽绒服还是多穿几件T恤呢?相信大多数人会说:肯定是穿羽绒服啊,在大冬天的穿N件T恤是不是sha啊?确实,正常人思维都会第一时间想到穿羽绒服,其实这就是为了保暖而去制定战术了。穿羽绒服或者是T恤这个事情就是具体的战术策略。那为什么我们没有想过冬天是否应该保暖呢?因为在中国的冬天很冷,保暖这个决定是我们作为人类自然而然的选择:一个不费脑子做出的选择。这里牵出另外一个问题:「在选择保暖or不保暖」和「穿羽绒服orT恤」之间哪个权衡更重要?假如你在夏威夷,到了冬季,你会选择保暖吗?我想大概率不会:夏威夷的冬天并不冷,那里的人不需要为冬天做保暖措施。因此,选择保暖或者不保暖就是一个战略,而选择穿什么(羽绒服还是T恤)就是战术了。在生活和工作中,战略的产生效果是大于战术的。比如比选择了保暖,但是穿了十件T恤,虽然看起来比较滑稽,总比选择不保暖,继续保持现状(秋季一身轻薄外套)要好得多。同样,关于选择测试岗位和这个行业的选择,我们也应该用战略和战术的思维去思考如何选择
  • 【缺陷管理】10:怎样有效的记录软件缺陷(Bug)?
    bug从修复到解决的流程 通常情况下,一个bug从发现到解决的流程应该是这几步: 这其中,发现bug的环节不可控,因为我们不知道什么时候会有bug提出来,我们能做的就是发现bug后用最少的时间和人力成本来解决这个bug(都说技术人员的kpi不好衡量,如果做好了形成了团队的规范准则,应该也可以算一个绩效点,因为可以提高工作效率,至于权重多少,需要配合实际数据来分配)。复现bug环节,简单的问题很好复现,可能比较耗成本又最容易忽视的环节应该是复现bug了,至于定位bug,修复bug和测试环节,因为天生自带主角光环,更容易被重视。那么,有没有办法尽可能减少这个环节的时间和人力成本呢? 发现bug是测试人员必须具备的能力,不管在什么公司,测试人员在执行测试任务的时候,发现bug和提bug,以及跟踪Bug是必要的工作。如何提出高质量的bug,是体现测试人员水平的重要标志。从功能测试人员,到测试开发,高级测试开发等,都避免不了与bug打交道。可是现在也存在这么一种现象:测试人员提的bug质量不高,开发人员看不明白。于是就来找测试人员,来解释这个bug是怎么回事,如此来回折腾浪费工作时间,在跨部门协作的时候,这样的情况尤其严重。 测试人员提bug质量不高,主要表现在如下几个方面: (1)bug表述不清,只有一句话,介绍bug是什么,然后没有其他的说明。 (2)不提bug,发现问题直接告诉开发人员
  • 还用什么scrapy!用这个框架快速轻量,原来爬虫这么简单
    之前,我们写爬虫,用得最多的框架莫过于scrapy啦,今天我们用最近新出的爬虫框架feapder来开发爬虫,看下是怎样的体验。 目标网站:aHR0cHM6Ly93d3cubGFnb3UuY29tLw== 需求:采集职位列表与职位详情,详情需每7天更新一次 为了演示,以下只搜索与爬虫相关的职位 1. 调研 1.1 列表页面 首先我们需要看下页面是否为动态渲染的,接口是否有反爬。 看是否为动态渲染的可以右键,显示网页源代码,然后搜索网页上的内容源码里是否存在,比如搜索列表的第一条知衣科技,匹配了0条,则初步判断是动态渲染的 或者可以用feapder命令,下载网页源码,查看。 打开后的页面为加载中 调用response.open()命令会在工作目录下生产一个temp.html文件,内容为当前请求返回的源码,我们点击查看,是一段js,有安全验证。因此可以推断出该网站有反爬,难度升级预警 feapder还支持使用curl命令请求,方式如下: 按F12,或者右键检查,打开调试窗口,刷新页面,点击当前页的请求,复制为curl,返回命令行窗口,输入 feapder shell --然后粘贴刚刚复制的内容 发现携带header,cookie也不行,可能是某些参数只能用一次吧。 调研结论:列表页有反爬,页面动态渲染 ps: 正常大神还会继续调研,列表接口是什么,如何破解反爬,但因为我是小白
  • 软件测试的分类及生命周期,你了解多少?
    前言:大家好,我是一菲,岁岁年年花相似,年年岁岁题不同。到了2020年的2月初了,还有1.2个月又到了每年找工作的金三银四季,这几天我翻阅资料和书籍,给大家搜集了软件测试分类和软件测试周期的内容,我个人认为我总结的是比较详细的,希望各位小伙伴们批评指正。希望今天的分享可以给朋友们能够带来帮助。 软件测试的分类: 一.按测试技术 1.黑盒测试 1.1、定义 在程序接口进行测试,它只是检查程序功能是否按照规格说明书的规定正常使用。也被称为功能测试或者数据驱动测试。它是通过测试来检测每个功能是否都能正常使用。在测试中,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。 1.2、黑盒测试优缺点 优点:a.容易实施,不需要关注程序内部的实现;b.更贴近用户的使用角度; 缺点:a.测试覆盖率较低,一般只能覆盖到代码量的40%;b.针对黑盒的自动化测试,复用率较低,维护成本较高。 1.3、黑盒测试主要测试内容 是否有不正确或遗漏的功能; 在接口上,输入是否能正确的接受?能否输出正确的结果? 是否有数据结构错误或外部信息访问错误? 性能上是否能够满足要求? 1.4
  • [小白进] 大佬们学习为什么简单?小白该如何学习?学历不高如何找工作?副业很好赚?了解后少走弯路
    一、前言 对于新手来说,最开始学习编程的难度不亚于学天书,那为什么有经验的程序员在接触一门新技术时能够快速的上手并且完成一些需求的开发呢? 有些人可能看了这个问题觉得我在说废话,“有经验那不快那怎么才快?”。其实你有没有想过经验是可以传授的?在学习某一技术前,首先了解大致全局学习起来是否更加得心应手? 编程对于大多数刚接触的同学来说是一片未知的世界,这个世界的所有规则都与自己之前所接触的知识不同,从而导致在学习这一门技术时,每一步都要去理解这个“世界”中很多的“规则”从而积累对这个编程的认知;在我看来学习一门技术前,对这门技术有一定的了解将会对自己学习这门技术会有着很大的学习效率提升。 例如你从未做过菜,也没见人做过菜,突然有一天你需要去做菜,你可能连第一步需要做什么都不懂,或者说每一步都需要有人去提示你,但你依旧不理解为什么要这样做。有经验的大佬由于熟悉整个流程、对这个世界规则熟悉,知道某些情况下为什么要这么做,并且可以从中得到自己的结论,那么在这些有经验的大佬接触这些“新事物”后也会快速的上手。 二、基础编程心法 基础编程排难 由于在院校中,大部分学生可能接触的第一门编程语言是 C 语言,在此我们使用 C 语言为例。 在学习 C 语言时,很多学生由于刚学习编程,对于编程完全不了解,直接学习 C 语言更加难上加男,导致形成了一个很有意思的“刻板映像”,那就是 C 语言是最难的了。
  • 【我拼搏的2016】-苦逼运维如何变身为SRE成长经历
    提起运维很多人能联想到的字眼就有“苦逼”、“辛苦”、“加班”、“背锅”,随着国内互联网大潮的兴起,特别是最近几年互联网行业的火爆,催生了大批运维从业人员。类似于当年网络管理员的职业发展,由于普通人对于该领域专业知识的匮乏和良莠不齐的从业人员素质,拉低了整个社会对于这一职业的认知,和当今的运维职业何其相似。 作为运维大军中的一员,我也是经历过从自己摸索自学到专业培训机构系统化学习,再到逐渐完善知识体系和不断提高眼界认知,过程是极其曲折艰辛的,但是这是必经之路,没经历过大的事故、事件或者说大项目的历练,运维生涯一定是不完整的。曾经也非常彷徨,特别是刚入门那段时间兴奋和紧张交织,既有浓浓的好奇求知欲同时伴有茫然无措,由于各方面经验不足怕遇到事情之后自己不知道如何处理或者害怕处理不好,被动接受任务和工作内容。再到慢慢主动挑战,改善遇到的不足和优化不合理的地方,到最后具备了一定的架构和全局掌控能力,在这一阶段看似可以满足和放松下来,实际上这完全是是一种错觉,现今的行业环境和对从业人员的要求不断拔高和刷新。 我是愤怒蚂蚁,于2016年10月份参加了51CTO学院老男孩Alex老师主讲的Python自动化开发工程师课程,希望自己通过python培训能够在平时运维和管理过程中更多的应用python开发,来提高工作效率和逼格,真正实现上班能够喝茶看报额和泡前台妹纸。 经过几个月的学习
  • 前后端分离实践有感
    前后端分离并不是什么新鲜事,到处都是前后端分离的实践。然而一些历史项目在从一体化 Web 设计转向前后端分离的架构时,仍然不可避免的会遇到各种各样的问题。由于层出不穷的问题,甚至会有团队质疑,一体化好好的,为什么要前后端分离? 说到底,并不是前后分离不好,只是可能不适合,或者说……设计思维还没有转变过来…… 一体式 Web 架构示意 前后分离式 Web 架构示意 为什么要前后端分离 比为什么要前后端分离更现实的问题是什么时候需要前后端分离,即前后端分离的应用场景。 说起这个问题,我想到了 2011 年左右,公司在以 .NET 开发团队为主的基础上扩展了 Java 团队,两个团队虽然是在做不同的产品,但是仍然存在大量重复性的开发,比如用 ASP.NET WebPage 写了组织机构相关的页面,用 JSP 又要再写一遍。在这种情况下,团队就开始思考这样一个方案:如果前端实现与后端技术无关,那页面呈现的部分就可以共用,不同的后端技术只需要实现后端业务逻辑就好。 方案根本要解决的问题是把数据和页面剥离开来。应对这种需求的技术是现成的,前端采用静态网页相关的技术,HTML + CSS + JavaScript,通过 AJAX 技术调用后端提供的业务接口。前后端协商好接口方式通过 HTTP 提供,统一使用 POST 谓词。接口数据结构使用 XML 实现,前端 jQuery 解析 XML 很方便
  • 前后端分离实践
    本篇文章转自微信公众号【边城客栈】,分享给大家原文链接:https://mp.weixin.qq.com/s/nKvjsU2frT5NDU4DLWqvYg 一、前言 前后端分离并不是什么新鲜事,到处都是前后端分离的实践。然而一些历史项目在从一体化 Web 设计转向前后端分离的架构时,仍然不可避免的会遇到各种各样的问题。由于层出不穷的问题,甚至会有团队质疑,一体化好好的,为什么要前后端分离? 说到底,并不是前后分离不好,只是可能不适合,或者说……设计思维还没有转变过来…… 一体式 Web 架构示意 前后分离式 Web 架构示意 二、为什么要前后端分离 比为什么要前后端分离更现实的问题是什么时候需要前后端分离,即前后端分离的应用场景。 说起这个问题,我想到了 2011 年左右,公司在以 .NET 开发团队为主的基础上扩展了 Java 团队,两个团队虽然是在做不同的产品,但是仍然存在大量重复性的开发,比如用 ASP.NET WebPage 写了组织机构相关的页面,用 JSP 又要再写一遍。在这种情况下,团队就开始思考这样一个方案:如果前端实现与后端技术无关,那页面呈现的部分就可以共用,不同的后端技术只需要实现后端业务逻辑就好。 方案根本要解决的问题是把数据和页面剥离开来。应对这种需求的技术是现成的,前端采用静态网页相关的技术,HTML + CSS + JavaScript,通过 AJAX
  • 网工2.0 - 给你一次逆袭的机会
    聊天的画风已变! 你好,我是姜汁啤酒,咱们又见面了。 不知道你是否注意到,网络技术群里面的聊天画风慢慢开始变了。 以前,聊天内容是这样的。 兄弟,最近实验敲得咋样啊。 我刚把NP的题看完。 嗯,我准备学点安全和语音的技术。 而现在的聊天内容,以我的《老司机网络运维-读者群》为例。 大家讨论的不光是日常网络故障和经验汇总。 慢慢地,朋友们开始研究如何学习Python。 如何把玩Juniper的PyEZ模块实现日常运维自动化。 连这13周年庆学习专栏送书活动。 大家购买的不再是什么思科学习指南。 更多的是Python,Ansible等书籍。 难道,这个世界变了么? 我的回答是:世界不仅变了,而且速度超乎你的想象。 若现在的你,仍然像昔日的王朝,固守传统的网络技术疆土。 那很抱歉,云技术,虚拟化,SDN,NetOps网络运维自动化会慢慢撕开你坚固的防线。 所谓和你一条战线上的厂商们,纷纷倒戈。 思科IOS-XE系列的设备,华为CloudEngine系列的设备纷纷开始支持SDN,Python自动化,更别说Juniper以及其他大厂,全都自愿的,不自愿的投入了未来技术的怀抱。 新的网络技术时代 - 网络工程师2.0 到来! 机遇和挑战 每一次新的技术出现,并存着机遇。 若你抓住了,就会被技术的浪潮抬升到新的高度。 若负隅顽抗,最好的结果就是随波逐流。 正如文章标题所述,这是一次逆袭的机会
  • 50道阿里、京东、百度大厂常驻面试题 ,你离心动大厂只是一道题目的距离!
    前言: 大家好,我是一菲,在告别10天的春节假期后,再次和大家见面了,先道一声新年好。 虽说新年新气象,新的一年有新的期许,新的愿望,新的目标,那么同时也伴随着新的压力,新的责任等等。时间好快,还有一个月的功夫又到了每年金三银四的就业季和跳槽季。今天一菲就给大家梳理了像京东、阿里、百度大厂常见的面试题,希望会给即将要找工作的小伙伴们一些帮助。大家赶快一本正经的好好学起来吧。在这里插入图片描述1、问:你在测试中发现了一个bug,但是开发经理认为这不是一个bug,你应该怎样解决? 答:首先,将问题提交到缺陷管理库里面进行备案。 然后,要获取判断的依据和标准:根据需求说明书、产品说明、设计文档等,确认实际结果是否与计划有不一致的地方,提供缺陷是否确认的直接依据; 如果没有文档依据,可以根据类似软件的一般特性来说明是否存在不一致的地方,来确认是否是缺陷; 根据用户的一般使用习惯,来确认是否是缺陷;与设计人员、开发人员和客户代表等相关人员探讨,确认是否是缺陷; 合理的论述,向测试经理说明自己的判断的理由,注意客观、严谨,不参杂个人情绪。 等待测试经理做出最终决定,如果仍然存在争议,可以通过公司政策所提供的渠道,向上级反映,并有上级做出决定。 2、问:给你一个网站,你如何测试? 答:首先,查找需求说明、网站设计等相关文档,分析测试需求。 制定测试计划,确定测试范围和测试策略