二.功能软件测试基础

目录

1.先做个小游戏 

2.什么是软件测试

3.什么是测试用例:

4.测试用例的设计方法

5.软件开发流程 

6.软件测试流程

7.测试六种模型:

7.软件测试方法:


1.先做个小游戏 

以上游戏我们会找到很多不同的地方,而这些不同就是我们软件中所说的bug

2.什么是软件测试

        就是一个找bug的,什么是bug?比如微信,有的时候微信频频闪退,或者逛PDD,商品价格是1元,实际确扣了你99,本身是99最后扣了1块钱,再或者你玩一款游戏,这个游戏上线之后再下线,装备丢了,你可以看到,这就是bug。软件测试是要避免这些bug出现,对用户造成损害,对用户造成影响,这是软件测试要做的事情。

        但大多数时候,测试需要参照物进行测试来找出不同,例如通过:测试用例,测试需求文档,接口测试文档作为参考去进行测试。

3.什么是测试用例:

        根据接口文档或者产品原型,需求文档作为参考进行测试点的编写。

例如:一个登录场景。产品需求设计说明:登录账号为手机号登录,用户密码为8位以上字母,数字,特殊字符进行组合。

那测试点有哪些:a.账号正确,密码错误的情况下;b.账号错误,密码正确的情况下;c.账号为手机号码且账号存在,密码正确时;d.账号非手机账号,密码错误时。等测试点;

以文档的形式去编写可能存在的一些测试点。

A.测试用例文档要素属性有哪些:

a.测试用例的编号:用来标识用例,且编号唯一。

b.用例功能模块:描述测试点属于哪一个功能模块下。功能可以理解成可点击的按钮;模块则是多个可点击的按钮或者菜单组成。(例如微信登录,可理解成登录功能。微信朋友圈可理解成,朋友圈功能或模块都可以)。

c.用例名称:简要说清楚,测试点;例如登录:(登录用户名不正确;用户名非手机号登录)

d.用例前置条件:前置条件可以理解成某些功能测试点需要在特定场景下才会出现;也可以理解测试点,需要提前假设一个条件才会出现。(例如:在淘宝购买东西,前提是要进行登录或前提银行卡有余额并且余额大于商品价格才能进行购买;拨打一个手机号,需要拨通的前提,当前环境有信号,手机卡有钱。)

e.操作步骤:执行测试点,需要做的操作步骤;例如:上面提到的功能登录。测试当用户名不正确,密码正确时;操作步骤:1.输入错误的用户名;2.输入正确的密码;3.点击登录,查看结果。

f.预期结果:产品原型给的结果,或者接口文档给的结果。

g.实际结果:执行用户操作后,系统反馈的结果。

h.执行人:编写测试用例的人员。

i.备注:需要备注说明的测试用例。

(实际操作,编写测试用例进行演示,百度,QQ)

4.测试用例的设计方法

a.等价类划分:又分无效等价类和有效等价类。无效等价类:指一系列无效的数据输入(错误的用户名,错误的密码,不符合规则的密码)有效等价类:指一些列有效数据的输入例如下图,满足11位数据且是13,14,15,18开头的11位数据则为有效等价类,其他则为无效等价类。

 b.边界值分析法:首先先了解什么是上点,什么是离点,什么是内点

上点:是指边界上的点,无论此时的域是开区间还是闭区间,开区间的话,上点就是在域外,闭区间的话,上点就是在域内。
离点:是指离上点最近的点,这里就跟是闭区间还是开区间就有关系了,如果是开区间,那么离点就在域内,如果是闭区间,那么离点就在域外。(开内闭外)    遵循的原则:开内闭外    开区间往中间找,闭区间往外找
内点:域内的任意点都是内点。(包含0,10的为闭区间,区间中不包含该数字为开区间)

0<=x<=10           左上点 0    左离点 -1    右离点  11  右上点 10   内点 5
 
0<x<10             左上点 0    左离点 1     右离点 9   右上点 10    内点 5
 
0<=x<10            左上点 0    左离点 -1    右离点 9   右上点 10    内点 5

