软件功能测试

本文详细介绍了软件功能测试,包括测试的目的、原则和基本方法。着重讲解了等价类、判定表、因果图和正交方法在设计测试用例中的应用,旨在帮助测试人员高效地找出软件潜在问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1,软件测试的目的和原则是为了找到软件/网站存在的问题,并且通过提前找到软件的问题,可以降低商业风险

2,软件测试的定义是通过人工或者自动化的方式对软件系统进行测试,通过测试找到预期结果和实际结果的差异

3,软件测试的基本原则是  1;所有的软件都是有问题的,不能证明不存在。  2,不能进行穷举测试,应该进行分类测试。3,测试工作应该尽早介入,可以降低修复成本。4,缺陷聚集原则,二八法则。5,依赖测试环境

程序的架构: B/S C/S
B/S 架构: Broswer/Server ,通过浏览器访问服务
C/S 架构: Client/Server ,通过客户端程序访问服务
测试 B/S 架构准备三款浏览器:谷歌、火狐、 IE 【苹果、欧鹏、 QQ 360 、搜狗】
测试 C/S架构准备:
6,杀虫剂现象, 测试人员在经过一段时间后会进入自己的固有的思维意识,很难在测试出其他的 bug ,这个时候可 以进行交叉测试,就是交互测试人员。
7,不存在缺陷谬论
       软件开发模型
软件的生命周期就是软件开发模型
软件测试与软件的开发者模式有着紧密的联系,作为一个测试人员。应该充分理解软件的开发模式,以便找准自己在其中的位置,从而发挥自身的价值。
在软件开发的几十年的实践中,人们总结了很多软件开发模型用来描述和表示一个复杂的开发过程,软件开发有三种模式:
         瀑布模型
         快速原型模型
         螺旋模型
瀑布模型

