1）须严格遵守5.1.1的第1）和第2）条，确保每个测试用例步骤是可执行的。
2）须严格遵守5.1.4，确保测试结果的正确性是可判定的，再现的。
3）如果仅在测试用例对象内出现的同类性质的各输入项或界面的测试，如各标签内容、各项风格布局、各控件功能、各必填项等的测试输入和期望结果，应合并成一条测试用例步骤。
4）在设计测试用例时，仍可发现其它测试用例对象中存在同类性质的测试项，如session检查、数据保存验证等，应将这些测试用例步骤抽取到公共用例中。
5）公共用例中测试输入或期望结果中的输入项和验证项（显示的控件、数据库表和字段）名称必须以参数变量保存，而不是直接输入某个名称，这是因为调用公共用例的各对象的实际输入项和验证项名称是不同的，参数变量的名称以输入项和验证项的特性命名。如需要检查在某个数据表中检查符合某个条件的某个字段数据是否与页面显示的相同，测试输入则应该这样编写：
“1在xxx页面中输入查询条件<<<condition_name>>>，选择查询；
2使用sql查询语句：select
<<<vfield_name>>>from<<<table_name>>>where<<<cfield_name>>>=<<<condition_name>>>”，<<<>>>是TD申明参数变量的命名符，括号内的字符便成为该测试用例对象的私有参数变量。
公共用例参数变量的设置应涵盖所有调用者对象需要的变量，是“与”的概念。为保持软件一贯的命名习惯及可读性，参数变量名不应使用中文字符。
6）当公共用例设置了参数表量，调用其的用例对象所对应的测试用例步骤中，Call<公共用例名>后会自动增加“withthefollowingparameters:参数变量名=?”。鼠标移至此step，通过点击右键，弹出选择菜单，如图五，选择calledtestparameters后，可通过TD弹出的输入框，如图六，输入调用者对象实际的输入项或验证项的名称。调用者对象不需要的公共用例参数变量，可以不输，这体现了调用者对象输入项或验证项、及其数量的虚拟化，即体现了5.3.5第3）条的多态特征。
7）根据5.1.3的第2）条，及5.3.1和5.3.2，应该增加与之相关边界条件或值、无效等价类的测试用例步骤。
8）根据5.3.3，使用因果图法生成决策表，决策表的每个规则就是一个测试用例步骤，这类的一组规则应该生成独立的规则用例。
9）在设计备选流用例对象时，起始步骤的测试输入中，应首先说明由哪个基本流用例的StepName触发的，我们可以规范为：“在基本流step9中输入无效的用户名或密码，系统显示登录信息错误的提示。”
2.4.5测试实施
1）设计执行测试的流程：
建立测试执行包：如图七，左侧一级包按测试类型命名，二级包根据迭代计划，或集成构建计划的版本命名，三级包按SRS中的模块命名，也可按业务流程命名；
建立测试布置（testset）：三级包下建立testset，它可以是一组覆盖一个系统用例的测试用例对象，也可以是一组覆盖一个业务流程的测试用例对象。将图七右侧一组相关测试用例对象拖至testset的executionflow标签页中，全选右键弹出图七所示的菜单，选择Arrangetestssequentially后，TD弹出如图八的Ordertests,在Ordertests框中，通过上下按钮选择测试执行的顺序。
2）设计测试数据：
建立测试数据文件：建立如图九的Excel文件，用于保存测试用例对象的测试数据，必须并且仅在每个基本流用例、备选流用例、异常流用例中保存各自的测试数据。每条测试数据必须注明步骤编号，由于上述三种测试用例对象可能Call公共用例和规则用例，因此该步骤编号必须是执行的测试用例对象编号加其测试用例步骤编号，如图九左上侧所示；
上传测试数据文件：在基本流、备选流和异常流测试用例对象的Attachments标签页中，将属于各自的测试数据文件上传到TD服务器，如图十。修改时，需打开修改，保存后选择该Attachments标签页中的upload进行更新。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
