2014-12-29 01:11:29 sinat_14994283 阅读数 563
  • 2019Python全套视频教程

    2019千锋好程序员全新Python教程,深入浅出的讲解Python语言的基础语法,注重基本编程能力训练,深入解析面向对象思想,数据类型和变量、运算符、流程控制、函数、面向对象、模块和包、生成器和迭代器。 您观看课程学习后 免费入群领取【超全Python资料包+17本学习电子书】

    13759 人正在学习 去看看 千锋
   1. 先自我介绍一下吧!
软件测试工作方面的问题:
   2:完成过软件测试的具体项目及知道它的职责吗?
   3. 平时工作除了软件测试测试,还有什么内容?
   4. 软件测试遇到版本迭代,你如何处理?
   5. 如何编写测试用例,保证版本迭代?
   6. 软件测试经历中,你最有成就的案例,并详细介绍一下。
   7. 如有bug,如何和开发人员沟通?
   8. 软件测试用例的模型,如果发现迭代,如何优化版本?
   9. 流程有误觉得不好的地方,如果测试文档不全,你如何与相关人员沟通?
   10. 遇到紧急上线,测试不能上线,如何和开发人员沟通?
    11. 如果产品上线出现bug,研发人员不认为是bug,软件测试人员不认为是bug,如何处理?
   12. 你以往的工作中web测试的经验。
   13. http使用经验,操作系统的使用和数据库的使用?
   以上的问题你都了解吗?如果不了解,那你一定要把这些软件测试的问题弄明白,以防你在面试的时候手忙脚乱的。如果你了解,那么恭喜你,你面试软件测试的过程一定会很顺利的!
2019-03-21 14:58:59 u010095372 阅读数 670
  • 2019Python全套视频教程

    2019千锋好程序员全新Python教程,深入浅出的讲解Python语言的基础语法,注重基本编程能力训练,深入解析面向对象思想,数据类型和变量、运算符、流程控制、函数、面向对象、模块和包、生成器和迭代器。 您观看课程学习后 免费入群领取【超全Python资料包+17本学习电子书】

    13759 人正在学习 去看看 千锋

软件工程概述

软件危机

是指落后的软件生产方式无法满足迅速增长的计算机软件需求,从而导致软件开发与维护过程中出现一系列严重问题的现象

软件危机泛指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

软件生命周期

软件的产生直到报废或停止使用的生命周期

软件开发主要分为以下几个阶段

  1. 问题定义
    确定好要解决的问题是什么(what),通过对客户的访问调查,系统分析员扼要的写出关于问题性质、工程目标和工程规模的书面报告,经过讨论和必要的修改之后这份报告应该得到客户的确认。
  2. 可行性研究
    确定该问题是否存在一个可以解决的方案。这个阶段的任务不是具体解决问题,而是研究问题的范围,套索这个问题是否值得去解决,是否有可行的解决办法。可行性研究的结果是客户做出是否继续进行这项工程的决定的重要依据,一般来说,只有投资可能取得较大的效益的那些工程项目才值得继续进行下去。
  3. 需求分析
    深入具体的了解用户的需求,在所开发的系统要做什么这个问题上和用户想法完全一致。明确目标系统必须做什么,确定目标系统必须具备哪些功能。通常用数据流图、数据字典和简要的算法表示系统的逻辑模型。用《规格说明书》记录对目标系统的需求。
  4. 概要设计(总体设计)
    概括的说,应该怎样实现目标系统,设计出实现目标系统的几种可能方案,设计程序的体系结构,也就是确定程序由哪些模块组成以及模块之间的关系。
  5. 详细设计
    实现系统的具体工作,编写详细规格说明,程序员可以根据它们写出实际的程序代码。详细设计也称模块设计,在这个阶段将详细的设计每个模块,确定实现模块功能所需的算法和数据结构。
  6. 编码和单元测试(编码占全部开发工作量的10%-20%)
  7. 综合测试(测试占全部开发工作量的40%-50%)
    分为集成测试和验收测试。
  8. 软件维护
    在这里插入图片描述

瀑布模型特点

瀑布模型有以下优点

  1. 为项目提供了按阶段划分的检查点。
  2. 当前一阶段完成后,您只需要去关注后续阶段。
  3. 可在迭代模型中应用瀑布模型。
    增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
  4. 它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

瀑布模型有以下缺点

  1. 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
  2. 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
  3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
  4. 瀑布模型的突出缺点是不适应用户需求的变化。

快速原型模型特点

原型是指模拟某种产品的原始模型,在其他产业中经常使用。软件开发中的原型是软件的一个早期可运行的版本,它反映了最终系统的重要特性。
快速原型模型又称原型模型,它是增量模型的另一种形式;它是在开发真实系统之前,构造一个原型,在该原型的基础上,逐渐完成整个系统的开发工作。快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。

优点:克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险。
这种模型适合预先不能确切定义需求的软件系统的开发。

缺点:所选用的开发技术和工具不一定符合主流的发展;快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
使用这个模型的前提是要有一个展示性的产品原型,因此在一定程度上可能会限制开发人员的创新。

