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/