编写有效的软件测试用例及如何进行用例评审

发表于:2010-12-06来源:作者:点击数: 标签:软件测试评审编写
编写有效的 软件测试用例 及如何进行用例评审 软件测试 测试用例是测试的指导文档,是保证产品的基本武器,同时也是 测试人员 的主要输入成果,因此保证测试用例的有效性及时时性就显得尤为重要。哪么我们如何尽可能的保证测试用例的有效性及及时性呢? 一、

  编写有效的软件测试用例及如何进行用例评审 软件测试

  测试用例是测试的指导文档,是保证产品的基本武器,同时也是测试人员的主要输入成果,因此保证测试用例的有效性及时时性就显得尤为重要。哪么我们如何尽可能的保证测试用例的有效性及及时性呢?

  一、明确项目的进度及计划

  只有明确了项目的进度及计划,我们才知道应当在何时进行测试用例的编写,何时完成测试用例的编写。以保证在测试执行时,至少已经有了第一版本的测试用例。同时也可以避免因时间仓促而草草编写的测试用例。另外,测试用例编写任务的下达必须要明确完成的时间及需要达到的目标,没有时间限定及目标的测试用例编写将是低效的。

  二、提供产品的相关文档

  正所谓“巧妇难为无米之炊”,要求测试人员编写测试用例,就必需要为提示人员提供尽可能多的产品相关信息,如软件需求说明书、市场同类产品信息、市场反馈的相似产品的主要问题、软件及硬件环境,甚至于开发人员联系方式及项目的主要负责人信息等。这些信息都将有力的推动测试用例的有效性。

  三、深入理解产品的相关文档

  在正式编写测试用例之前,需要深入理解产品的相关文档。虽然需求分析人员都具有一定的产品规划能力,但是也有可能会犯错。很难想像根据一份有瑕疵的、甚至是严重错误的需求文档编写出来的测试用例是有着多么可怕的“指导”作用。因此我们在编写测试用例之前,需要深入的理解产品的相关文档。建议可以采用会议的方案来进行,各自提出自己的见解,经过讨论会将相关的疑问提前给需求分析人员重新确认。同时将这些疑问作为BUG进行提交,记住这也是工作成果的一部份。一份完美的需求应该不存在任何的歧义或含糊的地方。

  四、编写测试用例概要

  在充分的理解产品的相关文档之后,就可以正式编写测试用例的概要了。之所以没有要求进行详细测试用例的编写,主要是出于编写测试用例时间的压力及评审的需要。由于测试人员的工作除了编写测试用例以外,还要进行日常的测试工作及各类报告的书写,工作量大且相对繁琐,因此应当尽量的控制编写测试用例的时间,以保证测试人员有充分的休息时间。同时对于一份详尽的、完整的测试用例而言,对于进行评审是很不经济的(试想一下,让你对1000个详尽的测试用例进行评审,你会作何感想?)。

  测试用例的概要应该简洁明了,只需要说明验证点即可。同时在编写测试用例的概要时,尽量反映时编写测试用例的基本思路。对于100个测试用例概要进行分别评审比对10类(每类10个)的测试概要进行评审要困难得多。

  测试用例概要可以采用如下格式:

  //以下X个测试用例用于验证XX问题:

  ◎ 验证……

  ◎ 验证……

  ◎ 验证……

  ◎ 验证……

  ……

  五、测试用例的评审

原文转自:http://www.ltesting.net