快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。
  显然,快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有显著的效果。
快速原型的关键在于尽可能快速地建造出软件原型,一旦确定了客户的真正需求,所建造的原型将被丢弃。因此,原型系统的内部结构并不重要,重要的是必须迅速建立原型,随之迅速修改原型,以反映客户的需求。
快速原型模型有点整合“边做边改”与“瀑布模型”优点的意味。

增量模型特点

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

增量模型的最大特点就是将待开发的软件系统模块化和组件化。基于这个特点,增量模型具有以下优点。

  1. 将待开发的软件系统模块化,可以分批次地提交软件产品,使用户可以及时了解软件项目的进展。
  2. 以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。
  3. 开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序,先完成需求稳定的核心组件。当组件的优先级发生变化时,还能及时地对实现顺序进行调整。

增量模型的缺点是要求待开发的软件系统可以被模块化。如果待开发的软件系统很难被模块化,那么将会给增量开发带来很多麻烦。
增量模型适用于具有以下特征的软件开发项目:

  1. 软件产品可以分批次地进行交付。
  2. 待开发的软件系统能够被模块化。
  3. 软件开发人员对应用领域不熟悉,难以一次性地进行系统开发。
  4. 项目管理人员把握全局的水平较高。

迭代模型特点

早在20世纪50年代末期,软件领域中就出现了迭代模型。最早的迭代过程可能被描述为“分段模型(stagewise model)”。迭代模型是RUP推荐的周期模型。被定义为:迭代包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和要使用该发布必需的所有其他外围元素。在某种程度上,开发迭代是一次完整地经过所有工作流程的过程:需求分析、设计、实施和测试工作流程。实质上,它类似小型的瀑布式项目。RUP认为,所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。
在现代过程方法XP(eXtreme Programming,极限编程)、RUP无一例外地都推荐、主张采用能显著减少风险的迭代模型。美国国防部原本提倡瀑布过程和观点,在发现那么多采用了瀑布模型的失败的项目之后,不但放弃了对它的要求,而且从1994年的报告开始,积极地鼓励采用更加现代化的迭代模型来取代瀑布模型做法。同时,中国中科院也提倡选用迭代模型。
与瀑布模型不同,不再强调开发工作的序列化过程,而是将这些过程并行化,分为多个阶段,每个阶段都包含这些工作,只是不同阶段,不同的比例。
优点
与传统的瀑布模型相比较,迭代过程具有以下优点:

  1. 降低了在一个增量上的开支风险。如果开发人员重复某个迭代,那么损失只是这一个开发有误的迭代的花费。
  2. 降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险,可以尽早来解决而不至于在开发后期匆匆忙忙。
  3. 加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在,他们的工作会更有效率。
  4. 由于用户的需求并不能在一开始就作出完全的界定,它们通常是在后续阶段中不断细化的。因此,迭代过程这种模式使适应需求的变化会更容易些。

需求分析

数据流图

数据流图是结构化分析方法中使用的工具,它以图形的方式描绘数据在系统中流动和处理的过程,由于它只反映系统必须完成的逻辑功能,所以它是一种功能模型。在结构化开发方法中,数据流图是需求分析阶段产生的结果。

数据字典

数据流图描写叙述了系统的分解。但没有对图中各成分进行说明。数据字典是对数据流图中出现的全部被命名的图形元素在数据字典中作为一个词条加以定义,使每一个图形元素的名称都有一个确切的解释。

需求分析的重要性分析

需求分析也称为软件需求分析、系统需求分析或需求分析工程等,是开发人员经过深入细致的调研和分析,准确理解用户和项目的功能、性能、可靠性等具体要求,将用户非形式的需求表述转化为完整的需求定义,从而确定系统必须做什么的过程。
需求分析是软件计划阶段的重要活动,也是软件生存周期中的一个重要环节,该阶段是分析系统在功能上需要“实现什么”,而不是考虑如何去“实现”。需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理,确认后形成描述完整、清晰与规范的文档,确定软件需要实现哪些功能,完成哪些工作。此外,软件的一些非功能性需求(如软件性能、可靠性、响应时间、可扩展性等),软件设计的约束条件,运行时与其他软件的关系等也是软件需求分析的目标。

总体设计

软件模块化的基本思想

在设计较复杂的程序时,一般采用自顶向下的方法,将问题划分为几个部分,各个部分再进行细化,直到分解为较好解决问题为止。模块化设计,简单地说就是程序的编写不是一开始就逐条录入计算机语句和指令,而是首先用主程序、子程序、子过程等框架把软件的主要结构和流程描述出来,并定义和调试好各个框架之间的输入、输出链接关系逐步求精的结果是得到一系列以功能块为单位的算法描述。以功能块为单位进行程序设计,实现其求解算法的方法称为模块化。模块化的目的是为了降低程序复杂度,使程序设计、调试和维护等操作简单化。
利用函数,不仅可以实现程序的模块化,使得程序设计更加简单和直观,从而提高了程序的易读性和可维护性,而且还可以把程序中经常用到的一些计算或操作编写成通用函数,以供随时调用。

HIPO图

