软件测试四年,总结下功能测试用例设计思路

发表于:2023-4-07 10:00

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:Charming    来源:知乎

分享:
  我们为什么要写好一份测试用例呢?测试同学应该都知道测试用例的重要性,测试用例就是我们测试的依据,也是测试过程中不能缺少的测试文档。
  一、用例编写规范目的:
  1、提高测试用例的可读性,可执行性、合理性。
  2、测试用例,会被开发、产品等阅读审查或执行;也更可能被其他测试人员或者新员工作为熟悉当前产品的可靠依据,是可以不看需求不看交互最直接的、最快速的了解产品的文档。
  二、设计用例过程:
  1、参加需求评审会议:即产品讲解需求,需求中包含需要实现的功能。
  a、需求评审前要大致看一遍需求文档,对于有疑惑不明白的语句做好标记;
  b、参加需求文档评审会议时,紧跟产品思路,了解需求背景,需求内容等。并且一边听一边在脑海中形成产品形态,发现不合理和有疑问的地方及时提出并督促产品解决;
  c、会议当场确定测试范围、确定各需求的测试优先级、确定测试的通过标准。
  2、逐字逐句解读需求文档,熟悉业务需求(组织或客户高层次的目标)、功能需求(规定开发人员必须在产品中实现的软件功能)、用户需求(从客户角度出发,用户的目标,或用户要求系统必须能完成的任务)
  a、拆分需求点,梳理功能模块:
  业务功能:与用户实际业务直接相关的功能
  数据约束:数据的显示范围、数据之间的关系
  权限约束:不同角色权限对功能的处理
  编辑约束:对数据输入项的要求限制
  辅助功能:辅助完成业务功能的一些功能或者是细节
  易用性需求:易于使用的功能细节
  性能约束:执行功能时必须满足的性能需求
  3、书写测试用例
  一、设计原则:
  a、测试用例应全部覆盖需求文档里面的各项功能。
  b、真实场景的需求及模拟:测试点在编写的过程中,一定要考虑真实使用场景
  c、测试用例设计应关注新增需求对原有各项功能的影响
  d、测试用例设计应关注关联/复用模块,功能相互影响模块
  e、测试用例的设计应包括各种类型的测试用例。在设计测试用例的时候,除了满足系统基本功能需求外,还应该考虑各种异常情况、边界情况和承受压力的能力
  f、划分系统/功能模块,按模块分类进行编写
  g、测试用例对测试功能点、测试条件、测试步骤、输入值和预期结果应该有准确的定义。在什么页面,点击什么按钮、输入什么数据
  二、编写内容
  a、用例名称:1)常用的结构“主、谓、宾”;2)名称简洁易懂,不要包括具体操作步骤;
  b、前置条件:1)执行用例测试步骤前需要做的所有必备条件,原则上所有用例都有前置条件;2)完整清楚,包括入口、帐号类型、账号权限、数据准备等
  c、操作步骤:1)操作步骤描述清晰。如:在什么页面,点击什么链接或按钮;页面入口、链接、按钮名称都要写清楚;2)操作和结果是一一对应的,但操作中不要包含结果的检查;3)用例描述中不允许出现假设性词汇,比如:假如,或许,可能,…的时候等;
  d、预期结果:1)原则上每个用例必须要有预期结果,结果不能为空;2)结果中只能包含结果,不能有步骤;3)一个结果有多个检查点时,确保检查点完整;
  最后,测试用例的维护也是不可缺少的,我们当前项目结束后要及时归档,上传的svn或者qc,以便后续查看。
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号