测试(上篇)b
Posted 鸟随二月
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了测试(上篇)b相关的知识,希望对你有一定的参考价值。
入门
概念
验证软件满足用户的需求。
测试分类
分为:动态测试和静态测试
软件测试和研发的区别?
(1)~软件测试和调试的区别
目的不同:
软件测试是检查软件的质量(以需求为标准)
软件调试是开发人员为了检查程序是否实现了他(开发人员)想让程序实现的功能
人员不一样:
软件测试,黑盒测试工程师,白盒测试工程师,开发人员(单元测试,或者白盒测试)、用户
软件调试,开发人员
阶段不同:软件调试,只在开发阶段
软件开发的生命周期:
软件测试:贯穿到了整个软件开发的生命周期
其中软件生命周期:需求分析-计划-设计-开发-测试-运行
(2)难易程度,技能要求
开发广度小,专业度高( java工程师 java框架 增删改查)
测试广度大,专业度低
接口测试 postman soupui Charles
抓包fiddler Charles 测试的手段
模拟弱网工具(性能测试) jmeter
自动化测试 java Python ruby unittest TestNG安全测试 网络知识Linux tomacat 数据库
测试左右移
测试左移:需求前调研阶段和需求阶段,测试人员参加。
测试右移:产品上线后,系统监控,日志记录和分析。
概念
需求
软件开发中的需求:需求就是满足用户的期望或者合同规定的标准,规范,文档所需要的条件和权限。
bug
(1)当软件需求规格(软件需求)存在并且合理,如果软件功能和软件需求规格不相符合,我们就说是软件错误(BUG)
(2)当软件需求规格不存在的时候,用户需求存在并且软件功能和用户需求不相符,就是软件错误(BUG)。
测试用例
向被测试系统发起的一组集合,这组集合包括测试数据,测试步骤,测试平台,预期结果。
例子1
例子2
例子3
例子4
例子
一个测试人员所具备的素质
(1)软件测试这个岗位的兴趣
(2)有能力,编程能力,懂几门编程语言,沟通,团结协作(team work)
(3)责任感和承受一定的压力
思维方面’发散性思维,逆向思维
开发模型
瀑布模型
优点:各个阶段比较独立,看重需求分析和软件测试;
缺点:无法适应需求的变化;测试到编码后才介入,导致前期的缺陷无法及时发现。无法及时修正。适用的项目:适用于需求稳定的项目。
螺旋模型
适用的项目:前期需求不是很明确,并且有风险,项目比较庞大的系统开发;
优点:强调软件质量;每一次迭代进行严格的风险分析,提供讨论项目是否有必要进行下去的机会缺点:引入风险管理,会投入大量人力物力;
迭代增量模型
一个系统的四个功能,A模块、B模块、C模块、D模块,两周时间完成
迭代模型:第一周开发人员完成ABCD四个模块基础功能,第二周,在基础功能之上进行细化和完善;
增量模型:第一周,完成A模块,B模块,第二周完成C模块D模块。
迭代模型抗风险能力更强
敏捷模型
轻文档,轻流程,重目标,重质量(目标交付一个高质量可用的软件)
拥抱变化,可以适应需求的变化
scrum流程:1~4周10人以内
PO,product owner 产品经理,把客户的需求整理成user story,课表的代表方;
SM scrum master项目经理负责保证整个敏捷流程的顺利实施;
STscrum Team研发团队,目标是交付一个高质量可用的软件;
scrum流程
1,发布计划会议(PO负责讲解user story,根据user story的紧急程度排出本期要迭代的userstory,形成sprint backlog。)
2,迭代计划会议(细化user story ,分配任务,每个人需要完成什么任务以及完成的时间节点;)
3,开发过程中,每日站会(三件事,昨天做了什么,遇到什么困难,今天的计划;)
4,产品演示评审会(给用户演示完成的产品,用户会提出一定的意见,产品经理整理成新的user story 放到下一次的迭代当中;)
5,回顾会议(对本期迭代进行总结。)
软件测试v模型(瀑布模型的变种)
改进软件开发的效率和效果
优点:左边开发的每一个阶段和右边测试的每一个阶段一一对应,是右边测试每一个阶段的依据。
缺点:测试介入晚,前期的错误和风险到后期才发现,会失去及时就纠正的机会;不能适应需求变化的项目。
软件测试W模型
优点:测试阶段和开发阶段在两个独立的V模型里面,测试介入包比较早,在项目初期就介入,前期的风险可以及时被发现;
缺点:W模型每一个阶段仍然是一个串行的过程,不能适应需求变化的项目,所以无法应用到敏捷开发
基础
测试的生命周期
描述bug
bug的级别(简单的划分)
1.崩溃
系统运行阻断,严重的影响了开发人员和测试人员的工作,需要立马修复;如果出现一个线上bug的话,需要回退一个稳定的版本。
(2)严重
系统还可以运行,但是已经不稳定了,如果再运行下去,可能会产生严重的后果。比如视频画面失真。
(3)一般
系统可以稳定的运行,但是一些次要功能没有实现,可能会影响用户的体验。如查询功能有一个总是出现在分页中。
(4)次要(建议性)
没有严格体现在需求里面的;
影响用户的视觉体验,界面的文字提示内容,展示,图片的排版。要不要改和产品经理商量;
bug的生命周期
另外:测试人员提了一个BUG,开发人员已经修改了,但是测试人员测试的时候,发现这个BUG依然存在,有哪些原因?
1开发人员没修改好
2开发人员没有把代码更新到测试环境(没有提交代码)
3测试人员忘记拉取最新的代码到测试环境进行发布
测试时如何和开发人员沟通(遇到bug时)
(1)先检查自己的BUG描述是否清楚
(2)检查BUG的定级是否按照公司的标准来的
(3)站在用户的角度去说服开发
(4)不断提高自己的业务水平和技术水平
(5)和开发人员,产品经理开会商量BUG的解决方案
测试用例
好坏的判定
用例表达清楚,无二义性。。
用例可操作性强。
用例的输入与输出明确。一条用例只有一个预期结果。
用例的可维护性好。
用例对需求的覆盖率高,
暴露程序Bug的能力强力。
设计测试用例的方法
根据需求测试
先验证需求的合理性在进行设计
黑盒测试
等价类
等价类把输入(特殊情况下才考虑输出)划分成若干个等价类,从每一个等价类当中选一个测试用例进行测试,如果这个测试用例测试通过,那我们就说这个测试用例代表的等价类测试通过。
有效等价类:根据需求规格说明,有意义的输入的数据集合;
无效等价类:根据需求说明,不符合需求的
边界值
边界值:针对输入输出的边界进行测试用例的设计
因果图
用因果图法设计测试用例的步骤
(1)分析出所有的输入,输出
(2)找出输入输出之间的逻辑关系
(3)根据输入输出之间的关系画因果图
(4)根据因果图画判定表
(5)根据判定表设计测试用例
正交法
研究多因素多水平的一种实验〈(测试)方法。根据正交性,从输入组合当中选取最优的组合进行试验,分析结果,通过这些最优组合得出的试验结果来分析这个试验的结果。
因素:输入的变量
水平:变量的取值
正交表的构成:
列:因素数,变量的个数
水平数:每个变量的最大值的个数
行:L(正交表的行)=(水平数-1)*因素数+1
正交表的性质:
(1)每一列不同数据出现的次数一致
(2)任意两列不同数据的组合出现的次数一样
正交表设计测试用例的步骤:
1,确定所有的输入(变量)
2,确定每一个变量的取值的个数
3,确定因素数(正交表的列),水平数 正交表的行
4,根据正交表的性质,把变量的值映射到表中
5,写测试用例,正交表的每一行就是一个测试用例6,补充正交表中没有的但是你认为可能出现的测试用例
场景法
根据场景法设计测试用例:把场景中的每一个功能点提出来,考虑功能点可能的不同的情况,根据这些情况去设计测试用例
错误猜测法
根据测试人员的知识,经验,直觉去判断哪一个模块会出现问题,专门针对这个模块进行测试用例的编写。作为一种补充的设计测试用例的方法,
例子
题意:
以上是关于测试(上篇)b的主要内容,如果未能解决你的问题,请参考以下文章
Java盲点攻克「TestNG专题」摒弃JUnit单元测试,带你学会使用TestNG测试框架(上篇)
基于 BDD 理论的 Nebula 集成测试框架重构(上篇)