是表示软件结构的一种图形工具,以模块分解的层次性以及模块内部输入、处理、输出三大基本部分为基础建立的。
点击链接

内聚

是一个模块内部各成分之间相关联程度的度量

  1. 功能内聚 模块的所有成分对于完成单一的功能都是必须的,则称为功能内聚
  2. 通信内聚 如果一个模块的所有成分都操作同一数据集或生成同一数据集,则称为通信内聚。
  3. 逻辑内聚 几个逻辑上相关的功能被放在同一模块中,则称为逻辑内聚。如一个模块读取各种不同类型外设的输入。尽管逻辑内聚比偶然内聚合理一些,但逻辑内聚的模块各成分在功能上并无关系,即使局部功能的修改有时也会影响全局,因此这类模块的修改也比较困难。
  4. 偶然内聚 如果一个模块的各成分之间毫无关系,则称为偶然内聚,也就是说模块完成一组任务,这些任务之间的关系松散,实际上没有什么联系。

耦合

软件工程中对象之间的耦合度就是对象之间的依赖性

  1. 数据耦合 模块之间通过参数来传递数据,那么被称为数据耦合。数据耦合是最低的一种耦合形式,系统中一般都存在这种类型的耦合,因为为了完成一些有意义的功能,往往需要将某些模块的输出数据作为另一些模块的输入数据。
  2. 特征耦合 两个都与同一个数据结构有关的模块发生的耦合。由于同时使用同一个数据结构,当数据结构变动时,必然影响这两个模块,从而增加模块间的依赖性,降低模块独立性。在设计模块结构时,应当尽量将数据结构传递修改为数据传递,从而将特征耦合变为数据耦合,降低耦合度。
  3. 控制耦合 一个模块通过接口向另一个模块传递一个控制信号,接受信号的模块根据信号值而进行适当的动作,这种耦合被称为控制耦合。
  4. 公共耦合 两个或两个以上的模块共同引用一个全局数据项,这种耦合被称为公共耦合。在具有大量公共耦合的结构中,确定究竟是哪个模块给全局变量赋了一个特定的值是十分困难的。
  5. 内容耦合 当一个模块直接修改或操作另一个模块的数据时,或一个模块不通过正常入口而转入另一个模块时,这样的耦合被称为内容耦合。内容耦合是最高程度的耦合,应该避免使用之。

详细设计

https://blog.csdn.net/chs007chs/article/details/78366663

程序流程图

是用统一规定的标准符号描述程序运行具体步骤的图形表示。程序框图的设计是在处理流程图的基础上,通过对输入输出数据和处理过程的详细分析,将计算机的主要运行步骤和内容标识出来。程序框图是进行程序设计的最基本依据,因此它的质量直接关系到程序设计的质量。

PAD图

它是日本日立公司提出,由程序流程图演化来的,用结构化程序设计思想表现程序逻辑结构的图形工具。

面向对象软件工程

面向对象的优点

  1. 易维护
    采用面向对象思想设计的结构,可读性高,由于继承的存在,即使改变需求,那么维护也只是在局部模块,所以维护起来是非常方便和较低成本的。
  2. 质量高
    在设计时,可重用现有的,在以前的项目的领域中已被测试过的类使系统满足业务需求并具有较高的质量。
  3. 效率高
    在软件开发时,根据设计的需要对现实世界的事物进行抽象,产生类。使用这样的方法解决问题,接近于日常生活和自然的思考方式,势必提高软件开发的效率和质量。
  4. 易扩展
    由于继承、封装、多态的特性,自然设计出高内聚、低耦合的系统结构,使得系统更灵活、更容易扩展,而且成本较低。

面向过程的区别

面向过程就是分析出解决问题所需要的步骤,然后用函数把这些步骤一步一步实现,使用的时候一个一个依次调用就可以了。
面向对象是把构成问题事务分解成各个对象,建立对象的目的不是为了完成一个步骤,而是为了描叙某个事物在整个解决问题的步骤中的行为。

用例模型

用例模型是系统既定功能及系统环境的模型,它可以作为客户和开发人员之间的契约。用例是贯穿整个系统开发的一条主线。同一个用例模型即为需求工作流程的结果,可当作分析设计工作流程以及测试工作流程的输入使用。

类图绘制

https://blog.csdn.net/u013870094/article/details/78826614

类间的各种关系及UML表示

https://blog.csdn.net/qq_28379809/article/details/79499577

活动图绘制

https://blog.csdn.net/anyue0205/article/details/72604790

软件测试

黑盒测试

黑盒测试也称功能测试,它是通过测试来检测每个功能是否都能正常使用。在测试中,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。

白盒测试

白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法,盒子指的是被测试的软件,白盒指的是盒子是可视的,你清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。

语句覆盖

就是针对代码语句的嘛。它的含义是我们设计出来的测试用例要保证程序中的每一个语句至少被执行一次。通常语句覆盖被认为是“最弱的覆盖”,原因是它仅仅考虑对代码中的执行语句进行覆盖而没有考虑各种条件和分支,因此在实际运用中语句覆盖很难发现代码中的问题。

