一、摘要 自动化测试可以快速自动完成大量测试用例,节约巨大的人工测试成本;同时它需要拥有专业开发技能的人才能完成开发,且需要大量时间进行维护(在需求经常变化的情况下),所以大部分具有很好开发技能的人员不是很愿意编写自动化用例。但由于软件规模的高速增长,人力资源的逐步稀缺,自动化测试已是势在必行。 对于自动化测试首先需要保证其功能是对客户有价值的和正确可用的。而这一切的基础就是用例要能测试客户的需求,期望,最好能让客户参与到测试用例的开发过程中来或让客户评审测试用例,因此出现了ATDD、BDD等各种理论方法来
测试点是测试者在测试时需要关注的地方。虽然我们在分析测试点时,会使用各种测试方法,但这些方法在思路和操作上都是不同的,一些方法得到的测试点要细一些、具体一些,一些方法得到的测试点粗一些、泛一些是非常正常的。另外,谁也不能保证这些测试点之间不会重复或是相互包含。如果我们的测试就是按照这样一份粗细不一、深浅不明、关系不清的说明书来进行的,又怎么不会陷入既冗余又不足的困境中呢?
在第一篇文章 接口自动化测试实践指导(上):接口自动化需要做哪些准备工作中详细给小伙伴们讲解了一下接口自动化需要做哪些准备工作,准备工作中最后一步接口测试用例设计是非常重要的一个环节,用例设计的好不好,直接关系到我们的测试质量,那如何进行测试用例设计呢,这里呢我结合自身经验,帮助大家梳理一下接口测试用例设计思路,希望对大家后续接口测试工作有所帮助和提升。
之前开发的接口测试平台https://github.com/liwanlei/FXTest,今天的时候,想开发一个将测试用例转化成Jmeter压测脚本的功能。想着还是在原来的框架下做开发。那么我是怎么构思的呢。
单元测试应该在的功能和参数上验证程序的正确性;单元测试过后,机器状态应该保持不变;单元测试的运行、通过、失败不依赖于别的测试,可以人为构造数据,以保持单元测试的独立性。
测试用例是一个传统而又基础的话题,对于新手来说如何写一个全面的测试用例是走出小白的第一步,随着技术和时代的进步,传统的冗余测试用例已经逐渐跟不上时代,不写测试用例没事做,写了测试用例也跟不上需求的变化还浪费时间,那么怎么办呢?
从最初的探索,再到现在的团队成员共同完善 Flutter 单元测试,期间踩了不少坑也积累了不少经验,现将这些内容分享出来,希望能给对 Flutter 单元测试感兴趣的同学带来一些帮助。
简单来说,无论函数如何实现,单测可以保证我们始终能得到预期的结果。 最近半年我们在提升我们项目的代码单测覆盖率,来提前发现代码中的问题。单元测试可以有效的提前发现问题,也可以很好的实现测试左移。
通过基本的单元测试框架介绍(http://km.oa.com/group/viptest/articles/show/374474)和mock框架介绍(http://km.oa.com/group/viptest/articles/show/377938),能指引我们会写自己的单元测试了,最近在给开发同学宣讲go单测时,交流过程发现开发同学特别关注如何写出好的单元测试,最近也在看业界大牛们的分享,结合实践过程理解,大致整理了下几个要点。 用断言来代替原生的报错函数 让我们看这样一个例子: GO 语
前面一篇,我们一气呵成地完成了第一个Selenium自动化脚本的编写过程。当然是我完全给你灌输了这些代码和代码的解释,也许你还没有掌握。因为,我没有教你如何元素定位,如何写精确的xpath表达式,如何高效写测试断言。这些东西,有些你可以去我博客看看对应文章,有些是无法教会你,需要你多多练习,自己思考和总结。本篇,我们来找找上一篇自动化用例的不合理之处有哪些。
其实很多人测试人er都知道测试用例的重要性,它不仅会锻炼我们的测试思维,还可以对项目有个整体的把握,假如有新人来了,通过看测试用例也能熟悉不少,也省去一些我们教的时间。
前面一篇《单元测试框架系列教程1-TestNG简介》,介绍了TestNG的特点和官网地址,以及在IDEA上的配置过程。这篇,我们就来动手写一个基于TestNG的测试代码,或者叫测试用例。
测试驱动开发(Test-Driven Development)是一种软件开发的思维和方法,我的理解是它是一种开发的循环,先写测试代码,再用最小的代码实现这个测试,再继续写测试代码,继续用最小的代码实现。当实现所有的测试用例,代码也就完成了。
现在大公司越来越重视项目的单元测试,甚至明确要求项目的单元测试覆盖率不能低于某个值,足可见单元测试的重要性;
本文中的Robot framework安装在Win7 (32 bit) 平台上. 接下来按顺序安装以下的软件/包。
有一次,我在一个讲座上听到主持人问听众如何故意编写难于测试的代码。在场的小伙伴都惊呆了,因为没有任何人会故意写这种糟糕的代码。我记得他们甚至给不出一个好的答案。
本文主要面向单元测试新手,首先简单介绍了什么是单元测试,为什么要写单元测试,讨论了一下 Android 项目中哪些代码适合做单元测试,并以一个简单例子演示了如何编写属于你的第一个 Android 单元测试(kotlin 代码)。
诸如此类的疑问很多,今天我们先来聊聊“如何编写用例”的问题。编写用例是我们测试人员日常工作中最主要也是最频繁的工作,我们可以从书上或者网上查到很多这方面的资料,很遗憾的是,很难用一篇文章能把这个问题讲得全面而清晰。这也跟企业中面临的情况复杂多变有关,本文希望抛砖引玉,欢迎大家在文章下方留言。
前面文章细心的小伙伴会发现宏哥在运行测试用例的时候有的是在main方法下,而有的不需要用main方法去执行用例,那么为什么有的就不需要在main方法下就能够成功运行测试用例了。这就需要单元测试框架的支持,这篇宏哥就来简单介绍TestNG单元测试框架的安装和基本使用。
在多人协作的项目中,特别是项目团队中,会有多个技术选型类似的项目,例如是都是通过 React 全家桶搭建的项目。随着项目的业务逻辑逐渐增加,我们都会抽取其中一些公共的代码,特别是一些与业务没有强耦合的组件,组成一个基础公共组件库,提供给各个项目使用。听起来很美好,但是在实际工程实践方面,会产生一些问题:
前言 软件测试是把控软件质量的重要防线,但风险又存在于软件测试的全过程,如何有效的进行风险控制呢?就是主动的发现,暴露产品存在的风险和缺陷,并协同团队成员,做好容灾解决方案并一起解决风险。 无论是模
关于TestRunner, 我想大家都已经非常熟悉了。在我的的书中也有其各个用法的专门介绍,这里不再赘述。
测试计划的内容包含测试策略、测试目标、测试里程碑、测试资源评估、交付成果。测试计划是我们完成某个项目过程中所需要付出的努力,是软件测试活动的蓝图,由测试经理进行把控整个测试过程。
在上文 走进Java接口测试之从0到1搭建数据驱动框架(需求篇) 中我们介绍了数据驱动框架中的需求,本文我们将根据需求进入设计阶段,废话不多说,直接进入主题。
主要有三个层级,模块、方法/函数、类,都是setup、teardown,实际写 的时候注意大小写
grex 是可以通过测试用例生成正则表达式的命令行工具和库,可以简化繁琐的正则表达式编写过程,下面是一个例子
本文开始介绍如何通过unittest来管理和执行测试用例,这一篇主要是介绍unittest下addTest()方法来加载测试用例到测试套件中去、用addTest()方法来加载我们测试用例到suite中去和利用discover()方法去加载一个路径下所有的测试用例。
相信不少同学在写单测的时候,最大的困扰不是如何写测试代码,而是:“应该测什么?”,“要测多深入”,“哪些不该测”。
首先,单元测试是十分重要的,试想如果没有单元测试,那么如何保证代码能够正常运行呢?测试人员做的只是业务上的集成测试,也就是黑盒测试,对单个的方法是没有办法测试的,而且,测试出的 bug 的范围也会很广,根本不能确定 bug 的范围,还得去花时间来确定 bug 出在什么地方。难道这就不浪费时间了吗?甚至,这样的方式,时间浪费的会更多。其重要性请看博文论单元测试的重要性
今天的这篇文章继续接着昨天的文章《软件测试新人问题回复(一)》开始解答剩下的问题:
对于单元测试中的单元,不同的人有不同的看法:可以理解为一个方法,可以理解为一个完整的接口实现,也可以理解为一个完整的功能模块或者是多个功能模块的一个耦合。
本文介绍基于http request的接口测试,从创建项目到编写case到断言,一步步教会你如何写一个接口测试用例。
最近在带一个学生,是一个超级认真、努力的学生,布置的作业和学习点都会认真去完成,我能感受到他是在尽心尽力地去做好,从提出的问题中就能看到这个变化,由以前的很外行的提问,到目前问题都能问到真正的点上,以下就是他针对测试流程的相关问题,王豆豆觉得可能刚入行或打算入行的小伙伴都会有类似地问题,故分享出来。
转账是银行等金融系统中常见的一个场景。在在最近的一个针对转账服务的单元测试中,笔者就遇到了上述问题。一个极端简化的转账申请如下图:
在这篇文章里,我们来学习一下接口测试用例设计,主要是来学习一些用例设计要点。其实说白了,接口用例设计和功能用例设计差不多,照猫画虎即可。不要把它想象的多么高大上,多么的难,其实一样,以前怎么设计,现在就怎么设计,和黑盒测试设计测试用例半斤八两。这里不再赘述,想详细了解的可以看一下Python的接口自动化用例设计。宏哥在这里,换一个角度来说接口测试的用例设计,首先我们看一下接口测试的范围。
打破软件自动化测试的格局 自动化测试的误区 自动化测试仅仅被认为是替代人工,所以我们看到很多企业实施自动化测试仅仅是将现有的 Test Case 转换成自动化脚本。 这样做既没有提高测试整体水平,也没有改善测试结果。结果是通过手工能测试出来的问题自动化测试可以测试出来,手工测试不出来的问题自动化测试也没有测试出来。 因为测试的观念仍停留在已有 Test Case 阶段,而 Test Case 停留在业务流程测试的阶段。 最终自动化测试仅仅是按照测试用例走一边业务流程,完成业务流程的检验。 分层与部署带来的问
目前,前端的测试框架很多,像QUnit、jasmine、mocha、jest、intern等框架,这些框架各有特点,简单描述下,感兴趣的可以具体研究:
本篇讲 fixture 里面的 name 参数如何使用,使用别名后代码更容易理解。
很早之前,曾在网络上见到过 TDD 这 3 个大写的英文字母,它是 Test Driven Development 这三个单词的缩写,也就是“测试驱动开发”的意思——听起来很不错的一种理念。
如何进行用例设计,如何让设计好的用例覆盖全面,将代码存在的问题在上线前更早发现是每一个测试工程师必备的技能。那么如何达到这些指标呢?如何将用例设计既快又全面呢?今天小编就告诉大家常用设计用例的方法,以及每个方法的适用范围,便于大家更快的选择出最优的方法。
Hi,大家好,今天是三月的第一天,至此正式进入 “金三银四”升职加薪的黄金季。如果你在公司是加班时的超人,加薪时的隐形人。面对跳槽机会,你动心吗?假如发展空间受限而此时恰好有很好的机会,积极投入到找工作的新大军不失为当前的一种选择,今天分享一波接口自动化面试题为你助攻,祝加薪成功!💰 一 请求接口中常见的返回状态码 请求接口中返回状态码以如下数字开头: 1xx– 信息提示(表示临时的响应。客户端在收到常规响应之前,准备接收一个或多个 1xx 响应)。 2xx – 成功(表明服务器成功地接受了客户端请求)。
1、用例编号:产品名-测试阶段-测试项XXX英文(wechat_st_register_001) 2、测试项目:功能模块–子项目 3、测试标题:测试点的细化,一行一个测试点 4、重要级别P1(冒烟)P2,P3,P4,P5.—-high,medium,low 5、预置条件:前提条件,否则无法执行 6、测试输入:跟步骤一起 7、操作步骤:明确每一个步骤。非常的详细 8、预期结果:唯一
相信大家都有过写登录测试用例的经验,相较于开发人员编写代码而言,测试人员编写用例同样重要。本文作者总结了一些关于登录用例的经验。
P3:作为一个从业十多年的测试经理,从过程管理做到研发,从研发做到测试,扎根测试十多年,经历过单机版、CS系统、BS系统、B/CS系统、3D沉浸式系统、云计算,等等数十个产品和项目,在传统或者敏捷开发项目管理模式下,推动自动化测试都有一个痛点,就是不断变化的系统对已实现自动化用例的冲击。
在实际研发与测试工作中,单元测试是代码走向高质量的必经之路,也是效能优化实践的重要一环。单元是应用的最小可测试部件。在过程化编程中,一个单元就是单个程序、函数、过程等;对于面向对象编程,最小单元就是方法,包括基类、超类、抽象类等中的方法。单元测试就是软件开发中对最小单位进行正确性检验的测试工作。
微信公众号后台回复“资源”、“测试工具包”领取测试资源,回复“微信交流群”、“内推群”一起进群打怪。
Json是轻量级的数据交互格式,以key-value的键值对形式来保存数据,结构清晰,可以说是目前互联网项目开发中最常用的一种数据交互格式。字典,同样是以key-value的键值对来保存数据,是python中的一种数据类型。
XCTest是iOS的单元测试框架,有objective-c和swift两种语言可以选择。Xcuitest是iOS的UI测试框架。
领取专属 10元无门槛券
手把手带您无忧上云