<如何编写有效测试用例>这本书里面有很多概念很不错,每读一遍都有收获.下面从what 和how讲一下这本书关于编写测试用例的那些好的观点
什么是好的测试用例？(what)
一、 多写海平面以上的用例
海平面以上的用例,是指多从用户的意图出发去编写用例,而不是拘泥于某个用户操作界面。这里书中写了个小技巧：每次编写用例可以多问自己，执行者执行完此用例可以达到什么目的。判断的标准可以是以下
1、执行者执行完一次用例可以愉快离开
2、 执行者(雇员)多次执行这一用例可以加薪
3 、一个人在一个地方执行2-20分钟的操作
二、 有考虑项目相关人员的利益
什么是项目相关人员？常见的有客户,操作这个系统的主要执行者(雇员) ,还有经常漏掉的雇员的老板。其实老板的权限应该比雇员高,不仅能有雇员的操作权限,还有更高一级。只有老板才能解锁的权限。常见的项目相关人员及利益有以下:
1 、公司的利益：保证主执行者不能免费得到某些利益，或得为他所得付费
2 、管理部门利益：确保公司能够遵循一定的准则，然后保存某种类型的数据
3 、项目相关人员的典型利益：从事务失败恢复机制收益，需要更多记录。
三、.用例的合理划分
用例长度:一般用例的长度一般在5～9个步骤比较合适，如果长度过短就要考虑用例的层次是否过低，那就要多问自己用户的意图，以此来获得更高层次的用例。如果用例过长就要考虑是否步骤划分太细小，这个时候就可以考虑将一些步骤进行合并。
用例的扩展:一般把失败的步骤都写在这里,方便维护
基用例和子用例:适当使用基用例和子用例可以让文档更精简和清晰,可以使用超链接链接起来
如用户寻找一件失物,这里可以链接到子用例.
四、 关于条形裤
用例无论有多少场景，总共有只有两种结局：成功和失败，而走向成功和失败有很多场景和路径，殊途同归，就像条形裤一样。
五、 良好的用例编写格式
好的用例编写语言习惯：
1 使用简单语法（不要遗漏了主语）：
主+谓+宾+前置短语 eg： 系统...从用户余额中扣除...一定数量
2 明确写出“谁控制球”
在同一个场景使用相同的结构，执行者就像球员，是主语，而球是执行者和执行者传递的信息或数据。
3、从俯视的角度来编写用例
为了避免出现从系统内部去看待世界这种思维定式，可以学会用俯视角度来编写用例，像编剧描写一部剧一样。
比如
用户：插入ATM卡并输入PIN
系统：从用户金额扣除一定数量
4、显示过程向前推移
可以将一些由同个执行者执行又处于同个方向操作步骤小的操作（靛青色的用例）进行合并，避免用例文档过长的情况
5、显示执行者的意图而不是动作
6、包含合理的活动集
7、“确认而不是检查是否”
“确认”这个动词比“检查是否“更能体现过程更进一步的过程和系统的意图。
8、可选择地提及时间限制
大多数的用户步骤都是紧跟上一步，但是有时候也会这么写
在步骤3和步骤5的任何时候，用户将......
9 习惯用语“用户让系统A和系统B交互”
笨拙的写法：用户通知系统B获取数据
系统B从系统获取数据
好的写法：用户命令系统B从系统获取数据（体现了谁控制球）
10 习惯用语：循环执行步骤X到步骤Y，直到条件满足
为了让场景容易阅读，可以把循环重复步骤放在步骤的后面
eg 1、顾客提供账号名字或地址
2、系统查出用户的爱好
3、用户选择一个商品，并做一个购买标记
4、系统把用户选购的商品放入购物车
顾客 重复步骤3~4，直到顾客选购完所有的商品
5 顾客购买完购物车的商品
六、关于用例的扩展
扩展条件就是在一些条件下系统会完成不同的动作，之所以用扩展，是因为有失败和成功两种情况。
用“检测到什么”来编写条件，不要写什么顾客忘记密码，系统是不可能发现顾客忘记密码，系统只能检测到等待时间超出了限制，应该这样写，系统检测到用户输入密码等待时间超出限制。
如果使用编号，可以在编号后面加上字母，像2a 2b什么的
我们可以采用一个简单简短的主成功场景和一个扩展列表，为了避免列表过长，可以采用以下方法
1、删除多余的条件，按照以下两个标准，判断哪些不符合以下标准的条件便可以删除。
a 系统能检测到条件
b 系统必须完成的检测的条件
2、可以合并对系统来说等价的条件，可以合并一些低层次的失败用例。
3、扩展用例常见的有调用子用例和基用例的扩展。
判断是用子用例还是基用例的扩展可以采用以下标准判定。
如果触发条件包括了基用例应负责的事件：即基用例知道什么时候/在什么地方调用第二个用例，应该采用调用子用例的方式
如果触发条件包括了第二个用例应负责的事件：即第二个用例知道什么时候/在什么地方调用第二个用例，采用扩展基用例的方式
4、尽量不要用扩展用例，后期维护比较麻烦。
下面是关于如何编写有效测试用例的一些干货(how)
1 、 每个用例都是一篇散文
2 、使用用例易于阅读，可以按照以下一些技巧来达到这个目的
a 让用例短小，切题
b 从头开始，以一条主线贯穿始终，顶部是对全局有重要意义的用例，并分离出用户用例和最终子用例
c 用动词短语来编写用例，这些动词表明了这些用例想要达到的目的
d 从触发条件开始一直继续，直到目标被实现或取消，并且系统完成与这次事务处理相关的记录的保存
e 用完整的主动语态语句来描述所要完成的子目标
f 确保每一步执行者及其意图是可见的
g 突出失败条件，使失败恢复动作可读，最好不必为每个步骤编号，人们可以清楚知道下一步要做什么
h 将可选的行为放在扩展部分而不是放在用例条件的主体语句中
i 只有在非常必要的情况下扩展用例
3 仅用一种句型，主用例和扩展可以用不同语法格式用于区分
主用例格式： a 现在时态语句
b 在主动语态用主动动词
c 描述执行者成功到达某个目标，这个目标推动了整个过程的前进
扩展格式： a 采用过去时态
b 采用句子片段而不是完整句子
c 用冒号结束而不是句号结束
4、 包含子用例
5 、谁控制球
6 、正确得到目标层（更高层次、海平面以上）
7 、不考虑GUI界面（避免写死后后面一旦更改给维护带来负担）
8 、两个结果：成功和失败
9 、项目相关人员需要的保证（利益、最小成功保证）
10 、前置条件
11 、对用例的通过和失败进行测试
关于<编写有效测试用例>这本书的一些表也值得推荐，在文中的P97的11章
输入输出表
系统设计范围表
用户目标级别表
书里还介绍的一种很特别的方法，对于前期写用例能够更好地提供思路：写故事
给自己的用户写几个故事，往往会有意想不到的效果。
最后是日常工作的时候,我领悟到的一些方法
1 前期梳理业务:思维导图
所需要的工具非常简单：一只笔,一张白纸。
可以按照主成功场景,写执行者执行步骤,.画一个路径图,注明下一步的出发条件,开启分支则注明分支条件,对于前期梳理业务非常有帮助。
2 编写文档时,可以先写主成功场景,写完后,在扩展这一下失败场景,不容易乱
前期以主成功的业务场景为主，不要把自己过多陷入各种失败场景中，只会把自己绕晕。最好的方式是先把业务关系梳理清楚再去扩展失败的场景丰富用例。
3、多写海平面以上的例子，这也是书中一直强调，这有个好处，就是既可以精简用例，又可以在阅读用例的时候留下想象的空间，更好地去提问，去发现问题，而底层用例不仅用例多而且不利于思考。
4、借鉴文中的编写格式,可以更好维护测试文档。尤其在需求变更很快的情况下,可以更好地应对。