软件测试精要-优快云博客

软件测试的定义（software testing）
- 官方释义
  - 用来促进鉴定软件的正确性，完整性，安全性和质量的工程
  - 是一种实际输出与预期输出之间的审核或者比较的过程
  - 使用人工和自动化手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定需求或是浓情预期结果和实际结果之间的差别
- 经典定义
  - 在规定的条件下对程序进行操作，以发现错误；也是对软件质量进行评估的一个过程
软件质量的定义
- 软件质量：软件满足规定或潜在用户需求的能力。具体来说，软件质量是符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的和隐含特征相一致的程度。
软件测试和软件质量的区别
- 质量保证（QA）：主要工作是通过预防，检查与改进来保证软件质量。它所关注的是软件质量的检查与测量。着眼软件开发活动中的过程、步骤产及物，而不是对软件进行剖析而找出问题。
- 软件测试：测试关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。测试人员要“执行”软件，对过程中的产物---开发文档和源代码进行走查，运行，以找出问题，报告质量。测试人员必须假设软件存在问题，所以所做的操作都是为了找出更多的问题，而不仅仅验证每一件事是正确的。
软件测试的内容
- 根据测试定义，测试贯穿与整个软件生命周期中。在开发的不同阶段，需要测试不同的内容。包括文档，源代码，数据等。
软件测试的分类
- 按开发阶段来分
  - 单元测试
    - 最小模块
    - 是对软件中的基本组成单位进行测试，如一个模块，一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性相对于该单元的规约（详细设计）而言的。因此，单元测试以被测试单位的规约为基准。
    - 单元测试方法
      - 控制流测试
      - 数据流测试
      - 排错测试
      - 分域测试
      - 等等……
    - 单元原则
      - 尽可能保证各个测试用例是相互独立
      - 一般由被测代码的开发人员来实施，用以检验所开发的代码功能是否符合自己的设计要求
    - 单元测试的益处
      - 能尽早发现缺陷
      - 有利于重构
      - 简化集成
      - 文档（减少文档的存在）
      - 用于设计
    - 限制
      - 不可能覆盖所有的执行路径，并且捕捉到所有错误
      - 每一行代码，一般需要3到5行测试代码才能完成单元测试。所以存在投入和产出在一个平衡点
  - 集成测试
    - 是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。集成测试的策略主要是自顶向下和自底向上两种
    - 集成测试的主要实施方案
      - big bang（一次性集成）
      - 自顶向下
      - 自底向上
      - 核心系统集成
      - 高频集成
  - 系统测试
    - 是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确行和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多。主要有功能测试，性能测试，随机测试等
  - 验收测试
    - 由客户或最终用户执行，指在向软件的购买者展示该软件系统满足用户的需求。它的测试数据通常是系统测试的测试数据子集。所不同的是，验收测试常常有软件系统购买者代表在现场，甚至在软件安装使用的现场。这是软件在投入使用之前的最后测试。
- 按测试的实施单位来分
  - 开发方测试
  - 用户测试
  - 第三方测试
