确定单服测试的通过与
否
iii
便于回归测试的执行
这样讲应该比较明白了吧。
c
测试用例应该包括什么测试执行过程中所需的所有信息，举例说明下。例如：
i
表头：功能名称、案例编写人员、编写时间、测试人员、测试时间
ii
正文：功能点、测试点、测试输入、预期结果、实际结果
iii
用例执行结果统计
d
功能点模块化理念
都知道一个复杂庞大的系统，程序在实现时会将其分成若干模块按照模块功能优先级进行实现。我们测试过程中也采用这种方法，将复杂的功能点按照实现功能进行分类，分类后的测试点，再进行分类，直至细分成为一条条用例。就像庖丁解牛那样。
按照等价类划分法，将同一判断条件的测试点组成一个集，在这个条件基础上再次判断的条件，我们假设它已经成立。这样在用例设计过程中就需要测试人员清楚的知道，哪些条件是一类需优先确认的，哪些是以这类条件为基础的。我们最终形成的测试用例一定确保的是一条用例只检查一个测试点。
这样设计也有另外一个好处，如果一条用例不能走通，其它的还可以继续检测，经常会遇到测试过程中由于一个bug，导致测试工作停滞。现在这样子我们就可以采取脚本调试，或者其它方法跳过有bug的测试内容，继续进行其它测试点的测试了。
e
场景测试法协助功能点细分
游戏测试中，场景测试方法是经常用到的一种方法，什么是场景测试法，及按照功能设计要求，在脑中模拟出来的一个功能使用时的操作流程。按照每步操作的针对点，将针对点划分为所用例设计时的小功能点。划分时需每步针对点的各种检查点分到该功能点内设计为该功能点的检查点。再根据检查点进行测试输入（及操作过程）的编写。用例编写过程中的思考方式就如上了。讲起来比较抽象，希望对大家有所帮助。
ff
用例的设计原则一直有人问到底要详细到什么程度
i
我们不期待用例编写到任何人都可以执行，也没有这个必要
ii
我们针对的是网游的测试人员，至少是玩过网游的人，这些人对于游戏中的基础设定都有认识，
我们不可能对着一个不知道任务界面是什么的人大讲怎么测试任务。所以我们用例编写的原则就是针对我
们测试组内的测试人员。
iii
但是，请不要简略到别的测试人员看不懂，特别是当你是专职的用例编写人员时，编写时请多考
虑下语言描述的方式。请让你的同伴可以看懂，你所要表达的意思。
iv
用例是没有固定格式的，它的主要原则就是，测试中所需所有信息，我通过你的文档都能够获取
到。所以不要再执着的像别人要模r