判定覆盖

判定覆盖也被成为分支覆盖(Branch Coverage),也就是说设计的测试用例要保证让被测试程序中的每一个分支都至少执行一次。

条件覆盖

条件覆盖于分支覆盖不同,条件覆盖要求所设计的测试用例能使每个判定中的每一个条件都获得可能的取值,即每个条件至少有一次真值、有一次假值。

判定条件覆盖

判定条件覆盖,说白了就是我们设计的测试用例可以使得判断中每个条件所有的可能取值至少执行一次(条件覆盖),同时每个判断本身所有的结果也要至少执行一次(判定覆盖)。不难发现判定条件覆盖同时满足判定覆盖和条件覆盖,弥补了两者各自的不足,但是判定条件覆盖并未考虑条件的组合情况。

条件组合覆盖

意思是说我们设计的测试用例应该使得每个判定中的各个条件的各种可能组合都至少出现一次。显然,满足条件组合覆盖的测试用例一定是满足判定覆盖、条件覆盖和判定条件覆盖的。

Alpha测试

一般来说 alphatest 测试是在公司内部组织进行的面向于部分职工的,自愿参与的产品试用。其主要目的就是以最终用户的视角去发现产品的设计缺陷和功能的不足,发现问题后,测试者可以提交BUG(硬件,软件,结构,外观方面) 给开发部门和质量部门以确保产品在最终上市前达到比较理想的状态。此测试在正规的手机研发公司和游戏开发公司中有着较为广泛的开展,也是新产品引入流程中重要的一环。

2011-10-03 00:00:00 cpongo4 阅读数 19
  • 2019Python全套视频教程

    2019千锋好程序员全新Python教程,深入浅出的讲解Python语言的基础语法,注重基本编程能力训练,深入解析面向对象思想,数据类型和变量、运算符、流程控制、函数、面向对象、模块和包、生成器和迭代器。 您观看课程学习后 免费入群领取【超全Python资料包+17本学习电子书】

    13759 人正在学习 去看看 千锋

随着敏捷越来越广为人知,敏捷测试也更多受到了大家的关注。在这里,我想谈一下我在敏捷项目中遇到的一个自动化测试相关问题以及我们如何借助DSL领域专用语言来解决它。

\

对敏捷软件开发方法有一定了解的人都知道,敏捷软件开发过程是一个迭代式交付的过程。每个迭代相当于比较小型的交付周期。那么,为了配合频繁的软件交付,敏捷测试相对于传统测试必须要做相应的调整。这也导致了敏捷项目中的测试面临几个特有的挑战:

\
  1. 频繁的回归测试以确保每个迭代的成果都是可交付的\
  2. 让整个开发团队参与到测试活动中以缩短质量信息的反馈周期\
  3. 让客户参与到测试活动中来帮助提高测试的有效性\

自动化测试在应对频繁的回归测试这个挑战上起着非常关键的作用。自动化测试做不好,团队最终会被每个迭代都会增加的回归测试工作量压垮。

\

我经历过的一个团队,在这个团队中,大家很早就意识到了自动化测试的重要性,在自动化测试上的投入不遗余力。我们相信自动化功能测试增加到足够多的时候,它就能指导手动回归测试,保证整个交付过程顺利进行。

\

的确,自动化测试刚开始进行的时候,我们收益颇多。每增加一个自动化测试,我们就能减少一些手动测试。自动化测试让我们我们有比较充裕的时间来手动测试那些还没有来得及自动化的、难以被自动化的功能点上,而且还能有时间和精力做探索性测试。这个结果让团队感到生活很美好,也让我们对自动化测试坚信不疑。

\

然而好景不长,随着自动化测试的不断增加,我们会面临这样一些问题:

\
  1. 自动化测试是围绕着实现细节展开的。随着数量的增多,业务的轮廓很容易迷失在细节中。\
  2. 在功能级别丧失了对测试的追踪。由于测试人员无法具体知晓那些测试案例被自动化测试覆盖。每次回归的时候,团队都需要回归整个测试组。\

于是,我们的手动测试越来越难得到自动化测试的帮助。它开始成了项目的鸡肋。测试代码阅读困难、维护困难以及测试结果的看起来也很费劲。这直接导致了我们不仅要投入相当的时间来增加自动化测试,也要投入不少时间来阅读并利用测试结果。

\

于是我们开始重新审视自动化测试的做法,继续摸索更好的方式。

\

很快,我们发现“能够跑起来”并不是好的自动化测试仅需的特性。让我们通过一段测试代码来看一下具体怎么回事。

\
\selenium.open(“/”)\selenium.type(“id=username”, “myname”)\selenium.type(“id=password”, “mypassword”)\selenium.click(“id=btnLogin”)\selenium.waitForPageToLoad(30000)\assertTrue(selenium.isTextPresent(“Welcome to our website!”))
\

这个测试中,我们首先打开了一个页面,在页面中寻找一个id为username的输入框,输入“myname”,然后再寻找一个id为password的输入框,输入“password”,然后点击一个id为btnLogin的按钮,等待30秒以后,断言页面应该出现的文字。

