偷懒了几天没有写写博客了，看来养成一种习惯也是需要一定的毅力的，正如软件测试的工作，看似都很烦琐的工作，但也要有一定的毅力和耐心才能做好，在测试中会不断的测试每一个包，或许每个包只fix了一些小bug，或许还有些新的bug，也会有老的未发现的bug，但测试人员面对的是几乎差别不了多少的版本，有些审美疲劳，这样很容易错过一些问题，或者把一些常见到的问题习以为常的忽略过去，这样很容易出现一些low quality的产品，所以测试人员要把每次拿到的新版本当成第一次使用产品来对待，才能更有效的找出其中的bug。一直说到找bug，那么测试人员如何发现bug?根据什么来判定bug呢？本篇博文主要想介绍如何写出好的case，既然说好的case，那首先要了解一下什么样的case可以算做好的case,好的case包括哪些内容。简单说来，用最少的语言覆盖尽可能多的路径，下面细细说明一下。
Case Table的内容主要有：
ü 测试环境要求（硬件配置、网络环境、操作系统、浏览器、语言等）
ü 测试的目标：Function, Feature , Usable 和Stable等
ü 测试的类型：Primary, Full
ü 测试的项目：针对所采取的测试方法对各项目测试的数据、参数确定；包括Case ID号、Case名称、Case描述(含Criteria)和目标（Objective）
ü Case Table要充分实现系统或产品测试的目标，满足MRD或Specification，力求覆盖所有的功能、操作路径和应用环境。
如何写出好的Case, 其基本的要点有：
ü 认真研读市场需求文档 ( MRD)和设计规范（Function Specification）
ü 深入理解产品的特性、应用范围或客户群，
ü 掌握相关计算机技术、网络技术，确定技术难点和测试重点
ü 结合软件工程、软件测试技术，确定具体得测试方法、测试思路等
ü 以用户的角度看问题，以技术角度分析问题
ü 参考以前相似的测试事例
ü UI和性能方面的往往易被忽略掉，这其实是很错误的思维，试想一下，如果一个软件功能做的很好但是界面不友好，或者非常的难看，或其性能很低下，就如一个杯子用工很好但是设计的很难看，相信不会有太大的市场，或者一个网站很好，内容丰富，但是打开一个页面要好几分钟，很难想像当用户遇到这样的网页还会有很强的耐心停留在此网站上浪费时间的，所以UI和性能方面也是不可忽略的一部分。
当然，要写好一套 Case 是一件不容易的事。以测试环境为基础，以 MRD 和 Function Specification 为标准，不是将 Function Specification 堆到 Case 中去，而是在此基础上，发挥自己的创造思维，有时候逆向思维也很重要，分析产品的特性和程序代码的弱点，寻找测试的边界条件和其它事例，并不断补充、完善，才能得到 一套覆盖率高、效率高的 Case 。