软件测试基础知识

基本概念

• 软件测试

  在规定条件下对程序进行操作，以发现错误，对软件质量进行评估，包括对软件形成过程的文档、数据以及程序进行测试

• 软件测试的目的

  • 发现程序中存在的错误 发现程序中存在的错误，而不是证明程序无错误。一个好的测试用例在于它能发现至今尚未发现的错误。一个成功的测试则是发现了至今未发现的错误。开始我们认为做测试无非是为了证明我们编的程序是无错误的，那是大错特错了。因为bug会因时间不同，条件不同而出现。永远无法证明我们的程序是绝对正确的。

  • 为反馈信息做准备 为开发者或软件项目经理提供反馈信息，以及为风险评估所准备的信息

• 软件测试的原则

  • 所有的测试都应追溯到用户需求。因为软件的目的是使用户完成预定的任务，满足其需求，而软件测试揭示软件的缺陷和错误，一旦修正这些错误就能更好地满足用户需求。

  • 应尽早地和不断地进行软件测试。由于软件的复杂性和抽象性，在软件生命周期各阶段都可能产生错误，所以不应把软件测试仅仅看作是软件开发的一个独立阶段，而应当把它贯穿到软件开发的各个阶段去。在需求分析和设计阶段就应开始进行测试工作，编写相应的测试计划及测试设计文档，同时坚持在开发各阶段进行技术评审和验证，这样才能尽早发现和预防错误，杜绝某些缺陷和错误，提高软件质量，测试工作进行得越早，越有利于提高软件的质量，这是预防性测试的基本原则。

  • 在有限的时间和资源下进行完全测试，找出软件所有的错误和缺陷是不可能的，软件测试不能无限进行下去，应适时终止。因为，测试输入量大、输出结果多、路径组合太多，用有限的资源来达到完全测试是不现实的。

  • 测试只能证明软件存在错误而不能证明软件没有错误。测试是无法显示潜在的错误和缺陷，继续进一步错误可能还会找到其它错误和缺陷。

  • 充分关注测试中的集群现象。在测试的程序段中，若发现的错误数目多，则残存在其中的错误也越多，因此应当花较多的时间和代价测试那些具有更多错误数目的程序模块。

  • 程序员应避免检查自己的程序。考虑到人们的心理因素，自己揭露自己程序中的错误是件不愉快的事，自己不愿意否认自己的工作;另一方面，由于思维定势，自己难以发现自己的错误。因此，测试一般由独立的测试部门或第三方机构进行。

  • 尽量避免测试的随意性。软件测试是有组织、有计划、有步骤的活动，要严格按照测试计划进行，要避免测试的随意性。

• 软件测试对象

  程序开发过程中的各个文档、源程序、目标程序及数据

• 软件测试的模型

  • 测试是开发之后的一个阶段。

  • 测试的对象就是程序本身。

  • 实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。

  • 整个软件产品的过程质量保证完全依赖于开发人员的能力和对工作的责任心，而且上一步的结果必须是充分和正确的，如果任何一个环节出了问题，则必将严重的影响整个工程的质量和预期进度

  • V模型

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

  • 左边依次下降的是开发过程各阶段，与此相对应的是右边依次上升的部分，即各测试过程的各个阶段。

  • V模型问题：

  • W模型 相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。 W模型也有局限性。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动，无法支持迭代、自发性以及变更调整。

软件测试的流程

• 需求评审

  阅读需求、理解需求及了解需求

• 测试计划

  根据需求估算测试所需资源（人力、设备等）、所需时间、功能点划分、如何合理分配安排资源等。

• 用例设计

  根据测试计划、任务分配、功能点划分，设计合理的测试用例。

• 执行测试

  根据测试用例的详细步骤，执行测试用例。

常见的用例设计方法

