软件测试工程师培训-测试基础

软件测试工程师培训

测试基础培训内容软件测试的定义软件测试的模型测试策略软件测试的定义软件生存周期软件测试的概念软件测试的对象软件测试的分类软件测试的目的软件测试的原则软件生存周期软件生存周期：项目规划、需求定义和需求分析、软件设计、程序编码、软件测试、运行维护。问题：需求定义与需求分析？软件生存周期设计说明书设计员：我要让软件怎么做？需求规格说明书分析员：我可以提供什么？源程序程序员：我要让计算机怎么做？软件需求用户：我要什么？运行结果计算机：程序运行得到什么？理解正确性编码正确性理解正确性设计正确性表达正确性理解正确性表达正确性相符吗？输入正确性运行正确性软件测试的概念软件生存期的各个阶段都可能产生错误。而软件需求分析、设计和实现阶段是软件的主要错误来源。问题：需求分析、设计都可能引入什么错误；其严重性如何？软件测试的概念经典定义：在规定的条件下对程序进行操作，以发现错误和对软件质量进行评估

A+B+C=>D使用人工或自动化手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是发现预期结果与实际结果之间的差别。软件测试的概念扩展定义：软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（包括输入数据与预期输出结果），并利用这些测试用例运行软件，以发现软件错误的过程。软件测试的概念广义的软件测试是由确认、验证、测试3个方面组成。确认：评估将要开发的软件产品是否正确无误、可行和有价值的。确认意味着确保一个待开发软件是正确无误的，是对软件开发构想的检测。验证：检测软件开发的每个阶段、每个步骤结果是否正确无误，是否与软件开发各阶段的要求或期望的结果相一致。验证意味着确保软件会正确无误地实现软件的需求，开发过程是沿着正确的方向进行的。测试：与狭隘的测试概念统一。软件测试的概念确认：保证所生产的软件可追溯到用户需求的一系列活动。（生产的软件是否正确）确认（validation）：arewebuildingtherightproduct?验证：保证软件正确地实现了特定功能的一系列活动。（生产软件的步骤是否正确）验证（verification）：arewebuildingtheproductright?软件测试的概念确认主要体现在计划阶段、需求分析阶段，也会出现在测试阶段；验证主要体现在设计阶段、编码阶段；测试主要体现在编码阶段和测试阶段。确认、验证与测试是相辅相成的。确认产生验证和测试的标准，验证和测试帮助完成确认。软件测试的对象软件测试不等于程序测试。软件测试贯串于软件定义和开发的整个期间。需求规格说明、概要设计说明、详细设计说明、程序、用户文档都是软件测试的对象。软件测试的分类按测试用例设计方法：白盒测试、黑盒测试。按测试策略和过程：单元测试、集成测试、确认测试、系统测试、验收测试。按实施对象：企业内部测试、最终用户测试、第三方测试。软件测试的目的测试的最直接的目的是寻找错误，并且是尽最大可能找出最多的错误。观点1：好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。观点2：成功的测试是发现了至今为止尚未发现的错误的测试。测试方案1、测试方案2测试方案3软件测试的目的证明程序的正确性——除非仅处理有限种情况发现程序错误——直接目标检查系统是否满足需求——期望目标软件测试的目的测试目的延伸（软件工程）：测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。

