在网上看了一种关于黑盒测试的测试用例的设计方法

s1100411

在网上找到的，是用来编写黑盒测试的测试用例的方法，看完以后有点半懂不懂的感觉，求助各位大神，能不能帮忙给举个例子，帮助下理解。。。下面是原文：


          熟悉测试理论的人都知道，路径覆盖是白盒测试中一种很重要的方法，广泛应用于单元测试。那么基于路径覆盖的分析方法是不是只能应用于单元测试呢，能不能将其推而广之呢。一般而言，在单元测试中，路径就是指函数代码的某个分支，而实际上如果我们将软件系统的某个流程也看成路径的话，我们将可以尝试着用路径分析的方法来设计测试用例。采用路径分析的方法设计测试用例有两点好处：一是降低了测试用例设计的难度，只要搞清了各种流程，就可以设计出高质量的测试用例来，而不用太多测试方面的经验；二是在测试时间较紧的情况下，可以有的放矢的选择测试用例，而不用完全根据经验来取舍。下面就具体的介绍一下如何用路径分析的方法编写测试用例。   
          首先是将系统运行过程中所涉及到的各种流程图表化，可以先从最基本的流程入手，将流程抽象成为不同功能的顺序执行。在最基本流程的基础上再去考虑次要或者异常的流程，这样将各种流程逐渐细化，这样既可以逐渐加深对流程的理解，还可以将各个看似孤立的流程关联起来。完成所有流程的图表化后就完成了所有路径的设定。     
          找出了所有的路径，下面的工作就是给每条路径设定优先级，这样在测试时就可以先测优先级高的，再测优先级低的，在时间紧迫的情况下甚至可以考虑忽略一些低优先级的路径。优先级根据两个原则来选取：一是路径使用的频率，使用越频繁的优先级越高；二是路径的重要程度，如果失败对系统影响越大的优先级越高。将根据两个原则所分别得到的优先级相加就得到了整个路径的优先级。根据优先级的排序就可以更有针对性的进行测试。   
           为每条路径设定好优先级后，接下来的工作就是为每条路径选取测试数据，构造测试用例。一条路径可以对应多个测试用例，在选取测试数据时，可以充分利用边界值选取等方法，通过表格将各种测试数据的输入输出对应起来，这样就完成了测试用例的设计。     
            对于测试人员而言，测试用例的设计是一件非常困难的工作，而同时测试用例的设计好坏又直接关系到整个系统的设计质量。本文介绍了一种更理论化的设计方法来尽量简化这种工作，将一般应用于单元测试的路径分析方法推广到集成测试、系统测试等后续测试过程中，希望能给大家一点启示。

Jackc

回复 1# s1100411

大概浏览了一下文中提到的路径覆盖理论，以下分两个层面来说一说我的理解：

1. 测试执行的策略

    针对实体化的测试目标，我们在设计实际用例时(特别是在设置用例优先级时)，将测试目标的主干流程作为优先级最高的用例组。如下图中，“提交申请--权限检查-修改申请--线下采购”为主干流程（这个流程图比较特殊，如果没有业务特殊要求，则有两条主干流程（单/批）），其他场景均为支干流程。

   针对主干流程，我们通常采取以下方法来体现其高优先级：更细用例颗粒度，更优先的执行序列，在单个测试生命周期内享有更多的测试执行次数，失败产生的bug具有更高的严重程度。。。(此文中主要体现了更多的执行次数和bug严重程度)
   比如，单个版本测试周期内，主干流程用例的整体执行次数为2，而其他支干流程用例的执行次数为1；主干流程测试用例失败产生的bug严重程度为P1，支干流程用例失败产生的bug严重程度为P2/P3

备注：其实我相信大多数公司即使不使用文中提及的分析方法，在实际测流程中，也多多少少已经将该方法的预期收益使用其他方法代替，并已得到成效了。大家目的相同，只是依据的分析方法不同而已。LZ可以思考一下目前你们bug定级标准的依据是什么，与文中提及的“路径覆盖”概念有什么异曲同工之处。


2. 测试流程的策略

   其实我们在整个测试流程策略中，在针对测试类型部署时，做出来的效果已经和文中提及的预期效果一致了。。。
   典型的测试流程策略，如，回归测试和版本可接受测试的测试范围定义。为什么我们一开始就定义这些测试活动是在一个狭隘而特定的测试范围内进行测试，而不使用类似系统测试这样的广域测试范围来定义？

小结：其实文中只是针对“无穷尽测试”的问题，提出了一种分析模型（方法）。
虽然无数前人已针对此问题提出了各种标准模型和分析方法，但文中作者还是依据自身特点，选择了一种适合自己理解，并可在自己实际工作中落实的分析模型。

s1100411

回复 2# Jackc


    看完了你的解答，感觉思路清晰了不少，谢谢了，呵呵，我也是刚接触测试，看了不少用例的设计方式方法，但是一到实际工作中，就总感觉无从下手，不知道怎么和实际工作相结合，我现在所在的公司测试部门刚组建，基本可以说没什么规范，都是自己凭感觉去测，而且都是黑盒，不用接触代码，数据库，想自己多学点关于测试的知识，想请教下，学完测试用例设计方面的知识以后应该再学什么，该学性能工具LR之类的还是学哪方面的理论知识？感觉自己特没明确方向和计划

没翅膀的飞鱼

回复 3# s1100411

用例设计是个长期积累的过程，如果你们部门刚组建，建议多看看测试规范方面的资料，之后再由针对性去学习

icestick8586

我觉得其实在白盒测试中也有黑盒测试方法，上面的路径可以理解为流程分析法，有基本流，然后分备选流，再加上优先级

没翅膀的飞鱼

是的，其实没有必要分清楚黑盒还是白盒--

丝路

看了楼主的转帖，觉得简直是我们公司的现状啊。经过7年测试流程的改进，测试用例的设计最终就是这种模式。实际上这是RUP理念中测试用例指南的精髓所在。

sy070904

目前我们公司采用单个功能点作为一个测试点，写成一个或者多个测试用例。对于一个功能很多的系统来说，一个最基本的流程中会设计到很多功能点，每个功能点又较为复杂，也需要单独测试。lz公司的测试又刚起步，采取测试单个功能点的方法最安全，这样能最大程度地保证所有的点都能测试到。
以场景方式的用例，应该建立在模块与模块间功能无问题的基础上，或者还有其他方法测试最基本功能点无问题的基本上。
不知道版主 丝路 公司的测试流程是啥样的，愿意深入交流

罗晶淼

看过之后 是否是和用户场景法测试用例设计很像，只是将用户场景设计的用例更加细化了

罗晶淼

回复 3# s1100411


    我也是新手测试，刚进入公司时，公司用的技术是Java，当时我就想着去学习Java，并坚持了两个多星期，后来才发现，其实这样不对，我们现在应该做的是掌握好我们的本职工作，即测试工作，掌握好测试知识，等到测试工作做的少许上手了，再去扩充其他知识，我是这样觉得的，不知大家何意？