首先对项目进行可行性的研究,通过可行性的研究可以判断这个项目是否挣钱
调研完成后会得到一个可行性调研报告。
这个工作是有项目负责人来完成
2. 需求分析:
调研判断项目没问题以后,就可以进行需求分析。
这个工作是又项目经理完成。
最终会得到一个需求规格说明书。规格书中仅仅是需求大体说明。
第二个阶段:项目开发阶段
1. 概要设计:
就是将需求规格书中的内容落地。
概要设计完成后,会得概要设计文档。
这个是由经验丰富的前端和的后端程序员。
概要设计文档中会将整个项目分成若干个功能模块,而且会明确说明每个模块中的功能。
2. 详细设计:
在详细设计中,明确指定了模块具体实现的细节。
整个工作由一线程序员来完成。
最终会得到一个详细 设计文档。
3. 编码:
其实就是程序员写代码。
4. 软件测试:
测试软件是否可以正常运行,是否达到了预期效果,最终会得到测试报告。
第三个阶段:项目运维阶段
1. 上线,用才能访问
瀑布模型的特点
是以文档驱动,后面所有的工作都是基于前面的文档的内容。
每个阶段执行一次,而且是线性依次进行的
开发模式中,瀑布模型是非常重要的一种
瀑布模型的优点
各个阶段非常清晰
每个人只需要关注自己的阶段
瀑布模型的缺点
下面的阶段是依赖上面阶段的分析结果的,一旦上面出现错误,那么下面全部都错了
整个流程过分依赖需求分析结果,这种模式不能适应变化频繁的项目
这种模式设传统项目和行业:银行、保险、建筑
快速原型模型
一个项目在很短的时间就有个版本上线,这个版本功能不全而且有bug。在后续版本中陆续修复bug,并逐渐完善功能。
特点:
快速上线
支持用户参与
优点:
克服了瀑布模型的缺点,减少中间环境,可以及早发现问题并进行修复
缺点:
仅仅适合中小型项目,不适合大型项目。
测试模型:所谓的模型就是这个行业的人总结出来的测试经验。
第一种: V 模型
这种模型其实就是在前面瀑布模型的基础上进行测试的
这种模型其实也是瀑布模型的变种
根据测试阶段不同,测试也同样分成四个不同的阶段
V 型的流程
用户需求 => 需求分析 => 概要设计 => 详细设计 => 编码 => 单元测试 => 集成测试 => 系统测试
=> 验收测试
优点:
整个流程比较清晰,即包含了底层测试,也包含了对高层进行测试
缺点:
这个本质上还是瀑布模型,因此具有瀑布模型的缺点
第二种: W( V) 模型
这种模式主要是为了解决 V 型模型存在的问题,解决思路就是测试前移
W 型比 V 型多的部分
集成:每个程序员将自己负责的功能模块合并到一起
实施:将 开发好的软件安装到客户的服务器上
交付:教给用户如何使用软件
静态和动态测试
W 模型中,对各种的文档进行测试,都是静态测试
对程序进行测试,就是动态测试
总结: W 模型中的流程
开发 V :用户需求 => 需求分析 => 概要设计 => 详细设计 => 编码 => 集成 => 实施 => 交付
测试 V :验收测试设计 => 系统测试设计 => 集成测试设计 => 单元测试设计 => 单元测试 => 集成测试 =>
系统测试 => 验收测试
优点:
测试工作前移,可以今早发现存在的问题
缺点:
对技术和管理能力要求较高
质量体系: ISO 9126
六大特性
功能性
可靠性
易用性
效率
维护性
可移植性
第一种分类方法:按照阶段分类
单元测试
模块:程序的最小单位就是模块,比如用户登录模块、购物车模块
单元测试:就是检测这个模块是否满足测试用例的要求,仅仅是测试一个单独的模块是否能
正常运行
集成测试
集成测试又称为 组装测试
在单元测试完成以后,就是表示每个单独的模块已经正常
集成测试,就是将多个模块组合起来进行测试
系统测试
在集成测试完成以后,才能进行系统测试
系统测试,将软件作为一个整体来测试,测试的依据是软件需求说明书【就是检查软件是否
达到了当初想要的样子】
验收测试
主要是检查软件是否满足客户的要求,对软件做最后的测试
验收测试分为几个小类
α 测试【 Alpha 】:阿尔法测试的软件版本内存版本,软件 bug 较多,一般不让用户直接
使用,而是公司内部交流使用。
β 测试【 Beta 】:贝塔测试就是软件的公测版本,目的就是让更多的用户通过使用软件
来发现更多的问题。
γ 测试【 Gamma 】:伽马测试就是软件的正式候选版,这个版本和用户最后使用的正式
版几乎完全一致。
第二种分类方法:按是否查看源码分
白盒测试 不去执行程序,而是去直接读取程序的代码
黑盒测试:
又称之为数据驱动测试
这种测试就是直接使用软件,完全不考虑程序内部结构和代码
例如:输入账号、密码,一点就能登录成功,就表示测试通过
灰盒测试
即要去读程序的代码
也要去执行程序
既要做黑盒的工作,也要做白盒的工作
第三种分类方法:按照是否运行程序划分
静态测试
动态测试
第四种分类方法:是否自动运行
人工测试:所有的测试工作,由测试人员手动点击完成
自动化测试:通过 python 开发自动化工具,用工具完成测试工作
第五种分类方法;其他分类
冒烟测试
测试软件基础功能是否正常
回归测试
在测试工作种,一旦发现了 bug ,需要将这个 bug 提交给开发,开发修复完成后,需要重新进
行测试
测试人员必须对哪些曾经发生过的 bug 再次进行测试
随机测试
虽然叫做随机测试,但是不是真的随机
这里的随机其实是重复测试,包括测试之前的测试用例种没有涵盖的部分
探索测试
这个测试不是必要
  软件缺陷