假如输入用户名可以为一位且不能超过10位,那测试点必须包含离点,上点和一到两个内点即可,例如:当输入一位字符串时,输入为空时,输入10位时,输入11位时,输入5位时,输入6位时。

c.因果图:有一个处理单价为2.5元的盒装饮料的自动售货机软件。若投入2.5元硬币,按“可乐”、“啤酒”、或“奶茶”按钮,相应的饮料就送出来。若投入的是3元硬币,在送出饮料的同时退还5角硬币。

原因(输入):                  中间状态                 结果(输出)
投入2.5元硬币;               已投币/已按钮            退还5角硬币;
投入3元;                                            
按“可乐”按钮;                                         送出“可乐”饮料;
按“啤酒”按钮;                                         送出“啤酒”饮料;
按“奶茶”按钮。                                         送出“奶茶”饮料;

d.错误推测法:通常是一些经验老道的测试,会用到的用例设计方法,因为测试的系统多了,遇到某一个功能或者应用常见便能够总结出,一些异常的情况,例如:

测试手机终端的通话功能,可以设计各种通话失败的情况来补充测试用 例:

无SIM 卡插入时进行呼出(非紧急呼叫)

插入已欠费SIM卡进行呼出

射频器件损坏或无信号区域插入有效SIM卡呼出

网络正常,插入有效SIM卡,呼出无效号码(如1、888、333333、不输入任何号码等)

网络正常,插入有效SIM卡,使用“快速拨号”功能呼出设置无效号码的数字

e.判定表法:是指多个条件桩,相互组合后对应的用户操作与动作(动作桩)

需求:

验证”用户欠费或者关机,则不允许手机被叫“功能的测试

是否欠费
条件是否关机
操作是否允许手机被叫

需求:

  1. 输入手机号或者电子邮箱作为账户名
  2. 输入正确验证码
  • 两项验证成功,填写账户信息
  • 如果一项验证不正确(输入手机号或电子邮箱格式错误),报错L
  • 验证码输入错误,报错M

由上面的判定表可看出,第一条和第二条的情况不存在,再从结果来看,相同结果但是条件不同的情况不可简化,因此得到下面六条用例

编号模块用例标题优先级前提条件操作步骤预期结果实际结果
zc-01注册注册成功稳定的网络环境

1,输入手机号;

2,输入正确的验证码;

3,点击验证。

提示”验证成功“;

跳转填写账户信息界面。

zc-02注册注册失败稳定的网络环境

1,输入手机号;

2,输入错误的验证码。

3,点击验证。

提示”验证失败“。
zc-03注册注册成功稳定的网络环境

1,输入电子邮箱;

2,输入正确的验证码。

3,点击验证。

提示”验证成功“;

跳转填写账户信息界面。

zc-04注册注册失败稳定的网络环境

1,输入电子邮箱;

2,输入错误 的验证码。

3,点击验证。

提示”验证失败“。
zc-05注册注册失败稳定的网络环境

1,不输入手机号或电子邮箱;

2,输入正确的验证码。

3,点击验证。

提示”验证失败“。
zc-06注册注册失败稳定的网络环境

1,不输入手机号或电子邮箱;

2,输入错误的验证码。

3,点击验证。

提示”验证失败“。

 f.正交表法:

正交表Ln(m^k):
特点:均匀分散、整齐可比、高效、快速、经济.

n 正交表的行数,也就是需要测试的组合的次数;
k 正交表的列数,也就是控件的个数;
m是每个控件包含的取值个数;

L9 3^4

 g.场景分析法:通过模拟业务场景来对系统的功能点或业务流程的描述,从而提高测试效果的黑盒测试方法。

5.软件开发流程 

1.需求统计与分析-产生需求文档,产品原型。

2.需求评审。

3.编写测试用例,测试计划,项目计划等。

4.开发计划,接口文档设计,系统详细设计等。

5.软件研发编程。

6.软件测试,冒烟测试,系统测试,集成测试。

7.试运行,试运行报告,验收测试。

8.项目总结,测试报告。

9.项目上线。

