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上留下相关的文字说明及描述。
文章来源于领测软件测试网 https://www.ltesting.net/
