51Testing软件测试论坛

标题: 你在撰写测试用例的时候思维清晰吗？-------测试用例撰写之架构 [打印本页]

作者: ricmy 时间: 2010-8-6 14:22
标题: 你在撰写测试用例的时候思维清晰吗？-------测试用例撰写之架构
从编程的角度来讲，架构的开发要比具体功能的实现重要的多，一个合理的架构会给以后的开发留有很好的发展空间，可是如果碰到一个不好的架构，后期的开发会变得寸步难行；同样一份好的测试用例架构也是很重要的，而通常你的架构需要与程序的架构相吻合，这样的case 才会合理，在开发领域有一个叫软件架构工程师，近几年在软件测试领域也出现了软件测试架构工程师，我相信在某种程度上，这俩个架构工程师在看待同一AP上会得到一份相似的架构。
   同样，我们先来看看研发，作为软件架构工程师，拿到一份FRS，进行DNS的时候，他也许会从2个方面着手：第一，模块的划分，第二，核心数据结构的建立，以及数据的流向规划。而模块的划分通常会以功能点或是UI为出发点来进行规划。核心数据我们这里就不讨论了。
  然后我们再来看看测试，一个软件测试架构师，同样拿到的也是一份FRS，进行STD的设计，而他呢，也是需要对FRS进行模块的划分，这部分的划分越趋近程序的架构越好，这样的好处在于日后AP发生改变的时候，Case也可以找到想对应的部分进行变化，而不至于需要对Case进行全面的修改。
  如此看来测试用例的撰写第一步遇到的与开发是同样的问题，那就是模块的划分，当然测试肯定还是有自己的特点。一般的情况下，我们认为Test Case 可以分为三级来划分：
第一级：正常情况下的测试，特殊场景下的测试，压力测试，性能测试等大类别的分开
第二级：基于UI或是功能对其进行模块的划分
第三级：第二级如果是UI模块，那么第三级需要按照功能点来划分，如果第二级为功能模块，那么第三级优先按照UI模块来划分
所以，从上面来看，最终会划分会到每个具体的功能点，那么每个功能点的测试又需要包含含下面几个要素的测试：
1．  Default status check
2．  当前动作所操作的对象划分（可以称为源分类）
3．  动作过程中的选项
4．  动作所要达到的目的（可以称为目标分类）
5．  确认不同方式可执行此动作

针对以上三个原则和几个要素，我们以系统的Explorer为例来讨论一下如何进行Case 的撰写：
首先我们会分为这几大类：Administration 用户测试，Limited 用户测试，压力测试，性能测试等，就Administration 用户测试又可以分为：ToolBar，TreeView，ListView，Statusbar （以上是按UI模块来划分的，有时候还需要添加一些按照功能来划分的）Search，收藏夹，同步，文件夹选项等，而展开TreeView第二级的Case,按照上面的原则，这是一个UI模块，第二级分类，需要按照功能来分，于是就出现New，Copy/Paste,Cut/Paste,Delete……；就具体的每个动作，我们进行具体Case 的撰写，按照上面提到的要素，Copy 的Case 需要有如下测试用例：Default Status，源分类（Copy 本地目录，网络目录，系统目录，只读目录，无权限访问目录，含子目录的目录，含有文件的目录….）,目标分类（Paste到本地，网络，网络目录，系统目录，只读目录，无权限访问目录…）。
至于Limited 用户测试，我们可能需要根据Limited user 下一些特殊的限制进行有针对性的撰写，而不需要像Administration 那样面面俱到。

以上就是大概的一个思路，这些以文字的方式来描述，理解起来会比较费劲，我们可以借助思维导图类的软件来帮助我们更好的来呈现，下面就是我用MindManager对Explorer 一个局部的描述：

附件:

Explorer case架构图 [时间:2010-8-6 14:28]

作者: liuwwb 时间: 2010-8-6 15:57
顶一下！

作者: sakuna 时间: 2010-8-6 16:02
支持一下

作者: msnshow 时间: 2010-8-6 21:19
使用思维导图，不错

作者: ermine 时间: 2010-8-6 22:26
确实，同感。
用惯了思维导图，设计用例感觉挺顺手的。

作者: ricmy 时间: 2010-8-9 09:10
确实，而且使用思维导图也便于Case 的 Review

作者: Jackc 时间: 2010-8-9 10:25
恩，确实不错，逐层向下铺展测试点不仅能让自己思维清晰，也能为评审的提供一个清晰的思维空间。::ybaojc:::

针对于LZ的例子，我经常还会再做一个功能模块交互关系图，为“特殊场景测试”提供用例设计指导。

作者: ricmy 时间: 2010-8-9 11:31

原帖由 Jackc 于 2010-8-9 10:25 发表
恩，确实不错，逐层向下铺展测试点不仅能让自己思维清晰，也能为评审的提供一个清晰的思维空间。::ybaojc:::

针对于LZ的例子，我经常还会再做一个功能模块交互关系图，为“特殊场景测试”提供用例设计指导。

没想到版主大人也来了，深感荣幸呀
另外，请教一下像这种情况，您的功能模块交换关系图，会是什么样子呢？如能简单勾画一下，不甚感激！

作者: Jackc 时间: 2010-8-10 13:01

原帖由 ricmy 于 2010-8-9 11:31 发表
另外，请教一下像这种情况，您的功能模块交换关系图，会是什么样子呢？如能简单勾画一下，不甚感激！

通常会分为两部分，模块内部关系图和外部关系图。
1、内部关系图
内部关系图的结构元素基本与你提到的用例设计结构使用的元素基本一致，只是组成方式不同，着重强调各个子模块之间的相互调用关系。
[attach]64376[/attach]

2、外部关系图

外部关系图则强调测试模块与系统其它模块的相互调用以及OS对测试模块的调度策略（比如后台运行、同时运行等）

[attach]64377[/attach]

PS：这些结构图都需要大量的时间来设计，而其作用也比较有限，只对交互和场景测试具有指导意义。所以不适合时间比较紧的项目。

作者: ricmy 时间: 2010-8-12 10:21
恩，有了这样的内外部关系图，对Case的设计确实是有很大的帮助
而且从某种程度上来讲，这种关系图对研发也是有很大帮助的，便于对模块接口的划分与定义，非常不错，受益了，谢谢！

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)