在获取需求文档后,不要马上开始编写测试用例,需要仔细推敲整理需求,绘制系统级、模块内的流程图,并找出各种测试点,等对需求进行头脑风暴后,此时已经对测试系统的功能非常清楚,然后着手编写测试用例。那写测试用例的总体思路是什么呢?经过半年的测试用例编写经验,总结如下,如有不妥之处需要改进。
1.整理分析需求文档
认真阅读需求文件文档,记录不明白的地方和关键测试点,并简单地画出总体流程图。接着再次进行,仔细分析各个模块的功能,画出模块内部流程图,找出所有的功能,并列出了主要的测试点
2.编写用例
测试用例可以根据不同的业务规则分为四个部分:场景用例、系统用例、功能用例
情景用例:根据用户的实际操作和业务逻辑来设计用例,不必涉及非常复杂的操作或逻辑,将用户常用的、正常的操作流程作为场景设计测试用例。
系统用例:是用户场景的细化,包含了正常场景、分支场景和异常场景,是由两个或多个相关功能组合而成的场景。
函数用例:用来验证业务规则的各个功能点,包括接口元素和各个功能的业务规则验证。对着一个单一的功能点。
步骤1:场景用例(关键词:模拟用户的实际操作)
在所绘制的模块内流程图的基础上,描述了用户的主要业务目标,包括了完整的系统级场景和模拟用户实际操作的不同场景,一些功能点的结合也是用户场景。
第2步:系统角色的系统用例
并结合所绘制的模块内流程图,将系统分成多个角色,又把每个角色分解成多个任务,每一个都是系统用例。系统用例将常规流程、异常流程、分支流程等划分为场景描述。
步骤3:功能性案例
阐述了单点函数的逻辑规则和页元,层次结构描述逻辑规则,对逻辑规则的细化直接作为用例的操作步骤描述。
在撰写用例时也存在一些困惑:
问1:场景法描述的方式比较清晰,以及后期需求改变的容易维护?
第二问:测试案例和测试数据之间有什么关系?这两者怎么区分呢?
3、报告类功能模块是怎样编写测试用例的?
报告的模块基本上没有业务流程,不适用场景方法。实际上报表类模块主要是根据查询条件来验证是否能正确地查询显示数据,并保证数据的正确性。测试用例可以划分为功能点测试用例和报告数据正确性验证。
步骤1:编写查询功能用例
查询函数可以分解成多个测试场景,分别验证单个场景的期望结果。可以按以下分类。
方案1:默认条件查询结果正确;
方案2:修改选择的输入条件查询结果正确
1、进入搜索(高级搜索)页面。2、逐项选取个别查询条件可选项,如:「全部」、「类别1」等,按「搜寻」,查询结果正确。组合单个查询条件可选择,如:价格+产品,点击“搜索”,查询结果正确。
方案3:修改输入条件查询结果正确
1、进入搜索(高级搜索)页面。2、逐个输入文字域条件,模糊查询值,点击“搜索”,查询结果正确。逐个输入文字域条件,精确匹配值,点击“搜索”,查询结果正确。逐字输入文字域条件,中文值,点击“搜索”,查询结果正确。5、逐字输入文字域条件,字母大、小写值,点击“搜索”,查询结果正文字域条件,数值型别,按“搜索”,查询结果正确。7、逐个输入文本域条件,全角、半角值,点击“搜索”,查询结果正确。8组合文本域中的条件查询,点击“搜索”,查询结果正确。
情景4:组合可选条件、正确的输入条件查询结果
方案5:错误、 null记录查询结果为 null
步骤二:编写其他功能点测试用例,同样可以将功能点分解成多个场景。
步骤3:写数据正确性验证测试案例
找到影响报告的各种数据因素,并列出它们所显示的各种数据,列出这两种数据的正确性验证用例。
以上是关于软件测试的知识,由多测师亲自撰写,全网独家提供!
发表评论 取消回复