如何编写好的测试用例

    做测试这么多年，写过无数个测试用例，但始终没有静下心来总结过如何编写一个好的测试用例，甚至有时候别人问起来，忽然还有点陌生不知所措的感觉了。前几天翻阅了网上的如何编写测试用例的各个版本，大概激发了一点点想法，于是简单总结一下；
    一、全面性
    1、对功能的理解，深刻理解功能对编写用例很有好处，胆小勤问，有条件的情况下看看客户的原始需求；
    2、需求逐句拆分，然后再细化，逻辑复杂的功能需要画出流程图；
    3、功能点罗列，也可以称为验收标准，目的是便于初期和开发人员沟通需求；
    4、到具体编写测试用例阶段了，细化罗列的功能点，注意事物两面性，每个功能点从反面去考虑，会出现什么情况；（这个地方涉及到很多测试用例设计方法，常用的有等价类、边界值等等）
    5、如果与其他模块有关联的功能，需要考虑场景回归测试；
    二、正确性
   1、包括数据正确性和操作正确性，首先保证输入数据和输出数据正确，其次操作步骤要正确；
    三、易用性和可维护性
    1、测试用例包含基本要素：用例标题、预置条件、操作步骤、预期结果。整个用例可以做到：一个不懂业务的人员能看懂用例，这样就增加了易用性和后续人员的可维护性；

没思路了，后续再补充
。。。。。。。。。。。
继续测试用例编写实战（中间可能会穿插测试用例设计方法的描述）：
从拿到需求开始---分析需求---功能点罗列（也可叫功能块划分）---细化功能块并生成用例---用例评审---修改用例---确认并入测试用例库；
具体例子：

大数据日志分析处理（后台）

一、需求描述（这个需求比较简单只有一句话）
 乐视网日志需要支持一种新的日志发布格式：letv，新日志格式为：#$server_addr:$server_port $remote_addr [$time_local] "$log_for_ts" $status 
二、需求分析
OK，拿到需求，开始分析，主要分析点：1、一种新的发布格式，那么需要配置管理系统（logcms）发布接口新增一种发布格式：letv；2、日志发布系统（adam_publish）处理日志并转化为客户需要的日志格式；3、分析新日志格式的各个字段含义以及数据来源于原始日志的哪些字段；4、有没有和其他模块关联（回归测试要考虑的）；
三、功能点罗列
logcms系统：1、发布接口api新增一种发布格式，名字：Letv; 2、单接口功能不需要系统功能回归测试；
adam_publish系统：1、新日志格式各个字段取值正确；2、此日志格式不会影响到其他日志发布格式的正确性（利用等价类随机选取一种原有的日志发布格式回归测试）；
四、用例设计
logcms系统：
1、用例标题：检查新增Letv日志格式名称显示是否正确；
    //前置条件：安装部署新的Logcms程序，配置频道A的日志发布格式为letv；
     //操作步骤：浏览器输入api接口地址，查看返回的json字符串接口，查看日志发布字段显示名称；
     //预期结果：日志发布字段名称显示为letv；
adam_publish系统：
1、用例标题：检查新增日志格式字段server_addr，server_port，remote_addr [$time_local] ，$log_for_ts" $status取值是否正确；
    //前置条件：1、安装部署新的adam_publish系统，配置Logcms接口地址；2、上传原始日志到/fc/src/目录；3、原始日志server_addr，server_port，remote_addr [$time_local] ，$log_for_ts" $status字段存在不同的值；
    //操作步骤：运行adam_publish程序，/fc/pub/目录查看运行结果；
    //预期结果：server_addr，server_port，remote_addr [$time_local] ，$log_for_ts" $status按照原始日志IP显示；
2、回归用例挑选，挑选w3c日志格式发布的任意一条用例执行，查看结果是否有影响；

举例子只是理清下思路，不了解此业务的可能会不太明白内容，可以忽视内容；整理后感觉心情舒畅多了，没有那么乱了。后续继续补充例子，前端的，涉及到测试用例方法的例子；