|
从编程的角度来讲,架构的开发要比具体功能的实现重要的多,一个合理的架构会给以后的开发留有很好的发展空间,可是如果碰到一个不好的架构,后期的开发会变得寸步难行;同样一份好的测试用例架构也是很重要的,而通常你的架构需要与程序的架构相吻合,这样的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]
|
|