一、测试定义
a、什么是测试
测试是一个带着找到错误的目的来运行程序或系统的过程。或者，它是任何旨在评估程序或系统属性和性能的活动，通过这些活动来决定该程序或系统是否符合所要求的结果。
对于软件来说，它并没有不同于其他那些接收输入、产出输出的物理过程，它不同之处在于以何种方式运行失败。大多数物理系统运行失败在一个固定的（相当小）设置方式上。相反的，软件可以失败在许多奇怪的方式上。要发现软件所有不同的失败方式通常是不太可能的。
b、测试目标
要证明所提供的软件产品达到了被要求的指标。
软件能正常运行，没有任何错误或故障（功能上）。
产生高品质的测试案例，进行有效测试，发表正确有帮助的错误报告。
c、一个优秀测试案例的特征
一个好的或者说一个成功的测试案例在于它具有很高的可能性来发现尚未发现的错误。
它容易找到程序失败的方式。
它让测试捕捉到错误的这种可能性变的合理。
它不是多余的。
它既不是太过简单也不是太过复杂。
d、测试原则
1、测试是一个带着找到错误的目的来运行程序的过程。测试不应该把"不会有错误被发现"计划在隐性假设中。
2、不仅使用有效的输入条件进行测试，还要使用无效和意想不到的输入条件来测试。
3、当遇到一个无效的测试时程序应该产生正确的消息，当遇到一个有效的测试时程序应该产生正确的结果。
4、在一个或一组模块中存在更多错误的可能性与已经找到的错误数量，是成正比的。
5、测试时保持软件静态。
6、在设计的测试用例集被执行的时候，不能修改程序。
7、使用文档形式来记载测试案例和测试结果
8、如果可能的话提供预期的测试结果。
e、V过程模型总结
V模型是一个软件开发的过程。V模型揭示了开发生命周期每个阶段与测试的关系。
V模型部署了一个结构良好的框架方法。按照这个框架，每个阶段都能按照前一阶段的详细文档来执行。测试活动就像测试设计，开始于项目的最开端，放在编程之前，这样就很有可能为工程进度省下一大部分时间。
二、白盒测试与黑盒测试
f、白盒测试
白盒测试基于应用程序代码的内部逻辑知识。测试基于代码语句、分支、路径、条件的覆盖。
测试人员必须知道软件内部是怎么工作的，要知道软件的结构和程序语言，至少要知道程序语言的意义
白盒测试是在一个结构性测试策略下进行的，要求对对象结构的完全访问，也就是源代码。
g、黑盒测试
黑盒测试不需要知道软件内部是如何工作的，也不需要知道软件的结构、设计、代码或测试模块的程序语言。黑盒测试，像其他大多数测试一样，必须依据一个最终源文件，比如规格说明书或要求文件。"你看到的就是你测试的。"它基于需求和功能来测试。
h、白盒测试技术
白盒测试技术包括以下4种
I、代码覆盖
1、段覆盖：确保对每一句代码都测试一次。
2、分支覆盖或节点测试：覆盖所有可能的代码分支。
3、复合条件覆盖：对于多个条件，通过多个路径测试每一个条件，并且通过不同路径组合来达到这一条件。
II、基本路径测试
代码中每个独立的路径都要被测试过。数据流测试是一种方式，即你通过各种可能的计算来跟踪特定变量，从而通过代码定义中间路径集。数据流测试往往反映相关性，它主要是通过数据序列来操作。简言之即跟踪每个数据变量，验证其使用。这种方法往往会发现错误来源于变量使用而不是变量初始化，或者来源于变量声明而不是使用，等等诸如此类。
III、路径测试
路径测试就是定义和覆盖测试代码中所有可能的路径。这是一项费时的工作。
IV、回归测试
测试思路涉及到测试单圈、串联循环、和嵌套循环。通过这种方法测试独立和非独立代码循环和代码值。
i、黑盒测试技术
为便于理解，将在下面详细给出黑盒测试主要技术。
I、等价类划分
等价类划分是一种软件测试技术。将软件单元的输入数据范围划分成若干等价区域，每一个区域编写一个测试案例。原则上，测试案例的编写至少覆盖每个分区一次。该技术试图定义测试用例从而揭示错误类，这样测试案例的总数就相应减少了。
在极少数情况下，等价区域划分也适用于软件组件的产出，是具有代表性的，它适用于测试元件的输入。等价区域划分常常遵循于输入属性需求规格说明书，从而影响测试对象的处理。输入具有一定的有效输入范围和无效输入范围。这里的无效输入数据不是说数据类型是错误的，而是指该输入数据在某个具体分区之外。
举个等价区域划分的例子，比如你想要测试范围在1到10，000之间的某个输入数字，你不需要一一测试每一个1到10，000之间的数字，你只需使用等价区域划分的方法，将数字范围划分，比如划分成一位数、两位数、三位数和四位数，像5、15、555、5555。
II、边界值分析
边界值分析是等价区域划分的扩展，它是取等价区域上的边界值来进行测试。很多错误往往就是发生在输入范围的边界值上而不是输入范围中间的地方，至于为什么会这样还不是完全清楚。正是由于这个原因，边界值分析发展成了一项测试技术。边界值分析产生了测试用例的选择，选择使用边界值来进行测试。
边界值分析是一个测试案例设计技术，是等价区域划分的补充。边界值分析不是选择等价区域内任意的数据，而是选择区域边界值作为测试案例。边界值分析不仅仅关注输入条件，还从输出域中产生出测试用例。
举个边界值分析的例子，比如测试1到12月之间的某个月份，我们取一个小于0的负数据，取一个1到12之间的有效数据，取一个大于12的数据来进行测试，观察是否是只有1到12之间的有效数据被输入才是可接受的。
III、错误猜测
这是一个基于测试者综合能力的一项软件测试设计技术。在测试过程中，测试者根据他的经验、知识和直觉来预测软件上的错误。一些典型的错误域常常会发生在空字符串、零实例、某些特殊值、字符串中的空字符、负数数据上。
尽管过去测试经验对错误猜测来说是很关键的基础，但它们也可能会用不到。容易出错的情况，有包括数据初始化（例如，重复某个过程，查看数据是否被正确删除），错误类型数据（例如，负数数据、非数字对数字），真实数据处理（也就是，测试那些通过系统或真实记录创建的使用数据，因为程序员往往会通过创建的数据来反映他们预期的设想），错误管理（例如，将多个错误进行优先排序，清除错误消息，当遇到某个错误时需适当进行数据保存，错误过后程序应当能继续处理）， 计算（例如，手工计算需比较的项目），重新启动、恢复（也就是，强制终止一个批处理程序，并且测定重启/恢复进程是否能工作正常），妥善处理并发进程（也就是，在事件驱动的应用程序上，同时让多个进程运行，测试程序的处理情况）。
IV、决策表
决策表是一种精确且紧凑塑造复杂逻辑的方式。像if-then-else和switch-case语句那样，通过条件来执行相应事件。不同于传统编程语言里的控制结构，决策表能通过一个直观的方式将许多独立的条件和事件关联起来。
一个决策表通常被分成四个象限，如下图所示。
每个决策对于一个变量、关系或表明满足条件选项中的可能值。每一个动作执行一个过程或操作，并且该项指定动作是否（或按什么顺序）按照项目对应的条件选项集执行。
举例：描述有限项决策表是最简单的。条件选项是简单的布尔值，并且动作项是检查标记，表明哪一个给定列中的动作将被执行。一个技术支持公司编写决策表来诊断打印机问题，问题的了解基于客户通过电话向他们描述的症状。下面是一个平衡的决策表。
V、因果图
在软件测试中，因果图是一个定向图，由原因集映射到结果集上。原因可能被认为是程序的输入，结果可能被认为是程序的输出。通常，图表显示在左边的节点代表原因，显示在右边的节点代表结果。中间可能有中间节点，使用逻辑运算符，如AND 和OR，将输入结合起来。
三、测试类型
j、单元测试
单元测试的主要目标是测试应用程序中可测试的最小组成部分，可以独立于软件的其余代码，测试其是否按照你所希望的在运行。在将每一个单元集合成模块来测试模块间的接口前，应该先分别测试每一个单元。单元测试很重要，很大比例的错误都是在单元测试中发现的。
单元测试最常用的方法需要写入驱动和存根。驱动模拟一个呼叫单元，存根模拟一个被呼叫单元。由于单元测试投资在开发时间上较长，有时会导致将单元测试放在较低的优先级上，但这样做往往是错的。尽管编写驱动和存根要耗费一定人力和时间，但单元测试展现了一些不可否认的优势。单元测试允许测试过程自动化，降低了从更复杂的应用程序块中找到错误的难度。因为每个单元都被关注了，所以测试的覆盖率也往往被提高了。
例如，如果你有两个单元，想知道将他们集合在一起进行测试所花的成本是否会偏低些，一开始就将它们作为一个整体单元进行测试，错误的发生点可能会出现在很多地方：
单元一这里会出现错误吗？
单元二这里会出现错误吗？
两个单元都会出现错误吗？
两个单元之间的地方会出现错误吗？
会因为测试的缺陷出现错误吗？
将模块直接集合在一起进行测试远比先独立测试每一个单元模块，然后再将它们集合在一起进行测试要复杂的多。
驱动和存根可重复使用，在开发周期中不断发生的变化可以经常进行重新测试，而无需编写大量的额外测试代码。事实上，这减少了每次编写驱动和存根的成本，并且对重复测试的成本也更好控制。
k、集成测试
集成测试是单元测试逻辑上的延伸。最简单的测试形式是，在完成了两个单元的单元测试后，将这两个单元组合成一个组件，测试两单元之间的界面。这里组件的意思是指多个单元的综合。在真实的场景中，很多单元被合并成组件，这些组件又被合并成更大的部分。这个想法是测试组合件，最终扩大测试该组模块与别组模块的过程。最终所有模块将并一起进行测试。除此之外，如果程序是多个进程组成，它们应该成对测试，而不是一次性全部一起测试。
集成测试是在将单元结合在一起的时候发现错误。通过使用一个测试计划，测试每一个单元，并在合并单元前确保每个单元的都是ok的。你就会知道在合并单元时发现的错误就可能和单元间的界面有关系。利用这种方法，可以将推测错误位置的可能性降低到一个简单的多的分析水平上。
集成测试有很多种方法，以下三种是最常见的：
自上而下的方法：需要测试最高级别的模块，并且先集成起来。这使得在过程中要先测试高层次的逻辑和数据流，往往最小化了驱动的需要。然而，存根的需求使测试管理复杂化。并且在软件开发生命周期中，低级别的往往在后面测试。自上而下的集成测试另外个不好的地方在于它不支持有限功能的提前释放。
自下而上的方法：需要测试最低级别的单元，并且先集成起来。这些单元常常被称为公用模块。通过使用这个方法，在开发过程早期测试公用模块，存根的需要就被最小化了。不过这个方法的缺点就是驱动的需求使测试管理复杂化，并且高级别的逻辑和数据流往往在后面测试。像自上而下的方法一样，自下而上的方法同样不支持有限功能的提前释放。
第三个方法，有时也被称为伞方法，需要沿着函数数据和控制流路径来测试。首先，函数的输入是集成在上面讨论的自下而上的模式中。然后，函数的输出是集成在自上而下的模式中。该方法最主要的优势在于它支持有限功能的提前释放。并且它将存根和驱动的需求最小化。该方法潜在的弱点是显著的，它比其他两种方法要欠缺系统性，导致需要更多的回归测试。
l、验收测试
用户验收测试常常是推出程序之前的最后一步测试。
通常，使用程序的最终用户会在接受程序前对应用程序进行测试。这种形式的测试使最终用户对交付到他们手上的应用程序质量更具有信心。该测试也能帮助发现程序在可用性上的缺陷。该测试有两种测试类型，分别是Alpha测试和Beta测试。
Alpha和Beta测试
Alpha测试在开发员的站点上进行，在发行给外面客户使用前，先由内部工作人员对业务系统进行测试。
Beta测试在客户的站点上进行，在发行给别的客户前，先由一组顾客在他们自己的站点上使用该系统对其进行测试。后者通常被称为"现场测试"。
m、系统测试
系统测试对软件整体进行测试。在一个有代表性的企业里，由程序员来做单元测试。这保证了每一个组件都正常工作。集成测试关键在于软件各个部分的成功组合（组件或单元代码）。一旦组件被组合到一块，整个系统就需要进行彻底的测试来保证它达到质量标准。
因此系统测试建立在单元测试和集成测试的基础上。通常一个专业的测试团队是有责任做系统测试的。系统测试在质量管理过程中是关键性的一步。
为什么系统测试如此重要？
在软件开发生命周期中，系统测试在系统作为一个整体进行测试中是第一级的。通过测试系统来检验它是否达到功能和技术上的要求。应用程序/系统是在一个很类似于生产环境的环境下进行测试的，那里应用程序最后要被释放。系统测试让我们测试、检验并确认产品无论在业务需求还是体系结构上是否都达到标准。
i、性能测试
性能测试是在程序运行下进行的，从某个角度来讲，是检测系统在特定的负载下各方面的运行情况。它也可以用来验证和核实系统其他质量属性，如可扩展性，可靠性和资源使用率。性能测试是性能工程的一个子集，是一种新兴的计算机科学实践，为提高系统设计和体系结构的性能而努力，做在实际的编码工作之前。
性能测试可用于不同的目的。它可以证明该系统性能符合标准。它可以通过比较来发现哪个系统执行地好。或者，它可以测量系统或负载的哪部分导致系统运行失败。在诊断进行中，软件工程师使用工具，如廓线仪，来测量是设备或软件的哪部分导致运行失败，或者为维持可接受的响应时间来创建吞吐量水平（和阀值）。对一个新系统来说，性价比是至关重要的。性能测试工作始于开发项目的启动，并且扩展到整个项目中。性能缺陷发现的越晚，修复的成本越高。这在功能测试中，情况属实，性能测试更是如此，原因在于其终端到终端的范围性质。
ii、回归测试
如果软件的某一部分因为某个原因被修改了，就需要进行测试，测试修正过后的软件是否按照指定要求在工作，确保软件没有被影响并且之前的功能都俱全。这种测试就叫做回归测试。
为什么回归测试很重要？
因为任何软件上的修改都能引起现有的功能遭破坏。软件组件上的改变可能会影响到别的相关组件。软件上的一个修正可能会引起其他错误，这是很常见的。所有这些都影响了系统的质量和稳定性。因为回归测试的目的是为了验证并确保这一切不会发生，所以是非常重要的。
四、测试过程
n、测试计划
测试计划是一个文件，详细说明了测试一个系统，如一机器或一软件的系统方法。该计划通常包含最终工作流程会是什么样子的详细说明。
它是一份描述测试计划的文件，换句话说，即如何执行测试计划。它通常包括测试对象的罗列、测试人员角色和责任分配、开始测试的前提条件、测试环境、假设、测试执行成功后要做什么、测试执行失败后要做什么，等等。
一个测试计划描述了如何验证和确保产品或系统满足其设计规范和其他要求的战略步骤。通常，测试工程师会对测试计划做大量准备和投入。
i、测试计划的目标
测试计划的目标是提供一套工具，以各种方式来支持测试团队的工作。这些好处包括：
a、可以减少重要工作被忽略、被误估计、被忘记的风险
b、可以将工作按照重要性的高低来完成。
c、可以估计该项目（技术和程序性）的风险，并确定是否可以缓解步骤。
d、可以组织安排测试的工作。
e、可以将测试工作的进展情况和该项目作为一个整体来监视。
五、单元测试
单元测试是一个验证源代码的个别单位是否正常工作的测试（通常是自动的）。单位是应用程序中最小的可测试部分。在程序编程里，一个单位可能是一段指令、一个函数或者一段程序等等。而在面向对象的编程里，单位可能是一个基数类/父类、抽象类或派生类/子类。
单元测试通常是由软件开发商来操作，要确保他们编写的代码符合软件的要求，并且按照开发员意想来运行。
单元测试该测试些什么呢？
这在很大程度上取决于程序或正在创建的单元的类型。它可能是一个画面或一个组件或web服务。大致上从以下几方面来考虑：
a、对于UI画面，测试用例要能验证所有需要显示在屏幕上的屏幕元素。
b、对于UI画面，测试用例要能验证所有显示在屏幕上的标签或文本的拼写/字体/大小。
c、创建测试用例，保证单位每行代码在一个测试周期中至少被测试一次。
d、创建测试用例，保证条件语句里每一个条件都被测试过。
e、创建测试用例，测试数据可输入的最小和最大范围。例如，参数传递，要测试数值型参数的最大输入值或字符串型参数的最长输入长度。
f、创建测试用例，查看遇到各种错误程序会如何处理。
g、创建测试用例，验证是否所有的验证工作都在被执行。
请关注 私信回复：“学习”就可以免费拿到软件测试学习资料