- 按测试技术来分（测试手段）
  - 白盒测试
    - 是对软件的过程性细节做细致的检查。是把测试对象看成一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称结构测试或者逻辑驱动测试。
    - 白盒测试覆盖
      - 语句覆盖
      - 判定覆盖
      - 条件覆盖
      - 判定/条件覆盖
      - 条件组合覆盖
      - 路径覆盖
      - 等等……
    - 优点
      - 迫使测试人员去仔细思考软件，理解原理
      - 可以检测到代码中的每一条分支和路径
      - 揭示隐藏在代码中的错误
      - 对代码的测试比较彻底
    - 缺点
      - 昂贵
      - 无法检测代码中遗漏的路径和数据敏感行性的错误
      - 不能直接验证需求规格的正确性
    - 测试方法
      - 代码检测法
      - 静态结构分析法
      - 静态质量度量法
      - 逻辑覆盖
      - 基本路径测试
  - 黑盒测试
    - 把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或者数据驱动测试
    - 黑盒测试的设计方法
      - 等价类划分
      - 边界值分析
      - 因果图分析
      - 错误推测论
      - 功能图分析
      - 等等……
    - 优点
      - 容易实施，不需要关注内部的实现
      - 更贴近用户的视角
    - 缺点
      - 测试覆盖率底，一般覆盖不到40%
      - 针对黑盒的自动化测试，复用率较低，维护成本高
    - 关注点
      - 是否有不正确或遗漏的功能？
      - 在接口上，输入是否能够正确接收？是否能够输出正确的结果？
      - 是否有数据结构错误或外部信息访问错误？
      - 性能上是否能够满足要求？
  - 灰盒测试
    - 介于黑盒和白盒之间的，关注输出对于输入的正确性，同时关注内部表现
  - 功能测试
    - 对产品的各个功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能
  - 回归测试
    - 是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或者导致其他代码产生错误，回归测试的困难在于不好确定哪些内容应当被重新测试。
  - Alpha测试
    - 由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试，开发者负责记录发现在错误和使用中遇到的问题。总之，Alpha测试是在受控制的环境中进行的。
  - Beta测试
    - 由软件的最终用户们在一个或者多个客房场所进行，与Alpha测试不同，开发者通常在Beta测试的现场，因Beta测试是软件在不能控制的环境中的“真实”应用。用户Bata测试过程中遇到的一切问题，并且定期把这些问题报告给开发者，接收到Beta测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品
  - 冒烟测试
    - 可以根据其名称理解为该种测试耗时短，仅用一袋烟的功夫就足够了，其实是对软件的基本功能进行测试，测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本的功能正常，保证软件系统能跑起来，可以进行后续的正式测试工作
  - 随机测试
    - 主要是根据测试者的经验对软件进行功能和性能进行抽查。它是根据测试说明书执行样例的重要补充手段，是保持测试覆盖完整性的有效方式和过程
  - 动态测试
    - 是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种测试方法由三部分组成：构造测试实例、执行程序、分析程序的输出结果。所谓软件的动态测试，就是通过运行软件来检验软件的动态行为和运行结果的正确性。目前，动态测试也是公司的测试工作的主要方式
  - 静态测试
    - 是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书，软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数，不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的差错，并为测试用例选取提供指导
    - 方式
      - 互审
      - 走查
      - 会议
  - UI测试
    - 指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等，用户界面测试用于核实用户与软件之间的交互。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI测试还可确保UI中的对象按照预期的方式运行，并且符合公司或者行业的标准。包括用户友好性，人性化，易操作性测试。UI测试比较主观，与测试人员的喜好有关
  - 自动化测试
    - 利用软件测试工具自动实现全部或者部分测试，它是软件测试的一个重要的组成部分，能完成许多手工测试无法实现或难以实现的测试，正确、合理的实施自动测试，能够快速、全面的对软件进行测试，从而提高软件质量，节省经费，缩短软件发布周期
  - 性能测试
    - 是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件对系统的各项性能指标进行测试。负载测试和压力测试都是属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试
软件测试的目的
- 发现软件中的各种缺陷
- 测试只能证明软件存在缺陷，不能证明软件不存在缺陷
- 测试可是使软件中的缺陷降低到一定程度，而不是彻底消灭
- 以最少的用例，时间和人力找出软件中潜在的各种错误与缺陷，通过修正各种错误和缺陷来提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患以及带来的商业风险
什么是软件缺陷
- 软件未达到产品说明书标明的功能
- 软件出现了产品说明书不会出现的错误
- 软件功能超出产品说明书指明的范围
- 软件未达到产品说明书虽未指出但应该达到的目标
- 软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好
测试用例（Test Case）的了解
- 是为某个特殊目标而编制的一组测试输入、执行条件以及预期效果，以便测试某一个程序路径或者核实是否满足某个特定需求
- 目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并且形成文档
- 是将软件测试的行为为活动做一个科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式，同时测试用例也是将测试具体量化的方法之一
测试用例八大设计方法
- 等价类划分方法
  - 指某个输入域的子集合。在该集合中，各个输入数据对于揭露程序总的错误是等效的并合理的假定；测试某等价类的代表值就等于这一类其他值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中获取一个数据作为输入条件，就可以用少量代表性得测试数据，取得较好的测试结果。等价类划分为两种不同的情况：有效等价类和无效等价类。
- 边界值分析方法
  - 是对等价类划分方法的补充，测试工作经验告诉我，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查处更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
- 错误推测方法
  - 基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。
  - 错误推测方法的基本思想：举例出程序中所有可能有的错误和容易发生错误的特殊情况，根绝他们选择测试用例。例如：在单元测试时曾列出的许多的在模块中常见的错误。以前产品测试中曾经发现的错误等，这些就是经验总结。还有，输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况，可选择这些情况下的例子作为测试用例
- 因果图方法
  - 前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，互相组合等。考虑输入条件之间的互相组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情，即使把所有的输入条件划分未等价类，他们之间的组合情况也相当多。因此必须考虑采用一种合适与描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图（逻辑模型）。因果图方法最终产生的就是判定表。它适合与检查程序输入条件的各种组合情况。
- 判定表驱动分析方法
  - 是分析和表达多逻辑条件下执行不同操作的情况的工具。
- 正交表设计分析方法
  - 有时候，可能因为大量的参数的组合而引起测试用例数量的激增，同时。这些测试用例并没有明显的优先级的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性
- 功能图分析方法
- 场景模拟分析方法

测试基础(一)