西北工业大学软件测试复习提纲

软件测试提纲单元测试：Unittesting，一段代码的基本测试，实际大小未定，通常是一个函数或子程序，一般由开发者执行。单元测试是针对程序模块进行正确性检验的测试。从本质上讲，属于白盒测试。是测试过程的最小粒度。集成测试：Integrationtesting，被测系统的所有组件都集成在一起，找出被测系统组建之间关系和接口中的错误。该测试一般在单元测试之后进行。系统测试：Systemtesting，系统测试实际上是针对系统中各个组成部分进行的综合性检验。尽管每一个检验有着特定的目标，然而所有的检测工作都要验证系统中每个部分均已得到正确的集成，并能完成指定的功能。验收测试：Acceptancetesting，它包括Alpha测试和Beta测试，系统开发生命周期方法论的一个阶段，由相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收该系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性的控制。α测试：Alphatesting，既可以是一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试。Alpha测试不能由程序员或测试员完成。β测试：Betatesting，软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。静态测试：Statictesting，不通过执行来测试一个系统，如代码检查、文档检查和评审等。静态测试是基于期望、专业经验、通用标准来对工作件的特征进行详细描述检查的一种测试方法。动态测试：Dynamictesting，通过执行软件的手段来测试软件。白盒测试：Whiteboxtesting，根据软件内部的工作原理分析来进行测试，是基于代码的测试。测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件质量。白盒测试一般由项目经理在程序开发中进行。白盒测试也叫结构性测试、逻辑测试或基于程序的测试，是根据被测程序的内部结构设计测试用例的一类测试。黑盒测试：Blackboxtesting，指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件各种输出结果来发现软件的缺陷和测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。黑盒测试又叫功能性测试、数据驱动测试或基于规格说明的测试，是一种从用户观点出发的测试。灰盒测试：Grayboxtesting，介于白盒测试与黑盒测试之间，灰盒测试结合了白盒测试和黑盒测试的要素，它考虑了用户端、特定的系统知识和操作环境。功能测试：functionaltest，功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。逻辑功能测试界面测试：Userinterfacetesting，指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字、图片组合是否完美，操作是否友好，等等。测试的目标是确保用户界面为用户提供相应的访问或浏览功能，确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性。易用性测试：Usabilitytesting，指用户使用软件时是否感觉方便。安装测试：Installingtesting，确保该软件在正常情况和异常情况的不同条件下，例如，进行首次安装、升级、完整的或自定义的安装都能进行安装。安装测试包括测试安装代码以及安装手册。兼容性测试：Compatibilitytesting，指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能够很友好的运行的测试。性能测试：Performancetesting，评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。在一定的负载情况下，系统的响应时间、资源利用、效率等特性是否满足特定的性能需求。时间性能：事务响应时间等空间性能：系统资源消耗等一般性能测试可靠性测试：在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。负载测试：通过在被测系统上不断加压，直到性能指标达到极限，例如“响应时间”超过预定指标或都某种资源已经达到饱和状态。压力测试：压力测试方法测试系统在一定饱和状态下，例如CPU、内存在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。并发测试：并发测试方法通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其者他性能问题。配置测试：配置测试方法通过对被测系统的软\硬件环境的调整，了解各种不同对系统的性能影响的程度，从而找到系统各项资源的最优分配原则。回归测试：Regressiontesting，在错误修改之后，重复先前的测试以保证修改的正确性。理论上，对软件的任何新版本，都需要进行回归测试，验证以前发现和修复的错误不会在新软件版本上再现。冒烟测试：Smoketesting，冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。随机测试：Adhoctesting，它主要是根据测试者的经验对软件进行功能和性能抽查，是没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。软件缺陷生存周期New、Open、Fixing、Fixed、Reopen、Rejected、ClosedOpen、Fixing、Fixed称为缺陷的活动态，Rejected、Closed称为缺陷的终结态。CMM：CapabilityMaturityModel，过度成熟度模型。TMM：TestingMaturityModel，测试成熟度模型。（1级初始级，2级定义级，3级集成级，4级管理和度量级，5级优化级）。广义的测试概念：广义的软件测试由确认、验证、测试3个方面组成。1.确认：评估将要开发的软件产品是否正确无误、可行和有价值。2.验证：检测软件开发的每个阶段、每个步骤的结果是否正确无误，是否与软件开发各阶段的要求或期望的结果相一致。3.测试：与狭义的测试概念统一。狭义的测试概念：（第一类测试）软件测试是在既定的状况条件下，运行一个系统或组件，观察记录结果，并对其某些方面进行评价的过程。（第二类测试）软件测试是为了发现错误而运行程序的过程。软件测试的对象：软件测试并不等于程序测试，软件测试应该贯穿整个软件定义与开发整个期间。因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应该是软件测试的对象。软件测试的原则：编号原则1测试用例中一个必需部分是对预期输出或结果进行定义2程序员应当避免测试自己编写的程序3编写软件的组织不应当测试自己编写的软件4应当彻底检查每个测试的执行结果5测试用例的编写不仅应当根据有效和遇到的输入，而且也应当根据无效或者未遇到的输入情况6检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”7应该避免测试用例用后即弃，除非软件本身就是一个一次性的软件8计划测试工作时不应默许假定不会发生错误9程序某部分存在更多错误的可能性，与该部分已发生错误的数量成正比10软件测试是一项极富创造性、极具智力挑战的工作软件测试过程：具体来讲，软件测试过程是一个不断输入数据，观察和记录软件运行行为和输出结果，并判断其行为和输出结果的正确性，直到能够由这些结果有效地分析该软件的性能的过程。抽象地讲，软件测试就是不断进行测试、排错、修改，然后再进行测试(回归测试)、排错、修改，直到软件达到用户性能要求的一个循环往复过程。从软件开发的过程按阶段划分有：1.需求分析：在软件开发生命周期的需求阶段，业务需求的定义是比较高级的，并且也是后续阶段及最终实现的基础。因此，在需求阶段对需求进行验证，可以使得尽早的发现错误。2.单元测试：单元测试是测试的基本阶段，也是在软件开发过程中要进行的最低级别的测试活动，在这个过程中，软件的独立单元将在与程序的其他部分隔离的情况下进行测试，针对的是单个的函数模块，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例使之对任何合理的输入和不合理的输入，都能鉴别和响应。3.集成测试：集成测试是在单元测试的基础上，把程序的基本单元按照软件结构设计的要求，组装成软件系统进行测试。一般采用黑盒测试方法，白盒测试方法作为补充，主要在模块功能、模块间接口等方面的查错。4.确认测试：集成测试完成以后，分散开发的模块被联接起来，构成完整的程序，确认测试应检查软件能否按合同要求进行工作。5.系统测试：系统测试实际上是针对系统中各个组成部分进行的综合性检验。尽管每一个检验有着特定的目标，然而所有的检测工作都要验证系统中每个部分均已得到正确的集成，并能完成指定的功能。6.验收测试：最后，要进行验收测试。验收测试是以用户为主的测试，用户参与设计测试用例，使用用户界面输人测试数据，并分析测试的输出结果，还应该对软件的兼容性、可维护性等进行确认，验收测试实际上是对整个测试计划的一个走查。软件测试过程模型V-模型：虽然V-模型已存在了很长时间，且被广泛应用，但是它也存在一些局限性。比如，它没有明确地说明早期的测试，无法体现“尽早地和不断地进行软件测试”的原则。W-模型：W-模型是V-模型的发展，强调的是测试过程伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。W-模型也存在局限性，它无法支持迭代的开发模型。对于当前软件开发复杂多变的情况下，W-模型并不能解除测试管理面临的难题。H-模型：H-模型将软件测试过程活动完全独立出来，使之贯穿于整个产品的周期，与其他流程并发地进行。X-模型：X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，右上半部分显示此后将进行频繁的交接，通过集成最终合称为可执行的程序，这些可执行程序还需要进行测试。基于模型的测试：软件模型是对软件行为和软件结构的抽象描述。基于模型的软件测试技术可以根据测试模型对被测试程序中所有输入及其状态组合进行系统枚举，因此可以使测试实现系统化、集中化以及自动化。面向对象的测试：传统程序执行的路径是在程序开发时定义好的，程序执行的过程是主动的，其流程可以用一个控制流图从头至尾地表示；面向对象程序中方法的执行通常不是主动的，程序的执行路径也是运行过程中动态地确定的，因此描述它的行为往往需要动态的模型。与传统的程序相比较，面向对象程序主要具有封装性、继承性、多态性和动态绑定等几大特性。web测试：Web应用程序拥有许多传统软件没有的特点。Web应用程序通常都是由品类繁多的实体组成，这些实体大部分是使用多语义的标记符或脚本编写而成的，例如，HTML、Javascript、eol脚本、Asp和JSP等。测试用例设计原则：测试用例的设计是软件测试人员的工作核心，它的设计必须符合以下原则：1.测试用例设计要基于需求：必须按照不同的测试级别的要求，设计测试用例。如单元测试依据详细的设计说明，集成测试，依据概要设计说明书等。2.测试用例设计要基于测试方法：必须指明采用的用例设计方法。为了达到不同的测试覆盖率，要采用相应的测试方法，如等价类划分、边界值分析、正交分析和决策表等具体方法。3.测试用例必须具有代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。4.测试用例必须具有可执行性：每个用例必须有详细的执行步骤。5.一个用例只能针对一个问题：同时覆盖多个测试点，会导致bug定位困难。6.测试结果必须具有可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。7.测试结果必须具有可再现性：即对同样的测试用例，系统的执行结果应当是相同的。8.兼顾测试的充分性和