软件测试的定义
软件测试是用人工或者自动的手段测试某个软件系统的过程,目的在于检验是否满足规定的需求或弄清预期结果和实际结果的差别。
软件测试面临的挑战(为什么需要软件测试)
- 软件功能越来越复杂,规模越来越大,如何进行有效和充分的测试成为难题
- 系统的复杂程度要求测试工程师进一步学习具备更高的能力
软件测试职业生涯规划发展
- 自动化测试工程师
- 接口测试工程师
- 性能测试工程师
- 测试开发工程师
- 安全测试工程师
- 测试架构师
软件的生命周期
计划阶段
- 确定开发目标:开发什么样的产品
- 完成项目的可行性研究:确定软件能不能做来有没有意义li>
- 对项目进度进行预估和安排:安排人力和时间,确定预算
- 制定实施计划
需求分析阶段
- 分析整理项目的需求项:项目具体有哪些功能需要开发。
- 根据整理出来的需求项,编写需求规格说明书(SRS):Software Requirement Specification。
- 制作产品原型
设计阶段
完成概要设计
完成项目详细设计
编码阶段
根据概要设计说明书和详细设计说明书编写程序代码
测试阶段
- 单元测试:对程序的最小单元进行测试的过程。最小单元指函数或者一个类的代码。
- 集成测试:对模块与模块之间调用的接口进行的测试叫集成测试。
- 系统测试:对完成编译的系统整体进行测试的过程。
- 验收测试:交付给客户或者最终用户时,和客户一起完成的测试。
运维阶段
- 产品部署
- 运行维护
- 功能升级
- 性能提升
常见的测试模型
模型:将比较抽象的事物用比较形象的模型表现出来
瀑布模型
测试工作开展太晚,发现问题的时间就晚,改错成本高。
V模型
- 测试阶段划分清晰,分为单元测试,集成测试,系统测试,验收测试的四个阶段
- 每个开发阶段都有对应的文档支持
- 测试仍然需要等待开发完成后再进行
- 只对程序进行测试,没有对文档进行测试
W模型
将测试和开发过程分离开来,对项目中的需求文档,设计文档同样进行测试,提前测试工作,降低项目的质量风险。
敏捷模型
敏捷模型是为了适应现代互联 公司的“短频快”的开发节奏,而设计的一种开发和测试的模型。
迭代:每次迭代叫做一个sprint,每个sprint里面选出来要实现的需求安排到sprint product里。每个月为一个周期
Product Owner:相当于是产品经理。整理出整个项目的所有需求,并按照需求的优先级来拍列岛product backlog。
daily meeting:主要内容包括三点:昨天做了什么,今天准备做什么,有什么风险和问题。
sprint burndown:迭代燃尽图。记录剩余的工作量。
sprint review meeting:迭代回顾会议。主要是回顾在本轮迭代中存在的问题有哪些。后面如何改进。
软件质量模型
若问到怎么测试一个产品,需要从产品质量模型的8个质量属性去思考问题,不容易考虑不周。
问题:如何去测试一个水杯的质量p>
功能性
- 装一半容量的水
- 装最大安全容量的水
- 水杯的刻度是否准确
- 水杯是否可以装冷水,热水,杯壁是否冻手或者烫手li>
- 水杯的保温程度
- 杯子的杯盖能否保证水不漏出来
可靠性
- 杯子摔了不容易损坏
- 保温的时长
- 杯子的耐热耐冷程度
- 杯子的承重性
易用性
- 杯子的外观是否美观,完整
- 杯子的参数大小是否和规定的一致
- 杯子的杯盖是否容易打开、关闭
- 杯子的重量是否合适
- 抓举杯子的部位是否防滑
- 杯子的大小是否方便携带
安全性
- 杯子的材质是否无毒
- 杯子是否容易滋生细菌
- 杯子的接触面是否容易划伤消费者
- 杯子在高温,低温的环境中是否容易产生有害的物质
可移植性
- 杯子是否可以在高温,低温,特殊环境(高压,低压)下使用
- 杯子是否容易拆分、组装
兼容性
- 杯子是否可以盛放不同种类的液体(果汁,汽油,酒精等)
性能效率
- 杯子的最大容量
- 杯子接水/倒水的进水/出水量
可维护性
- 杯子是否容易修复
- 杯子是否容易被降解
常见的测试类型
名称 | 说明 | 对应的质量属性 |
功能测试 | 验证产品是否满足用户特定的功能要求并做出正确的响应 | 功能性 |
安全性测试 | 验证产品是否有保护数据的能力,并且能在一定程度上防范恶意攻击 | 功能性 |
兼容性测试 | 验证产品是否能和其他相关产品顺利对接 | 功能性 |
易用性测试 | 验证产品是否易于理解,学习和操作 | 易用性 |
可靠性测试 | 验证产品在长时间运行下能否达到相应的性能水平;在异常状态下是否可靠 | 可靠性 |
性能测试 | 测试产品提供某项功能时的资源使用情况 | 效率 |
安装测试 | 测试产品能否被正确安装并运行 | 可移植性 |
配置测试 | 验证产品能否在推荐配置上流畅运行 | 功能性,易用性 |
按类别划分测试类型
测试阶段不同
- 单元测试
- 集成测试
- 系统测试
- 验收测试
代码是否可见
- 黑盒测试:在不知道被测软件代码结构的基础上根据产品需求规格对软件的输入和输出进行测试的过程叫做黑盒测试。
- 白盒测试:基于被测软件的代码和结构本身进行测试的过程叫做白盒测试。
- 灰盒测试:介于黑盒和白盒之间,一般来说针对接口进行测试。比如只知道函数的函数名以及返回值,不知道函数内部的实现结构。
执行手段不同
- 手工测试
- 自动化测试
测试目的不同
- GUI测试
- 接口测试
- 性能测试
其他测试类型
- 回归测试
- 冒烟测试
- 探索性测试
项目相关的文档
开发阶段主要文档
- 需求规格说明书
- 概要设计
- 详细设计
测试阶段主要文档
- 测试计划和方案
- 测试用例
- 缺陷 告
- 测试 告
测试的流程
- 分析:需求评审、测试需求分析,得到测试点。
- 计划:测试计划和方案文档编写。
- 设计:设计测试用例
- 实现:编写测试用例,测试脚本等。
- 执行:搭建测试环境,执行测试用例, 告缺陷。
为什么要做测试需求分析
- 了解测试的系统是干什么的
- 了解系统的特点
- 了解系统的功能
- 了解系统的业务流程
- 系统在这个版本上哪些需要测试,哪些不需要测试
- 系统对性能和安全性上有没有要求li>
需求分析的流程
- 根据产品需求提取测试点
- 利用测试用例设计方法设计测试用例
测试用例编写
用例编 :标注用例编
用例标题:尽量清晰简单的描述需要执行用例的概括
前置条件:执行测试用例新的前提
执行步骤:写出执行用例的步骤
预期结果:需求文档预期的结果
实际结果:实际执行测试用例得到的结果
优先级:根据用例重要程度进行划分
测试结果:通过或者不通过
备注:描述特殊情况
测试用例设计方法
把测试点转换为测试用例的过程就叫测试设计。
等价类划分法
定义:某个输入域的集合,在这个集合中每个输入条件都是等效的,如果一个输入不会导致问题,其他的输入测试也不会发现问题。
有效等价类:对程序有意义,正确的输入数据
无效等价类:对程序无意义,不正确的输入数据
1.如果输入条件规定了取值范围和值的个数,则可以确定一个有效等价类和两个无效等价类
例如,要求输入年龄在18-25之间,18-25就是一个有效等价类,小于18和大于25就是两个无效等价类。
2.输入条件规定了输入值的集合,或者规定了必须的条件,则可以确定一个有效等价类和一个无效等价类。例如要求输入学历,学历包含大专,本科,硕士,博士,博士后,那么学历中的值就是一个有效等价类,不属于这个学历集合的就是无效等价类。
3.输入条件是布尔值的情况下,可以确定一个有效等价类和一个无效等价类。
4.在规定了输入数据必须遵守规则的前提下,可以确定一个有效等价类(遵守规则),和若干个无效等价类(从不同角度违反规则)。例如,要求输入一个正整数,那么正整数可以是一个等价类,无效等价类可是0,负数,小数。
步骤方法
- 编写等价类表:为每个输入划分等价类,得到等价类表。
- 设计一个测试用例,使其尽可能多的覆盖有效等价类。重复这一步骤直到有效等价类均被测试用例所覆盖。
- 设计一个测试用例,使其只覆盖一个无效等价类。重复这一步骤使得所有无效等价类均被测试用例所覆盖。(覆盖多个无效等价类无法确定问题)
边界值法
- 边界值分析法的理论基础是假定大多数错误发生在输入条件的边界上,如果边界附近的取值不会导致程序出错,那么其他取值导致程序出错的概率可能性也很小
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!