缺陷不等于 bug
bug 仅仅是缺陷中的很小的一个部分而已
什么是缺陷:只要让测试人员感觉不爽,那么这个就是缺陷
软件缺陷判定标准
1. 软件未能达到需求规格书中的要求
2. 软件的功能超出规格书中的要求
3. 软件出现了规格书中明确指定不能出错的地方
4. 软件出现了规格书中未明确指定,但是不应该出现的错误 软件缺陷产生的原因【缺陷只能减少、不能完全避免】
1. 对于需求文档等文等文件解释、理解错误【需求说明会】
2. 设计文档本身有错误
3. 程序代码错误
4. 硬件和软件系统有错
软件缺陷的类型
1. 功能错误:软件没有达到需求文档的功能要求,或者功能异常
2. 界面错误:软件功能正常,但是界面不好看或者未达到规格说明中的要求
3. 兼容性错误:软件和系统中的其他的程序冲突,导致软件无法运行
4. 易用性错误:软件用起来不好用
5. 改进建议:改了更好,不改也没事


   软件测试的方法

测试用例:
将要进行的测试工作,具体化,并且记录到一个文件中,一般情况下是一个excel【表格】
在测试用例中,明确的指定到了每一步做什么操作,希望得到什么结果。
测试工作:
等程,序员完成代码,此时就可以进行前期准备工作,就是编写测试用例,将需要测试的每一项都填写到表格中
当程序员完成代码,此时就可以开始进行测试,也就是根据表格中的内容一项一项的进行测试
测试用例的基本构成
ID模块优先级用例标题预置条件测试步骤测试数据预期结果
JD-登录-001登录P1输入正确账号和密码,登录成功。网络正常
已注册
1.打开浏览器,输入商城的登录地址URL
2.光标定位到用户名输入框,输入正确的用户名
3.光标定位到密码输入框,输入正确的密码
4.点击【登录】按钮
用户名:tom
密码:123456
登录成功,直接跳转商城页面。
第一部分:测试用例编号:
编号必须唯一
编号的构成可以写成:项目名-模块名-编号
例如:测试网站登录模块,而且是第三条用例,编号可以这么写: web-login-03
第二部分:模块名
第三部分:优先级
用于测试正常的功能用例,优先级要更高一些
一般是用 P1 P2 P3 来表示优先级
数字越小,优先级越高 第四部分:用例标题
在用例标题中,需要说明这条测试用例的功能以及预期出现的结果
第五部分:测试步骤
这个是指定这个条测试用例如何操作和执行
第六部分:预置条件
第七部分:测试数据
在进行测试的时候,输入什么数进行测试
这些数据既有满足条件的数据,也有不满足条件的数据
第八部分:预期结果
这条用例希望得到的结果
2.2 等价类方法
设计测试用例的方法很多
穷举测试
将所有可能的数据都测试一遍
但是实际上,这种方法不可行
等价类:
分析测试的数据,找出其中的规律,然后从规律中找出有特点的数字进行测试就可以了
通过划分等价类,可以避免进行穷举测试
等价类的种类
有效等价类:
满足条件的数据,就是属于有效等价类
例如:找 6-10 位长度自然数: 123456
无效等价类:
不满足条件的数据,就是属于无效等价类
例如:找 6-10 位长度自然数: 12345 12345a
用等价类方法设计测试用例步骤
第一步:分析需求
通过分析需求,判断项目需要达到什么效果
第二步:划分等价类【找到有效 / 无效的数据】
案例:找 6-10 位长度自然数
有效等价类:比较好找, 123456 1234567
无效等价类:相对复杂,可以从以下几点来思考
数据长度不符合:过长、过短
数据内容不符合
数据是否为空
数据是否重复

第三步:结合等价类设计测试用例

有几条等价类,就根据等价类设测试机用例
等价类的使用场景
搜索框
登录框
注册页面

案例 2 :登录 qq 邮箱
要求用户输入账号和密码
邮箱的名字: 6-20 位字符,支持数字、字母、下划线,但是名字不能都是下划线
邮箱的密码: 6-10 位,