\

我们可以看到,这个测试的实现很完整的描述了测试的操作过程,是一个面向步骤而不是目的的描述。当然,稍加分析,我们也可以看出来这个测试的目的是测用户登录成功系统。

\

但是,想象当我们有很多这样面向步骤来描述的测试时,要从中抽离出被无数细碎的操作步骤所淹没的测试意图,并把测试的结果利用起来,其实并没有那么直观。而且,如果在测试中出现了错误,对于问题的具体功能点的定位也不是那么容易。

\

与此同时,并不是团队中所有的成员都有能力阅读和编写这样的测试。这无疑降低了团队成员对于自动化测试的参与度。对于客户,自动化测试更是一个黑盒子,做了什么,没做什么,基本上搞不清,更谈不上参与到自动化测试中,帮助提高测试的有效性。

\

种种状况,究其原因就是测试可读性太差,测试意图不够明显。可运行并且容易读的测试才是好的自动化测试。这样才能够保证任何时候,我们不会丧失对于测试案例的跟踪与管理。测试人员随时都可以通过快速阅读测试,了解那些功能已经被自动化测试覆盖,有效规划手工测试的工作量。

\

怎么提高测试的可读性呢?

\

我们的解决办法是DSL领域专用语言。

\

什么是领域专用语言?在马丁大叔的博客里有比较详细的描述。大致来说,领域专用语言就是针对某个领域的特定目的编程语言。不像Java、C#等通用语言,可以解决任何领域的问题。领域专用语言通过自己独特的语法结构来描述更接近于专业领域语言的业务。

\

让测试的描述能够接近被测系统的领域语言、使测试意图得到清晰表达就是我们想要得到的效果。DSL正好能够帮我们实现。

\

让我们再看看之前的那段代码:

\
\selenium.open(“/”)\selenium.type(“id=username”, “myname”)\selenium.type(“id=password”, “mypassword”)\selenium.click(“id=btnLogin”)\selenium.waitForPageToLoad(30000)\assertTrue(selenium.isTextPresent(“Welcome to our website!”))
\

由于使用的是通用语言,在我们这个特定的使用场景中显得过于细节化、过程化,不能清晰表达测试意图。

\

换成DSL,我们的测试就可以直接用验收标准的语言来描述如下:

\
\Given I am on login page\When I provide username and password\Then I can enter the system
\

这样测试的内容就直观多了,还包含了一些业务信息,让我们知道这个是在测试一个登录的场景,而不是任意的输入信息,兼顾传递了业务知识的职责。至于这些DSL背后能够运行的代码,也被隐藏起来。如果是不能够阅读原来那样的测试代码的人(不管是需求分析人员还是客户甚至一些对自动化代码关注比较少的测试人员)想要加入到自动化测试活动中进行反馈,就不会被DSL背后的代码带来的“噪音”所影响。

\

当然,在我们的现实应用场景中,这个需求没有那么简单,我们的验收标准还会考虑不同的数据比如输入不同组合的用户名密码:

\
\Given I am on login page\When I provide ‘david’ and ‘davidpassword’\Then I can enter the system\Given I am on login page\When I provide ‘kate’ and ‘kate_p@ssword’\Then I can enter the system
\

以及更多的测试数据。

\

那么这种情况下,仅仅是比较通俗的语言还是不够的,毕竟测试数量在那摆着。如果测试数量不能减少,维护起来仍然很麻烦。打个比方,如果系统的实现变成了每次都要输入用户名、密码和一个随机验证码,我们就需要在我们的自动化测试中修改多处,比较繁琐。因此,我们需要在可读性比较好的自然语言描述的测试上,把它的抽象层次再提高一点。

\

幸运的是,我们当时选择的DSL工具是cucumber,它除了提供了几个测试的描述层次:Feature,Scenario,Steps,还提供了非常好的一种组织方式—数据表。

\

这样,我们的这个自动化测试就可以把之前的那个登录的功能根据特性、场景总结和具体的步骤分离开来,清晰的分层,同时利用数据表我们的测试精简成一系列被重复多次但输入数据有所变化的操作过程,如下:

\
\Feature: authentication\In order to have personalized information\I want to access my account by providing authentication information\So that the system can know who I am\Scenario Outline: login successfully\Given I am on login page\When I provide ‘\u0026lt;username\u0026gt;’ and ‘\u0026lt;password\u0026gt;’\Then I can enter the system\Examples:\|username |password |\|david |davidpass |\|kate |kate_p@ssword|
\

测试这下看起来就更清爽了。首先,用Feature关键字,我们把测试分类到login这个大特性下的,并对这个特性本身的业务目的进行相关描述,带进业务目标,传递业务知识;然后用Scenario关键字来提高挈领的标明我们这个测试场景中做的是测试登录成功的情况,并且把步骤都写出来;最后,我们用Examples关键字引出具体的数据表格把用到的数据都展示出来,避免我们的相同步骤因为测试数据的变化而重复若干遍造成冗余。万一碰上了需求的变化,要求同时提供用户名、密码和验证码,那我们的测试也只需要改动较少的地方就足够了。

