站在测试的角度看需求讲述.pptx
文本预览下载声明
站在测试角度看需求
一:需求文档所需要包括的内容
二:如何根据需求设计测试用例
三:没有需求文档的时候如何来设计测试用例
需求文档所需要包括的内容---概述
1.更改记录:对需求版本信息的跟踪;
2.项目概述:主要描述这个项目产生的背景,以及这个项目所能解决目前面临的问题;
3.需求文档编写的目的:阐述该需求文档在项目开发中所起的作用;
4.用户和角色:描述项目当中所涉及到的各角色,以及各角色的权限与作用
需求文档所需要包括的内容---需求描述
1:功能模块
1.1 概述:系统所包括的功能模块
1.2 模块描述:描述其子模块,子模块下的子功能点
1.2.1 业务概述:该子功能所包括的具体业务
1.2.2 使用者:该功能的使用者
1.2.3 输入要素:数据输入对象的描述
1.2.4 处理流程:功能操作的描述
1.2.5 输出要素:输出结果的描述
需求文档所需要包括的内容---需求描述
2:功能性需求
2.1 功能点列表
2.2 功能项描述
2.2.1 功能描述
2.2.2 典型操作
2.2.3 异常,交叉引用,约束条件,前置条件,后置条件
2.2.4 参考界面
2.2.5 数据描述:各输入对象是如何产生的
需求文档所需要包括的内容---需求描述
2:功能性需求
2.1 功能点列表
2.2 功能项描述
2.2.1 功能描述
2.2.2 典型操作
2.2.3 异常,交叉引用,约束条件,前置条件,后置条件
2.2.4 参考界面
2.2.5 数据描述:各输入对象是如何产生的
2.3 非功能性需求
2.4 质量要求
需求文档所需要包括的内容---需求描述
3 其他描述
4 附录
如何根据需求设计测试用例
整理分析需求文档:仔细将需求文档阅读一遍,记录不明白的地方及关键测试点,简单画出总体流程图。然
后再来一遍,仔细分析各个模块的功能,画出模块内流程图,找出所有功能,并列出主要测试点
如何根据需求设计测试用例---编写用例
1.按照不同的业务规则可将测试用例分为四部分:场景用例、系统用例、功能用例
2.场景用例:根据画出的模块内流程图,描述用户的主要业务目标,包含完整的系统级场景和模拟用
户实际操作的不同场景,几个功能点的组合也算是用户场景
3.系统各角色的系统用例:结合画出的模块流程图,将系统划分多个角色,再将每个角色分解为多个任务,每个任
务就是一个系统用例。系统用例分为正常流程、异常流程,分支流程,以场景的形式描述。
4.功能用例:描述单点功能的逻辑规则及页面元素,分层描述逻辑规则,对逻辑规则细化可直接作为
用例的操作步骤描述。
如何根据需求设计测试用例---报表类功能模块如何编写测试用例
1.报表类的模块基本没有业务流,不适用场景法。其实报表类模块主要验证能否依据
查询条件正确查询显示数据,并保证数据的正确性。可将测试用例分为功能点测试用例和报
表数据正确性验证。
2.编写查询功能测试用例
a.场景1:默认条件查询结果正确;
b.场景2:修改可选择输入条件查询结果正确
c.场景3:修改输入条件查询结果正确
d.场景4:组合可选条件、输入条件查询结果正确
e.场景5:错误、空记录查询结果为空
3.编写其他功能点测试用例,同样可将功能点分解多个场景。
4.编写数据正确性验证测试用例:找出影响报表的各种数据因素、列举报表展示的各种数据,列举两者编写数据正确
性验证用例。
没有需求文档的时候如何来设计测试用例
一:测试过程中一般没有需求文档的三种情况
1、开发人员的意识不足,开发流程不规范,可能是以前做项目一直都是拿到市场可行性分析,然后项目管理
人员进行简单模块划分,任务就分配下去了,更不就不写需求文档,或者只是简单书写大体功能点。
2、项目进度紧张,后期需求变动可能比较大,来不及书写详细的需求文档
3、项目是从原有项目上进行迭代开发,开发人员认为不要再进行需求文档编写。
没有需求文档的时候如何来设计测试用例---针对上述情况的个人见解
对于第一种情况:
1、测试负责人应该坚持开发没出需求文档,就不进行测试,要坚持让开发输出项目需求文档,哪怕是写的不够详细也好,最少都要输出一份简单的功能列表;
2、需求文档要进行评审,评审做会议记录,并有专门人员对需求文档进行修改;
3、最后就是测试人员进行测试需求分析,再根据测试需求点进行测试用例编写了。
没有需求文档的时候如何来设计测试用例---针对上述情况的个人见解
对于第二和第三种情况:
1、测试人员尽量找到已存在的资料,比如市场调研书,可行性分析报告,收集一切对项目有用的文档。并提出其中的功能点需求;
2、如果是迭代项目开发,则找到前期项目的一些需求文档,概要设计,详细设计,测试需求,用例等。提起里面的功能点;
3、咨询相关人员,获取项目一些大体功能,最好能知道大体项目的框架,然后记录咨
显示全部