功能测试_功能测试用例 - CSDN
功能测试 订阅
功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。 展开全文
功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。
信息
外文名
functional test
应用学科
通信科技;运行、维护与管理
用    途
对产品的各功能进行验证
中文名
功能测试
功能测试功能测试
Functional testing(功能测试),也称为behavioral testing(行为测试),根据产品特性、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。功能测试是为了确保程序以期望的方式运行而按功能要求对软件进行的测试,通过对一个系统的所有的特性和功能都进行测试确保符合需求和规范。功能测试也叫黑盒测试或数据驱动测试,只需考虑需要测试的各个功能,不需要考虑整个软件的内部结构及代码.一般从软件产品的界面、架构出发,按照需求编写出来的测试用例,输入数据在预期结果和实际结果之间进行评测,进而提出更加使产品达到用户使用的要求。应用电子技术方面的测试:印刷电路板,又称印制电路板,印刷线路板,常使用英文缩写PCB(Printed circuit board),是重要的电子部件,是电子元件的支撑体,是电子元器件线路连接的提供者。由于它是采用电子印刷技术制作的,故被称为“印刷”电路板。在印制电路板出现之前,电子元件之间的互连都是依靠电线直接连接而组成完整的线路。电路面包板只是作为有效的实验工具而存在,而印刷电路板在电子工业中已经成了占据了绝对统治的地位。20世纪初,人们为了简化电子机器的制作,减少电子零件间的配线,降低制作成本等优点,于是开始钻研以印刷的方式取代配线的方法。三十年间,不断有工程师提出在绝缘的基板上加以金属导体作配线。而最成功的是1925年,美国的Charles Ducas 在绝缘的基板上印刷出线路图案,再以电镀的方式,成功建立导体作配线。[1]直至1936年,奥地利人保罗·爱斯勒(Paul Eisler)在英国发表了箔膜技术,他在一个收音机装置内采用了印刷电路板;而在日本,宫本喜之助以喷附配线法“メタリコン法吹着配线方法(特许119384号)”成功申请专利。而两者中Paul Eisler 的方法与现今的印刷电路板最为相似,这类做法称为减去法,是把不需要的金属除去;而Charles Ducas、宫本喜之助的做法是只加上所需的配线,称为加成法。虽然如此,但因为当时的电子零件发热量大,两者的基板也难以配合使用[1],以致未有正式的实用作,不过也使印刷电路技术更进一步。1941年,美国在滑石上漆上铜膏作配线,以制作近接信管。1943年,美国人将该技术大量使用于军用收音机内。1947年,环氧树脂开始用作制造基板。同时NBS开始研究以印刷电路技术形成线圈、电容器、电阻器等制造技术。1948年,美国正式认可这个发明用于商业用途。自20世纪50年代起,发热量较低的晶体管大量取代了真空管的地位,印刷电路版技术才开始被广泛采用。而当时以蚀刻箔膜技术为主流[1]。1950年,日本使用玻璃基板上以银漆作配线;和以酚醛树脂制的纸质酚醛基板(CCL)上以铜箔作配线。[1]1951年,聚酰亚胺的出现,便树脂的耐热性再进一步,也制造了聚亚酰胺基板。[1]1953年,Motorola开发出电镀贯穿孔法的双面板。这方法也应用到后期的多层电路板上。[1]印刷电路板广泛被使用10年后的60年代,其技术也日益成熟。而自从Motorola的双面板面世,多层印刷电路板开始出现,使配线与基板面积之比更为提高。1960年,V. Dahlgreen以印有电路的金属箔膜贴在热可塑性的塑胶中,造出软性印刷电路板。[1]1961年,美国的Hazeltine Corporation参考了电镀贯穿孔法,制作出多层板。[1]1967年,发表了增层法之一的“Plated-up technology”。[1][3]1969年,FD-R以聚酰亚胺制造了软性印刷电路板。[1]1979年,Pactel发表了增层法之一的“Pactel法”。[1]1984年,NTT开发了薄膜回路的“Copper Polyimide法”。[1]1988年,西门子公司开发了Microwiring Substrate的增层印刷电路板。[1]1990年,IBM开发了“表面增层线路”(Surface Laminar Circuit,SLC)的增层印刷电路板。[1]1995年,松下电器开发了ALⅣH的增层印刷电路板。[1]1996年,东芝开发了B2it的增层印刷电路板。[1]就在众多的增层印刷电路板方案被提出的1990年代末期,增层印刷电路板也正式大量地被实用化。为大型、高密度的印刷电路板装配(PCBA,printed circuit board assembly)发展一个稳健的测试策略是重要的,以保证与设计的符合与功能。除了这些复杂装配的建立与测试之外,单单投入在电子零件中的金钱可能是很高的 - 当一个单元到最后测试时可能达到25,000美元。由于这样的高成本,查找与修理装配的问题是重要的步骤。今天更复杂的装配大约18平方英寸,18层;在顶面和底面有2900多个元件;含有6000个电路节点;有超过20000个焊接点需要测试。在朗讯加速的制造工厂(N. Andover,MA),制造和测试艺术级的PCBA和完整的传送系统。超过5000节点数的装配对我们是一个关注,因为它们已经接近我们现有的在线测试(ICT,in circuit test)设备的资源极限(图一)。我们制造大约800种不同的PCBA或“节点”。在这800种节点中,大约20种在5000~6000个节点范围。可是,这个数迅速增长。新的开发项目要求更加复杂、要有更大的PCBA和更紧密的包装。这些要求挑战我们建造和测试这些单元的能力。更进一步,具有更小元件和更高节点数的更大电路板可能将会继续。例如,正在画电路板图的一个设计,有大约116000个节点、超过5100个元件和超过37800个要求测试或确认的焊接点。这个单元还有BGA在顶面与底面,BGA是紧接着的。使用传统的针床测试这个尺寸和复杂性的板,ICT一种方法是不可能的。在制造工艺,特别是在测试中,不断增加的PCBA复杂性和密度不是一个新的问题。意识到的增加ICT测试夹具内的测试针数量不是要走的方向,我们开始观察可代替的电路确认方法。看到每百万探针不接触的数量,我们发现在5000个节点时,许多发现的错误(少于31)可能是由于探针接触问题而不是实际制造的缺陷(表一)。因此,我们着手将测试针的数量减少,而不是上升。尽管如此,我们制造工艺的品质还是评估到整个PCBA。我们决定使用传统的ICT与X射线分层法相结合是一个可行的解决方案。
收起全文
精华内容
参与话题
  • 功能测试的一些心得总结

    千次阅读 多人点赞 2018-07-20 10:56:54
    功能测试是测试工程师的基础功,很多人功能测试还做不好,就想去做性能测试、自动化测试。很多人对功能测试的理解就是点点点,如何自己不用心去悟,去研究,那么你的职业生涯也就停留在点点点上了。在这里,我把我对...

    一、前言

    功能测试是测试工程师的基础功,很多人功能测试还做不好,就想去做性能测试、自动化测试。很多人对功能测试的理解就是点点点,如何自己不用心去悟,去研究,那么你的职业生涯也就停留在点点点上了。在这里,我把我对功能测试的理解写下来。

    二、功能测试所需要掌握的技能

    2.1  熟练使用SQL

    1、常用的 sql 语句一定会写。比如说增删改查之类。

    2、了解数据库的事务、会编写存储过程、熟练常用的系统函数。

    3、了解并可以进行数据库的备份、迁移、还原、镜像等操作

    4、对 sql 语句进行调优,并对可以对运行的语句监控查看性能

    5、了解数据库集群等操作。

    2.2 Linux

    Linux是测试人员的基础功,不需要掌握太难或者很不常见的Linux命令,正常能做到查看日志,定位问题就可以了。

    1、基本命令

    常用的Linux基本命令,面试经常会问的,或者给出一种场景,问你用什么命令。

    2、查看日志

    初级测试人员在工作时经常遇到,发现bug,开发不承认或者不愿意解决的情况,测试人员怎么摆脱这样的问题呢?

    那就是根据发现的bug根据日志级别,来查看日志,定位问题。

    那这里首先要说一下日志级别了。

    首先记住这一点:日志级别越高,输出的信息越少 。

    具体的日志级别分为四级:

    info : 代码 info 信息,不包括sql语句等一些debug信息

    warning warning : 代码警告信息

    error : 程序本身报错信息 java.lang.outindexERROR.....

    critical :几乎用不到

    一般不符合需求的bug在 debug中,程序本身报错的bug在 error中。

    2.3 使用数据库,跟数据流向

    关于数据库,请见另外一篇博文。

    1、数据库的本质

    常见数据库主要是MAYSQL、ORECAL、Redis

    其中Mysql数据库是典型的关系型数据库

    2、数据库操作

    (1) 数据库和表操作

    (2)表数据操作

    (3)复杂sql查询

    2.4 写好测试用例

    在测试过程中很重要的一类文档,它是测试工作的核心、是一组在测试时输入输出的标准、是软件需求的具体对照。编写测试用例,是测试人员的基本功,但是真正能写好的人并不多。

    测试用例必须包含的内容:

    用例编号、用例名称、测试背景、前置条件、优先级、重要级、测试数据、测试步骤、预期结果、实际结果、备注。

    1、测试用例的编写流程

    需求分析->提取测试点->测试用例编写->测试用例评审

    2、编写测试用例的思路

    (1)根据产品的RPD,提取测试点。

    (2)根据数据流的走向。

    (3)根据的架构部署。

    (4)编写测试用例的常用方法:等价类划分法、边界值分析法、流程图法等。

    (5)覆盖弱网测试、接口测试、安全测试、性能测试等。

    (6)常用测试工具有:Postman、 Charles、 Fiddler 、Jemter、Loadrunner等。

    3、编写测试用例注意事项

    (1)根据项目的实际情况设计测试用例表格

    (2)用例格式不要生搬硬套

    (3)根据具体情况编写

    (4)学会质疑需求,不要完全按照需求来写测试用例,要从客户和产品的角度来理解需求,看到需求之外的功能和体验

    4、管理测试用例

    为什么要管理测试用例?

    (1)测试用例数目巨大

    (2)测试用例会根据需求的改变而改变

    (3)测试用例需要长期补充完善

    如何管理测试用例?

    (1)原始的Excel管理

    (2)专业的项目管理系统(eg:git、禅道、JIRA、Confiuence等)一般都为web格式

    2.5 http与https协议

    面试经常关于Http协议的下面几个问题

    1、Http协议原理

    2、http和http协议的区别

    3、TCP和UDP的区别

    4、session和token的区别

    5、公钥和私钥的理解

    6、get和post的区别

    7、从输入URL到页面加载发生了什么

    8、什么叫代理,正向代理和反向代理?

    2.6 了解业务

    做功能测试,一定要了解业务,甚至理解业务。只有把业务吃透,才能把功能测试做好,并且有一定的提高。

    业务熟悉后,会知道很多常识,知道下面的常识之后,你就可以尝试进阶,学习做自动化测试、接口测试、性能测试

    1、什么时候介入自动化 => 当你系统趋于稳定的时候

    2、什么时候介入接口测试  => 当接口开发完毕的时候

    3、什么时候介入性能测试 => 当出现促销的时候,或者抢购的时候(618大促,过年抢火车票,抢优惠券)

    比如说,5000张优惠券,大概有多少人抢,在多长时间内抢完

    2.7 bug管理

    做功能测试,还有个很重要的工作就是bug管理,一个优秀的的测试人员,线上bug非常多,多于和你一起工作的其他同事,但是线上bug非常少,少于其他同事。

    1、 bug定义

    (1)不符合需求的

    (2)程序本身报错

    (3)不符合用户的使用习惯

    2、bug生命周期当我们测试人员提交一个bug的时候,自始bug就有它的生命周期,从开始到

    结束,生命周期如下

    3、bug单内容

    Bug描述(summary)

    环境信息:操作系统/数据库/浏览器/软件版本 (OS/Database/Project/Build/Release)

    所属功能模块、测试/开发人员、严重等级(1-5)、客户优先级、风险程度、状态、重现步骤、实际结果、是否要回归问题等

    4、测试报告

    把测试的过程和结果写成文档,对发现的问题和缺陷进行分析,为纠正软件的存在的质量问题提供依据,

    同时为软件验收和交付打下基础测试报告和测试计划一样,一般由测试leader编写,测试人员需要了解

    一下测试报告中都有哪些内容

    2.8 典型bug

    1、抓包作用: 测试一个app搜索功能,抓包,抓到一个搜索接口,突然发现抓到了两个请求接口 -> 当访问量上来了,服务的压力上升两倍

    2、数据流走向 : 测试时候发现页面上数据只有一条,但是数据库里面多了一条 -> 1、数据量变大,查询变慢 2、脏数据太多,瞬间爆满,程序崩溃了

    3、弱网测试:app项目一定要有弱网络测试(模拟2g、3g、4g,wifi网络状态以及丢包情况);网络切换测试(网络断开后重连、3g切换到4g/wifi 等)

    三、小结

    总结下来,做好功能测试并不是一件容易的事情。我做了两年的互联网功能测试来,还是很多知识不明白,只有不断的学习,自己才能成才。

    很多人功能测试都做不好,就想做性能测试、自动化测试,其实是好高骛远,我觉得基础打好了,再去学习性能测试、自动化测试什么什么的,肯定事半功倍。

    展开全文
  • 功能测试的方法

    千次阅读 2016-08-23 15:19:35
    等价类划分法是把所有可能的输入划分成若干部分(子集),然后从每一个子集中选取具有代表性的数据作为测试用例。 有效等价类:有效等价类指对于程序规格说明来说,是合理的、有意义的输入数据构成的集合。 无效...


    1.等价类划分法:

    等价类划分法是把所有可能的输入划分成若干部分(子集),然后从每一个子集中选取具有代表性的数据作为测试用例。

    有效等价类:有效等价类指对于程序规格说明来说,是合理的、有意义的输入数据构成的集合。

    无效等价类:无效等价类和有效等价类相反,无效等价类是指对于软件规格说明而言,没有意义的、不合理的输入数据集合。

    2.边界值分析法:

    边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。

    通常边界值分析法是作为对等价类划分法的补充(即等价类划分法与边界值分析法配合着一起使用,可以减少测试次数,又可以做到更精准的测试),其测试用例来自等价类的边界。应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据。

    在进行测试时,应先使用等价类划分法根据输入的特性,首先将其分为有效等价类跟无效等价类,然后再用边界值分析法选取有效等价类还有无效等价类的边界值,最后对这些边界值进行测试。(除了边界值之外,还可以再每一等价类中多选几个数据)

    例如:闹钟在800响铃,则先使用等价类划分法将其划分为有效等价类:800;无效等价类:0007598012400。然后用边界值分析法对其进行补充,选取边界值,提高测试准确度:759,800,801。除此之外还可以在无效等价类中多选几个值,比如:810,940等。

    3.错误猜测法:

    错误猜测法基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。

    例如:

    • 新增动画,在动画过程中能否被打断,有没有对其他操作进行屏蔽,例如:Home、返回键、来电、短信提示、屏保、快速操作;

    • 挂载SD卡,取消挂载SD卡;

    • 内存不足;

    • 程序异常停止,正在运行杀死后台进程、Eclipse、最近运行等;

    • 2D/3D设置项数据是否有同步;

    • 同一数据源的不同模块,在修改后是否有同步;

    • 数据下载过程中,网络突然中断了会怎么样;

    • 输入框中只输入空格或换行,会不会被当成有效输入;

    • 更新软件后,功能表程序图标是否有更新;

    • 横竖屏切换后,界面是否能够还原,数据是否可以保存;

    错误推测法即思考一些特殊的情况(外部环境的突然改变;用户的一些可能性操作),这些特殊的情况会带来什么影响,然后根据这些特殊情况设计测试用例。

    例如:在DarlingAlarm项目中,用错误推测法可以猜测一下用户是否会无意间设计了两个相同类型(都是健康睡眠)的闹钟,而且内容也都一样,对手机或者这个app有什么影响。

    4.场景法:

    场景法一般包含基本流和备用流,从一个流程开始,通过描述经过的路径来确定的过程,经过遍历所有的基本流和备用流来完成整个场景。

    基本流:是经过用例的最简单的路径,需求分解后的基本用例;

    备选流:备选流从基本流开始,跳到其他界面完成用例、基本流执行时回到开始、基本流执行时打断结束,备选流执行时打断。


    5.因果图/判定表

    如果在测试时必须考虑输入条件的各种组合,就可使用因果图来设计测试用例。它适合于描述对于“多种条件的组合,会相应产生多个动作”的情况。

    因果图– 基本符号:




    用场景法及因果图/判定表对下列案例进行测试用例设计

    案例描述GGBook电子书购买测试用例的设计。

    其规格说明如下:

    1点击付费电子书,若登录账号,账号余额充足,点击确定购买,扣款成功,则电子书可读。

    2若没有登录账号,则提示登录账号。

    3若账号余额不足,则提示充值。

    4扣款失败,账户余额不变,电子书不可读。

    场景法:

    (1)购买电子书示意图

       user                  购买电子书                                    GGBook

                                

    (2)用例图

    基本流

    1.输入帐号,密码,检查是否正确(对此事件流,帐号是有效的,成功登录)

    2.用户选择电子书,选择购买并付款,检查余额是否充足(对此事件流,用户余额充足)

    3.外部环境良好,扣款成功,并据此更新用户余额,成功购买电子书

    备选流1;帐号无效

    在基本流步骤1中,验证账户;验证出账户无效,并给出相关提示

    备选流2:余额不足

    在基本流步骤2中,检查出余额不足并给出相应提示,提示用户充值

    备选流3:扣款失败

    在基本流步骤3中,由于其他原因,导致没有扣款成功,并给出相应提示,如未链接网络

    (3)场景设计

    场景描述

    基本流

    备选流

    场景一:成功购买

    基本流


    场景二:帐号无效

    基本流

    备选流1

    场景三:余额不足

    基本流

    备选流2

    场景四:扣款失败

    基本流

    备选流3

    (4)用例设计

    序号

    场景

    描述

    结果

    1

    成功登录,余额充足,扣款成功

    成功购买

    2

    登录失败,账户无效

    帐号无效

    3

    登录成功,余额不足

    余额不足

    4

    登录成功,余额充足,但是外部环境不够良好

    扣款失败

    因果图/判定表:

    (1)、分析原因和结果

    原因:

    c1、登录账号

    c2、余额充足

    c3、扣款成功

    结果:

    e1、提示登录

    e2、提示充值

    e3、电子书可读

    e4、电子书不可读

    (2)、画出因果图(所有原因结点列在左边,所有结果结点列在右边)


    (3)、转换成因果图判定表



    结合上面两个的测试案例的设计,场景法跟因果图/判定表有时候是可以相互转换的。因此当要考虑条件的多种组合情况时并且条件组合情况较多,采用因果图/判定表较为合适。但是当条件组合较少,可以采用场景法,这样有利于测试设计者设计测试用例,同时使测试用例更容易理解和执行。

    6.用例测试的综合策略:

    • 使用等价类划分各个区间和简化用例;

    • 在任何情况下都必须使用边界值分析方法;

    • 使用错误推测法追加一些测试用例;

    • 对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度;

    • 程序功能说明中输入条件组合情况较为复杂,可选用因果图法;

    • 业务流很清晰的系统,可用场景法贯穿整个测试案例过程;

    • 进行用例评审,保证用例完善度

    展开全文
  • 如何做好功能测试

    万次阅读 多人点赞 2018-05-30 10:40:51
    当然你也有自己对功能测试的理解,但是最近两年感觉功能测试好像不太受欢迎,同时不少同学真的是功能测试都没有做好,就去尝试自动化测试测试开发什么的,结果是越学越迷茫,这是为什么呢?究其原因是,你功能测试...
         不论你是什么时候开始接触测试这个行业的,你首先听说的应该是功能测试。通过一些测试手段来验证开发做出的代码是否符合产品的需求?当然你也有自己对功能测试的理解,但是最近两年感觉功能测试好像不太受欢迎,同时不少同学真的是功能测试都没有做好,就去尝试自动化测试,测试开发什么的,结果是越学越迷茫,这是为什么呢?究其原因是,你功能测试还没有学好呢!

         我们通常认为的功能测试是根据需求,采取如下测试流程:需求分析,用例编写,用例评审,提测验证,Bug回归验证,上线与线上回归等来进行测试。如此日复一日,年复一年,响应了很多需求,可是想换工作的时候却得不到认可,大家想想是不是这种情况?下面我就以一个功能测试人员如何进行工作,来介绍一下功能测试应该用到的知识及相关的提升建议。

    一,  需求分析,发挥主动性

          正常的需求在产出的时候,产品是要分析这个需求的价值,影响范围和实现代价的。可是现在很多情况是,需求来了就组织评审,然后开发测试与上线。产品主导型的开发模式非常常见,作为测试我们无法主导需求和项目。在需求评审的时候,作为一个测试人员必须了解这次需求的内容,影响到哪些现有的功能,涉及到的操作系统或是类别等,然后准确的评估出工作量,防止因评估不足造成后期测试不充分。再者,关注开发和产品的讨论,如果开发说哪一部分比较难实现,最后如何实现?其中做出的变动和难点就是测试的时候必须重点关注的部分。不能因为这些暂时和你没有关系就不去关注,后期会带来麻烦。第三,需求评审结束后,要求产品更新此次评审过程中的所有改动部分,同时给出方案确保产品的任何改动都及时更新。第四,根据产品需求,设计测试方案及时间安排,此时可以粗粒度考虑,时间上要合理;同时与在会人员进行探讨。

    二,  用例设计与评审,做到不遗不漏

         测试用例是每个测试人员工作过程中必须要完成的工作,不管你是用Excel,还是用FreeMind来写,在测试工作中一是用来指导测试工作,而且是相关业务的一个文档沉淀。可能你不太在意测试用例的编写,可是在我以往面试的经验中,有超过一半的人写的测试用例是不达标的。很多人写用例是用书本上的方法,什么边界值法,条件覆盖法等等,其实我们更应该关注用户,从用户的角度来写用例才对.
         测试用例必须具备的测试用例名,执行步骤,预期结果这三点是必须要写清楚的。再者就是测试方案选择必须全面,作为功能测试人员你可能不会编写自动化测试脚本,不会性能测试,安全测试,但是你必须能根据需求想到要实施哪方面的测试。如面试的时候给你一个场景:一个全新的App要发版,如果让你来测试,你能想到哪些测试方案?如果你只能想到如何去测试app的功能的话,那你作为功能测试人员就是考虑不全面。此时的App的功能,App的性能,数据传输的安全性,接口或服务的功能测试,接口或服务的自动化测试与监控,接口或服务的性能测试,底层数据的存储与容灾情况都必须考虑在内。
         设计用例的时候要设计两类, 一类是开发自测和验收提测试标准的冒烟测试用例,一类是针对需求的全面测试用例。写完用例要主动联系相关人员进行用例评审,强调开发自测,在评审过程是及时修改不合适的用例。

    三,  测试流程,注重项目控制

         其实项目的流程控制在需求开始的时候就应该重视起来,只是很多时候我们没有意识到这是测试的工作,有的是产品来控制,有的是专门的项目经理来控制。测试人员是一线的工作人员,不管你工作了多久,必须有关注整体项目的意识。如果你不关注项目进度,什么时候提测你什么时候开始测试,在测试过程中你就会遇到测试的内容和最初的需求不一致,增加新的内容从而增加工作量,或是产品和开发一起来压缩测试时间的情况,到时你想不加班都难。
          需求一旦明确了由你来负责的时候,就要时刻按排期来关注项目的情况。中间变更需求的时候,要评估是否影响项目进度,如果影响了重新进行排期。如果开发提测试晚了,是否影响上线时间,如果可能会影响,马上就要给相关的人员发预警邮件,通知大家详细的情况。同时在测试过程中,发现了bug必须详细描述问题,不管是jira,禅道或是其他的bug管理方式,一个bug要写清楚以下几点:Bug问题描述,bug重现步骤,是否有前置条件,预期结果,实际结果,以方便开发去进行修改。同时给bug准确分级,实时跟踪进度,保证项目按期完成。

    四,  上线回归与项目总结

         一个需求上线完成后,要及时进行线上回归,如果有必须提醒相关的人员进行自动化线上回归或是监控工作。同时必须回归我们在需求评审的时候考虑到的可能影响到的原有的功能,以确保新功能的完全上线成功。而作为功能测试人员,在一个项目完成后,不管公司有没有要求,要对项目做相应的文字总结。总结整个项目过程中遇到的问题,最后的解决办法或是当时讨论的处理办法,有哪些需要注意的问题?有什么可以借鉴的方案或是改进策略?项目中有没有通用性的问题等等。
          如果公司有相应的项目总结方案,那测试的时候就要多关注一些数据,如冒烟测试是否一次通过,Bug数及不同级别的bug数,参与开发人员对应的Bug数,提测试次数,上线次数等等。而后借助于第三方工具进行图表化相应的数据,然后相关问题的总结,改进方案都需要进行详细的总结。

    五,  能力的总结和沉淀

         在我们找工作的时候,很多做功能测试多年的同学一般很难通过面试,这里面的原因究竟是什么?其实最核心的原因是,你不具备相应工作年限应该具备的能力.
         测试工具的使用:在你以往的工作经验中,有没有总结过什么样的需求或是项目应该使用什么样的测试工具,而不是仅仅使用公司提供或是指定的工具?有没有分析过同类的工具的优缺点?如果一个类似的全新的产品,你能否围绕着工作需求,准备相应的测试工具来辅助测试?什么样的测试工具在测试项目的时候可能存在问题,问题的解决办法是什么?
          问题的总结:在测试工作中总结部署环境出现502或是404产生的原因及解决办法?产品的哪儿块功能容易出现问题,或是开发怎么实现相应的功能可能出现问题?产品的功能模块之间是如何工作的,修改部分功能后可能会对其他模块产生影响?哪个版本的编译器打包的产品容易在哪些方面出现问题?等等相应的问题总结有没有做,如果做了,在接到相应的需求后就能快速的评估测试范围,选择测试方案,规划测试时间等。
         技术的沉淀:技术不仅仅指的是编码能力,像平时我们部署环境出现问题后,最后的解决方案的总结;测试过程中日志出现空指针的排查;项目测试过程中遇到的问题及解决方案;一些常见问题的排查及解决方案等等。要在工作中善于积累,从而指导自己的工作或是为同事提供解决问题的思路与办法。
          时常问自己一句话:离开现有的平台,我还有什么?这个才是你的资本,对公司业务的熟悉,公司现在工具的使用等等,对你来说是没有任何优势可言的。而对同类业务流程的掌握,项目的整体把控,快速了解业务并能根据需求选择测试方案,引进现有的测试工具提高测试效率,测试过程中遇到问题的预判和解决办法等才是功能测试人员必须具备的能力。这些方面你做到了吗?业务专家也是不想做编码的测试人员一个很好的选择,不要整天抱怨功能测试如何如何,要充分认清行业现状和自己的优缺点,做好职业规划。
    展开全文
  • 功能测试方法总结/常见面试问题

    千次阅读 2018-12-03 16:45:27
    一、功能测试 1、链接测试 链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的...

    一、功能测试

    1、链接测试

    链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。

    链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试。

    2、表单测试

    当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。

    3、Cookies测试

    Cookies通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用Cookies访问了某一个应用系统时,Web服务器将发送关于用户的信息,把该信息以Cookies的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。

    如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。

    4、设计语言测试

    Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了HTML的版本问题外,不同的脚本语言,例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。

    5、数据库测试

    在Web应用技术中,数据库起着重要的作用,数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中,最常用的数据库类型是关系型数据库,可以使用SQL对信息进行处理。

    在使用了数据库的Web应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试。

    二、性能测试

    1、连接速度测试

    用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟),用户就会因没有耐心等待而离开。

    另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。

    2、负载测试

    负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。例如:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?

    3、压力测试

    负载测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个Web系统能同时处理的请求数量将远远超出这个限度,所以,只有放在Internet上,接受负载测试,其结果才是正确可信的。

    进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。

    压力测试的区域包括表单、登陆和其他信息传输页面等。

    三、可用性测试

    1、导航测试

    导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个Web应用系统是否易于导航:导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?

    在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动,很快地扫描一个Web应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构,因此,Web应用系统导航帮助要尽可能地准确。

    导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。

    Web应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。

    2、图形测试

    在Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:

    (1)要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。

    (2)验证所有页面字体的风格是否一致。

    (3)背景颜色应该与字体颜色和前景颜色相搭配。

    (4)图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩。

    3、内容测试

    内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。

    信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行,例如使用Microsoft Word的”拼音与语法检查”功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般Web站点中的所谓”相关文章列表”。

    4、整体界面测试

    整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?

    对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。

    对所有的可用性测试来说,都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。

    四、客户端兼容性测试

    1、平台测试

    市场上有很多不同的操作系统类型,最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。

    因此,在Web系统发布之前,需要在各种操作系统下对Web系统进行兼容性测试。

    2、浏览器测试
    Web应用的测试内容都包括哪些方面
    浏览器是Web客户端最核心的构件,来自不同厂商的浏览器对Java,、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如,ActiveX是Microsoft的产品,是为Internet Explorer而设计的,JavaScript是Netscape的产品,Java是Sun的产品等等。另外,框架和层次结构风格在不同的浏览器中也有不同的显示,甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。

    测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

    五、安全性测试

    Web应用系统的安全性测试区域主要有:

    (1)现在的Web应用系统基本采用先注册,后登陆的方式。因此,必须测试有效和无效的用户名和密码,要注意到是否大小写敏感,可以试多少次的限制,是否可以不登陆而直接浏览某个页面等。

    (2)Web应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。

    (3)为了保证Web应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

    (4)当使用了安全套接字时,还要测试加密是否正确,检查信息的完整性。

    (5)服务器端的脚本常常构成安全漏洞,这些漏洞又常常被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。

    怎么做好文档测试?

    仔细阅读,跟随每个步骤,检查每个图形,尝试每个示例,检查文档的编写是否满足文档编写的目的,内容是否齐全,正确,完善.标记是否正确.

    软件测试分哪2种方法?分别适合什么情况?

    软件测试分2种:白盒测试和黑盒测试。白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试,它着重于程序的内部结构及算法,通常不关心功能与性能指标;黑盒测试又称功能测试、数据驱动测试或基于规格说明的测试,它实际上是站在最终用户的立场,检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定

    2.白盒测试有几种方法?

    总体上分为静态方法和动态方法两大类。
    静态:关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义
    动态:语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

    3.系统测试计划是否需要同行审批,为什么?

    需要,系统测试计划属于项目阶段性关键文档,因此需要评审。

    4.Alpha测试与beta的区别?

    Alpha测试在系统开发接近完成时对应用系统的测试;测试后仍然会有少量的设计变更。这种测试一般由最终用户或其它人员完成,不能由程序或测试员完成。
    Beta测试当开发和测试根本完成时所做的测试,最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其它人员完成,不能由程序员或测试员完成。

    5.比较负载测试,容量测试和强度测试的区别?

    负载测试:在一定的工作负荷下,系统的负荷及响应时间。
    强度测试:在一定的负荷条件下,在较长时间跨度内的系统连续运行给系统性能所造成的影响。
    容量测试:容量测试目的是通过测试预先分 析出反映软件 系统应用特征的某项指标的极限值(如最大并发用户数、数据库记录数等),系统在其极限值状 态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试 还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测试是面向数据的,并且它的目的是显示系统可以处理目标内确定的数据容量。

    6.测试结束的标准是什么?

    用例全部测试。
    覆盖率达到标准。
    缺陷率达到标准。
    其他指标达到质量标准

    7.描述软件测试活动的生命周期?

    测试周期分为计划、设计、实现、执行、总结。其中:
    计划:对整个测试周期中所有活动进行规划,估计工作量、风险,安排人力物力资源,安排进度等;
    设计:完成测试方案,从技术层面上对测试进行规划;
    实现:进行测试用例和测试规程设计;
    执行:根据前期完成的计划、方案、用例、规程等文档,执行测试用例。
    总结:记录测试结果,进行测试分析,完成测试报告。

    8.软件的缺陷等级应如何划分?

    A类—严重错误,包括以下各种错误: 1. 由于程序所引起的死机,非法退出 2. 死循环 3. 数据库发生死锁 4. 因错误操作导致的程序中断 5. 功能错误 6. 与数据库连接错误 7. 数据通讯错误

    B类—较严重错误,包括以下各种错误: 1. 程序错误 2. 程序接口错误 3. 数据库的表、业务规则、缺省值未加完整性等约束条件

    C类—一般性错误,包括以下各种错误: 1. 操作界面错误(包括数据窗口内列名定义、含义是否一致) 2. 打印内容、格式错误 3. 简单的输入限制未放在前台进行控制 4. 删除操作未给出提示 5. 数据库表中有过多的空字段

    D类—较小错误,包括以下各种错误: 1. 界面不规范 2. 辅助说明描述不清楚 3. 输入输出不规范 4. 长操作未给用户提示 5. 提示窗口文字未采用行业术语 6. 可输入区域和只读区域没有明显的区分标志

    9. 当开发人员说不是BUG时,你如何应付?

    开发人员说不是bug,有2种情况,一是需求没有确定,所以我可以这么做,这个时候可以找来产品经理进行确认,需不需要改动,3方商量确定好后再看要 不要改。二是这种情况不可能发生,所以不需要修改,这个时候,我可以先尽可能的说出是BUG的依据是什么?如果被用户发现或出了问题,会有什么不良结果? 程序员可能会给你很多理由,你可以对他的解释进行反驳。如果还是不行,那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不 要修改就不改。其实有些真的不是bug,我也只是建议的方式写进TD中,如果开发人员不修改也没有大问题。如果确定是bug的话,一定要坚持自己的立场, 让问题得到最后的确认。

    10.你为什么想离开目前的职务?

    因为公司运作情况并不理想,公司需要调整部门体系,公司考虑到缩减部门人员,所以大批量的裁员(有6,7个),这是我的第一份工作,对公司也有较深的 感情,因为在这里我找到了职业理想(就是测试),所以公司需要精简人员,我自愿退出。虽然很舍不得,但我将会有新的发挥能力的舞台。

    11.您认为做好测试用例设计工作的关键是什么?

    白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
    黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题

    12. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

    黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。
    白盒测试:已知产品的内部工作过程,可以通过测试证明每种内部操作是否符合设计规格要求,所有内部成分是否以经过检查。
    软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序 的需求规格说明书,检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误:
    1、是否有不正确或遗漏的功能?
    2、在接口上,输入是否能正确的接受?能否输出正确的结果?
    3、是否有数据结构错误或外部信息(例如数据文件)访问错误?
    4、性能上是否能够满足要求?
    5、是否有初始化或终止性错误?
    软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计 或选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序状态,确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测 试。白盒测试主要是想对程序模块进行如下检查:
    1、对程序模块的所有独立的执行路径至少测试一遍。
    2、对所有的逻辑判定,取“真”与取“假”的两种情况都能至少测一遍。
    3、在循环的边界和运行的界限内执行循环体。
    4、测试内部数据结构的有效性,等等。
    单元测试(模块测试)是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。
    单元测试是由程序员自己来完成,最终受益的也是程序员自己。可以这么说,程序员有责任编写功能代码,同时也就有责任为自己的代码编写单元测试。执行单元测试,就是为了证明这段代码的行为和我们期望的一致。
    集成测试(也叫组装测试,联合测试)是单元测试的逻辑扩展。它的最简单的形式是:两个已经测试过的单元组合成一个组件,并且测试它们之间的接口。从这 一层意义上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组合成组件,而这些组件又聚合成程序的更大部分。方法是测试片段的组合,并最终扩展进 程,将您的模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。
    系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。(常见的联调测试)
    系统测试的目的是对最终软件系统进行全面的测试,确保最终软件系统满足产品需求并且遵循系统设计。
    验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。
    验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,接口错误也已经基本排除了,接着就应该进一步验证软件的有效性,这就是验收测试的任务,即软件的功能和性能如同用户所合理期待的那样。

    展开全文
  • 常见的功能测试点!

    千次阅读 2019-06-21 09:47:46
    登录 1)空白 用户名和密码均为空/用户名填写,密码为空/用户名为空,密码填写 2)错误校验 输入错误的用户名和密码/用户名错误密码正确/用户名正确密码错误 3)大小写区分(如:用户名和密码都为小写时) ...
  • 功能测试

    2018-05-22 15:48:44
    功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。常用的测试方法如下: 1. 页面链接检查:每一个链接是否都有对应的页面,并且页面之间切换正确。 2. 相关性...
  • 功能测试心得

    千次阅读 2018-08-26 20:25:45
    回头想想,基本的功能测试好像还做不好,用例写的也不是特别好用,还研究一堆技术。这篇文章以后应该会不断增加内容,写一些功能测试遇到的特殊点,距离上一个大项目时间有点长了,可能会漏一些东西,先把能记起的写...
  • 功能测试方法

    千次阅读 2013-08-01 16:03:06
    功能测试主要采用黑盒测试方法,结合测试内容对功能进行测试,同时在测试过程中对用户需求、设计文档和使用手册进行检查。测试方法主要根据测试对象的不同灵活进行选择。 功能测试主要分为功能模块测试和业务流程...
  • 本文主要介绍; 显式功能性需求(Functional requirement) 显式功能性需求(Functional requirement)的含义从字面上就可以很好地理解... 每一个人都是一个测试人员,如同《人人都是产品经理》这本书一样,对...
  • 软件测试功能测试点总结

    千次阅读 多人点赞 2018-08-09 20:37:36
    针对web系统的常用测试方法如下: 1. 页面链接检查: 每一个链接是否都有对应的页面,并且页面之间切换正确。可以使用一些工具,如LinkBotPro、File-AIDCS、HTML Link Validater、Xenu等工具。LinkBotPro不支持...
  • 一、注册功能怎么测试

    千次阅读 2019-02-21 16:54:26
    功能测试用例: (1)输入已注册过的手机号获取验证码再次注册; (2)输入不符合手机号规则的号码获取验证码进行注册; (3)输入欠费的手机号获取验证码进行注册; (4)输入10位数字获取验证码进行注册; (5)...
  • 1.功能测试:  --又名:黑盒测试  --依据;需求文档  --执行:测试用例  --方法:等价类划分,边界值分析,错误推测,因果图法,判定表驱动分析方法,正交实验设计方法,功能图分析方法  --错误:功能错误...
  • 文章目录系统测试概述功能测试性能测试负载测试压力测试性能测试、压力测试、负载测试的关系兼容性测试安全测试健壮性测试配置测试可用性测试文档测试 系统测试概述 系统测试的定义 将已经集成好的软件系统,作为...
  • JMeter性能测试教程

    万次阅读 2020-10-08 14:39:12
    Apache JMeter是一款纯java编写负载功能测试和性能测试开源工具软件。相比Loadrunner而言,JMeter小巧轻便且免费,逐渐成为了主流的性能测试工具,是每个测试人员都必须要掌握的工具之一。 本文为JMeter性能测试...
  • 1、功能测试。 Functional testing(功能测试),也称为behavioral testing(行为测试),根据产品特性、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。 1>又名:黑盒测试或数据...
  • 软件性能测试的几种方法

    万次阅读 2015-11-27 22:34:01
    首先我们来看看什么是软件性能?  软件的性能是软件的一种非功能特性,它关注的不是软件是否能够完成特定的功能,而是在完成该功能时展示出来的及时性。 表明了软件系统对时间...再看看性能测试的定义?  狭义的
  • 几种性能自动化测试工具整理

    万次阅读 2018-09-07 11:10:55
    在移动应用和Web服务正式发布之前,除了进行必要的功能测试和安全测试,为了保证互联网产品的服务交付质量,往往还需要做压力/负载/性能测试。然而很多传统企业在试水互联网+的过程中,往往由于资源或产品迭代速度等...
  • 浅谈自动化测试和性能测试

    万次阅读 2018-01-11 10:23:16
    常常有刚接触自动化和性能测试的同学问我,感觉性能测试和自动化测试是差不多的,我自己刚接触的时候认为也是差不多的,区别就是:自动化一个用户再跑,性能测试需要并发,需要设计各种场景。慢慢的做的多了,发现...
  • 十大软件测试工具

    万次阅读 多人点赞 2017-04-12 20:30:17
    目前由于软件测试工作在软件的生产过程中越来越重要,很多软件测试工具应运而生,这里介绍一下目前最流行的一些软件测试工具,一个十个,介绍如下:    一、企业级自动化测试工具WinRunner 这款软件是Mercury ...
  • 网上功能测试案例模板各种各种不计其数,性能测试案例模板少之又少,前段时间看到一个朋友在群里跪求性能测试案例模板,其实不用跪,只要大家多总结,多思考,自己也能设计出一个满足自己测试需求的性能测试案例模板...
1 2 3 4 5 ... 20
收藏数 2,472,879
精华内容 989,151
关键字:

功能测试