你在撰写测试用例的时候思维清晰吗？-------测试用例撰写之架构

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

Explorer case架构图