方法：这里针对业务流程的测试推荐使用“场景法”。

　举例：   　　

分析：先考虑用户使用场景　　

场景1：列表有数据，用户把数据按默认方式导出　　

点击导出->开始导出->查看导出文件　　

场景2：用户突然不想导出　　点击导出->点击取消　

场景3：列表有数据，用户把数据按自定义方式导出　　

点击导出->开始导出->查看导出文件　　点击导出->设置导出列->开始导出->查看导出文件　　

点击导出->设置导出列->设置导出记录数->查看导出文件　　场景4：找不到导出的文件，重复导出　　

点击导出->导出列和记录数设置和上次一样->开始导出->查看导出文件　　这些主要的考虑了，接下来考虑容错啥的　　

1.列表没数据，进行导出　　

2.导出列的边界值测试　　

好了，接下来就是细分和组合等了　　细分：比如上面的导出列设置时，可以是全部选中，可以添加部分选中　　

组合：比如那个取消导出操作可以和其它场景的写在一起　

　更多详情，搜索 场景法　　再举个例子说明按逻辑设计的好处：　　 　

点击修改，弹出修改界面，继续点击单位，出现如图界面    　　

要点分析：　　此处的修改是服务端管理员对学生端学员信息的修改，如果按业务逻辑来，这里的修改会同步学生端学员信息的修改，这个点不容易遗漏的　　

说明：按业务逻辑来设计用例，容易让自己陷入矛盾的地方　　

背景：某个在线教育产品，功能模块包含了 我的笔记，课程-视频课件播放，其中，我的笔记中，笔记内容记录，来源视频播放界面提交的笔记　　

举例：按业务逻辑来，可能会如下方式编写　

1、打开视频播放界面，输入笔记内容，提交---(预期结果)　　

2、打开我的笔记--可见提交的笔记　　这样看好像没问题，但是细想下，测试 我的笔记 模块时，会漏掉步骤2的验证么？

不会吧，所以这里的步骤2是多余的，可去掉，这里应该对步骤1进行重点测试，不输入、输入字符过长，输入字符含特殊字符，输入字符含换行等　　那步骤2怎么办？在我的笔记模块新增用例，把步骤1当做一条线，如下　

1、打开视频播放界面提交一条笔记（预期结果可免了，视频播放模块已验证过了）　　

2、打开我的笔记--预期结果（提交时间，内容显示，字符类型支持等）　　

这里也告诉我们，仅当某个点不会被单独作为一个用例检测点时，才需要进行一个“关联”，好比上面的学员信息修改，数据同步　　

这样看好像是没错的，但是很大的不足是啥呢？还是上面提到的，人力的重复投入：测试提交笔记时至少测输入字符串的长度，类型支持；测试笔记模块的查阅时也要测试笔记内容是否被截断，要测试特殊字符的显示是否正常等，也要进行提交笔记时执行的测试操作　　解决方案：没错，还是按逻辑设计用例>>输入笔记->提交笔记->显示笔记，　　

1、打开视频播放界面，输入笔记内容，提交---(预期结果)　

2、打开我的笔记--可见提交的笔记　　

这里可以根据本文中提到的，检测点的思想，进行细化，分成多条用例　

　比如用例1.记笔记(字符长度测试)；用例2.记笔记(字符类型验证)，当然对应的用例内容也跟着改，如下　

1、打开视频播放界面，输入超长字符的笔记内容，提交---(预期结果)　　

2、打开我的笔记--笔记显示不截断，过长以…结尾　　接着可以根据本文中提到的，归到同一个模块，比如笔记模块，分配给同一个人　　

d) 独立出公共用例　　思想：把某些公用的模块或功能独立出来设计，减少冗余　

举例：常见的智能手机，很多模块中选择文字，文字变底色，通常伴随弹出操作面板，类似全选，复制等，

那可以考虑在某个模块中把这个功能单独出来设计用例，其它模块则不再重复写　　e) 提高用例复用性                  

本文由职坐标整理并发布，希望对同学们有所帮助。了解更多详情请关注职坐标软件测试之测试技术频道！