1、Rquirement
　　◆根据系统的需求进行编写测试需求，测试需求的编写，需求简单明了。
　　◆测试需求点加上与系统需求一致的编码。
　　规则：
　　◆在Requirement、Test Plan、Test Lab中，基本流只存在一个，并且排在第一项。
　　(在TD中的后续步骤中，可对该基本流进行重复的运行测试)
　　◆在需求编写的大体分级上，应该遵循的顺序：主菜单→次菜单→功能点。
　　◆测试中的需求点要与实际的系统编码一致。
　　◆当需要对功能点的某一需求进行分级时，也遵循“功能点－需求点”的规范
　　以task2007为例子，制定需求的编写格式：
　　◆在task2007中，二级菜单是页面的各个功能点，所以按“主菜单→功能点”编写。
　　◆task分为new、edit、delete、remind
　　◆逐一对功能点进行细分，new又可分为Basic Flow（基本流）和Alternation Flow（可选流）。
　　◆可选流可以有多个，按照A01、A02、A03等进行编号，需求点A01还可以继续进行划分，A0101、A0102等，依次类推。
　　◆当需求编写完毕后要导到Test Plan中。
　　2、Test Plan
　　◆编写Test Plan中的主要大的功能点，要和需求中的一致；
　　◆根据功能点的具体项进行分支，编写测试用例；
　　规则：
　　◆在Test Plan中，基本流只存在一个，并且排在第一项。
　　◆测试用例的上下级关系必须与需求保持一致，多级的用例允许用文件夹进行分类
　　◆如果在测试用例上有做功能点名称的修改，在需求中也应做相应的更新。
　　◆可以通过在需求中选择不同的视图进行匹配，达到一一对应的关系。
　　以task2007为例子，制定Test Plan的编写格式：
　　◆从Requirement导到Test Plan中，根据具体的功能的进行划分，然后编写测试用例。
　　◆如果在Test Plan中有进行功能点的修改时，应该与需求进行匹配，达到一一对应。
　　3、Test Lab
　　◆编写Test Lab的编写和Test Plan中的主要大的功能点是一一对应的。
　　◆可以通过再次拖动测试用例，对测试用例进行多次执行。
　　规则：
　　◆在Test Lab中，基本流只存在一个，并且排在第一项。
　　◆当你要执行多次测试用例时，在Test Lab中应该保存执行的结果。
　　◆可以通过在Test Lab中编写的功能点，需达到一一对应的关系。
　　4、Defects
　　◆提交或者修改bug时，必须在TD中填写相应的信息。
　　规则：
　　◆开发人员修改bug时，需要填写bug修改的优先级和估计修改的时间
　　◆除开发人员填写的内容外，其他均由测试人员进行填写；
　　◆计划关闭bug的版本栏位允许为空。
　　验证bug的标准
　　◆根据bug的描述重复该bug的发生操作；
　　◆需要重新对该bug所属的用例进行重新执行；
　　◆验证bug，需要在TD上留下相关的文字说明及描述。