等价类划分方法针对手机状态大致可以归几个大类：
- 按键类（等价法）：有效输入和无效输入（有效输入指UM和菜单指示；无效输入指测试菜单功能此时没有定义的按键和用户动作）；
- 外部中断类（等价法）：常用、不常用及无效
- 常用：来电和来消息（短信、彩信、push消息）；掀合盖；侧键；耳机＆FM；情景模式；电量不足
- 不常用：充电；闹钟＆记事本＆关机时间＆整点报时提示；Icon＆动画显示；Icon＆动画刷新；编辑界面＆pop显示框输入为空或满；编辑界面＆pop显示框状态输入法默认＆字符编码默认；失效SIM卡；大容量等SIM卡兼容；排序；号码识别；
- 无效：“资料读取中…”；“复制中…”；“请稍后再试”
- 存储器类
- 等价法分类：读或写；不读或不写。
- 因果法分类：先SIM卡后手机；先手机后SIM卡；提示用户选择存储器（对比Nokia）。
- 操作分类：读；写；新增；删除；复制（先删除后新增；先新增后删除）
- 状态类：正确；错误；变更；用户设定变更
举例一，短消息发送功能:
英文：Default 7-bit alphabet (over 160 characters)
合法等价类： 0～160
非法等价类：：>160
The quick fox jumps over the lazy brown dog
中文：UCS-2 alphabet (over 70 characters)
合法等价类： 0～70
非法等价类：：>70
诺基亚（英文）：Extended default 7-bit alphabet (over 140 Bytes)，智慧短信，可以携带黑白图片。
合法等价类： 0～140
非法等价类：：>140
在写字板里面输入“联通”二字，保存后，再打开，即出现乱码。
举例二，单个通话实例的拨打与挂断
| 测试用例标识 | 测试阶段：系统测试 | |
| 测试项 | 单个通话实例的拨打与挂断 | |
| 测试项属性 | A | |
| 参照规范 | ||
| 重要级别 | 高 | |
| 测试原因 | 手机在待机状态下，确保手机能正常拨出电话 | |
| 预置条件 |
| |
| 输入 |
| |
| 测试执行步骤 | IDLE状态拨打号码 按Send键发送 按End键挂断 | |
| 预期输出结果 |
| |
| 测试用例标识 | 测试阶段：系统测试 | |
| 测试项 | 单个通话实例的拨打与挂断 | |
| 测试项属性 | A | |
| 参照规范 | ||
| 重要级别 | 高 | |
| 测试原因 | 手机在无信号或无网络情形下，手机无法正常拨打电话 | |
| 预置条件 |
| |
| 输入 | 同上用例 | |
| 测试执行步骤 | IDLE状态拨打号码 按Send键拨号 | |
| 预期输出结果 |
| |
软件测试全栈专题系列课程
https://edu.csdn.net/combo/detail/2221Jmeter高级性能测试实战https://edu.csdn.net/course/detail/35834RobotFramework+Jmeter接口自动化测试课程https://edu.csdn.net/course/detail/36152Fiddler接口抓包神器使用教程https://edu.csdn.net/course/detail/32782零基础新手入门软件测试必知必会https://edu.csdn.net/course/detail/32598
| 测试用例标识 | 测试阶段：系统测试 | |
| 测试项 | 单个通话实例的拨打与挂断 | |
| 测试项属性 | A | |
| 参照规范 | ||
| 重要级别 | 高 | |
| 测试原因 | SIM卡失效情况下，手机无法正常拨打电话 | |
| 预置条件 |
| |
| 输入 | 同上用例 | |
| 测试执行步骤 | IDLE状态拨打号码 按Send键拨号 | |
| 预期输出结果 |
| |
| 测试用例标识 | 测试阶段：系统测试 | |
| 测试项 | 单个通话实例的拨打与挂断(开启固定拨号名单时) | |
| 测试项属性 | A | |
| 参照规范 | ||
| 重要级别 | 高 | |
| 测试原因 | 手机在待机状态下，确保手机能正常拨出固定拨号名单中电话号码 | |
| 预置条件 | 正常信号环境 IDLE状态 默认原厂参数设定 SIM卡开启固定拨号名单 | |
| 输入 |
| |
| 测试执行步骤 | IDLE状态拨打号码 按Send键发送 按End键挂断 | |
| 预期输出结果 |
| |
| 测试用例标识 | 测试阶段：系统测试 | |
| 测试项 | 单个通话实例的拨打与挂断(设定通话限制时) | |
| 测试项属性 | A | |
| 参照规范 | ||
| 重要级别 | 高 | |
| 测试原因 | 手机在待机状态下，确保手机能满足通话限制功能 | |
| 预置条件 | 正常信号环境 IDLE状态 默认原厂参数设定 申请开通通话限制服务 | |
| 输入 | ||
| 测试执行步骤 | IDLE状态拨打号码 按Send键发送 按End键挂断 | |
| 预期输出结果 | ||
| 测试用例标识 | 测试阶段：系统测试 | |
| 测试项 | 单个通话实例的拨打与挂断(漫游情形时) | |
| 测试项属性 | A | |
| 参照规范 | ||
| 重要级别 | 高 | |
| 测试原因 | 手机在待机状态下，确保手机能满足通话限制功能 | |
| 预置条件 | 正常信号环境 IDLE状态 默认原厂参数设定 申请开通通话限制服务 | |
| 输入 | ||
| 测试执行步骤 | IDLE状态拨打号码 按Send键发送 按End键挂断 | |
| 预期输出结果 | ||
例子1：
短消息发送功能的等价类划分方法:
英文：Default 7-bit alphabet (over 160 characters)
合法等价类： 0～160
非法等价类：：>160
The quick fox jumps over the lazy brown dog
中文：UCS-2 alphabet (over 70 characters)
合法等价类： 0～70
非法等价类：：>70
诺基亚（英文）：Extended default 7-bit alphabet (over 140 Bytes)，智慧短信，可以携带黑白图片。
合法等价类： 0～140
非法等价类：：>140
例子2：
首先用7列的LCD显示屏，软件可以显示7列汉字，如果换成8列汉字的显示屏，那么，如果软件格式化处理比较僵化，可能依然显示7个汉字。这样，软件的实现，与LCD的规格不符合。因此，需要考虑LCD屏幕的规格，依据边界值方法设计用例。
LCD屏幕上有效显示区域4行每行8汉字，可考虑编辑超过4行每行超过16字符情形来进行测试。
LCD列边界值需要考虑：7个汉字，8个汉字，9个汉字
行边界值：31个汉字，32个汉字，33个汉字
例子3：
SIM卡名片簿姓名超长（20个英文字符），号码超长情形，新增和查看用户姓名
由学员完成该作业：
- 注意等价类和边界值的用例设计方法
- 关注LCD的显示格式问题
- 关注新增、查看两种功能的结合，可能新增姓名是正确的，但是查看的格式错误。
例子1：
利用手机闹钟重响的例子引入错误猜测法基本概念，讲解错误猜测法的意义
未接来电29通，内存中规划的分区一直分配被占用。即使同一号码也同样占用资源。假设此时第30通电话正好为来电号码不显示，即“来电号码未知”或境外来电号码隐藏时（国外保护个人隐私，自动开启来电号码隐藏功能），可能会出现BUG，实际情况证明，此时会出现Reset问题。
同样道理，推断第一通电话如果为“来电号码未知”，也可能出现上述问题。
例子2：
通常手机解决方案中sunplus、雅马哈和弦芯片发声。为了降低成本采用DSP策略纯软件发声（如果采用硬件独立声音控制芯片，不会出现下面问题），此时测试中就猜测当手机设定闹钟时，闹钟时间到后，确定为重响，此时用户进入铃声选择-浏览-播放时，这时候铃声控制软件会出现资源冲突，可能出现BUG。测试结果是出现RESET或者浏览铃声无响铃的结果。
例子3：
比如，设定闹钟铃声,在IDLE下闹钟响铃未处理（响铃一分钟后，铃声停止，系统进入另外一种状态，菜单提示为闹钟是否重响？）,待钤声响完后按两次SKL键（确定键），（第一次确定要重响，第二次应该返回IDLE状态）,再次进入"钤声设定"/"钤声类型",此时任选一铃声都没有声音
举例一，若手机用户欠费或停机，则不允许主被叫。表示为判定表如下：
| 1 | 2 | 3 | 4 | ||
| 条件 | 用户欠费 | Y | Y | N | N |
| 用户被停机 | Y | N | Y | N | |
| 动作 | 可以主被叫 | N | N | N | Y |
| 1 | 2 | 3 | 4 | ||
| 条件 | 显示运营商logo正确 | Y | Y | N | N |
| 显示有信号 | Y | N | Y | N | |
| 动作 | 可以拨打电话 | Y | N | Y（除拨112外还可以拨打其它号码） | Y |
- 流程分析方法
1-手动/自动选网模式；11-自动注册并显示已有网络服务
2-手动模式（选网模式的一种）；3-搜寻到HPLMN（归属网络）及FPLMN（禁止网络）；6-频段搜索；7-自动选择频段；8-手动选择频段900或1800；（新手机才有频段手动选择）4-选择FPLMN；5-注册FPLMN
路径
path1:1-11
path2:1-2-3-4-5-1-11
path3:1-2-3-6-8-9-10-1-11
path4:1-2-3-6-7-9-10-1-11
举例二，彩信发送功能
- 终端发送MMS，如果是终端到终端，那么以WSP（无线会话协议）协议编码送到WAP网关；如果终端到应用服务器（发送Email）,则以IP协议发送到IP网关；
- WAP网关或IP网关都以HTTP协议与MMS中继器通信，文件内容传给中继器
- 中继器将文件送往MMS服务器，并以MIME格式存储。（MIME的格式可以被手机终端识别并显示，并且可以被Email客户端浏览并显示的文件格式）
- 如果MMS接收方为手机终端，MMS服务器调用号码以及相关路由信息，并进行数据分析，判断终端支持能力和承载能力，如果终端不支持MMS，只通过短消息格式发文字部分；如果终端支持MMS，直接发送MIME格式的文件到手机终端。
- 如果，发送到Email服务器，系统通过路由选择，把MIME格式的文件发送到Email地址所在的服务器。
- 该MMS支持的媒体格式包括文本、铃声、图片；文本没有上限64K，包括64K；铃声单首最大为64K，包括64K，最多支持5页；单页图片最大64K，最多5页；
软件测试全栈专题系列课程https://edu.csdn.net/combo/detail/2221Jmeter高级性能测试实战https://edu.csdn.net/course/detail/35834RobotFramework+Jmeter接口自动化测试课程https://edu.csdn.net/course/detail/36152Fiddler接口抓包神器使用教程https://edu.csdn.net/course/detail/32782零基础新手入门软件测试必知必会https://edu.csdn.net/course/detail/32598
测试用例设计
利用流程分析方法，测试分析时需要考虑以下几点：
- 彩信发送测试时需要考虑基于WAP业务实现和基于IP网关的流程差异；
- MMS服务器数据分析并确定处理方法时需要考虑终端到终端的情形和终端到应用的业务情形；
- 确定终端到终端的情形下，还需要考虑终端是否支持MMS发送
例子1：
假设一个WEB站点，该站点有大量的服务器和操作系统，并且有许多具有各种插件的浏览器浏览：
WEB浏览器：Netscape6.2、IE6.0、Opera4.0
插件： 无、RealPlayer、MediaPlayer
应用服务器：IIS、Apche、Netscape Enterprise
操作系统：Windows2000、Windows NT、Linux
正交表：
| 1 | 2 | 3 | 4 | |
| 1 | 1 | 1 | 1 | 1 |
| 2 | 1 | 2 | 2 | 2 |
| 3 | 1 | 3 | 3 | 3 |
| 4 | 2 | 1 | 2 | 3 |
| 5 | 2 | 2 | 3 | 1 |
| 6 | 2 | 3 | 1 | 2 |
| 7 | 3 | 1 | 3 | 2 |
| 8 | 3 | 2 | 1 | 3 |
| 9 | 3 | 3 | 2 | 1 |
提取系统功能说明中的因子：
WEB浏览器
插件
应用服务器
操作系统
分析各因子的状态
WEB浏览器：1＝Netscape6.2、2=IE6.0、3=Opera4.0
插件: 1=None、2=RealPlayer、3=MediaPlayer
应用服务器: 1=IIS、2=Apche、3=Netscape Enterprise
操作系统: 1=Windows2000、2=Windows NT、3=Linux
将因子、状态映射到上面正交表中：
| 测试用例 | 浏览器 | 插件 | 服务器 | 操作系统 |
| 1 | Netscape6.2 | None | IIS | Windows2000 |
| 2 | Netscape6.2 | RealPlayer | Apche | Windows NT |
| 3 | Netscape6.2 | MediaPlayer | Netscape Enterprise | Linux |
| 4 | IE6.0 | None | Apche | Linux |
| 5 | IE6.0 | RealPlayer | Netscape Enterprise | Windows2000 |
| 6 | IE6.0 | MediaPlayer | IIS | Windows NT |
| 7 | Opera4.0 | None | Netscape Enterprise | Windows NT |
| 8 | Opera4.0 | RealPlayer | IIS | Linux |
| 9 | Opera4.0 | MediaPlayer | Apche | Windows2000 |
举例2：MMS处理模块
编辑模块：支持SMIL（同步多媒体综合语言）、不支持SMIL…..
效果处理模块：水波纹、半透明、水印、反透…..
界面显示模块：POP形式、窗体式显示…..
举例3：照相机功能测试
- 状态迁移法
举例手机mp3键盘播放模式测试用例设计
- 键盘用户模式基本操作功能
- 支持媒体格式与文件格式要求
- 多媒体播放中对外部事件的响应
- 终端处理能力（包括终端异常处理、文件操作）
- PC与终端同步能力
键盘用户模式基本操作功能系统测试用例设计步骤：
编写状态—事件表；
编制状态图转换表；
编写合法测试用例；
编写非法测试用例；
编写错误异常处理测试项；
| 序号 | 需求内容 | 播放器要求 |
| 1 | 功能类型和操作方式 | 采用菜单选项方式 |
| 2 | 文件播放 | 必须支持 |
| 3 | 播放基本功能Play, Pause, Stop, Seek | 必须支持 |
| 4 | 声音调节 | 必须支持 |
| 5 | 亮度调节 | 必须支持 |
| 6 | 对比度调节 | 推荐支持 |
| 7 | 播放进度显示 | 必须支持 |
| 8 | 模式选择及切换 | 必须支持，可通过设定功能键切换常规模式 |
| 9 | 后台播放模式 | 推荐支持 |
| 10 | 播放器设置 | 必须支持，提供缺省设置 |
| 11 | 播放统计及列表记录 | 必须支持 |
| 12 | 5键快捷设定及操作 | 必须支持 |
| 5键 | 功能定义 |
| Up | 增大音量 |
| Down | 减小音量 |
| Left | 上一首或后退 |
| Right | 下一首或快进 |
| Select（侧键ok） | 播放/暂停 功能切换 |
状态—事件表（黑点着重号表示为非法组合）
| 函数名字 | Idle | 倒 | 播放 | 进 | 录音 |
| EvRewindbutton （倒） | 1-倒 | · | 8-倒 | 11-倒 | · |
| Evplaybutton （播放） | 2-播放 | 5-播放 | · | 12-播 | · |
| Evfastforwardbutton （进） | 3-进 | 6-进 | 9-进 | · | · |
| Evrecord （录音） | 4-录音 | · | · | · | · |
| Evstopbutton （Idle） | · | 7-idle | 10-idle | 13-idle | 14-idle |
7软件测试文档
由安博测试空间技术中心http://www.btestingsky.com/提供
1、软件测试文档就是为将软件测试当作一个项目一样实施计划和管理而引入的，它为测试项目的组织、规划和管理提供了一个规范化的架构。
2、软件测试文档主要包括测试计划、测试用例、测试规程、测试事件报告、测试总结报告等。测试文档总所规定的内容可以作为对测试过程完备性的对照检查表，有助于提高测试工程每个阶段的能见度，极大地提高了测试工作的可管理性。
为了统一测试文档的书写标准，IEEE/ANSI制定了829-1983标准，还有其他的一些也用于指导软件测试文档的编写，如我国制定的《计算机软件测试文件百年之规范（GB/T 9386-1988）》
3、 测试文档编写规范（GB/T 9386-1988）简介
（1）.引用标准
该规范的引用标准为：
GB/T 11457 软件工程术语
GB 8566 计算机软件开发规范
GB 8567 计算机软件产品开发文件编制指南
（2）.关键术语定义
设计层：软件项的设计分解（如系统，子系统，程序，模块）
通过准则：一个软件项或软件特性的测试是否通过的判别依据
软件特性：软件项的显著特性（如功能，性能或可移植性）
软件项：源代码，目标代码，作业控制代码，控制数据或这些项的集合。
测试项：作为测试对象的软件项
（3）.规范的主要内容
该规范确定了各个测试文件的格式和内容，所提出的文件类型包括测试计划，测试说明和测试报告。
测试计划免除测试活动的范围，方法，资源和进度，他规定被测试的项，被测试的特性，应完成的测试任务，担任各项工作的人员职责及与本计划有关的风险等。
4、测试说明包括三类文件
测试设计说明：详细描述测试方法，规定该设计及其有关测试所包括的特性，还规定完成测试所需的测试用例和测试规程，并规定特性的通过准则。
测试用例说明：列出用于输入的具体值以及预期的输出结果，并规定在使用具体测试用例时，对测试规程的各种限制。将测试用例与测试设计封开，可以使它们用于多个设计并能在其它情形下重复使用。
测试规程说明：规定对于运行系统和执行指定的测试用例来实现有关测试设计所要求的所有步骤。
5、测试报告则包括四类文件：
测试项传递包括：指明在开发组和测试组独立工作的情况下或者在希望正式开始测试的情况下为进行测试而传递的测试项。
测试日志：测试组用于记录测试执行过程中发生的情况。
测试事件报告：描述在测试执行期间发生并需进一步调查的一切事件。
测试总结报告：总结与测试设计说明有关的测试活动。
6.对规范的实施
使用该规范的每个单位，要规定测试阶段所应有的特性文件，并在测试计划中规定测试完成后所能提交的全部文件。
使用该规范的每个单位应该补充规定对内容的要求和约定，及便反映总结在测试，文件控制，配置管理和质量保证方面所用的特定方法，设备工具。
一下是规范中的文件编制实施及使用指南
- 实施指南
在实施测试文件编制的初始阶段可先编写测试计划于测试报告文件。测试计划将为整个测试过程提供基础。测试报告将鼓励测试单位以良好的方式记录整个测试过程的情况。
- 用法指南
在项目计划及单位标准中，指明在那些测试活动中需要那些测试文件，并可在文件中加入一些内容，使各个文件适应一个特定的测试项及一个特定的测试环境。
7《软件测试文件编制规范》中的内容要求
以下是规范中各个测试文件的书写格式及内容。
a测试计划
- 测试计划名称（该计划的第1章）
- 引言（该计划的第2章）
- 测试项
- 被测试的特性
- 不被测试的特性
- 方法
- 项通过的准则
- 暂停标准和再启动要求
- 应提供的测试文件
- 测试任务
- 环境要求
- 职责
- 人员和训练要求
- 进度
- 风险和应急
- 批准
b测试设计说明
- 测试设计说明名称
- 被测试的特性
- 方法详述
- 测试用例名称
- 特性通过准则
c测试用例说明
- 测试用例说明名称
- 测试项
- 输入说明
- 输出说明
- 环境要求
- 特殊的规程要求
- 用例间的依赖关系
d测试规程说明
- 测试规程说明名称
- 目的
- 特殊要求
- 规程步骤
e测试项传递报告
- 传递报告名称
- 传递项
- 位置
- 状态
- 批准
f测试日志
- 测试日志名称
- 描述
- 活动和事件条目
g测试事件报告名称
- 测试事件报告取一个专用名称
- 摘要
- 事件描述
- 影响
h测试总结报告
- 规定该报告必须由哪些人（姓名和职务）审批，并为签名和日期留出位置。
背景知识：
目前主流的软件生命周期模型或软件开发过程模型有：瀑布模型、原型模型、螺旋模型、增量模型、渐进模型、快速软件开发(RAD)以及Rational统一过程(RUP)等，这些模型对于软件开发过程具有很好的指导作用，但是在这些过程方法中，软件测试的地位和价值并没有体现出来，也没有给软件测试以足够的重视，利用这些模型无法更好地指导测试实践。软件测试是与软件开发紧密相关的一系列有计划、系统性的活动，显然软件测试也需要测试模型去指导实践。下面先对主要的模型做一些简单的介绍，再补充软件生命周期做介绍。
1、V模型
V模型是最具有代表性的测试模型。V模型最早是由Paul Rook在20世纪80年代后期提出的，V模型在英国国家计算中心文献中发布，旨在改进软件开发的效率和效果。
在传统的开发模型中，比如瀑布模型，通常把测试过程作为在需求分析、概要设计、详细设计和编码全部完成之后的一个阶段，尽管有时测试工作会占用整个项目周期一半的时间，但是有人仍认为测试只是一个收尾工作，而不是主要的工程。V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系，从左到右，描述了基本的开发过程和测试行为，明确地标明了测试工程中存在的不同级别，清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。如图5-1所示。
图1 V模型图
图1 V模型图中箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即测试过程的各个阶段。
V模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了确保源代码的正确性，高层测试是为了使整个系统满足用户的需求。
V模型指出，单元和集成测试是验证程序设计，开发人员和测试组应检测程序的执行是否满足软件设计的要求；系统测试应当验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标；由测试人员和用户进行软件的确认测试和验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满足用户需求或合同的要求。
V模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段隐藏的问题一直到后期的验收测试才被发现。
类比记忆：此模型与软件开发模式中的线性模型（典型的瀑布模型）有相似的不足，在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，开发前期未发现的错误会传递并扩散到后面的阶段，而在后面发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。
软件测试全栈专题系列课程https://edu.csdn.net/combo/detail/2221
Jmeter高级性能测试实战https://edu.csdn.net/course/detail/35834RobotFramework+Jmeter接口自动化测试课程https://edu.csdn.net/course/detail/36152Fiddler接口抓包神器使用教程https://edu.csdn.net/course/detail/32782零基础新手入门软件测试必知必会https://edu.csdn.net/course/detail/32598
2、W模型
V模型的局限性在于没有明确地说明早期的测试，不能体现“尽早地和不断地进行软件测试”的原则。在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型，因为实际上开发是V，测试也是与此相并行的V。基于“尽早地和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活动应遵循IEEE std1012-1998《软件验证和确认(V&V)》的原则。
一个基于V&V原理的W模型示意图如图2所示。
图2 W模型图
相对于V模型，W模型更科学。W模型可以说是V模型自然而然的发展。W模型强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。这样，只要相应地开发活动完成，我们就可以开始执行测试，可以说，测试与开发是同步进行的，从而有利于尽早地发现问题。以需求为例，需求分析一完成，就可以对需求进行测试，而不是等到最后才进行针对需求的验收测试。
如果测试文档能尽早提交，那么就有了更多的检查和检阅的时间，这些文档还可用于评估开发文档。另外还有一个很大的益处是，测试者可以在项目中尽可能早地面对规格说明书中的挑战。这意味着测试不仅仅是评定软件的质量，还可以尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。参与前期工作的测试者可以预先估计问题和难度，这将可以显著地减少总体测试时间，加快项目进度。
根据W模型的要求，一旦有文档提供，就要及时确定测试条件，以及编写测试用例，这些工作对测试的各级别都有意义。当需求被提交后，就需要确定高级别的测试用例来测试这些需求。当概要设计编写完成后，就需要确定测试条件来查找该阶段的设计缺陷。
W模型也是有局限性的。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动。同样，软件开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可以正式开始下一个阶段。这样就无法支持迭代、自发性以及变更调整。对于当前很多文档需要事后补充，或者根本没有文档的做法(这已成为一种开发的文化)，开发人员和测试人员都面临同样的困惑。
类比记忆：W模型相当两个V模型的叠加，一个是开发的V，一个是测试的V，由于在项目中开发和测试的是同步进行，相当于两个V是并列同步的进行的，测试在一定程度是随着开发的进展而不断向前进行。
3、H模型
V模型和W模型均存在一些不妥之处。首先，如前所述，它们都把软件的开发视为需求、设计、编码等一系列串行的活动，而事实上，虽然这些活动之间存在相互牵制的关系，但在大部分时间内，它们是可以交叉进行的。虽然软件开发期望有清晰的需求、设计和编码阶段，但实践告诉我们，严格的阶段划分只是一种理想状况。试问，有几个软件项目是在有了明确的需求之后才开始设计的呢？所以，相应的测试之间也不存在严格的次序关系。同时，各层次之间的测试也存在反复触发、迭代和增量关系。其次，V模型和W模型都没有很好地体现测试流程的完整性。
为了解决以上问题，提出了H模型。它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。H模型如图3所示。
图3 H模型图
H模型图仅仅演示了在整个生存周期中某个层次上的一次测试“微循环”。图中的其他流程可以是任意开发流程。例如，设计流程和编码流程。也可以是其他非开发流程，例如，SQA流程，甚至是测试流程自身。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以(或者说需要)进行了。
概括地说，H模型揭示了：
1）软件测试不仅仅指测试的执行，还包括很多其他的活动。
2）软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。
3）软件测试要尽早准备，尽早执行。
4）软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。
在H模型中，软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。
4、X模型
Marick曾提出过一些观点和意见，其中首先是Marick不建议要建立一个替代模型。这里我很冒昧地引用了一些Marick的想法，并重新经过组织，形成了“X模型”。其实并不是为了和V模型相对应而选择这样的名字，而是由于其它一些原因：X通常代表未知，而Marick也认为他的观点并不足以支撑一个模型的完整描述，但其中已经有一个模型所需要的一些主要内容，其中也包括了象探索性测试（exploratory testing）这样的亮点。我还需要在使用文字方面也向Marick道歉，因为认同Marick观点的无疑大多属于X一代（X一代）。另外，我勾画了一张X形状的示意图，我相信该图能够很好地以另一种表达形式来体现Marick的观点。
图2--X模型示意图
由于X模型从没有被文档化，其内容一开始需要从在V模型的相关内容中进行推断，这在Marick的相关文章中已有体现。这里关于X模型的论述比较简短，因为它还没有完全从文字上成为V模型的全面扩展，而且我不想在这里重复在《软件测试：不可忽略的阶段》文章中所提到的很多测试技术的概念。
Marick对V模型的最主要批评是V模型无法引导项目的全部过程。他认为一个模型必须能处理开发的所有方面，包括交接，频繁重复的集成，以及需求文档的缺乏等等。
5、前置测试模型
前置测试是一个将测试和开发紧密结合的模型，该模型提供了轻松的方式，可以使你的项目加快速度。
前置测试模型体现了以下的要点：
开发和测试相结合
前置测试模型将开发和测试的生命周期整合在一起，标识了项目生命周期从开始到结束之间的关键行为。并且表示了这些行为在项目周期中的价值所在。如果其中有些行为没有得到很好的执行，那么项目成功的可能性就会因此而有所降低。
如果有业务需求，则系统开发过程将更有效率。我们认为在没有业务需求的情况下进行开发和测试是不可能的。而且，业务需求最好在设计和开发之前就被正确定义。
对每一个交付内容进行测试
每一个交付的开发结果都必须通过一定的方式进行测试。源程序代码并不是唯一需要测试的内容。在图中的被圈框表示了其它一些要测试的对象，包括可行性报告、业务需求说明，以及系统设计文档等。这同V模型中开发和测试的对应关系是相一致的，并且在其基础上有所扩展，变得更为明确。
前置测试模型包括2项测试计划技术，这也是属于上述21项需求测试技术中的一部分。其中的第一项技术是开发基于需求的测试用例。这并不仅仅是为以后提交上来的程序的测试做好初始化准备，也是为了验证需求是否是可测试的。这些测试可以交由用户来进行验收测试，或者由开发部门做某些技术测试。很多测试团体都认为，需求的可测试性即使不是需求首要的属性，也应是其最基本的属性之一。因此，在必要的时候可以为每一个需求编写测试用例。不过，基于需求的测试最多也只是和需求本身一样重要。一项需求可能本身是错误的，但它仍是可测试的。而且，你无法为一些被忽略的需求来编写测试用例。
第2项技术是定义验收标准。在接受交付的系统之前，用户需要用验收标准来进行验证。验收标准并不仅仅是定义需求，还应在前置测试之前进行定义，这将帮助揭示某些需求是否正确，以及某些需求是否被忽略了。
在设计阶段进行计划和测试设计
设计阶段是做测试计划和测试设计的最好时机。
在V模型中，验收测试最早被定义好，并在最后执行，以验证所交付的系统是否真正符合用户业务的需求。
与V模型不同的是，前置测试模型认识到验收测试中所包含的3种成份，其中的2种都与业务需求定义相联系：即定义基于需求的测试，以及定义验收标准。但是，第三种则需要等到系统设计完成，因为验收测试计划是由针对按设计实现的系统来进行的一些明确操作定义所组成，这些定义包括：如何判断验收标准已经达到，以及基于需求的测试已算成功完成。
技术测试主要是针对开发代码的测试，例如V模型中所定义的动态的单元测试，集成测试和系统测试。另外，前置测试还提示我们应增加静态审查，以及独立的QA测试。
QA测试通常跟随在系统测试之后，从技术部门的意见和用户的预期方面出发，进行最后的检查.同样的还有特别测试。我们取名特别测试，并把该名称作为很多测试的一个统称，这些测试包括负载测试、安全性测试、可用性测试等等，这些测试不是由业务逻辑和应用来驱动的。
对技术测试最基本的要求是验证代码的编写和设计的要求是否相一致。一致的意思是系统确实提供了要求提供的，并且系统并没有提供不要求提供的。技术测试在设计阶段进行计划和设计，并在开发阶段由技术部门来执行。
6、测试模型的使用
前面我们介绍了几种典型的测试模型，应该说这些模型对指导测试工作的进行具有重要的意义，但任何模型都不是完美的。我们应该尽可能地去应用模型中对项目有实用价值的方面，但不强行地为使用模型而使用模型，否则也没有实际意义。
在这些模型中，V模型强调了在整个软件项目开发中需要经历的若干个测试级别，而且每一个级别都与一个开发级别相对应，但它忽略了测试的对象不应该仅仅包括程序，或者说它没有明确地指出应该对软件的需求、设计进行测试，而这一点在W模型中得到了补充。W模型强调了测试计划等工作的先行和对系统需求和系统设计的测试，但W模型和V模型一样也没有专门对软件测试流程予以说明，因为事实上，随着软件质量要求越来越为大家所重视，软件测试也逐步发展成为一个独立于软件开发的一系列活动，就每一个软件测试的细节而言，它都有一个独立的操作流程。比如，现在的第三方测试，就包含了从测试计划和测试用例编写，到测试实施以及测试报告编写的全过程，这个过程在H模型中得到了相应的体现，表现为测试是独立的。也就是说，只要测试前提具备了，就可以开始进行测试了。
因此，在实际的工作中，我们要灵活地运用各种模型的优点，在W模型的框架下，运用H模型的思想进行独立的测试，并同时将测试与开发紧密结合，寻找恰当的就绪点开始测试并反复迭代测试，最终保证按期完成预定目标。
试并反复迭代测试，最终保证按期完成预定目标。
1、瀑布模型
瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
1）为项目提供了按阶段划分的检
查点。
2）当前一阶段完成后，您只需要去关注后续阶段。
3）可在迭代模型中应用瀑布模型。
增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
1）在项目各个阶段之间极少有反馈。
2）只有在项目生命周期的后期才能看到结果。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
2、原型模型
原型模型的主要思想：
先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的。
原型模型通过向用户提供原型获取用户的反馈，使开发出的软件能够真正反映用户的需求。同时，原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈作出快速的响应。相对瀑布模型而言，原型模型更符合人们开发软件的习惯，使目前较流行的一种实用软件生存期模型。
原型模型的特点：
(1）开发人员和用户在“原型”上达成一致。这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。
（2）缩短了开发周期，加快了工程进度。
（3）降低成本。
原型模型的缺点：
当告诉用户，还必须重新生产该产品时，用户是很难接受的。这往往给工程继续开展带来不利因素。
不宜利用原型系统作为最终产品。采用原型模型开发系统，用户和开发者必须达成一致：原型被建造仅仅是用户用来定义需求，之后便部分或全部抛起，最终的软件是要充分考虑了质量和可维护性等方面之后才被开发。
3、螺旋模型
螺旋模型采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版本。使用它，项目经理在早期就能够为客户实证某些概念。该模型是快速原型法，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。采用螺旋模型的软件过程如下图所示:：
软件过程
螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。对于这些系统，风险是软件开发不可忽视且潜在的不利因素，它可能在不同程度上损害软件开发过程，影响软件产品的质量。减小软件风险的目标是在造成危害之前，及时对风险进行识别及分析，决定采取何种对策，进而消除或减少风险的损害。
四种象限
螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：
四种象限
（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；
（3）实施工程：实施软件开发和验证；
（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。
螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。
螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。在实践中，螺旋法技术和流程变得更为简单。迭代方法体系更倾向于按照开发/设计人员的方式工作，而不是项目经理的方式。螺旋模型中存在众多变量，并且在将来会有更大幅度的增长，该方法体系正良好运作着。下表是螺旋法能够解决的各种问题：
| 经常遇到的问题 | 螺旋模型的解决方案 |
| 用户需求不够充分 | 允许并鼓励用户反馈信息 |
| 沟通不明 | 在项目早期就消除严重的曲解 |
| 刚性的体系(Overwhelming architectures) | 开发首先关注重要的业务和问题 |
| 主观臆断 | 通过测试和质量保证,作出客观的评估 |
| 潜在的不一致 | 在项目早期就发现不一致问题 |
| 糟糕的测试和质量保证 | 从第一次迭代就开始测试 |
| 采用瀑布法开发 | 在早期就找出并关注风险 |
（1）螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。
（2）如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。
（3）软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险
一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。
1）设计上的灵活性,可以在项目的各个阶段进行变更。
2）以小的分段来构建大型系统,使成本计算变得简单容易。
3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
4）随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。
5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。
螺旋模型的项目适用：
对于新近开发，需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更！
每轮循环包含如下六个步骤：
1. 确定目标，可选项，以及强制条件。
2. 识别并化解风险。
3. 评估可选项。
4. 开发并测试当前阶段。
5. 规划下一阶段。
6. 确定进入下一阶段的方法步骤。
软件测试全栈专题系列课程https://edu.csdn.net/combo/detail/2221
Jmeter高级性能测试实战https://edu.csdn.net/course/detail/35834RobotFramework+Jmeter接口自动化测试课程https://edu.csdn.net/course/detail/36152Fiddler接口抓包神器使用教程https://edu.csdn.net/course/detail/32782零基础新手入门软件测试必知必会https://edu.csdn.net/course/detail/32598
844
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
