搜索
软件测试理论基础概述软件测试定义软件测试目标软件测试对象软件测试原则软件测试方法软件生命周期软件测试流程软件测试评测方法建议软件测试定义定义一：使用人工和自动化的手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。定义二：软件测试是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程。•验证：是为确定某一开发阶段的产品是否满足在该阶段开始时提出的要求而对系统或部件进行评估的过程。•确认：是在开发过程中或结束时，对系统或部件进行评估，以确定其是否满足需求规格的过程。定义三：软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例，并利用这些测试用例运行软件，以发现软件错误的过程。软件测试目标第一：确保软件的质量第二：提供信息第三：保证整个软件开发过程是高质量的软件测试对象软件测试的对象不仅仅是程序，还包括整个软件生命周期中产生的所有过程文档。如：•在软件定义阶段产生的可行性报告、项目实施计划、软件需求说明书或系统功能说明书，•在软件开发阶段产生的概要设计说明书、详细设计说明书，以及源程序等。软件测试原则一、尽早和不断地进行测试二、遵循Pareto原则三、软件测试是不完全的四、并非所有的软件错误都能修复五、由小到大的测试范围六、避免由开发人员测试自己的程序七、追溯至用户需求八、程序修改后要回归测试九、妥善保存一切测试过程文档软件测试方法软件测试单元测试集成测试系统测试验收测试静态测试动态测试按阶段划分按是否运行程序划分按是否查看源代码划分其他白盒测试黑盒测试功能测试性能测试回归测试冒烟测试随机测试兼容性测试安装测试易用性测试界面测试逻辑功能测试一般性能测试稳定性测试负载测试压力测试软件测试方法单元测试集成测试系统测试验收测试概念对软件中的最小可测试单元进行检查和验证在单元测试基础上的，将所有模块按照概要设计要求组装成子系统或系统后的测试，重点测试不同模块的接口部分将整个软件系统看做一个整体进行测试，包括对功能、性能以及软件所运行的软硬件环境进行测试旨在向未来的用户展示该软件系统已能满足其需求要求测试时机编码之后，代码已经通过编译之后在单元测试之后集成测试之后系统测试后期，软件正式交付用户使用之前测试人员白盒测试工程师或开发人员白盒测试工程师或开发人员黑盒测试工程师用户和黑盒测试工程师测试依据1、源程序本身，包括代码和注释2、详细设计文档1、单元测试的模块2、概要设计文档需求规格说明书需求规格说明书测试通过标准1、单元测试用例的执行率为100%，通过率为95%2、语句的覆盖率达100%3、分支的覆盖率达85%1、各个单元模块结合到一起能够协同配合，正常运行2、测试用例的执行率为100%，通过率为95%1、系统功能、性能等满足需求规格说明书中的要求2、测试用例的执行率为100%，通过率为95%1、系统功能、性能等满足需求规格说明书中的要求2、测试用例的执行率为100%，通过率为95%主要方法控制流测试、数据流测试、排错测试、分域测试等自顶向下测试、自底向上测试功能测试、性能测试、随机测试等Alpha测试、Beta测试软件测试方法测试阶段静态测试动态测试可行性评审√需求评审√设计评审√单元测试√集成测试√系统测试√验收测试√静态测试：不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。动态测试：实际运行被测软件，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。软件测试方法黑盒测试白盒测试概念又称为功能测试或数据驱动测试。它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。在测试时，把程序看作一个黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试。它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。又称结构测试或逻辑驱动测试。它是知道产品内部工作过程，可通过测试来检测产品内部工作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都能按预定要求正确工作，而不顾它的功能。测试人员黑盒测试工程师或用户白盒测试工程师或开发人员测试依据需求规格说明书1、源程序本身，包括代码和注释2、详细设计文档主要方法等价类划分、边界值分析、因果图、错误推测等逻辑覆盖、循环覆盖和基本路径测试应用软件确认测试软件验证测试软件测试方法功能测试：主要检查实际软件的功能是否符合用户的需求。功能测试又可细分为：逻辑功能测试：假设一个软件的业务流程是，如果输入1就走A流程，输入2，走B流程，输入3，退出。那对于测试人员来说，输入1到3就是不同的逻辑，你也可以输入0，4，来检验程序是否有做保护处理。界面测试：验证软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息等方面的测试。易用性测试：从软件使用的合理性和方便性等角度对软件系统进行检查，来发现软件中不方便用户使用的地方。安装测试：是验证软件能否正常进行安装和卸载的测试。兼容性测试：是测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。包括向上兼容、向下兼容，软件兼容和硬件兼容。软件测试方法性能测试：主要是验证系统的性能指标是否满足需求要求。性能测试又可细分为：一般性测试：指的是让被测系统在正常的软硬件条件下运行，不向其施加任何压力。稳定性测试：也叫可靠性测试，是指连续运行被测系统，检查系统运行时的稳定程度。负载测试：指让被测系统在其能忍受的压力的极限范围内连续运行，检查系统运行时的稳定性。压力测试：通常是指持续不断地给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。软件测试方法回归测试：是在软件维护阶段，重复执行上一个版本测试时的测试用例，对修改后的新版本进行的测试。其目的是检验对软件所做的修改是否正确。冒烟测试：是指在对一个新版本进行系统的大规模测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。随机测试：是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。软件生命周期软件生命周期：即一个软件从功能确定、设计、开发成功、投入使用，并在使用中不断的修改、增补和完善，直至被新的需要替代而停止使用的全过程。软件生命周期包括软件开发的生命周期和软件测试的生命周期。软件生命周期模型是软件项目的流程模版，为制定项目流程提供参考依据。软件生命周期瀑布模型优点：1、强调开发的阶段性，各阶段具有顺序性和依赖性2、推迟编码实现的观点，主张早期调研和需求分析3、质量保证的观点，要求每个阶段的产品都应在评审之后才能流入下一阶段，作为下一阶段的输入4、“线性”逻辑容易掌握及应用5、可在复杂的非线性模型中应用瀑布模型缺点：1、文档驱动，用户无法及时了解产品的情况2、当需求变更时将会导致阶段反复，而且都要重复需求、设计、编码、测试等过程。3、流程单一，不可逆4、早期的错误可能要等到开发后期的测试阶段才能发现，无法全面的保证质量，控制风险5、严格线性运行，无法在人员、工作量分配上实现最优搭配，严重影响工作效率和进度瀑布模型适用范围：需求稳定的产品计划需求设计编码测试运维软件生命周期编编编编编编编编编编编编编编编编编编编编编编编编编编编编编编编编编编V模型优点：1、明确地标明了测试过程中存在的不同级别2、清楚地表示出测试阶段和开发过程各阶段的对应关系3、强调了测试过程与开发过程的并行性V模型缺点：1、没有说明项目的前期测试需要做哪些工作，如编写测试计划、测试用例等2、把系统开发过程划分为具有固定边界的不同阶段，很难跨过这些边界来采集测试所需要的信息软件生命周期渐进模型优点：1、设计上的灵活性,可以在项目的各个阶段进行变更2、关键的功能更早出现，随着项目推进,客户始终掌握项目的最新信息，可以提高开发人员与客户之间的有效信息交互3、用户在整个软件开发过程中都直接参与，因此最终的产品能够很好地满足用户的需求4、以小的分段来构建大型系统,使成本计算和风险控制变得简单容易渐进模型缺点：由于过多的开发周期会增加成本，耗费时间渐进模型适用范围：开发初期用户需求不甚明确相关技术和理论需要不断研究、反复实验开发过程需要经常与用户交互的产品软件测试流程•需求评审•测试计划•测试设计•测试前期准备•测试执行•缺陷管理•测试报告•测试评测软件测试流程-需求评审需求评审的注意事项：一、注意对需求规格说明的正确性进行评审1、是否冲突或者重复2、是否清晰、简洁、无二义性3、是否有内容和语法错误4、是否合理地确定了性能指标5、是否合理地确定了安全性指标二、注意对需求规格说明的完整性进行评审1、是否包含了所有已知的客户需求或系统需求2、所有需求的详细程度是否合适，是否能为设计提供足够的基础3、是否定义了每个需求的实现优先级4、是否把不确定的需求标记为待确定的问题，而不是直接遗弃5、是否对所有预期的错误条件所产生的系统行为都进行了描述三、注意对需求的可实施性进行评审1、是否每个需求都有惟一标识2、是否每个需求都易修改，可跟踪3、是否每个需求都是实际的、量化的、逻辑清晰的4、在现有的资源下,是否能实现所有的需求5、每个需求在特定的输入条件下是否给出已知的输出结果测试人员参加“需求评审”活动需要达到的目标：1、充分理解用户需求2、确保需求的可测试性软件测试流程-测试计划为什么要编写测试计划1）领导能够根据测试计划做宏观调控，进行相应资源配置等2）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等3）便于其他人员了解测试人员的工作内容，进行有关配合工作什么时间开始编写测试计划尽早开始。原则上应该在需求定义完成之后开始编写测试计划，对于开发过程不是十分清晰和稳定的项目，测试计划也可以在总体设计完成后开始编写由谁编写测试计划具有丰富经验的测试负责人测试计划编写策略1.明确测试的目标，增强测试计划的实用性2.坚持“5W1H”规则，明确内容与过程1）why—为什么要进行这些测试2)what—测试哪些方面，不同阶段的工作内容3)who—安排哪些测试人员进行测试4)when—测试不同阶段的起止时间5)where—给出测试文档和软件的存放位置，测试环境等6)how—指出测试的方法和工具3.采用评审和更新机制，保证测试计划满足实际需求4.分别创建测试计划与测试详细规格、测试用例软件测试流程-测试设计过程：分解测试对象定义测试用例建立需求覆盖设计测试步骤分析测试用例更新测试用例软件测试流程-测试设计测试用例是为某个特殊目标而编制的一组测试输入、执行条件、测试步骤以及预期结果。为什么要写测试用例1）便于团队交流2）便于重复测试3）便于跟踪统计4）便于用户自测什么时候写测试用例：通常在测试设计阶段，即需求规格说明书和测试计划完成之后由谁来写测试用例：测试设计人员测试用例编写依据：需求规格说明书和软件原型测试用例包含的内容：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则、注释最佳方案：为每个被测需求至少编制两个测试用例：正面测试用例和负面测试用例软件测试流程-测试设计（一）白盒技术1、逻辑覆盖：是通过对程序逻辑结构的遍历实现程序的覆盖(1)语句覆盖：设计足够多的测试用例，使被测程序中每条语句至少执行一次(2)判定覆盖：设计足够多的测试用例，使得程序中的每一个判定至少获得一次‘真’值和‘假’值(3)条件覆盖：设计足够多的测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次(4)条件判定组合覆盖：设计足够多的测试用例，使得判定中的每个条件的所有可能（真/假）至少出现一次，并且每个判定本身的判定结果也至少出现一次(5)条件组合覆盖：设计足够多的测试用例，使得每个判定中条件的各种可能组合都至少出现一次满足条件组合覆盖一定满足判定覆盖、条件覆盖、条件判定组合覆盖(6)路径覆盖：设计足够多