2.3 边界值方法
两位数加法器:
计算的范围: -99 ~ 99
计算的方法:加法
在日常的测试工作,经常发现,在数据的 临界值位置 是经常出现 bug 的,因此这种位置就应该作为我们
重点的测试对象
边界值:
有效等价类和无效等价类的边界
这也是一种黑盒测试方法
边界值的三个概念:
上点:边界值上面的这个点,就是上点
内点:有效等价类中的任意一个点
离点:边界值相邻的两个点

数学表示方法
[ 大于等于
] 小于等于
( 大于 用数学表达是表示
数学表示
上点
内点
离点
大于等于 6 ,小于等于 12
[6 , 12]
6 12
8
5 7 11 13
) 小于
边界值的使用场景
项目中出现了 > < = 之类的符号
项目中出现了大于、等于、小于之类的描述
案例 1 :判断 qq 是否在合理的范围【 6-12 位】,结合边界值设计测试用例

                                                                                                                                                               边界值的优化

必须保留的点 上点 离点中的无效等价类中的点 内点 一共是5个点

优化后结果如下

    2.4判定表方法

判定表:
    以表格的形式来组合多个条件
    通过判定表可以综合考虑多个条件的输入和输出结果之间的关系
案例:手机通话
条件:
   是否欠费:欠费、不欠费
   是否开机:开机、不开机
条件组合
条件一:是否欠费      条件二:是否开机             结果
     欠费                                 关机                      不能通话
     欠费                                 开机                      不能通话 
    不欠费                               关机                     不能通话
    不欠费                               开机                      能通话
转为表格形式

 概念:

条件桩:所有可能出现的条件,例如上例中,有两个条件:是否欠费、是否开机

动作桩:所有可能出现的值、例如上例中,有四个值:欠费、不欠费、开机、关机

条件项:这是条件桩中的一个或者多个值

动作项:这是动作桩中的一个或者多个值

等价类:

  有效

  无效

等价类:在判定表中,表示有效和无效有两种表示方式

方式一:用字母表示 
 有效等价类:Y

 无效等价类:N

方式二:用数字表示

 有效等价类:1

 无效等价类:0

基于判定表的方式设计测试用例的步骤

  第一步:首先确定条件桩

  第二步:确定动作桩

  第三步:对条件桩进行组合

  第四步:确定条件组合的结果

  第五步:根据结果写测试用例

案例:手机通话

条件:

  是否欠费:欠费、不欠费

  是否开机:开机、关机

第一步:首先确定条件桩

 是否欠费

 是否开机
 这里是有两个条件,那么就是在表格中写入两行内容,每行代表一个条件

第二步:确定动作桩

 一共有四种动作,每个条件桩中有2个,一共有四个动作

欠费、不欠费
开机、关机

第三步:对条件桩进行组合

将每个条件的每个值和另外一个条件的每个值进行组合

第四步:确定条件组合的结果

 第五步:根据测试结果写测试用例

思考:条件数量,和测试用例的数量是什么关系

条件越多,得到的测试用例的数量越多

有两个条件的话,得到的测试用例数 2**2 = 4

有三个条件的话,得到的测试用例数 2**3 = 8
有四个条件的话,得到的测试用例数 2**4 = 16

2.5因果图方法

作为了解部分

以图形的方式来表示多个不同条件/输入以及对应的最终结果的关系

也是一种黑盒测试方法

试用场景:

有多个输入条件的情况下

概念:

   因:条件

   果:结果

符号:

- 恒等,表示当条件成立的时候,结果成立 ; 当条件不成立的时候,结果不成立
~ 相当于 NOT ,也就是逻辑非,表示当条件成立的时候,结果不成立 ; 当条件不成立的时候,结果成立
v 相当于 OR ,也就是逻辑或,表示当多个条件中,有至少一个条件成立的时候,结果成立 ; 当全部条件都不
成立的时候,结果不成立
^ 相当于 AND ,也就是逻辑与,表示多个条必须都成立,结果成立 ; 当有任意一个条件不成立的时候,结果不
成立

