关于python:运维测试测试理论工具总结笔记第1篇测试理论的主要内容已分享附代码

106次阅读

共计 3491 个字符,预计需要花费 9 分钟才能阅读完成。

本系列文章 md 笔记(已分享)次要探讨测试实践 + 测试工具相干常识。Python 测试实践的次要内容,把握软件测试的根本流程,晓得软件测试的 V 和 W 模型的优缺点,把握测试用例设计的因素,把握等价类划分法、边界值法、因果图法、断定表法。理解缺点的定义,晓得缺点的详细信息。理解禅道、Jire 的装置配置,把握禅道的应用, 包含角色的常见、缺点状态的批改。

全套笔记和代码移步 gitee 仓库:gitee 仓库获取残缺文档和代码

感兴趣的小伙伴能够自取哦,欢送大家点赞转发~


共 5 章,16 子模块

Python 测试实践的次要内容
  • 软件测试的根本实践

    • 把握测试的定义
    • 把握测试的分类
    • 把握测试的根本流程
    • 把握测试的根本 准则
  • 测试用例

    • 把握测试用例编写的因素
    • 把握编写测试用例
  • 缺点

    • 理解什么是缺点
    • 理解缺点治理的益处
    • 理解缺点报告的内容
  • 缺点管理工具

    • 禅道
    • Jire

参考:

  1. Jira 中武官网
  2. 禅道官网
  3. google 软件测试之道
  4. 优质代码: 软件测试的原实际与模式

学习指标

  • 把握软件测试的根本流程
  • 晓得软件测试的 V 和 W 模型的优缺点
  • 把握软件测试的分类
软件测试的倒退

1960 年代是调试期间(测试即调试)

1960 年 – 1978 年 论证期间(软件测试是验证软件是正确的)和 1979 年 – 1982 年 破坏性测试期间(为了发现错误而执行程序的过程)

1983 年起,软件测试已有了行业标准(IEEE829),它须要使用专门的办法和伎俩,须要专门人才和专家来承当。

1990 年起软件迅速倒退,测试行业也更着产生了巨大变化,开始引入业余测试工具

什么是软件测试

在规定条件下对程序进行操作, 从而发现错误, 对软件品质进行评估的一个过程.

软件测试的目标

是想以起码的人力,物力和工夫找出软件中潜在的各种谬误与缺点,通过修改各种谬误和缺点进步软件品质,回避软件公布后因为潜在的软件缺陷和谬误造成的隐患以及带来的商业危险。

留神:不要和软件测试的定义混同

软件测试的定义

应用 人工或主动 伎俩来运行或测试摸个零碎的过程, 其目标在于测验它是否满足规定的需要或是弄清预期后果和理论后果之间的差异.

软件开发过程模型

软件开发模型 (Software Development Model) 是指软件开发全副过程、流动和工作的构造框架。软件开发包含需要、设计、编码和测试等阶段,有时也包含维护阶段。软件开发模型能清晰、直观地表白软件开发全过程,明确规定了要实现的次要流动和工作,用来作为软件我的项目工作的根底。对于不同的软件系统,能够采纳不同的开发方法、应用不同的程序设计语言以及各种不同技能的人员参加工作、使用不同的治理办法和伎俩等,以及容许采纳不同的软件工具和不同的软件工程环境。

软件开发过程模型 是软件开发人员在公司里工作的过程.

常见的软件开发过程模型

  • 瀑布模型
  • 疾速原型模型
  • 增量模型
  • 螺旋模型

1. 瀑布模型


1970 年温斯顿·罗伊斯(Winston Royce)提出了驰名的“瀑布模型”,直到 80 年代晚期,它始终是惟一被宽泛采纳的软件开发模型。

瀑布模型将软件生命周期划分为制订打算、需要剖析、零碎设计、程序编写、软件测试和运行保护等六个根本流动,并且规定了它们自上而下、互相连接的固定秩序,如同瀑布流水,逐级着落。

1.1 核心思想

瀑布模型核心思想

在瀑布模型中,软件开发的各项流动严格依照线性形式进行,以后流动承受上一项流动的工作后果,施行实现所需的工作内容。以后流动的工作后果须要进行验证,如果验证通过,则该后果作为下一项流动的输出,持续进行下一项流动,否则返回批改。

1.2 位置

瀑布模型是最早呈现的软件开发模型, 在软件工程中占有重要的位置, 它提供了软件开发的根本框架.

1.3 优缺点

长处:

1. 为我的项目提供了按阶段划分的检查点, 软件开发的每个阶段都很清晰明了
 2. 以后阶段实现后, 只有去关注后续阶段
 3. 可在迭代模型中每轮迭代很相似于一个小的瀑布模型
 4. 它提供了一个模版, 这个模版使得剖析、设计、编码、测试能够在改模版下有一个独特的领导

毛病:

  1. 各个阶段的划分齐全固定,阶段之间产生大量的文档,极大地减少了工作量
  2. 因为开发模型是线性的,用户只有等到整个过程的末期能力见到开发成绩,从而减少了开发危险
  3. 突出毛病是不适应用户需要的变动
  4. 软件的理论状况必须到我的项目开发的前期客户能力看到,这要求客户有足够的急躁