\

更棒的是,用了这种数据表的方式,整个团队的协作效率提高了。对于写代码没有那么顺畅的测试人员来说,增加自动化测试也就是增加更多测试数据,填充到数据表里就可以了。

\

就这样,我们用DSL实现了可执行的可读性高的文档。帮助了回归测试,降低了文档维护难度,也促进团队成员利用测试来传递知识的积极性,让更多人能够参与到测试中。如果您的团队也遇到了类似的问题,不妨也尝试一下。

\

感谢张凯峰对本文的审校。

\

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。

2017-11-03 13:11:31 wangqingjiewa 阅读数 2657
  • 2019Python全套视频教程

    2019千锋好程序员全新Python教程,深入浅出的讲解Python语言的基础语法,注重基本编程能力训练,深入解析面向对象思想,数据类型和变量、运算符、流程控制、函数、面向对象、模块和包、生成器和迭代器。 您观看课程学习后 免费入群领取【超全Python资料包+17本学习电子书】

    13759 人正在学习 去看看 千锋

数据库变更过程中的问题

开源数据库迁移工具 – Flyway

在软件开发迭代过程中,一般有两类变化,一是代码程序的变化,二是数据库(数据结构等)的变化,代码部分的变化我们通过二进制包的版本来定义每次的变化,我们可以快速了解到不同环境(开发、测试、生产等)的软件版本,并替换升级到最新版本,而不同于代码管理,数据库是有状态的,通常我们需要从某状态升级到最新版本,我们在上生产环境时常常会遇到在测试环境变更的脚本在生产环境未执行,甚至是漏掉一些数据库变更操作,出现数据库不一致,导致线上问题。因此数据库管理侧,我们需要考虑以下几个问题:

1. 在某台机器或环境上数据库是什么状态

2. 该环境是否应用了某数据库升级脚本

3. 应用到生产环境的脚本是否在测试环境经过测试

4. 如何快速搭建一个新的数据库实例

针对以上问题,Flyway 提供了一个便利的管理工具帮助我们轻松的管理数据库变更和迁移问题。

Flyway 特性

l 自动升级:Flyway 会根据当前数据库状态升级到最新版本。

l 规约优于配置:Flyway 定义了一套默认的规约,不需要修改任何配置就可以正常使用。

l 跨平台:Windows, Mac OSX, Linux, Java 和 Android

l 兼容多种数据库:Oracle, SQL Server, SQL Azure, DB2, DB2 z/OS, MySQL, MariaDB, Google Cloud SQL, PostgreSQL, Redshift, Greenplum, Vertica, EnterpriseDB, H2, Hsql, Derby, SQLite

l 高可靠性:在集群环境下进行数据库升级是安全可靠的。

l 支持失败修复:提供了Repair 功能,用于解决数据库更新操作失败问题。

Flyway 如何工作

开源数据库迁移工具 – Flyway

按照 Flyway 规范,我们需要对每一次的数据变更记录对应一个脚本升级文件,并通过文件名称描述脚本版本号,脚本文件名规范 V<version>[_<SEQ>][__description],

如:V1__Initial_Setup.sql,V2__First_Changes.sql,V2_1__Second_Changes.sql 。在创建一个新的数据库时,Flyway 会初始化一个表SCHEMA_VERSION,该表记录了数据库变更历史记录,之后会按找脚本的版本号顺序执行相应脚本。下图为 SCHEMA_VERSION 记录表的数据:

开源数据库迁移工具 – Flyway

当我们在一个已存在环境进行数据库升级时,我们只需要按照版本命名规范,创建一个新的脚本文件V2_1__Refactoring.sql,Flyway 会根据当前数据库版本状态,自动过滤已经执行的脚本,只执行版本号大于当前版本号的脚本,如下图:

开源数据库迁移工具 – Flyway

开源数据库迁移工具 – Flyway

Flyway 使用方法

Flyway 支持多种工作方式,可以轻松与现有系统进行集成:

l Command Line 命令行方式

l API(Java Interface)

l Maven

l Gradle

l Ant

l SBT

以通用的命令行方式为例

1. 下载 Flyway 并解压

开源数据库迁移工具 – Flyway

2. 配置 Flyway

修改 /conf/flyway.conf 文件,配置数据库源

开源数据库迁移工具 – Flyway

3. 创建第一个数据脚本

在 sql/ 目录根据规范创建脚本文件 V1__Create_person_table.sql:

开源数据库迁移工具 – Flyway

4. 迁移数据到指定数据库

开源数据库迁移工具 – Flyway

执行日志如下:

开源数据库迁移工具 – Flyway

5. 创建第二个数据库升级脚本,并执行升级

在 sql/ 目录根据规范创建脚本文件 V2__Add_people.sql:

开源数据库迁移工具 – Flyway

执行迁移操作结果:

开源数据库迁移工具 – Flyway

可以看到我们将当前数据库从 Version 1升级到了Version 2版本。

Flyway事务处理

在最新4.2.0 版本中增加了 Group 的概念,可以将多个 Pending 状态的升级脚本放在同一个事务中执行,对于支持事务的数据库,如果其中有失败的语句,可以快速回滚到迁移前状态,保证一致性。

