测试用例是测试的指导文档，是保证产品的基本武器，同时也是测试人员的主要输入成果，因此保证测试用例的有效性及时时性就显得尤为重要。哪么我们如何尽可能的保证测试用例的有效性及及时性呢?
一、明确项目的进度及计划
只有明确了项目的进度及计划，我们才知道应当在何时进行测试用例的编写，何时完成测试用例的编写。以保证在测试执行时，至少已经有了第一版本的测试用例。同时也可以避免因时间仓促而草草编写的测试用例。另外，测试用例编写任务的下达必须要明确完成的时间及需要达到的目标，没有时间限定及目标的测试用例编写将是低效的。
二、提供产品的相关文档
正所谓“巧妇难为无米之炊”，要求测试人员编写测试用例，就必需要为提示人员提供尽可能多的产品相关信息，如软件需求说明书、市场同类产品信息、市场反馈的相似产品的主要问题、软件及硬件环境，甚至于开发人员联系方式及项目的主要负责人信息等。这些信息都将有力的推动测试用例的有效性。
三、深入理解产品的相关文档
在正式编写测试用例之前，需要深入理解产品的相关文档。虽然需求分析人员都具有一定的产品规划能力，但是也有可能会犯错。很难想像根据一份有瑕疵的、甚至是严重错误的需求文档编写出来的测试用例是有着多么可怕的“指导”作用。因此我们在编写测试用例之前，需要深入的理解产品的相关文档。建议可以采用会议的方案来进行，各自提出自己的见解，经过讨论会将相关的疑问提前给需求分析人员重新确认。同时将这些疑问作为BUG进行提交，记住这也是工作成果的一部份。一份完美的需求应该不存在任何的歧义或含糊的地方。
四、编写测试用例概要
在充分的理解产品的相关文档之后，就可以正式编写测试用例的概要了。之所以没有要求进行详细测试用例的编写，主要是出于编写测试用例时间的压力及评审的需要。由于测试人员的工作除了编写测试用例以外，还要进行日常的测试工作及各类报告的书写，工作量大且相对繁琐，因此应当尽量的控制编写测试用例的时间，以保证测试人员有充分的休息时间。同时对于一份详尽的、完整的测试用例而言，对于进行评审是很不经济的(试想一下，让你对1000个详尽的测试用例进行评审，你会作何感想?)。
测试用例的概要应该简洁明了，只需要说明验证点即可。同时在编写测试用例的概要时，尽量反映时编写测试用例的基本思路。对于100个测试用例概要进行分别评审比对10类(每类10个)的测试概要进行评审要困难得多。
测试用例概要可以采用如下格式：
//以下X个测试用例用于验证XX问题：
◎ 验证……
◎ 验证……
◎ 验证……
◎ 验证……
……
五、测试用例的评审
在测试用例概要编写完成之后，下一步的工作就是进行测试用例的评审。个人对产品的理解及经验始终是有限的。测试用例的评审的主要目的就是集众人的经验及认识于一体，对测试用例进入查漏补缺，使得测试用例的有效性进一步提升。
尽管我们采用了测试用例概要及用例概要分类的方法来简化测试用例，明确测试用例编写的思路。但是对于一些比较大型的项目，其需要评审的内容仍然是巨大的。因此我们需要在测试评审开始前做好如下准备：
1. 提前至少一天将需要评审的内容以邮件的形式发送给评审会议相关人员。并注明详审时间、地点及偿参与人员等。
2. 在邮件中提醒评审会议相关人员至少简读一遍评审内容，并记录相关的疑问，以便在评审会议上提出。
3. 会议主持者(一般为用例编写人员)应在会议前整理相关疑问，以便在会议上提出。
在会议进行时，会议主持者应尽量把握会议进度，尽量按时有效的完成评审工作。在评审会议结束后，应提交会议记录，会议记录应由与会人员签字确认，以说明测试用例评审是一件严肃而认真的事情。用例编写人员在会议结束后应根据会议中提出的问题及疑问，对测试用例进行优化。
六、细化测试用例
经过测试用例的评审，并对测试用例进行优化之后就可以进行测试用例的细化工作了。测试用例的细化并没有标准的形式，依各个公司的不同而有所不同，但主要都包含了操作步骤、预期结果等。
测试用例的细化就是根据测试概要，对各个验证点的前置条件、操作步骤、预期结果进行完善以适应公司测试招待的要求。对于自动化测试，在测试用例细化时应提示相关的测试脚本文件。
好的测试用例应该是具体完全的指导性，且无二义的。为了保证测试用例指导的唯一性，在测试用例细化完成后，应与测试组长进行抽查(或者与同事之间进行相关检查)。在发现问题时应及时要求测试用例编写人员进行整改。
七、测试用例长期更新
没有任何事物是一成不变的，测试用例也是如此。在进行具体的测试之后，测试人员将对产品的需求及功能等产生最为深入的理解，对于这些有用的理解应及时将其更新至测试用例中，同时对于一些不是在测试用例中发现的BUG，可根据其对价值考虑是否需要将其更新至测试用例中。测试用例在整个产品的测试过程中应一直保挂动态的更新，甚至当项目结束以后，对于市场上反馈的有价值的问题，也应及时更新至测试用例表中，直到产品退出市场为止。
| 
