产品测试车轮图

测试类型，即测试要从哪些角度去测试产品，确定了测试的思路。接下来我们要讨论的就是怎么做的问题了，即具体的测试方法。

图描绘的质量属性的六大类和测试类型之间的关系，并没有深入到各个质量子属性和各个子属性对应的测试类型中去

从“车轮图”中能够分析出产品测试的两个关键问题：
一是如何保证测试验证的“全面性”的问题。
显然，只要我们使用的测试方法能够覆盖六大质量属性，我们的测试就不会出现大方向性的遗漏。
二是如何确定测试“深度”的问题。
一般来说，测试团队使用的测试方法越多，对产品就测试得越深。
这些都会影响测试的效果，影响测试对产品质量的评估。
除此之外，“车轮图”还能帮助我们评估测试团队的能力。
软件测试人员能够驾驭的测试方法越多，他的测试能力就越强。

功能测试方法

单运行正常值输入法。
单运行边界值输入法。
多运行顺序执行法。
多运行相互作用法。
PS:在软件测试中，测试人员模拟的用户的“操作”或“行为”。

单运行：在软件测试中，测试人员模拟的用户的“一个操作”或“一个行为”。
多运行：在软件测试中，测试人员模拟的用户的“多个操作”或“多个行为”。
也就是说，“运行”是指从用户的角度来看，有意义的操作或行为。
从功能的层面来说，一个“运行”确定了“输入”和“输出”的一种可能的情况，如图所示。

有时候，我们会从设计的角度来划分功能，不能为用户提供一个完整的、有意义的行为
eg:
“用户和邮件服务器建立了一个新的连接”
“邮件服务器删掉了和用户的连接”
这种细粒度的功能即使确定了输入和输出，都不算作“运行”。
这时，可以将多个功能组合起来，直到这个功能能够为用户提供完整的、有意义的行为为止，如图所示。

单运行正常值输入法

就是测试时输入的“A1”和“A2”是系统允许的“正常值”的测试方法。

单运行边界值输入法

就是测试时输入的“A1”和“A2”是系统的“边界值”的测试方法。

多运行顺序执行法

将多个“单运行”操作放在一起考虑，得到的结果就是“多运行”操作。
使用多运行顺序执行法进行测试时，分析各个运行之间的顺序性，是使用该方法的关键。
多运行顺序执行法在和用户的操作习惯相关的地方使用非常有效。

此外，多运行顺序执行法也比较适合使用在功能的配置测试上。

多运行相互作用法

多运行相互作用法是指在功能测试时把多个存在相互关系的运行组合在一起进行测试的方法
和多运行顺序执行法强调多个运行之间的顺序性不同，多运行相互作用法强调的是多个运行之间的关系性，这个关系可以是外在关系，如某个业务的顺利进行需要多个运行之间相互协作；也可以是内在关系，如这些运行会用相同的资源（如内存或其他硬件资源）。
需要特别指出的是，都是“针对一个用户”的操作场景，而不是“两个不同的用户同时发送邮 件”或是“一个用户发送邮件，一个用户接收邮件”这样的场景。事实上，前者属于功能测试的范畴，而后者属于可靠性测试的范畴。

可靠性测试方法

异常值输入法

异常值输入法是一种使用系统不允许用户输入的数值（即异常值）作为测试输入的可靠性测试方法。

故障植入法

故障植入法是把系统放在有问题的环境中进行测试的一种可靠性测试法，主要能够测试到的质量属性是容错性和成熟性。
和异常值输入法不同，异常值输入法是直接输入一个系统认为是错误的、不支持的值；而故障植入法是把系统放在有问题的环境中，但是输入依然是正常值。

用户的业务环境中，会有哪些故障、错误或问题？列出这些场景，把系统放到这些场景中，运行正常的业务，分析此时系统的反应是否合理。
如果系统被部署在用户的硬件环境中，考虑系统所需要的硬件资源，如CPU、内存、存储空间等，在出现不足的情况下，系统的反应是否合理。还是以“用户发送电子邮件”为例。网络故障对用户来说是一个常见的故障，如断网，网络时断时续、存在丢包。
果系统被安装在用户的系统中，考虑系统在软件冲突、驱动不正确等情况下，系统的反应是否合理。
如果系统是一个独立的设备，考虑它的关键器件（如机框、单板、插卡、硬盘、芯片等）出现问题时，系统的反应是否合理。

