精华内容
下载资源
问答
  • 用什么工具来编写测试用例比较好呢? 看看从什么时候开始编写测试用例。 当产品人员整理出需求分析文档或者开发人员把项目开发出来,给我们系统文档、部署环境或数据库结构等,此时,我们就可以根据这些...

           在实际的执行测试过程中,编写测试用例的工具,采用的不一,有用Excel表格,Word文档,xmind思维导图,禅道等等工具进行编写。那用什么工具来编写测试用例比较好呢?

           写看看从什么时候开始编写测试用例。     

           当产品人员整理出需求分析文档或者开发人员把项目开发出来,给我们系统文档、部署环境或数据库结构等,此时,我们就可以根据这些文档来开始制定测试计划,设计和编写测试用例。切记,编写测试用例一定要以需求为参考!

           软件测试用例是描述测试过程具体步骤的文档,。

    软件测试用例的编写通常包括以下内容:

    1,测试用例编号;2,测试项目(具体到模块);3,测试标题(描述bug出现的位置,方便快速定位);4,重要级别;

    5,预置条件/前提条件;6,操作步骤;7,预期结果/期望结果;

    8,测试结果/实际结果;9,复现概率等等。

            重要级别也可称为优先级,是对缺陷的严重程度做出的判断。一般分为高(highs)级别,中(mediums)级别,低(lows)级别等。一些管理软件中也分为严重,重要,轻微等级别。只是名称的不同,在实际工作中,我们还要根据项目内容及bug详情来做具体的判断。另外还有一种小版本确认测试,也称为“冒烟测试”,其重要级别要优于高级别,但并不是所有项目必须。

    冒烟测试

    这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后,直接给设备加电。如果没有冒烟,则该组件就通过了测试。在软件中,“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后,冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行,且不会破坏整个版本的稳定性。

    来源

    冒烟测试(smoke testing),据说是微软起的名字。在《微软项目求生法则》一书第14章“构建过程”关于冒烟测试,就是开发人员在个人版本的软件上执行目前的冒烟测试项目,确定新的程序代码不出故障。

    冒烟测试的名称可以理解为该种测试耗时短,仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板基本功能检查。任何新电路板焊好后,先通电检查,如果存在设计缺陷,电路板可能会短路,板子冒烟了。

     

    应用

    冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。

    在一般软件公司,软件在编写过程中,内部需要编译多个版本(Builds),但是只有有限的几个版本需要执行正式测试(根据项目开发计划),这些需要执行的中间测试版本,在刚刚编译出来后,软件编译人员需要进行基本性能确认测试,例如是否可以正确安装/卸载,主要功能是否实现,是否存在严重死机或数据严重丢失等Bug。如果通过了该测试,则可以根据正式测试文档进行正式测试。否则,就需要重新编译版本,再次执行版本可接收确认测试,直到成功。

         

           预置条件是对测试的特殊条件或配置进行说明,操作步骤要求简介不冗余,思路清晰,能快速定位,并且步骤中还要包含设备或操作环境等信息。复现率则是判断该bug是否为必现或者出现的概率有多大,这在测试过程中也十分重要。

     编写测试用例目的

           编写测试用例可以使我们理清思路,避免遗漏,并以此来判断被测软件的各模块是否正常工作,同时可以跟踪测试进展,为测试项目提供参考依据。

    测试用例的设计方法和编写 

    测试用例常见的编写方法

    等价类划分法

           等价类是输入的集合,在每个等价类中选取一定数目的值,选择适当的数据子集来代表整个数据集。等价类分为有效等价类和无效等价类,输入符合条件的值对功能进行检验,输入无效等价类中的值可以找出程序错误的地方。通过降低测试的数目来实现合理的覆盖,覆盖更多的可能数据,以发现更多的软件缺陷。


    边界值分析法

           对输入的边界值或稍大(小)于边界值的值进行分析。使用边界值分析法设计测试用例时一般与等价类划分结合起来,但它不是从一个等价类中任选一个例子作为代表,而是将测试边界情况作为重点目标,选取正好等于、刚刚大于、刚刚小于边界值的测试数据。


    场景法

           通过运用场景对系统的功能点或业务流程的描述,从而提高测试效果。场景法一般包括基本流和备用流,从一个流程开始,通过描述经过的路径来确定的过程。经过遍历所有的基本流和备用流来完成整个场景。

    错误猜测法

          通过直觉和经验对结果进行分析。

    因果法

     因果图一般指鱼骨图

    鱼骨图(又名因果图、石川图),指的是一种发现问题“根本原因”的分析方法,现代工商管理教育将其划分为问题型、原因型及对策型鱼骨图等几类。

    鱼骨图由日本管理大师石川馨先生所发明,故又名石川图。鱼骨图是一种发现问题“根本原因”的方法,它也可以称之为“Ishikawa”或者“因果图”。其特点是简捷实用,深入直观。它看上去有些像鱼骨,问题或缺陷(即后果)标在“鱼头”处。在鱼骨上长出鱼刺,上面按出现机会多寡列出产生问题的可能原因,有助于说明各个原因之间是如何相互影响的。

    问题的特性总是受到一些因素的影响,我们通过头脑风暴法找出这些因素,并将它们与特性值一起,按相互关联性整理而成的层次分明、条理清楚,并标出重要因素的图形就叫特性要因图、特性原因图。因其形状如鱼骨,所以又叫鱼骨图(以下称鱼骨图),它是一种透过现象看本质的分析方法。鱼骨图也用在生产中,用来形象地表示生产车间的流程。

    类型介绍

    A、整理问题型鱼骨图(各要素与特性值间不存在原因关系,而是结构构成关系)

    B、原因型鱼骨图(鱼头在右)

    C、对策型鱼骨图(鱼头在左,特性值通常以“如何提高/改善……”来写)

           因果图在软件测试用例设计过程中,用于描述被测对象输入与输入、输入与输出之间的约束关系。因果图的绘制过程,可以理解为用例设计者针对因果关系业务的建模过程。根据需求规格,绘制因果图,然后得到一个盘点表进行用例设计,通常理解因果图为判定表的前置过程,当被测对象因果关系较为简单时,可以直接使用判定表设计用例,如若不然可使用因果图与判定表结合的方法设计用例。 

     

    逻辑覆盖法

           逻辑覆盖法是基路径是一组独立路径,这组独立路径中的所有路径相互不可替代,其余路径均可由这组路径的某种组合方式来遍历。基路径测试就是设计测试用例来覆盖每条基路径。

    一般步骤:

    ①从被测程序代码生成程序图;

    ②根据程序图计算环复杂度,确定基路径集合的大小(二者相等);

    ③利用“主路径+转向”的策略确定基路径集合,即找到一条从程序入口结点开始,到出口结点结束的路径,该路径应经过尽可能多的判断结点(包括循环结点),然后每次以主路径为基础,每当碰到一个未转向的判断结点,就在该结点处转向一次。

    ④剔除不可行路径,补充其他重要的路径。如:补充执行概率较高的路径;补充可能包含严重缺陷的路径;补充经数据流测试确定具高风险的路径;补充涉及复杂算法的路径

    ⑤根据路径集合确定测试用例,填入测试数据。

    测试用例管理

    测试用例评审

    ⒈测试用例的评审

    测试用例是软件测试的准则,但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审,需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成,也可邀请客户代表参加。

    ⒉测试用例的修改更新

    测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故:第一、在测试过程中发现设计测试用例时考虑不周,需要完善;第二、在软件交付使用后反馈的软件缺陷,而缺陷又是因测试用例存在漏洞造成;第三、软件自身的新增功能以及软件版本的更新,测试用例也必须配套修改更新。

    一般小的修改完善可在原测试用例文档上修改,但文档要有更改记录。软件的版本升级更新,测试用例一般也应随之编制升级更新版本。

    如何管理测试用例

    • 原始的excel管理
    • 专业的项目管理工具(eg:ALM、禅道、testlink、Bugzilla、JIRA)一般都为web格式

    ALM

           所谓应用生命周期管理(ALM),是利用计算机辅助软件工程(CASE tool)的软件工具,一个组织通常为多个客户生产软件,而客户的要求也是多样化的。一种软件生命周期往往不能适合所有的情况,因此组织可以规定多种软件生命周期供项目使用。

    ALM定义

           ALM(application lifecycle management)应用程序生命周期管理!

           这些软件生命周期一般从软件工程文献中获得,并可加以修改,使之适于组织的情况。在制定项目定义软件过程时,这些软件生命周期可以和组织标准软件过程结合在一起使用。以标准的流程管理方式,协助降低软件开发过程中人为造成的开发瑕疵,特别适用于大型应用的开发。包括HP、Borland、Serena、IBM等,都有提供ALM产品。

           ALM(adaptive logical module)在FPGA中指自适应逻辑模块!

     

    Testlink

          TestLink 是基于web的测试用例管理系统,主要功能是测试用例的创建、管理和执行,并且还提供了一些简单的统计功能。

          TestLink用于进行测试过程中的管理,通过使用TestLink提供的功能,可以将测试过程从测试需求、测试设计、到测试执行完整的管理起来,同时,它还提供了好多种测试结果的统计和分析,使我们能够简单的开始测试工作和分析测试结果。 TestLink 是sourceforge的开放源代码项目之一。作为基于web的测试管理系统,TestLink的主要功能包括:

    测试需求管理

    测试用例管理

    测试用例对测试需求的覆盖管理

    测试计划的制定

    测试用例的执行

    大量测试数据的度量和统计功能。

          目前在XLS导入上存在缺陷,但可以使用第三方的“Testlink Convert”工具实现XLS/TXT/XML导入导出。

     

    实现功能

    1 根据不同的项目管理不同的测试计划,测试用例,测试构建相互之间独立

    2 根据树状的项目,组件,分类,测试用例,设计测试用例

    3 可以基于关键字搜索测试用例

    4 可以将现有测试用例简单修改后复用

    5 同一项目可以制定不同的测试计划,然后将相同的测试用例分配给该测试计划(可以实现测试用例的复用,筛选)

    6 可以设定执行测试的状态(通过,失败,锁定,尚未执行),失败的测试用例可以和 bugzilla 中的 bug 关联,每个测试用例执行的时候,可以填写相关说明

    7 测试结果分析(可以实现按照需求,按照测试计划,按照测试用例状态,按照版本,统计测试结果)

    8 自定义角色,通过角色控制用户权限

    9 测试结果可以导出为 excel 表格

    10 测试用例可以导出为 csv , html 格式

    11 通过超链接,可以将文本格式的需求,计划关联

    12 可以将测试用例和测试需求对应。测试可以根据优先级指派给测试员,定义里程碑

    缺陷

    1 不能根据优先级筛选用例,如果需要优先级,必须通过关键字来实现,比较麻烦

    2 不能设定测试用例的种类,如果需要必须通过关键字来实现,更麻烦,也不太现实

    3 如果测试用例需要大量的数据,创建测试用例时不方便

    优点

    1、开源

    2、免费

    3、web界面

    4、简单易学

         

           综上所述,写测试用例的目的是为了,更好的指导测试,作为测试人员之间沟通的文档,分析与追踪软件缺陷,觉得用哪个工具、软件来写测试用例比较好,这个就因人而异了。 

     

    展开全文
  • 以XXAPP的功能为模板,展示怎么使用等思维导图工具快速编写测试用例,大家可以作为参考
  • 1. 系统测试分类 测试类型包括单元和单元集成测试、功能测试、性能测试、安全测试、可用性测试、压力测试、易用性测试、可维护性测试、可扩展性测试、可重用性测试等类型。...4. 测试用例设计 5. 测试方案
  • 软件测试用例管理工具比较软件测试工具名综述优点缺点备注TestManagerRational测试解决方案中推荐的测试用例管理工具。1.功能强大。2.文件夹形式的管理,可以对测试用例无限分级。3.可以和Rational的测试工具robot、...
  • 测试用例管理工具有哪些?

    千次阅读 2020-12-07 18:13:41
    目前市面上的测试管理工具有很多,功能基本上都大同小异,要完成一款测试用例工具的选型,首先要需求明确,就是说你要这个测试管理工具干什么? 最终想要达到什么目标?才能进一步完成对测试管理工具的选型。 除此...

    目前市面上的测试管理工具有很多,功能基本上都大同小异,要完成一款测试用例工具的选型,首先要需求明确,就是说你要用这个测试管理工具干什么? 最终想要达到什么目标?才能进一步完成对测试管理工具的选型。

    除此方法外,我们团队调研对比了当前市场上的测试用例管理工具以供参考,以及工具的选择经验供借鉴。

    一、明确需求

    测试管理工具大体上分俩类,一类就是面对QA的功能测试,主要是满足测试人员对用例的维护,测试计划的建立,用例的执行,以及生成测试报告等。

    另一类就是面对开发人员的接口测试,功能测试,压力测试,性能测试,以及自动化测试,到最后的集成到流水线中,有的公司这块由专门的测试人员来做,而这是2种不同的使用场景,对工具的要求也大不相同,在不同的企业内,这2种场景可能都是由一个测试团队来完成,也可能是测试人员只是负责功能的实现的测试,开发人员来完成接口测试,功能测试,压力测试,性能测试,以及自动化测试,这完全取决于团队的工程化水平及人员配置。

    聊到测试,有的人说用Excel就足以,通过Excel来维护测试用例,每次产品发布,按照Excel里面的用例,把产品功能过一遍,这样做也没问题,但是你想过没有,随着项目的迭代,复杂度的增加,Excel的缺点就显而易见了,工作的效率及其低下,并且不能多人合作,用例的版本维护乱七八糟的,并且无法与缺陷做到实时关联,可以说用Excel来测试的团队,是那种及其小的团队,一个测试人员而已,或者没有专门的测试人员,由产品来代劳,我们就把它称为广义测试的第一阶段吧。

    而在一些稍具规模的公司,测试团队大概在20人以内的,基本上都会选择一个成熟的测试管理工具来管理整个产品的质量,达到多人协作,包括用例评审,讨论,版本,测试和需求,缺陷的关联,测试报告 以及后续的统计分析,能更好的支持反馈和跟踪,持续提高产品的质量,保证产品的稳定性,我们就称为广义测试的第二阶段吧,大多数的公司基本上也都处于这个阶段,这个阶段的工具非常多,功能也不尽相同,笔者就目前国内做的比较好的几款产品做了一些简单的功能分析,供大家参考
    在这里插入图片描述

    二、国内几款好的产品的对比分析

    通过笔者的比对,目前看 PingCode 产品的 Testhub 功能是比较全面,并且用户体验非常好的,但是它在测试自动化,以及Open Api 这块基本上都不支持,这块是弱于Jira的,这就回到前面的问题了,你要用这个工具来做什么的,达到什么目的?

    从这点出发,Testhub 完全能满足我的需求,还有一点让我心动的地方就是 Testhub 是支持用例自定义,这对于对扩展有情结的人来说非常重要,因为业务是多变的,多给自己留点空间,同时用例导入这块支持脑图的导入也是非常吸引我的。

    Jira在测试自动化,以及OpenApi做的比较好,这是其它几个产品不具备的,但是Jira对本土化的支持不是很友好,行为习惯和国内的用户有一些差距。

    禅道是开源的,用户可以自己下载搭建,但有一定的使用门槛,笔者不太喜欢它的界面风格,当然对于有代码控的人除外。

    ones现在还是收费的,试用版本有诸多的限制

    上图中的功能比对也是以笔者所在的公司的业务决定的,视角也可能不是很全面,需要这方面的工具的同学还是要自己亲自注册比对,做出自己最好的选择。

    聊到这,除了工具的对比之外,大家会觉的测试应该还有更高级的阶段,没错,你想的是对的,性能测试,压力测试,负载测试,自动化测试,以及集成到流水线,我们把这个称为广义测试第三阶段吧,笔者目前所就职的公司基本上是处于这个阶段的,但在性能测试,压力测试这块基本上是0,也可能是目前的数据量和用户量没达到一定的级别的原因吧,也是需要持续改进的。

    经过一段时间的调研和产品的试用,最终我们选用了PingCode TestHub测试管理工具,带着好奇心并对PingCode这个平台的其它产品做了一些研究,总之他们的产品非常全面,是一款支持研发全流程的产品,在研发的工具链,通过敏捷开发,测试管理,项目集,知识库,以及其它的多元化产品来服务研发的全流程,从而形成DevOps的闭环,持续迭代,持续发布,持续交付。

    三、使用经验总结

    目前笔者就对正在使用的PingCode 的 Testhub 做一些总结性的介绍

    • 用户体验友好,界面清爽,适合国内企业的用户风格
    • 功能全面,全部支持我们定义的测试第一阶段的所有功能
    • 作为研发全流程的一环,完美实现了和其它研发产品的对接,互联互通
    • 官方的发布计划,下一步会完全支持测试自动化,对于想支持这块的用户也不用担心了

    一个高质量的产品,测试是必不可少的,一个好的测试管理工具对提升研发效能也至关重要,笔者就Pingcode Testhub 产品的一些使用心得做简单的介绍

    • 创建用例库:
      用例库是用来存储所有的用例,对用例统一的管理,按照不同的项目,对应不同的用例库,在研发体系中,有一些公用的用例,我们也可以把这些用例放到一个公共的用例库里面,通过共享用例库的方式来达到公用,从而减少用例重复维护的工作量

    在这里插入图片描述

    • 创建测试用例:
      你可以按照所测试的功能点建立对应的测试用例,书写用例步骤,设置用例的级别,维护人,用例的类型,备注等,用例的步骤支持复制,同时用例支持连续创建,这个功能点非常的爽

    在这里插入图片描述

    • 导入测试用例 : 支持 Excel 和脑图导入,脑图的导入这个功能很赞

    在这里插入图片描述

    • 用例列表的维护:当你创建了很多用例了,就需要一个维护页面,在这个界面,可以批量设置维护人,删除用例,把用例移动,复制到其它用例库,同时还支持各种条件的搜索,功能非常的全面

    在这里插入图片描述

    • 用例和用户故事关联:这里支持测试用例和用户故事的关联,就是说你这个用例是测试那些用户故事的场景的,并且能很方便的去查看所关联的用户故事的信息,状态,等
      在这里插入图片描述
    • 新建用例评审:在有一些场景,一个测试人员写完的测试用例,并不是立马就按照所写的用例来测试的,可能会有一个评审的环节,大家通过评审,共同去梳理这些测试用例的规范以及全面性,提高测试的能力
      在这里插入图片描述
    • 评审结果展示:这个界面就是展示评审通过的用例,评审通过的用例是得到大家一致认可的
      在这里插入图片描述
    • 测试计划:用例维护好了之后,我们就可以通过测试计划来完成一次的功能测试了,也就是说,你要测那些功能,就通过一个测试计划来把所测的功能对应的用例规划进来,测试计划的建立,具体取决于每个团队的流程。
      在这里插入图片描述
    • 执行用例:我们按照测试计划规划好测试用例之后,就是具体的一个个的来测试功能来,填写在真实的测试过程的实际值是不是符合用例的期望值,是不是功能有缺陷,测试是否通过,等等
      在这里插入图片描述
    • 用例与缺陷关联:
      如果你在测试的过程中发现了缺陷,你可以立马在执行用例的上面创建一个缺陷,提交到缺陷系统中,同时这个缺陷和这次的测试关联起来,做到可以追溯,开发人员修正缺陷之后,测试人员也可以进一步的回顾测试。
      在这里插入图片描述
    • 用例的自定义配置: 这个功能非常强,用户可以定义自己需要的任何场景的测试用例,支持定制化
      在这里插入图片描述
    • 用例的模板:
      对于测试人员来说,有些测试用例测试步骤大体上是一样的,只是有一些细微的差别,这样用户在写完一个测试用例之后,可以把它保存称模块,在书写其他用例的时直接使用模板,然后改一改就可以了,非常节省时间,提高测试效率
      在这里插入图片描述
    • 输出完整的测试报告:对于一个测试团队的leader来说,他可能更关心,一次测试计划的整体报告,测试的覆盖率,缺陷的统计,以及每个测试人员测试了多少用例。
      在这里插入图片描述

    更多的使用细节,就不一一介绍了,总之好用还免费,有兴趣的同学注册PingCode,自己试用一下吧。

    展开全文
  • 在软件测试中,测试用例对被测软件的覆盖率,是发现软件缺陷的重要前提之一.本文采用软件工程实验方法,基于Defects4J数据集,...该研究对于如何使用这两种工具生成高覆盖率的测试用例,以及对工具的改进具有参考价值.
  • 测试行业使用testlink作为测试管理工具是普遍的现象,但测试用例导出不能导出格式 化的excel格式的用例,本工具实现了这个功能。将testlink导出的默认XML格式的用例解析成标准格式 的excel文件。
  • pict测试用例组合工具

    2021-01-15 13:31:22
    用于设计测试用例,可实现全面覆盖 访问以下地址学习使用工具:https://blog.csdn.net/qq_39184753/article/details/112661144?spm=1001.2014.3001.5502
  • 测试用例转换工具

    2019-01-09 15:03:30
    很好用的一个小工具,可以把已经编写好的excel用例转换为testlink认可的xml文件
  • 安全测试分析的来源主要是需求、系统设计、安全工程师安全建议。 采用的测试策略:工具扫描,手工测试.安全测试用例设计可参考安全测试用例库.
  • TestDirectortestDirector软件测试工具中用TestDirector生成的测试用例用TestDirector生成的测试用例有两种样式:FullPage和TabularTestDirector中没有关于测试用例的目的以、该用例的前提条件等字段,因此可以在...
  • 件敏捷测试是否写测试用例 敏捷测试是否写测试用例?答案多种化如果是你,你会选用还是不用呢? 软件测试时代风起云涌,问题虽小,意义却大,让大家一起学习一起探讨! 经过大家的水深火热的探讨答案出来了,但是各...

    件敏捷测试是否写测试用例

    敏捷测试是否写测试用例?答案多种化如果是你,你会选用写还是不用写呢?

    软件测试时代风起云涌,问题虽小,意义却大,让大家一起学习一起探讨!

    经过大家的水深火热的探讨答案出来了,但是各有各的想法各有各的不同,但我想他们的所想和所论对于大家都是有帮助的,大家可以看一下这个讨论题,希望在技术上能帮到大家一些。

    LoveTT : 我觉得敏捷测试不需要写测试用例;

    所谓敏捷,就是要快准狠,快速的找到系统中存在的问题,高效率的完成测试任务!

    谁来跟我辩论?

    傲气凌云 : 我认为需要写,因为所有的用例都是人类靠思维来编写的,不是凭空出现的。就算是敏捷性测试,也是需要记录的。

    tigerbbs : 在敏捷开发中,测试管理者不可能像传统的项目测试一样制定详细的测试计划,那怎样执行测试呢?以下是我总结的一些琐碎经验: 在敏捷开发中整个团队都是测试人员,一起需要对产品质量负责,测试管理人员需要指引大家共同测试,需要发动起大家一起执行测试,而不仅仅是测试人员的事情,这同时也要求整个团队中每个成员对自己的产品了如指掌,测试人员需要共同参与产品的设计和需求分析,在敏捷开发中需求在不断变化,你不可能等着完整的需求文档进行测试需求分析,当产品定义和需求不断的细化时,测试分析也要不断的细化,我很喜欢让测试人员去绘制业务流程图,以及整理功能列表进行测试分析,因为在绘制业务流程图中你可以发现很多的逻辑问题,和产品定义问题,可以即时的和产品定义人员、需求人员进行沟通,立马改进产品设计,敏捷测试中,根据业务流程图或测试分析图书写主要测试用例就行了,你根本就没有时间能面面俱到去维护那么的测试用例,更何况需求和产品定义一直在变化一定要自动化测试,自动化测试脚本中要写好注释,这是测试用例的体现,也便于读取在测试之前制定好测试方案,但测试执行的时间很难控制,一定要熟知数据库。

    LoveTT : 楼上的傲气凌云 有点狡辩了,混淆视听,人类的精髓很多,马克思主义毛泽东思想,都是人类的精华,但是这些老前辈都还说,具体问题具体分析呢,而你一概而论,我觉得站不住脚!我觉得阁下还是好好看看什么是敏捷开发,和敏捷测试再来发表见解吧!否则贻笑大方就不好了!

    test110 : 肯定得写哈,那是测试的依据。

    敏捷宣言:

    个体和交互比过程和工具更有价值;

    能工作的软件比全面的文档更有价值;

    顾客的协作比合同谈判更有价值;

    及时响应变更比遵循计划更有价值。

    并非每个企业都能严格按敏捷的相关开发方法进行项目管理,例如测试驱动、XP、SCRUM等。也并非都需要按这些方式管理才能实现敏捷。只要我们理解了敏捷的原则和精髓,我认为很多方法、很多地方都可以应用敏捷的思想,实现敏捷的管理。

    测试用例的设计是其中一项。

    测试用例的粒度

    测试用例可以写得很简单,也可以写得很复杂。最简单的测试用例是测试的纲要,仅仅指出要测试的内容,如探索性测试(Exploratory Testing)中的测试设计,仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样,会指定输入的每项数据,期待的结果及检验的方法,具体到界面元素的操作步骤,指定测试的方法和工具等等。

    测试用例写得过于复杂或过于详细,会带来两个问题:一个是效率问题,一个是维护成本问题。另外,测试用例设计得过于详细,留给测试执行人员的思考空间就比较少,容易限制测试人员的思维。

    测试用例写得过于简单,则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行“设计”,只是把需要测试的功能模块记录下来而已,它的作用仅仅是在测试过程中作为一个简单的测试计划,提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求,检验需求,并把对软件系统的测试方法的思路记录下来,以便指导将来的测试。

    大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键,也将影响测试用例设计的效率和效果。我们应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。

    软件是开发人员需要去努力实现敏捷化的对象,而测试用例则是测试人员需要去努力实现敏捷化的对象。要想在测试用例的设计方面应用“能工作的软件比全面的文档更有价值”这一敏捷原则,则关键是考虑怎样使设计出来的测试用例是能有效工作的。

    基于需求的测试用例设计

    基于需求的用例场景来设计测试用例是最直接有效的方法,因为它直接覆盖了需求,而需求是软件的根本,验证对需求的覆盖是软件测试的根本目的。

    要把测试用例当成“活”的文档(Effective Software Testing : 50 Specific Ways to Improve Your Testing – Elfriede Dustin),因为需求是“活”的、善变的。因此在设计测试用例方面应该把敏捷的“及时响应变更比遵循计划更有价值”这一原则。

    不要认为测试用例的设计是一个阶段,测试用例的设计也需要迭代,在软件开发的不同的阶段都要回来重新审视和完善测试用例。

    测试用例的评价

    测试用例设计出来了,质量如何,如何提高测试用例设计的质量?就像软件产品需要通过各种手段来保证质量一样,测试用例的质量保证也需要综合使用各种手段和方法。

    测试用例的检查可以有多种方式,但是最敏捷的应当属临时的同行评审。我认为同行评审,尤其是临时的同行评审,应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”,要强调测试用例设计者之间的思想碰撞,通过讨论、协作来完成测试用例的设计,原因很简单,测试用例的目的是尽可能全面地覆盖需求,而测试人员总会存在某方面的思维缺陷,一个人的思维总是存在局限性。因此需要一起设计测试用例。

    除了同行评审,还应该尽量引入用户参与到测试用例的设计中来,让他们参与评审,从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛,关键在于你怎样定义测试,如果测试是对产品的批判,则顾客应该指最终用户或顾客代表(在内部可以是市场人员或领域专家);如果测试是指对开发提供帮助和支持,那么顾客显然就是程序员了。

    获取更多相关知识访问如下链接
    https://edu.csdn.net/lecturer/3215
    https://edu.csdn.net/course/detail/31909
    https://edu.csdn.net/course/detail/30898
    https://edu.csdn.net/course/detail/25768
    https://edu.csdn.net/course/detail/22948
    https://edu.csdn.net/course/detail/28104
    https://edu.csdn.net/course/detail/28103
    https://edu.csdn.net/course/detail/27231

    因此,参与到测试用例设计和评审中来的人除了测试人员自己和管理层外,还应该包括最终用户或顾客代表,还有开发人员。

    测试用例数据生成的自动化

    在测试用例设计方面最有希望实现自动化的,要当属测试用例数据生成的自动化了。因为设计方面的自动化在可想象的将来估计都很难实现,但是数据则不同,数据的组合、数据的过滤筛选、大批量数据的生成等都是计算机擅长的工作。

    很多时候,测试用例的输入参数有不同的类型、有不同的取值范围,我们需要得到测试用例的输入参数的不同组合,以便全面地覆盖各种可能的取值情况。但是全覆盖的值域可能会不可思议地广泛,我们又需要科学地筛选出一些有代表性的数据,以便减轻测试的工作量。在这方面可利用正交表设计数据或成对组合法设计数据。

    可利用一些工具,例如TConfig、PICT等来产生这些数据。

    在性能测试、容量测试方面,除了设计好测试用例考虑如何测试外,还要准备好大量的数据。大量数据的准备可以使用多种方式:编程生成、SQL语句生成(基于数据库的数据)、利用工具生成。

    工具未必能生成所有满足要求的数据,但是却是最快速的,编程能生成所有需要的数据,但是可能是最复杂、最慢的方式。所以应该尽量考虑使用一些简单实用的工具,例如DataFactory等。

    seanhe : 先抛观点:需要写测试用例

    先看测试用例是什么,也就是我们打算进行的测试执行的具体内容

    测试用例可以分级别:如大纲型、方案型、具体操作数据型,但是根本一点就是要使测试过程有序的进行,尽量少做无必要的重复。

    敏捷宣言是什么?拥抱变化

    拥抱变化不代表着杂乱无章,代码即文档,不代表着代码没有注释,所有人都靠代码去看逻辑。

    敏捷下测试是需要规划的,用例是需要书写的,但是书写的用例并不应该是我们通常意义上非常详尽的测试用例,而可能演变成单元测试框架或者功能自动测试框架,或者测试大纲。

    总之,测试过程是需要规划的,在有效规划的前提下,尽量少的做无用工作

    LoveTT : 楼上的Test110写了很多关于测试用例设计的东西,写道粒度问题!我不知道这些你是从哪里抄来的,但是我觉得用例这样写没有问题,但是敏捷测试作为一种特殊的测试类型如”tigerbbs“所说 因为敏捷开发和测试的快捷性和多变性,导致测试的设计变得困难,或者根本就没办法实现”你根本就没有时间能面面俱到去维护那么的测试用例,“正如文章中提到,所以我觉得楼上的论据站不住脚,如果说一般的测试类型,应该没有问题的!

    魅力彩虹 : 我认为测试用例是一定要的,没有用例怎样做到快和准?请问LOVETT一个系统中你能记住那里测过那里没有测过?等到新的版本出来,恐怕就会乱套了吧,何来快准狠?敏捷有从何体现?

    test110 : CASE也有简单和复杂呀~~`针对不同的项目也可以具体考虑的,但是肯定是必须写的

    LoveTT : 楼上的说道用例设计过程中的跟踪,说道那些是测试了那些是没有测试,这个我们完全可以通过功能点,或者流程图等跟踪方式进行跟踪,只要我所有的需求被覆盖被测试,就可以了!

    shinnoshi : 敏捷测试需要写测试用例,既然是敏捷测试,就应有与其相衬的敏捷测试用例。

    敏捷测试同样需要合理的分析,快速、准确并不应建立在毫无条理的测试中。敏捷不是抛弃所有只注重效率。

    test110 : 其实我们在这里说的都是理论的,老大弄个模拟环境吧 我们实际做下就得了的 我很现实的,实践才是真知

    LoveTT : 楼上的又在教条主义,和本本主义,你为什么说测试必须写测试用例呢!

    另外敏捷测试作为一种快速的测试方式,我们没有必要把时间花费到用例设计的过程中,但是我们当然需要设计,但设计的不是测试用例,而是细化的需求!

    test110 : 设计case都是测试流程中的一部分的,我们平时测试项目也是按照流程去测试的,也就是说流程制约着我们去测试的,如果我们把测试流程做得很细化了的,那我们的测试就是很精确的,我们得一步一步的走,设计case必须是测试流程中的一部分

    实际还有一个问题的,就是时间!我们在前期就把时间放在case的设计上的,到我们实际测试的时候就会节约很多时间的;如果你一边测试一边在自己大脑中设计case肯定会浪费时间的,而且还会造成自己和项目组内的人一种紧张的气氛。 大家可以对比下的,case在前期设计和在测试过程中设计,那个更节约时间!那个 效率更高的

    pi_pi : 个人觉得不管是为了告诉领导你做了那些东东,还是自己记录分析自己的测试思路和策略也好,暂且不管用例的简易复杂程度有多少,这个用例肯定是需要写的。

    魅力彩虹 : 没有用例的测试是不可行的,首先你的测试是不是有效的验证了需求呢?要有一个测试的执行步骤和执行数据,通过评审之后才能够成为可行的测试。否则只是个人进行的测试怎样判定是系统真的有缺陷还是测试的过程或测试的理解存在问题?总不能等到发现问题后再来讨论测试步骤及测试数据你是否合理吧?即使可以,又怎样能够正确的描述出当时的操作步骤呢?

    angel0527 : 在对一个系统进行测试之前,都会去找测试点,再从测试点整理出测试用例。只是所整理用户的简单复杂程度不同。

    如果不去整理测试用例,就没有办法明确是否将该进行测试的点都已经测试完。有可能会做许多重复的工作。这样就谈不上敏捷了。

    shinnoshi : 如果说没有必要写测试用例,其实最终想说的就是时间,写测试用例需要时间,需要大量的时间。

    其实不然,清晰的了解需求,用简洁的语言,可以是符号语言,从代码级出发,与开发同步,直到最终的组件完成。如果说你在开发人员写代码的时候都无法利用,那你所谓的时间真的很不够。随着开发的继续,反复的回归测试,如若不是记忆力超群,测试已经达到什么程度,你能给出一个准确的答案吗?
    获取更多相关知识访问如下链接
    https://edu.csdn.net/lecturer/3215
    https://edu.csdn.net/course/detail/31909
    https://edu.csdn.net/course/detail/30898
    https://edu.csdn.net/course/detail/25768
    https://edu.csdn.net/course/detail/22948
    https://edu.csdn.net/course/detail/28104
    https://edu.csdn.net/course/detail/28103
    https://edu.csdn.net/course/detail/27231
      LoveTT : 请16楼的朋友注意,你说的一你们平常的工作,第一点,你们做的不是敏捷开发,当然你们也不是敏捷测试,你们按部就班没有问题,但是我们今天的辩题是”敏捷测试“作为现在一个新的概念,或者一种新的方法,正在为大家研究,所以你的经验主义不值得一提

    LoveTT : 一看你就是科班出身,是做质量管理的吧! 什么事情都看得这个规矩,我觉得规矩没有错,但是规矩制约了发展就是错误了,你所谓的评审,审核

    LoveTT : 一看你就是科班出身,是做质量管理的吧!

    什么事情都看得这个规矩,我觉得规矩没有错,但是规矩制约了发展就是错误了,你所谓的评审,审核,在一般的测试过程中是没有问题的,而在敏捷测试过程中,他的测试团队覆盖面很广,可以快速的识别问题并且修改问题,要是等待你的评审恐怕黄花菜都凉了!

    魅力彩虹 : 楼上LOVETT的观点我不同意,你老说这个教条,那个是平时的工作,不是做敏捷测试。那请问一下你做过敏捷测试吗?你的观点依据又是什么呢?

    LoveTT : 根据我这个测试新手孜孜不倦的学习,倒是接触过一些,记得前几天IBM刚开了一个什么大会好像这个论坛中也有报道,我演戏了他的整个敏捷开发的过程,以及他的质量控制方法,所以我以此为依据说出上述论断,大家要是有争议,可以看IBM关于敏捷开发的文章

    魅力彩虹 : 评审用例不仅是规矩的问题,用例不去评审就盲目的执行,怎样保证执行的正确性?发现了BUG怎样反应给开发人员?有些用例你认为覆盖了需求,你有怎样知道自己执行的用例真正体现了需求的定义?如果根据个人临时在大脑中想到的用例来测试系统,测试的有效性和以体现

    LoveTT : 《Agile Testing - What is it? Can it work?》和《Agile Testing Challenges》

    大家可以看一下这个两本书!

    所以我觉得敏捷测试有没有设计测试用例,要不要评审,这个是两个概念,楼上的跑题了

    傲气凌云 : 但是在你工作中,你可以这么做吗?即便是公司就你一个测试人员,也是需要编写测试用例的。同样,也就伴随着评审等一系列活动。

    shinnoshi : 敏捷是少文档,少流程,多沟通,使开发与测试更加紧密。不是不需要文档,不需要流程,不需要测试用例。

    请问你提及的测试通过,开发完毕是用什么来衡量的?

    ash : 敏捷的不是反文档的。

    测试用例最终生成也会以文档数据方式存在,并且是显性知识,是可以传播、共享和继承的。(不清楚看下面解释)

    我们应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识,知识具备两种形态,显性的和隐性的,传统的观念是尽量把隐性知识显性化,即文档化,而忽略了这其中的代价(特别是更新同步文档的代价)。

    因此,在实施敏捷的时候,需要在团队内明确哪些知识是必须显性的,这些知识可以通过文档交流。哪些知识是可以隐性的,这些知识则完全可以通过口头的方式进行交流,以达到沟通的最佳效率。

    new.bug : 个人觉得,敏捷测试只是相对而言的,比如让你测试一个比较复杂的系统,功能很多,那你说不用测试用例怎么比较有条理的进行测试?
    获取更多相关知识访问如下链接
    https://edu.csdn.net/lecturer/3215
    https://edu.csdn.net/course/detail/31909
    https://edu.csdn.net/course/detail/30898
    https://edu.csdn.net/course/detail/25768
    https://edu.csdn.net/course/detail/22948
    https://edu.csdn.net/course/detail/28104
    https://edu.csdn.net/course/detail/28103
    https://edu.csdn.net/course/detail/27231

    展开全文
  • : 轻量级的跨平台测试自动化工具,可以以业务语言编写测试用例。 用例生成 : 基于模型的测试用例生成框架 : 微软公司开发的pairwise testing的用例生成工具 用例和bug管理 : 开源测试用例管理,测试计划,测试执行,...
  • JIRA管理工具,如何在JIRA上编写测试用例以及测试用例的标准规范
  • 测试行业使用testlink作为测试管理工具是普遍的现象,但测试用例导出不能导出格式 化的excel格式的用例,本工具实现了这个功能。将testlink导出的默认XML格式的用例解析成标准格式 的excel文件。 testlink 测试用例...
  • 测试用例管理,测试报告管理,缺陷来源,缺陷情况分析
  • 按照模板自动生成测试用例。exe文件,免安装。默认自带模板,模板可以自定义。 演示视频:https://www.bilibili.com/video/BV1e5411b7hx/ 适用于测试工程师、文档工程师、cnas/cma质量保障人员等。 默认授权至2022年...
  • PICT-测试用例生成工具

    千次阅读 2021-08-12 23:23:52
    文章目录PICT-测试用例生成工具1、什么是PICT2、怎么2.1、安装PICT,下载好安装包PICT 3.3 直接按提示一步步安装即可。2.2、参数文件格式2.3、在PICT安装目录下,新建.txt文件,编辑上你要测试的字段,参数要求,...

    PICT-测试用例生成工具

    作者:华姐

    1、什么是PICT

    PICT(Pairwise Independent Combinatorial Testing )工具就是在微软公司内部使用的一款成对组合的命令行生成工具,已经对外提供,可以在互联网上下载到。

    成对组合覆盖这一概念是Mandl于1985年在测试Aad编译程序时提出来的。Cohen等人应用成对组合覆盖测试技术对Unix中的“Sort”命令进行测试。测试结果表明覆盖率高达90%以上。可见成对组合覆盖是一种非常有效的测试用例设计方法。但是实际工作过程中有成对组合量太大,PICT就很好的解决了这一难题。

    PICT 可以有效地按照两两测试的原理,进行测试用例设计,在使用PICT时,需要输入与测试用例相关的所有参数,以达到全面覆盖的效果·

    2、怎么用

    2.1、安装PICT,下载好安装包PICT 3.3 直接按提示一步步安装即可。

    2.2、参数文件格式

    也叫模型文件,至少包括一个部分,最多包括三个部分:

    parameter definitions
    [sub-model definitions]
    [constraint definitions]
    

    首先是参数定义部分,然后是可选的子模型约束部分(如果使用)区段之间不需要任何特殊的分隔符。空行可以出现在任何地方。可以通过在行前面加“#”字符来包含注释

    2.3、在PICT安装目录下,新建.txt文件,编辑上你要测试的字段,参数要求,实例如下:

    username:手机号,邮箱,昵称,非空字符,空
    password:正确密码,错误密码,空
    captcha:正确验证码,错误验证码,超时正确验证码,空
    save_password:是,否
    

    在这里插入图片描述

    2.4、Windows 打开cmd进入命令窗口:

    方法一:

    1)使用命令进入pict安装所在的盘
    在这里插入图片描述

    2)进入PICT安装的文件目录
    在这里插入图片描述

    方法二:

    直接在安装目录下,路径输入cmd按回车键
    在这里插入图片描述

    3)输入命令:pict test_demo.txt 产生测试用例
    在这里插入图片描述

    4)导出产生的测试用例,操作如下:

    4.1:输入命令在这里插入图片描述
    Excel文件可以在PICT安装目录下创建好Excel文件,即可以导出
    在这里插入图片描述

    3、其它的命令参数选项含义如下:

    / o :N - 组合数,默认值为2
    / d :C - 值与值之间的分隔符,默认为逗号(,)
    / a :C -别名间的分隔符,默认是管道符(|)
    / n :C - 无效数值或者是非法数值的前缀,默认值为(~)
    / e :file - 定义种子文件,作用是可以指定组合方式
    / r [:N] - 随机生成,N -种子
    / c - 参数的值完全区分大小写
    / s - 显示模型统计数据
    

    4、实际应用

    4.1、场景1

    需求描述:假设一个web系统,需要做兼容性测试,该系统兼容不同操作系统,数据库和web服务器软件,并且客户端有许多的浏览器:

    浏览器:fireFox、IE、Chrom
    数据库:MySQL、oracle、DB2
    应用服务器:nginx、,Apche、Tomcat
    操作系统:Windows Server、Unix、Linux
    

    根据上述需求,提取测试的因子和水平值分析:

    浏览器:fireFox,IE,Chrom
    数据库:MySQL,oracle,DB2
    应用服务器:nginx,Apche,Tomcat
    操作系统:Windows Server,Unix,Linux
    

    以上4因子3水平用全等价测试用例数为3^4=81

    用PICT设计过程:

    1. 新建记事本,复制以上因子和水平值,格式如下
      在这里插入图片描述

    2. 运行PICT,得到用例组合:
      在这里插入图片描述

    4.2、场景2

    需求描述:邮驿付项目—商户自动开通D0功能,需要满足条件:机构设置商户进件自动审核、人工审核,机构D0配置,开通(“商户自动开通D0”),是否补贴为否,风控管理商户提现白名单有效,账户结算类型3种。

    根据上述需求,提取测试的因子和水平值分析:

    商户类型:企业,个体商户,政府组织及事业单位,其他机构组织,小微商户
    账户结算类型:对公,法人对私,非法人对私
    机构D0配置("商户自动开通D0"):开,关
    是否补贴:是,否
    商户进件审核:自动审核,人工审核
    商户提现白名单:失效,生效
    

    用PICT设计过程:

    1.新建记事本,复制以上因子和水平值,格式如下
    在这里插入图片描述

    2.运行PICT,得到用例组合:
    在这里插入图片描述

    展开全文
  • 一最近几天,连续有几个同学在微信中问我类似的问题「我拿到一个 XXX 需求,应该如何开始写测试用例呢?」我没有问需求细节,问了我也不一定明白,但这个问题是可以直接从方法论角度进行解决,所以我给的答复都是「...
  • 流量工具测试用例

    2018-10-27 13:10:15
    测试用例(Test Case)是将软件测试的行为活动做一个 测试用例 测试用例 科学化的组织归纳,目的是能够将软件测试的行为转化成可管理的模式;同时测试用例也是将测试具体量化的方法之一,不同类别的软件,测试用例是...
  • 1、Testlink专有测试用例模板。 2、支持excel2003和excel2007 1、Testlink专有测试用例模板。 2、支持excel2003和excel2007
  • Xmind也可以写测试用例

    千次阅读 2020-08-24 17:19:03
    大家可能知道 Excel 可以写测试用例,但是 Xmind 是一款什么软件呢?它为可以代替 Excel 帮助我们撰写测试用例呢? 1.测试用例什么? 一组由前提条件、输入、执行条件、预期结果等组成,以完成对某个特定需求或者...
  • PICT测试用例设计工具(安装包),PICT测试用例设计工具(安装包),亲测可用!
  • 软件测试用例管理工具,有数据库!属于转载哦
  • 这个第二个版本,想比第一个版本,支持被转换的excel包含多个sheet页,且生成的xml文件包含的用例数最大为100(TestLink批量导入超过100条用例会产生遗漏)。 具体使用方法参见博客:...
  • 单元测试用例

    2019-03-22 01:50:29
    NULL 博文链接:https://czjxdm.iteye.com/blog/914019
  • 原文链接https://blog.csdn.net/u011541946/article/details/777452171. 为什么要做接口测试 在日常开发过程中,有人做前端开发,有人负责后端...一般我们大部分人都是做功能测试,很多是界面的功能测试。如果你理...
  • 简单易用的可视化建模工具 支持子流程多层嵌套,分解复杂业务 智能检查提示模型中存在的问题
  • 软件测试如何测试用例

    千次阅读 2020-09-17 22:12:12
    如何测试用例 一、测试用例与编写流程介绍 1.常用术语 软件:数据+程序+文档 测试时就是操作数据,操作的主体就是程序,文档就是工作时的可视化 软件测试的基础:软件测试就是保证软件质量,满足用户...
  • OA系统测试用例

    2016-02-23 11:30:30
    OA系统测试用例 1 引言 1.1 编写目的 本文档的目的在于为执行测试提供用例,指导测试的实施,查找分析缺陷,评估测试质量。 1.2 文档范围 本文档包括了功能测试用例、性能测试用例、GUI测试用例、压力测试用例。 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 144,840
精华内容 57,936
关键字:

一般写测试用例用什么工具

友情链接: COM_INT.zip