6.软件测试流程

1.测试需求分析,制定测试计划

2.编写测试用例,评审测试用例

3.冒烟测试,集成测试,功能测试,回归测试,验收测试。

4.提交bug,跟进bug生命周期。编写测试报告。

5.进行版本迭代,发布。

7.测试六种模型:

a.瀑布模型:

特点:(1)是线性模型的一种,每一个阶段执行一次   (2)文档驱动

优点:(1)开发的各个阶段比较清晰,当前阶段完成后,只需关注后续阶段

缺点:(1)不响应需求的变化,(2)风险往往颜值后期才显露,失去及早纠正机会

b.快速原型模型:

解释:在开发知识系统之前,构造一个原型,在该原型的基础上,逐渐完成整个系统的开发工作

    特点:(1)快速构造软件模型。 (2)支持用户参与。

    优点:克服瀑布的缺点,减少由于软件需求不明确带来的项目开发 风险。

    缺点:不适合大型系统的开发(适合小型的,灵活性高的系统)

 

 c.螺旋模型:

特点:引进了风险分析活动

优点:螺旋模型很大程度上是一种风险驱动的方法体系

缺点:采用螺旋模型需要具有相当丰富的风险评估经验和专门知识

d.V型模型:

介绍:V模型是最具有代表意义的测试模型,最早是由Paul Rook在20世纪80年代后期提出,由英国国家计算机中心文献中发布,指在改进软件开发的效率和效果

V模型本身的软件开发中瀑布模型的变种,它反映了测试活动与分析和设计的关系

V模型标明了测试过程中本身存在的不同阶段,从左到右,描述开发过程中和测试过程间的阶段对应关系

优点:测试V模型既包含了底层测试又包含了高层测试;

缺点:当需求变更时将会导致返工量非常大,模型灵活比较低

e.双V型模型

介绍:测试伴随整个软件开发周期,并且测试的对象不仅仅是程序,需求和设计同样测试

优点:(1)强调测试办税着整个软件开发周期,而且测试的对象不仅仅是程序,还包括需求和设计(2)更早地介入测试,能尽早的发现缺陷进行修复

缺点:对测试技术要求高,事件起来困难

f.质量模型:

软件质量,就是软件与明确地和隐含地定义的需求相一致的程度

ISO 9126软件质量模型是评价软件质量的国际标准,这个模型是软件质量标准的核心,对大部分的软件,都可以考虑从这6个特性和27个子特性去测试,评价一个软件

7.软件测试方法:

1.黑盒测试:不考虑内容实现及代码,根据需求和功能进行测试。

2.白盒测试:根据代码的内部逻辑,按照代码的语句、分支、路径、条件进行测试。要会代码。

3.单元测试-集成测试:开发写好代码自测,自测完成后进行联调,单个接口功能联调结束后,进入集成测试。此阶段关注代码实现逻辑是否符合需求,代码逻辑是否抱错,发现问题及时修改。

4.系统测试-冒烟测试:P0级别的功能进行冒烟测试,冒烟测试主要关注主流程。测试人员进行系统测试,关注是否正确实现需求。

5.回归测试:每当软件经过了代码修复或者环境发生变化,都需要重新测试,一般是在测试最后阶段,经过多次回归后,才能上线。

6.性能测试:检查系统是否满足需求规格说明书中规定的性能。
如 接口支持的并发量、接口响应时间等。

7.可用性测试:对用户友好的特性进行测试,这是一种主观感受,取决于用户[使用者]或者客户。

8.安全测试:系统在应对非授权的内外部访问、或是故意破坏时的防护情况。

9.兼容性测试:软件在特殊的硬件、软件、操作系统、网络环境等环境下的表现。

10.验收测试(α测试-β测试)α测试:在开发一个应用软件即将完成时所进行的测试。此时还允许有较小的修改。[用户在测试环境测试]。

β测试:当开发和测试已基本完成,需要在正式发行之前最后寻找毛病而进行的测试。通常由最终用户或其他人进行这种测试,而不是由程序员和测试人员来进行。[用户在生产环境测试]。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值