软件测试之功能测试详解_软测中功能测试描述

 一、测试项目启动与研读需求文档

（一） 组建测试团队

1、测试团队中的角色

2、测试团队的基本责任

• 尽早地发现软件程序、系统或产品中所有的问题。
• 督促和协助开发人员尽快地解决程序中的缺陷。
• 帮助项目管理人员制定合理的开发和测试计划。
• 对缺陷进行跟踪、分析和分类总结，以便让项目的管理人员和相关的负责人能够及时、 清楚地了解产品当前的质量状态。
• 帮助改善开发流程、提高产品开发效率。
• 促进程序编写的规范性、易读性、可维护性等

3、测试团队与开发团队的 3 种模式

（1）以开发为核心，测试只是开发队伍的一部分，也就是开发团队中有测试人员，但 没有形成独立的团队

（2）以项目经理为核心，开发小组和测试小组并存，隶属于项目经理领导。

 （3）项目经理、开发组长和测试组长“三足鼎立”，测试团队具有独立的、权威的地 位。

（二）软件质量需求

1、软件质量需求的分类

软件质量需求用于确定测试目标。
测试目标包括：功能、性能、界面、易用性、兼容性、安全性、可用性/可靠性、可维 护性、可扩展性等。
功能以外统称非功能。

2、功能

• 软件能做什么？
• 需要做什么？
• 怎么做是正确的？
• 哪些功能要测试、哪些功能不需要测试？
• 哪些功能重要，哪些不重要？
• 哪些功能先实现或先测试？

3、性能

反映软件运行时的效率和占用资源情况的能力。
时间特性：时间短、速度快、效率高。
资源特性：占用资源（CPU、内存、硬盘、网络）少。

4、界面（UI）

• 布局合理；
• 控件位置恰当；
• 文字没有乱码、字体大小合适；
• 颜色使用恰当；
• 图片、表格恰当、舒适、美观。

5、易用性

在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。

6、兼容性/可移植性

指软件产品从一种环境迁移到另一个环境的能力，反映一个软件与不同的硬件环境、操 作平台、其他软件的共同使用的能力

• 包括与不同硬件、平台、软件自身不同版本、其他软件、数据的兼容。

7、安全性

指软件产品保护信息和数据的能力。

8、可用性/可靠性

指系统正常运行的能力或程度，可用性=正常运行时间/（正常运行时间+非正常运行时 间）×100%

• 可用性指标一般要求达到 4 个 9 即 99.99%（全年 52 分钟不正常工作）或 5 个 9 即 99.999%（全年 5 分钟），对一些军事系统，可用性高达 7 个 9（99.99999%（全年 失效时间不超过两秒）。
• 一般测试时间不足，可以采用空间换时间的办法，如在高负载情况下进 行为期一周 或一个月的测试，以判断其可靠性。
• 关注 MTTF（平均无故障时间）、MTTR（平均恢复时间）、MTBF（平均失效间 隔时间）。

9、可维护性

指软件产品可被修改的能力

• 修改可能包括修正、改进或软件对环境需求和功能规格说明变化的适应。
• 可维护性的软件应该是易改变的、稳定的、易测试的。

10、可扩展性/可伸缩性测试

通过很少的改动就能实现整个系统处理能力的增长

• 如在部署两台服务器时测试系统性能（容量，即最大负载），再部署四台、八台服 务器时分别进行系统容量的测试，看其容量是否为上次（两台、四台）实验值的两 倍或接近两倍。如果是，系统就具有良好的可伸缩性。

（三）研读需求文档

1、测试需求分析的过程

收集与研读文档，提出并解决问题，整理需求信息
功能拆分、功能描述/需求整理
编写测试点
需求评审

2、研读需求文档

2.1 研读文档主要任务

提取有用的需求信息
提出需求中不清晰、不理解、不明白的问题
 和用户、业务人员、产品经理或产品设计人员、开发人员等沟通

2.2 怎么研读文档

分析思路
 分析软件的用户群，分析用户的实际需要；
 分析软件的开发环境、开发语言、数据类型；
 分析软件架构、软件的运行环境和平台、数据库类型；
 分析软件要实现哪些目标（功能、性能、界面、易用性、兼容性、安全性）以 及具体的要求是什么；
 分析软件有哪些功能，每种功能要完成什么业务，这些业务应该怎么实现，业 务逻辑是什么，业务流程是怎样的，业务规则有何要求；
 分析功能或业务间的联系，哪些业务更关键或重要；
 明确测试周期，测试目标，测试范围。