稳定性测试法

稳定性测试法是在一段时间里，长时间大容量运行某种业务的一种可靠性测试法，它能够非常有效地测试到系统的“成熟性”，是非常重要的一种可靠性测试法。
需要特别指出的是，稳定性测试法、压力测试法和性能测试法是存在一定关系的，这个关系纽带就是产品规格。
产品规格：产品承诺的能够处理的最大容量或能力。例如，系统最多支持100个用户并发登录、系统最多支持建立100条安全策略都是产品规格。

性能测试的目的就是测试产品真实规格是否和说明书中承诺的需求规格一致。显然，最后我们实测出来的性能值，就是系统真正能够处理的最大容量或者能力。

稳定性测试是在低于性能值的前提下测试的。事实上，用户在使用系统时，也不会时时刻刻让系统在极限的状态运行，在测试时，我们可以控制测试中的负载量，使其和用户的实际使用情况尽量接近，使得测试能够更为准确，更有价值。

压力测试是在高于性能值的前提下进行测试的。虽然测试时负载超过了系统能够处理的最大能力，但并不等于在这种情况下系统的功能都会失效，我们需要根据实际情况来分析系统的表现是否合理。
例如，系统最多支持100个用户并发登录，但此时有110个用户同时发起了登录的操作，那么系统应该保证这110个用户中有100个用户能够正常登录， 有10个用户不能登录才合理，而不是所有用户都不能登录。
现在让我们再回到稳定性测试上（。从方法的角度来说，稳定性测试法是所有测试方法中最为有趣的，可以总结为一个“四字诀”——多、并、复、异。

“多字诀”的要义是，在测试中通过增加用户对功能的操作数量，来测试系统的稳定性。
“并字诀”的要义是，在测试中让多个用户同时来操作这个功能，由此来测试系统是否依然稳定。有时我们也称这个测试为并发测试。 “复字诀”的要义是，在测试中让一个或多个用户，反复进行新建、刷新、删除、同步、备份之类的操作，以此来测试系统是否稳定。
“异字诀”的要义是，在测试中让一个或者多个用户，反复进行异常操作，验证系统是否能够持续做出合理的反应。与异常输入法和故障植入法相比，“异字诀”强调的是“持续”和“累积”。事实上，使用“异字诀”来测试往往还比较有效，这是因为，开发在编码的时候，容易考虑正确情况下资源的申请和回收，忽视异常情况下资源的回收。

压力测试法

压力测试法是在一段时间内持续使用超过系统规格的负载进行测试的一种可靠性测试方法。
尽管产品已经声明了规格，只承诺在规格范围内才能提供稳定可靠的功能，不承诺在超过系统规格的情况下还能提供正确的功能，但压力测试仍然是有意义的。一个重要的原因是，业务的突发现象——用户的业务负载并不是平均的，可能在极短的时间里，出现超过负载的情况，但是平均下来，却没有超过规格。

我们希望系统在突发的情况下不会像纸牌屋那样脆弱，而是有切实的应对措施，如不处理超过系统规格的负载、记录日志供用户分析突发原因等。不会因为突发情况导致死机、反复重启等致命问题，这才是我们进行压力测试的真正目的。为了达到这个测试目标，我们在进行压力测试时，需要使用突发形态的负载模型

不建议用持续超过系统规格负载这样的测试方法来挖掘产品的问题。但是对测试来说，使用持续超过规格的负载模型测试也并不是完全没有意义，它是我们另外一种可靠性测试法—— 恢复测试法的组成部分
恢复测试法
恢复测试法是指使用持续超过规格的负载进行了测试后，再将负载降到规格以内的测试方法，如图

持续进行超过规格的负载测试时，允许规格内的业务不是100%正确。当负载降到规格值之内后，业务必须能够恢复到100%的正确。
为了加深大家对压力测试法和恢复测试法的理解，我们不妨来对比一下两个模型在不同负载下对“业务”结果的期望，如图所示

