软件测试大致分为功能测试和非功能测试。 让我们详细讨论这些测试类型,以及功能测试和非功能测试之间的确切差异。 什么是功能测试? 功能测试是测试被测软件或应用程序的“功能”。 非功能测试的类型 下面给出了各种类型的非功能测试。 性能测试: 1)负载测试:预期应处理特定工作负载的应用程序会在描述特定工作负载的真实环境中测试其响应时间。 功能测试与非功能测试之间的区别 功能测试 非功能测试 它测试产品的功能。它检查应用程序的操作和动作。 它检查应用程序的行为。 功能测试是根据业务需求进行的。 它根据客户要求进行测试。 它根据客户的期望进行测试。 客户反馈有助于降低产品的风险因素。 客户反馈对于非功能性测试更有价值,因为它有助于改善功能,并使测试人员了解客户的期望。 它正在测试软件的功能。 它正在测试软件功能的性能。 功能测试具有以下类型: 单元测试 集成测试 系统测试 验收测试 非功能测试包括:性能测试 负载测试 压力测试 容量测试 安全测试 安装测试 恢复测试
这表明功能测试和非功能测试对于交付用户友好型应用程序的重要性。因此,让我们了解什么是功能测试。 什么是功能测试? 进行功能测试以确保应用程序的功能符合需求规范。 非功能测试旨在通过各种标准(例如负载测试,可伸缩性测试,压力测试等)评估应用程序的就绪状态。它评估应用程序在挑战性条件下的性能。 非功能测试类型 让我们看一下针对移动应用程序的5种主要的非功能测试。 该应用程序经过测试过程,以检查是否根据目标区域设计了默认语言,日期和时间格式,货币等。 功能测试与非功能测试之间的区别 功能测试 非功能测试 这样做是为了验证应用程序的动作和操作。 它在非功能测试之前执行。 在功能测试后执行。 定义功能需求很容易。 很难定义非功能测试的要求。 例如:检查登录功能。 例如:页面应在1秒钟内加载。 可以使用良好的策略和工具在应用程序上执行功能测试和非功能测试来避免这种情况。
本章将讨论非功能需求的测试方法,这主要是关于容量(capacity)、吞吐量(throughput)和性能(performance)的测试。 非功能需求的管理 把非功能需求与功能需求区别对待,就很容易把它从项目计划中移除,或者不给予它们足够的分析。然而,这可能就是一个灾难,因为非功能需求常常是项目风险的来源之一。 总而言之,在项目一开始,交付过程中的每个人(包括开发人员、运维人员、测试人员和客户)都需要思考一下应用程序的非功能需求,以及它们对系统架构、项目时间表、测试策略和总成本的影响。 小结 如何设计出满足非功能需求的系统是一个很复杂的问题。很多非功能需求的横切本质(crosscutting nature)意味着,很难管理它们给项目中带来的风险。 我们必须和客户及用户紧密合作,共同确定应用程序中的敏感问题,并根据真实的业务价值定义详细的非功能需求。
有多少功能是真正值得去完成、真正被用户所需要的? 功能不该有优先级吗? 我们的功能在开发和测试的眼中,大多是一视同仁的,开发要保证每一个功能的准确性,和一定程度上的可用性;测试要保证覆盖到所有的功能点。 比如说,在迅雷上可以看到免费的电影,在优酷上可以看到最新的视频新闻,在人人网上可以建设自己的主页,和朋友交流…… 那么这些功能,就是相应这些产品最有存在价值的地方,这些功能,无论从质量还是进度上,应当被优先保证 我是测试,为了提高模块质量,那么我要仔细过测试用例,我要认真检查接口调用、业务逻辑是否正确,给每个提出的问题单写全面、写规范。 非功能性测试有多重要? 所有的测试用例,都是面对功能性测试而言的,对于自动化测试更是如此,对于非功能性测试,覆盖率只有零。
吃软件测试这碗饭的,如果基础理论都不懂,谈何长久? 欢迎来学习本系列,基础理论比较枯燥,这也是为什么现在很少人掌握的主要原因。 Part1前言 我们之前讲了非功能性的功能特性。本节课我们继续学习另一个大特性:可靠性。 Part2可靠性 可靠性共有:成熟性,容错性,易恢复性和依从性。 所以,衡量这个的质量标准就叫做【易恢复性】 易恢复性的定义:系统失效后,重新恢复原有的功能和性能的能力。 4可靠性的依从性 如上图,依从性简单来说就是要符合行业规则,业界规律,国家法律。
共有:•适合性•准确性•互操作性•保密安全性•依从性
温馨提示:本教程仅在Emlog5.3.1版本下测试正常,其他版本未做测试,不确保能用的哦!!!
F代表“功能性”, NF代表“非功能性”, X代表“不应当是需求” 解释 非功能性需求是指依一些条件判断系统运作情形或其特性,而不是针对系统特定行为的需求。 非功能性需求的分类方法较多,并没有业界通行和一致的标准,但是大多数殊途同归,名称/叫法以及分类方法上可能略有差异,但是其含义和指向一般是趋向一致的,我简单介绍一下我一般较多采用的分类: 性能/容量:性能和容量比较利于理解 这里小小纠正一下@子柳 的一个观点,百万级的数据支撑,还是有一些商业数据库产品可以支持的,TPC-C/TPC-D以及新一代的业界性能测试标准中还有千万级数据规模的测试项目,也有数据库厂商报名参加的,当然 事实上,从我的经验来看,一般来说,很多软件项目及产品,其在非功能性需求上的成本,难度和工作量,是要超过功能性需求的。 在特定的软件领域,例如网站(尤其是淘宝,facebook这样海量用户规模的网站),金融(银行证券),电信领域,其非功能性需求实现的重要性,工作量,技术难度要远远远远大于功能性需求的实现。
不过废话不多说,最近被分配了一项比较有意思的task,尝试着非root用户搭建MHA并测试下能否成功漂移,以下是两天测试和文档编写的成果,分享给各位看客,欢迎交流学习。 MHA的各项功能。 测试的环境: 1、两台CentOS服务器,iptables关闭,配置为8核8G内存,系统CentOS release 6.8 (Final)。 测试的步骤: 1、配置MHA复制集(master-slave-manager),GTID+Semi-Sync+并行复制 2、安装MHA及基本环境配置 3、MHA健康检查 4、MHA切换测试 relay_log_info_repository=table //将日志存储为表形式,更加安全,防止日志信息破损 2.2、Semi-Sync配置 1、在MHA的master上安装半同步插件并开启半同步功能
对于一个软件来说,功能如何并不难完全代表质量好坏,没有bug的软件不一定是一个好软件。 •比如很多大型同类产品。他们的功能都差不多,且几乎都没什么bug。 今天就来说说软件质量角度的:功非接
测试用例的编写需要按照一定的思路进行,而不是想到哪写到哪,一般测试机制成熟的公司都会有公司自己自定义的测试用例模板,以及一整套的测试流程关注点,当然我们自己在测试生涯中也应当积累一套自己的测试框架,所有功能性的测试都可以依据框架的思路来进行 功能测试框架可以包括:界面友好性测试、功能测试、链接测试、容错测试、稳定性测试、常规性能测试、配置测试、算法测试等等。 1.1.1 界面友好性测试 1. 风格、样式、颜色是否协调 2. 合法性检查:(输入0日、1日、32日)、月输入[1、3、5、7、8、10、12]、日输入[31]、月输入[4、6、9、11]、日输入[30][31]、输入非闰年,月输入[2],日期输入[28、29]、输入闰年 1.1.3 业务流程测试(主要功能测试) 业务流程,一般会涉及到多个模块的数据,所以在对业务流程测试时,首先要保证单个模块功能的正确性,其次就要对各个模块间传递的数据进行测试,这往往是容易出现问题的地方 如某一功能模块具有最基本的增删改查功能,则需要进行以下测试: 1. 单项功能测试(增加、修改、查询、删除) 2. 增加——>增加——>增加(连续增加测试) 3. 增加——>删除 4.
我有个问题,第一版里面您说需求分为功能需求,非功能需求,设计约束,第二版把非功能需求改成质量需求,我也看过您写的CTO糊涂术语文章,您认为非功能需求属于什么术语呢? UMLChina潘加宇 我现在的观点是,“非功能需求”属于模糊术语,不过这个模糊是表达上的模糊,来源于历史习惯,继续使用的害处比“功能模块”、“用户需求”之类的术语要小。 模糊之处在于,针对“需求”集合,“功能需求”是一个子集,“非功能需求”的字面意思就是“功能需求”的补集,所以这两个相加就是全集了,“需求分为功能需求,非功能需求,设计约束”的表述是不严谨的。 但是,类似于功能需求+非功能需求+设计约束的表述方式由来已久,我自己应该是从2002年开始使用这样的表述。当然,我肯定也是从教材上看的,具体哪一本教材现在不记得了。 (2)设计约束是非功能需求的一种。这个可以,但是习惯上说到“非功能需求”,想到的是速度、可靠性等等,这也是出现模糊表达的原因。 (3)把“非功能需求”改名。
软件研发分为可行性分析,需求分析,概要设计,详细设计,编码,测试,发布,交付,维护,下线等节点。 大厂牛逼架构师:问题2:系统概要设计阶段的非功能需求有哪几种? 小李:软件除了实现客户的基本功能需求之外,还要满足预设的非功能性需求,好比冰山下的庞大底座,看不见的东西往往最耗费和考验软件工程师的功力,对架构能力,编码能力要求比较高。 小李:高性能是软件系统的核心非功能需求,性能调优是软件架构师的核心职责,一般由高并发引起性能问题。要进行系统的性能优化,必须先进行性能测试。 软件系统的性能指标如下。 1,不愧是多年的一线开发人员,软件研发流程非常熟悉,而且敏捷研发模式有一定经验; 2,高性能是非常重要的非功能需求,调优方式7中都答的很到位; 3,安全性也是非常重要的,数据加密分类清晰,http的攻击防护手段有所了解
职位描述: 1.APP、Web测试及功能测试相关经验; 2.参与设计讨论,结合需求文档进行测试用例的设计; 3.能够独立安排测试计划,执行测试用例,提交测试分析、报告、跟踪BUG,并协助开发人员重视、修正 BUG; 4.能够控制软件开发的关键节点输入输出; 任职要求: 1.熟悉软件开发流程,最好懂敏捷流程 2.两年以上手机APP测试。 有WEB系统测试相关经验优先,懂Linux; 3.对BUG跟踪管控有一定的方法,会使用postman,jmeter优先; 4.能够独立设计相关测试用例、熟悉测试流程; 5.热爱软件测试工作、工作认真负责 ,能够不断的改进和促进测试规范高效的方向发展; 6.我们希望你是一个对自己有要求的人,我们希望你是高手,最好能够掌控节奏,给你平台让你发挥,公司会支持你所有好的方案及想法,并服务于你让它实施。
compression功能测试 1.启动compression 功能描述: 1.目前从k版本开始支持compression,目前支持zlib、snappy、zstd,注意从ceph version 12.0.0 5.compression特性对用户透明,用户是无法感知压缩功能是否存在的。 new.buckets.extra", "index_type": 0, "compression": "zlib" #插件类型 } } ] 3.压缩效果对比 测试使用一个 snappy zstd zlib 容量大小 258998272 248091783 245851907 246105300 4.总结 不考虑性能和时间的情况下,zstd效果最佳,由于每个插件还有一些压缩测试可以微调 ,所以测试的结果仅供参考。
吃软件测试这碗饭的,如果基础理论都不懂,谈何长久? 欢迎来学习本系列,基础理论比较枯燥,这也是为什么现在很少人掌握的主要原因。
随着IT技术日新月异,各种应用程序、APP层出不穷,软件测试这个行业也在不断发展壮大,这就要求我们不再满足简单的点点点的功能测试,而转向更深层次的测试之路的探索。 下面由我来絮叨一下关于不同类别的测试面试的内容及要点,抛砖引玉一下。 功能测试面试说 功能测试也称黑盒测试,即把测试对象当成一个黑盒子,不需要关注该软件的内部结构及处理过程。 拿手机号为例,有效等价类包括有效移动手机号、电信手机号、联通手机号等,无效等价类包括非手机号段的11位数字、含特殊字符、不足11位数字等。 以上介绍了关于功能测试设计测试用例的概念,接下来再说一下具体的测试面试题目 问1:你在测试中发现了一个bug,但是开发经理认为这不是一个bug,你应该怎样解决? 答:测试用例设计的话,首先是正常的使用,就是点击页面中的按钮、输入正 常的查询等等; 其次,反向用例设计,即非正常的测试用例,比如过长的字符、非法字符等等, 最后,功能测试一般采用就是黑盒测试的方法
上节课我们学习到了功能性测试的输入处理和输出三大概念包括其子概念:可见/不可见。 然后有人就问了: 答: Part2非功能 非功能,字面理解,就是测试软件产品的功能性之外的一些特性。 非功能测试,应该是我们测试工程师作为最终解释人,我们要站在用户角度,勇敢的对产品经理反击! 注意,这个内容非常多,我只能分期给大家讲完,请耐心听。原本的内容非常枯涩无味,而且难以理解。 那么首先要登场的,就是让同学糊涂的 非功能性 的六大特性 中的第一个:【功能性】 Part3非功能的第一个大特性:功能性 1功能性 让我先来举个小例子: 这个小例子中:用户抱怨自己的音乐APP为什么总推送毫不相干的文章新闻 俩个人完全是牛头不对马嘴,按照我们之前讲的【功能测试】这个大概念来说,这个推送功能没有任何bug,但是却犯了一个致命的问题,那就是这个功能压根就不适合用户,更加不适合这个音乐app。 所以,这件事就可以归纳于,非功能测试中的功能性的范围。 【非功能测试的功能性】一共分为:适合性,准确性,互操作性,保密安全性,依从性 。五个子特性。这个小例子明显违反了第一条子特性,就是适合性。
移动端的功能测试通常由用户交互的测试及测试事务构成。 影响功能测试的因素有: 基本功能及业务流(银行?游戏?保险?等等) 目标用户群体(个人用户?企业用户? 通常情况下,下述的功能测试场景应该要执行: 验证所有的必填字段是否按要求实现 验证所有必填字段是否有明显的标识 验证应用是否在每次启动/停止时,按照需求进行的 验证在有电话打进来时,应用能否进入最小化模式
引言 软件学习之路:功能测试,自动化测试,性能测试。 近些年来,随着互联网的高速发展,互联网上的教程多到你看都看不完的,自学成了一个人最根本的能力。 众测平台 众测平台是近几年互联网高速发展的产物,特别针对一些规模比较小,雇佣的测试人员少的公司,通过众测平台派送测试任务给大量的测试人员,一来可以降低测试周期和成本,二来可以提高测试质量。 最后 通过以上的方式,希望你步入软件测试行业,从最开始的功能测试做起。 或许做了一两年的你觉得做功能测试很简单,只是点点鼠标,提个Bug而已,确实尤其对于做了几年的功能测试的人来说可能觉得枯燥,乏味,没有什么技术成长,其实不然,曾经在工作遇到了好几位优秀的功能测试同事,他们共同的特点就是敬业 所以随着年龄越来越大,积攒测试经验,加强对业务的了解,保持敬业精神,另外学习更多的软件测试技术,比如自动化测试,性能测试,安全测试等等,才会在职业道路上保持竞争力。