测试用例制度及规范

  测试用例是测试的基础,很多测试说点点点没技术含量,其实这样理解是不正确的,我觉得功能测试才是最重要的,至少你没听说过有公司不做功能测试吧?而且,自动化、性能、安全等测试,都是功能测试主流程稳定后才开始的,特别提出测试用例制度及规范,快速编写测试用例,管理测试用例,才能为后面的自动化、性能、安全保驾护航!
测试用例要素
1、测试用例编号
2、测试标题
3、所属模块
4、测试需求项编号
5、案例状态
6、预置条件
7、优先级
8、测试输入
9、操作步骤
10、预期输出
11、实际结果
12、案例设计者
13、设计日期

要求

  • 测试标题:【必填项】用概括语言描述测试用例的测试点,达到一目了然。
  • 测试需求项编号:【必填项】测试用例都是根据需求来的,对于用例的来源必须追溯源头,确保其正确性;
  • 预置条件:【必填项】执行当前测试用例的前提描述,如不满足这些条件,则无法进行测试。若无预置条件,可标注“无”;
  • 优先级:【必填项】分为高中低,对于高级别,大概占比用例的20%,对于中低级别占比用例的80%;
  • 测试输入:数据准备
  • 操作步骤:执行当前测试用例所要经过的操作步骤,需要给出每一步操作的详细描述。
  • 预期输出:当前测试用例的预期输出结果,用来与实际结果比较;
  • 实际结果:当前测试用例的实际输出结果,用来与预期输出比较,如果相同则测试通过,否则测试失败。

用例编写原则

  • 功能或流程划分时,一定要简单、清晰,一个测试用例只检查一个功能或一个流程;否则测试用例会比较混乱,降低可读性;
  • 测试用例要有一个简单直观的名字,有助于读者对测试用例的理解。
  • 测试用例的步骤描述要简单、清晰,一步就是一步。
  • 测试用例的数据要明确,特别是输入数据和期望结果;
  • 测试用例需要保障唯一性,即功能用例之间不存在重叠,流程用例不存在包含关系。没有重复、冗余的测试用例,满足相应的行业标准。
  • 描述要清晰、包含特定的场合、对象和术语,没有含糊的概念和一般性的描述。应尽量避免不确定的用词,如:如果、若、否则、大概、可能等。
  • 测试用例中保证,正常用例:异常用例=1:2;
  • 测试用例应确保覆盖详细设计的所有功能。但功能用例要覆盖所有数据操作处理的功能点;流程用例要尽可能的覆盖程序的各种路径,考虑存在跨年、跨月的数据,兼顾各种业务变化的可能。
  • 对于无输入的操作,应该详细描述其具体的操作步骤和结果。
  • 测试用例需要保障数据的正确性和操作的正确性;首先保证测试用例的数据正确,其次预期的输出结果应该与测试数据发生的业务吻合,操作的预期结果应该与程序发生的结果吻合。

用例创建原则

  • 创建主用例目录时,需要根据功能模块或者流程模块进行创建;如下图:
    image.png
  • 编写迭代用例时,根据迭代号创建目录,子目录跟之前创建的功能模块或流程模块吻合,如下图:image.png
  • 迭代结束后,快速把迭代用例合并至主用例目录中,保证主目录的用例完整及最新状态;
发布了32 篇原创文章 · 获赞 3 · 访问量 1080

猜你喜欢

转载自blog.csdn.net/lolo_zhu/article/details/100925302