测试汇总
软件测试基础
第二次实训成果展示
艾瑞科技有限公司
撰写人：刘文庆
版本：v2.0
时间：2015/9/28
目录
第二次实训成果展示... 1
1知识点总结... 4
1．1知识点重点考点.. 4
1.1.1什么叫做软件？.. 4
1.1.2什么叫做软件测试？.. 4
1.1.3软件生命周期有哪几部分？.. 5
1.1.4软件生命周期的模型有哪几部分？软件测试过程的模型有哪些？.. 5
1.1.5V模型的画法.. 5
1.1.6软件测试的思维.. 6
1.1.7软件测试过程及内容.. 6
1.1.8软件测试过程模型.. 7
1.1.9 软件测试分类.. 7
1.1.10缺陷的基本信息：.. 8
1.1.11缺陷流程：.. 8
1.1.12模型：.. 8
1.1.13静态测试概念：.. 8
1.1.14行评审的概念：.. 8
1.1.15一套完整的测试应该由哪些阶段组成？.. 8
1.1.16测试的主要内容？.. 9
1.1.17集成测试也叫组装测试或者联合测试，请简述集成测试的主要内容？.. 9
1.1.18述集成测试与系统测试关系？.. 9
1.1.19件测试的文档测试应当贯穿于软件生命周期的全过程，其中用户文档是文档测试的重点。那么软件系统的用户文档包括哪些？iPhone iPhoneiPhone. 9
1.1.20出bug报告当中一些必备的内容。.. 10
1.2 Testlink与.mantis总结.. 10
1.2.1 mantis与testlink的过程结合简图.. 10
1.2.2testlink步骤及用法.. 11
1.2.3testlink的过程注意点.. 12
1.2.4testlink中各角色职责.. 13
1.2.5mantis功能及使用流程及步骤介绍.. 14
2 mantis 与testlink常见问题及解决方案... 22
2.1. 22
2.2Mantis提交缺陷时超慢的原因和解决办法.. 24
3 测试用例的方法... 27
3.1黑盒概述.. 27
3．1.1.等价类划分法.. 27
3．1.2 边界值分析法.. 32
3．1.3错误推断法.. 41
3．1.4 因果图法.. 42
3．1.5 判定表驱动法.. 48
3.1.6 正交试验法.. 57
3.1.7 功能图法.. 58
3.1.8 场景法.. 60
3.2 白盒.. 64
3.2.1白盒测试定义.. 64
3.2．2白盒测试方法.. 64
4测试用例设计综合策略... 65
1.提出了使用各种测试方法的综合策略：.. 65
2.测试用例的设计步骤】.. 65
5 用例中作业中所遇到的问题及重点... 66
5.1测试用例中所遇到的问题及注意事项.. 66
5.2审核篇.. 67
6创新思维模块... 68
1 excel与testlink的结合.. 68
2黑盒，用例思维的延展性.. 70
3问题库 资源库的创建.. 70
问题库，提问单以及资源库.. 71
的使用说明以及各个组绩效考核.. 71
7 学习总结... 72
1知识点总结
1．1知识点重点考点
（注：由于牵扯接下来的面试，笔试，所以我把知识点总结以考题的形式总结）
1.1.1什么叫做软件？
程序+数据库+文档
1.1.2什么叫做软件测试？
通过手工或自动化手段来检测软件中存在缺陷的过程。进行软件测试的依据是什么？
需求，测试是对需求验证的过程
是否满足用户的需求；发现软件中存在的缺陷
1.1.3软件生命周期有哪几部分？
计划、需求分析、设计、编码、测试、运行和维护
急需维测设编行
1.1.4软件生命周期的模型有哪几部分？软件测试过程的模型有哪些？
瀑布迭代螺旋快速增量 vwh
1.1.5V模型的画法
用户需求——分析需求——概要设计 —— 详细设计——编码——单元测试——集成设计——确认测试——验收测试
用户的需求要进行析要进行概要设计与详细设计，进而编码，对单元集成系统进行分析
（1）显示缺陷的存在
（2）穷尽测试是不可能的
（3）测试尽早介入
（4）缺陷集群性
（5）杀虫剂悖论
（6）不存在缺陷的系统就是有用的系统的谬论
（7）测试活动依赖于测试背景；
早介入 /3 早发现 /1 早治疗/5 在集群性/4的背景下 /7 全部干掉（坏虫）是不可能的 2 但是不要就得不存在缺陷的 就是有用的7
测试尽早介入（测试早介入，耗费的成本要低，效率也会高）；
缺陷集群性（80-20原则，在某一个阶段大多数的错误可能会出现在某个模块，甚至是相同的错误）；
杀虫剂悖论（当用某一种测试方法无法在找出缺陷时，要及时更换测试用例）；不存在缺陷（就是有用系统）的谬论（如果系统不满足用户的需求，发现和修改缺陷无意义）
1.1.6软件测试的思维
先正向，后反向
（1）测试是为了证明程序有错，而不是证明程序无错
（2）一个好的测试用例在于它能够发现以前从未发现的错误
（3）一个成功的测试是发现了以前未发现的错误的测试
证明有错
1.1.7软件测试过程及内容
软件测试过程图你有啥测试的需求计划 就设计执行一下 其他的人就记录分析完毕总结一下
缺陷报告要追4 完毕追3
1.1.8软件测试过程模型
软件测试过程模型有V，W，H三种比较常见的模型
V模型表示了测试的各个阶段和开发阶段的对应关系，局限性在于问题不能过早的发现。
W模型是V模型的扩展，测试和开发是同步的，有利于尽早的发现问题。局限性在于这一系列的过程还是呈现线性关系，如果前面的项目文档资料不完整的情况下不能进行此模型。
H模型在于它的测试活动是完全独立的，整个流程和准备都是独立进行的。
1.1.9 软件测试分类
软件测试的分类：从5个方面对软件测试进行划分
是否关心内部结构：白盒测试（注重于内部结构，又称为逻辑测试或是结构测试）、黑盒测试（注重于软件的功能，比如界面是否满足用户的需求）、灰盒测试（介于白盒和黑盒之间，它不像白盒那样详细、完整、但比黑盒更注重于内部逻辑）
开发过程级别：单元测试（偏向于白盒测试，它测试的是每个单元模块的程序结构）、集成测试（集成是单元和单元拼在一起，不注重单元与单元之间的内部结构，而更注重于单元和单元拼在一起后的接口是否正确，一般用灰盒来测）、系统测试（测试的是软件的一些功能，用黑盒来测）、验收测试（又称为用户测试，关注用户的需求）
是否执行程序：静态测试、动态测试
执行过程是否要人工干预：手动测试（规模、复用性小）、自动测试（规模大的产品）
测试实施组织：开发测试、用户测试、第三方测试
软测的分类：手自动静白灰黑 在用户开发以及第三方面前做单元集成系统的验收
干预执行内部结构，是由实施组织的级别决定的
1.1.10缺陷的基本信息：
1.缺陷标题 2、标识 3、报告人 4、报告日期 5、程序的名称 6、版本号 7、配置 8、缺陷类型 9、严重性 10、优先级 11、关键词 12、缺陷描述 13、重现步骤 14、结果对比 15、附件（截图，图片上有所描述）
好/6人/3尸/2体/1 配/7日/4称 /5关键/11严重/9的类型/8要优先/10描述 /12进行/13重现步骤 /14结果对比，自后添加/15附件
1.1.11缺陷流程：
发现缺陷->测试人员提交->new->项目经理分配->open->开发人员修正->reject->评审委员会评审通过->Closed
出现缺陷的最大原因在需求分析阶段，其次是在设计阶段
1.1.12模型：
2个V模型组成，在每一个阶段都会有相对应的测试（第六章）
TMM：测试成熟度模型，描述测试的过程。五个级别：初始级；定义级；集成级；管理和测量级；优化、预防缺陷和质量控制级
1.1.13静态测试概念：
通常是不执行程序代码而寻找代码中可能存在的错误或评估程序代码的过程。最常用而且最主要的方法是同行评审
1.1.14行评审的概念：
开发软件产品作者以外的其他人检查工作，已发现缺陷并寻找改进的机会
同行评审根据正式程度（由低到高）可以划分为5种评审方法：临时评审、桌面评审、走查、小组审查、审查。其中临时评审、桌面评审、走查无标准的流程，正式程度越高，发现的错误越多，成本也越高，一般这5种方法中使用最多的是临时评审
临时走动5步
1.1.15一套完整的测试应该由哪些阶段组成？
参考答案：测试计划、测试设计与开发、测试实施、测试评审与测试结论
同上记吧
1.1.16测试的主要内容？
参考答案：
模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
边界路径局部错误接口
1.1.17集成测试也叫组装测试或者联合测试，请简述集成测试的主要内容？
参考答案：
（1）在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
（2）一个模块的功能是否会对另一个模块的功能产生不利的影响；
（3）各个子功能组合起来，能否达到预期要求的父功能；
（4）全局数据结构是否有问题；
（5）单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
不利于/2父功能/3的接口/1误差/5会对全局的数据结构4产生影响
1.1.18述集成测试与系统测试关系？
参考答案：
（1）集成测试的主要依据概要设计说明书，系统测试的主要依据是需求设计说明书；
（2）集成测试是系统模块的测试，系统测试是对整个系统的测试，包括相关的软硬件平台、网络以及相关外设的测试。
1.1.19件测试的文档测试应当贯穿于软件生命周期的全过程，其中用户文档是文档测试的重点。那么软件系统的用户文档包括哪些？iPhone iPhoneiPhone
参考答案：
用户手册
安装和设置指导
联机帮助
指南、向导
样例、示例和模板
授权/注册登记表
最终用户许可协议
手册安装需要联机帮助 指南向导带着样例模版 最后终于注册登陆成功 有了一份许可协议
1.1.20出bug报告当中一些必备的内容。
参考答案：
硬件平台和操作系统
测试应用的硬件平台（Platform），通常选择“PC”。
测试应用的操作系统平台（OS）。
a) 版本
提交缺陷报告时通过该字段标识此缺陷存在于被测试软件的哪个版本。
b) Bug报告优先级
c) Bug状态
d) Bug的编号
e) 发现人
f) 提交人
版本平台优先状态发现提交人的编号
1.2 Testlink与.mantis总结
1.2.1 mantis与testlink的过程结合简图
项目里找需求 定计划 创用列 通结合 分工作 做执行 看结果
1.2.2testlink步骤及用法
1.2.3testlink的过程注意点
1estlink，熟练建立需求树，录入测试用例并执行
创建测试项目：例如在线考试系统。
创建需求规约：1）大体模块需求：例如前台功能测试
2）大体模块中各个小模块功能需求：例如登陆测试
创建测试计划：在测试用例完成之后要制定计划，其中包括计划名称和计划描述：例如在线考试系统——测试计划
创建测试里程碑：明确测试人员的测试计划，日期以及完成的优先级别
构建版本：若没有创建版本，用例是不被执行的：例如版本为ver1.0
创建测试用例：1）创建新的测试集：例如前台功能测试
2）测试集下新建测试用例：例如登陆验证
3）编写测试用例步骤
（与模块需求标识统一）
关联需求与用例：把产品需求指派给测试用例。当查看已指派的测试用例即可看到需求的覆盖率
添加测试用例到测试计划：选择一个测试计划，点击“添加/删除测试用例到测试计划”
分派测试任务给测试人员：“指派执行测试用例”可以将当前计划中的每个测试用例指派给具体测试人员
执行：可查看测试计划中测试用例执行情况：
1）通过
2）失败 bug
3）锁定 阻塞
4）尚未执行
测试结果的分析
点击“测试报告和度量”，保存结果，有多种保存形式，根据情况导出适当形式的文档
1.2.4 testlink中各角色职责
Testlink中有如下几种级别的角色：
Admin：进行一切可行性操作，只有此用户维护产品和用户；
Leader：拥有所有测试计划权限，编辑测试规范和执行测试；
Test designer：编辑测试规范和测试需求；
Senior tester：编辑测试规范和执行测试；
Tester：只能执行测试；
Guest：只能浏览数据。
根据软件测试的需求，用户admin可以创建其他几种类型用户，不同类型的账户有不同的操作权限，这样就可以将测试任务根据测试需求向下分派给不同的用户，从而使软件测试和管理过程能清晰高效的执行。
1.2.5mantis功能及使用流程及步骤介绍
1.2.7 mantis使用注意
mantis录入缺陷并设置缺陷的问题等级、优先级等要素，清晰填写问题描述及重现步骤
录入缺陷并设置缺陷的问题等级、优先级等要素（即提交问题，要区分问题的严重等级和优先等级，便于开发部门进行工作的先后分配）
清晰填写问题描述及重现步骤（清晰的问题描述和重现步骤可以让开发部门更容易理解，便于缺陷的更改）
1.2.8 mantis相关负责人
1、 开发人员： 根据客户要求进行需求分析，研发项目，
自测完提交给测试人员测试项目
根据测试人员的测试结果修改程序
2、 开发经理：
1.负责软件开发团队管理工作；
2.负责组织项目策划，提出立项申请，参与立项评审工作
3.负责组织产品需求调研、需求分析和概要设计工作
4.负责公司自有软件产品开发工作的组织实施，保证产品质量
5.负责开发过程的管理与监控
6.负责组织公司产品的技术支持工作
7.负责组织软件产品的售后支持和维护工作
3、 测试人员：
1.根据软件设计需求制定测试计划，设计测试数据和测试用例；
2.有效地执行测试用例，提交测试报告；
3.准确地定位并跟踪问题，推动问题及时合理地解决；
4.完成对产品的集成测试与系统测试，对产品的软件功能、性能及其它方面的测试;
4、 测试经理：
1.负责软件测试团队管理工作；
2.负责各类网站的性能/自动化测试工作；
3.负责带领测试团队，设计、执行、优化测试过程,丰富测试手段，引入新的测试框架和测试策略；
4.与其他测试人员、开发人员、项目管理人员沟通和协作，推动整个项目的顺利进行；
5.维护测试流程，统计和分析测试结果，提高测试效率和质量。
2 mantis 与testlink常见问题及解决方案
2.1
| 知识点 Testlink |
问题描述 |
解决方案 |
||
| 安装 |
安装上的testlink无法访问http://localhost/testlink的网页 |
将testlink的压缩文件包解压到XAMP的htdocs文件下，并且将文件重命名为testlink，mantis安装亦是如此 |
||
| B/S模式 |
无法对页面进行访问 |
先启动服务器xampp，然后才能对页面进行访问 |
||
| 兼容性 |
在使用testlink的测试文档编辑模块无法输入文字
|
在testlink界面按F12，将其改成与浏览器版本兼容的视图；还可以自行下载现版本 |
||
|
|
|
|
||
| 步骤 |
操作过程不熟悉，不知道每一步应该建什么 |
通过看视频，网上搜索，听同学讲解和自己动手实践逐渐掌握使用方法和建立过程 |
||
| 安装过程出现的问题： |
|
|
||
| 名词含义 |
不能够完全明白其中名词的意义 |
查询资料，询问老师和同学，了解其作用 |
||
|
|
用例无法指派
|
创建完用例之后，点击用例，选择关联计划
|
||
|
|
创建完计划，测试计划管理模块无法显示
|
创建完测试计划，要勾选里面的公共和活动
|
||
|
|
项目分配中报告员无法显示，开发员分派给报告员。
|
创建完项目之后，要添加用户，一类一类的添加，不能一起。同时要修改工作阀值下面的分配。
|
||
|
|
端口号改变
|
Testlink默认80端口，当端口改变时，输入网址时也应该输入对应的端口，再使用默认的locahost/testlink无法进入
|
||
|
|
Mantis创建项目 Mantis创建完项目在页面右上角找不到项目
|
创建时勾选“启用”选项
|
||
|
|
.在Testlink创建测试用例时把所有的步骤都写在一起了
|
要一步一步分开写步骤，每写完一步点击“保存”按钮，才能写下一个步骤
|
||
| 构建 |
没有进行构建，无法进行测试用例的关联 |
建立构建，并查出构建的作用 |
||
| 模块用途 |
有些模块不知道有什么用途，有些模块还不知道写些什么 |
逐个尝试，了解每个模块的作用 |
||
| 功能及用法 |
无法将excel的表格导入mantis界面。 |
提交Bug给mantis公司。 |
2.2Mantis提交缺陷时超慢的原因和解决办法
问题原因
如果出现以上情况，可以确定是由于mantis的邮件发送出现问题导致数据库负担加重，写入数据时间过长，Mantis访问越来越慢。
解决问题
Mantis默认添加用户时Email提醒设置如下：
可以看出很多情况下Mantis都是默认发送邮件，如果Mantis里面的用户和项目过多且操作频繁时就会有大量的邮件数据产生并写入数据库
Mantis数据库（默认：bugtracker）存储Email的表：mantis_email_table
所有待发送的邮件都存在该表中，该表具有如下性质：
如果邮件发送成功，表内数据将被自动删除
如果邮件没有发送成功，或者没有清理成功，就会造成表 mantis_email_table内数据的堆积。这样会造提交时响应延迟
测试Mantis邮件发送
退出mantis登录用户，点击‘忘记密码
填写用户名和联系邮箱
登录邮箱查看是否接受到邮件
如果没有接受到邮件可以判断是Mantis的邮件发送出现问题，导致了全部的邮件提醒滞留在mantis_email_table中
查看mantis_email_table
可以看到该表中存在大量的数据（实际查看时已经超过6000条）
删除表中全部数据（如果重要也可以不删除，恢复发送邮件功能会自动发送）
mysql>truncate table mantis_email_table;
修改Mantis的邮箱配置
***/mantis/config_default_inc.php
只需要将相应的邮箱修改为正确的邮箱保存设置
重启Mantis，提交缺陷此时有邮件提醒即可，如果之前未删除数据库会陆续收到数据库表中全部的邮件
如果进行以上操作Mantis仍然访问慢，请检查下列设置：
**/mantis/core/email_api.php
函数email_send（）负责邮件发送，检查函数email_send() 中邮件发送和邮件删除功能是否正常
修改PHP配置文件的memory_limit(默认为8M，可以修改为12
3 测试用例的方法
3.1黑盒概述
黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。
3．1.1.等价类划分法
概念
等价类划分法是把程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值
等价类划分法的应用
1. 等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类。
有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
无效等价类:与有效等价类的定义恰巧相反。
设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性。
2. 划分等价类的六大原则：
在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.
在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.
在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类. 布尔量是一个二值枚举类型, 一个布尔量具有两种状态: true 和 false 。
在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.
例：输入条件说明输入字符为:中文、英文、阿拉伯文三种之一，则分别取这三种这三个值作为三个有效等价类，另外把三种字符之外的任何字符作为无效等价类。
在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）
在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类
3．1.1.3 将等价类转化成测试用例：
按照[输入条件][有效等价类][无效等价类] 建立等价类表,列出所有划分出的等价类
为每一个等价类规定一个唯一的编号.
设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.
设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.原创速记理解记忆：划区域,分子集，创编号，设用例，有效一对多，无效单对单
等价类划分实例
1. 某程序规定："输入三个整数 a 、 b 、 c 分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型，当此三角形为一般三角形、等腰三角形及等边三角形时，分别作计算 … "。用等价类划分方法为该程序进行测试用例设计。（三角形问题的复杂之处在于输入与输出之间的关系比较复杂。）
分析题目中给出和隐含的对输入条件的要求：
（1）整数 （2）三个数 （3）非零数 （4）正数
（5）两边之和大于第三边 （6）等腰 （7）等边
如果 a 、 b 、 c 满足条件（ 1 ） ~ （ 4 ），则输出下列四种情况之一：
1)如果不满足条件（5），则程序输出为 " 非三角形 " 。
2)如果三条边相等即满足条件（7），则程序输出为 " 等边三角形 " 。
3)如果只有两条边相等、即满足条件（6），则程序输出为 " 等腰三角形 "。
4)如果三条边都不相等，则程序输出为 " 一般三角形 " 。 划区域,分子集
列出等价类表并编号 创编号
覆盖有效等价类的测试用例：设用例
a b c 覆盖等价类号码
3 4 5 （1）--（7）
4 4 5 （1）--（7），（8）
4 5 5 （1）--（7），（9） 有效一对多
5 4 5 （1）--（7），（10）
4 4 4 （1）--（7），（11）
覆盖无效等价类的测试用例：无效单对单
2. 设有一个档案管理系统，要求用户输入以年月表示的日期。假设日期限定在1990年1月~2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的"日期检查功能"。（不考虑2月的问题）
1)划分等价类并编号,下表等价类划分的结果。 划区域,分子集 创编号
| 输入等价类 |
有效等价类 |
无效等价类 |
| 日期的类型及长度 |
①6位数字字符 |
②有非数字字符 ③少于6位数字字符 ④多于6位数字字符 |
| 年份范围 |
⑤在1990~2049之间 |
⑥小于1990 ⑦大于2049 |
| 月份范围 |
⑧在01~12之间 |
⑨等于00 ⑩大于12 |
2)设计测试用例，以便覆盖所有的有效等价类在表中列出了3个有效等价类，编号分别为①、⑤、⑧，设计的测试用例如下：设用例，有效一对多，无效单对单
测试数据 期望结果 覆盖的有效等价类
200211 输入有效 ①、⑤、⑧
3)为每一个无效等价类设计一个测试用例，设计结果如下：
测试数据 期望结果 覆盖的无效等价类
95June 无效输入 ②
20036 无效输入 ③
2001006 无效输入 ④
198912 无效输入 ⑥
200401 无效输入 ⑦
200100 无效输入 ⑨
200113 无效输入 ⑩
3．1.2 边界值分析法
概念
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
边界值分析法的应用
根据大量的测试统计数据，很多错误是发生在输入或输出范围的边界上，而不是发生在输入/输出范围的中间区域。因此针对各种边界情况设计测试用例，可以查出更多的错误。
使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
1. 边界值分析法与等价类分析法的区别：
1) 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
2) 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。
例：测试计算平方根的函数
--输入：实数
--输出：实数
--需求说明：当输入一个0或比0大的数的时候，返回其正平方根；当输入一个小于0的数时，显示错误信息"平方根非法-输入值小于0"并返回0；库函数Print-Line可以用来输出错误信息。
A. 等价类划分：
I.可以考虑作出如下划分：
a、输入 (i)<0 和 (ii)>=0
b、输出 (a)>=0 和 (b) Error
II.测试用例有两个：
a、输入4，输出2。对应于 (ii) 和 (a) 。
b、输入-10，输出0和错误提示。对应于 (i) 和 (b)。
B. 边界值分析：
划分(ii)的边界为0和最大正实数；划分(i)的边界为最小负实数和0。由此得到以下测试用例：
a、输入 {最小负实数}
b、输入 {绝对值很小的负数}
c、输入 0
d、输入 {绝对值很小的正数}
e、输入 {最大正实数}
2. 通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。
3. 相应地，以上类型的边界值应该在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、 最短/最长、 空/满等情况下。利用边界值作为测试数据
| 项 |
边界值 |
测试用例的设计思路 |
| 字符 |
起始-1个字符/结束+1个字符 |
假设一个文本输入区域允许输入1个到255个 字符，输入1个和255个字符作为有效等价类；输入0个和256个字符作为无效等价类，这几个数值都属于边界条件值。 |
| 数值 |
最小值-1/最大值+1 |
假设某软件的数据输入域要求输入5位的数据值，可以使用10000作为最小值、99999作为最大值；然后使用刚好小于5位和大于5位的 数值来作为边界条件。 |
| 空间 |
小于空余空间一点/大于满空间一点 |
例如在用U盘存储数据时，使用比剩余磁盘空间大一点（几KB）的文件作为边界条件。 |
4. 内部边界值分析：
在多数情况下，边界值条件是基于应用程序的功能设计而需要考虑的因素，可以从软件的规格说明或常识中得到，也是最终用户可以很容易发现问题的。然而，在测试用例设计过程中，某些边界值条件是不需要呈现给用户的，或者说用户是很难注意到的，但同时确实属于检验范畴内的边界条件，称为内部边界值条件或子边界值条件。
内部边界值条件主要有下面几种：
1) 数值的边界值检验：计算机是基于二进制进行工作的，因此，软件的任何数值运算都有一定的范围限制。
| 项 |
范围或值 |
| 位（bit） |
0 或 1 |
| 字节（byte） |
0 ~ 255 |
| 字（word） |
0~65535（单字）或 0~4294967295（双字） |
| 千（K） |
1024 |
| 兆（M） |
1048576 |
| 吉（G） |
1073741824 |
2) 字符的边界值检验：在计算机软件中，字符也是很重要的表示元素，其中ASCII和Unicode是常见的编码方式。如下列出了一些常用字符对应的ASCII码值。
| 字符 |
ASCII码值 |
| 空 (null) |
0 |
| 空格 (space) |
32 |
| 可输入的字符 |
33~126 |
| 0~9 |
48~57 |
| A~Z |
65~90 |
| a~z |
97~122 |
3) 其它边界值检验：在不同的行业应用领域，依据硬件和软件的标准不同而具有各自特定的边界值。如下列出部分手机相关的边界值：
| 硬件设备 |
范围或值 |
| 手机锂电池电压 |
工作电压：3.6~4.2V； 保护电压：2.5~3V不等 |
| 手机正常使用温度 |
-25°C~+60°C |
5. 基于边界值分析方法选择测试用例的原则
1) 如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。
例如，如果程序的规格说明中规定："重量在10公斤至50公斤范围内的邮件，其邮费计算公式为……"。作为测试用例，我们应取10及50，还应取10.01,49.99,9.99及50.01等。
2) 如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。
例如，一个输入文件应包括1~255个记录，则测试用例可取1和255，还应取0及256等。
3) 将规则1）和2）应用于输出条件，即设计测试用例使输出值达到边界值及其左右的值。
例如，某程序的规格说明要求计算出"每月保险金扣除额为0至1165.25元"，其测试用例可取0.00及1165.24、还可取一0.01及1165．26等。
再如一程序属于情报检索系统，要求每次"最少显示1条、最多显示4条情报摘要"，这时我们应考虑的测试用例包括1和4，还应包括0和5等。
4) 如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。
5) 如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。
6) 分析规格说明,找出其它可能的边界条件。
原创速记理解记忆：边界值分析法分边和界，有效取双边，无效刚越界
实例
1. 现有一个学生标准化考试批阅试卷,产生成绩报告的程序。其规格说明如下:程序的输入文件由一些有80个字符的记录组成,如右图所示，所有记录分为3组：
1) 标题：这一组只有一个记录，其内容为输出成绩报告的名字。
2) 试卷各题标准答案记录：每个记录均在第80个字符处标以数字"2"。该组的第一个记录的第1至第3个字符为题目编号（取值为1一999）。第10至第59个字符给出第1至第50题的答案（每个合法字符表示一个答案）。该组的第2，第3……个记录相应为第51至第100，第101至第150，…题的答案。
3) 每个学生的答卷描述：该组中每个记录的第80个字符均为数字"3"。每个学生的答卷在若干个记录中给出。如甲的首记录第1至第9字符给出学生姓名及学号，第10至第59字符列出的是甲所做的第1至第50题的答案。若试题数超过50，则第2，第3……纪录分别给出他的第51至第100，第101至第150……题的解答。然后是学生乙的答卷记录。
4) 学生人数不超过200，试题数不超过999。
5) 程序的输出有4个报告：
a)按学号排列的成绩单，列出每个学生的成绩、名次。
b)按学生成绩排序的成绩单。
c)平均分数及标准偏差的报告。
d)试题分析报告。按试题号排序，列出各题学生答对的百分比。
解答：分别考虑输入条件和输出条件，以及边界条件。给出下表所示的输入条件及相应的测试用例。
输出条件及相应的测试用例表。
2. 三角形问题的边界值分析测试用例
在三角形问题描述中，除了要求边长是整数外，没有给出其它的限制条件。在此，我们将三角形每边边长的取范围值设值为[1, 100] 。
| 测试用例 |
a |
b |
c |
预期输出 |
| Test1 Test2 Test3 Test4 Test5 |
60 60 60 50 50 |
60 60 60 50 50 |
1 2 60 99 100 |
等腰三角形 等腰三角形 等边三角形 等腰三角形 非三角形 |
| Test6 Test7 Test8 Test9 |
60 60 50 50 |
1 2 99 100 |
60 60 50 50 |
等腰三角形 等腰三角形 等腰三角形 非三角形 |
| Test10 Test11 Test12 Test13 |
1 2 99 100 |
60 60 50 50 |
60 60 50 50 |
等腰三角形 等腰三角形 等腰三角形 非三角形 |
3. NextDate函数的边界值分析测试用例
在NextDate函数中，隐含规定了变量mouth和变量day的取值范围为1≤mouth≤12和1≤day≤31，并设定变量year的取值范围为1912≤year≤2050 。
| 测试用例 |
mouth |
day |
year |
预期输出 |
| Test1 Test2 Test3 Test4 Test5 Test6 Test7 |
6 6 6 6 6 6 6 |
15 15 15 15 15 15 15 |
1911 1912 1913 1975 2049 2050 2051 |
1911.6.16 1912.6.16 1913.6.16 1975.6.16 2049.6.16 2050.6.16 2051.6.16 |
| Test8 Test9 Test10 Test11 Test12 Test13 |
6 6 6 6 6 6 |
-1 1 2 30 31 32 |
2001 2001 2001 2001 2001 2001 |
day超出[1…31] 2001.6.2 2001.6.3 2001.7.1 输入日期超界 day超出[1…31] |
| Test14 Test15 Test16 Test17 Test18 Test19 |
-1 1 2 11 12 13 |
15 15 15 15 15 15 |
2001 2001 2001 2001 2001 2001 |
Mouth超出[1…12] 2001.1.16 2001.2.16 2001.11.16 2001.12.16 Mouth超出[1…12] |
3．1.3错误推断法
概念
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。
原创速记理解记忆：易错直觉
错误推断法的应用
基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。
1. 例如, 输入数据和输出数据为0的情况；输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。
2. 例如，前面例子中成绩报告的程序，采用错误推测法还可补充设计一些测试用例：
1) 程序是否把空格作为回答
2) 在回答记录中混有标准答案记录
3) 除了标题记录外，还有一些的记录最后一个字符即不是2也不是3
4) 有两个学生的学号相同
5) 试题数是负数
3. 例如，测试一个对线性表（比如数组）进行排序的程序，可推测列出以下几项需要特别测试的情况：
1) 输入的线性表为空表；
2) 表中只含有一个元素；
3) 输入表中所有元素已排好序；
4) 输入表已按逆序排好；
5) 输入表中部分或全部元素相同。
4. 例如，测试手机终端的通话功能，可以设计各种通话失败的情况来补充测试用例：
1) 无SIM 卡插入时进行呼出（非紧急呼叫）
2) 插入已欠费SIM卡进行呼出
3) 射频器件损坏或无信号区域插入有效SIM卡呼出
4) 网络正常，插入有效SIM卡，呼出无效号码（如1、888、333333、不输入任何号码等）
5) 网络正常，插入有效SIM卡，使用“快速拨号”功能呼出设置无效号码的数字
3．1.4 因果图法
概念
因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
因果图法的应用
等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。
如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。
1. 因果图介绍
1) 4种符号分别表示了规格说明中向4种因果关系。
2) 因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。
3) C1表示原因，通常置于图的左部；e1表示结果，通常在图的右部。C1和e1均可取值0或1，0表示某状态不出现，1表示某状态出现。
2. 因果图涉及的概念
1) 关系
恒等：若c1是1，则e1也是1；否则e1为0。
非：若c1是1，则e1是0；否则e1是1。
或：若c1或c2或c3是1，则e1是1；否则e1为0。“或”可有任意个输入。
与：若c1和c2都是1，则e1为1；否则e1为0。“与”也可有任意个输入。
2) 约束
输入状态相互之间还可能存在某些依赖关系，称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。
输入条件的约束有以下4类：
E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1。
I约束（或）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。
O约束（唯一）；a和b必须有一个，且仅有1个为1。
R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。
输出条件约束类型
输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0。
3. 采用因果图法设计测试用例的步骤：
1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。
2) 分析软件规格说明描述中的语义，找出原因与结果之间, 原因与原因之间对应的关系，根据这些关系,画出因果图。
3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现，为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。
4) 把因果图转换为判定表。
5) 把判定表的每一列拿出来作为依据,设计测试用例。
原创速记理解记忆：什么原因导致什么结果，因间元素关系连接异或唯一强制要求
果中关系连接或与非加恒等
实例
1. 某软件规格说明书包含这样的要求：第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改，但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。
解答：
1) 根据题意，原因和结果如下：
原因：
1——第一列字符是A；
2——第一列字符是B；
3——第二列字符是一数字。
结果：
21——修改文件；
22——给出信息L；
23——给出信息M。
2) 其对应的因果图如下：
11为中间节点；考虑到原因1和原因2不可能同时为1，因此在因果图上施加E约束。
3) 根据因果图建立判定表。
表中8种情况的左面两列情况中，原因①和原因②同时为1，这是不可能出现的，故应排除这两种情况。表的最下一栏给出了6种情况的测试用例，这是我们所需要的数据。
2. 有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下：若投入5角钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。
1) 分析这一段说明，列出原因和结果
原因：
1——售货机有零钱找
2——投入1元硬币
3——投入5角硬币
4——押下橙汁按钮
5——.押下啤酒按钮
结果：
21——售货机〖零钱找完〗灯亮
22——退还1元硬币
23——退还5角硬币
24——送出橙汁饮料
25——送出啤酒饮料
2) 画出因果图，如图所示。所有原因结点列在左边，所有结果结点列在右边。建立中间结点，表示处理的中间状态。中间结点：
11—— 投入1元硬币且押下饮料按钮
12——押下〖橙汁〗或〖啤酒〗的按钮
13——应当找5角零钱并且售货机有零钱找
14——钱已付清
3) 转换成判定表：
4) 在判定表中，阴影部分表示因违反约束条件的不可能出现的情况，删去。第16列与第32列因什么动作也没做，也删去。最后可根据剩下的16列作为确定测试用例的依据。
3．1.5 判定表驱动法
概念
判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。 判定表驱动法
1. 判定表的优点
能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。
在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。
2. “阅读指南”判定表
| 1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
||
| 问题 |
觉得疲倦？ |
Y |
Y |
Y |
Y |
N |
N |
N |
N |
| 感兴趣吗？ |
Y |
Y |
N |
N |
Y |
Y |
N |
N |
|
| 糊涂吗？ |
Y |
N |
Y |
N |
Y |
N |
Y |
N |
|
| 建议 |
重读 |
√ |
|||||||
| 继续 |
√ |
||||||||
| 跳下一章 |
√ |
√ |
|||||||
| 休息 |
√ |
√ |
√ |
√ |
3. 判定表通常由四个部分组成如下图所示。
1) 条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
2) 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3) 条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
4) 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
4. 规则及规则合并
1) 规则：任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。
2) 化简：就是规则合并有两条或多条规则具有相同的动作，并且其条件项之间存在着极为相似的关系。
5. 规则及规则合并举例
1) 如下图左端，两规则动作项一样，条件项类似，在1、2条件项分别取Y、N时，无论条件3取何值，都执行同一操作。即要执行的动作与条件3无关。于是可合并。“－”表示与取值无关。
2) 与上类似，下图中，无关条件项“－”可包含其他条件项取值，具有相同动作的规则可合并。
3) 化简后的读书指南判定表
| 1 |
2 |
3 |
4 |
||
| 问题 |
你觉得疲倦吗？ |
- |
- |
Y |
N |
| 你对内容感兴趣吗？ |
Y |
Y |
N |
N |
|
| 书中内容使你胡涂吗？ |
Y |
N |
- |
- |
|
|
建议 |
请回到本章开头重读 |
x |
|||
| 继续读下去 |
X |
||||
| 跳到下一章去读 |
x |
||||
| 停止阅读，请休息 |
x |
. 判定表的建立步骤：（根据软件规格说明）
1) 确定规则的个数.假如有n个条件。每个条件有两个取值（0,1）,故有2n种规则。
2) 列出所有的条件桩和动作桩。
3) 填入条件项。
4) 填入动作项。等到初始判定表。
5) 简化.合并相似规则（相同动作）。
实例
1. 问题要求：”……对功率大于50马力的机器、维修记录不全或已运行10年以上的机器，应给予优先的维修处理……” 。这里假定，“维修记录不全”和“优先维修处理”均已在别处有更严格的定义。请建立判定表。
解答：
1) 确定规则的个数：这里有3个条件，每个条件有两个取值，故应有2*2*2=8种规则。
2) 列出所有的条件茬和动作桩：
3) 填入条件项。可从最后1行条件项开始，逐行向上填满。如第三行是： Y N Y N Y N Y N，第二行是： Y Y N N Y Y N N等等。
4) 填入动作桩和动作顶。这样便得到形如图的初始判定表。
| 1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
||
| 条件 |
功率大于50马力吗？ |
N |
Y |
Y |
Y |
N |
N |
N |
N |
| 维修记录不全吗？ |
Y |
Y |
N |
N |
Y |
Y |
N |
N |
|
| 运行超过10年吗？ |
Y |
N |
Y |
N |
Y |
N |
Y |
N |
|
| 动作 |
进行优先处理 |
x |
x |
X |
X |
X |
|||
| 作其他处理 |
X |
x |
x |
初始判定表
5) 化简，合并相似规则后得到图。
| 1 |
2 |
3 |
4 |
5 |
||
| 条件 |
功率大于50马力吗？ |
Y |
Y |
Y |
N |
N |
| 维修记录不全吗？ |
Y |
N |
N |
- |
- |
|
| 运行超过10年吗？ |
- |
Y |
N |
Y |
N |
|
| 动作 |
进行优先处理 |
x |
x |
X |
||
| 作其他处理 |
x |
x |
2. NextData函数的精简决策表
M1＝{月份， 每月有30天}
M2＝{月份， 每月有31天}
M3＝{月份， 2月} 有29＝512条规则
D1＝{日期，1～28} 12月末31日和其它31
D2＝{日期，29} 日月份的31日处理不同
D3＝{日期，30} 平年2月28日处理不同
D4＝{日期，31} 于2月27日
Y1 ＝{年：年是闰年}
Y2 ＝{年：年不是闰年}
改进为：
M1＝{月份： 每月有30天}
M2＝{月份： 每月有31天， 12月除外}
M4＝{月份：12月}
M3＝{月份： 2月}
D1＝{日期：1<=日期<=27}
D2＝{日期：28}
D3＝{日期：29}
D4＝{日期：30}
D5＝{日期：31}
Y1 ＝{年：年是闰年}
Y2 ＝{年：年不是闰年}
输入变量间存在大量逻辑关系的NextData决策表
3. 用决策表测试法测试以下程序：该程序有三个输入变量month、day、year（month、day和year均为整数值，并且满足：1≤month≤12和1≤day≤31），分别作为输入日期的月份、日、年份，通过程序可以输出该输入日期在日历上隔一天的日期。
例如，输入为2004年11月29日，则该程序的输出为2000年12月1日。
1) 分析各种输入情况，列出为输入变量month、day、year划分的有效等价类。
2) 分析程序规格说明，结合以上等价类划分的情况给出问题规定的可能采取的操作（即列出所有的动作桩）。
3) 根据（1）和（2），画出简化后的决策表。
案例分析如下：
month变量的有效等价类：
M1:{month=4,6,9,11} M2:{month=1,3,5,7,8,10}
M3: {month=12 }M4:{month=2}
day变量的有效等价类：
D1:{1≤day≤26} D2:{day=27} D3:{day=28} D4:{day=29} D5:{day=30} D6:{day=31}
year变量的有效等价类：
Y1: {year是闰年} Y2: {year不是闰年}
4) 考虑各种有效的输入情况，程序中可能采取的操作有以下六种：
a1:day+2 a2:day=2 a3:day=1
a4:month+1 a5:month=1 a6:year+1
4. 判定表在功能测试中的应用
1) 一些软件的功能需求可用判定表表达得非常清楚，在检验程序的功能时判定表也就成为一个不错的工具。如果一个软件的规格说明指出：
当条件1和条件2满足，并且条件3和条件4不满足，或者当条件1、3和条件4满足时，要执行操作1。
在任一个条件都不满足时，要执行操作2。
在条件1不满足，而条件4被满足时，要执行操作3。根据规格说明得到如下判定表：
这里，判定表只给出了16种规则中的8种。事实上，除这8条以外的一些规则是指当不能满足指定的条件，执行3种操作时，要执行1个默许的操作。在没必要时，判定表通常可略去这些规则。但如果用判定表来设计测试用例，就必须列出这些默许规则（如下表）。
| 规则5 |
规则6 |
规则7 |
规则8 |
|
| 条件1 |
- |
N |
Y |
Y |
| 条件2 |
- |
Y |
Y |
N |
| 条件3 |
Y |
N |
N |
N |
| 条件4 |
N |
N |
Y |
- |
| 默许操作 |
x |
x |
x |
x |
默许的规则
2) 判定表的优点和缺点
优点：它能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏。
缺点：不能表达重复执行的动作，例如循环结构。
3) B. Beizer 指出了适合使用判定表设计测试用例的条件：
规格说明以判定表形式给出,或很容易转换成判定表。
条件的排列顺序不会也不影响执行哪些操作。
规则的排列顺序不会也不影响执行哪些操作。
每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则。
如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要。
B. Beizer提出这5个必要条件的目的是为了使操作的执行完全依赖于条件的组合。其实对于某些不满足这几条的判定表，同样可以借以设计测试用例，只不过尚需增加其它的测试用例罢了。
3.1.6 正交试验法
概念
依据Galois理论,从大量的（实验）数据（测试例）中挑选适量的,有代表性的点（例）,从而合理地安排实验（测试）的一种科学实验设计方法.类似的方法有:聚类分析方法,因子方法方法等.
正交试验法
利用因果图来设计测试用例时, 作为输入条件的原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到。往往因果关系非常庞大,以至于据此因果图而得到的测试用例数目多的惊人，给软件测试带来沉重的负担，为了有效地,合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计。
利用正交实验设计测试用例的步骤：
1. 提取功能说明,构造因子--状态表
把影响实验指标的条件称为因子.而影响实验因子的条件叫因子的状态.利用正交实验设计方法来设计测试用例时,首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素,把他们当作因子,而把各个因子的取值当作状态.对软件需求规格说明中的功能要求进行划分,把整体的概要性的功能要求进行层层分解与展开,分解成具体的有相对独立性的基本的功能要求.这样就可以把被测试软件中所有的因子都确定下来,并为确定个因子的权值提供参考的依据.确定因子与状态是设计测试用例的关键.因此要求尽可能全面的正确的确定取值,以确保测试用例的设计作到完整与有效。
2. 加权筛选,生成因素分析表
对因子与状态的选择可按其重要程度分别加权.可根据各个因子及状态的作用大小,出现频率的大小以及测试的需要,确定权值的大小。
3. 利用正交表构造测试数据集
正交表的推导依据Galois理论（这里省略,需要时可查数理统计方面的教材）。
利用正交实验设计方法设计测试用例,比使用等价类划分,边界值分析,因果图等方法有以下优点:节省测试工作工时；可控制生成的测试用例数量；测试用例具有一定的覆盖率。
3.1.7 功能图法
概念
功能图由状态迁移图和布尔函数组成.状态迁移图用状态和迁移来描述.一个状态指出数据输入的位置（或时间）,而迁移则指明状态的改变.同时要依靠判定表或因果图表示的逻辑功能.例,一个简化的自动出纳机ATM的功能图。
功能图法的应用
1. 功能图介绍
一个程序的功能说明通常由动态说明和静态说明组成.动态说明描述了输入数据的次序或转移的次序.
静态说明描述了输入条件与输出条件之间的对应关系.对于较复杂的程序,由于存在大量的组合情况,因此,仅用静态说明组成的规格说明对于测试来说往往是不够的.必须用动态说明来补充功能说明.功能图方法是用功能图FD形式化地表示程序的功能说明,并机械地生成功能图的测试用例.
功能图模型由状态迁移图和逻辑功能模型构成.状态迁移图用于表示输入数据序列以及相应的输出数据.在状态迁移图中,由输入数据和当前状态决定输出数据和后续状态.逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系.逻辑功能模型只适合于描述静态说明,输出数据仅由输入数据决定.测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成.功能图方法其实是是一种黑盒白盒混合用例设计方法。
（功能图方法中,要用到逻辑覆盖和路径测试的概念和方法,其属白盒测试方法中 的内容.逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法.该方法要求测试人员对程序的逻辑结构有清楚的了解.由于覆盖测试的目标不同,逻辑覆盖可分为:语句覆盖,判定覆盖,判定-条件覆盖,条件组合覆盖及路径覆盖.下面我们指的逻辑覆盖和路径是功能或系统水平上的,以区别与白盒测试中的程序内部的.）
2. 测试用例生成方法
从功能图生成测试用例,得到的测试用例数是可接受的. 问题的关键的是如何从状态迁移图中选取测试用例. 若用节点代替状态,用弧线代替迁移,则状态迁移图就可转化成一个程序的控制流程图形式.问题就转化为程序的路径测试问题（如白盒测试）问题了.
3. 测试用例生成规则
为了把状态迁移（测试路径）的测试用例与逻辑模型（局部测试用例）的测试用例组合起来,从功能图生成实用的测试用例,须定义下面的规则.在一个结构化的状态迁移（SST）中,定义三种形式的循环:顺序,选择和重复.但分辨一个状态迁移中的所有循环是有困难的.（其表示图形省略）。
4. 从功能图生成测试用例的过程
1) 生成局部测试用例:在每个状态中,从因果图生成局部测试用例.局部测试用例由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成。
2) 测试路径生成:利用上面的规则（三种）生成从初始状态到最后状态的测试路径。
3) 测试用例合成:合成测试路径与功能图中每个状态中的局部测试用例.结果是初始状态到最后状态的一个状态序列,以及每个状态中输入数据与对应输出数据的组合。
5. 测试用例的合成算法:采用条件构造树.
3.1.8 场景法
概念
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。
场景法的应用
基本流和备选流：如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。
实例
1. 例子描述
下图所示是ATM例子的流程示意图。
2. 场景设计：下表所示是生成的场景。
表3-8 场景设计
| 场景1——成功提款 |
基本流 |
|
| 场景2——ATM内没有现金 |
基本流 |
备选流2 |
| 场景3——ATM内现金不足 |
基本流 |
备选流3 |
| 场景4——PIN有误（还有输入机会） |
基本流 |
备选流4 |
| 场景5——PIN有误（不再有输入机会） |
基本流 |
备选流4 |
| 场景6——账户不存在/账户类型有误 |
基本流 |
备选流5 |
| 场景7——账户余额不足 |
基本流 |
备选流6 |
注：为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入上表。
3. 用例设计
对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。
表3-9 测试用例
| TCID |
场景/条件 |
PIN |
账号 |
输入（或选择）的金额 |
账面 金额 |
ATM内的金额 |
预期结果 |
| CW1 |
场景1：成功提款 |
V |
V |
V |
V |
V |
成功提款 |
| CW2 |
场景2：ATM内没有现金 |
V |
V |
V |
V |
I |
提款选项不可用，用例结束 |
| CW3 |
场景3：ATM内现金不足 |
V |
V |
V |
V |
I |
警告消息，返回基本流步骤6，输入金额 |
| CW4 |
场景4：PIN有误（还有不止一次输入机会） |
I |
V |
n/a |
V |
V |
警告消息，返回基本流步骤4，输入 PIN |
| CW5 |
场景4：PIN有误（还有一次输入机会） |
I |
V |
n/a |
V |
V |
警告消息，返回基本流步骤4，输入 PIN |
| CW6 |
场景4：PIN有误（不再有输入机会） |
I |
V |
n/a |
V |
V |
警告消息，卡予保留，用例结束 |
4. 数据设计
一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。
测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据，如表3-10所示。
表3-10 测试用例表
| TCID |
场景/条件 |
PIN |
账号 |
输入（或选择）的金额（元） |
账面 |
ATM内的金额（元） |
预期结果 |
| CW1 |
场景1：成功提款 |
4987 |
809-498 |
50.00 |
500.00 |
2 000 |
成功提款。账户余额被更新为450.00 |
| CW2 |
场景2：ATM内没有现金 |
4987 |
809-498 |
100.00 |
500.00 |
0.00 |
提款选项不可用，用例结束 |
| CW3 |
场景3：ATM内现金不足 |
4987 |
809-498 |
100.00 |
500.00 |
70.00 |
警告消息，返回基本流步骤6，输入金额 |
| CW4 |
场景4：PIN有误（还有不止一次输入机会） |
4978 |
809-498 |
n/a |
500.00 |
2 000 |
警告消息，返回基本流步骤4，输入PIN |
| CW5 |
场景4：PIN有误（还有一次输入机会） |
4978 |
809-498 |
n/a |
500.00 |
2 000 |
警告消息，返回基本流步骤4，输入PIN |
| CW6 |
场景4：PIN有误（不再有输入机会） |
4978 |
809-498 |
n/a |
500.00 |
2 000 |
警告消息，卡予保留，用例结束 |
3.2 白盒
3.2.1白盒测试定义
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，你清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字
3.2．2白盒测试方法
白盒测试的主要用例设计方法有6种：
语句覆盖，使程序的每一条可执行语句至少被执行一次。可以很直观地从源代码得到测试用例，无须细分每条判定表达式。由于这种测试方法仅仅针对程序逻辑中显式存在的语句，对于隐藏的条件和可能到达的隐式逻辑分支是无法测试的。语句覆盖对于多分支的逻辑运算是无法全面反映的，它只在乎运行一次，而不考虑其他情况。
判定覆盖，也叫分支覆盖，使程序中每个分支判断的每一种可能都至少被执行一次。判定覆盖比语句覆盖要多几乎一倍的测试路径，当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。往往大部分的判定语句是由多个逻辑条件组合而成（如，判定语句中包含AND、OR、CASE），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。
条件覆盖，使程序中每一个分支判断中的每一个条件的可能结果至少被执行一次。条件覆盖比判定覆盖，增加了对符合判定情况的测试，增加了测试路径。要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。
判定/条件覆盖，使程序同时满足条件覆盖和判定覆盖。判定/条件覆盖满足判定覆盖准则和条件覆盖准则，弥补了二者的不足，缺点是未考虑条件的组合情况。
条件组合覆盖，使程序中每一个分支判断中的每一个条件的每一种组合都至少被执行一次。条件组合覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。更改的判定/条件覆盖要求设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果。但线性地增加了测试用例的数量。
路径覆盖，使程序中所有可能的路径都至少被执行一次。这种测试方法可以对程序进行彻底的测试，比前面五种的覆盖面都广。但需要设计大量、复杂的测试用例，使得工作量呈指数级增长。
正确使用白盒测试，要先从代码分析入手，根据不同的代码逻辑规则、语句执行情况，选用适合的覆盖方法。任何一个高效的测试用例，都是针对具体测试场景的。逻辑测试不是片面的测试正确的结果或是测试错误的结果，而是尽可能全面地覆盖每一个逻辑路径。
4测试用例设计综合策略
1.提出了使用各种测试方法的综合策略：
1) 在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。】
2) 必要时用等价类划分方法补充一些测试用例。
3) 用错误推测法再追加一些测试用例。
4) 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
5) 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。
2.测试用例的设计步骤】
1) 构造根据设计规格得出的基本功能测试用例；
2) 边界值测试用例；
3) 状态转换测试用例；
4) 错误猜测测试用例；
5) 异常测试用例；】
6) 性能测试用例；
7) 压力测试用例。
3. 优化测试用例的方法
1) 利用设计测试用例的8种方法不断的对测试用例进行分解与合并；
2) 采用遗传算法理论进化测试用例；
3) 在测试时利用发散思维构造测试用例
作业项目中描写
5 用例中作业中所遇到的问题及重点
5.1测试用例中所遇到的问题及注意事项
（1）不要合并单元格！
（2）以打开这个软件或者双击 软件图标已打开软件或为已成功打开登陆界面！-- 放在Pre-condition:
（3）测试名称需要把遇到的相关测试要点写出来吗？
需要！测试名称要不一样！
（4）测试要点与覆盖不一致！
（5）过于与测试要点相匹配，造成不像用例！
（6）用例不准确！点击取消，或者关闭页面按钮？结果一样！
（7）点击图标，查看标题，这属于两部！
（8）没有退出和登陆按钮！？
是的！可以提交缺陷中的建议项。
（9）完全根据测试需求 但要注意隐形需求！？
是的！
（10）注册？
提交缺陷测试报告
（11）特殊字符这一块，提示狂？
提交缺陷报告建议
（12）纯数字可与首位为数字为一个用例吗？
不可以，需求上有显示
5.2审核篇
（1）
！点击确定按钮 是否为通过？
不通过
（2） ！测试点冗余通过？
不通过
（3）合法非法！注意表明
（4）纯数字，数字打头？
（5）3位纯字母！不要包涵动作和结果！
（6）输入正确的代理名和密码？密码不为数字，字母组成特殊字符？？
（7）连续输入四次密码 点击确认按钮，到底是测试要点 还是用例？
代理明晨有纯数字组成，点击确认，提示框弹出_合法？
错误
（8）不区分大小写？
是的
（9）密码为7位？
冗余
6创新思维模块
1 excel与testlink的结合
在上课的时候我问婷姐我用excel写完测试用例，还要在testlink上在输一边，这样太麻烦了吧，婷姐告诉我因为excel文档格式与testlink内部定义不一致导致的，至于怎么做，当时没解决，今天查询相关见解，终于知道该怎么解决。
我当时的想法就是快速的通过导入方式将所有的用例都导入到Testlink中，不过不知道该如何去做呢？
首先说明一下导入用例选项中提供了XML和XLS两种格式来导入，但试过之后发现XLS格式导入excel，并不能导入成功，所以在这里我们要把excel的内部定义转换为XML
基本步骤如下：
1、首先，在Testlink中手动编写一个测试用例
2、然后，将刚才编写的用例导出一份XML格式
3、通过编辑工具打开XML文件，取其格式
4、通过脚本读取Excel文件以及单元格的内容
5、接着将读取的Excel单元格内容对应XML格式进行拼接，完成符合XML的格式
6、最后生成XML文件
思路基本上就是这样了，经过一番周折，我这里通过VBS来模拟完成了此过程，而且还有辅助界面，这样避免了因为不同文件不同路径而需要每次都修改源代码，界面基本实现如下：
1、先获取文件，这里需要输入绝对的文件路径和名称，如下图：
2、按照如上步骤，确定之后，需要输入读取的Excel中目标表格的名称，如下图：
3、接着以上步骤，确定之后，需要输入转换之后的XML文件保存的路径以及名称，如下图：
4、确定后待转换结束，会给出提示，并提示总共完成多少条数据的转换，如下图所示：
2黑盒，用例思维的延展性
用列这种思维的全面性与延展性是否可以考虑应用到智能机器人，以求得编码的尽可能多的可能性，以获得机器人更多更宽广的思维，使他们面对问题分析时，有更多的选择方向与目标，从而使他们看起来更聪明。
3问题库 资源库的创建
问题库
提问单
绩效考核表
问题库，提问单以及资源库
的使用说明以及各个组绩效考核
问题库
对于软件测试，每个软件熟练使用完之后都定期交一份关于软件使用中，所遇到的困难及问题的描述，以及问题解决方案，在问题描述中建议使用文字，图片，或者录屏（如果使用录屏请用红色箭头标出问题所在）。在解决方案中建议使用录屏。
对于java中遇见的重难点问题，首先把重难点及问题进行描述，然后写出解决方案。
以上请各个小组长及时统计提交，二者请分两份提交，请在邮件上写清组名及小组标号。请每周于周一23:00之前发到我邮箱，邮箱号：[email protected]
提问单
提问单受众人群为各小组成员，各小组长请务必向各组员传达问题单的事宜，，首先写清问题关键词，问题描述可用文字或者图片进行描述。
问题单可分为测试与java两种，请各个小组长及时统计提交，二者请分两份提交，请在邮件上写清组名及小组标号。请每周于周二23:00之前发到我邮箱，邮箱号：[email protected]
资源库使用
公司成员资源收集库：每个同学有好的资源材料，及自己擅长的技术指导，例如凤依琳的PPT制作以及艳华的PS简历制作，建议两位相关同事可进行录屏演示。其他同事有好的材料资源可直接传给我，资源材料会上传到公司成员资源库——公司成员资源收集库里。邮箱号[email protected]资源库会直接链接本公司网站，直接署名个人名字，对大家以后面试会有帮助。
导师录屏：陈婷导师会将每个软件的使用进行录屏，上传资源库导师录屏栏里。周广千老师也会把重难点使用录屏或者图片的方式进行问题剖析，上传资源库导师录屏栏里。
答案解析：周广千导师会把java 相关的实验练习题及答案解析一一上传到资源库答案解析栏里。
我们班群里的东西我会定期整理，收集。
绩效考核待议
以上描述属于首稿，请各同学及时提问及修正
7 学习总结
细心，耐心是素质
准确，效率是能力
合作，互助是基础
创新，思维是根本
如何把用例素质与现实科技与生活相结合？
爱下去，学下去，努力下去，一直下去！！！！！