-------------------------接 Part1--------------------------
方法：这里针对业务流程的测试推荐使用“场景法”。（当然，个人理解业务流程是从系统整体来把握的，局部角度来看，有些只算是“操作流程”,但是这个区别并不影响方法的使用）
举例：
分析：先考虑用户使用场景
场景1：列表有数据，用户把数据按默认方式导出
点击导出->开始导出->查看导出文件
场景2：用户突然不想导出
点击导出->点击取消
场景3：列表有数据，用户把数据按自定义方式导出
点击导出->开始导出->查看导出文件
点击导出->设置导出列->开始导出->查看导出文件
点击导出->设置导出列->设置导出记录数->查看导出文件
场景4：找不到导出的文件，重复导出
点击导出->导出列和记录数设置和上次一样->开始导出->查看导出文件
这些主要的考虑了，接下来考虑容错啥的
1.列表没数据，进行导出
2.导出列的边界值测试
好了，接下来就是细分和组合等了
细分：比如上面的导出列设置时，可以是全部选中，可以添加部分选中
组合：比如那个取消导出操作可以和其它场景的写在一起
更多详情，搜索 场景法
再举个例子说明按逻辑设计的好处：
教师端学员信息修改
点击修改，弹出修改界面，继续点击单位，出现如图界面
要点分析：
此处的修改是服务端管理员对学生端学员信息的修改，如果按业务逻辑来，这里的修改会同步学生端学员信息的修改，这个点不容易遗漏的
说明：按业务逻辑来设计用例，容易让自己陷入矛盾的地方
背景：某个在线教育产品，功能模块包含了 我的笔记，课程-视频课件播放，其中，我的笔记中，笔记内容记录，来源视频播放界面提交的笔记
举例：按业务逻辑来，可能会如下方式编写
1、打开视频播放界面，输入笔记内容，提交---(预期结果)
2、打开我的笔记--可见提交的笔记
这样看好像没问题，但是细想下，测试 我的笔记 模块时，会漏掉步骤2的验证么？不会吧，所以这里的步骤2是多余的，可去掉，这里应该对步骤1进行重点测试，不输入、输入字符过长，输入字符含特殊字符，输入字符含换行等
那步骤2怎么办？在我的笔记模块新增用例，把步骤1当做一条线，如下
1、打开视频播放界面提交一条笔记 （预期结果可免了，视频播放模块已验证过了）
2、打开我的笔记--预期结果（提交时间，内容显示，字符类型支持等）
这里也告诉我们，仅当某个点不会被单独作为一个用例检测点时，才需要进行一个“关联”，好比上面的学员信息修改，数据同步
这样看好像是没错的，但是很大的不足是啥呢？还是上面提到的，人力的重复投入：测试提交笔记时至少测输入字符串的长度，类型支持；测试笔记模块的查阅时也要测试笔记内容是否被截断，要测试特殊字符的显示是否正常等，也要进行提交笔记时执行的测试操作
解决方案：没错，还是按逻辑设计用例>>输入笔记->提交笔记->显示笔记，
1、打开视频播放界面，输入笔记内容，提交---(预期结果)
2、打开我的笔记--可见提交的笔记
这里可以根据本文中提到的，检测点的思想，进行细化，分成多条用例
比如用例1.记笔记(字符长度测试)；用例2.记笔记(字符类型验证)，当然对应的用例内容也跟着改，如下
1、打开视频播放界面，输入超长字符的笔记内容，提交---(预期结果)
2、打开我的笔记--笔记显示不截断，过长以…结尾
接着可以根据本文中提到的，归到同一个模块，比如笔记模块，分配给同一个人
d) 独立出公共用例
思想：把某些公用的模块或功能独立出来设计，减少冗余
举例：常见的智能手机，很多模块中选择文字，文字变底色，通常伴随弹出操作面板，类似全选，复制等，那可以考虑在某个模块中把这个功能单独出来设计用例，其它模块则不再重复写
e) 提高用例复用性
设计用例应该多考虑用例的复用性，可以从以下几个方面来考虑：
1)通用性。通用性是指可复用测试用例并不局限于具体的应用，不过分依赖于被测软件的需求、设计和环境，能够在某一类型、某一领域的相似软件的测试中广泛使用。(可以尝试去构建自己的用例库)
2)有效性。测试用例的目标是尽早发现软件问题
3)独立性。
1.用例之间不存在相互依赖关系
对于测试需求 R1和 R2，测试用例集分别为 cl和 c2，c1 和 c2 的交集为空，并且每个可复用测试用例能够独立运行。测试用例是否具有独立性，决定了测试用例可复用能力的强弱。
如果测试用例之间存在着相互关联，或测试用例的运行环境取决于其他测试用例的执行状态，那么，其中的测试用例不能复用时，与之相关的测试用例的可复用性也不复存在。
2.测试逻辑和测试数据分离
详情见下文
4)标准化
见”用例组成”
1、用例编写
1.1 用例组成
用例应遵循统一或规范的格式、结构，规范的命名规则，使用术语，用简明、易懂、无歧义的语言来描述，并且具有详细的文档。主要元素如下：
标识符ID：每个测试用例应该有一个唯一的标识符，它将成为所有和测试用例相关的文档、表格引用和参考的基本元素
测试项(用例名)：测试用例的标题，所给名称最好能清晰且简洁地表达测试用例的功能，见名知意，即测试目的、验证点。
建议格式：【模块-子模块】用例名
比如：【登录】密码大小写敏感测试
测试需求：对要验证的测试需求的描述和测试要求，如登录验证需求：
a 、用户名长度为 6 至 10 位（含 6 位和 10 位），
b 、用户名由字符（ a-z 、 A-Z ）和数字（ 0-9 ）组成，。
测试环境：where-在哪里测？测试用例运行时所处的环境，包括系统的配置和设定等要求，也包括操作操作系统，浏览器，通讯协议等环境。即软硬件环境。一般来说，在整个的测试模块里面应该包含整个的测试环境的特殊要求，而单个测试用例的测试环境需要表征该测试用例所单独需要的特殊环境需求。
测试前提：测试用例执行前必须满足的条件，如已登录、某个选项已经被勾选
输入数据： which-输入哪些数据?用来执行测试用例的数据。可能包括数据、文件，必要的时候，相关的数据库、文件也必须被罗列。
操作步骤：how-怎么做? 操作步骤，如 1 打开软件，2 点击 xx 按钮
预期输出：标识按照指定的环境和输入标准得到的期望输出结果(包含中间结果和最后结果)。
用例关联：用来标识该测试用例与其它用例之间的依赖关系，例如，用例 A 需要基于 B 的测试结果正确的基础上才能进行，此时需要在 A 的测试用例中表明对 B 的依赖性，从而保证测试用例的严谨性。并非所有的测试用例之间都需要关联
优先级：优先级越高的用例，应越早被执行
优先级通常是这样分的：
首先：核心功能>次要功能
其次：正向用例>逆向用例
也就是说，先确保核心功能正常，再次要功能测试；先确保常规路径运转正常-然后再逆向测试；
注意：
1.优先级之分主要是从“关注对用户最有价值的东西”这个点出发来考虑的。
2.上述的优先级的顺序，银行为例，银行账户登录，登录模块也包含逆向测试，但是涉及资金安全，登录模块的逆向测试的优先级也大于常规的正向用例的优先级，所以本质上优先级应该是：核心功能（正向用例>逆向用例）> 次要功能（正向用例>逆向用例），而针对核心功能
所在模块：按模块书写，通常情况下，建议 【模块-子模块】用例名称
版本号：用于测试用例的版本管理，每个测试用例应按照定义的规则设定一个版本号。
测试阶段：被测软件所处的测试阶段，包括单元测试、集成测试、确认测试、系统测试、验收测试等
测试类型：有功能测试、性能测试、安全测试、用户界面测试、接口测试、安装测试等，可选择多项。
附件：对测试用例附加的一些描述信息，例如文本、图像、模型、与测试用例有关的一些文档，方便测试人员迚一步理解测试用例。
1.2用例编写
1.层次性
2.明确性
3.可测性
4.可读性
1.层次性
黑盒理论：输入->处理->输出
设计应用：测试步骤与预期结果对应
举例：
测试步骤1--预期结果1
测试步骤2--预期结果2
2.完整性
黑盒理论：输入->处理->输出
设计应用：对输出物进行完整的检验
举例：
数据导出，如图
点击导出--弹出导出确认框
确认导出--可在导出目录下看到导出文件
---------------以下对步骤往往被忽略-----------------
打开导出文件--导出记录数正确，内容完整，准确
3.可测性
黑盒理论：预期结果 vs 实际结果 ->验证是否缺陷
设计应用：预期结果必须可测
举例：
数据查询
选择目标状态全部，输入注册时间，点击查询--列出注册时间范围内的的所有学员记录，数据正确，完整
分析：
情形一：列表的数据不是你自己造的，且测试不接触后台数据库，即数据源不知
这种情况下，预期结果的“列出所有的”，”数据正确“，”完整“，从何验证，这样的预期结果没实际意义
情形二：列表的数据是自己造的或者可通过后台查询，即数据源可知
这种情况下，预期结果的“列出所有的”，”数据正确“，”完整“是可验证的，有实际意义。
所以这里要根据实际情况来写预期结果，以情形一为例：
选择目标状态全部，输入注册时间，点击查询--列出学员记录的注册时间在给定注册时间查询范围内
4.可读性
1.数据和逻辑独立性，详见上面
2.语言描述：尽量精炼，用词恰当等
3.规范（我个人不是很赞同）
对用例中用到的元素，输入数据和非输入数据如按钮，控件等，添加标识规范，如输入数据用｛｝，类似按钮控件，链接等非输入数据用【】
例子：
在密码框中输入｛密码｝，点击【登录】按钮
关于这点我不是很赞成的，有待讨论，因为需求什么都在变，可能这个版本写“登录”，下个版本写“确认”，但是同一个意思，登录系统，所以我个人比较建议用自然语言描述，比如输入密码和用户名，登录系统，这样大大提高用例可复用性。再说了，稍微有点电脑基础的人，一看界面也应该大致知道类似删除，登录，修改之类的元素吧。。。
