网站建设行业企业发展前景,wordpress看访问量,iis7 伪静态 wordpress,重庆网站seo营销模板俗话说外行看热闹#xff0c;内行看门道。
写这篇文章#xff0c;是希望把我的一些我认为是非常有价值的经验总结出来#xff0c;能够帮助刚做测试不久的新同学#xff0c;或者是测试经验丰富的老同学以共享。
希望我们可爱的新同学#xff0c;准备要在测试领域耕耘的伙…俗话说外行看热闹内行看门道。
写这篇文章是希望把我的一些我认为是非常有价值的经验总结出来能够帮助刚做测试不久的新同学或者是测试经验丰富的老同学以共享。
希望我们可爱的新同学准备要在测试领域耕耘的伙伴能够通过我的文章了解到测试的底层逻辑也就是我们测试工作中可能看不到隐藏较深的点而不只是日常所见的写用例、提bug、开发自动化、做平台 我认为测试人员不应该成为PRD的搬运工高级测试工程师也不应该只是测试工具得开发者 测试人员最基本的测试基础理论一定要掌握当然研发编码技术也必不可少如果这两样缺少一样都无法成为一个优秀的测试人员之前有很多测试人员都是不喜欢写代码然后做了测试但在未来或者现在一个不懂代码的测试人员很难成为一个优秀的测试人员但只懂代码不了解测试理论基础的人不懂得测试分析、用例设计、测试策略的人或者即使了解一些 但实际工作中不怎么使用的人一定也不是一个合格的测试人员。 下面带大家了解一些测试的底层逻辑测试的门道。 根据Testerhome《2022年度测试行业问卷调查报告》-【优秀测试人员应具备的技术/能力】分析 1、“编程/脚本/自动化、沟通表达、测试基础理论” 被认为是优秀测试人员的三大核心能力继续领先其他项 2、数据库、性能测试、安全测试、大数据算法等技术要求从2020年开始大幅增长 三大核心能力基本是大家公认的也是稳定不变的但新的技术要求近几年开始都有了大量需求从分析数据可以看到市场对测试人员的要求会随着新技术的出现而不断变化但三大核心能力是测试人员的必修课变化不会太大会一直占据核心位置。 自从10几年前的QTP开始自动化测试就是测试人员追求的目标直至今日各种自动化技术、框架已经琳琅满目市场对测试人员的要求也越来越高测试人员不仅要会写自动化用例还需要具备开发维护自动化框架平台的能力纯黑盒的测试人员要么已经完成了能力升级要么在升级的路上完全依赖黑盒测试完成工作的已经越来越少如果不会编写自动化用例或不了解编程语言估计找工作简历都很难通过。 但往往物极必反测试人员的代码能力越来越强测试基础能力却被忽视测试领域的专业能力逐步被淡化正如逆水行舟不进则退三大核心能力应该是齐头并进不应该顾此失彼。 这些年参与了部门很多的招聘面试我的感受就是很多测试人员虽然工作多年但对测试用例的设计方法、策略等掌握并不好至少有60%的人在用例设计中不会用什么用例设计方法也不会思考怎么进行测试分析和设计他们大部分只是功能测试的执行者测试设计方面思考很少测试计划更是很少有人写测试用例也只是PRD的拆分总之测试人员一不小心就会成为PRD的搬运工。 作为一个测试老人还是希望测试行业能够健康发展在新技能提升的情况下测试的专业性也能与时俱进毕竟质量保障是测试人员的根本。 什么是黑盒测试 它是把程序看作一个黑盒子在不考虑程序内部结构的情况下检查程序功能是否按照PRD的规定正常使用程序是否能适当地接收输入数据产生正确的输出。 这其实就是黑盒测试的定义也是黑盒测试的底层逻辑一般人不会重视定义但往往就是定义会告诉你真理。 工作中有很多人在习惯了一种类型的系统测试然后换一个新的业务类型忽然就不知如何下手了也许是新的总要有一个适应的时间其实万变不离其宗只要掌握了黑盒测试的底层逻辑就能够让你很快上手不再需要适应调整 我们大部分做的都是黑盒测试所以无论什么类型的系统我们的测试方案都是“ 检查程序功能是否按照PRD的规定正常使用程序是否能适当地接收输入数据产生正确的输出。” 。 我们的测试依据是PRD首先必须对PRD了如指掌然后分析他的输入有哪些输出有哪些这些都覆盖到了你基本就可以做到80分了也就是你拿下这个项目已不成问题。 最后我还是想再啰嗦强调一下 就怕我讲的大家还是没有看懂因为上面讲的大家都懂第一天了解测试就知道什么时候黑盒测试什么输入输出了但是往往真理就藏在平凡之间记住他的定义 当你遇到项目不知如何下手测试时把定义拿出来认真读三遍一定会找到答案 强调 实际当中纯黑盒的其实并不多除了了解输入、输出中间的处理逻辑也一定要清楚这样对测试更有帮助另外更重要的就是必须熟读PRD必须对PRD里的内容分析透彻不放过任何一段文字一个词。其实PRD里和设计文档里也会有很多的漏洞等你挖掘。 【输入输出测试模型】 【输入】 这里的输入并不是简单的界面输入框才算是输入任何只要能够触发系统运行的都是输入。 按照代码架构分层输入也可以做到如下分类 1、界面操作的输入
正向操作
1单一操作
•正常的操作输入框、按钮、单选复选框、按钮、下拉框等的规定操作异常的操作输入框的异常值、超长输入等、按钮的多次点击、快速连续点击很容易就会发现数据重复提交或者系统反应缓慢等各种问题说不定系统就此而崩溃
2复杂操作
•组合操作一般系统的功能都是各种操作的组合另外一种跟业务场景相关也就是各种业务场景同时组合进行操作。
•并行操作多人对同一功能点的并发操作或者多人对同一个数据进行的操作比如两个人同时对一条单价进行修改、删除等操作。
逆向操作
3逆向操作
•回退操作通过浏览器或APP进行的回退操作取消操作正常操作突然取消例如用户填写很多表格内容突然操作了取消是否需要保存或提示呢删除操作通过系统提供的功能对数据进行删除 下面的输入是最容易被忽略的
2、服务层的输入 •接口服务对外提供的接口对于系统来说也是很常见的一种输入这种输入也是最容易出问题的
•文件上传有些系统功能是通过获取ftp服务器上的excel、xml等文件来触发系统运行的所以这时候的输入就变成了文件。
•MQ消息也是京东最常见的一种输入形式MQ里也可能会包含文件地址等这种输入就更加灵活了。
强调
•对于接口上游的输入无论何种形式都要分析上游数据的每一个字段了解上游各种输入的可能。
•有些字段还必须从业务【源头】了解这个字段的含义可能的枚举值可能的结果等
•另外由于历史原因源头的数据就可能存在各种想象不到的数据
•对于输入的分析非常重要这时候你就可以使用【等价类】方法进行分析。 3、数据层的输入 •数据的变化有很多后台处理的任务就是监控是否有新数据的插入或删除等数据字段的变化后台处理任务监控数据状态的变化或组合字段的变化等缓存数据的变化除了数据库的变化有的是缓存数据的变化时间的变化定时任务除了数据是输入时间也是他的输入。 【输出】输出分为可见输出和不可见输出 看的见的输出 就是我们常见的系统操作反馈用户能直接看到的变化比如弹框、提示、跳转、数据的新增、修改、删除后的变化图片、视频等操作后的变化等等。 看不见的输出 看不见的输出是最容易忽略也是最容易出问题的【看不见的输出】包括数据库的变化、缓存的变化、系统文件的变化、发送给下游接口的数据等 【看的见的输出】虽然能够帮我们验证基本90%以上的功能通过界面展示的数据也能验证我们新增或修改的数据是否新增成功了或正确的被修改了但是我们看到的只是一部分还有很多字段是没有被展示的有的可能只是给下游或其他系统使用的也有可能是留给未来使用的这些不可见的部分经常就会引起系统的异常也是隐藏在系统中最大的坑 所以测试除了站在用户的角度去测试系统还要站在设计者的角度去测试更应该站在整个产品的角度去思考。 说到测试分析与设计我认为这个是测试人员最核心的能力 上面讲到的黑盒测试、输入输出模型只是针对功能测试的方法虽然一般的系统测试中功能测试占到80%-90%左右但并不是全部。而且也只是测试中的一个阶段一个类型要想做好测试测试分析和设计是必不可少的。 大家可以思考一个问题拿到一个项目你如何来测试如何保障质量 面试中很多人给我的答案是分析需求编写用例然后执行测试发报告这个只是测试的流程只是告诉了我们测试的先后顺序但并不能指导一个测试人员如何去测试如何去做测试分析更无法保障系统的质量。 拿到一个项目你如何来测试
可以借用5W2H方法来分析其实作为测试架构师不需要5W也不需要3W2W1H 就够了 因为这2W1H 是最重要的也是最容易被经验代替然后就忽略的日常的测试工作由于产品的形态及系统的架构基本固定所以测试方案思路也基本固定这样就导致拿到类似的项目就不再有思考基本很快就按照经验开始干了一旦遇到不同类型的系统或者遇到新的业务就不知如何下手这时候2W1H分析法就可以帮助我们解决这个问题。 测试架构师只需要思考三个问题2W1H 就够了 1、Why 为什么做这个项目项目的背景是什么——只有知道为什么才知道用户想要什么。
2、What 这个项目我们需要测什么我们的测试范围有哪些——只有范围明确测试才不会遗漏。
3、How? 这个项目我们怎么测我们应该使用哪些测试策略、测试方法——这里告诉我们测试应当有策略有方法
测试负责人也可能是测试架构师还需确定的两个问题
4、When? 项目期望的完成时间
5、Who? 可以调用的资源有哪些
项目经理需要考虑的另外两个问题测试负责人也需要思考的2个问题
6、Where是否需要集中封闭是否需要研发测试坐到一起
测试人员还可以思考需要在什么环境下测试测试环境预发环境线上环境windows环境Linux环境ios环境Android什么浏览器什么版本等等
7、How Much 这个项目成本是多少需要多少人日需要多少服务器资源 测试分析和设计的底层逻辑就是如何回答好2W1H这三个问题 Why和What可以指导我们进行测试分析了解项目的【背景】确认测试的【范围】 How可以指导我们去进行测试设计根据项目背景及测试范围确定测试的【策略】。 不过目前讲的还是方法论具体的操作步骤还没有讲由于这一部分内容比较多可以通过一篇文章具体来讲大家也可以自己去了解学习一下就是HTSM启发式测试策略模型这个模型正好与2W1H是相对应的。 作为测试人员“沟通表达等软技能”被认为是优秀测试人员的三大核心能力一 根据上面的统计数据90%以上的人都是认可的。下面把我之前的一些总结分享一下 1、主动沟通 在电商领域特点就是快速和变化有些需求或项目经常要求快速上线由于时间短PRD里有些逻辑就可能会存在漏洞或者根本没有考虑到面对这样的情况我们测试该怎么办呢这时就需要沟通与产品随时沟通需求与开发随时沟通设计与其他系统随时沟通联调没有沟通项目里的坑很容易就会被遗漏。沟通还必需得是主动出击找产品、找研发、找其他条线的测试把自己当成老板这个项目的质量基本就有保障了把自己当成老板的员工一定是最让老板放心的员工。 2、要有自己的标准 系统测试最基本的依据就是需求规格说明书作为测试人员我们是最后一道保障测试必须有自己的分析不能轻易就跟着研发的思路走因为他告诉你的已经是经过他们思考加工过的与原始需求可能已经存在了偏差这也正是测试的价值所在。即使他们说的99%都是对的但是也只能作为我们分析的一个材料我们必须自己通过需求去分析。 3、对一切都要有怀疑的态度 需求是测试的依据但是依据也有错的时候所以对PRD也要有怀疑的态度。测试就是要怀疑一切 每一个流程每一个细节我看需求的时候第一遍基本默认他是对的等对整体有了一定的理解我就开始怀疑流程是否完整? 是否存在漏洞? 模块功能是否能满足用户的要求? 非正常操作是否会出现问题? 用户是否会用这个功能是否真的为客户解决了问题等等这些问题可以通过我们的一些质量标准、测试策略以及测试经验去怀疑去思考。总之测试每一个功能都要“三思”。 4、站在公司和用户的角度思考 公司越大部门越多系统就会越复杂相互依赖越多出问题的几率也会越大因为边界多了沟通成本也就高了需要沟通的点多了只要有些细节没有沟通到位或者都没有考虑到或者都认为是对方负责那坑就出现了当然这样的坑大部分会在联调测试阶段发现但对于测试进度影响非常大经常会造成反工、延期等风险 要想这些坑能够在测试阶段发现这时候就需要有一个主测试了但我觉得主测试不应该是一个人所有测试人员都应该是“主测试” 作为测试人员软件质量的最后把关者不能只看到自己负责的这一块不能局限于自己的部门、团队只要对整个系统有疑问我们都有责任提出来去找人解决。 测试不能只看局部要看全局要站在公司的位置和用户的角度去思考去测试。
上面主要是总结了我得一些经验测试中的一些道有不足之处或不够全面的也希望大家多多补充
下面是一些测试自学资料希望可以帮到有需要的人评论区自取