开源数据库迁移工具 – Flyway

总结

在日常软件版本迭代过程中,常常遇到开发测试时变更的数据库操作没有完整记录,在生产环境出现代码与数据库不一致问题,甚至在没有开发和测试环境测试的前提下,直接在生产环境进行数据库变更,出现问题很难排查,提高了管理复杂度,通过使用 Flyway 提供的规范和工具,我们可以轻松跟踪数据库版本状态,以及升级的记录,升级代码的同时升级数据库,降低对数据库变更管理的复杂度,减少人工操作带来的失误。


作者:刘永强

JFrog 中国技术支持负责人,曾在 HPE,亿玛等公司担任高级工程师,专注系统架构、软件CI/CD及devops领域,在互联网平台建设上有着丰富的经验,曾服务的客户有中兴通讯,宜人贷,易保科技,顺丰等等,并负责过多个互联网平台和移动应用的研发和运维工作。


2015-05-26 13:08:31 wonew1228 阅读数 361
  • 2019Python全套视频教程

    2019千锋好程序员全新Python教程,深入浅出的讲解Python语言的基础语法,注重基本编程能力训练,深入解析面向对象思想,数据类型和变量、运算符、流程控制、函数、面向对象、模块和包、生成器和迭代器。 您观看课程学习后 免费入群领取【超全Python资料包+17本学习电子书】

    13759 人正在学习 去看看 千锋

1.  测试遇到的困惑与挑战

随着飞信活跃用户、同时在线数量的不断增加,互联网的快速发展,以及微信等新一代IM产品的上线,客观上对飞信的发展带来了巨大的挑战。作为飞信的开发运营支撑商,必须产品运营模式和开发流程进行变革才能使飞信产品更好的发展。而这些变化必然对原有的测试流程和体系带了很大的挑战。

互联网转型:互联网时代的到来,最直接的变化就是快,产品需要快速迭代,快速发布版本,原来需要半年时间发布一个客户端,而现在需要2个月甚至一个月发布一个客户端。如何在最短的时间提高更高质量的产品是摆在我们面对的一个首要问题。


多架构共存:为了适应互联网产品的快速发展以及更好的满足客户需求,需要对原有的架构进行升级,而在升级的过程中存在多系统架构并存,在测试过程中既要满足系架构的稳定正常运行,又要保证对老的系统架构的兼容性,这些无论是在工作难度还是工作量上都对测试工作提出了一个很大的挑战。

多种开发模式共存:为了适应互联网的开发节奏和保持原有系统的稳定,在开发过程中敏捷开发模式与传统开发模式交替共存,测试怎么样实现在传统模式中的“稳”和敏捷模式中的“快”,对测试来说这是一个巨大的挑战。

分省运营、灰度发布

在互联网产品中常常使用灰度发布这一策略,灰度发布能够及早获得用户的意见反馈,完善产品功能,提升产品质量 让用户参与产品测试,加强与用户互动降低产品升级所影响的用户范围。 另外,随着移动互联网公司的成立,对飞信的运营模式进行了改革,要求支持飞信分省运营模式。灰度发布和分省运营的变化对测试来说,工作量成指数增加。如何在测试成本可控的条件下进行测试是我们每个人必须考虑的一个课题。

另外随着移动互联网的快速发展,飞信需要支持的客户端越来越来越多,用户场景越来越复杂,对测试的难度和工作量剧增。

2.  各种接口方案分析及实施

如何解决上面提到的几个问题?要解决这些问题按照常规的测试模式,肯定不能满足;经过分析(见下图)我们认为在客户端的皮下层进行测试。也就是接口测试,可以很好的解决上面的问题。


经过对业务和接口的详细梳理,发现在所有的系统中,其接口测试无非就是需要对以下集中种接口进行测试:

客户端模拟接口测试

随着无线互联网的飞速发展,越来越的手机厂商加入,越来越多基于开源手机操作系统开发的系统的增加,以及多种网络的接入,采用传统在UI进行测试的方法成本越来越高,实施分层测试,进行模拟客户端测试势在必行,对于一般的系统来说,各种客户端连接服务器端的接口都是相同的,或者根据版本不同会有略微差异。那么在接口测试时,就可以把UI要测试的几十种版本分类抽象出一个或者几个版本接口测试,而客户端的测试仅仅需要在UI上进行核心功能验证和适配测试,从而大大提高测试效率。如在飞信测试过程中大概会有15个以上客户端需要测试,在测试过程中又会根据情况选择1-3个版本的客户端进行测试,那么在一个大的版本测试中累计测试客户端达到30个以上,其工作量可想而知;如果进行接口测试,通过对各个客户端和不同版本分析,其接口后台通信协议只有三种(如下图所示),那么在测试过程中只需要模拟三个客户端,即可完成对所有客户端模拟测试,大大节省了测试时间。另外测试前移也使得在开发过程中尽早尽快的发现问题成为可能,从而加快版本迭代速度。


多系统集成项目接口测试

