软件测试入门.pptx
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
但是对于测试人员或用户来说可能却是 非常头痛和不方便的
形象类问题
这类问题一般是表面上的，技术含量不高，但是给予用户的 感觉往往是软件不够专业…… ❖1.不符合用户操作习惯。如，快捷键定义不科学（不易理 解、与系统快捷键冲突等）、不实用(键位分布不合理、按 键太多，甚至没有快捷键等)； ❖2.风格的统一性；对于同一个系统，同一系统环境下的应 用程序出现不同的界面风格和操作风格，对用户来说是一大 考验，对开发者来说是专业性和正规性的表现。
测试执行的步骤：维护
测试评估的目标
❖提交量化的测试覆盖域及缺陷跟踪报告 ❖评估软件质量
测试评估的内容：覆盖域
❖哪些测试需 求经过了测试
❖哪些需求通 过了测试
❖我们的工作 进度及效率如 何
测试评估的内容：缺陷
❖我们发现了哪 些缺陷
❖我们解决了哪 些缺陷
❖遗留缺陷对软 件有何影响
测试评估：综合评价
应用程序
白盒测试又称结构测试、逻辑驱动测试 或基于程序本身的测试，也可称为测试 员测试，主要应用于结构化开发环境。
软件测试方法：黑盒测试
黑盒测试又称功能测试、数据驱动测试或基 于规格说明的测试，也可被称为用户测试， 主要应用于快速应用开发（RAD）环境。 RAD：Rapid Application Development
测试计划：定义测试需求
用户需求
定义
测试需求
根据用户需求定义并完善测试 需求，以作为整个测试的标准
测试计划：考虑测试内容
❖系统功能 ❖用户界面 ❖系统性能 ❖加载测试 ❖强化测试 ❖容量测试 ❖配置测试 ❖安装测试
测试设计的目标
❖定义自动测试过程 ❖选择适当的测试用例 ❖组织测试过程信息，并传递给测试开发 人员
测试执行的目标
❖执行测试 ❖检查测试结果 ❖研究并组织测试结果以便评估 ❖维护缺陷记录
测试执行的步骤：单元
测试执行的步骤：模块
测试执行的步骤：集成
测试执行的步骤：系统联调
测试执行的步骤：验收测试
❖系统联调成功后， 系统便可以进入试运 行阶段。
❖经过相对时间的系 统试运行后，如果系 统运行正常。便可进 行用户验收测试阶段。
❖3.为了达到某个设置或对话框，用户必须做许 多冗余操作（如对话框嵌套层次太多）； ❖4.不能记忆用户的设置或操作习惯（如用户每 次进入都需要重新操作一次初始环境）； ❖5.使用不完善的功能且不给用户以恰当的提示； ❖6.不经用户确认就对系统或数据进行重大修改；
稳定性问题
往往是在设计时考虑不周而造成的一些问题。 ❖1.不可重现的死机，或不断申请但不完全释放 资源，系统性能越来越低； ❖2.主系统和子系统使用同样的临界资源而互相 不知道（如：使用同样的类名或临时文件名、使 用同样的数据库字段名或登录帐号）； ❖3.不能重现的错误（如不检查异常情况(如内存 申请不成功、网络突然中断或长时间没有响应) 导致错误等）；
❖2.界面中的信息不能及时更新，不能正确反映数据状态， 甚至对用户产生错误的误导（如：记录个数、参数设置对 话框中的缺省值等）；
可用性问题（续）
下面是一些低效的用户界面的例子： ❖1.表达不清或过于模糊的信息提示； ❖2.要求用户输入多余的、本来系统可以自己得到的数据 （如：安装后用户要手动修改某些配置文件）；
❖3.界面中英文混杂，经常弹出莫名其妙的信息， 甚至还拼错单词；
❖4.提示、标题等不够专业，或各处描述不一致；
形象类问题（续）
❖5.界面元素的位置：缺省认为用户使用某种分辨率， 导致在其他分辨率下显示不正常； ❖6.说明书或帮助的排版格式不专业：中英文搭配不对、 标点符号全角半角部分、没有排版禁则… ❖7.程序名/路径名不规则（比如为程序员的名字等）； ❖8.没有安装程序、或安装程序不完善(丢掉一些必要的 模块或文件)； ❖9.界面元素参差不齐，文字不能完全显示，TAB键顺 序与使用顺序不一致等；
RAD为软件测试带来新的挑战
❖软件结构越来越复杂 ❖团队规模越来越大 ❖开发成本与风险越来 越高
❖用户对应用程序的质 量要求越来越严格
软件测试生命周期
软件测试的阶段组成
测试计划
测试设计
测试开发
测试评估
测试执行
测试计划的目标
❖收集并组织测试计划信息 ❖将软件细化为可检验的测试需求 ❖建立测试计划
…………
可用性问题
用户比开发或测试人员在接触界面上要花费更多时间。错 误和低效的用户界面的影响会变得越来越大，最终甚至会 掩盖了产品有用的方面。 下面是一些用户界面错误的例子：
❖1.输入无合法性检查和值域检查，允许用户输入错误的 数据类型（有时只需要选择合适的输入控件即可，比如日 期用专门的日期输入控件），并导致不可逆料的后果；
测试入门
软件测试目的
❖ 测试是一个为了寻找错误而运行程序的 过程
❖ 一个好的测试用例是只可能找到迄今为 止尚未发现错误的用例
❖ 一个成功的测试是揭示了迄今为止尚未 发现的错误的测试
软件测试方法分类
两种测试方法从不同的角度出发， 反映了软件的不同侧面，也适用于
不同的开发环境。
软件测试方法：白盒测试
测试模式
错误分级－严重性
我们一般把发现的错误(Bug)/缺陷(Defect)按严重性分为4类：
1.严重：系统崩溃或挂起等导致系统不能继续运行；
2.主要：使系统不稳定、或破坏数据、或产生错误结果，而 且是常规操作中经常发生或非常规操作中不可避免的主要问 题；
3.次要：系统性能或响应时间变慢、产生错误的中间结果但 不影响最终结果等影响有限的问题，如：显示不正确但输出 正确；
测试设计
用户需求
定义 决定
选择
测试需求
测试用例 测试过程
测试开发目标
❖建立可重用的自动测试 ❖维护测试对于测试需求的可跟踪性
ห้องสมุดไป่ตู้ 测试开发技术：编程
优势： 具有较大的灵活性
缺点： 编程过程复杂
测试开发技术：录制
优势： 操作简单、快捷
缺点： 灵活性较差
测试开发技术
录制
自动生成
脚本
脚本生成自动化，并可根据需要修改
4.轻微：界面拼写错误或用户使用不方便等小问题或需要完 善的问题；
错误分级－优先级
我们也把发现的错误按优先级分为三种： 1.高：立即修改； 2.中：必须修改，但不一定马上修改； 3.低：允许不修改；
一般来说是越影响用户接受或使用该产 品的错误优先级越高。
常见问题
下面将列出一些问题，他们具有一些特征： 显而易见的 开发时容易被忽略 容易避免 容易修改
形象类问题
这类问题一般是表面上的，技术含量不高，但是给予用户的 感觉往往是软件不够专业…… ❖1.不符合用户操作习惯。如，快捷键定义不科学（不易理 解、与系统快捷键冲突等）、不实用(键位分布不合理、按 键太多，甚至没有快捷键等)； ❖2.风格的统一性；对于同一个系统，同一系统环境下的应 用程序出现不同的界面风格和操作风格，对用户来说是一大 考验，对开发者来说是专业性和正规性的表现。
测试执行的步骤：维护
测试评估的目标
❖提交量化的测试覆盖域及缺陷跟踪报告 ❖评估软件质量
测试评估的内容：覆盖域
❖哪些测试需 求经过了测试
❖哪些需求通 过了测试
❖我们的工作 进度及效率如 何
测试评估的内容：缺陷
❖我们发现了哪 些缺陷
❖我们解决了哪 些缺陷
❖遗留缺陷对软 件有何影响
测试评估：综合评价
应用程序
白盒测试又称结构测试、逻辑驱动测试 或基于程序本身的测试，也可称为测试 员测试，主要应用于结构化开发环境。
软件测试方法：黑盒测试
黑盒测试又称功能测试、数据驱动测试或基 于规格说明的测试，也可被称为用户测试， 主要应用于快速应用开发（RAD）环境。 RAD：Rapid Application Development
测试计划：定义测试需求
用户需求
定义
测试需求
根据用户需求定义并完善测试 需求，以作为整个测试的标准
测试计划：考虑测试内容
❖系统功能 ❖用户界面 ❖系统性能 ❖加载测试 ❖强化测试 ❖容量测试 ❖配置测试 ❖安装测试
测试设计的目标
❖定义自动测试过程 ❖选择适当的测试用例 ❖组织测试过程信息，并传递给测试开发 人员
测试执行的目标
❖执行测试 ❖检查测试结果 ❖研究并组织测试结果以便评估 ❖维护缺陷记录
测试执行的步骤：单元
测试执行的步骤：模块
测试执行的步骤：集成
测试执行的步骤：系统联调
测试执行的步骤：验收测试
❖系统联调成功后， 系统便可以进入试运 行阶段。
❖经过相对时间的系 统试运行后，如果系 统运行正常。便可进 行用户验收测试阶段。
❖3.为了达到某个设置或对话框，用户必须做许 多冗余操作（如对话框嵌套层次太多）； ❖4.不能记忆用户的设置或操作习惯（如用户每 次进入都需要重新操作一次初始环境）； ❖5.使用不完善的功能且不给用户以恰当的提示； ❖6.不经用户确认就对系统或数据进行重大修改；
稳定性问题
往往是在设计时考虑不周而造成的一些问题。 ❖1.不可重现的死机，或不断申请但不完全释放 资源，系统性能越来越低； ❖2.主系统和子系统使用同样的临界资源而互相 不知道（如：使用同样的类名或临时文件名、使 用同样的数据库字段名或登录帐号）； ❖3.不能重现的错误（如不检查异常情况(如内存 申请不成功、网络突然中断或长时间没有响应) 导致错误等）；
❖2.界面中的信息不能及时更新，不能正确反映数据状态， 甚至对用户产生错误的误导（如：记录个数、参数设置对 话框中的缺省值等）；
可用性问题（续）
下面是一些低效的用户界面的例子： ❖1.表达不清或过于模糊的信息提示； ❖2.要求用户输入多余的、本来系统可以自己得到的数据 （如：安装后用户要手动修改某些配置文件）；
❖3.界面中英文混杂，经常弹出莫名其妙的信息， 甚至还拼错单词；
❖4.提示、标题等不够专业，或各处描述不一致；
形象类问题（续）
❖5.界面元素的位置：缺省认为用户使用某种分辨率， 导致在其他分辨率下显示不正常； ❖6.说明书或帮助的排版格式不专业：中英文搭配不对、 标点符号全角半角部分、没有排版禁则… ❖7.程序名/路径名不规则（比如为程序员的名字等）； ❖8.没有安装程序、或安装程序不完善(丢掉一些必要的 模块或文件)； ❖9.界面元素参差不齐，文字不能完全显示，TAB键顺 序与使用顺序不一致等；
RAD为软件测试带来新的挑战
❖软件结构越来越复杂 ❖团队规模越来越大 ❖开发成本与风险越来 越高
❖用户对应用程序的质 量要求越来越严格
软件测试生命周期
软件测试的阶段组成
测试计划
测试设计
测试开发
测试评估
测试执行
测试计划的目标
❖收集并组织测试计划信息 ❖将软件细化为可检验的测试需求 ❖建立测试计划
…………
可用性问题
用户比开发或测试人员在接触界面上要花费更多时间。错 误和低效的用户界面的影响会变得越来越大，最终甚至会 掩盖了产品有用的方面。 下面是一些用户界面错误的例子：
❖1.输入无合法性检查和值域检查，允许用户输入错误的 数据类型（有时只需要选择合适的输入控件即可，比如日 期用专门的日期输入控件），并导致不可逆料的后果；
测试入门
软件测试目的
❖ 测试是一个为了寻找错误而运行程序的 过程
❖ 一个好的测试用例是只可能找到迄今为 止尚未发现错误的用例
❖ 一个成功的测试是揭示了迄今为止尚未 发现的错误的测试
软件测试方法分类
两种测试方法从不同的角度出发， 反映了软件的不同侧面，也适用于
不同的开发环境。
软件测试方法：白盒测试
测试模式
错误分级－严重性
我们一般把发现的错误(Bug)/缺陷(Defect)按严重性分为4类：
1.严重：系统崩溃或挂起等导致系统不能继续运行；
2.主要：使系统不稳定、或破坏数据、或产生错误结果，而 且是常规操作中经常发生或非常规操作中不可避免的主要问 题；
3.次要：系统性能或响应时间变慢、产生错误的中间结果但 不影响最终结果等影响有限的问题，如：显示不正确但输出 正确；
测试设计
用户需求
定义 决定
选择
测试需求
测试用例 测试过程
测试开发目标
❖建立可重用的自动测试 ❖维护测试对于测试需求的可跟踪性
ห้องสมุดไป่ตู้ 测试开发技术：编程
优势： 具有较大的灵活性
缺点： 编程过程复杂
测试开发技术：录制
优势： 操作简单、快捷
缺点： 灵活性较差
测试开发技术
录制
自动生成
脚本
脚本生成自动化，并可根据需要修改
4.轻微：界面拼写错误或用户使用不方便等小问题或需要完 善的问题；
错误分级－优先级
我们也把发现的错误按优先级分为三种： 1.高：立即修改； 2.中：必须修改，但不一定马上修改； 3.低：允许不修改；
一般来说是越影响用户接受或使用该产 品的错误优先级越高。
常见问题
下面将列出一些问题，他们具有一些特征： 显而易见的 开发时容易被忽略 容易避免 容易修改