单元1 软件测试入门

单元1 软件测试入门

软件测试

认识：单纯以发现错误为目的的到验证确认软件的功能特性、评估软件质量为目的的过程。

定义

  • IEEE软件工程(1983) :

    使用人工或者自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。它是帮助识别开发完成(中间或最终的版本)的计算机软件(整体或部分)的正确度（Correctness)、完全(Completeness)和质量(Quality)的软件过程:是SQA(Software Quality Assurance)的重要子域。

  • 软件工程知识体系：

    软件测试由一个程序的行为在有限测试用例集合上，针对期s望的行为的动态验证组成，测试用例是从常用的无限执行领域中适当选取的。

相关补充

  • 动态：软件测试的结果不仅仅取决于输入的值，还与当时系统的状态有关。

  • 有限：由于一个程序的用例很多，很难完成穷举测试。所有一般认为测试集合无限。所以需要平衡有限的资源与无限的测试需求的平衡。

  • 选取：不同的测试技术，其本质区别在于如何选取测试集合。不同的选择标准可能会出现不同的效果。

  • 期望：确定观察到的结果是否可以被接受。观察到的结果与用户期望对比（确认测试）、与规格说明对比（验证测试）。

    3个重要观点

    1. 测试是为了证明程序有错，而不是证明程序无错误。
    2. 一个好的测试用例是在于它能发现至今未发现的错误。
    3. 一个成功的测试是发现了至今未发现的错误的测试。

软件工程

定义

  • IEEE

在软件工程术语汇编中的定义:软件工程是将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件的研究。

  • FritzBauer

在NATO会议上给出的软件工程定义:软件工程是建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。

  • 计算机科学技术百科全书

软件工程是应用计算机科学、数学及管理科学等原理，开发软件的工程。软件工程借鉴传统工程的原则、方法，以提高质量、降低成本。其中，计算机科学、数学用于构建模型与算法，工程科学用于制定规范、设计范型(Paradigm)、评估成本及确定权衡，管理科学用于计划、资源、质量、成本等管理。

目前比较认可的一种定义认为:

软件工程是研究和应用如何以系统性的、来寻 找软件中的缺陷。规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验质而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。

软件测试与软件工程各阶段联系

软件测试模型

  • V模型

V模型中的过程从左到右，描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期问各阶段的对应关系。

V模型的局限性在于没有明确地说明早期的测试，无法体现“尽早地和不断地进:行软件测试”的原则。

  • W模型

相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试，测试与开发是同步进行的，从而有利于尽早地发现问题。

W模型也有局限性。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动，无法支持迭代、自发性以及变更调整。

  • X模型

X模型也是对V模型的改进，X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序。

  • H模型

H模型中，软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发进行。 某个测试点准备就绪时，就可以从测试准备阶段进行到测试执
行阶段。软件测试可以尽早进行，并且可以根据被测物的不同而分层次进行。

​ 揭示原理:

软件测试是一个 独立的流程，贯穿于产品的整个生命周期，与其他流程并发地进行。H模型指出软件测试要尽早准备，尽早执行。

  • 前置模型

前置模型则体现了开发与测试的结合，要求对每个交付内容进行测试。前置模型是一个将测试和开发紧密结合的模型，此模型将开发和测试的生命周期整合在一起， 从项目开发生命周期的开始到结束，涉及每个关键行为。

要点

  1. 开发和测试相结合。

  2. 对每一个交付内容进行测试。

    ​ 包含的测试技术:

    1. 开发基于需求的测试用例。为以后测试程序做好准备,也为了验证需求是可测试的.

    2. 定义验收标准。在交付前用户用于验证,并且帮助揭示需求是否正确,需求是否被忽略.

  3. 在设计阶段进行计划和测试设计

  4. 测试和 开发结合在一起 在开发阶段以编码----测试----编码----测试的方式来体现.

  5. 让验收测试和技术测试保持相互独立。

  6. 反复交替的开发和测试。

  7. 发现内在的价值。

软件缺陷

定义

  • IEEE

    从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题;

    从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

体现

  1. 软件没有实现产品规格说明所要求的功能模块。
  2. 软件中出现了产品规格说明指明不应该出现的错误。
  3. 软件实现了产品规格说明没有提到的功能模块。
  4. 软件没有实现虽然产品规格说明没有明确提及但应该实现的目标。
  5. 软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户认为我。

产生原因

  1. 软件本身问题
  2. 团队工作问题
  3. 技术问题
  4. 项目管理问题

修复成本

软件质量

定义

概括:软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”。

具体:软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准，以及所有专业开发的软件都应具有的隐含特征的程度。

影响软件质量的主要因素

  1. 正确性、健壮性、效率、完整性、可用性、风险(产品运行)。
  2. 可理解性、可维修性、灵活性、可测试性(产品修改)。
  3. 可移植性、可再用性、互运行性(产品转移)。

