功能测试

软件测试基础 - 集成测试(理论部分)

∥☆過路亽.° 提交于 2019-12-28 05:03:04
一、集成测试概念 集成测试也叫组装测试、联合测试、子系统测试或部件测试,是在单元测试的基础上,将所有函数按照概要设计要求组装成为子系统或系统所进行的测试;它和单元测试所关注的范围是不同的,因此,它们在发现问题的集合上包含有不相交的区域,不能使用集成测试来替代单元测试,反之亦然。 二、集成测试关注点 1.模块间的接口 把各个模块连接起来的时候,穿越模块接口的数据是否会丢失; 全局数据结构是否有问题,会不会被异常修改; 2.集成后的功能 各个子功能组合起来,能否达到预期要求的父功能; 一个模块的功能是否会对另一个模块的功能产生不利的影响; 单个模块的误差积累起来,是否会放大,从而达到不可接受的程度。 三、集成测试的层次 四、集成测试策略的主要模式 现有一个模块包含以下几个函数,将以此为例讲解每种模块的运作方式: 1.大爆炸集成方式 *** 这种方式中,首先对每个模块分别进行单元测试,然后再把所有单元组装在一起进行测试,最终得到要求的软件系统,如图所示: 缺点: a.这种一次性组装方式试图在辅助模块的协助下,在模块单元测试的基础上,将所测模块连接起来进行测试。但是由于程序中不可避免地存在模块间接口、全局数据结构等方面的问题,所以一次试运行成功的可能性并不很大; b.在发现错误的时候,其问题定位和修改都比较困难; c.即使被测系统能够被一次性集成

单元测试规范流程

混江龙づ霸主 提交于 2019-12-26 23:56:02
目录导航 一.测试用例编写规范 1、测试用例编写目的 2、适用范围 3、测试用例 4、用例设计方法 5、测试用例设计的原则 6、用例设计步骤 二.测试规范 1、接口功能测试:用来保证接口功能的正确性 2、局部数据结构测试(不常用):用来保证接口中的数据结构是正确的 3、边界条件测试 4、代码覆盖率 5、各条错误处理测试:保证每一个异常都经过测试 三.实施方案 1、idea安装junit插件 2、添加pom依赖: 3、命名 4、几种常用的注解(导org.junit.jupiter包) 5、断言 6、参数化测试 7、MockMvc使用(模拟controller请求接收) 8、几个方法的简单说明: 9、增加app服务的验证签名之后的junit修改 四.验收方法 五.CI流程中需要增加的项目 1、pom依赖 2、profile 3、测试代码中profile的使用 4、测试数据的规范 六.集成方案 1、安装JDK 2、安装Jenkins 3、配置Jenkins 4、新建测试项目 一.测试用例编写规范 1、测试用例编写目的 (1)为用例的质量负责,使用例编写工作能够有序、合理; (2)统一测试用例编写的规范,为测试设计人员提供测试用例编写的指导,提高编写的测试用例的可读性,可执行性、合理性; (3)能有效的提高系统所有功能点的覆盖率。 2、适用范围 适用于人员:用于测试人员阅读和执行

功能自动化测试之QTP录制脚本(一)

故事扮演 提交于 2019-12-25 18:44:31
说明:该篇博客是博主一字一码编写的,实属不易,请尊重原创,谢谢大家! 接着上一篇博客继续往下写 : https://blog.csdn.net/qq_41782425/article/details/103668789 文章目录 一、安装 QTP 1.安装 QTP 脚本调试器 2.安装 QTP 3.汉化 4.破解 二、QTP 的工作原理 1.录制脚本 2.运行脚本 3.增强脚本 4.支持的脚本语言 三、QTP 的测试过程 1.QTP 的测试流程 2.案例 2.1 录制脚本 2.2 运行脚本 2.3 解决执行(回放)脚本的一系列问题 2.4 增强脚本(设置检查点,检查计算器结果是否正确) 2.5 增强脚本(参数化,使用不同的用例测试计算器) 2.6 QTP导入Excel表用例 2.7 执行计算器用例并添加实际结果 2.8 分析计算器的测试结果 一、安装 QTP 说明:博主在windows server 2008中进行演示 1.安装 QTP 脚本调试器 首先恢复纯净版快照,然后挂载QTP iso安装文件 点击退出安装页面,右击光盘驱动器打开,进入脚本调试器目录 安装脚本调试器 2.安装 QTP 点击光盘驱动器,进入QTP安装页面,点击安装程序 安装必要程序 安装.net FrameWork,点击同意安装即可 安装完成,点击退出即可 紧接着会自动弹出C++ 2005的安装,点击yes即可

冒烟测试与回归测试的区别