结合因果图设计测试用例的步骤:

第一步:分析需求

第二步:画因果图

第三步:将因果图转换为判定表

第四步:结合判定表写测试用例

案例:让用户输入内容,要求输入的第一个字符是5或7,第二个字符是是字母

如果第一个字符不正确,输出结果 L
如果第二个字符不正确,输出结果 M
如果都正确,输出 Q

绘制因果图

将因果图转换为判定表

 

 2.6正交方法

这个方法同样是在多个输入和多个输出的情况

正交发:

本质上是用数学中的数据统计【统计学】中的方法进行测试

通过正交法可以用少量测试用例来覆盖大多数的测试情况

概念:

因素【k】:表示的是输入的条件,每列是一个因素
水平【 m 】:表示的是输入的条件所得到的结果,表格中的每个小格是一个结果
成立n :测试用例数
表示正交表的: k 因素 m 水平,例如 5 因素 3 水平
基于正交表法设计测试用例的步骤
第一步:需求分析
第二部:确定因素和水平【其实就是找有几个输入和几个结果】
第三步:根据因素和水平数量、确定选哪个正交表
第四步:将具体的值替换掉正交表中的内容
第五步:根据正交表写测试用例
案例1:设置字体属性
字体:仿宋、楷体、微软雅黑
字符样式:粗体、斜体、下划线
颜色:红色、黑色、蓝色
字号: 20 号、 30 号、 40
第一步:需求分析
要测试4个内容,也就是有4个输入·
第二步:确定因素和水平【其实就是找有几个输入和几个结果】
4 个输入,就是有 4 个条件,也就是有 4 个因素
每个因素都有三种结果,那么就是 3 水平
结论: 4 因素 3 水平
第三步:根据因素和水平的数量,确定选择哪个正交表

第四步:将具体的值替换掉正交表的内容

字体: 仿宋 (1) 楷体 (2) 微软雅黑 (3)
字符样式:粗体 (1) 斜体 (2) 下划线 (3)
颜色: 红色 (1) 黑色 (2) 蓝色 (3)
字号: 20 (1) 30 (2) 40 (3)

第五步:根据正交表写测试用例
正交表中的每一行,都是一个测试用例
用工具生成正交表
2.7 场景法
又称为流程图法,用图形的方式来表示测试的条件和输出的结果
概念:模拟用户对软件进行操作的场景
这种方法更合适测试多个模块
适合用在测试过程中的哪个阶段?
集成测试
系统测试
验收测试
基于场景法设计测试用例的步骤
1. 第一步:分析需求
2. 第二步:绘制流程图
3. 第三步:根据流程图写测试用例
流程图中的符号
绘图软件:
visio
亿图
案例:电商平台购物流程
购物过程包括
1. 注册
2. 登陆
3. 商品列表
4. 购物车
5. 付款
6. 订单管理
流图图如下

 

设计测试用例
流程图中的一条先就是一个测试用例
1 - 2 - 3 - 4 - 5 - 5.1 - 6 1 - 2 - 3 - 4 - 5 - 5.2 - 6
1 - 2 - 3 - 4 - 5 - 5.3 - 6
1 - 2 - 2 - 2
1 -2 - 2 - 3 - 4 - 5 - 5.1 - 6
1 -2 - 2 - 2 - 3 - 4 - 5 - 5.1 - 6
2.8 错误推断法
凭借经验来做的
原理就是根据同类型的软件的具有的 bug ,判定这个目标软件也有这个 bug
使用场景:
时间、资源不充足情况才会是使用
使用这种方法,通常都是做初测
2.9 总结
等价类:测试的内容有输入功能,而且输入的内容之间没有关系
边界值:输入的内容有边界,有类型、大小、长度的要求
判定表 / 因果图:有多种输入的内容,而且有多种输出结果
正交法:测试的数据和条件特别多
场景法:整合测试多个功能,需要使用场景法
错误推断法:时间、资源补充足;仅仅需要做初测
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值