在互联网时代,任何一个系统都不能孤立存在,需要和其它系统进行交互。而在大部分情况下, 这种多系统之间的集群测试,很难等到所有项目都配置部署完成才进行测试,那么就需要模拟被测系统与其他系统的交互(如下图所示)。在模拟测试前,现需要整理分析其被测系统前置条件和被测系统发送的请求信息;在模拟系统接收到请求信息后,按照预先约定的信息下发通知给被测系统,被测系统接收到下发通知后,继续执行被测系统,完成一次测试模拟。通过多系统集群的模拟测试,提高系统的测试覆盖率。


通用接口(比如web services等)测试和自定义对象格式接口测试

通用接口(比如web services等)测试和自定义对象格式接口测试(如SDK接口等)这两种接口测试在本质上没有多大的区别,但其在测试实现和组织上会有一定的差异,在此不详细叙述。对于这两种测试,测试人员需按照协议规范设置需要的测试输入输出参数,然后按照约定的请求格式发送请求,然后在比对测试结果。对于这类测试,如果在接口比较少的情况向,建议使用测试代码直接测试;而对于接口较多,使用较为频繁,根据情况可以开发测试工具或者自动化工具;对于使用自动化测试来说,其难点是如何组织设置接口的前置条件,所以说对于这类测试建议最好使用测试工具而不是自动化测试。

强交互类系统接口测试

3.  接口收获与经验

通过对接口测试使用自动化后,对server的测试带来很多收获。

1.     自动化测试使得测试覆盖率提高10%,通过自动化测试实现了一些原来不能测试的用例:比如心跳,强制短信、短信回复、消息稳定率(7*24)测试、电量、内存等长时间测试。

2.     测试效率提升50%:自动化测试覆盖核心用例和单功能用例实现100%覆盖,重要功能70%以上覆盖,总体覆盖达53%;在测试执行中,BVT用例、灰度测试以及版本任务测试(版本任务实现手工测试与自动化测试统一管理,协调工作);通过测试实践得出整体测试效率提升50%以上(说明:测试脚本在开发单模块时一次完成,对于协议测试不需要维护成本。

3.     通过自动脚本整理,自动化测试脚本描述的业务逻辑分析,其业务描述已成为公司最新最全的业务资产库。通过对业务逻辑分析,优化逻辑,大大提升了量,比如会过业务分析化消息成功率从99.9%提升到99.987%

在接口测试过程中,怎么像测试人员证明其测试结果是可信的,怎样才能保证实施自动化过程中不增加测试人员的工作量和不改变测试人员原有工作模式。这些都是考验自动化测试是否能够成功的最主要因素。

在自动化测试过程中,如果保证测试结果正确性,在测试实践中有几条我认为比较好的经验。

1.    测试脚本评审:在编写自动化测试脚本后,每个测试脚本必须通过评审。测试脚本评审虽然不能保证测试脚本完全正确,但至少可以查出一些比较明显的业务逻辑,同时也是使其参与评审测试人员在内心不会对测试脚本的质量感到恐慌和不信任。在评审过程中有几点要注意:1.尽可能的让评审业务相关的测试人员参与;2.每次评审时间不超过1个小时,时间过程容易流于形式;3谁提出问题,谁负责审查。

2.     定时任务检查:通过评审的信令场景加入定时任务,连续运行监测其正确性。在其定时任务执行过程中,一般会连续执行一个月,每天会安排固定人员对测试结果进行分析验证(一般会安排参与评审的业务人员,分析时间一般不超过30分钟)。对于在连续一周以上且通过率高于93%的任务,安排进行与版本同步测试验证其正确性。



3.     与测试版本同步:在版本测试任务同时,进行自动化测试,检查其脚本的正确性。

4.     测试交付:通过评审,最近两周定时任务连跑中通过率超过95%,IM基础功能和测试模块,在版本任务中测试验证过两次以上

在自动化测试过程中, 尽可能不改变原有测试流程,比如我们在飞信业务测试过程中,自动化测试时结合原有流程(如下图)


1)   测试用例和手工测试用例实现一管理,在编写用例过程中,直接从测试工具中导入用例到自动化平台,同时在测试管理工具中标示出改用例已自动化实现。

2)   在有版本任务分过来后,在测试平台建立测试任务,同时自动在自动化平台生成一个测试计划。

3)   测试人员只需要测试自动化没有实现的测试用例,自动化测试执行自动化实现的用例,在执行完成后把测试结果自动导入到测试平台。

4)   测试人员根据测试结果编写测试报告

在自动化测试过程中要结合业务进行一些定制化的测试,比如在飞信测试项目中,根据其特点建立了数据池及灰度测试策略和二次连跑机制

账号池及灰度测试::通过统一账号管理,实现对不同账号的管理(不同环境的账户、不同site的账户管理),通过执行策略,分账户实现功能之间灰度测试

二次连跑:针对协议测试的不确定情况,设置了连跑模式,可以设置不同的连跑模式(连跑、二次连跑、直到通过等)


如有问题请发邮件至wonew1228@163.com

接口测试群:接口测试分享群  群号:126225381


没有更多推荐了,返回首页