可见，两个测试方法最大的差别，在于图中“黑色”的部分。在使用突发负载模式进行压力测试时，图中的黑色部分是不允许出现业务失败的，而使用持续负载模式进行恢复测试时，黑色部分允许出现业务失败。

性能测试方法

性能测试的目的是测试产品真实规格是否和说明书中承诺的需求规格一致，我们实测出来的性能值，就是系统真正能够处理的最大容量或者能力。
一般来说，产品的需求规格会给出性能期望值，测试者只需要确认产品能否达到规格即可。假如需求规格中对产品性能规格定义得很简单、很粗糙，我们可以按图进行性能测试

第一步 测试出系统最好的性能值

在进行性能测试时，我们可以先试着测试出系统最好的性能值。
我们可以以性能规格中要求的性能值作为测试的项目，测试出这些指标在系统中的极限。
不同产品的性能规格可能会千差万别，但总的来说，却可以分为以下两类。
1）系统能够正确处理新业务的最大能力,我们也称为“新建”。
例如，系统每秒能够允许多少新用户上线登录、系统每秒能够主动发起多少新的连接等。
针对系统的新建能力进行性能测试，测试的是系统为一个新业务从分配资源到完成处理流程的速度。
业务处理流程和资源的总量都会影响系统的新建能力。
需要注意的是，系统不能 只“建”不“拆”：已经完成或异常的业务需要被及时拆除，占用的资源要能够被回收，用于新的业务。
2）系统能够同时正确处理的最大业务能力，我们也称为“并发”。
例如，系统能够支持的最大用户同时在线数、系统能够同时发起的最大连接数等。
需要特别指出的是，“新建”和“并发”之间是存在关系的，如图所示。

注意：新建和并发这两个指标会互相影响，比如最大并发能力是4000，测试的时候
只“建”不“拆”，当每秒新建150条，到24秒时，并行数大于最大并发能力是4000，而导致新建数降低。
因此，我们在测试系统最好的性能值时，需要注意测试指标之间的内在关系，在测试一个指标的时候，别的指标不能对这个指标造成影响。

第二步 分析会影响性能值的各种因素，测试它们对性能的影响

配置”和“业务”都会对性能指标产生影响。
试想一下，配置了1条用户策略和配置了1000条用户策略的性能应该是不同的；系统接收1字节大小的邮件和接收10M大小的邮件测试出来的性能值也是不同的。在这个步骤中，我们要分析出系统中的哪些因素对性能有影响（性能下
降），然后进行测试，分析性能下降是否符合预期，最坏的情况是否还算合理。

通过测试这些性能值，我们很容易得到：
哪些因素对系统性能的影响大，哪些因素对系统性能的影响不大。
各个因素对性能的影响趋势。通过挑选测试的样本，通过数学中的“曲线拟合”技术，得到因素的影响曲线，我们可以通过曲线来分析这个下降趋势是否合理。
在各个因素下，性能的最坏值。分析这个最坏值是否合理，是否会成为系统的性能“瓶颈”。
很多时候，影响一个性能指标的因素并不是单一的，而可能会有多个。在这个步骤中仅测试单个因素对性能的影响即可，多个因素对性能的影响可以放在典型场景中，选择典型的配置和业务来进行性能测试。

第三步 以场景为单位来测试性能

最后我们以“场景”为单位，来测试这个场景中的典型配置、典型业务下的性能值。
以“用户发送邮件”为例，假设在这个场景下，典型的配置为“200条过滤策略”，邮件大小为1KB、10KB、2MB以1：2：1混合情况下，邮件系统每秒能够接收并正确处理的最大邮件数。

一致性测试法

一致性测试法在测试中关注的是产品的用户界面：

风格、布局、元素上是否一致、统一。
布局的合理性、操作的合理性、提示等是否符合UI设计规范。
一致性测试法能够测试到产品在易理解和易用性依从性方面的能力，但它并不关心产品功能是否正确，所以可以直接对产品的UI设计原型进行测试

可用性测试法

可用性测试法的测试对象也是用户界面，但在可用性测试中，我们关注的是产品提供的功 能，对用户来说是否易于学习理解、易于使用，所以可用性测试需要和功能测试结合起来， 以场景作为测试粒度，以用户的视角进行测试。

可移植性测试

