功能测试
功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
定义
Functional testing（功能测试），也称为behavioral testing（行为测试），根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的一样。功能测试是为了确保程序以期望的方式运行而按功能要求对软件进行的测试，通过对一个系统的所有的特性和功能都进行测试确保符合需求和规范。
功能测试也叫黑盒测试或数据驱动测试，只需考虑需要测试的各个功能，不需要考虑整个软件的内部结构及代码.一般从软件产品的界面、架构出发，按照需求编写出来的测试用例，输入数据在预期结果和实际结果之间进行评测，进而提出更加使产品达到用户使用的要求。
黑盒测试
概述
黑盒测试（Black-box Testing，又称为功能测试或数据驱动测试）是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。
比如黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。
黑盒测试试图发现以下类型的错误：
（1）功能错误或遗漏
（2）界面错误
（3）数据结构或外部数据库访问错误
（4）性能错误
（5）初始化和终止错误
用例设计
（1）等价类划分方法
（2）边界值分析方法
（3）错误推测方法
（4）因果图方法
（5）判定表驱动分析方法
（6）正交实验设计方法
（7）功能图分析方法
等价类划分
- 是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的，常用的黑盒测试用例设计方法。
划分等价类
等价类是指某个输入域的子集合.在该子集合中，各个输入数据对于揭露程序中的错误都是等效的.并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试.因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况：有效等价类和无效等价类。
有效等价类：是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
无效等价类：与有效等价类的定义恰巧相反。
设计测试用例时，要同时考虑这两种等价类.因为，软件不仅要能接收合理的数据，也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性。
方法
——下面给出六条确定等价类的原则。
①在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。
③在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。
④在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。
设计用例
在确立了等价类后，可建立等价类表，列出所有划分出的等价类：
输入条件 有效等价类无效等价类
... ... ...
... ... ...
然后从划分出的等价类中按以下三个原则设计测试用例：
①为每一个等价类规定一个唯一的编号.
②设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步.直到所有的有效等价类都被覆盖为止.
③设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步.直到所有的无效等价类都被覆盖为止.
边界值分析法
边界值分析方法是对等价类划分方法的补充.
⑴边界值分析方法的考虑：
长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例，可以查出更多的错误.
使用边界值分析方法设计测试用例，首先应确定边界情况.通常输入和输出等价类的边界，就是应着重测试的边界情况.应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据.
⑵基于边界值分析方法选择测试用例的原则：
1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据.
2）如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据.
3）根据规格说明的每个输出条件，使用前面的原则1）.
4）根据规格说明的每个输出条件，应用前面的原则2）.
5）如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例.
6）如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例.
7）分析规格说明，找出其它可能的边界条件.
错误推测法
错误推测法： 基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法.
错误推测方法的基本思想： 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例. 例如，在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等，这些就是经验的总结. 还有，输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
因果图方法
- 前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等. 考虑输入条件之间的相互组合，可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）.
- 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
- 利用因果图生成测试用例的基本步骤：
⑴ 分析软件规格说明描述中，那些是原因（即输入条件或输入条件的等价类），那些是结果（即输出条件），并给每个原因和结果赋予一个标识符.
⑵ 分析软件规格说明描述中的语义.找出原因与结果之间，原因与原因之间对应的关系. 根据这些关系，画出因果图.
⑶ 由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件.
⑷ 把因果图转换为判定表.
⑸ 把判定表的每一列拿出来作为依据，设计测试用例.
从因果图生成的测试用例（局部,组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而线性地增加.
前面因果图方法中已经用到了判定表.判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.
判定表
——通常由四个部分组成
- 条件桩（Condition Stub）：列出了问题得所有条件.通常认为列出得条件的次序无关紧要.
- 动作桩（Action Stub）：列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.
- 条件项（Condition Entry）：列出针对它左列条件的取值.在所有可能情况下的真假值.
- 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作.
- 规则：任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则。显然，判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列.
建立步骤（根据软件规格说明）
①确定规则的个数.假如有n个条件.每个条件有两个取值（0,1），故有5种规则：
②列出所有的条件桩和动作桩。
③填入条件项。
④填入动作项.等到初始判定表。
⑤简化.合并相似规则（相同动作）。
B. Beizer 指出了适合使用判定表设计测试用例的条件：
①规格说明以判定表形式给出，或很容易转换成判定表。
②条件的排列顺序不会也不影响执行哪些操作。
③规则的排列顺序不会也不影响执行哪些操作。
④每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
⑤如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。
优点
-
基本上不用人管着，如果程序停止运行了一般就是被测试程序crash了
-
设计完测试例之后，下来的工作就是爽了，当然更苦闷的是确定crash原因
缺点
-
结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG的东西很值得借鉴
-
没有状态转换的概念，一些成功的例子基本上都是针对PDU来做的，还做不到针对被测试程序的状态转换来作
-
就没有状态概念的测试来说，寻找和确定造成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来说，就更麻烦了，尤其不是一个单独的testcase造成的问题。这些在堆的问题中表现的更为突出。
工具的选择
-
那么，如何高效地完成功能测试？选择一款合适的功能测试工具并培训一支高素质的工具使用队伍无疑是至关重要的。尽管现阶段存在少数不采用任何功能测试工具，从事功能测试外包项目的软件服务企业。短期来看，这类企业盈利状况尚可，但长久来看，它们极有可能被自动化程度较高的软件服务企业取代。
-
用于功能测试的工具软件有很多，针对不同架构软件的工具也不断推陈出新。这里重点介绍的是其中一个较为典型自动化测试工具，即Mercury公司的WinRunner。
WinRunner是一种用于检验应用程序能否如期运行的企业级软件功能测试工具。通过自动捕获、检测和模拟用户交互操作，WinRunner能识别出绝大多数软件功能缺陷，从而确保那些跨越了多个功能点和数据库的应用程序在发布时尽量不出现功能性故障。
WinRunner的特点在于： 与传统的手工测试相比，它能快速、批量地完成功能点测试； 能针对相同测试脚本，执行相同的动作，从而消除人工测试所带来的理解上的误差； 此外，它还能重复执行相同动作，测试工作中最枯燥的部分可交由机器完成； 它支持程序风格的测试脚本，一个高素质的测试工程师能借助它完成流程极为复杂的测试，通过使用通配符、宏、条件语句、循环语句等，还能较好地完成测试脚本的重用； 它针对于大多数编程语言和Windows技术，提供了较好的集成、支持环境，这对基于Windows平台的应用程序实施功能测试而言带来了极大的便利。
功能测试架构：
| 序号 | 测试点 | 分散 |
| 1 | 安装 | a. 首次安装 b. 覆盖安装 c. 不同的操作系统（不同的补丁）安装 |
| 2 | 卸载 | 卸载后遗留文件 |
| 3 | 更新 | a. 近版本更新 b. 老版本更新 c. 强制更新 |
| 4 | 正常功能 | a. 所有流程点一遍 b. 所有【按钮】、【输入框】正常、异常判断 |
| 5 | 异常 | a. 输入错误数据 b. 进行异常流程 c. 断网 d. app切换后台 e. 快速多次点击某个功能 f. 同一个功能多次操作 g. 两个手指分别同时点击返回按钮及功能键 |
| 6 | 不同网络 | a. 三大运营商 b. nat 与 非nat |
| 7 | UI测试 | 各功能UI |
| 8 | 兼容性 | 【电脑】：不同浏览器不同系统补丁 【手机】：android、ios 系统主流手机 |
| 9 | 竞品测试 | 不同产品之间功能对比 |
| 10 | 易用性 | 产品符合用户习惯 |
| 11 | 可维护性 | 产品更新和维护 |
| 12 | 文档测试 | 帮助文档、帮助信息 |
| 13 | 性能和压力测试 | 不通负载情况下 |
| 14 | 稳定性测试 | 长时间运行软件是否稳定 |
| 15 | 负载均衡测试 | A B 服务请宕机 |
| 16 | 冲突测试 | a. 防病毒软件 b. 防火墙 c . 同类产品 |