springboot项目怎么自测(怎么判断springboot项目启动成功)
811
2022-11-06
本文目录一览:
常见的开发模型:
V模型、瀑布模型、敏捷开发模型、W模型
软件生命周期:
1、问题的定义及规划
2、需求分析
3、软件设计(明确怎么做!)
4、软件编码
5、软件测试
6、运行维护
测试生命周期:
单元测试:一般是开发完成时
集成测试:单元测试之后,单元之间接口是否正确,数据是否正常传递。比如说注册和充值两个功能是否能够连通。
系统测试:根据测试用例,进行完整的系统测试
验收测试:用户对软件进行验收
软件测试阶段:
单元、集成、系统、验收(正式验收、Alpha测试,Beta测试)
软测方法:
白盒测试、黑盒测试、灰盒测试
软测类型:
功能、界面、安全、兼容性、易用性、性能、压力、负载、恢复测试等
其他测试分类:冒烟测试、回归测试、探索性测试
常用的开发的模型:V模型
软件测试的分类
什么是黑盒测试?
黑盒测试也称功能测试,它是通过测试来检测每个功能是否都能正常使用。不考虑内部结构,在程序接口进行测试。
Alpha、Beta测试的区别?
Alpha测试:前期的用户测试,公司内部在模拟实际操作环境下进行的一种验收测试。
Beta测试:后期的用户测试,此时已经通过内部测试,即将真实发布,是软件的在一个或者多个用户的实际使用环境下进行的测试
冒烟测试和回归测试区别?
冒烟测试:在新版本出来的时候,将软件的全部功能过一遍,功能可以正常进行不会影响测试进度,这个版本就可以真正测试了
回归测试:对以前版本中发现的bug在新的版本中验证是否存在且是否引发新的bug
1、边界值:
选取等于、刚刚大于、刚刚小于边界的值作为测试数据
基本思想是在最小值、略高于最小值、正常值、略低于最大值和最大值等处取值
2、等价类划分:
等价类划分就是把程序的输入域划分成若干部分,然后从每部分选取少量的具有代表性的数据作为测试用例。
无效等价类:不合理的、无意义的输入数据结婚,验证程序处理意外数据的能力
有效等价类:有意义的输入数据的集合,检验程序是否实现了规格说明总的功能和性能
等价类划分方法:按区间划分、数值划分、数值集合划分、限制条件和规则划分
3、错误推算法:
进行错误的操作,验证程序是否对出错的场景和情况有些应对能力,来选择测试用例数据
4、因果法/判定表法:
将判定表的每一列作为依据,设计测试用例。检查输入条件的各种组合情况
5、场景法:
通过描述的业务流程,设计用例来列出不同业务场景,作为测试用例的测试数据
基本流:主要是功能的正常操作流程
分支流:需要程序做非法判断处理的
* 测试用例方法的选择*(划重点)
1、进行等价类划分,主要是输入条件的划分,这是提高测试效率最有效的方法
在任何情况下都必须使用边界值分析法,这种方法设计出测试用例发现程序错误的能力最强
2、用错误推测法追加测试用例
3、如果程序说明中含有输入组合情况,则一开始就用判定表法(判定表法很少用到)
4、如果还没有达到覆盖标准,应当再补充足够的测试用例(场景法)
1、列出需求文档中的可测试性的原始需求
2、对每一条需求进行细化分解,形成可测试的测试点
3、针对测试点确定执行适合的测试类型
4、建立测试需求分析矩阵,对测试需求进行管理
软件测试需求的 重点 是“ 测什么 ”。
测试需求分析的目的:获取测试点,根据测试点编写用例
按钮指示灯:按压上下按钮指示灯是否亮
电梯门开关:按压上下按钮电梯门在当前楼层是否能打开
按向上按钮:电梯是否关门且向上面楼层方向走
按向下按钮:电梯是否关门且向下面楼层方向走
当电梯门没有关上:按开电梯门按钮,门是否开
当电梯门没有关上:按关闭电梯门按钮,门是否关闭
电梯内:按各个楼层,对应的指示灯是否亮
电梯内报警装置:报警装置是否正常
电梯内通话设备:按通话按钮能否接通外界
电梯内灯光:电梯内灯光是否亮,是否有无损坏
电梯内通风:是否通风
按各个楼层按钮:是否到当前楼层停止并开门
当超过最高重量:电梯是否报警打开电梯门,直到小于最高承重
电梯当前楼层是否和电梯内显示屏楼层一直
显示屏内是否有当前楼层,当前向上或者向下箭头,且与当前操作一致
电梯门超过规定时间未关门是否会有报警提示
上下按钮是否控制一个电梯或者两个电梯的开关门,如果控制两个电梯,按向上或者向下按钮,另一个电梯是否受控制
电梯是否分单双层?
在单层电梯情况下,按双层电梯,对应双层电梯数字是否亮,是否会到这一层
在双层电梯情况下,按单层电梯,对应单层电梯数字是否亮,是否会到这一层
电梯限层:按超过限层的电梯层数,数字是否亮,是否会到这一层
双击某楼层:是否会取消这个楼层且楼层灯灭
假如我在9楼,有人先按12楼,有人后按1楼,此时电梯是否先上12楼,再下1楼?
电梯感应:有人或者物体在门中间卡着,门是否会关闭,是否会有警铃提示?
电梯到达指定楼层是否有声音提示?
电梯是否刷卡:刷卡的电梯,如果没有刷卡是否能选楼层
维修开关:电梯内是否有维修开关
测试用例:指导性执行测试,帮助证明软件功能或发现软件缺陷的一种说明。每一个测试点的数据设计和步骤设计。
测试用例的重要性:
(1)、便于测试计划的实施
一般主要适用于集成测试、系统测试、回归测试。根据用例知道自己的进度
(2)、规划测试数据的准备
比如测注册,要提前准备好手机号、身份证号、不重复的用户名,邮箱等
(3)、编写测试脚本的根本
自动测试的中心任务是编写测试脚本。测试脚本就是以测试用例为基础。
(4)、评估测试结果的基准
通过测试用例的覆盖性和错误率,可以判断测试的结果,是否能发布
(5)、分析缺陷标准
收集缺陷,对比测试用例。分析是漏测还是缺陷复现。反应了测试的不完善,应立即补充相应的测试用例
*测试标题如何写:测试点,对测试点进行细化分解。比如:输入正确用户名、密码,能否正常登陆。
测试用例编写格式注意:
(1)、测试标题一定要描述测试点(验证什么写什么),简洁明了,不存在重复
(2)、测试步骤要有指导性的意义,涉及测试数据输入最好包含具体的测试数据
(3)、预期结果是唯一的,不能出现“发送成功或失败”
如何编写测试用例?
用例包含:用例编号、功能模块、用例标题、前提条件、操作步骤、期望结果(含判断标准)、实际结果、备注
编写方式:按照功能+业务逻辑
(1)、首先保证单个功能是正常的
(2)、然后功能联合起来的业务逻辑是对的
比如:登录、充值、提现功能都是好的。业务逻辑,就是把所有的功能联合起来走一遍,看是否是好的
用例覆盖:包含正面和反面的用例
(1)、正面用例:根据功能模块划分,针对要测试的功能模块,所有正常输入数据的测试用例都写出来
(2)、反面用例:例如登录失败等,输入非法数据,违反唯一约束等等
1、用例覆盖程度 毫无疑问,这一点应该是最重要的,无需多说,覆盖率最大化是一套测试用例的最重要评价标准,如果漏测就杯具了。2、用例是否已经达到工作量最小化 在满足用例覆盖程度最大化的前提下,应该尽量减小执行用例所需要的工作量。
测试用例,是一份关于具体测试步骤的文档,它描述了测试的输入参数、条件及配置、预期的输出结果等,以判断被测软件的工作是否正常。
设计、书写和执行测试案例是测试活动中重要的组成部分,测试案例通常由测试案例管理系统或工具进行管理。
测试用例的重要性是毋庸置疑的,它是软件测试全部过程的核心,是测试执行环节的基本依据。测试用例编写应该遵循的原则:
特性:
一个好的测试用例应该具有较高的发现某个尚未发现的错误的可能性,而一个成功的测试案例能够发现某个尚未发现的错误,通常一个好的测试案例有以下特性:
测试用例不可能设计得天衣无缝,也不可能完全满足软件需求的覆盖率,测试执行过程里肯定会发现有些测试路径或数据在用例里没有体现,那么事后该将其补充到用例库里,以方便他人和后续版本的测试。
测试用例的信息有很多,可以根据实际的情况进行增删,一般来说一个优秀的测试用例应该包含以下信息:
这些信息建议可以由测试案例自动生成。
测试级别进行说明:
6.测试类型:功能测试、边界测试、异常测试、性能测试、压力测试、兼容测试、安全测试、恢复测试、安装测试、界面测试、启动/停止 测试、文档测试、配置测试、可靠性测试、易用性测试、多语言测试。
7.预置条件:对测试的特殊条件或配置进行说明
8.测试步骤:详细描述测试过程,案例的操作步骤建议少于15个。
9.预期结果:预期的测试结果
例如:假设目前测试中国移动互联短信网关是否能正确发送短信给中国联通互联网关,测试用例的设计如下:
(1)测试用例ID:TC000001
(2)测试用例名称:中国移动全球通手机用户成功发送短信给中国联通手机用户
(3)测试功能点:中国移动全球通手机用户成功短信给中国联通手机用户,中国联通网关返回成功的状态报告
(4)测试目的:
A、中国移动互联短信网关能否正确处理全球通用户发送给中国联通用户的短信;
B、中国移动互联短信网关能否正确处理中国联通互联短信网关返回成功的状态报告的情况。
(5)测试级别:基本功能测试
(6)测试类型:功能测试
(7)预置条件:各网关实体按照组网图中的关系连接好,各实体之间的连接和通信正常。
(8)测试步骤:
A、中国移动全球通手机用户(13901000001)给中国联通手机用户(13001000001)发送MO短信,内容为“测试”,目的号码填为中国联通手机号码;
B、中国联通互联短信网关把短信下发给中国联通用户成功后,给中国移动互联短信网关返回一个标识成功的状态报告。
(9)预期结果:
A、中国联通手机用户(13001000001)接收到了短信,内容为“测试”,源号码为中国移动全球通的用户号码(13901000001);
B、在中国移动互联短信网关上产生SMO话单,其中“短消息发送状态”填0(表示成功),“源手机号码”13001000001,“目的手机号码”为13001000001。
下面是一个完整的测试用例的模版:
对一个全新的产品来说,首先需要了解的是产品需求文档和产品模块之间的关系。然后需要从需求文档中书写与所有需求相对应的主路径测试案例和烟雾测试案例, 这个时候也同时会包括一定的基本路径测试案例甚至是详细测试案例。在这个时候,因为对产品没有直接的使用感受,书写测试案例要考虑面广而不要太过精细。继 续阅读产品功能定义文档,将所有的功能定义直接对应写相关的测试案例,这个时候,最好能够对程序的本身有一定的接触,加深对程序的了解,以便写出更好,更 全面的测试案例。最后,在实际测试中,还需要不断扩充,修改以前的测试案例,得到完整的基本功能测试案例和详细测试案例。如果对于一个已有一定或大部分案 例的产品来说,不管测试者是否本身熟悉这个产品,其主要的任务就是阅读,检查需求及相关的变更,然后对原有的案例进行理解,扩充和修改。这就是案例的重用 /复用。设计测试案例的时候,需要有清晰的测试思路,对要测试什么,按照什么顺序测试,覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技 术和流程,而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。
测试用例设计一般包括以下几个步骤:
1、测试需求分析从软件需求文档中,找出待测试软件/模块的需求,通过自己的分析、理解,整理成为测试需求,清楚被测试对象具有哪些功能。测试需求的特点是:包含软件需求,具有可测试性。
测试需求应该在软件需求基础上进行归纳、分类或细分,方便测试用例设计。测试用例中的测试集与测试需求的关系是多对一的关系,即一个或多个测试用例集对应一个测试需求。
2、业务流程分析软件测试,不单纯是基于功能的黑盒测试,还需要对软件的内部处理逻辑进行测试。为了不遗漏测试点,需要清楚的了解软件产品的业务流程。建 议在做复杂的测试用例设计前,先画出软件的业务流程。如果设计文档中已经有业务流程设计,可以从测试角度对现有流程进行补充。如果无法从设计中得到业务流 程,测试工程师应通过阅读设计文档,与开发人员交流,最终画出业务流程图。业务流程图可以帮助理解软件的处理逻辑和数据流向,从而指导测试用例的设计。
从业务流程上,应得到以下信息:
A、主流程是什么
B、条件备选流程是什么
C、数据流向是什么
D、关键的判断条件是什么
3、测试用例设计
完成了测试需求分析和软件流程分析后,开始着手设计测试用例。测试用例设计的类型包括功能测试,边
界测试,异常测试,性能测试,压力测试等。在用例设计中,除了功能测试用例外,应尽量考虑边界、异
常、性能的情况,以便发现更多的隐藏问题。
黑盒测试的测试用例设计方法有:等价类划分、边界值划分、因果图分析和错误猜测,白盒测试的测试用
例设计方法有:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。在这里主要讨论黑盒测
试。在设计测试用例的时候可以使用软件测试用例设计方法,结合前面的需求分析和软件流程分析进行设
计:
功能测试:测试某个功能是否满足需求的定义,功能是否正确,完备。
适合的技术:由业务需求和设计说明导出的功能测试、等价类划分
边界测试:对某个功能的边界情况进行测试。
适合的技术:边界值划分
异常测试:对某些功能来说,其边界情况无法简单的了解或某些操作不完全是正确的但又是可能发生的,
类似这样的情况需要书写相关的异常测试。
适合的技术:由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值分析、内部边界值测试、
性能测试:检查系统是否满足在需求中所规定达到的性能,性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置,系统资源使用状况;外部因素包括响应时间,吞吐量等。
适合的技术:业务需求和设计说明导出的测试
压力测试:压力测试又称强度测试,主要是检查系统运行环境在极限情况下软件运行的能力,比如说给一个相当大的负荷或网络流量给应用软件兼容测试:测试软件产品在不同的平台,不同的工具,相同工具的不同版本下功能的兼容性。
4、测试用例评审
测试用例设计完成后,为了确认测试过程和方法是否正确,是否有遗漏的测试点,需要进行测试用例的评审。
测试用例评审一般是由测试leader安排,参加的人员包括:测试用例设计者、测试leader、项目经理、开发工程师、其它相关开发测试工程师。测试用例评审完毕,测试工程师根据评审结果,对测试用例进行修改,并记录修改日志。
5、测试用例更新完善
测试用例编写完成之后需要不断完善,软件产品新增功能或更新需求后,测试用例必须配套修改更新;在测试过程中发现设计测试用例时考虑不周,需要对测试用例 进行修改完善;在软件交付使用后客户反馈的软件缺陷,而缺陷又是因测试用例存在漏洞造成,也需要对测试用例进行完善。一般小的修改完善可在原测试用例文档 上修改,但文档要有更改记录。软件的版本升级更新,测试用例一般也应随之编制升级更新版本。测试用例是“活”的,在软件的生命周期中不断更新与完善。
一、等价类划分法
所谓「等价」,就是具有相同属性或者方法的集合,这个集合中某个个体所表现的特征与其他个体完全一致。
由此可知,等价类划分就是将所有可能的输入数据,划分成若干个等价类,然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类,分为有效等价类和无效等价类。
例如,规定的用户名长度区间为4~8个字,那么它的有效等价类是用户名长度在[4,8],无效等价类为用户名长度大于8位,或用户名长度小于4位。
二、边界值
测试经验告诉我们,在测试有时会涉及到大量的数据,遍历所有数据会使测试效率低下,如果是手工执行,更加难以覆盖所有数据。这时更有效率的做法是,先划分等价类,再从等价类中选择部分参数测试,边界值是等价类所有可选参数中最容易出问题的地方,所以我们一般会选择边界值作为测试的重点,边界值法的应用步骤如下:
1.先根据等价类法划分有效等价类和无效等价类,确定上点、离点及内点。上点是边界上的点,离点是离上点最近的点,内点则是边界有效范围内的任意一点。同样以用户名长度为4~8位为例,4和8为上点,3和9为离点,6则为内点。
2.设计一个新的测试用例,使其尽可能地覆盖所有尚未覆盖的有效等价类,直到所有有效等价类完全覆盖。
3.设计一个新的测试用例,使其仅覆盖一个无效等价类,直到所有无效等价类都被覆盖。
三、判定表法
判定表又称策略表、决策表,能表示输入条件的组合,以及与每一输入组合对应的动作组合。判定表法适合逻辑判断比较复杂的场景,通过穷举条件获得结果,对结果再进行优化合并,具体又明确地表达复杂地逻辑关系和多种条件组合情况。
判定表主要由条件桩和动作桩两部分组成。条件桩是功能要满足地所有条件,动作桩则是所有可能的操作以及产生的结果。
判定表能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。其缺点是判定表的建立过程较烦杂,当条件过多时,需要分析的逻辑组合呈2的倍数增长。测试工程师可根据实际情况与等价类划分法、边界值法结合使用。
四、正交试验法
正交试验法是研究多因素、多水平组合的一种实验法,它是利用正交表来对实验进行设计,通过少数的实验替代全面实验。正交表中所有参与试验的、影响试验结果的条件成为因子,影响试验因子的取值或输入的成为水平。
在设计测试用例时,采用正交试验法能够有效地、合理地减少测试的工作量与和成本。正交试验的一般流程包括以下几个步骤:
1)分析测试需求,获取因子和水平
2)根据因子和水平选择合适的正交表
3)替换正交表中的因子和水平,获取试验次数
4)根据经验或者其他因素补充试验次数
5)细化输出获得测试用例
以上是一些常见的测试用例设计方法,希望能够解答你的问题。
一、等价类划分
定义: 把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,用少量代表性的测试数据,取得较好的测试结果。等价类划分可有两种不同的情况:有效等价类和无效等价类。
1)确定等价类
有效等价类: 满足输入条件的
无效等价类: 不能满足输入条件的 超出范围的数值
空值
特殊字符
有空格(前、中、后)
2)生成测试用例
每个等价类编写一个测试用例;
设计一条测试用例,尽可能多地覆盖所有还未被覆盖的有效等价类;
设计一条测试用例,覆盖一条还未被覆盖到的无效等价类。
等价类划分的六大原则:
1)输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。
例如:手机号码由11位数字组成
有效:11位符合电话号码规则的数字
无效:1、小于11位数字;2、大于11位数字
2)在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可以确立一个有效等价类和一个无效等价类。
3)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。布尔量是一个二值枚举类型,一个布尔量具有两种状态:true和false
4)在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。
例如:
输入条件说明输入为:中文、英文、数字三种之一,则分别取这三种值作为三个有效等价类,另外把这三种字符以外的任何字符作为无效等价类
5)在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)
例如:输入条件说明每个学生可选修1~3门课程
有效:选修1~3门课程
无效:1、未选修课程
2、选修课程超过3门
6)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。
等价类划分法要点:长度、类型、字母、汉字、特殊字符、空、空格
二、边界值分析法
边界值分析方法是对等价类划分方法的补充。
使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是着重测试边界的情况。选取正好等于,刚刚大于或刚刚小于边界值的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。
1)如果输入条件规定了一个输入值范围,那么应针对范围的边界设计测试用例,针对刚刚越界的情况设计无效输入测试用例;
比如:需求规定输入的数字在0~100范围内,此时测试数据应该有一下几类:
a.刚刚等于边界:0、100;
b.刚刚超出边界范围:-1、101:;
c.刚刚在范围内:1、99
2)如果输入条件规定了输入值的数量,那么应针对最小数量输入值、最大数量输入值,以及比最小数量少一个、比最大数量多一个的情况设计测试用例;
例1:输入手机号码有:
a 输入11位合法数字;b 输入10 位合法数字;c 输入12位合法数字
例2:输入6~8位数字密码:
a 输入6位数字;b 输入8位数字c 输入5位数字;d 输入9位数字
3)如果程序输入或输出是一个有序序列,则应该特别注意该序列的第一个和最后一个元素。
三、错误推测法
错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。需要多实践,且在实践时多积累常见问题。
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例-例如, 在单元测试时曾列出的许多在模块中常见的错误-以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行-这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。
四、因果图法
因果图法适用于描述对于多种输入条件组合的测试方法。(有多步输入操作)
根据输入条件的组合、约束条件和输出条件的因果关系,分析输入条件的各种组合情况,从而设计测试用例的方法,它适用于检查程序输入条件涉及的各种组合情况。
例题:有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。若投入1元5角硬币,按下“可乐”、“雪碧”、“红茶”按钮,相应的饮料就送出来。若投入的是两元硬币,在送出饮料的同时退还5角硬币。
分析:
输入条件:a 投入1元5角硬币 b 投入2元硬币
1 按“可乐”按钮 2 按“雪碧”按钮 3 按“红茶”按钮
中间状态:1 已投币 2 已按按钮
输出结果:A 送出可乐 B 送出雪碧 C 送出红茶 D 退还5角硬币
测试用例:
1)投币1元5角,按“可乐”按钮,送出可乐
2)投币1元5角,按“雪碧”按钮,送出雪碧
3)投币1元5角,按“红茶”按钮,送出红茶
4)投币2元,按“可乐”按钮,送出可乐,退5角硬币
5)投币2元,按“雪碧”按钮,送出雪碧,退5角硬币
6)投币2元,按“红茶”按钮,送出红茶,退5角硬币
输入组合:投硬币+按按钮
结果组合:送出饮料+退钱
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~