软件测试的目的通过分析错误产生的原因还可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行软件过程改进。同时通过对测试结果的分析整理，还可以修正软件开发规则，并为软件可靠性分析提供依据。软件测试的目的测试是以评价一个程序或者系统属性为目标的一种活动，测试是对软件质量的度量与评估，以验证软件的质量满足用户的需求，为用户选择与接受软件提供有力的依据。软件测试的目的验证用户需求发现软件缺陷改进开发过程目的：在软件分发到最终用户手中之前，发现并解决软件缺陷软件测试的原则所有的软件测试都应追溯到用户需求。尽早地和不断地进行软件测试。程序员应避免检查测试自己编写的程序。执行测试计划，尽量避免测试的随意性。增量测试，由小到大。软件测试的原则充分注意群集现象。完全测试是不可能的，测试需要终止。测试无法显示软件潜在的错误妥善保存一切测试过程文档。培训内容软件测试的定义软件测试的模型测试策略软件测试的模型V模型W模型H模型其他模型V模型——制定测试案例用户需求需求分析概要设计详细设计编码单元测试集成测试确认和系统测试验收测试软件产品V模型－应用需求、设计和编码的开发活动随时间而进行，而相应的测试活动（即针对需求、设计和编码的测试）开展的次序正好相反。成功应用V模型的关键因素是设计测试案例的时机。V模型－问题测试是开发之后的一个阶段。测试的对象就是程序本身。实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。W模型W模型－应用测试伴随整个开发周期。测试对象不仅是程序，还包括需求和设计。相应开发活动完成，即可执行测试（例如：需求分析完成，即可进行针对需求的测试/设计）。W模型－应用需求验证关注重点：完备性一致性正确性可行性易修改性易理解性易测试性和可验证性W模型－应用设计验证测试关注重点：完备性一致性正确性可行性易修改性模块性健壮性易追溯性易测试性和可验证性W模型－问题W模型未解决V模型中的部分问题：需求、设计、编码串行进行，无法并行工作。未将测试流程的完整性表示出来。H模型测试流程：测试准备活动：测试计划、测试设计、测试开发。测试执行活动：测试运行、测试评估。测试准备测试执行测试流程其他流程（如设计流程）测试就绪点H模型－应用测试不仅仅是测试执行，还包括其他活动。测试是一个独立流程，贯穿产品整个周期，与其他流程并发进行。测试要尽早准备，尽早执行。H模型－意义测试准备和测试执行分离，有利于资源调配。降低成本，提高效率。充分体现测试过程（不是技术）的复杂性。有组织、结构化的独立流程，有助于跟踪测试投入的流向。其他模型－X模型其他模型－X模型X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试。此后将进行频繁的交接，通过集成最终合成为可执行的程序。这一点在图的右上方得以体现。这些可执行程序还需要进行测试，已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。X模型还定位了探索性测试，即图中右下方所示。其他模型－X模型对V模型提出质疑，也因为V模型基于一套必须按照一定顺序严格排列的开发步骤，而这很可能并没有反映实际的实践过程。因为在实际中，很多项目缺乏足够的需求，V模型还是从需求处理开始。质疑了单元测试和集成测试的区别，因为在某些场合人们可能会跳过单元测试而热衷于直接进行集成测试。其他模型－前置模型其他模型－前置模型开发和测试相结合：前置测试模型将开发和测试的生命周期整合在一起。对每一个交付内容进行测试：每一个交付的开发结果都必须通过一定的方式进行测试。在设计阶段进行测试计划和测试设计：设计阶段是做测试计划和测试设计的最好时机。其他模型－前置模型测试和开发结合在一起：将测试执行和开发结合在一起，并在开发阶段以编码-测试-编码-测试的方式来体现。让验收测试和技术测试保持相互独立：验收测试应该独立于技术测试，这样可以提供双重的保险，以保证设计及程序编码能够符合最终用户的需求。培训内容软件测试的定义软件测试的模型测试策略测试策略测试的过程单元测试集成测试确认、系统与验收测试测试的过程集成测试确认测试系统测试单元测试被测模块已集成的软件已确认的软件可交付的软件测试通过的模块设计信息软件需求系统其它元素单元测试被测模块单元测试被测模块验收测试用户核心流程单元测试单元测试又称为模块测试，是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。软件单元测试的目的是检测程序模块对《详细设计说明书》的符合程度；软件单元测试依据是《单元测试计划》。单元测试－设计测试模型驱动模块：相当于所测模块的主程序。桩模块：也叫做存根模块。用以代替所测模块调用的子模块。测试用例驱动模块桩模块2被测模块测试结果桩模块1桩模块n单元测试－设计考虑方面模块接口测试局部数据测试独立路径测试出错处理测试边界条件测试模块接口独立路径边界条件局部数据模块出错处理单元测试－设计原则为模块正常运行设计为正向测试设计为逆向测试设计为满足特殊需求设计为代码覆盖设计单元测试－执行检查编码是否遵循软件编程规范和标准。自动或手动分析程序。设计测试用例并运行。错误跟踪分析。单元测试－完成单元测试单元测试单元测试单元测试单元测试集成测试软件集成测试又称组装测试，即对程序模块采用一次性或增值方法组装起来，对系统的接口进行正确性检验的测试工作。软件集成测试的目的是检测程序对《概要设计说明书》的符合程度；软件集成测试依据是《集成测试计划》。集成测试－设计集成测试，通常是在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是：在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失。一个模块的功能是否会对另一个模块的功能产生不利的影响。各个子功能组合起来，能否达到预期要求的父功能。全局数据结构是否有问题。单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。模块间是否存在时序问题（实时系统）与资源竞争。集成测试－整体拼装一次性组装/整体拼装：使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。可以并行调试所有模块，因此充分利用人力，加快工作进度。接口错误发现晚。错误定位困难。集成测试－整体拼装集成测试－增殖式组装增殖式组装/渐增式组装：首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。集成测试－增殖式组装自顶向下的增殖方式：集成步骤：主模块作为驱动模块，所有与主模块直接相连的模块用桩模块替代。采用深度或广度优先，每次用一个子模块替换桩模块。进行回归测试以确定集成新模块后没有引入错误。从第2步重复进行上述过程，直到整个系统被集成完成。特点：这种组装方式将模块按系统程序结构，沿控制层次自顶向下进行组装。自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。集成测试－增殖式组装集成测试－增殖式组装自顶向下的增殖方式：桩模块的选择集成测试－增殖式组装自底向上的增殖方式：集成步骤：由驱动模块控制最底层模块，进行并行测试。用实际模块替换驱动模块，形成子系统。为子系统配备驱动模块进行测试。按程序结构向上组装测试后的构件，直到整个系统被集成完成。特点：这种组装的方式是从程序模块结构的最底层的模块开始组装和测试。因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。集成测试－增殖式组装集成测试－增殖式组装自底向上的增殖方式：驱动模块的选择集成测试－增殖式组装优点缺点自顶向下测试