只愿长相守 提交于 2019-12-24 18:37:41
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 冒烟测试,是微软首先提出来的一个概念,和微软一直提倡的每日build(构建版本)有很密切的联系。具体说,冒烟测试就是在每日build(构建版本)建立后,对系统的基本功能进行简单的测试。这种测试强调程序的主要功能进行的验证,也叫版本验证测试,提交测试。 冒烟测试 这个名称的来历,是从电路板测试得来的。因为当电路板做好以后,首先会加电测试,如果板子没有冒烟在进行其它测试,否则就必须重新来过。类似的如果冒烟测试没有通过,那么这个build也会返回给开发队伍进行修正,测试人员测试的版本必须首先通过冒烟测试的考验。 冒烟测试的说法据说是:象生产汽车一样,汽车生产出来以后,首先发动汽车,看汽车能否冒烟,如果能,证明汽车最起码可以开动了。说明完成了最基本的功能。 冒烟测试一般用于每日构建(Nightly build),构建服务器首先从CVS服务器上,下载最新的源代码,然后编译单元测试,运行单元测试通过后,编译可执行文件,可执行文件若可运行,并能执行最基本的功能,则认为通过了冒烟测试,这时,构建服务器会把程序打包成安装文件,然后上传到内部网站,第二天一早,测试人员来了以后,会收到构建服务器发来的邮件提示昨晚是否构建成功。若构建成功,则测试人员进行相关的功能测试。所有这些功能的完成,一般是靠编写脚本完成的

用户登录页面测试的一步步深入

时间秒杀一切 提交于 2019-12-24 10:45:09
登录页面测试 在面试测试工程师相关的岗位时,一般面试官都会使用用户登录页面的测试来考察面试者的测试用例设计能力以及测试思维。 初级 一个看似简单的测试用例设计题,从你的回答就能得出你的测试用例设计功底。 初级的测试工程师可能会想到以下测试用例: (1)什么都不输入,验证是否登录失败,并且提示信息正确; (2)输入正确的用户名,正确的密码,验证是否登录成功; (3)输入正确的用户名和错误的密码,验证是否登录失败并且提示信息正确; (4)输入错误的用户名和任意密码,验证是否登录失败并且提示信息正确; (5)用户名和密码两者之一为空,验证是否登录失败并且提示信息正确; (6)若启用了验证码功能,在用户名和密码都正确的情况下,输入正确的验证码,验证是否登录成功; (7)若启用了验证码功能,在用户名和密码都正确的情况下,输入错误的验证码,验证是否登录失败并且提示信息正确; 有经验 嗯,以上这些测试用例已经覆盖了主要的功能测试场景,但是若要做的更好,还可以对以上测试用例进行扩充,一个有经验的测试工程师还会考虑以下测试用例: (1)用户名和密码是否大小写敏感; (2)用户名和密码是否有字符长度和字符内容限制; (3)页面上的密码框是否加密显示; (4)后台系统创建的用户第一次登录成功后,是否提示记住密码; (5)忘记用户名和忘记密码的功能是否可用; (6)若登录功能需要验证码

web端功能测试总结(一)

佐手、 提交于 2019-12-23 04:46:43
一、功能测试 1.1链接测试 链接是web应用系统的一个很重要的特征,主要是用于页面之间切换跳转,指导用户去一些不知道地址的页面的主要手段,链接测试一般关注三点: 1)链接是否按照既定指示那样,确实链接到了该链接的界面 2)测试该链接所链接的页面是否真的存在 3)保证系统中没有单独存在的页面(即没有链接指向,只能通过正确的URL地址才能访问) PS:这里顺带说点关于协议的一些小知识,URL全称“统一资源定位符”,表示获取某一互联网资源的地址;而URI表示“统一资源标识符”,代表互联网上某一些资源 1.2表单测试 这个也可以理解为 数据落地 ;当用户在web应用系统上向服务器提交信息时,就需要使用表单操作,比如,用户注册,登录,信息变更等等;这种情况下,我们必须测试提交信息的完整性, 以检验 提交给服务器的数据的正确性, 当然,这涉及 到一些 常理性逻辑 ,比如:出生日期和职业,工作年限是否恰当,所在地省份城市区域间的匹配等,如果设定使用默认值,也需要测试。 1.3导航测试 作为测试,很多时候都要站在用户的角度去思考,那么,作为一个用户,当他访问一个web的网站或者系统时,会怎么去操作呢? 大部分用户都是目的驱动的,当他访问一个网站,会很快的浏览系统,找不到满足自己需求的信息时,会很快离开,很少有用户愿意花时间去熟悉系统的结构,因此,导航测试就显得很重要。 导航测试

非功能测试之性能测试基础

