关于自动化测试的几点思考(持续更新)

最新推荐文章于 2024-08-27 14:19:59 发布

yongwan5637

最新推荐文章于 2024-08-27 14:19:59 发布

阅读量496

点赞数

分类专栏： Android自动化测试

本文链接：https://blog.csdn.net/yongwan5637/article/details/79724428

版权

Android自动化测试专栏收录该内容

4 篇文章 0 订阅

订阅专栏

1、写脚本应当遵循的原则：

a、高内聚，低耦合

关于软件自动化测试用例设计的几点分析

1、手工测试用例和自动化测试用例功能定位的区别。

　　a)手工测试用例

　　 i. 较好的异常处理能力，能通过人为的逻辑判断校验当前步骤的功能实现正确与否。

　　 ii. 人工执行用例具有一定的步骤跳跃性。

　　 iii.人工测试步步跟踪，能够细致的定位问题。

　　 iv. 主要用来发现功能缺陷

　　b)自动化测试用例

　　 i. 执行对象是脚本，任何一个判断都需要编码定义。

　　 ii. 用例步骤之间关联性强。

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

在我们测试工作中大多数测试人员使用的用例设计方法都是黑盒用例设计方法，其中使用最多的方法就是等价类划分法和边界值分析法，这两者也是所有的用例设计方法中最简单的，但是有一个缺点是如果我们稍不注意就会造成数据的遗漏，我们这篇文章就主要来分析一下如何合理高效的使用这两种方法设计测试用例。

　　如何编写测试用例

　　1.测试用例的组成元素

　　用例编号

　　用例标题

　　功能模块名称

　　前置条件

　　输入数据

　　操作步骤

　　预期结果

　　优先级

　　执行结果

　　编写人

　　执行人

　　其他补充项

　　以上列出来的项并不是需要完全写在我们的用例里面的，但是像用例编号，用例标题，前置条件，输入数据，操作步骤，预期结果，优先级，执行结果则是每一条测试用例必要元素。

　　 2.用例标题

　　不能有过多的字数

　　概括性-只需要看一眼标题就知道本条用例到底写了什么

　　坚决杜绝歧义性

　　3.测试用例的特点

　　步骤清晰

　　要有很清楚的操作步骤，如果你不知道怎么写就按照执行测试的步骤一步一步写清楚就好了，比如我们现在有一个QQ登录的用例，那么就可以这样写操作步骤：

　　1.点击QQ应用程序

　　2.输入正确的用户名

　　3.输入正确的密码

　　4.点击登录

　　结果唯一

　　每一条测试用例都只能有一个唯一的测试结果；每一条测试用例都只能包含一个测试点；每一条测试用例允许有多个检查点；预期结果中不能有歧义或者二义的字。

　　可操作性强

　　要保证不同的测试人员或者不同的测试平台，最终的结果都是相同的。

　　注意点：不管是用例标题还是预期结果，尽量不要使用含糊不清的语句

　　用例设计方法

　　1.等价类划分法

　　等价类划分法就是把输入域的可输入值进行等价性划分，然后在每一个等价域中取少量的能代表这个等价域的值作为测试用例的输入数据。根据每个等价类值是否对程序有作用，分为有效等价类和无效等价类。

　　有效等价类：此类中的值对于我们执行用例的程序来说是有意义且合理的，可以有效的检验程序是否实现了需求规格说明中规定的功能和性。

　　无效等价类：此类中的值正好相反，对程序来说是不合理的、无意义，输入此类中值程序无法实现相应的功能和性能，但是不是说程序不会对此类中值有反应，从程序的健壮性来考虑，程序也应该对此类中的值做出正确的反应。

　　等价类划分的原则：

　　1、按区间划分

　　当输入条件已经规定了取值范围或者值的个数时，我们基本可以确定一个有效等价类和两个无效等价类。

　　2、按数据集合划分

　　在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类（该集合有效值以外）

　　3、按数据布尔值划分

　　在输入条件是布尔值的情况下，可确定一个有效等价类和一个无效等价类

　　4、按数值划分

　　要规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类

　　5、按限制条件或规则划分

　　在规定了输入数据必须遵守的规则情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）

　　6、按细分等价划分

　　在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类

　　我们根据上面几条原则将输入域的可输入值进行划分后，就可以在每个等价域中选取少量具有代表意义的值来作为程序执行的输入数据，并开始设计测试用例。其实我们在设计测试用例时不仅要考虑输入域，更要考虑输出域，输出域的等价类划分和输入域的划分是相同的。

　　设计测试用例的方法：

　　1）设计新的测试用例，使其尽可能多地覆盖未覆盖的有效等价类，按照这一步骤重复进行，直到所有的有效等价类都被覆盖为止

　　2）设计新的测试用例，使其只覆盖一个尚未被覆盖的无效等价类，按照这一步骤重复进行，直到所有的无效等价类都被覆盖为止

　　注意点：非常重要的一点是一条测试用例中只有有一个无效等价类，就好像我们常说的一条测试用例只包含一个测试点一样的。如果你一开始不能分清楚有效等价类和无效等价类可以先输出等价类表，然后根据等价类表来输出测试用例。

　　 2.边界值分析法

　　边界值分析法我们一般用于对等价类划分法完成之后作补充，但是这也是必不可少的，原因在于程序的很多错误都是发生在输入或者输出的范围的边界上的，而不是在输入范围的内部，所以针对各种边界情况进行测试用例的设计通常都会有很好的测试效果。

