A2软件测试基础理论

软件测试分类

按照阶段划分

  • 单元测试
  • 对软件中最小可测试单元(类,函数或者模块等)进行检查和验证,一般有开发进行
  • 集成测试
  • 在单元测试的基础上,将所有的软件单元按照要求组装成模块、子系统或者系统时,有没有问题的过程。重点在于单元之间的接口有没有问题 集成测试须在单元测试之后。
  • 系统测试
  • 将整个软件看成一个整体进行测试,主要是根据需求进行测试,是否存在系统级别的问题
  • 验收测试
  • 检查软件是否符合用户需求,主要包括两个环节
  • α测试:用户(公司内部人员:测试,开发,产品经理等)在内部(开发,测试,预发布)环境下进行的测试。可以称为内测
  • β测试:用户(种子用户,灰度用户,核心用户等)在正式环境下进行体验测试。可以称为公测
  • 按照状态划分

  • 静态测试
  • 不运行被测程序本身,仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性
  • 动态测试
  • 通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率、正确性和健壮性等性能指标。
  • 按照测试执行划分

  • 冒烟测试
  • 测试软件产品主要功能是否正常,是否具备可测试的条件。一般在开发提测之前进行冒烟测试。
  • 探索测试
  • 经验充足的测试人员使用最多,效率最高的测试。
  • 测试方法:不看用例,也不用刻意的与需求核对的方式进行测试。直接根据自己的经验,快速验证产品功能。对于测试人员能力要求较高。
  • 随机测试
  • 完全随机测试,任意发挥,玩玩会发现出乎意外的问题
  • 回归测试
  • 测试完成之后,在进行快速地重复一轮测试 主要的策略有:全量回归,新增功能回归,发现的BUG回归
  • 按照技术划分

  • 功能测试
  • 只需考虑需要测试的各个功能,不需要考虑整个软件的内部结构及代码.一般从软件产品的界面、架构出发, 按照需求输入数据,然后对结果进行测试。
  • 性能测试
  • 通过自动化技术,对软件的各项性能指标进行测试评估的过程。一般须在功能稳定之后才能进行性能测试
  • 安全测试
  • 站在防御者的角度,尽可能地发现软件安全隐患的过程
  • 按照自动化划分

  • 手工测试
  • 不通过工具,只通过双手“点点点”的方式进行的测试
  • 自动化测试
  • 通过程序,编写自动化测试代码,自动对软件进行的测试。
  • 自动化测试比例:10%UI自动化,20%接口自动化,70%单元测试(理论)
  • 优点 可以解决难以测试的场景 可以快速回归测试
  • 缺点 不能完全替代手工 脚本维护困难 技术要求高,推广难度高
  • 按照是否清楚代码内部运行逻辑划分

  • 白盒
  • 完全清楚代码逻辑,针对代码进行的测试。一般由开发完成 测试方法包括:路径覆盖,语句覆盖,条件覆盖,判断覆盖(分支)
  • 黑盒
  • 完全不清楚代码逻辑,只按照需求设计输入数据,然后对输出进行验证的过程
  • 灰盒
  • 介于白盒和黑盒之间的测试
  • 软件测试的策略

    测试策略的定义

    在一定的软件测试标准、测试规范的指导下,依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。

    测试策略的目的

    指导工程师进行软件测试的总体方向和目标;以最少的软、硬及人力资源投入而获得最佳的测试效果

    软件测试的基本原则

  • 常见的基本原则
  • 基于用户角度发现
  • 越早介入测试越好
  • 不能穷举测试
  • 二八原则(出现BUG的模块,出现更多BUG的可能性更高)
  • 不仅要设计正向用例,还需要设计反向用例
  • 软件开发模型

    边做边改型

    适合小作坊

  • 流程图
  • 优缺点
  • 优点:非常贴合用户的需求
  • 缺点:没有需求,没有管理,用户就是测试
  • 瀑布模型

    瀑布模型是文档需求开发过程的模型,整个流程中,下一个流程严格依赖上一步。是过去非常流行的开发模型

  • 流程图
  • 优缺点
  • 优点:结构和层次很清晰,更有利于进行项目管理
  • 缺点:测试最后介入,一旦发现问题,修复成本比较高;进度没有达到100%之前,相当于0%;执行过程当中,会产生大量的文档,导致有大量时间需要维护文档
  • 快速原型

    快速原型的特点是,快速建立一个原型,用来让客户进行评估,从而快速地解决出用户需求不明的问题

  • 流程图
  • 优缺点
  • 优点:能解决用户需求问题
  • 缺点:测试最后介入
  • 螺旋模型

    螺旋模型是1988年,巴利&波姆 提出来的概念,它将瀑布模型和快速原型结合起来,增加了其他模型没有的风险分 析,特别适合大型复杂的系统

  • 流程图
  • 实施步骤
  • 制定目标和计划
  • 风险分析
  • 实施
  • 客户评估,准备下一个计划
  • 优缺点
  • 优点:解决了瀑布模型需求不明确的问题;解决了快速原型测试介入太晚的问题;将开发过程拆分为更小的单元 用户可以每个阶段参与产品的体验,带来更好的质量提升和交互体验。
  • 缺点:需要有丰富的风险评估经验的人员;迭代次数太多,导致延迟提交时间
  • 敏捷模型

    其因为在项目的度量方式是用产品数量来度量,所以管理人员偏向于“先有产品,再优化迭代”的开发思想以及具备快速开发、快速迭代的特点,所以目前市场上敏捷开发特别火

    SCRUM

  • 流程图
  • 优缺点
  • 优点:功能少,迭代快,易于开发和测试;以人为本 能够激发工作热情
  • 缺点:如果在开发过程当中,有人员更迭,那么会导致工作交接困难
  • XP极限编程

  • XP是一种轻量(敏捷)、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式
  • 流程图
  • 最里层:编程方法
  • 用最简单的方法设计软件
  • 小组编程:互相评审
  • 测试驱动开发:先写测试代码,再写能测试通过的代码
  • 重构:增强程序可复用性
  • 中间层:小组实践
  • 代码集体所有:每个人都必须对代码负责,都能修改代码
  • 编码标准:遵循统一的标准
  • 稳定高速的步伐:保持稳定高速的工作节奏
  • 持续集成:每天都把代码集成为产品,快速发现是否存在问题
  • 隐喻:用形象的比喻描述产品的特点,(这么做的奥秘是因为用具体的需求描述时,可能会忽视一些抽象细节)
  • 最外层:交付和管理
  • 小规模发布(Small Releases):1-3周发布一个版本,这个产品能够直接使用和验证
  • 计划游戏(Planning Game):做好计划
  • 完整团队(Whole Team):围绕用户进行工作
  • 用户测试:用于参与测试
  • DevOps

    可以把DevOps看作开发(软件工程)、技术运营和质量保障(QA)三者的交集

  • DevOps在项目流程中的位置
  • DevOps实施过程
  • 持续开发 通过敏捷模型来推动持续开发
  • 持续测试 通过持续集成的技术,通过自动化的技术进行自动持续的测试
  • 持续集成 每天周期性的提交代码到平台,并自动构建,打包,单元测试,还反馈测试结果
  • 持续交付 自动搭建测试环境,自动运行自动化测试代码,自动发布
  • 持续监控 部署持续监控服务器相关资源的工具,来监控软件运行是否稳定。
  • 优缺点
  • 优点 减少变更范围;加强协调;自动化
  • 缺点 成本高,投入大
  • 软件测试模型

    V模型

  • 流程图
  • 优缺点
  • 优点:测试过程非常清楚
  • 缺点:测试最后才介入
  • W模型

  • 流程图
  • 优缺点
  • 优点:能够让测试更早的介入
  • 缺点:因为实用W模型时,会产生更多的文档,所以会带来维护困难的问题
  • H模型

  • 流程图
  • 优缺点
  • 优点 软件测试完全独立 软件测试活动可以尽可能早的准备,灵活性很强
  • 缺点 测试就绪点很难分析 对项目组人员技术要求较高
  • 软件质量模型

    ISO9126

    ISO9126 软件质量模型是评价软件质量的国际标准。该标准由6个特性和27个子特性构成

    质量特性

    功能性

    可靠性

    易用性

    效率

    维护性

    可移植性

    质量子特性

    适合性

    成熟性

    易理解性

    时间特性

    易分析性

    适应性

    准确性

    容错性

    易学性

    资源利用性

    易改变性

    易安装性

    互操作性

    已恢复性

    易操作性

    稳定性

    共存性

    保密安全性

    吸引性

    易测试性

    易替换性

    功能性的依从性

    可靠性的依从性

    易用性的依从性

    效率依从性

    维护性的依从性

    可移植性的依从性

  • 功能性
  • 适合性 提供了相应的功能
  • 准确性 正确(用户需要的)
  • 互操作性 产品与产品之间交互数据的能力
  • 保密安全性 允许经过授权的用户和系统能够正常的访问相应的数据和信息,禁止未授权的用户访问…….
  • 功能性的依从性 国际/国家/行业/企业 标准规范一致性
  • 可靠性
  • 产品在规定的条件下,在规定的时间内完成规定功能的能力
  • 成熟性 防止内部错误导致软件失效的能力
  • 容错性 软件出现故障,自我处理能力
  • 易恢复性 失效情况下的恢复能力
  • 可靠性的依从性
  • 易用性
  • 在指定使用条件下,产品被理解、 学习、使用和吸引用户的能力
  • 易理解性
  • 易学性
  • 易操作性
  • 吸引性
  • 易用性的依从性
  • 效率性
  • 在规定台条件下,相对于所用资源的数量,软件产品可提供适当性能的能力
  • 时间特性 平均事务响应时间,吞吐率,TPS(每秒事务数)
  • 资源利用性 CPU 内存 磁盘 IO 络带宽 队列 共享内存
  • 效率依从性
  • 软件维护性
  • “四规”, 在规定条件下,规定的时间内,使用规定的工具或方法修复规定功能的能力
  • 易分析性 分析定位问题的难易程度
  • 易改变性 软件产品使指定的修改可以被实现的能力
  • 稳定性 防止意外修改导致程序失效
  • 易测试性 使已修改软件能被确认的能力 维护性的依从性
  • 可移植性
  • 从一种环境迁移到另一种环境的能力
  • 适应性 适应不同平台
  • 易安装性 被安装的能力
  • 共存性
  • 易替换性
  • 可移植性的依从性
  • GBT25000.10-2016

  • 使用质量要求
  • 产品质量特性
  • 软件测试沟通技巧

  • 降低沟通成本
  • 通过正确的方式进行沟通
  • 让表述更容易理解
  • 注意沟通方式
  • 用肯定句来沟通
  • 建立“共识”,避免对立
  • 树立共同的任务目标:为了让产品顺利上线、为了不用加通宵班修复BUG
  • 跨部门沟通
  • 测试与产品沟通
  • 需求评审
  • 在分析需求阶段
  • 在测试用例编写阶段
  • 在测试过程中
  • 测试与开发沟通
  • 分析需求
  • 测试用例编写
  • 测试过程
  • 线上监控发现bug
  • 以上内容来做拉勾教育自动化测试训练营,笔记整理。

    声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

    上一篇 2022年8月13日
    下一篇 2022年8月13日

    相关推荐