时光荏苒,从毕业到现在已经10年,10年来一直从事着软件测试的工作。从一个什么都不会,到测试技术人员再到测试管理,期间有迷茫,有痛苦,有弯路,有捷径。 今天对自己过去的10年测试经历做一个总结,一是给自己重新出发增加动力,二是给刚入道的、迷茫中的测试朋友一点点建议,希望你们少走弯路。 首先,谈谈测试职业规划,即做什么的问题。 也不是,可以朝着测试管理岗位发展。说到这里,引出了测试职业规划的第一条路:测试管理。那么很容易想到职业规划的另外一条路,测试技术专家。在测试技术领域里,无外乎就是性能测试专家和自动化测试专家。 关于如何成长为测试管理人才:首先你一定要成为一个功能测试专家;通过参与至少2个完整项目的测试工作,你对测试理论、一个完整项目的测试流程、测试活动、测试输出了于指掌。 第二,正式场合的沟通能力,如项目周会、评审会议、总结会议,一定要提前做准备,讲什么、怎么讲,自己私下里先练习一下,这样在正式场合才能表达清楚、气定神闲、落落大方,给领导和同事留下一个好的印象。
VOL 313 28 2021-10 今天距2022年65天 这是ITester软件测试小栈第313次推文 本文3440字,阅读约需7分钟 Hi,大家好。 今天用10张思维导图,给大伙盘点面试过程中被问频率较高的接口测试相关面试题,如果想要获取更多面试题,可以在后台回复“面试顺利”进行解锁。 1 HTTP协议的特点? HTTP协议的特点可总结为以下5个方面: 2 HTTP请求的组成部分? HTTPS=SSL+HTTP,二者总结区别如下: 5 HTTP接口请求参数类型有哪些? 常用协议如下: 10 HTTP接口测试常见请求类型?
性能测试总结 目录 1、性能测试概念 2、性能测试的种类 3、性能测试关注角度 4、性能测试工具 5、性能测试指标 1、性能测试概念 【虚拟用户】模拟真实业务逻辑步骤的虚拟用户,其模拟的操作步骤都被记录再虚拟用户脚本中 【压力测试】侠义的压力测试,是指超过安全负载的情况下,对系统不断施加压力。 【稳定性测试】稳定性测试的TPS,响应时间,资源消耗等波动率不超过15%。 3、性能测试关注角度 【用户角度】响应时间,用户体验。性能测试压测服务器的响应时间一般在内网,所以不考虑公网的响应时间。压力测试不应该在公网测试,因为公网的环境是不可控的。 网络 一个网卡,进出网卡40% 两个网卡,进网卡80%,出网卡80% 9、低点临界值非高峰期的业务值A的各项指标是多少 (1)CPU 50% (2)内存50% (3)I/O 40% (4)网络30% 10 、性能测试各个点的总结 (1)在安全值希望没有虚拟内存的交换 (2)如何测试拐点?
还是对自己的复习经历来一个总结吧。 一、出来混总是要还的 软考考的知识,能够说有百分之六七十都在自考的学习中遇到过。 假设自考大酱油的同学。 总结: 考试的难度不大,首先要放松自己的心态。做到战略上藐视敌人,战时上重视敌人。 在做下午题的时候。一定要先从总体出发,对题目有一个宏观把握,做到胆大心细。
在用python进行自动化测试之前,我们今天先讲一下接口测试,如何进行接口测试,使用什么工具进行接口测试,如何使用fiddler进行抓包等等。 说到测试,我们有个金字塔模型可以了解一下。 什么是接口测试和为什么要做接口测试 接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。 如今系统越来越复杂,传统的靠前端测试已经大大降低了效率,而且现在我们都推崇测试前移,希望测试能更早的介入测试,那接口测试就是一种及早介入的方式。 接口测试的策略 接口测试也是属于功能测试,所以跟我们以往的功能测试流程并没有太大区别,测试流程依旧是:1.测试接口文档(需求文档) 2.根据接口文档编写测试用例(用例编写完全可以按照以往规则来编写, tag),start(取结果的offset),count(取结果的条数),如果接口请求正常返回状态200,返回大体如下结果: { "start": 0, "count": 10
万能公式和具体的方法如何理解 (1)万能公式 测试万能公式:功能测试+兼容性测试+界面测试+性能测试+易用性测试+网络测试+安全性测试. 自动化测试是指使用一定的自动化工具和脚本来执行测试,以达到减少人工测试工作量、提高测试效率、缩短测试周期、增加测试覆盖率和减少测试成本等目的。 自动化测试可以有效地解决手工测试的问题,提高测试效率,提高测试覆盖率,避免重复的测试工作,提高测试质量和稳定性。 Selenium+驱动+浏览器的工作原理 总结上图,Selenium的工作原理为以下: 开发人员编写自动化脚本代码(测试代码),使用Selenium提供的API来控制浏览器。 (3)和功能测试的区别: 性能测试和功能测试是软件测试中两种不同的测试类型. 功能测试: 功能测试主要关注系统是否按照需求规格说明书中定义的功能进行正常运行,并符合用户的期望。
界面测试总结 by:授客 问题提出:怎么进行界面测试? 分析:不管做什么,都讲究投入和产出比,即最少的投入获得最大的产出,不管做什么,我们都希望把复杂的事情简单化,同样做测试也一样。 如何做到呢? 动静结合,先静后动,循环交替:对每个界面(窗口)都采取先观察界面再对界面操作的的原则,对每个界面测试都尽可能的同其它功能测试结合,减少 “测试冗余”->减少投入。 同一界面上的控件数最好不要超过10个,多于10个时可以考虑使用分页界面显示。 2. 选项数较少时使用选项框,相反使用下拉列表框 3. 界面空间较小时使用下拉框而不用选项框。 4. 10. 对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。 11. 非法的输入或操作应有足够的提示说明。 12. 10. 如果能给用户提供自定义界面风格则更好,由用户自己选择颜色、字体等。 5.数据准确性 1.
数字与字母混合、16进制,8进制数值、货币型输入(允许小数点后面几位)、(4)安全性检查:不能直接输入就copy3、日期型输入框:(1)合法性检查:(输入0日、1日、32日)、月输入[1、3、5、7、8、10 )输入错误的用户名和错误的密码(5)不输入用户名和密码(均为空格)(6)只输入用户名,密码为空(7)用户名为空,只输入密码(8)输入正确的用户名和密码,但是不区分大小写(9)用户名和密码包括特殊字符(10 不应该显示英文的cancel、ok,应该显示中文的确定等)6、界面中各个控件是否对齐7、日期控件是否可编辑8、日期控件的长度是否合理,以修改时可以把时间全部显示出来为准9、查询结果列表列宽是否合理、标签描述是否合理10 进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。 测试人员尽量不要使用同一个用户进行测试8、提示信息:提示信息是否完整、正确、详细9、帮助信息:是否提供帮助信息,帮助信息的表现形式(页面文字、提示信息、帮助文件),帮助信息是否正确、详细10、可扩展性:
测试分析的目的 做对的事 分解复杂事物, 确保测试设计时, 所需面对的对象的完整性和正确性, 是后续活动的输入 确保测试活动的效率及有效性 测试分析输出 完整的测试范围, 包括测试功能点/功能点需要覆盖的测试点 /测试类型/测试手段 功能点/测试点之间的依赖关系, 合理的测试用例框架 3. 测试分析流程 分析框架 应当针对需求/产品线/功能模块整理测试框架, 明确测试范围覆盖的依据 范围包括功能测试/性能测试/稳定性测试/压力测试/兼容性测试/其他专项测试 分析角度 原始需求 功能设计/实现逻辑 测试分析设计总结 ---- 1. 测试分析设计的意义 测试工作前移 在得到测试对象之前测试无法实施, 但可以预先梳理和明确"我们要测试什么"和"和怎么测试", 充分的测试分析设计达到的理想状态是在得到测试对象前完成了除测试执行以外的所有内容
反应总体响应速度,和高于该值的10%超时率。是用来评估系统容量的重要指标之一。 最小响应时间:响应时间的最小值。反映服务最快处理能力。 最大响应时间:响应时间的最大值。反映服务器最慢处理能力。 如何做性能测试 常用性能测试方法 根据测试的指标,可以分为以下几种: 稳定性测试: 测试在未过载场景下,系统长期运行能否正常工作。 并发测试: 调节并发请求量,获取系统能够承受的并发请求量。 根据测试的手段,可以分为以下几种: 压力测试: 对系统施加压力,可以分成暴力测试和稳定性测试,分别对应时间维度和空间维度。 (暴力测试:施加过载压力,评估系统过载时的风险。稳定性测试:测试在未过载场景下,系统长期运行能否正常工作。) 基准测试: 特定标准条件下的测试。指定时间条件或负载条件。 容量测试: 根据负载测试的指标,评估系统的容量。
169.13583374023438 IO rate std deviation: 135.4413193785257 Test exec time sec: 86.042 TestDFSIO -clean 清理 读测试 mb/sec: 144.37628173828125 IO rate std deviation: 23.001677374779344 Test exec time sec: 360.126 总结
测试找BUG总结 1、对业务模块的理解要全面、深刻。 即:对此次新功能或者功能改进相关的业务要理解透彻。 好处: 1)对此次需求的合理与否可做出判断。 3、提测多了以后,要善于总结哪些是开发的易错点、易遗漏的点,发现后不仅要在测试时予以测出,还要告知开发此处易错,帮助开发分析原因。 如: 1)自我反省测试点是否全面,以及总结在测试中遇到的问题和对应的解决办法,以便在以后的测试过程中再次遇到,能够及时知晓该如何应对。 3)应将测试过程中新增的需求点,补充到wiki中,形成一个书面的完整知识体系备忘录,以便以后自己复习、查阅和供其他同事了解。 10、责任心是测试人员所必要的。 以上是笔者在日常测试工作中,对找bug的一些思维方面的总结,分享给大家,感谢阅读。
评审后对需求文档变更部分进行整理总结经验,提高以后的产品设计质量。 需求定稿后,不得随意更改。 用例管理及更新(需求变更以及测试过程中发现用例遗漏或错误及时更新)。 测试执行 冒烟测试,依据内部标准评定,不通过则拒绝测试,可以避免无效测试以及提升开发质量意识。 测试人员依据测试用例执行并标记执行结果,统计测试结果并进行分析总结,对于多发性问题形成文档,给至开发负责人。 bug记录,依据内部规范记录bug至管理系统上。 一轮测试完成后,进行组内交叉测试以及随机测试(猜错法)。 产出测试报告。 测试发版 系统发版应严格有效控制,勿随意过多发布,任意发布严重影响测试结果的有效性,增加了测试风险。 联调测试 目前联调测试执行混乱,各方未有效协调,建议协调好,产出联调测试计划。 产出联调测试场景及验证点而后开始测试。 测试总结 依据统计的bug分析需求及开发方面存在的问题,周知相关人员。
最近在论坛看到一些有关项目复盘的分享,有不少的收获,所以决定也把以往的项目总结分享出来,希望对同行能有所帮助,也期待能看到更多的分享。 测试要点项目测试要点的设计可以概括为两类:通用测试要点和专项测试要点。通用测试要点指的是所有功能测试都可以采用的方法。首先,笔者借鉴MVC框架将项目拆解为测试MVC模型。 如图4-1所示,我们可以通过篡改【10.认证状态及额度信息】的接口响应数据,验证不同认证状态以及不同额度信息场景下App端的交互和UI是否符合预期。 项目收获 & 问题复盘项目的收获可以从与人协作、业务知识、技术能力和项目管理四个方面来总结,具体内容本文暂不展开分享,具体项目可以参考几个方面去进行总结。 总结针对App测试项目总结,本文分别介绍了项目简介、项目成员、测试要点、测试方法与测试工具和项目收获与问题复盘五个模块,希望对大家有所启发,也欢迎留言交流。
如今,几乎人人都有手机,移动端设备数不胜数,手机、平板、笔记本都要使用无线网络,所以无线安全是非常重要的,本文的主要目的是无线渗透测试的方法总结,本文来源于老外的总结,可以点击原文连接查看原文,这里使用的操作系统是 总结 以上内容均来自uceka.com的博客,请自行测试,我只是作为一个备份,以备不时只需。需要查看原文的请点击原文连接查看。
当移植好一款wifi模块后,需要到检测机构去检测各项指标,取得相关认证,这时有必要了解下WiFi测试的相关测试内容。 单位dBm,dBm=10lg(p/mw)。 .上升沿下降沿时间 9.带内平坦度 10.载波抑制 11.接收机最小输入电平 12.接收机最大输入电平 13.接收机领导抑制比 14.接收机阻塞 15.动态频率选择 8.几种测试类型 传导测试 仅仅对模块进行测试,需要断开模块与天线的连接电路,如果有匹配电路,则可以断开串联的元器件。 有源测试:顾名思义,将机器装成可实现正常通讯功能的整机测试(需要电源开机)。 无源测试:是指不需要电源开机,就可以进行的测试。
一.系统测试 1.易用性,功能,分支,边界,性能等功能性和非功能性需要都要进行测试 2.介入需求一定要早 ,越早介入不仅可以减少成本,还避免了后续工作不必要的麻烦 3.测试用例尽量覆盖全面,最好做到用少的测试用例测试出多的 bug 4.你在测试中发现了一个bug,但是开发经理认为这不是一个bug,你应该怎样解决。 UI测试 一.自动化使用场景: 需求稳定,不会频繁变动的场景。 研发和维护周期长,需要频繁执行回归测试的场景。 需要在多个平台上重复运行相同测试的场景。 通过手工测试无法实现或成本太高的场景。 被测软件开发较为规范,并且能够保证系统可测试性的场景。 测试人员已经具备编程能力的场景。
什么时候进行性能测试? 在功能测试完成,所有的功能都比较稳定的时候,才可以做功能测试,一般在测试的中后期执行 性能测试术语 1.并发数: 广义并发数:同一时刻向服务器发送Http请求的用户数量;(有可能不是同一个功能) 在线用户数 性能测试类型 1.负载测试: (运行15min左右) 并发测试:在一定的软硬件环境下,系统的其他指标不变,测试系统在不同用户量访问级别下,系统性能的表现 容量测试:在一定的软硬件环境下,系统的其他指标不变 ,测试系统数据库数据量在不同的级别下,系统性能的表现 2.压力测试: 高于系统的最高负载,去运行系统,查看系统的表现 3.可靠性测试(疲劳测试): 低于系统的最高负载,去运行系统,查看系统的表现 4.配置测试 ,比较每次测试结果,从而确定各个因素对系统性能的影响。
话接上回(测试基础10问-上),继续问答之旅,答案是什么并不重要,重要的是引发一些思考。学问学问,边学边问。 06 测试是否需要过早的参与产品需求讨论? 很多测试人员会以挖掘出一个经过N个步骤(N大于10之类的),才会出现的缺陷为荣。个人并不是很认可这种观点。从用户的操作行为来看,可能永远无法发现这类问题。 10 测试有没有钱途 这个问题本来想放在第一问的,毕竟是大家最关注的问题。但个人觉的这也不是个问题。 测试的天花板也没有你们想的那么低。没事多看看招聘信息,多和行业高手互动。测试还是大有可为的。 10问聊完,大家对测试是否有新的认知呢? 在整理这10问题的时候,自己也做了更多的思考,测试这份职业还是比较好玩的。个人从事测试10多年,还是热爱这个行业的。测试相关的问题,欢迎沟通交流。 END 标星、点赞、关注三连走起,感谢支持。
本文总结之前文章中学习 Linux 和 Git 的常用命令,权当做一份备忘录。 Linux 导航相关 cd [directory]:在当前目录切换到指定目录。 ls:显示当前目录下的文件和目录列表。