测试过程
软件生命周期回到顶部
那么，软件测试要经过一个什么样的过程呢，这就要从软件的生命周期开始说起了。 软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期。 整个生命周期包括问题定义与规划、需求分析、系统设计、软件编程、软件测试、软件运维等阶段。
在周期内，我们无论是开发还是测试都依赖于某个模型进行作为依据，有效地提高开发、测试效率。
软件开发模型回到顶部
在软件开发的实践中，人们总结了很多软件的开发模型来描述和表示一个复杂的开发过程，如果瀑布模型、快速原型模型、螺旋模型等。
软件测试与软件开发模式有着紧密的关系，作为一名测试人员，应该充分理解软件的开发模式，尽快的找准自己的位置，从而尽快的发挥自己的价值。
瀑布模型回到顶部
瀑布模型是线性模型的一种，在所有的模型中占有重要的地位，是所有其他模型的一个基础。
瀑布模型如同工地里的建造盖房流程，使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。
测试的切入点，开发完成后，必须留给测试足够的时间给测试人员，否则可能会导致测试不充分，导致很多问题到项目的后期才体现出来。
优点
- 明确划分了软件生命周期的各个环节。
- 强调早期软件计划，需求分析比较重要。
- 清晰的工作流程，便于分工协作。
- 适合需求稳定的产品开发。
- 每个阶段都有一个检查点。
缺点
- 线性的开发流程，存在巨大的风险。
- 依赖于早期的需求调查，不适应需求的变化，单一流程不可逆。
- 风险在后期可能才会暴露，且无法纠正，导致项目的失败。
- 无法保证用户的产品需求不变，开发过程无法更改。比如盖房子，照着图纸打好的地基可以承载7层楼，现在用户突然要加五层，那么地基就得重打，已经盖好的楼就得爆破，当然这是不可能的操作。
改良
沿用瀑布模型的线性思想，细化了各个阶段，在某些重要关注的阶段之间掺入迭代的思想。
问题的定义及规划 确定软件开发目的以及可行性，指定开发计划。
需求分析 在确定软件开发可行性正确下，对软件所需的功能进行详细分析，明确客户需求，输出原型图。
软件设计 概要设计：架构的实现，表述各模块功能、模块接口和数据传递等事务。 详细设计：对表述的各模块深入分析，要求达到代码级别，将程序具体的实现描述出来，以及数据库设计。
软件编码 按照详细的模块功能表，编程人员编写出计算机可运行代码。
快速原型模型回到顶部
在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。
第一步是构建一个快速原型，实现用户与系统的交互，用户对原型进行评价，进一步细化待开发软件的需求，通过逐步调整原型使其满足用户的要求，开发人员可以确定用户的真是需求是什么。
第二步是在第一步的基础上开发出用户满意的软件产品。
优点
克服瀑布模型的缺点，更好的满足用户的需求并减少由于软件需求不明确带来的项目开发风险，适合预先不能确切定义需求的软件开发。适合开发小型的、灵活性高的系统。
缺点
不适合大型系统的开发，前提要有一个展示性的产品原型作为参考，因此在一定程度上可能会限制开发人员的创新。
螺旋模型回到顶部
将开发过程分为螺旋周期，每个螺旋周期和瀑布模型相符，沿着螺旋线旋转，坐标轴的四个象限表示四个活动。
1988年由巴里·勃姆提出的软件开发模型升级版，兼顾了瀑布模型的优点。
螺旋模型的核心就在于不需要在刚开始的时候就把所有事情都定义的清清楚楚。轻松上阵，定义最重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到用户满意的最终产品。
- 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
- 风险分析：分析评估所选方案，考虑如何识别和消除风险；
- 实施工程：实施软件开发和验证；
- 客户评估：评价开发工作，提出修正建议，制定下一步计划。 螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
螺旋模型的优点 引入了其他模型不具备的风险分析，使得软件遇见风险时可以停止，减少损失。 要求每个迭代阶段都需要构建原型，进行软件测试以减小项目开发风险。 整个过程有较高灵活性，开发过程的任意阶段自由应对变化。
缺点 需要测试人员有丰富的风险评估经验和专业知识才能及时标识风险，减少软件缺陷损失，过多的评审迭代，造成开发成本压力。
敏捷开发模型回到顶部
软件测试模型回到顶部
软件测试 & 软件工程回到顶部
软件测试是软件工程的一部分，并且是整个软件工程组成中不可或缺的部分。
在软件工程、项目管理、质量管理得到规范化应用的企业，软件测试也会进行的比较顺利，软件测试发挥的价值也会更大。
而我们要关注的是，软件工程、项目管理、质量管理、配置管理与软件测试的关系，在不同的软件开发模式下，如何进行软件测试。
随着软件测试的发展，测试人员在大量实践中总结出一些测试模型，对测试活动进行抽象，如V模型、W模型等。
V模型（掌握）回到顶部
V模型是最具代表意义的测试模型，最早是由Paul Rook在20世纪80年代后期提出，由英国国家计算机中心发布，旨在改进软件开发的效率和效果。
在V模型推出之前，人们通常吧测试过程作为在需求分析、概要设计、详细设计、编码全部完成后的一个阶段，尽管在那个时候，已经出现了有的测试工作会占用项目周期的一半时间，但是大多数人仍然认为测试只是一个收尾工作，而V模型的推出，就是为了改变行业对测试的普遍认识。
V模型本身是软件开发中瀑布模型的变种，它反映了测试活动与分析和设计的关系。
V模型标明了测试过程中本身存在的不同阶段，从左到右，描述了开发过程间的阶段对应关系。
V模型和瀑布开发模型有着一些共同的特性，V模型中的过程从左到右，描述了基本的开发过程和测试行为。 V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。 局限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现。
V模型的优点
- V模型既包含了底层测试有包含了高层测试：
- 底层测试，如单元测试。
- 高层测试，系统测试。
- V模型清晰的标出了软件开发的各个阶段。
- V模型自顶而下逐步求精的方式把整个开发过程分成不同的阶段，每个阶段的工作都很明确，因此便于控制开发过程，当所有的阶段都完成后，该软件开发过程也随之结束。
V模型的缺点
- 缺点也显而易见，正是它自身的顺序性导致，只有到了测试阶段，才开始执行测试流程。但有些错误直到这时才被发现，甚至无法发现，沉珂已久，回天乏术......
- 另外，在实际的开发过程中，在需求阶段很难把用户的需求完全明确下来，因此，当需求变更时将会导致阶段反复（如重新分析需求、设计、编码、测试等过程），返工量非常大，模型灵活性比较低。
改良：正如开发瀑布模型的改良一样，在相关步骤中进行小的迭代工作。
W模型（熟悉）回到顶部
IEEE Std1012-1998《软件验证和确认》原则中提出在软件需求设计阶段，也得有测试活动。
W模型由Evolutif公司提出，在软件开发中，开发一个V，测试一个V，组合而来的W，所以W模型也称双V模型。
测试伴随着整个软件开发周期，并且测试对象不仅仅是程序，需求和设计阶段同样需要测试。
开发和测试的协调工作图，绿色为开发V，橙色为测试V。
W模型优点
- 测试伴随整个软件开发生命周期，测试对象不仅仅是程序，需求和概要同样需要测试。
- 更早介入测试，可以更好的发现需求设计中的缺陷，修复成本也更低。
- 同样分阶段工作，便于控制项目过程。
W模型缺点
- 依赖于软件开发和测试的前后线性关系，还是无法解决需求变更调整的问题。也就是无法支持迭代，自发性和需求变更调整。
- 对于有些项目，在执行过程中根本不产生文档，那么W模型也基本无法适用（小型公司直接产出原型图，并不写需求说明书）。
- W模型的技术复杂度较高，对于需求设计和测试人员要求较高，实践起来，门槛较高。
一般，仅有中大型企业使用W模型。
H模型（了解）回到顶部
在实践中，人们发现，虽然软件开发中的需求、设计、编码等被分阶段执行。但是并不是完全串行执行的，更多的是交叉、迭代进行。 所以，有专家就提出了H模型，H模型将活动完全独立出来，形成一个完全独立的流程，同时将测试准备和测试执行也清晰的表现出来。
H模型的测试流程
- 测试准备：所有测试执行活动的准备，判断是否到测试的就绪点。
- 测试就绪点：测试准入准则，即是否可以开始执行测试的条件。
- 测试执行：具体的执行测试的程序。
其他流程
- 具体开发中的流程，比如设计流程、小型迭代工作。
H模型的优点
- H模型揭示了软件测试除了测试执行外，还需要有很多的其他工作。
- 软件测试完全独立，贯穿整个生命周期，且与其他流程并行进行。
- 软件测试活动可以尽早的进入准备阶段，尽早执行，灵活性较强。
- 软件测试可以根据被测对象的不同可以分为多层次、分阶段、分次序的执行，同时也是可以被迭代。
H模型的优点
- 管理型要求高：由于模型的灵活性，必须有相应清晰的规划和管理制度。否则测试过程将非常难以管理控制。
- 技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小。
- 测试就绪点分析困难：在测试阶段，我们并不知道测试准备到什么程度算是合适的，也就是就绪点很难把握。比如说就绪点在哪里？就绪的标准是什么？这对测试的执行带来很大的困难。
- 对于整个项目的人员素质要求非常高：在规范的制度下，工作的效率很高，但是由于个人的技能不足，会导致因为一个点出问题，导致整个项目的进度受到干扰。
H模型虽好，但是，大家很少用，因为H模型对于上到管理层，下到各项目组成员的要求非常高。
V、W、H模型总结
V模型适用于中小企业。
W模型适用于中大型企业，因为对于项目组成员要求高。
H模型对项目组成员要求非常高，很少有公司采用。
测试分类回到顶部
按软件测试职位分类回到顶部
- 功能测试，验证当前软件主体功能是否可用。
- 自动化测试，用程序测试程序 （测试API），解放双手
- 性能测试，定位系统瓶颈，保证系统良好性能与稳定性
- 黑盒测试（black-box testing），又称数据驱动测试，该测试不关注底层代码实现，而是测试应用程序的功能，验证结果是否正确，也是就是说只关心软件的输入数据和输出数据。
- 白盒测试（white-box testing），测试的主体就是软件的底层代码，不会在意外在的界面等是否OK，只求底层功能实现，同时逻辑正确。说白了就是把盒子打开，去研究内部的源代码和程序结构。
- 灰盒测试，介于黑、白盒之间的测试，也就是接口测试。
按测试对象是否执行分类回到顶部
- 静态测试（static testing），指的是不实际的执行被测软件，只是静态的检查程序代码、界面、或者文档中可能存在的错误。比如测试接口文档，都是文字，怎么执行？这些测试人员可以是主持人、内审员、作者、列席人员、用户代表、记录员、技术人员一起来开个会啥的.......
- 动态测试（dynamic testing），是指实际的运行被测软件，输入相应的测试数据，检查输出结果是否符合预期的过程。
按软件测试功能分类回到顶部
按测试对象分类
- 黑盒测试
- 白盒测试
- 灰盒测试
上述三种方法中的盒指的是被测对象。
测试手段划分
- 手动测试，测试核心的是人，根据自己主观意识，优点是可以灵活的改变测试操作及环境。
- 自动化测试，自动化测试是测试人员通过脚本驱动测试工具，自动的完成测试，还需人为的配合。另外还可以通过第三方的工具，对比被测对象进行测试。自动化测试的优点是可以高效的实现人工无法实现的操作（比如测试网站的并发量）。
测试阶段划分
- 开发阶段测试：
- 单元测试（组件，模块测试，文件测试，函数、类测试）
- 集成测试(组装测试，测试接口，测试数据结构)
- 已有成型的产品测试：
- 系统测试(将软件和计算机硬件，支持软件，数据和工作人员等要素，结合起来，针对产品进行测试)
- 上线环境，产品可以工作后的测试：
- 验收测试（正式验收测试、Alpha测试、Beta测试）
测试内容划分
- 功能测试
- 界面测试
- 安全测试（银行等企业），验证软件是否只能授权用户提供功能使用。
- 兼容性测试，验证软件在不同环境下是否可用。
- 易用性测试
- 性能测试，验证软件对资源的消耗与产出能力。
- 压力测试
- 恢复测试
- 冒烟测试，冒烟测试术语来源于硬件行业，对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。
测试环节回到顶部
一般地，软件从开发到交付使用，要经历的测试有：
- 黑盒测试
- 白盒测试
- 单元测试
- 集成测试
- 系统测试
- 验收测试
但是测试人员的角色却在不断发生变化：
- 开发人员在不同的开发阶段要做：黑盒测试、白盒测试、单元测试
- 测试人员在测试周期内要做：黑盒测试、集成测试、系统测试
- 而用户要做的就是：验收测试
根据不同的范围，测试可以大致的分为单元测试、集成测试、系统测试和验收测试。体现了测试由小到大、由内致外、循序渐进的测试过程和分而治之的思想。
单元测试回到顶部
单元测试（UT，unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义。并且单元测试，粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合设计。
黑盒测试回到顶部
黑盒测试不考虑程序内部结构和逻辑结构，主要是用来测试系统的功能是否满足需求规格说明书。 一般会有一个输入值，一个输入值，和期望值做比较。黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。可以得到软件的实际使用效果报告。
如电视遥控器，就是一个标准的黑盒测试，我们不用管是液晶的还是其他方式。 要求多组数据，多次测试才能得到准确的报告。
白盒测试回到顶部
白盒测试主要应用在单元测试阶段，主要是对代码级的测试，针对程序内部逻辑构，测试手段有：
- 语句覆盖
- 判定覆盖
- 条件覆盖
- 路径覆盖
- 条件组合覆盖
白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。 这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。
对比黑盒测试，白盒测试更严谨，对软件的源码和架构进行测试，需要软件源代码，流程图等设计文档。
黑盒，白盒测试，相辅相成，白盒测试通过了，还得运行软件，查看软件的性能好坏，界面美丑，是否易用等等方面。
灰盒测试回到顶部
灰盒测试是介于白盒测试和黑盒测试之间的测试，灰盒测试既保证了黑盒的关注点，又掌控了白盒的内部结构，但不会对内部程序和运作做详细的了解，灰盒测试结合了白盒测试和黑盒测试的要素。
集成测试回到顶部
集成测试（IT，system integration test），又称为组装测试，界于单元测试和系统测试之间，起到桥梁作用，一般由开发小组采用白盒加黑盒的方式来测试，既验证设计，又验证需求。 主要用来测试模块与模块之间的接口，同时还要测试一些主要业务功能。集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它最简单的形式是：把两个已经测试过的单元组合成一个组件，测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合为程序的更大部分。方法是测试片段的组合，并最终扩展成进程，将模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有集成测试进程。
系统测试回到顶部
系统测试（ST，system test）粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合需求规格说明书。在经过以上各阶段测试确认之后，把系统完整地模拟客户环境来进行的测试。系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方，从而提出更加完善的方案。它的的任务是尽可能彻底地检查出程序中的错误，提高软件系统的可靠性，其目的是检验系统"做得怎样？"。这阶段又可分为三个步骤：
- 模块测试，测试每个模块的程序是否有错误。
- 组装测试，测试模块之间的接口是否正确。
- 确认测试，测试整个软件系统是否满足用户功能和性能的要求。
该阶段结束应交付测试报告，说明测试数据的选择，测试用例以及测试结果是否符合预期结果。测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。
验收测试回到顶部
验收测试（AT，acceptance test）与系统测试相似，主要区别是测试人员不同，验收测试由用户执行。一般分为：
- α测试（内测）：Alpha测试模拟实际操作环境下验收测试，如删档内测试，软件只是初步完成的产品，bug可能较多，不会进行上线提供用户访问。
- β测试（公测）：Beta测试系统已经通过内部测试，大部分错误已经修复，即将正式发布，在多个真实环境下发布，如不删档公测。 对比α版本已经有了较大改进，但仍可能存在一些bug，需要大规模测试，例如DNF公司更新一个地图，提供公测免费下载，由专业游戏玩家进行游戏结果反馈，开发者再进行修复。
- γ版本：Gamma版本，指的是软件版本正式发行的候选版本，与即将发布的正式版相差无几。Gamma版也可以称为RC（Release Candidate）版本。
- UAT测试：UAT测试（user acceptance test），UAT（用户验收测试）阶段的测试就不是软件开发商自己的测试来做了，而是由客户根据自己的实际业务场景，（或派人员）来使用软件，对具体的功能进行测试。
随机测试回到顶部
随机测试也称为探索测试。
主要是对被测软件的一些重要功能进行复测，也包括测试那些当前测试用例没有覆盖到的部分。除此之外，对于软件的更新和新增功能进行重点测试，尤其是对一些特殊情况点、特殊的使用环境、并发性等进行测试，还包括以前测试中发现的重大bug进行再次测试。
随机测试可以结合回归测试一起进行。
回归测试回到顶部
回归测试（regressive testing）是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。
回归测试流程 以下流程适合单元测试、集成测试和系统测试：
- 在测试策略制定阶段，制定回归测试策略；
- 确定需要回归测试的版本；
- 回归测试版本发布，按照回归测试策略执行回归测试；
- 回归测试通过，关闭缺陷跟踪单（问题单）；
- 回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试；
灰度发布（测试）回到顶部
灰度发布（或称金丝雀发布，或称灰度测试），是指在黑与白之间能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。
灰度发布是对某一产品的发布逐步扩大使用群体范围，也叫灰度放量。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。
灰度发布的意义
灰度发布能及早获得用户的意见反馈，完善产品功能，提升产品质量，让用户参与产品测试，加强与用户互动，降低产品升级所影响的用户范围。
灰度发布的步骤
- 定义目标
- 选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
- 筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等
- 部署系统：部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调
- 发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表
- 产品完善
- 新一轮灰度发布或完整发布
穷尽测试回到顶部
尽管我们提出了如此多的测试用例，一定还会有未涉及到的所有测试方法。
穷尽测试指的是包含了软件输入值和前提条件所有的可能的组合的测试方法，完成穷尽测试的系统中不该残留任何未知的软件缺陷，因为必须去做更多的测试去找到他们。
但是在绝大多数软件中，测试受到时间和经济成本的影响，不可能完成穷尽测试，而是基于风险驱动模式，侧重的设计测试用例，寻求缺陷和研发成本的平衡。
单元、集成、系统测试的比较回到顶部
测试方法不同
- 单元测试属于白盒测试范畴；
- 集成测试属于灰盒测试范畴；
- 系统测试属于黑盒测试范畴；
考察范围不同
- 单元测试主要测试单元内部的数据结构、逻辑控制、异常处理等；
- 集成测试主要测试模块之间的接口和接口数据传递关系，以及各模块组合后的整体功能；
- 系统测试主要测试整个系统相对于需求的符合度；
评估基准不同
- 单元测试的评估基准主要是逻辑覆盖率；
- 集成测试的评估标准主要是接口覆盖率；
- 系统测试的评估基准主要是测试用例对需求规格的覆盖率；
软件测试分类与环节回到顶部
软件测试分类较多，称谓也有所不同，而且各分类具有一定的互通性，交叉性。