可以自然地做到逐步求精，一开始便能让测试者看到系统的框架

需要提供桩模块输入输出模块、复杂算法模块一般在最底层，错误发现晚自底向上测试

不需要桩模块输入输出模块、复杂算法模块测试早

直到最后一个模块被加进去之后才能看到整个系统的框架

集成测试－增殖式组装混合增殖式测试：衍变的自顶向下的增殖测试强化输入输出模块、复杂算法模块测试。自底向上组装成子系统。由主模块开始自顶向下增值测试。自底向上——自顶向下的增殖测试首先对含读操作的子系统自底向上直至根结点模块进行组装和测试。然后对含写操作的子系统做自顶向下的组装与测试。集成测试－增殖式组装关键模块：满足某些软件需求。高层控制模块。较复杂、较易发生错误。有明确定义的性能要求。关键模块及早测试，回归测试时重点测试。集成测试－设计集成测试应与单元测试的完成时间协调起来。在制定测试设计时，应考虑如下因素：是采用何种系统组装方法来进行组装测试。组装测试过程中连接各个模块的顺序。模块代码编制和测试进度是否与组装测试的顺序一致。测试过程中是否需要专门的硬件设备。集成测试－完成单元测试单元测试单元测试单元测试单元测试集成测试确认、系统与验收测试集成测试确认测试系统测试单元测试被测模块已集成的软件已确认的软件可交付的软件测试通过的模块设计信息软件需求系统其它元素单元测试被测模块单元测试被测模块验收测试用户核心流程确认、系统与验收测试－确认测试确认测试包括有效性测试与软件配置复查。任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明中已经明确规定。确认、系统与验收测试－确认测试有效性测试是在模拟的环境（可能就是开发的环境）下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列的需求。软件配置复查保证软件配置的所有成分都齐全。各方面的质量都符合要求。具有维护阶段所必需的细节。而且已经编排好分类的目录。确认、系统与验收测试－系统测试系统测试是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起测试。在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。确认、系统与验收测试－验收测试验收测试根据合同、《需求规格说明书》对成品进行验收测试。验收测试与系统测试的区别：组织机构：验收组由用户代表、开发商代表、监理代表等组成。测试地点：验收测试原则上在顾客所在地进行，但如顾客同意也可在公司内模拟用户环境进行。覆盖范围：验收测试针对用户关心的核心流程。实施人员：用户为主。确认、系统与验收测试－设计功能（机能）测试：目标中的功能是否真正实现了。安全性测试：设法破坏程序的安全性、保密检查。可靠性测试：平均无故障时间、因故障停机时间，需要模拟运行环境。恢复测试：测试系统出错后如何恢复正常工作的。确认、系统与验收测试－设计并发负载测试：在一定工作负荷和配置条件下，系统响应时