精华内容
下载资源
问答
  • 自动化测试用例设计原则(转)

    千次阅读 2018-06-03 09:28:47
    一、自动化测试存在的真正意义: 主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工作中解脱出来。它的主要目的在于验证问题,而不是发现问题。所以对于自动化的设计,主要集中在功能正确性方面。 目前...

    内容摘自:http://www.cnblogs.com/jshtest/p/6362677.html

    一、自动化测试存在的真正意义:

    主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工作中解脱出来。它的主要目的在于验证问题,而不是发现问题。所以对于自动化的设计,主要集中在功能正确性方面。

    目前自动化测试阶段定位在冒烟测试和回归测试。冒烟测试执行的是主体功能点的用例,回归测试执行全部或部分的测试用例。

    二、自动化测试用例的设计原则:

    1、一个脚本是一个完整的场景,从用户登陆操作到用户退出系统关闭浏览器。

    2、一个脚本只验证一个功能点,不要试图用户登陆系统后把所有的功能都进行验证再退出系统

    3、尽量只做功能中正向逻辑的验证,不要考虑太多逆向逻辑的验证,逆向逻辑的情况很多(例如错误的登录账号有很多情况),验证一方面比较复杂,需要编写大量的脚本,另一方面自动化脚本本身比较脆弱,很多非正常的逻辑的验证能力不强。(我们尽量遵循用户正常使用原则编写脚本即可)

    4、脚本之间不要产生关联性,也就是说编写的每一个脚本都是独立的,不能依赖或影响其他脚本。
    5、如果对数据进行了修改,需要对数据进行还原。

    6、在整个脚本中只对验证点进行验证,不要对整个脚本每一步都做验证。

    三、用例选择注意事项:

    1、不是所有的手工用例都要转为自动化测试用例。

    2、考虑到脚本开发的成本,不要选择流程太复杂的用例。

    3、选择的用例最好可以构建成场景。例如一个功能模块,分n 个用例,这n 个用例使用同一个场景。这样的好处在于方便构建关键字测试模型。
    4、选择的用例可以带有目的性,例如这部分用例是用例做冒烟测试,那部分是回归测试等,当然,会存在重叠的关系。
    5、选取的用例可以是你认为是重复执行,很繁琐的部分,例如字段验证,提示信息验证这类。这部分适用回归测试。

    6、选取的用例可以是主体流程,这部分适用冒烟测试。

    7、测试用例需要更多的关注功能逻辑的实现,而不必纠结某些字段的限制。

    8、自动化测试也可以用来做配置检查,数据库检查。这些可能超越了手工用例,但是也算用例拓展的一部分。项目负责人可以有选择地增加。

    9、如果平时在手工测试时,需要构造一些复杂数据,或重复一些简单机械式动作,可以让自动化脚本来帮你。

    四、自动化测试用例转型原则

    1、当前的测试用例前置配置信息要写清楚。

    2、每一个步骤都要衔接好,错了,脚本要抛出异常。

    3、每一个步骤要做什么,验证什么要写清楚,写具体。有时一个检查点,你只需看一眼,但是脚本要写一堆代码去验证,这样的做法是不可行的。

    4、用例之间不要有关联性,自动化测试开发同样是软件开发工程,脚本编写同样提倡高内聚低耦合的理念。

    5、不是每一个步骤都需要验证点。

    6、别在多个地方重复相同的验证。脚本很忙!我没空。当然,除非有必要。

    7、开门记得要关门,配置信息要回归原点,否则脚本要迷路。

    展开全文
  • 自动化测试的基本原则

    千次阅读 2018-08-13 15:03:26
     每个实行持续交付的项目,都有生产流水线的元素,如持续集成和自动化测试。这些测试是在不同层面进行的,从单元测试到冒烟测试再到功能测试。自动化功能测试的优点之一是可重复性和可预测的执行时间。出于这个原因...

    介绍
      每个实行持续交付的项目,都有生产流水线的元素,如持续集成和自动化测试。这些测试是在不同层面进行的,从单元测试到冒烟测试再到功能测试。自动化功能测试的优点之一是可重复性和可预测的执行时间。出于这个原因,它应该作为软件质量的每一个构建之后的指标。功能测试自动化往往会成为一个瓶颈,所以你应该熟悉一下如何创建这样的测试的基本原则。
      
      首先设计你的测试
      测试集合可以比作盆景树。
      最初的时候,我们照顾树根和树干。我们选择会成长的主要分支,我们每天都细心照料这棵树并等待它长出健康的叶子。
      我们可以以类似的方式继续测试。
      我们建一个将负责应用程序主要功能(例如:开启)的基类。
      根据说明,我们先明确将被测试覆盖的应用程序的主要功能,然后每天我们在执行测试的时候都添加更多平行测试。
      每一个支持测试(例如创建一个新的用户)的方法都需要与测试分离——让我们在单独的类里面来实现。
      你应该在包括了应用程序主要功能的目录里保持类。
      去建一个规定很多功能共有方法的抽象类是很好的做法。
      如果你正在测试Web应用程序,就用页面对象设计模式。该模式里,一个类及其方法对应了单个页面的功能或一个大型网页里单个页面上的一个元素。
      
      
      无需事事自动化
      自动化花费很多,所以你应该主要测试应用程序的主要功能。
      某些测试可以快速轻松地手动完成,且潜在脚本可能难以实现。
      值得用到自动化的是那些繁琐的需要被重复很多次的,和那些需要大量数据验证的测试工作。
      
      写短测试
      在一个或多个测试失败的情况下,开发团队的任何成员都应该能够轻松地找到错误的原因。
      出于这个原因,每个测试方法里应该最多有5个断言,并且每个方法都必须提供的测试操作的完整记录。
      明智的做法是使用BDD(行为驱动开发)技术,但是当你没有用一个特定的测试框架时,你应该把接下来的测试步骤放在comments //given //when //then下。
      
      创建独立测试
      在测试类中的每个方法应该是一个独立的实体,而不是依赖于其他测试。我们应该能够在任何时间运行单个测试。否则,这样的测试用例集将来维护起来就会很贵——必须定期跟踪和更新测试之间的联系。
      很多时候,测试需要一定的前提条件来满足。这些条件不应该用外部方法,应该在试验开始时运行。如果这些条件和测试类的所有方法一样,它们就可以被放在一开始进行的方法里(例如:在JUnit中被标记为@ BeforeClass)。
       
      关注可读性
      源代码应该是自我记录的,而写下以下几行代码的每个利益相关者应该明白测试在做什么,为什么它被这么写。尽量避免在源代码注释,因为它也必须被更新。这值得花比平常多一点的时间来命名方法,从而使你的代码更易读。
      再看看行为驱动开发技术,每个测试方法都应以单词“应该”开始,而不是“测试”。
      根据这一惯例,我们马上就可以明白一个特定的方法测试什么内容了,它在分析测试报告时特别有用。
      
      测试必须要快
      正如在本文开头所提到的,自动化功能测试应该是应用程序质量的一个指标。连续传递过程中的每一步都应指明最长持续时间;并且根据这个概念,开发团队应该尽快获得有关软件质量的反馈。自动化功能测试的持续时间应不超过几分钟。
      对一个非常全面的测试集来说,有必要并行运行测试(经常在不同的机器上)。虚拟化在这里可能是非常有帮助的。
      
      创建抗变测试
      最常提及自动化功能测试的缺点是其对应用程序中变化的低抵抗性,尤其是在GUI中。
      在Web应用程序中,测试应该能抵抗网站的内容的变化。测试应该只验证功能,这就使得它可以在不同的位置运行测试。这并不意味着我们不应该编写自动化测试来检查网页的内容。
       如果你已经想创建这样的测试,你应该遵循DDT(数据驱动测试)技术。这意味着,检查内容是与源代码分离开的。
      Web应用程序的页面布局变化非常频繁,这已经影响到了用户界面。
      当你设计一个界面时,每个区段和每个页面你都应该有一个你可以用来测试的唯一标识符,即使一个网站的层次结构发生了变化。
      
      自动化测试无法取代人类
      功能自动化测试可以是项目中的主要测试技术,但绝不是唯一的一个。
      自动化测试是可重复再生的,他们的覆盖范围总是相同的。
      另一方面,虽然探索性测试是低再生的,但是它们能够覆盖自动化测试未触及的区域。
      你还应该记住,自动化测试的“绿色”状态并不意味着你的应用程序是没有错误的。
      这种情况往往会让测试员分心,而且有可能会影响测试的准确性。

    展开全文
  • 自动化测试用例设计

    千次阅读 2018-09-19 16:22:09
    一、了解自动化测试的目的和作用  自动化测试是为了让测试人员从繁琐重复的机械式测试过程中解脱出来,把时间和精力投入到更有价值的地方,从而挖掘更多的产品缺陷。目前自动化测试更多的是定位在冒烟测试和回归...

     一、了解自动化测试的目的和作用

      自动化测试是为了让测试人员从繁琐重复的机械式测试过程中解脱出来,把时间和精力投入到更有价值的地方,从而挖掘更多的产品缺陷。目前自动化测试更多的是定位在冒烟测试和回归测试;冒烟测试执行的是主体功能点的用例。回归测试执行全部或部分的测试用例。它的主要目的在于验证问题,而不是发现问题。所以对于自动化的设计,主要集中在功能正确性方面。

      在自动化测试的流程中,其关键点在于自动化测试设计,包括测试用例设计、测试脚本架构及测试组织。

      下面主要讲自动化测试用例的设计。

      二、手工测试用例与自动化测试用例的区别

      1、手工测试用例

      a、能通过人为的逻辑判断校验当前步骤的功能实现是否正确。能较好的处理异常场景。

      b、执行测试用例具备一定的跳跃能力。

      c、人工测试可以步步跟踪分析,能够细致的定位问题。

      d、主要用来发现产品缺陷。

      2、自动化测试用例

      a、所有的判断校验都需要编写脚本来实现。

      b、测试用例步骤之间需要关联关系。

      c、主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工作中解脱出来。

      d、目前自动化测试阶段定位在冒烟测试和回归测试。

      三、自动化测试用例设计原则

      自动化测试用例设计决定自动化测试成败的关键。

      1、设计误区

      a、不编写测试用例直接编写测试脚本。

      b、直接拿手工测试用例来编写自动化测试脚本。

      2、设计原则

      a、测试用例是一个完整的场景。从用户登录系统到用户退出。

      b、测试用例只验证一个功能点。不要试图用户登录后验证所有的功能点再退出。

      c、测试用例尽量只做正向的逻辑验证,正向是指脚本可实现的而非主观操作。逆向逻辑的情况很多,验证比较复杂,需要编写大量的脚本,投入成本比较高。

      d、测试用例之间不要产生关联,也就是说每个测试用例是独立,不能依赖或影响其他测试用例,要求高内聚低耦合。

      e、测试用例需要更多的关注功能逻辑的实现,而不必纠结某些字段的限制。

      f、测试用例的上下文必须有一定的顺序性,要能够互相连接起来;并且前置条件要清楚。

      g、测试用例中检查点的设置(根据测试用例的侧重点设置检测点、设置检测点要全面和设置检测点要灵活)。

      h、测试用例要对修改的数据进行还原操作。

      i、测试用例必须是可回归的。

      四、如何把手工测试用例和自动化测试用例相辅相成

      1、自动化测试用例选型原则

      a、不是所有的手工用例都要转为自动化测试用例。

      b、考虑到脚本开发的成本,不要选择流程太复杂的用例。如果有必要,可以考虑把流程拆分多个用例来实现脚本。

      c、选择的用例最好可以构建成场景。例如一个功能模块,分n个用例,这n个用例使用同一个场景。

      d、选择的用例可以带有目的性,例如这部分用例是用例做冒烟测试,那部分是回归测试等,当然,会存在重叠的关系。如果当前用例不能满足需求,那么唯有修改用例来适应脚本和需求。

      e、选取的用例可以是你认为是重复执行,很繁琐的部分,例如字段验证,提示信息验证这类。这部分适用回归测试。

      f、选取的用例可以是主体流程,这部分适用冒烟测试。

      2、自动化测试用例转型原则

      a、当前的测试用例前置配置信息要写清楚。

      b、每一个步骤都要衔接好,错了,脚本要抛出异常。

      c、每一个步骤要做什么,验证什么要写清楚,写具体。有时一个检查点,你只需看一眼,但是脚本要写一堆代码去验证,这样的做法是不可行的。

      d、用例之间不要有关联性,自动化测试开发同样是软件开发工程,脚本编写同样提倡高内聚低耦合的理念。

      e、不是每一个步骤都需要验证点。

      f、别在多个地方重复相同的验证。脚本很忙!我没空。当然,除非有必要。

      g、开门记得要关门,配置信息要回归原点,否则脚本要迷路。

    展开全文
  • 设计自动化测试用例的原则

    千次阅读 2015-08-08 14:49:32
    这是再基本不过的要求了,但别看只是简单的一句话,要能够达到切实覆盖全面,需要对被测试产品功能的全面了解、明确测试范围(特别是要明确哪些是需要测试的)、具备基本的测试技术(如:等价类划分等)等。...
    测试用例设计的最基本要求:覆盖住所要测试的功能。这是再基本不过的要求了,但别看只是简单的一句话,要能够达到切实覆盖全面,需要对被测试产品功能的全面了解、明确测试范围(特别是要明确哪些是不需要测试的)、具备基本的测试技术(如:等价类划分等)等。那么满足了上述这条要求是不是设计出来的测试用例就是好的测试用例了呢?答案:在理论上是,但在实际工程中还远远不是。之所以理论和实际会有这样的差别,是因为在理论上不要考虑的东东,而在实际工程中是不得不考虑的 - 成本。这里的成本包括:测试计划成本、测试执行成本、自动化测试用例、测试自动化成本,测试分析成本,以及测试实现技术局限、测试环境的Bug、人为因素和不可预测的随机因素等引入的附加成本等。 
    

          由于成本因素的介入,决定了工程中设计好的测试用例原则不只有“覆盖住所要测试的功能”这一条,下面是我根据自己的工作经验总结出的其它四条原则,在这里抛砖引玉,希望大家拍砖和指正。这些原则特别是针对那些需要被自动化,并且是要被经常执行的测试用例。

     

     

    1. 单个用例覆盖最小化原则。

           这条原则是所有这四条原则中的”老大“,也是在工程中最容易被忘记和忽略的,它或多或少的都影响到其它几条原则。下面举个例子来介绍,假如要测试一个功能 A,它有三个子功能点 A1,A2 和 A3,可以有下面两种方法来设计测试用例:

    • 方法1 :用一个测试用例覆盖三个子功能 -Test_A1_A2_A3,
    • 方法2 :用三个单独的用例分别来覆盖三个子功能 - Test_A1,Test_A2,Test_A3

    方法1适用于规模较小的工程,但凡是稍微有点儿规模和质量要求的项目,方法2则是更好的选择,因为它具有如下的优点:

    • 测试用例的覆盖边界定义更清晰
    • 测试结果对产品问题的指向性更强
    • 测试用例间的耦合度最低,彼此之间的干扰也就越低

           上述这些优点所能带来直接好处是,测试用例的调试、分析和维护成本最低。每个测试用例应该尽可能的简单,只验证你所要验证的内容,不要“搂草打兔子”捎带着把啥啥啥啥都带进来,这样只会增加测试执行阶段的负担和风险。David Astels在他的著作《Test Driven Development:A Practical Guide》曾这样描述 : " 最好一个测试用例只有一个Assert语句"。此外,覆盖功能点简单明确的测试用例,便于组合生成新的测试,很多测试工具都提供了类似组合已有测试用例的功能, 例如: Visual Studio中就引入了Ordered Test的概念。

     

     

    2. 测试用例替代产品文档功能原则。

           通常我们会在开发的初期(Scrum每个Sprint的头两天)用Word文档或者OneNote的记录产品的需求、功能描述、以及当前所能确定的任何细节等信息,勾勒将要实现功能的轮廓样貌,便于团队进行交流和细化,并在团队内达成对将要实现的产品功能共识。假设我们在此时达成共识后,描述出来的功能为A,随着产品开发深入,经过不断地迭代之后,团队会对产品的功能有更新的认识,产品功能也会被更具体细化,在一个迭代或者Sprint结束的时候最终实现的功能很可能是A+。如此往复,在不断倾听和吸收用户的反馈,修改产品功能,多个迭代过后,原本被描述为A的功能很可能最终变为了Z。这是时候再去看曾经的Word文档和OneNote页面,却仍然记录的是A。之所以会这样,是因为很少有人会去(以及能够去)不断更新那些文档,以准确反映出产品功能当前的准确状态。不是不想去做,而是实在很难!这里需要注意:早期的Word或者OneNote的文档还是必要的,它至少能保证在迭代初期团队对要实现功能有一致和准确的认识。

           就没有什么东西能够一直准确地描述产品的功能了吗?答案:当然有,那就是产品代码和测试用例。产品代码实现了产品功能,它一定是准确描述了产品的当前功能,但是由于各种编程技术,如:面向对象、抽象、设计模式、资源文件等等,使得产品代码很难简单地就能读懂,往往是在知道产品功能的前提下去读代码,而不是反过来看代码来了解功能。好的代码会有详细的注释,但这里的注释是对实现代码的解释和备注,并不是对产品功能的描述。这里有一篇很老的博客Reading Code Is Hard,介绍了如何能够使代码更可读一些编写技巧。

           那么就只有测试用例了,测试也应该忠实反映了产品功能的,否则的话测试用例就会执行失败。以往大家只是就把测试用例当作测试用例而已,其实对测试用例的理解应该再上升到另一个高度,它应该是能够扮演产品描述文档的功能。这就要求我们编写的测试用例足够详细、测试用例的组织要有调理、分主次,单靠Word、Excel或者OneNote这样通用的工具是远远无法完成的,需要更多专用的测试用例管理工具来辅助,例如 Visual Studio 2010引入Microsoft Test Manager

           此外,对于自动化测试用例(无论是API或者UI级别的)而言,代码在编写上也应该有别产品代码编写风格,可读性和描述性应该是重点考虑的内容。在测试代码中,当然可以引入面向对象、设计模式等优秀的设计思想,但是一定要适度使用,往往面向过程的编码方式更利于组织、阅读和描述。

     

     

    3. 单次投入成本和多次投入成本原则。

           与其说这是一条评判测试用例的原则,不如说它是一个思考问题的角度。成本永远是任何项目进行决策时所要考虑的首要因素,软件项目中的开发需要考虑成本,测试工作同样如此。对成本的考虑应该客观和全面地体现在测试的设计、执行和维护的各个阶段。当你在测试中遇到一些左右为难的问题需要决策时,尝试着从成本角度去分析一下,也许会给你的决策带来一些新的启发和灵感。

           测试的成本按其时间跨度和频率可以分为:单次投入成本和多次投入成本。例如:编写测试用例可以看作是单次投入成本,因为编写测试用例一般是在测试的计划阶段进行(Scrum每个Sprint的开始阶段)的,虽然后期会有不断的调整,但绝大多数是在一开始的设计阶段就基本上成型了;自动化测试用例也是如此,它也属于是一次性投入;测试用例(包括:手工和自动化测试用例)的执行则是多次投入成本,因为每出一个新版本Build时都要执行所有的测试用例(或者进行BVT测试仅执行高优先级的测试用例)、分析测试结果、调试失败测试用例、确定测试用例的失败原因(产品缺陷、测试用例缺陷、测试框架缺陷还是随机问题导致了测试用例的失败),以验证该版本整体质量是否达到了指定的标准。

           之所有要引入单次和多次成本的思考,是希望能够通过区分测试中不同活动对测试成本的影响,从而进行帮助我们合理布局在不同阶段的投入和做出正确的决策,以保证在有限可负担测试成本的前提下,最大限度地有效开展测试工作。例如,当我们意识到了,测试用例的设计和自动化属于是一次性投入,而测试用例的执行则是反复多次的投入时,就应该积极思考如何能够提高需要反复投入的测试执行的效率,在一次投入和需要多次活动需要平衡时,优先考虑多次投入活动的效率,其实这里是有很多工作可以做。

           例如:第一条原则-单个用例覆盖最小化原则 - 就是一个很好的例子,测试A功能的3个功能点A1,A2和A3,从表面上看用Test_A1_A2_A3这一个用例在设计和自动化实现时最简单的,但它在反复执行阶段会带来很多的问题:

    • 首先,这样的用例的失败分析相对复杂,你需要确认到底是哪一个功能点造成了测试失败;
    • 其次,自动化用例的调试更为复杂,如果是A3功能点的问题,你仍需要不断地走过A1和A2,然后才能到达A3,这增加了调试时间和复杂度;
    • 第三,步骤多的手工测试用例增加了手工执行的不确定性,步骤多的自动化用例增加了其自动执行的失败可能性,特别是那些基于UI自动化技术的用例;
    • 第四,(Last but not least)将不相关功能点耦合到一起,降低了尽早发现产品回归缺陷的可能性,这是测试工作的大忌。例如:如果Test_A1_A2_A3是一个自动测试用例,并按照A1->A2->A3的顺序来执行的,当A1存在Bug时,整个测试用例就失败了,而A2和A3并未被测试执行到。如果此时A1的Bug由于某些原因需要很长时间才能修复,则Test_A1_A2_A3始终被认为是因为A1的Bug而失败的,而A2和A3则始终是没有被覆盖到,这里存在潜在的危险和漏洞。当你在产品就要发布前终于修复了A1的Bug,并理所当然地认为Test_A1_A2_A3应该通过时,A2和A3的问题就会在这时爆发出来,你不得不继续加班修复A2和A3的问题。不是危言耸听,当A2/A3的代码与A1的Bug修复相关时,当你有很多如此设计的测试用例时,问题可能会更糟… …,真的!:( 

           综上所述,Test_A1_A2_A3这样的设计,减少地仅是一次性设计和自动化的投入,增加地却是需要多次投入的测试执行的负担和风险,所以需要决策时(事实上这种决策是经常发生的,尤其是在设计测试用例时)选择Test_A1_A2_A3还是Test_A1、Test_A2和Test_A3,请务必要考虑投入的代价。

     

     

    4. 使测试结果分析和调试最简单化原则。

           这条原则是实际上是上一条 - 单次投入成本和多次投入成本原则 - 针对自动化测试用例的扩展和延续。在编写自动化测试代码时,要重点考虑如何使得测试结果分析和测试调更简单,包括:用例日志、调试辅助信息输出等。往往在测试项目中,测试用例的编写人和最终的执行者是不同的团队的成员,甚至有个能测试的执行工作被采用外包的方式交给第三的团队去进行,这在当下也是非常流行的。因为测试用例的执行属于多次投入,测试人员要经常地去分析测试结果、调试测试用例,在这部分活动上的投入是相当可观的。有时候,测试框架提功能的一些辅助API等就可以帮助很好实现这个原则。例如:Coded UI Test就提供了类似的API,详见 - VS 2010 测试功能学习(18) – Coded UI Test三个必知的函数,来辅助基于Coded UI框架实现的自动化测试用例有更好的调试体验。

     

           测试理论为测试工作指明了大的前进方向,在实际工程中还需要我们不断地“活化”这些理论,使理论和实践更好的契合在一起。在我看来,软件工程项目不论成败和好坏,对我们每个参与者都是无比宝贵的。作为有心人,从中我们体会到很多书本上不曾提到过的东西,只要不断地去观察、体会和总结,你会有更多自己的认识、理解和发现。有很多人写书称赞,代码之美、测试之美,其实工程项目也是很美,只是看你能不能更客观地去看待它

    展开全文
  • 以RUP原则实施软件自动化测试第二部分软件测试本文内容包括自动化测试的计划管理自动化测试的最优化设计参考资料本文前部分阐述了企业引入自动化测试的条件,包括组织结构对自动化测试的支持,以及定义自动化测试...
  • 自动化测试的五大原则

    千次阅读 2015-04-26 14:49:06
    1.自动化测试用例范围往往是核心业务、流程或者重复执行率较高的。...4.手工测试用例往往需要回归原点,而自动化测试用例往往是必须的。 5.自动化测试用例和手工用例不同,需要每个步骤都写预期结果。
  • 前端自动化测试实践

    万次阅读 多人点赞 2018-10-31 23:35:49
    通过前端自动化测试,来解放自我
  • 自动化用例如何设计

    千次阅读 2019-05-27 11:26:53
    文章目录【1】自动化用例设计是非常重要的环节【2】自动化用例设计原则【3】在编写自动化用例过程中应该遵循以下几点原则 【1】自动化用例设计是非常重要的环节 用例设计部分,无论是手工测试还是自动化测试,都必须...
  • 自动化测试的利弊

    千次阅读 2017-01-22 10:46:20
    在网上看了很多关于自动化测试的文章,现摘录一二:以下内容引自:2014年自动化的个人感想 自动化技术的应用场所 1、功能回归测试、冒烟测试。 2、数据精度要求高的测试,数据计算、比较、统计测试。 3、简单...
  • 性能自动化测试之LoadRunner场景设计

    万次阅读 2020-02-03 18:19:51
    说明:该篇博客是博主一字一码编写的,实属不易,请...Controller 是 LR 的控制中心,包括场景设计和场景执行。 1.场景设计 场景设计是依据需求制定脚本如何执行的策略,使脚本运行更接近真实用户使用。 主要包括...
  • 自动化测试

    万次阅读 2019-06-14 14:03:45
    软件测试[2],就是在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复查,是软件质量保证的关键步骤。 定义1:软件测试是为了发现错误而在规定的条件下执行程序的过程。 定义2:软件测试是根据软件...
  • 细分自动化测试

    千次阅读 2018-01-11 10:26:54
    ”,关于自动化测试很多测试领域新人可能会有所疑惑,自动化测试没有明确的方向和概念,本文就常见问题带领大家一起揭露软件自动化测试。 常见问题  1.我们需要做什么样的自动化测试?  2.系统是否适合怎样的...
  • 基于sahi的UI自动化测试框架

    千次阅读 2016-06-26 12:24:16
    基于sahi pro excelframework自动化测试框架设计1.概述1.1.开发背景电子印章系统需要进行自动化测试功能,且需要一种易于开发、维护、使用的自动化测试工具。Sahi pro版本相比开源版本已经自带excelframework,既...
  • 自动化测试的七个步骤

    千次阅读 2013-07-18 20:05:55
    【摘要】 我们对自动化测试充满了希望,然而,自动化测试却经常带给我们...本文介 绍自动化测试的 7 个步骤:改进自动化测试过程,定义需求,验证概念,支持产品的可测试性,具有可延续性的设计( design for sustaina
  • 如果说“生活不只有眼前的苟且,还有诗和远方”的话,那么自动化测试可以说是很多测试人员心中的“诗和远方”。 “诗和远方”OR“禁果” 测试自动化,需要持续改进。但由于其本身是一种过于激动人心的想法:用程序...
  • 自动化测试全流程总结

    千次阅读 2021-10-08 19:10:11
    自动化测试 一般是指软件测试的自动化,软件测试就是在预设条件下运行系统或应用程序,评估运行结果,预先条件应包括正常条件和异常条件。 定义 人为驱动测试为转为机器执行过程 应用 软件测试的自动化 工具 ...
  • 有赞分层自动化测试实践

    千次阅读 2016-06-14 10:10:13
    先理一下自动化测试的概念,从广义上来说,一切通过工具(程序)的方式来代替或者辅助手工测试的行为都可以成为自动化。从狭义上来说,通过编写脚本的方式,模拟手工测试的过程,从而替代人工对系统的功能进行验证。 ...
  • 自动化测试框架Cucumber和RobotFramework

    千次阅读 2017-09-18 05:01:14
    自动化测试框架Cucumber和RobotFramework的实战对比 一、摘要自动化测试可以快速自动完成大量测试用例,节约巨大的人工测试成本;同时它需要拥有专业开发技能的人才能完成开发,且需要大量时间进行维护(在...
  • 自动化测试自动化测试生命周期

    千次阅读 2008-04-13 13:47:00
    1.1 自动化测试的定义及概述1.1.1 软件测试的定义与分类 软件测试[2],就是在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复查,是软件质量保证的关键步骤。 定义1:软件测试是为了发现错误而在规定...
  • 软件自动化测试自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常,在设计了测试用例并通过评审之后,由测试人员根据测试用例中描述的规程一步步执行测试,得到实际结果与期望结果的比较。在此过程...
  • 几种常见的自动化测试架构的对比

    千次阅读 2018-04-02 20:01:05
    转载自:http://www.51testing.com/html/03/311303-859188.html常见的自动化测试架构 一个自动化测试架构就是一个集成体系,其中定义了一个特殊软件产品的自动化测试规则。这一体系中包含测试功能函数库、测试数据...
  • 从微软过来的测试经理曾跟我说,自动化测试是一种手段,真正能发现缺陷(Bug)的是手工测试,当时我很理解。随着经验的积累,越来越体会到当时他给我说的那番理论,自动化测试也是有它的局限性的。可悲的是,我所...
  • selenium自动化测试(一)

    千次阅读 2015-07-25 10:45:08
    什么是自动化测试? (广义)一切能代替或辅助手工测试的行为,包括性能测试工具(jmeter,ab);  (狭义)通过工具或编写脚本的方式模拟手工测试的过程,通过回放或运行脚本来自动执行测试用例,从而代替人工对系统的...
  • 自动化测试基本策略

    千次阅读 2009-04-10 16:26:00
    第1章 自动化测试的好处1.回归测试,降低测试成本对于产品型的软件或生命周期长的项目,经常会有新功能的开发或需求的变动,对于新发布的软件功能,大部分都和上一个版本相近或相同,这些功能如果在上一个版本之前...
  • 如果你对此文有任何疑问,如果你也需要接口项目实战,如果你对软件测试、接口测试、自动化测试、面试经验交流感兴趣欢迎加入Python自动化测试技术群:953306497群里的免费资料都是笔者十多年测试生涯的精华。...
  • 聊聊自动化测试框架

    万次阅读 多人点赞 2018-05-29 09:00:15
    无论是在自动化测试实践,还是日常交流中,经常听到一个词:框架。之前学习自动化测试的过程中,一直对“框架”这个词知其然不知其所以然。最近看了很多自动化相关的资料,加上自己的...
  • DEVOPS之自动化测试

    千次阅读 2016-08-15 17:34:20
    除测试基础服务以外,我们没有选择从零开始,而是评估并引入好的开源技术和公司内部其他产品的可用技术,按照我们的自动化测试设计原则和方法进行相应的改造; 比如WebUI测试服务,我们选用了Selenium,为了适应我们...
  • 第五章 自动化测试模型 一个自动化测试框架就是一个集成体系,在这一体系中包含测试功能的函数库、测试数据源、测试对象识别标准,以及种可重用的模块。自动化测试框架在发展的过程中经历了几个阶段,线性测试、...
  • 老外讨论自动化测试开发

    千次阅读 2011-01-11 14:36:00
    关于自动化测试开发的一些讨论
  • 一些自动化测试基本的概念

    千次阅读 2018-08-09 22:13:59
    在此过程中,为了节省人力、时间或硬件资源,提高测试效率,便引入了自动化测试的概念。 为什么用自动化的软件测试 减少软件测试时间与成本改进软件质量 通过扩大测试覆盖率加强手动测试工作 进行手...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 92,323
精华内容 36,929
关键字:

自动化测试设计原则不包括