可移植性测试是确定软件组件或应用程序可以从一个硬件、软件或其他操作或使用环境中有效和有效地转移到另一个系统的容易或困难程度的过程。
测试结果, 由系统的各自的需要定义,通常以适应软件的费用到新的环境与重建的费用相比。

可维护性测试

可维护性被定义为可以轻松地对软件系统进行更改。这些变化可能需要纠正故障, 适应新的要求, 增加新的功能, 删除现有的功能或纠正错误或缺陷发生时, 可以完善, 适应或行动为降低进一步的维护成本而采取的措施。
可维护性测试与维护测试不同, 它是测试已修改的软件。
可维护性可以是静态测试形式, 即通过检查和检查进行, 或者是动态形式, 即测量执行维护活动所需的工作量。

一些补充

测试点不等于测试用例

如果我们拿测试点来进行测试，会发现很多让我们不爽、困惑的问题：

问题1：这些测试点在内容上有重复，存在冗余。
例如，测试点1、测试点4都会测试到“正确发送邮件”。

问题2：一些测试点的测试输入不明确，不知道测试时要测试哪些。
例如，测试测试点1时，我们并不知道我们要测试哪些“正常的输入数据”。存在类似问题的还有测试点5。
问题3：总是在搭相似的环境，做类似的操作。
有些测试点之间存在一定的执行顺序，需要把这些测试点放在一起测试。例如，先执行测试点6，再紧接着执行测试点11，可以最大限度地利用之前的测试环境和测试结果。

问题4：测试点描述得太粗，不知道是不是测对了。
有些测试点写得很粗，我们不知道测试目标是什么，或是该关注哪些地方。例如，测试点4，我们不知道将“用户发送电子邮件”和“用户接收的电子邮件”这两个操作放在一起，它们的“交互点”在哪里？

四步测试设计法

把测试点加工为测试用例，就叫测试设计，在这个过程中使用的方法就叫测试设计方法。
路径分析法、判定表、正交分析法、等价类、边界值等都是常见的测试设计方法。
在测试分析中，我们对被测对象按照测试方法进行思考，就能得到测试点，所以测试分析是一个“发现性”的过程，如图所示，而测试设计不同。

让两个测试者根据“车轮图”来分析同一个测试对象，他们得到的测试点差异并不会太大，但是最后生成的测试用例却会千差万别。
这是因为，从测试点到测试设计，我们会加工测试点， 对它们进行组合、拆分，选择测试数据，等等，这是个“创造性”的过程。

第一步：建模
其实，在这个步骤中，我们并不是要大家对每个测试点都原创出一些测试模型，而是根据测试点的特征，为测试点选择一个适合后续测试设计的模型。也许我们称这个步骤为“选模”更为贴切。
既然“选模”需要参考测试点的特征，研究测试点、分析特征的情况并对其进行归类是必不可少的。目前我们将其分为四类：

类型1：“流程”；类型2：“参数”； 类型3：“数据”； 类型4：“组合”。
对每一类测试点，我们都给出了一些最适合的“建模”方法：

对“流程”类，可以通过绘制“流程图”来建立测试模型。 对“参数”类，可以通过“输入输出表”来建立测试模型。 对“数据”类，可以通过“等价类分析表”来建立测试模型。对“组合”类，可以通过“因子表”来建立测试模型。

第二步：设计基础测试用例。
在这个步骤中，我们会对已经建立好的测试模型，来设计一些基础测试用例，覆盖这个测试模型。
测试用例和基础测试用例最大的差别在于，测试用例确定了测试条件（类似“在××情况下，进行××的测试”的描述）和测试数据（就是输入的“参数值”或“数值”），而基础测试用例只确定了测试条件。
第三步：补充测试数据。
在这个步骤中，我们为基础测试用例来确定测试输入，补充测试数据，这时基础测试用例就升级成真正的测试用例了。
第四步：扩展。
模型不是银弹，不能解决测试设计的所有问题。我们还需要根据经验，特别是对系统哪些地方容易发生缺陷的认识，补充一些测试用例，增加系统的有效性。
对测试点进行分类
在使用四步测试方法之前，我们首先要对测试点进行分类。分类的依据，就是看测试点是否有“流程”类的特征、“参数”类的特征、“数据”类的特征、“组合”类的特征。