测试需求分析第一部分
一、 界面中的控件知识
1 文本框和密码框
文本框
长度要求；
输入内容限制。
密码框
长度要求；
不允许明文显示；
禁止复制粘贴；
输入内容限制；
两次密码要一致。
2 单选按钮、 组合列表框 、 数码框
单选按钮
框架标题/提示文本不缺失且正确；
各个选项正确；
执行同一功能的多个单选按钮只能选中一个；
要有默认选中项；
一般不能取消选中；
存入后台的数据正确。
组合列表框/下拉列表
通常单选，条目内容要正确（没有多余/错放项、缺少项）；
横向显示要完整；
条目功能要正确实现；
组合列表框中可能允许输入数据。
数码框（up-down 控件）
能使用上下箭头控制数字变动；
数字有范围限制；
数字自动循环或者到达边界时停止；
可以直接输入数字。
3. 复选框
选项正确；
可以不选、任意选一个、任意选多个、全选；
可以取消选中；
每一个复选框功能都正确实现。
4.列表框
通常多选；
条目内容要正确（多余/错放项、缺少项）；
横向显示完整，纵向显示完整；
条目功能要正确实现。
二、 大纲法分解功能
1 大纲法
大纲法主要用于对软件进行功能拆分。
模块
包含多个功能操作的对象或功能集合，如文件（菜单）等。
功能点/功能
能独立完成一件事或一个业务。如新建、打开等。
业务流程
软件为了完成业务或完成核心功能所经历的步骤。
业务逻辑
是对业务的不同处理方式。
业务规则
如要求用户名只能用英文，5-11 个字符等。
案例
即时贴程序部分需求说明
便签的数量最多为 50 个
便签标题字数最多为 40 个字节
便签的正文文字数量最多为 200 个
年份只能设置在 1900－2100 之间
2 开始编写测试需求分析
将功能拆分与整理的需求信息写入测试需求分析
三、 测试需求分析与测试用例设计方法
1 场景法
1.1 测试点/ 检查点
测试时应该考虑可以测试的诸多方面。
1.2 场景法概述
场景法模拟用户操作软件时的情景，主要用于测试系统的业务流程。
当拿到一个测试任务时，我们先要关注它的主要功能和业务流程是否正确实现，这就需要使用场景法来完成测试。
1.3 场景的定义
场景用来描述软件操作的路径。
基本流
按照正确的业务流程来实现的一条操作路径（模拟正确的操作流程）。
备选流
导致程序出现错误的操作流程（模拟错误的操作流程）。
1.4 场景法的分析步骤
分析软件需求
从用户使用情景角度，写出业务流程和业务规则
写出基本流场景和备选流场景
1.5 场景法案例：ATM 机取款
步骤一：分析业务流程（可以绘制流程图）
步骤二：描述程序的基本流及备选流
1、基本流（正确的流程）
（1）插入银行卡：客户将银行卡插入 ATM 机的读卡器
（2）验证银行卡：ATM 机从银行卡的磁条中读取账户代码，并检查它是
否属于可以接受的银行卡
（3）输入密码：ATM 机要求客户输入密码
（4）验证密码：确定该密码是否正确
（5）进入 ATM 主界面：ATM 显示在本机中可用的各种选项
（6）选择取款并输入金额：客户选择“取款”，并选择取款金额
（7）ATM 机验证：ATM 机进行验证账户余额是否满足以及总取款金额
是否满足要求，验证 ATM 机内现金是否够用
（8）更新账户余额、出钞：验证成功，更新账户余额，输出现金，提示
用户收取现金
（9）返回主界面
2、备选流（各种错误情况）
（1）银行卡无效：提示错误并退卡
（2）密码错误：提示错误，并判断是否 3 次错误
（3）密码 3 次错误：吞卡
（4）账户余额不足：提示错误并退卡
（5）总取款金额超出当日可取限额：提示错误并退卡
（6）ATM 机余额不足：提示错误并退卡
步骤三：根据基本流和备选流生成不同的场景
3 错误推测
3.1 测试若干原则回顾
测试不是验证软件正确，而是攻击软件，发现错误。
测试要时刻保持怀疑的态度，具有缺陷预防意识。
测试要寻求系统设计、功能设计的弱点。
设计负面的、异常的测试，如考虑错误的或者异常的输入，往往可以发现更多的软件缺陷。
3.2 什么是错误推测
在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试方法。
错误推测分类
输入数据测试方面
输出数据测试方面
数据结构测试方面
文件系统方面
3.3 输入数据方面的错误推测
3.3.1 输入非法数据
一般用于键盘输入数据时。
测试方法
输入非法类型
输入非法范围/长度
输入非法格式
注意
错误信息的检查：需要额外考虑错误提示信息的内容
错误信息和错误要对应一致
错误信息不能为空
错误信息的内容不能只是错误代码，不能包含开发信息
错误信息不能中英文混合
测试需求分析第一部分相关推荐
- 测试理论-测试需求分析和设计方法
目录 一.测试需求分析 二.测试设计方法 一.等价类划分法 二.边界值分析法 三.判定表法 四.因果图法 五.正交实验法 六.状态迁移图法 七.流程分析法 八.其他方法 一.测试需求分析 1.概念:以 ...
- 全程软件测试之测试需求分析与计划
全程软件测试之测试需求分析与计划 在项目启动之后,就要着手软件项目的计划,包括软件测试计划.软件测试计划是整个开发计划的组成部分,同时,它又依赖于软件组织过程.项目的总体计划.质量文化和方针.在测试计 ...
- 功能测试与项目实战之测试需求分析与测试用例设计（重中之重）
说明:该篇博客是博主一字一码编写的,实属不易,请尊重原创,谢谢大家! 接着上一篇博客继续往下写 :https://blog.csdn.net/qq_41782425/article/details/1 ...
- 【软件测试】测试需求分析
进行测试需求分析的原因 把不直观的需求转变为直观的需求(用例图/活动图) 使得测试范围可以度量(有多少功能点,有多少功能项) 使得独立的功能点其对应的所有的处理分支可以度量 使得该系统需要测试的业务场 ...
- 测试需求分析第二部分
5.6 文件系统 方面的错误推测 5.6.1 使文件系统超载 适用于数据存储到硬盘中时. 案例 假设"软件测试工程师管理系统"要保存 10000 个工程师信息,则保存时engi ...
- linux内核测试指南 第一章
linux内核测试指南 第一章 内核,补丁,内核树 和 编译 1.1 内核 Linux内核的当前版本通常可以从linux内核档案网站(http://www.kernel.org/)以一个大的压缩文件的 ...
- 软件测试需求文档案例,软件测试如何进行测试需求分析？
作为一名软件测试工程师进行测试需求分析是非常基础的工作,一般测试需求分析是有张可寻的总结一下也就是那么几点,只要把问题考虑全面了,就会让你感觉这并是不那么困难. 1)确认功能 (业务功能.辅助功能.数 ...
- 全程软件测试之测试需求分析与计划（1）
在项目启动之后,就要着手软件项目的计划,包括软件测试计划.软件测试计划是整个开发计划的组成部分,同时,它又依赖于软件组织过程.项目的总体计划.质量文化和方针.在测试计划活动中,首先要确认测试目标.范围 ...
- 测试需求分析与测试用例设计
一. 界面中的控件知识 1. 文本框和密码框 文本框 长度要求: 输入内容限制. 密码框 长度要求: 不允许明文显示: 禁止复制粘贴: 输入内容限制: 两次密码要一致. 2. 单选按钮.组合列表框.数 ...
最新文章
- Hadoop Pipes编程之C++实现WordCount
- 【CVPR 2018】Learning Rich Features for Image Manipulation Detection(图像篡改检测)
- 新一代数据库TiDB在美团的实践
- 发送接收图片_国际空间站将在8月4-5号发送SSTV图片，普通对讲机可接收
- android 系统（155）---如何自己添加号码归属地数据库？
- MAC安装MySQL的正确姿势
- WSGI Server/Gateway
- [转]关于Linux下时间片分配给进程还是线程的问题
- python学习图解_大牛整理！Python学习方法和学习路线，看完茅塞顿开！
- 安装用户脚本的福音：Tampermonkey（油猴）
- autocad不能画图_AutoCAD经典技巧！
- 日志文件夹不存在或被删除
- Android常用框架
- 近期看到的很有意思的文章
- 神经网络机器翻译（一）
- 【正则表达式】字符与运算符
- 企业号、企业微信、企业邮箱三者融合，IBOS微信生态掘金之路
- HTML中的大于号和小于号怎样用代码打出来？
- 【LeetCode】35. 搜索插入位置---JavaScript解法
- 视频号常见问题五连问（15）