1初识虫剂悖论 提到虫剂悖论(pesticideparadox),我相信很多人都没听说的,除非是生物学专业的同学或者老师。 虫剂悖论描述的是重复使用某种农药杀灭害虫,时间越久,杀虫的效果就越差。 之所以这样,是因为出现抗药性,也就是说害虫发生了进化,对这种杀虫药免疫了。 为了保证农药的杀虫效果,我们必须不断的研究新农药。 这个理论,运用到软件测试中: bug类似于害虫,用例类似于农药,重复使用固定的一批测试用例,能发现的bug就越来越少,遗漏的bug就会越来越多。 也就是说,测试的有效性会随着时间不断衰减。 之所以存在这种现象,是因为软件在不断进化,新的b...
冒烟测试的介入时间? 开发编码完成,自测通过以后为最佳介入时间。 如果开发无自测直接提交,一般冒烟测试通过率会很低【除非你遇到的是大内高手】 什么需求需要做冒烟测试? 理论上,所有的需求均可以做冒烟测试。 冒烟测试需要做几轮? 一轮冒烟测试结束后,二轮冒烟对问题验证。 所以,二轮是比较普遍的,当然会也有可能更多轮。 冒烟测试要写用例吗? 答案是肯定。 任何不写用例的测试,都是“耍流氓”。 测试用例是测试工作的指导,是软件测试必须遵守的准则,更是软件测试质量稳定的根本保障。 冒烟测试用例怎么写? 和其他用例一样,重点放在正向流...
软件一旦作了修改就必须进行项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中,并对其进行维护和管理。当得到一个软件的基线版本时,用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候,就可以根据所选择的回归测试策略,从基线测试用例库中提取合适的测试用例组成回归测试包,通过运行回归测试包来实现回归测试。 保存在基线测试用例库中的测试用例可能是自动测试脚本,也有可能是测试用例的手工实现过程。回归测试需要时间、经费和人力来计划、实施和管理。在给定的预算和进度下,需要对测试用例库进行维护并依据一定的策略选择相应的回归测试包。 1、首先必须有个管...
1、请问一般情况的安全测试都是从哪几个方面展开的? 安全测试主要针对以下漏洞类型进行测试,顺便罗列一些常用的测试工具、80%都是我们在用的。 (1)弱口令Nessus\X-scan\h-scan\hydra (2)ACL访问控制列表暴露在外网的IP和端口、低版本应用、nmap扫描+Masscsn (3)系统及应用服务器扫描Nessus\openVas (4)web漏洞扫描AWVS(AcuneticwebVulnerabilityScanner)\Appscan\salmap\w3af\arachni\zedAttackProxy 2、测试小白该从哪几个方面去深入学习...
性能测试种类的划分与定义这里就不说了,各有各的说法,比如性能测试、负载测试、压力测试这三个词,在网上能找到N个版本的定义,大体理解就行了,没必要在文字层面上较这个真。以下的内容也只是我个人的理解,一些名词的定义可能和其他资料有所不同,但在我的工作中,这样是比较形象和容易理解的。 在实际工作,一般的应用系统会从这么几个方面进行性能测试。 1.基准测试 Benchmark或者Baseline测试。一般为单用户测试,或者是零数据量环境下的测试。目的在于建立一个可度量的参考标准,为其他测试场景或者调优过程提供对比参考。也可以认为是最基础的性能测试,如果基准测试的结果都不能达到预期要求,...
基础能力 上面提到了,测试开发的本质还是做测试交付相关的工作。 基本的如需求分析、设计测试场景、编写测试case、发现和验证bug、沟通协调以及测试流程管理、质量把控等。 技术能力 测试开发需要借助已有的成熟工具或者框架,搭建内部的各种测试过程平台或者框架。 因此除了coding能力,还需要负责对业内广泛使用或者成熟度较高的工具框架进行引入落地,来解决日常测试过程中的种种问题,提高测试过程效率,保障线上的交付质量。常见的有工具框架有: 单元测试框架如Junit; 单元测试覆盖率如jacoco; 自动化测试框架或工具,如apifox、pytest; 内部的...
一、能力验证 能力验证是性能测试中最简单也是最常见的一个应用领域。一个典型的能力验证的问题会采取这样的描述方式:某系统能否在A条件下具有B能力? 能力验证领域的特点与性能测试的特点非常接近: ①要求在已确定的环境下运行 只有在一个确定的环境下运行,软件性能的验证才是有意义的;因为无法或很难根据系统在一个环境中的表现去推断其在另一个不同环境中的表现,因此这种应用领域内的测试 必须要求测试环境(如硬件设备、软件环境、网络条件、基础数据等)已确定。 ②根据典型业务场景设计测试方案和用例 能力验证需要了解被测系统的典型业务场景,并根据典型场景设计测试方案和用例;一个典型...
一、首先,我们要了解清楚用人部门对初级测试人员的定位: 1.具备软件测试思维 一开始就测试思维,针对还没入门的新人来说有点难。 测试思维需要测试人员对软件测试有了比较清楚的认识;和对软件测试流程有了全局感;能够从各个方面对被测试对象进行测试时,这时再来看测试思维就简单了。 2.写测试用例 初级测试人员首先要具备做事的能力,在软件测试过程中测试人员做得最多的就是写文档,其中又以分析需求写测试用例为最多。 3.执行测试,记录缺陷 在软件测试过程中测试人员做得最多的另外一件事就是执行测试,更有公司初级测试人员只需要照着用例执行测试就行。执行测试过程中一定会产生缺陷,需...
一提到线上问题,很多测试小白要么”原则性“恐惧,要么憨憨如也,不知如何下手。 本篇文章,我再细化下这道常见的面试题,跟大家捋捋发生在线上问题,作为测试人,该有的思路。 首先,直接给出万金油三步公式: 第一步,初步排查,快速恢复业务; 第二步,查找问题的根本原因,彻底解决; 第三步,团队分享,避免出现类似问题。 这三步中的措辞,十分重要。特别是第一点——初步排查,快速恢复业务。 出现问题,不要一来就盲目定位,本着找不到根本原因不罢休的思想去处理突发问题,是不可取的。 线上有问题,最重要的是快速恢复业务。 你可以先检查CPU、内存、网络IO、磁盘IO等,看看...
1)你最近3-5年的职业规划是什么? 重点考察测试人员的职业发展方向是否与当前职位招聘相符?从其中可以侧面看出来其员工的稳定性。 2)一个项目测试结束,有没什么经验总结?如果有,具体是如何开展的? 重点考察测试人员对自己能力提升方面,有没有提高总结的地方,从项目中吸取的经验与教训。从中可以看出来,测试人员是否属于自我驱动型人才! 3)为什么会选择做测试这份工作? 重点考察测试人员对待测试工作的态度及是否有发展潜力?面试过很多测试人员,经常见到的回答,自己是女孩子,做测试细心,各位你认为这样回答你会满意吗?其码不是我想要的答案! 4)请说出一个你以前参与的项目,对你测...
如何确定一个软件的测试结束点 这个问题在每一本测试书上都有提到,光拿出来列也没多大意思,就归纳一下吧: 1、组织级的强制退出: 项目中止,通常是项目出现了严重的问题或人力不可抗拒因素 经费用尽,通常是项目经费没有得到很好的控制,弹尽粮绝,这种情况现在比较少见 超过期限,这是最常见的,特别是在传统的瀑布模式下,开发一再延期,导致测试时间不足,只好强行中止,听天由命了 添加图片注释,不超过140字(可选) 2、达到了功能质量指标。要把所有的质量指标罗列起来太困难了,摆几种常见的退出指标: 测试用例覆盖度 测试用例的执行率 测试平台的覆盖率,...
软件测试用例得出软件测试用例的内容,其次,按照软件测试写作方法,落实到文档中,两者是形式和内容的关系,好的测试用例不仅方便自己和别人查看,而且能帮助设计的时候考虑的更周。 一个好的测试用例必须包含足够的内容,将这些内容可以拆分为八个要素:用例编号、测试项目、测试标题、重要级别、预置条件、测试输入、操作步骤、预期输出。 1、用例编号 1)规则:是由字符和数字组成的字符串,具有唯一性、易识别性。 2)不同阶段的测试用例的用例编号 --系统测试用例:产品编号_ST_系统测试项名_系统测试子项名_XXX(具体用例序号) --集成测试用例:产品编号_IT_集成测试项名_集成测...
接口测试是一种测试类型,又是一种测试方法,它是很多个领域测试工作的一部分,同时它又可以通过不同方式来执行; 功能测试 功能测试即我们常说的黑盒测试,传统意义上的黑盒测试即验证开发出来的产品是否满足产品提出的产品需求说明书,而接口实际上也是产品需求的一部分; 例如: 产品需求:客户端输入一个词,点击按钮,即按时间倒叙展示这个词相关的新闻; 功能实现:客户端将用户输入的词拼成http请求,发往服务端接口,接口查找了这个词有关的新闻,并且按时间倒叙拼接成json,回复给客户端,客户端按顺序展示。 这个例子里,中心需求≈接口功能 安全测试 经常听说的安全测试很大程度...
关于评价自动化测试的优劣,除了常见指标外,还有一些不太容易拿数据说话的指标,这里叫做隐性指标。 隐性指标主要包括:自动化的维护成本、自动化的运行成本 1、自动化的维护成本 针对同一个业务,不同的自动化测试实现方案,对应的维护成本可能天壤之别。诚然,自动化的维护成本,受业务成熟度、迭代速度、项目规范程度影响,但不妨考虑以下情况下,你的维护成本如何: 新增了一些逻辑(如,接口/服务/应用),对新增部分维护自动化,你需要多长时间; 删除了一些逻辑(如,接口/服务/应用),对删除部分维护自动化,你需要多长时间; 修改了一些逻辑(如,接口/服务/应用),对修改部分维护自动化,...
接口测试的作用 接口测试的英文是interfacetesting,接口测试测试系统组件间接口的一种测试。接口测试的好处:由于接口测试代码本身就是用junit(当然接口的类型不同,不一定是Junit来实现)来实现的,是属于自动化测试的范畴,因此必定也包含自动化测试所固有的优势。 1)提高测试质量 软件开发的过程是一个持续集成和改进的过程,而每一次的改进都可能引进新bug,因此当软件的一部,或者全部修改时,都需要对软件产品重新进行测试。其目的是要验证修改后的产品是符合需求的,而当没有自动化测试代码时,往往会由于各种各样的原因,回归不充分,导致bug遗漏。 2)提高测试效率 ...
App,做为当下最热的手机安装软件,无论是产品本身的设计还是性能,易用性等都是非常受考验。一个app能在用户的手机上使用,并作为一个长期用户是非常不容易的。那么,App的测试中我们到底要测试什么呢? 1.功能 首先设计的功能必须是100%的测试,而且是最基本的测试。 2.安装卸载 App可以正常安装启动,各大应用市场下载安装,升级安装,跨版本升级安装,手机存储满时安装。安装时的权限也是很重要的。 App的卸载应该很容易,直接系统自带卸载。 3.流畅度 App的流畅度最能考验一款软件的易用性。如果一个软件打开就卡,随便滑动几下页面就卡死,谁还会用第二次呢? 4...
更高效的发现bug,考验测试设计的能力。 这方面有非常多的方法和技巧,以及经验,这里不细说。 发现bug之后如何清晰的描述,定级,以及跟进和验证。 这个看似简单,但是你会发现很多测试工作做了几年的人这样的基本功还是不够扎实。也可能没有受到过很好的训练或者一直没有人指导。 对业务和架构的理解能力。 没有这方面的能力,很难发现一些深层次的bug。而这样的能力对于快速学习和一些技术基础也有不低的要求。 发现bug之后如果举一反三的尽早发现更多类似的bug。 大家看到的很多经典的测试书籍讲的基本都是这个阶段做的事情,比如SoftwareTesting,HowWe...
什么是测试覆盖率? 测试覆盖率衡量您测试了多少应用程序。这不仅与您执行的测试数量有关。它还与您查看的真实设备、浏览器和操作系统版本有关!您测试的设备和操作系统组合越多,测试覆盖的代码越多,测试覆盖率就越高。 请注意,实现100%的测试覆盖率是不现实的。一般来说,达到70%对你来说可能就足够了。此外,实现更高的测试覆盖率可能需要更多时间并延迟您的应用程序启动。要确定正确的数字,您必须评估您的需求并分析与较低测试覆盖率相关的风险。经过仔细评估,您可以更安全地确定发布稳定可靠的应用程序需要多少测试覆盖率。 如果您知道您的应用程序的测试覆盖率,您还可以在您未测试的代码中找到被忽略的部分...
在考虑这个问题之前,你得知道学习软件测试应该掌握哪些技能,看看自己能不能一个人搞定,能的话就自学,不能的话就要考虑报班,还有效率的问题。 硬技能方面: 第一、计算机知识,包括操作系统,如windows,Linux等系统常用操作和常用软件的使用;以及比如数据库的操作和SQL语句等; 第二、网络知识,比如OSI七层网络模型,和一些常用的协议原理,如TCP、UDP、HTTP,HTTPS,FTP,SSH等; 第三、软件测试知识,包括测试理论和流程,常用的测试用例设计方法,测试用例编写,缺陷跟踪流程,软件质量评估,测试计划和测试报告的编写等; 第四、熟悉至少一门编程语言,比如主流...
它会是趋势,但它很难每个公司都能独立完成一个测试平台 前面有说过,完成测试平台所需要的能力五花八门,所以当你会这么多技能的时候,你可能就想要很高的薪资,但从国内对测试的态度来看,它的工资肯定会比开发低一层(大厂无视),这就变成一个恶性循环,公司想要低成本劳动力干测开的活,你作为测开想要拿到更高的薪资 所以网上有很多开源的测试平台,一般没能力开发平台的公司就会私有化部署,然后再定制化二次开发,这也是一种趋势,应该不存在销售测试平台的情况,毕竟开源的都挺好看挺好用的 测试平台很难做到适配所有项目,包括在阿里其实测试平台特别多,自动化、性能、兼容、云真机,但我所在的部门一个都没用上,...