4). 应用范畴

  • 用户的需要十分分明全面,且在开发过程中没有或很少变动;
  • 开发工作对用户参加的要求很低。

2. 疾速原型模型


疾速原型模型的第一步是建造一个疾速原型,实现客户或将来的用户与零碎的交互,用户或客户对原型进行评估,进一步细化待开发软件的需要。通过逐渐调整原型使其满足客户的要求,开发人员能够确定客户的真正需要是什么;第二步则在第一步的根底上开发客户称心的软件产品。

2.1 核心思想

疾速原型是利用原型辅助软件开发的一种新思维。通过简略疾速剖析,疾速实现一个原型,用户与开发者在试用原型过程中增强通信与反馈,通过重复评估和改良原型,缩小误会,补救破绽,适应变动,最终进步软件品质。

2.2 优缺点

长处:

克服瀑布模型的毛病, 适应需要的变动, 可能开发出更加让用户更加称心的需要

毛病:

  • 所选用的开发技术和工具不肯定合乎支流的倒退;
  • 疾速建设起来的系统结构加上间断的批改可能会导致产品质量低下。
  • 应用这个模型的前提是要有一个展现性的产品原型,因而在肯定水平上可能会限度开发人员的翻新。

2.3 应用范畴

  • 不适宜大型项目的研发
  • 对所开发的畛域比拟相熟而且有疾速的原型开发工具

3. 增量模型


3.1 介绍

增量模型又称为渐增模型,是把待开发的软件系统模块化,将每个模块作为一个增量组件,从而分批次地剖析、设计、编码和测试这些增量组件。使用增量模型的软件开发过程是递增式的过程。绝对于瀑布模型而言,采纳增量模型进行开发,开发人员不须要一次性地把整个软件产品提交给用户,而是能够分批次进行提交。

3.2 根本思维

增量模型在各个阶段并不交付一个可运行的残缺产品,而是交付满足客户需要的一个子集的可运行产品。整个产品被分解成若干个构件,开发人员一一构件地交付产品,这样做的益处是软件开发能够较好地适应变动,客户能够一直地看到所开发的软件,从而升高开发危险。

3.3 优缺点

长处

  • 将待开发的软件系统模块化,能够分批次地提交软件产品,使用户能够及时理解软件我的项目的停顿
  • 以组件为单位进行开发升高了软件开发的危险。一个开发周期内的谬误不会影响到整个软件系统。
  • 开发程序灵便。开发人员能够对组件的实现程序进行优先级排序,先实现需要稳固的外围组件。当组件的优先级发生变化时,还能及时地对实现程序进行调整。

毛病

  • 要求待开发的软件能给进行增量式的开发, 否则会很麻烦
  • 在软件开发过程中需要变动是不可避免的, 增量模型的灵活性能够使其适应这种变动的能力大大优于瀑布模型和疾速原型模型,但也很容易进化为边做边改模型,从而是软件过程的管制失去整体性.

3.4 应用场景*

  • 进行已有产品升级或新版本开发

4. 螺旋模型


1988 年,巴利·玻姆 (Barry Boehm) 正式发表了软件系统开发的“螺旋模型]”,它将瀑布模型和疾速原型模型联合起来,强调了其余模型所漠视的危险剖析,特地适宜于大型简单的零碎。

如图所示,螺旋模型沿着螺线进行若干次迭代,图中的四个象限代表了以下流动:

(1)制订打算:确定软件指标,选定实施方案,弄清我的项目开发的限度条件;

(2)危险剖析:剖析评估所选计划,思考如何辨认和打消危险;

(3)施行工程:施行软件开发和验证;

(4)客户评估:评估开发工作,提出修改倡议,制订下一步打算。

螺旋模型由危险驱动,强调可选计划和约束条件从而支持软件的重用,有助于将软件品质作为非凡指标融入产品开发之中。

4.1 优缺点

长处:

  • 设计灵便能够在我的项目各个阶段进行变更
  • 危险驱动, 每个我的项目上线前都要进行危险剖析

毛病:

  • 螺旋模型强调危险剖析, 须要相当丰盛的危险评估教训和专门知识, 在危险较大的我的项目开发中,如果未可能及时标识危险,势必造成重大损失;
  • 如果执行危险剖析将大大影响我的项目的利润,那么进行危险剖析毫无意义,

4.2 应用场景

适宜应用大规模的软件我的项目

评估:评估开发工作,提出修改倡议,制订下一步打算。

螺旋模型由危险驱动,强调可选计划和约束条件从而支持软件的重用,有助于将软件品质作为非凡指标融入产品开发之中。

4.1 优缺点

长处:

  • 设计灵便能够在我的项目各个阶段进行变更
  • 危险驱动, 每个我的项目上线前都要进行危险剖析

毛病:

  • 螺旋模型强调危险剖析, 须要相当丰盛的危险评估教训和专门知识, 在危险较大的我的项目开发中,如果未可能及时标识危险,势必造成重大损失;
  • 如果执行危险剖析将大大影响我的项目的利润,那么进行危险剖析毫无意义,

4.2 应用场景

适宜应用大规模的软件我的项目

正文完
 0