第1章 软件测试的基本知识
1.1 软件测试的定义
对于软件测试的定义，根据时代的演进，主要存在以下三种。
早期定义。软件测试是对程序能够按预期运行建立起一种信心。
《软件测试艺术》作者G.J.Myers对软件测试定义。软件测试是为了发现错误而执行程序的过程。它包括以下三个方面。
•测试是为了证明程序有错，而不是证明程序没有错误。
•一个好的测试用例在于它能发现至今没有发现的错误。
•一个成功的测试是发现了至今没有发现的错误的测试。
这个定义是比较片面的，一味强调测试就是发现错误。按照ISTQB定义的软件测试目的，测试除了应该包括“发现错误”以外，还应该包括“建立信心”“预防缺陷”以及“为领导者提供决策”三个方面。
IEEE的软件测试定义。软件测试是使用人工或自动的手段来运行或测定某个系统的过程，其目的在于检验，它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。
除了以上三个定义，作者认为：软件测试对于软件产品的“测”与“试”，“测”就是验证软件是否符合用户的显性需求；“试”就是尝试发现软件产品中是否存在不满足用户的隐性需求。这里的显性需求是在用户在用户需求中提出的需求；而隐性需求往往包括异常操作是否会给出合理提示、用户是否可以马上上手、性能是否可以接受等。
1.2 软件测试术语
软件测试术语有很多，并且存在好些出入，在我的另一本著作《软件测试技术实战设计、工具及管理》[1]中介绍了冒烟测试（Smoking Testing）、回归测试（Regression Testing）、白盒测试（White Box Testing）、黑盒测试（Black Box Testing）静态测试（Static Testing）、动态测试（Dynamic Testing）、单元测试（Unit Testing）、集成测试（Integration Testing）、系统测试（System Testing）、验收测试（Accept Testing）以及软件的出入口准则和挂起/恢复准则。[1]在这里介绍几个比较前沿的术语。[29]
1.2.1场景测试法
场景法即通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景、备选的用例场景、异常的用例场景和假定推测的场景。
1．正常的用例场景
通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。
场景法能如此清晰地描述整个事件的原因是系统基本上都是由事件来触发控制流程的。假设：发布一篇博文，作者发布以后需要由审核员审批，审批通过才可以发布，读者才可以阅读；否则退稿给作者，作者进行再一次修订，然后重新提交审批。而同一事件不同的触发顺序和处理结果形成事件流。这一系列的过程可以利用场景法可以清晰的描述清楚。
图1-1是最常见的场景法基本情况的一个实例图。
图1-1场景法实例图
2．备选流
每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定如下用例场景。
•场景1。基本流。
•场景2。基本流->备选流1。
•场景3。基本流->备选流1->备选流2。
•场景4。基本流->备选流3。
•场景5。基本流->备选流3->备选流1。
•场景6。基本流->备选流3->备选流1->备选流2。
•场景7。基本流->备选流4。
•场景8。基本流->备选流3->备选流4。
3．确定的
基本流：采用直黑线表示，是经过用例的最简单的路径。
备选流：采用不同颜色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中。
4．设计步骤
（1）根据说明，描述出程序的基本流及各项备选流
（2）根据基本流和各项备选流生成不同的场景
（3）对每一个场景生成相应的测试用例
（4）对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值
1.2.2探索式测试
[2]“探索式测试”是测试专家Cem Kaner博士于1983年提出，并受到语境驱动测试学派（Context DrivenTesting School）的支持。探索式测试（Exploratory Testing）：是一种自由的软件测试风格，强调测试人员展开测试学习、测试设计、测试执行和测试结果评估等活动，以持续优化测试工作。
1．定义
探索性测试可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。
对探索性测试最直白的定义是：同时设计测试和执行测试。探索性测试有时候会与即兴测试（ad hoc testing）混淆。即兴测试通常是指临时准备的、即兴的Bug搜索测试过程。从定义可以看出，谁都可以做即兴测试。由Cem Kaner提出的探索性测试，相比即兴测试是一种精致的、有思想的过程。
在对测试对象进行测试的同时学习测试对象并设计测试，在测试过程中运用获得的关于测试对象的信息设计新的更好的测试。这个有趣的过程如下图所示。
探索性测试强调测试设计和测试执行的同时性，这是相对于传统软件测试过程中严格的“先设计，后执行”来说的。测试人员通过测试来不断学习被测系统，同时把学习到的关于软件系统的更多信息通过综合的整理和分析，创造出更多的关于测试的主意。
2．探索性测试的基本过程
•探索性测 识别软件系统的目的。
•识别软件系统提供的功能。
•识别软件系统潜在的不稳定的区域。
•在探索软件系统的过程中记录关于软件的信息和问题。
3．探索性测试的四个类型
探索式软件测试一共分为自由式探索式测试、基于场景的探索式测试、基于策略的探索式测试和基于反馈的探索式测试。下面将详细介绍4种类型的应用场景。
1）自由式探索式测试
自由式探索式测试指的是对一个应用程序的所有功能，以任意次序、使用任何套路进行随机的探测，而不考虑哪些功能是否必须包括在内。自由式测试没有任何规则和模式、只是不停的去做。但是不幸的是，很多人认为所有的探索式测试都是自由式的，从长远的观点来看，这种看法低估了探索式测试技术的能力，在随后将看到这类测试的一些变种。
一个自由测试用例可能会被选中成为一个快速的冒烟测试，用它来检查是否会找到重大的崩溃或者严重的软件缺陷，或是在采用先进的技术之前通过它来熟悉一个应用程序。显然，自由式探索式测试无需也不应该进行大量的准备规则。事实上，它更像是“探索”而不是“测试”，所以应当相应的调整对它的期望值。
自由式测试不需要多少经验或者信息。但是，同以下提到的探索式技术相结合后，它将成为一个非常强大的测试工具。
2）基于场景的探索式测试
基于场景的探索式测试和传统的基于场景的测试有类似之处。两者都涉及到一个开商店，就是用户故事或者是文档化得端到端场景的开始之处，那也是各位所期望的最终用户开始执行应用程序的地方。这些场景可以来自用户研究、应用程序、以前版本的数据等，并作为脚本用于测试软件。探索式测试对传统场景测试的补充吧脚本的应用范围扩大到了更改、调查和改变用户执行路径的范畴。
使用场景作为指导的探索式测试人员经常会修改他感兴趣的输入或者是追寻一些并没有包括在脚本中的潜在副作用。不过，由于最终的不表是完成给出的场景，这些测试上的弯路、最终总是会回到脚本文件记载的用户主要执行路径。
《软件测试技术实战设计、工具及管理》[1]中3.2节介绍了一例基于场景的探索式测试。
3）基于策略的探索式测试
将自由式测试探索式与具有测试老手的经验、技能和感知融合在一起，就成为基于策略的探索式测试。它属于自由式的探索，只是他是在现有的错误搜索技术下引导完成的。基于策略的探索式测试应用所有的已知技术(如边界值分析或组合测试)和未知的本能(如异常处理往往容易出现软件缺陷)，来指导测试人员进行测试。
这些已知的策略是基于策略的探索式测试成功的关键，存储的测试知识越丰富，测试就会更有效率。这些策略缘于积累下来的知识，它们指导软件缺陷隐藏在哪里，如何综合人工输入数据，那些代码路径常常出现故障。
基于策略的探索式测试结合了资深测试工程师的经验和探索型测试人员的随机性。
4）基于反馈的探索式测试
基于反馈的探索式测试缘于自由式测试，但是随着测试历史的形成，测试人员们就会利用反馈来指导今后的探索。“覆盖”就是典型的例子。一名测试人员通过咨询那些覆盖指标（代码覆盖、用户界面覆盖、特性覆盖、输入覆盖或者其中的某一些组合）来选中新的测试用例，以使这些覆盖指标得以提高。覆盖指标只是收录反馈信息的标志之一。也会看其他标志，如代码改动数量和软件缺陷密集程度等。
基于反馈的探索式测试是一种“上一次测试”：在上一次我根据应用程序的最后状态选择了某一个输入之后、下一次我就会选中另外一个输入。或者在上一次遇到这个界面时我用A属性，这一次我就会用B属性。
基于反馈的探索式测试工具是非常有价值的，它可以是测试人员保存、搜索测试历史并据此采取实时行动。但是这样的工具太少了。
1.2.3快速测试
快速测试与传统测试主要有以下几方面的区别。[3]
1.不浪费时间
最快速的行动是完全不行动。因此，在快速测试中，要消灭掉任何不必要的活动。比较起来，传统测试是比较臃肿的，随之也带来一定的混乱。当然，需要通过一些培训和经验来知道如何来对传统测试“瘦身”。一般地说，大量的文档和虔诚的测试是最容易发生风险的区域。不要因为别人告诉重复是好的，就来回的测同一个东西。确保从每个测试中得到了好的、有价值的信息。要考虑每次测试活动的机会成本
2.愿景
在快速测试中不是以Task为导向（比如书写测试用例），而是以愿景为导向的。目标可能是“快点找到重要的问题”。如果是这样，那么写测试用例可能不是最好的方式。另一方面，如果目标是“使FDA听众满意”，那么不仅要写测试用例，还要按照指定的规格来写某几种测试用例。理解愿景，然后估算一下形势，并找到能朝着实现该目标立即开始执行的最快、最有用的行动。
3.技巧
做好任何的测试都要求技巧。普通测试不重视测试技巧的重要性，它更多关注测试文档的格式而不是测试的健壮性。快速测试，就像描述的，强调测试技巧。它不是像用微波炉炸爆米花那样的机械技术，或者是在DMV（机动车管理部门）填表格。健壮的测试是非常重要的，因此练习批判性思维和试验设计技巧。一个测试新手不会在测试中做得很好，除非有一个在测试艺术、技艺上有较高造诣的资深测试人员来监督和指导。
4.风险
普通测试关注功能和结构上的产品覆盖率。换句话说，如果产品能做什么，就测什么。快速测试更关注重要的问题。基于对产品的理解，找出那些认为的最可能发生并且发生后影响较大的问题。然后投入主要精力来测试那些问题。快速测试往往意味着尽可能快的揭露最重要的信息。
5.探索
快速测试也是快速学习，因此使用探索性测试。避免先写测试用例，除非有明确和强制性的要求。更喜欢让上一个测试影响下一个测试。这是一个好事情，因为并没有被预先设计好的测试步骤所禁锢，而且让大家发现了更好的测试思想。让测试快速地执行的其它方式，例如很多的测试自动化，总是有着这样的风险——即使运行了大量的非常快速的测试也不能在产品中帮助找到重要的问题。
6.启发法
必须当心高估所测试的问题，因此使用启发法来帮助各位避免思维短路，并且更快地测试。启发法本质上是反应――在某种意义上有偏差地反应——通常是帮助大家在正确地时间测试正确的东西。快速测试收集、记住并且练习使用有帮助的启发法。在普通测试中，启发法也有被使用，但是测试人员往往并不知道自己使用了这个方法，也不能完全地掌控这个方法。
7.反省
快速测试人员应该要经常问正在做什么和为什么这样做。要解析自己，并且讨论更好的测试策略和状况。
8.团队合作
快速测试意味着作弊。至少，大家做的事情在以前小学老师的眼中就是作弊：尽可能事先弄清楚事情，借用其它人的工作，使用能找到的任何资源和工具。例如，快速测试的一个重要的技术就是成对测试：两个人，一台电脑。这个思想在XP（极限编程）的实践中被证明是有效的，并且在测试工作中也很适用。在普通测试的经验中，测试人员通常安静、独自的工作，而不是像一群迅捷的狼在捕猎Bug。
1.2.4基于模型的测试
[28]基于模型的测试属于软件测试领域的一种测试方法。按照此方法，测试用例可以完全或部分的利用模型自动产生。以上所说的模型通常是指对被测系统（SUT，System Under Test）某些，通常是功能性的，方面的描述。
模型一般都是对被测系统预期行为动作的抽象描述。这些测试用例的集合就是平时所称的抽象测试套件（Abstract Test Suite)。抽象测试套件不可以直接执行于需测试的系统，所以他们不在同一抽象级别。
测试套件（Test Suites）是由模型生成，而不是由源代码生成。因此，基于模型的测试又常常被当作黑盒测试的一种形式。但从某种层面来说, 这并不十分准确。毕竟，基于模型的测试是与源代码级的测试覆盖率，以及对代码的功能测试都有着很大的关系。
1.2.5语境驱动学派
语境驱动学派是软件测试中的一个学派，他们遵循与贯穿以下7个原则。
•任何实践的价值都取决于其语境。
•在特定语境下有好的实践，但是没有最佳实践。
•在一起工作的人，是所有项目语境的最重要的组成部分。
•项目以常常不能预测的方式逐渐展开。
•产品是一种解决方案。如果产品不是解决方案，他就不能发挥作用。
•好的软件测试是一种具有挑战性的智力过程。
•只有通过判断和技能，在整个项目团队中始终进行协作，才能在合适的时间做合适的事，以有效地测试自己的产品。
为了贯彻上面7个基本原则，采取以下行动。
•成立测试小组是为了提供与测试有关的服务。测试小组并不开发项目，而是为项目提供服务。
•在为开发、质量管理、调试、调查或产品销售提供服务时，测试是代表项目相关人员实施的。完全不同的测试策略对于这些不同的目标是合适的。
•不同的测试小组有不同的任务是很正常的。服务一种任务的核心实践可能与另一种核心实践无关或生产率相反。
•采用无效的指标是危险的。
•任何测试用例的基本价值，在于它提供信息的能力（即减少不确定性的能力）。
•所有征兆都会有欺骗性。即使产品看起来通过了测试，但是也很有可能以测试员（或自动化测试程序）没有监视到的方式失效。
•自动化测试并不是自动化的手工测试，把自动化测试作为自动化的人工测试来讨论是没有意义的。
•不同类型的测试会暴露不同类型的缺陷——随着程序变得更稳定，测试应该更具进取性，或应该关注不同的风险。
•测试工作产品应该达到满足项目相关人员有关需求的程度。
1.2.6肥皂剧测试
肥皂剧测试（Soap Opera Testing）是Hans Buwalda（CTO，LogiGearCorporation）提出的系统级功能测试方法。其特征和方法对于基于情景（Scenario）的探索式测试很有启发性，是探索式测试者值得研究的工具。详细论述请参考Hans的原文。
1.2.7 DevOps
[28] DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
DevOps是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
DevOps的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。
[1]本节部分内容来源于网络或书籍，由于作为定义不引起二义性，尽量采用原文或原译文，会在对应部分加以标注。
[2]本节内容选自James,A.Whittaker的《探索式软件测试》一书，由于写得太精彩了，作者不得不在这里引入
[3]源于JamesA.Whittaker的博文。
——————————————————————————————————
顾老师课程欢迎报名
软件安全测试
https://study.163.com/course/courseMain.htm?courseId=1209779852&share=2&shareId=480000002205486
接口自动化测试
https://study.163.com/course/courseMain.htm?courseId=1209794815&share=2&shareId=480000002205486
DevOps和Jenkins之DevOps
https://study.163.com/course/courseMain.htm?courseId=1209817844&share=2&shareId=480000002205486
DevOps与Jenkins 2.0之詹金斯
https://study.163.com/course/courseMain.htm?courseId=1209819843&share=2&shareId=480000002205486
硒自动化测试
https://study.163.com/course/courseMain.htm?courseId=1209835807&share=2&shareId=480000002205486
性能测试第1季：性能测试基础知识
https://study.163.com/course/courseMain.htm?courseId=1209852815&share=2&shareId=480000002205486
性能测试第2季：LoadRunner12使用
https://study.163.com/course/courseMain.htm?courseId=1209980013&share=2&shareId=480000002205486
性能测试第3季：JMeter工具使用
https://study.163.com/course/courseMain.htm?courseId=1209903814&share=2&shareId=480000002205486
性能测试第4季：监控与调优
https://study.163.com/course/courseMain.htm?courseId=1209959801&share=2&shareId=480000002205486
Django入门
https://study.163.com/course/courseMain.htm?courseId=1210020806&share=2&shareId=480000002205486
啄木鸟顾老师漫谈软件测试
https://study.163.com/course/courseMain.htm?courseId=1209958326&share=2&shareId=480000002205486
