聊一聊我工作四年我对功能测试用例设计思路

lsekfe

我们为什么要写好一份测试用例呢？测试同学应该都知道测试用例的重要性，测试用例就是我们测试的依据，也是测试过程中不能缺少的测试文档。
　　一、用例编写规范目的：
　　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，以便后续查看。

ake9527

实践出真知，字字灼见

404688312

大善，点赞