软件缺陷定义

​ 软件缺陷就是通常说的Bug，它是指在软件中（包括文档和程序）存在的影响软件正常运行的问题。

软件缺陷产生的原因

  1. 需求描述不明确和频繁变更 软件需求不清晰或者开发人员对需求理解偏差，导致软件设计时偏离用户的需求目标，造成软件功 能或特征上的缺陷。此外，开发过程中客户频繁更新需求也会影响软件最终的质量。
  2. 软件结构复杂
  3. 编码问题
  4. 项目期限短
  5. 使用新技术
  6. 软件开发缺乏规范性文件指导
  7. 缺乏软件质量控制管理

软件缺陷分类

V模型

W模型

软件测试流程

阶段名 工作内容 产出物
测试准备阶段 项目立项、需求分析、需求评审 需求文档/产品PRD
测试计划阶段 编写测试计划、测试计划评审 测试计划
测试设计阶段 提取测试点、编写测试用例、测试用例评审 测试用例
测试执行阶段 冒烟测试、执行测试用例、提交bug、待bug修复后进行回归测试 缺陷报告
测试完成阶段 验收测试、编写测试报告、项目上线、线上环境灰度验证 测试报告

软件测试原则

  • 原则一:测试显示软件存在缺陷

    测试只能证明软件中存在缺陷，但并不能证明软件中不存在缺陷。软件测试是为了降低存在缺陷的可能性，即便是没有找到缺陷，也不能证明软件是完美的。

  • 原则二:穷尽测试是不可能的

    现在软件的规模越来越大，复杂度越来越高，想做到完全性的测试是不可能的。在测试阶段，测试人员可以根据风险和优先级来进行集中和高强度的测试，从而保证软件的质量。

  • 原则三:测试尽早介入

    为什么测试要尽早介入呢，简单的说就是保证软件质量，降低风险和成本。测试人员一般在需求阶段就开始介入，使缺陷在需求或设计阶段就被发现，缺陷发现越早，修复的成本就越小。

  • 原则四:缺陷集群性(2/8原则)

    缺陷集群性表明小部分模块包含大部分的缺陷。软件测试中存在Pareto原则:80%的缺陷发现在 20%的模块中。一个功能模块发现的缺陷越高，那存在的未被发现的缺陷也越高，故发现的缺陷与未发现的缺陷成正比。

  • 原则五:杀虫剂悖论

    反复使用相同的杀虫剂会导致害虫对杀虫剂产生免疫而无法杀死害虫。软件测试也一样。如果一直使用相同的测试方法或手段，可能无法发现新的bug。为了解决这个问题，测试用例应当定期修订和评审，增加新的或不同的测试用例帮助发现更多的缺陷。

    测试人员不能一直依赖于现有的测试技术，而要不断的提升测试方法以提高测试效率。

  • 原则六:测试活动依赖于测试内容

    根据业务的不同，软件测试内部也分为不同的行业，比如游戏行业、电商行业、金融行业。不同的行业，测试活动的开展都有所不同，比如测试技术、测试工具的选择，测试流程都不尽相同，所以软件测试的活动开展依赖于所测试的内容。

  • 原则七:没有错误是好是谬论

    有可能99%没有bug的软件也是不能使用的。如果对错误的需求进行了彻底的测试，这种情况就发 生了。软件测试不仅是找出缺陷，同时也需要确认软件是否满足需求。如果开发出来的产品不满足 用户的需求，即便找到和修复了缺陷也作用不大。

  • 原则八:程序员不能自测之后就上线

  • 原则九:严格执行测试计划，排除测试的随意性

  • 原则十:应当对每一个测试结果做全面的检查

  • 原则十一:妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便

  • 原则十二:设计测试用例时，应当包括合理的输入数据和不合理的输入数据

  • 原则十三:测试用例应由测试数据和与之对应的预期输出结果这两部分组成

软件测试分类

按照测试原理分类

​黑盒测试、白盒测试、灰盒测试

  • 黑盒测试(Black Box -Test):把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果。有人把黑盒测试比作中医，通过“望闻问切”来判断是否有问题。

    “望”:观察软件的行为是否正常。

    “闻”:检查输出的结果是否正确。

    “问”:输入各种信息，结合“望”，“闻”来观察软件的响应。

    “切”:像中医一样给软件“把把脉”，敲击一下软件的某些“关节” 。

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

  • 灰盒测试:一种基于程序运行时的外部表现同时又结合程序内部结构来设计测试数据的测试方法。

按照测试阶段分类

​单元测试、集成测试、系统测试、验收测试

  • 单元测试:对一个模块、一个函数或者一个类来进行正确性检验的测试方法
  • 集成测试:单元测试后，将单独的模块按照设计要求组装成为子系统或系统，作为整体进行测试的 测试方法
  • 系统测试:集成测试后，将硬件、软件看作一个整体,对系统的功能及性能的总体测试
  • 验收测试:系统测试后以用户测试为主，或有测试人员共同参与检验软件质量的测试方法

按照内容分类

功能测试、性能测试、兼容性测试

功能测试:

​ 界面测试、冒烟测试、回归测试、业务逻辑测试、易用性测试

  • 功能测试:根据产品操作描述和需求文档，测试一个产品的特性和可操作行为是否满足用户需求的测试方法
  • 界面测试:测试用户界面的功能模块的布局是否符合客户使用习惯，界面操作便捷性、导航简单易懂性的测试
  • 冒烟测试:验证系统的核心功能是否能够正常运行的测试方法
  • 回归测试:指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误的测试方法
  • 业务逻辑测试:在基本的功能点都已合格的基础上，准备多种测试数据，来驱动各种约束条件下业务流程，确定最终输出的结果是否符合预期的测试
  • 易用性测试:指用户使用软件时是否感觉方便的测试

性能测试:

  • 性能测试:通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行校验的测试方法
  • 压力测试:通过逐步增加系统负载，测试系统性能的变化，并确定在什么条件下系统性能处于失效状态
  • 负载测试:通过逐步增加系统负载，测试系统性能的变化，在满足性能指标的情况下，系统所能承受的最大负载量的测试
  • 并发测试:是一个负载测试和压力测试的过程，即逐渐增加并发用户数负载直到系统的瓶颈，通过分析资源监控指标等来确定系统并发性能

兼容性测试:

  • 浏览器兼容、操作系统兼容、系统版本兼容、分辨率兼容、硬件架构兼容、机型兼容

按照其他分类:

​冒烟测试、随机测试、安全性测试、探索性测试、回归测试、Alpha测试、Beta测试

  • 随机测试:随机测试主要是根据测试者的经验无需测试用例对软件进行功能和性能抽查的测试方法
  • 安全性测试:通过不同的测试方法，检验程序、网络、数据库安全性的测试方法
  • 探索性测试:碰到问题时能随机应变，强调测试人员的主观能动性明确整体的测试计划的测试方法
  • Alpha测试:俗称内测，α测试。内部环境下的测试;开发人员或测试人员在现场
  • Beta测试:俗称外测、公测，β测试。生产环境下的测试;开发人员和测试人员都不在现场