• 黑盒测试用例设计方法

  边界值分析和等价类划分的一个弱点是未对输入条件的组合进行分析。

  • 将规格说明书分解为可执行的片段。

  • 确定规格说明中的因果关系。

  • 分析规格说明的语义内容，并将其转换为连接因果关系的布尔图。

  • 给图加上注解符号，说明由于语法或环境的限制而不能联系起来的“因”和“果”。

  • 将因果图转换为判定表。

  • 将判定表转换为测试用例。

  • 因果图

  • 定义 因果图法是一种适合于描述对于多种输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件涉及的各种组合情况。因果图法着重分析输入条件的各种组合，每种组合条件就是“因”，它必然有一个输出的结果，这就是“果”。

  • 利用因果图生成测试用例的步骤。

  • 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。

  • 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

  • 在输入条件规定的取值范围或值的个数的情况下，可以确定一个有效 等价类和两个无效等价类。

  • 在规定了输入数据的一组值中（假定有n个值），并且程序要对每个输 入值分别处理的情况下，可以确定n个有效等价类和一个无效等价类。

  • 在规定输入数据必须遵守的规则的情况下，可以确定一个有效等价类 和若干个无效等价类。

  • 在输入条件规定了输入值的集合或规定了“必须如何”的条件下，可以确定一个有效等价类和一个无效等价类。

  • 在确定已划分的等价类中各元素在程序处理中的方式不同的情况下，则应将该等价类进一步地划分为更小的等价类。

  • 按区间划分。

  • 按数值划分。

  • 按数值集合划分。

  • 按限制条件或规划划分。

  • 按处理方式划分。

  • 等价划分

  • 定义 等价类划分法是一种典型的、重要的黑盒测试方法，它将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。利用这一方法设计测试用例可以不考虑程序的内部结构，以需求规格说明书为依据，选择适当的典型子集，认真分析和推敲说明书的各项需求，特别是功能需求，尽可能多地发现错误。等价类划分法是一种系统性的确定要输入的测试条件的方法。

  • 有效等价类 有效等价类指对于程序规格说明来说，是合理的、有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明预先规定的功能和性能。有效等价类可以是一个，也可以是多个，根据系统的输入域划分若干部分，然后从每个部分中选取少数有代表性数据当做数据测试的测试用例，等价类是输入域的集合。

  • 无效等价类 无效等价类和有效等价类相反，无效等价类是指对于软件规格说明而言，没有意义的、不合理的输入数据集合。利用无效等价类，可以找出程序异常说明情况，检查程序的功能和性能的实现是否有不符合规格说明要求的地方。

  • 等价类划分的方法

  • 等价类划分的原则

  • 边界值分析

  • 定义 边界值是指输入和输出等价类中哪些恰好处于边界、或超过边界、或在边界以下的值、

  • 与等价类划分方法的不同

• 白盒测试用例设计方法

  • 语句覆盖（SC）

  • 判定覆盖（DC）

  • 条件覆盖（CC）

  • 判定/条件覆盖（DCC）

  • 条件组合覆盖（CMC）

  • 路径覆盖

常见的测试方法和类型

• 按代码的可见程度划分

  • 黑盒测试 黑盒测试又称为数据驱动测试，把测试对象当做看不见的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性，它是站在使用软件或程序的角度，从输入数据与输出数据的对应关系出发进行的测试。

  • 白盒测试 白盒测试又称为结构测试或逻辑驱动测试，是一种按照程序内部逻辑结构和编码结构，设计测试数据并完成测试的一种测试方法。

  • 灰盒测试 灰盒测试是一种综合测试法，它将“黑盒”测试与“白盒”测试结合在一起，是基于程序运行时的外部表现又结合内部逻辑结构来设计用例，执行程序并采集路径执行信息和外部用户接口结果的测试技术。

• 按项目流程阶段划分

  • 单元测试 单元测试又称模块测试，是针对软件设计的最小单位----程序模块或功能模块，进行正确性检验的测试工作。其目的在于检验程序各模块是否存在各种差错，是否能正确地实现了其功能，满足其性能和接口要求。

  • 集成测试 集成测试又叫组装测试或联合，是单元测试的多级扩展，是在单元测试的基础上进行的一种有序测试。目的是检查软件单位之间的接口是否正确。

  • 系统测试 系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等是否满足其规约所指定的要求。

  • 验收测试 验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，向软件购买者展示该软件系统满足其用户的需求。

• 按执行过程是否需要人工干预划分

  • 手工测试 手工测试就是由人去一个一个的去执行测试用例，通过键盘鼠标等输入一些参数，查看返回结果是否符合预期结果。

  • 自动化测试 自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。 自动化测试：又可分为功能自动化测试与性能自动化测试。 我们一般所说的自动化测试就是指功能自动化测试，通过相关的测试技术，通过编码的方式用一段程序来测试一个软件的功能，这样就可以重复执行程序来进行重复的测试。如果一个软件一小部分发生改变，我们只要修改一部分代码，就可以重复的对整个软件进行功能测试。这样就大大的提高了测试效率。 性能自动化测试，当然，除了早期阶段，现在的性能测试工作都是通过性能测试工具辅助完成的。能过工具可以模拟成千上万的用户向系统发送请求，用来验证系统的处理能力。

• 其他测试方法

  • 冒烟测试 冒烟测试是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。

  • 回归测试 回归测试是指修改了旧代码后，重新时行测试以确认修改后没有引入新的错误或导致其他代码产生错误。

  • 随机测试 是指测试中的所有输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。

  • 压力测试、负载测试及性能测试 压力测试：验证软件在超过负载设计的情况下仍能返回正确的结果，没有崩溃负载测试：测试软件在负载情况下能否正常工作 性能测试：测试软件的性能，是否提供满意的服务质量

最后:【可能给予你助力的教程】

这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。