　　所谓的边界是指输入域中，稍高于或者地域边界值的一些特定情况，边界值分析不仅要考虑输入条件，还要考虑空值时的测试情况。空格，null，""等都是比较特殊的清理狂，在设计测试用例的时候需要特别注意一下。

　　边界值分析的值

　　内点：域内的任意点都是内点

　　上点：指边界上的点，无论此时域是开区间还是闭区间，上点就是域的上限与下限值

　　离点：指的就是离上点最近的点，这里就跟闭区间还是开区间就有关系了，如果是开区间，那么离点就在域内，如果闭区间，那么离点就在域外（开内闭外）

　　例如：输入框的输入数据范围为3-6（包含3和6），则内点是4，5；上点是3，6；离点是2，7。

　　边界值分析的原则：

　　如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据（内点，上点，离点）

　　如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据

　　如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例

　　如果程序中使用的一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例

　　分析规格说明，找出其他可能的边界条件

　　边界值分析法不仅可以针对输入框中数值进行分析，对于下拉框、空间都是可以进行分析的。

　　黑盒用例设计方法除了以上二种还有很多，测试人员在编写测试用例时不需要强制要求使用哪一种方法，并且在编写用例过程中，一般都需要搭配多种设计方法共同编写，以满足测试用例对需求规格说明书的最大覆盖。

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

2、自动化测试用例设计管理不善可以直接导致自动化测试开展的失败。

　　误区：

　　1、不编写测试用例直接投入测试脚本编写。

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

　　自动化测试替代不了手工测试，目的仅仅在于让测试人员从繁琐重复的机械式测试过程解脱出来，把时间和精力突入到更有价值的地方，从而挖掘更多的产品缺陷。

　　目前咱们TD中对用例加入了自动化测试的标签。

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

　　冒烟测试执行的是主体功能点的用例。

　　回归测试执行全部或部分的测试用例。

　　怎么编写自动化测试用例，如何将自动化测试用例和手工测试用例相辅相成。

3、用例选型注意事项：

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

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

　　3、选择的用例最好可以构建成场景。例如一个功能模块，分n个用例，这n个用例使用同一个场景。这样的好处在于方便构建关键字测试模型。

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

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

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

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

　　8、如果平时在手工测试时，需要构造一些复杂数据，或重复一些简单机械式动作，告诉自动化脚本，让他来帮你。或许你的效率因此又提高了。

4、用例转型注意事项：

　　1、首先测试人员应该了解脚本是怎么替代人工来执行用例。

　　2、当你写自动化测试用例时，你需要意识到你的用例是写给一个“智障人士”执行，执行对象是脚本。

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

　　4、每一个步骤都要衔接好，错了，脚本要报异常，我要去烦你。

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

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

　　7、不是每一个步骤都需要验证点，让子弹飞一会儿。

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

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

　　10、当你设计自动化测试用例时，难免对一个用例的功能点加加减减。不要因此而剪掉了一些验证点。因为手工用例+自动化用例=1。

　　写给项目测试负责人的一些话：

　　1、项目加入了自动化测试平台，负责人要有全局的把握。因为你的用例被拆分成自动化测试和手工执行用例，原来一些被打入冷宫的用例因自动化测试而重生，重生的用例需要你的维护。

　　2、当你迎来项目新立项，拿到需求文档，开始设计新用例，此时，别忘了该如何统筹安排你的用例。是的，这很像排兵布阵，有了自动化测试这把利剑，还得看你会不会用。

　　3、不要永远做自动化测试的门外汉。可能你的职业规划是测试经理，产品经理，或者其他，又可能你对其感到畏惧或厌倦，认为自己无法跨越对编码的恐惧。但是，无论如何，今天你是这个项目的测试负责人（一个资深的测试工程师），你要负起这个责任，挑起大梁。

　　4、如果以后你看到自动化测试报告单，没有发现一个bug，请不要抱怨，自动化脚本主要不是来帮你找缺陷，而是告诉你没有缺陷。

　　5、如果将来你参与了自动化测试脚本编写工作，请做好面对一大堆错误的心理准备。在前期，测试结果往往会夹杂着一大堆的各种错误，可能是框架机制问题，可能是脚本编写问题，可能是用例问题，还有可能是需求自身的问题。

　　6、咱们部门刚刚开展自动化测试，需要大伙的支持和理解。它的发展需要一个渐进的过程，从无序到有序，从困惑到豁然开朗。这个过程难免曲折艰辛，甚至会引来非议，但是从一些成功案例中，还是坚定了我继续走下去的信心。我渴望和大家一起分享这份成果，尽管现在连花儿都未曾开放。

　　7、会自动化测试和会 QTP是两回事，学习自动化测试不一定要会QTP，你也可以通过 Selenium入门。

　　8、请考虑下你负责的项目是否需要实施自动化测试，我们可以一起坐下来讨论，圈定一个范围和实施的计划。我们都是产品线上的一颗螺丝钉，我这颗螺丝钉很乐意为你的项目提供自动化测试的帮助。

　　9、不要过度信任自动化测试，它也是个撒谎高手。所以，自动化用例需要测试，框架需要测试，脚本函数需要测试，脚本过程需要测试，驱动数据需要测试。

　　10、看到这里，你一定觉得开展自动化测试很累人。没错，这本不是一件立竿见影的利索活。它的发光，需要一定时间的沉淀，我们现在讨论的，和接下来要做的工作就是为了如何来缩短这部分的时间。

参考：http://www.51testing.com/index.php?action-viewnews-itemid-3720545-php-1

如何设计软件测试用例？