细节上
 分析每个模块或功能上实现的功能
 设计的开发原理包括数据类型
 从用户使用场景角度分析业务流程
 记录业务规则

实施
 以情景再现的形式写出需求信息。

2.3 研读需求文档案例

拿到一个项目，怎么入手？
即时贴程序部分需求说明
便签的数量最多为 50 个
便签标题字数最多为 40 个字节
便签的正文文字数量最多为 200 个
年份只能设置在 1900－2100 之间

（四）需求评审

1、意义

• 对软件需求进行正确性的检查。
• 保证软件需求的可测试性。
• 通过产品需求文档的评审，与市场、产品、开发等各部门相关人员沟通，使得大家 认识一致，避免在后期产生不同的理解，引起争吵。
• 通过产品需求文档的评审，更好地理解产品的功能性和非功能性需求
• 在需求文档评审通过后，测试的目标和范围就确定了。虽然此后会有需求的变更， 但可以得到有效的控制，这样可降低测试的风险。

评审是否完成是以需求文档获得多方“邮件确认”或“签字”通过为标志的。这不 应该只体现在“签字”形式上，更重要的是达到下面的结果。

• 所有参与方达成一致。
• 已发现的问题被阐述清楚、被修正。

2、需求评审的质量要求

• 正确性
• 完备性
• 易理解性
• 一致性
• 可行性
• 易修改性
• 可测试性
• 可追溯性

3、需求评审的参加人员

• 用户代表
• 需求人员
• 产品经理
• 项目经理
• 开发人员
• 开发经理
• 测试人员
• 测试经理
• 市场经理
• 质量保证人员

4、测试人员参与评审时的注意事项

• 明确自己的角色和责任。
• 熟悉评审内容，为评审做好准备，做细做到位。
• 在评审会上，针对问题阐述观点，而不是针对个人。
• 可以分别讨论主要的问题和次要的问题。
• 在会议前或会议后可以就存在的问题提出自己建设性的意见。
• 提高自己的沟通能力，采取适当的、灵活的表述方式。
• 对发现的问题跟踪下去。
• 应该在需求形成的过程中进行分阶段的多次评审，而不是一次评审。
• 测试人员要善于提问，多思考

 这些需求都是用户提出来的吗？
 有没有画蛇添足的需求？没有漏掉什么需求吗？
 和竞争对手的产品做过比较吗？我们的产品优势体现在哪里？
 是否正确地描述了每个需求？这条描述是否存在二义性的问题？
 我的理解和文档作者的理解一致吗？

同时，我也为大家准备了一份软件测试视频教程（含面试、接口、自动化、性能测试等），就在下方，需要的可以直接去观看，也可以直接点击文末小卡片免费领取资料文档

软件测试视频教程观看处：

二、测试需求分析与测试用例设计

（一） 界面中的控件知识

1、文本框和密码框

2、单选按钮、组合列表框、数码框

 

3、复选框

4、列表框

5、命令按钮

6、其他界面元素

三、 测试需求分析与测试用例设计方法

1、场景法

1.1 测试点/检查点

测试时应该考虑可以测试的诸多方面。

1.2 场景法概述

场景法模拟用户操作软件时的情景，主要用于测试系统的业务流程。
当拿到一个测试任务时，我们先要关注它的主要功能和业务流程是否正确实现，这 就需要使用场景法来完成测试。

1.3 场景的定义

场景用来描述软件操作的路径。
基本流
按照正确的业务流程来实现的一条操作路径（模拟正确的操作流程）。
备选流
导致程序出现错误的操作流程（模拟错误的操作流程）。

1.4 场景法的分析步骤

分析软件需求
从用户使用情景角度，写出业务流程和业务规则
写出基本流场景和备选流场景

1.5 场景法案例：ATM 机取款

步骤一：分析业务流程（可以绘制流程图）

步骤二：描述程序的基本流及备选流

1、基本流（正确的流程）
（1）插入银行卡：客户将银行卡插入 ATM 机的读卡器
（2）验证银行卡：ATM 机从银行卡的磁条中读取账户代码，并检查它是 否属于可以接受的银行卡
（3）输入密码：ATM 机要求客户输入密码
（4）验证密码：确定该密码是否正确 
（5）进入 ATM 主界面：ATM 显示在本机中可用的各种选项
（6）选择取款并输入金额：客户选择“取款”，并选择取款金额
（7）ATM 机验证：ATM 机进行验证账户余额是否满足以及总取款金额 是否满足要求，验证 ATM 机内现金是否够用
（8）更新账户余额、出钞：验证成功，更新账户余额，输出现金，提示 用户收取现金
（9）返回主界面
2、备选流（各种错误情况）
（1）银行卡无效：提示错误并退卡
（2）密码错误：提示错误，并判断是否 3 次错误
（3）密码 3 次错误：吞卡
（4）账户余额不足：提示错误并退卡
（5）总取款金额超出当日可取限额：提示错误并退卡
（6）ATM 机余额不足：提示错误并退卡

