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