為{幸葍}努か 提交于 2019-12-23 03:59:01
说明:该篇博客是博主一字一码编写的,实属不易,请尊重原创,谢谢大家! 文章目录 一、性能测试的含义 1.什么是性能测试 2.什么时候进行性能测试 3.谁关注性能 二、性能测试术语 1.请求 2.响应 3.协议 4.响应时间 5.在线用户 6.并发用户 7.虚拟用户 8.吞吐量与吞吐率 9.每秒事务数(TPS,Transaction Per Second) 10.点击率(Hit Per Second) 11.思考时间(Think Time) 12.资源利用率 三、性能测试分类 1.负载测试(Load Testing) 2.压力测试(Stress Testing) 3.并发测试(Concurrency Testing) 4.容量测试(Volume Testing) 5.可靠性测试(Reliability Testing) 6.配置测试(Configuration Testing) 四、性能测试流程 1.设计阶段 2.构建阶段 3.执行阶段 4.分析、诊断和调节阶段 五、主流性能测试工具 一、性能测试的含义 1.什么是性能测试 测试软件的性能表现,考量软件运行的如何。 √ 一般关注时间/效率、资源占用等情况。 √ 既要马儿快点跑,又要马儿少吃草。 举例:QQ聊天 功能方面 功能缺陷:点击发送消息,信息没有发送过去 性能方面 时间/效率:点击发送消息,3分钟后对方才收到 资源占用

非功能测试之兼容性测试、文档测试和安装测试

余生长醉 提交于 2019-12-22 19:17:00
说明:该篇博客是博主一字一码编写的,实属不易,请尊重原创,谢谢大家! 文章目录 一、兼容性测试 1.兼容性测试的含义 2.案例 3.兼容性测试的前提 4.兼容性测试的测试点 二、文档测试 1.哪些文档需要测试 2.文档测试检查单 3.文档测试的测试点 3.1 Readme 文档 3.2 联机帮助 3.3 及时/即时联机帮助 3.4 用户手册 4.文档测试需要注意的问题 三、安装测试 1.安装测试的分类 2.安装测试注意事项 3.安装测试的测试用例 4.运行测试的测试用例 5.卸载测试的测试用例 6.加密测试 6.1 加密测试的内容 6.2 加密测试的测试用例 一、兼容性测试 1.兼容性测试的含义 兼容性测试验证软件与其所在的环境的依赖程度,包括对硬件的依赖程度,对平台的依赖程度、其他软件的依赖程度等。 2.案例 3.兼容性测试的前提 标准和规范是软件兼容性的保证 √ 高级标准 ✰ 产品遵守的规则 √ 低级标准 ✰ 文件格式和网络通信协议 4.兼容性测试的测试点 硬件兼容 √ 包括主板、处理器、内存、显卡、显示器、打印机等。 ✰ 如不同品牌和架构的计算机、不同频率或不同位数的 CPU、不同大小的内存、硬盘、不同带宽的网络等。 操作系统兼容 √ 包括操作系统类型、位数、补丁版本等。选择测试平台要考虑操作系统的流行程度、年份、类型、生产厂商等方面。 √ 不同操作系统如 Windows

非功能测试之界面测试和易用性测试

。_饼干妹妹 提交于 2019-12-22 18:47:42
说明:该篇博客是博主一字一码编写的,实属不易,请尊重原创,谢谢大家! 文章目录 一、界面测试 1.窗体界面测试 1.1 案例 1.2 窗体界面测试用例 2.控件界面测试 2.1 案例 2.2 控件界面测试用例 3.菜单界面测试 3.1 案例 3.2 菜单界面测试用例 4.特殊属性的界面测试 二、易用性测试 1.易用性测试的含义 2.易用性测试要点 3.案例 4.控件易用性测试用例 5.菜单易用性测试用例 6.快捷方式易用性测试用例 7.联机帮助易用性测试用例 8.辅助系统易用性测试用例 一、界面测试 1.窗体界面测试 1.1 案例 当点击窗体放大按钮后,出现如下图所见,功能聚集在左侧,而未均匀分布左右两侧,则表示这是一个缺陷 1.2 窗体界面测试用例 窗体大小 ——窗体大小要合适,使内部控件布局合理,不过于密集,也不过于空旷,合理的利用控件。 移动窗体 ——快速或慢速移动窗体,背景及窗体本身刷新必须正确。 缩放窗体 ——点击右上角最大化安钮,窗体被最大化,或者用鼠标直接拖动窗体边框,窗体也被放大。此时,内部控件没有相应放大。只放大窗体而忽略控件的缩放是错误的,窗体上的控件也应该随着窗体而缩放。在编程过程中,对于含有按钮的界面一般不应该支持缩放,右上角只有关闭功能。 显示分辨率 ——通常使用的显示分辨率包括 640x480 , 800x600 , 1024x768 ,

TDD测试驱动开发

五迷三道 提交于 2019-12-21 03:45:44
TDD(Test-Driven Development)是敏捷开发中的一项核心实践和技术,也是一种设计方法论,其基本思想是:在明确要开发某个功能后,在开发功能代码之前,先编写测试代码(UT),然后编写功能代码并用测试代码进行验证,如此循环直到完成全部功能的开发。 TDD:测试驱动开发的优点: 在任意一个开发节点都可以拿出一个可以使用,含少量的BUG 并具有一定的功能能够发布的产品。 TDD:测试驱动开发的缺点: 缺点:增加了代码工作量。测试代码几乎是系统代码的两倍或更多,但是同时节省了程序调试的时间以及挑错的时间。 https://blog.51cto.com/2681882/2120480 来源: CSDN 作者: 陕西冷娃2 链接: https://blog.csdn.net/u014545085/article/details/103604258