步骤三：根据基本流和备选流生成不同的场景

2、等价类划分

2.1 案例引入

测试两位数加法器（学生思考、讨论、陈述）

2.2 等价类划分核心思想

通过需求分析，找出程序的输入域。
将输入域划分成若干类。
每一类中选取代表性数据等价于这一类中的其他值。

2.3 等价类划分的步骤

需求分析
划分等价类（根据需求，有效等价类、无效等价类）并细化（根据计算机知识）

2.4 等价类划分案例

步骤 1：需求分析
阅读文档 ：
 借助开发知识
 与开发或用户沟通
 了解用户群及行业知识

写出需求：
 -99~99 之间的整数

步骤 2：划分等价类并细化
有效类
 -99 到 99 之中的整数
 细化 ：负数、0 、正数
无效类
 超范围 ：<-99 或 >99
 非法类型 ： 浮点数 、 字符（串）

2.5等价类划分注意事项

不但要考虑有效等价类，也要考虑无效等价类
两块划成一块（等价类划分过粗），结果？
 遗漏一种测试情况
一块划成两块（等价类划分过细），结果？
 冗余测试
仔细划分，审查划分
 过于粗略可能会漏掉软件缺陷
 积累经验

3、边界值分析

3.1 边界值分析的思想与步骤

分析需求，找出边界。
写出边界值
 最小值
 小于最小值
 最大值
 大于最大值

3.2边界值分析案例

两位数加法计算器的边界值 ： -99 、-100、99 、100

3.3 为什么分析边界值

看看下面的代码有错误吗？

 输入或输出的边界最容易产生错误。

4、决策表

前面测试两位数加法计算器的测试没有考虑输入组合。

4.1 决策表的分析步骤

需求分析
分析输入和输出
 用等价类划分分析输入的各种情况、输出的各种情况
画判定表
分析与简化判定表

4.2 决策表案例

分析输入条件和输出条件

输入

输出

 正确计算
 错误提示

原始决策表/判定表

优化决策表

优化策略

 测试基本功能的保留；
 一个输入错误，另外输入无所谓，可以整合；
 所有输入都要错误过。

最终的决策表

4.3 决策表的局限性与优化策略

导致测试量爆炸。

5、错误推测

5.1 测试若干原则回顾

测试不是验证软件正确，而是攻击软件，发现错误。
测试要时刻保持怀疑的态度，具有缺陷预防意识。
测试要寻求系统设计、功能设计的弱点。
设计负面的、异常的测试，如考虑错误的或者异常的输入，往往可以发现更多的软件缺陷。

5.2 什么是错误推测

在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对 性地编写检查这些错误的测试方法。

错误推测分类
 输入数据测试方面
 输出数据测试方面
 数据结构测试方面
 文件系统方面

5.3 输入数据方面的错误推测

输入非法数据

一般用于键盘输入数据时。

测试方法
 输入非法类型
 输入非法范围/长度
 输入非法格式

注意
错误信息的检查：需要额外考虑错误提示信息的内容
错误信息和错误要对应一致
错误信息不能为空
错误信息的内容不能只是错误代码，不能包含开发信息
错误信息不能中英文混合

5.4 错误推测

输入非法类型
输入非法范围（数值）
输入非法长度（个数）
输入非法格式
输入默认值
输入特殊字符
输入合法数据的非法组合
粘贴强制输入
一个输入多个输出不要遗漏
输出结果（含数据库）要正确
上溢、下溢（含结果）
操作数与操作符不符
文件超载
文件权限不足
介质忙或不可用
介质损坏

输入默认值

适用于有默认值的地方。
测试方法
 接受软件的默认值
 键入空值
 将默认值改为另外一个值
 将默认值改为另外一个值，再变为空值

输入特殊字符（集）

适用于不能输入有特殊含义的字符时。
测试方法
 根据被测软件所处的操作系统、程序设计语言、后台数据库以及具体业务 等信息列出表格，进行讨论，标明哪些需要测试，哪些需要剔除。
 了解具体行业知识，具体问题具体分析。
案例
文件命名下列特殊字符（33 个）
 不能使用：\ /<>|“