ISTQB基础知识：软件测试与软件生命周期

ISTQB基础知识软件测试与软件生命周期目录软件开发模型软件测试级别软件测试类型维护性测试软件开发模型软件开发模型简介软件生命周期软件需求、分析、设计、实现、测试、部署Deploy/Release、维护和退出的过程，称为“软件生命周期”（SoftwareLifeCycle）概述软件开发模型是指软件开发所依据的方式和过程从事软件测试为什么要熟悉开发模型？测试不是孤立存在的，测试活动与开发活动是息息相关的每个开发活动都有相对应的测试活动不同的开发生命周期模型需要不同的测试方法每个测试级别都有其特有的测试目标对于每个测试级别，需要在相应的开发活动过程中进行相应的测试分析和设计在开发生命周期中，测试人员在文档初稿阶段就应该参与文档的评审如何选择开发模型？根据项目的内容根据产品的特征软件开发V模型图V模型分析概述最早由PualRook于80年代末提出。其左右分支形成了V字型，因此称作V模型。含义V模型指出软件测试不仅仅是软件开发的一个独立阶段，而应贯穿于整个软件生命周期中V模型中的右分支列出的软件测试任务和相应的左分支列出的软件开发任务在整个软件项目中有着同等的重要性该模型描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。V模型的缺点仅仅把测试过程作为在需求分析、系统功能设计、系统架构设计及编码之后的一个阶段容易使人理解为测试是软件开发的最后的一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段的隐藏的问题一直到后期的系统测试和验收测试才被发现。说明在测试实践中，V模型中的各个开发及测试阶段可往往会根据具体情况有所增减甚至组合或重新排列迭代-增量模型图原型开发模型快速开发模型RUP（RationalUnifiedProcess），统一软件开发过程AgileDevelopment敏捷开发迭代-增量模型分析在每次迭代过程中,对迭代产生的系统可能需要在不同的测试级别上进行测试。通过将增量模块加入到以前开发的模块中，形成一个逐渐增大的系统，这个系统同样需要进行测试。在完成第一次迭代后，对所有的迭代进行回归测试会变得越来越重要。验证和确认可以在每个增量模块中进行。其它模型X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序前置测试模型体现了开发与测试的结合，要求对每一个交付内容进行测试软件测试级别测试级别概述软件开发的不同阶段对应不同级别(Level)的测试组件测试（单元测试）在软件编码结束后，对编写的每一个程序模块进行测试集成测试（组装测试，联合测试）在模块集成后，对集成在一起的模块组件，有时也可称为“部件”进行测试系统测试将整个程序模块集成为软件系统安装在运行环境下，对于硬件、网络、操作系统及支撑平台构成的整体系统进行测试验收测试（交付测试，确认测试）在上述测试后，需要检测与证实软件是否满足软件需求说明书中规定的要求良好的测试所具有的特征特征每个开发活动都有相对应的测试活动每个测试级别都有其特有的测试目标对于每个测试级别，需要在相应的开发活动过程中进行相应的测试分析和设计在开发生命周期中，测试员在文档初稿阶段就应该参与文档的评审注意：根据项目的特征或系统的架构，可以对测试级别进行合并或重新进行组合。比如，对于商业现货软件(COTS)产品集成到某个系统，购买者可以在系统级别（例如：与基础设施集成、与其他系统的集成或与系统应用的集成）进行集成测试和验收测试（功能的和/或非功能的测试，用户和/或运行测试等）。各个测试级别需要明确的内容测试的总体目标测试用例设计需要参考的工作产品（即测试的依据）测试的对象（即测试什么）发现的典型缺陷和失效对测试用具的需求测试工具的支持专门的方法和职责等注意：如果某些数据属于系统的一部分，那么在测试计划时就应当考虑是否对系统配置数据进行测试。组件测试概述概述组件测试是对软件基本组成单元进行的测试，一般在代码完成后由开发人员完成，测试人员辅助。组件测试的目的是检查代码是否符合设计和规范。测试依据组件需求说明详细设计文档代码测试对象组件程序数据转换/移植程序组件测试的特征和测试内容特征组件测试可能包括功能测试和特定的非功能特征测试，比如资源行为测试（如内存泄漏）或健壮性测试和结构测试（比如分支覆盖）。根据工作产品，例如组件规格说明、软件设计或数据模型等设计测试用例。测试内容模块接口测试检查局部数据结构能否保持完整性模块边界条件测试模块执行路径测试检查模块内部错误处理是否有效组件测试的测试方法测试框架和调试工具通过开发环境的支持，比如组件测试框架或调试工具(debuggingtool)，组件测试会深入到代码中，而且实际上设计代码的开发人员通常也会参与其中。在这种情况下，一旦发现缺陷，就可以立即进行修改，而不需要正式的缺陷管理过程。测试优先的方法或测试驱动开发在编写代码之前就完成编写和自动化测试用例这是高度迭代的方法，并且取决于如下的循环周期：测试用例的开发构建和集成小块的代码执行组件测试修正任何问题并反复循环，直到它们全部通过测试。集成测试概述概述通过单元测试的多个模块组合成更大的模块或子系统或产品，然后进行测试集成测试是对组件之间的接口进行测试，以及测试一个系统内不同部分的相互作用，比如操作系统、文件系统、硬件或系统之间的接口。测试依据软件和系统设计文档系统架构工作流用例测试对象子系统数据库实现基础设施接口集成测试的级别和内容集成级别集成测试，可以应用多种集成级别，也可以根据不同的测试对象规模采用不同的级别。组件集成测试对不同的软件组件之间的相互作用进行测试，一般在组件测试之后进行。系统集成测试对不同系统或软硬件之间的相互作用进行测试，一般在系统测试之后进行。内容各单元的接口是否吻合代码是否符合规定的标准界面标准是否统一等系统测试概述概述将经过确认测试的软件，与计算机硬件、外设、支持软件等一起，在实际运行环境下测试。系统测试关注的是在开发项目或程序中定义的一个完整的系统/产品的行为。目的充分运行系统，验证系统各部件是否能正常工作，符合软件需求规格说明。测试依据系统和软件需求规格说明用例功能规格说明风险分析报告典型测试对象系统、用户手册和操作手册系统配置系统测试类型与方法类型功能测试非功能测试：压力测试/性能测试/容量测试用户界面测试兼容性测试国际化测试/本地化测试测试方法基于需求的测试从需求导出测试目标和测试条件，设计测试用例，测试检查功能或者非功能特性（可靠性和可用性）。基于业务流程的测试从业务流程的说明和对业务流程的理解导出和选择测试用例的测试方法。基于用例（UseCases）的测试黑盒测试设计方法，根据实际的场景设计测试用例，进行测试。基于风险评估的测试说明：在系统测试中，测试环境应该尽量和最终的目标或生产环境相一致，从而减少不能发现和环境相关的失效的风险。系统测试通常由独立的测试团队执行验收测试概述概述技术测试的最后一个阶段，在软件产品完成了系统测试之后、产品发布之前所进行的软件测试活动验收测试通常是由使用系统的用户或客户来进行，同时系统的其他利益相关者也可能参与其中。目的验收测试的目的是建立对系统、系统的某部分或特定的系统非功能特征建立信心。验证系统是否达到了用户需求规格说明书（可能包括项目或产品验收准则）中的要求，保证系统或软件产品最终被用户接受发现缺陷不是验收测试的主要目标。测试依据用户需求系统需求用例业务流程风险分析报告验收测试的对象和内容对象基于完全集成系统的业务流程操作与维护流程用户处理过程结构报告内容安装测试功能测试可靠性测试安全性测试性能测试易用性测试可移植性测试可维护性测试文档测试验收测试的特点验收测试不一定是最后级别的测试。可能会在进行某个系统验收测试之后，进行大规模的系统集成测试。验收测试可以在多个测试级别上进行商业现货软件(COTS)产品可以在安装或集成时进行验收测试；组件的可用性验收测试可以在组件测试中进行；增加新功能的验收测试可以在系统测试之前进行。验收测试的形式形式（5种类型）用户验收测试操作验收测试系统操作验收测试由系统管理员来进行，测试内容主要包括：系统备份/恢复测试；灾难恢复测试；用户管理测试；维护任务测试；数据加载和移植活动；安全漏洞阶段性检查。合同和法规性验收测试合同验收测试根据合同中规定的生产客户定制软件的验收准则，对软件进行测试。应该在合同拟定时定义验收准则。法规性验收测试根据必须要遵守的法律法规来进行测试，比如政府、法律和安全方面的法律法规。验收测试的形式Alphatesting（α测试）在软件产品正式商业销售之前，市场或商业现货软件开发人员希望从市场中潜在的或已经存在的客户中得到关于软件的反馈信息。Alpha测试通常在开发组织现场进行，但测试并非由开发团队执行。Betatesting（β测试）Beta测试或实地测试，是在客户或潜在客户现场进行并由他们执行。概念辨析Alphatesting（α测试）：用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。Betatesting（β测试）：软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。软件测试类型测试类型概述软件类型众多，不同的分类标准对应不同的测试类型分类：功能性测试软件产品特性测试（非功能性测试）软件结构性测试变更相关的测试确认/验证测试（再测试）回归测试功能性测试和结构性测试可以应用于任何测试级别功能性测试概述概述功能性测试是基于软件产品功能和特征，以及专门的系统之间的交互进行的测试可以在各个测试级别进行，既可以用于组件级别、也可以用于集成和系统测试级别功能性测试不考虑程序的具体执行路径，仅关注功能是否实现功能测试的特点通常采用黑盒测试（Black-boxTesting，又称为功能测试或数据驱动测试），是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，只需要测试软件产品外部表现的功能，不需考虑软件产品的内部结构和处理过程。功能性测试的错误类型黑盒测试通常可以发现的错误类型功能错误或遗漏；界面错误；数据结构或外部数据库访问错误；性能错误；初始化和终止错误。注意：安全性测试就是功能测试的一种对安全性相关的功能（比如防火墙）进行测试，从而检测系统和数据是否能抵御外部恶意的威胁，如病毒等。互操作性测试是另一种功能性测试评估软件产品与其他一个或多个组件或系统交互的能力。非功能性测试概述为了测量系统和软件的运行特性，需要进行的测试。可以在任何测试级别上进行。基于产品的性能、负载、可用性、交互性、可维护性、可靠性及可移植性等方面的测试。包括测试产品是否遵从指定的标准、规范和约束，以及操作界面的具体细节和构造上的限制。通过测试，可以在不同尺度上来量化软件和系统的特征，比如进行性能测试来检验系统和软件的反应时间。类型非功能测试包括但不限于：性能测试、负载测试、压力测试、易用性测试、可维护性测试、兼容性、可靠性测试和可移植性测试结构测试概述概述结构测试也称白盒测试(White-boxTesting，又称逻辑驱动测试)。把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都能按预定要求工作，而不顾它的功能。最好在进行基于规格说明的测试