标准

满足需求 准守软件开发准则 满足软件的隐含需求

测试用例

定义

测试用例(Test Case)是为某个特殊目标而编制的一组测试输入、 执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

IEEE定义

测试用例是一组测试输入、 执行条件和预期结果，目的是要满足一个特定的目标， 比如执行一条 特定的程序路径或检验是否符合一个特定 的需求。

测试用例=输入+输出+测试环境

重要性

  1. 指导测试的实施 可避免盲目测试，是测试的事实做到突出重点。
  2. 规划测试数据的准备
  3. 编写测试脚本的《设计规格说明书》
  4. 降低工作强度

评价标准

  1. 有效性 由于无法穷举测试，只有针对主要业务和重要的数据建立测试用例
  2. 经济性 进行的是动态测试，应该尽量满足软硬件、数据、操作人员、执行过程的可行性原则
  3. 可仿效性 可降低对测试人员的素质要求，减轻设计工作量、加快文档撰写速度
  4. 可修改性 软件更新后需要对测试用例修正，一便于简单修正后可以入库
  5. 独立性 独立于应用程序实现、独立于测试人员。测试用例不受程序具体变动影响，不受人员更换影响
  6. 可跟踪性 测试用例于用户需求想对应。便于评估测试对功能需求的覆盖率。

基本原则

  1. 测试用例的代表性

    测试用例应能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。

  2. 测试结果的可判定性

    测试结果的可判定性即测试执行结果的正确性是可判定的，每一个测试用例都应有相应明确的预期结果，而不应存在二义性，否则将难以判断系统是否运行正常。

  3. 测试结果的可再现性

    测试结果的可再现性即对同样的测试用例，系统的执行结果应当相同。测试结果可再现有利于在出现缺陷时能够确保缺陷的重现，为缺陷的快速修复打下基础。

测试环境

定义

测试环境就是软件运行的平台，即进行软件测试所必需的工作平台和前提条件，可用如下公式来表示:

测试环境=硬件+软件+网络+历史数据

重要性

  1. 加快测试进度

    稳定、可控的测试环境，可以使测试人员花费较少的时问就能完成测试用例的执行，也无需为测试用例、测试过程的维护花费额外的时间。

  2. 准确重现缺陷

    稳定而可控的测试环境可以保证每一个被提交的缺陷都可在任何时候准确地重现。

  3. .提高工作效率和软件质量

    经过良好规划和管理的测试环境，可以尽可能地减少环境变动对测试工作的不利影响，并可积极推动测试工作效率和质量的提高。

良好测试环境的要素

  1. 好的测试模型

    良好的测试模型有助于高效地发现缺陷，包含一系 列测试方法，它是在长期实践中积累下来的一些历史数据， 包括有关某类软件的缺陷分布规律、有关项目小组历次测试的过程数据等。

  2. 多样化的系统配置

    测试环境在很大程度上应该是用户的真实使用环境，或至少应搭建模拟的使用环境，使之尽量逼近软件的真实软件环境。

  3. 熟练使用工具的测试员

    在系统测试尤其是性能测试环节，通常需要有自动化测试工具的支持。只有能熟练使用各种工具的测试员，才能发挥自动化测试工具的巨大优势。

测试分类

按阶段

  1. 单元测试

    单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。

    一般应由程序员而非测试员来完成

    单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等。

  2. 集成测试

    集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。

    集成测试的策略主要有自顶向下和自底向，上两种。

  3. 系统测试

    系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求
    软件系统测试方法很多，主要有功能测试、性能测试、随机测试等。

  4. 验收测试

    验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。

    它的测试数据通常是系统测试的测试数据的子集。

  5. 回归测试

    回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。

    这里修改的正确性有两重含义: 一是所做的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等;二是不影响软件其他功能的正确性。

  6. Alpha测试

    Alpha测试是在系统开发接近完成时对应用系统的测试。测试后仍然会有少量的设计变更。

    这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。

  7. Beta测试

    当开发和测试基本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。

    这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。

按方法

  1. 白盒测试

    白盒测试也称结构测试或逻辑驱动测试，是指基于一个应用代码的内部逻辑知识，即基于覆盖全部代码、分支、路径、条件的测试。\

    白盒测试可以借助一些工具来完成，如JUnit Framework、Jtest 等。

  2. 黑盒测试

    黑盒测试是指不基于内部设计和代码的任何知识，而基于需求和功能性的测试。

    黑盒测试可以借助一些工具， 如WinRunner、QuickTestPro、Rational Robot等。

  3. 灰盒测试

    灰盒测试是介于白盒测试和黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性;同时也关注内部表现，但这种关注不像白盒测试那样详细、完
    整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。

posted @ 2021-01-08 23:24  小菩萨啦啦啦  阅读(91)  评论(0)    收藏  举报