夜雨聆风
软件测试入门+测试流程:从0到1打造靠谱测试体系
-
软件测试概述
-
什么是软件
-
硬件概念: 由电子, 机械和光电元件等等组成的各种物理装置的总称
特点: 看得见摸得着
-
软件概念: 是一系列按照特定顺序组织的计算机数据和指令的集合
特点: 看得见摸不着
-
软件的分类
-
按开发规模划分
-
小型: 开发周期4个月内 — 参与人数10人以下
-
中型: 开发周期1年内 — 参与人数10~100人
-
大型: 开发周期1年以上 — 参与人数100人以上
-
按用户对象划分
-
产品: 微信/office/qq/百度
-
项目: 为企业定制的OA系统
-
按是否需要联网划分
-
C/S架构: qq/LOL
-
B/S架构: 搜狐/百度
-
单机: 蜘蛛纸牌/画图工具
-
网络:
-
按功能划分
-
应用软件: 淘宝/有道词典
-
系统软件: 操作系统/驱动软件
-
什么是软件测试
-
概念: 在规定条件下对程序进行操作, 以发现程序错误, 并对其是否能满足设计要求进行评估的过程
-
目的: 找缺陷 (找bug)
-
对象:
-
源程序
-
目标程序
-
数据
-
文档
-
软件开发流程
-
开发模型分类
-
边做边改模型
-
瀑布模型
-
快速原型模型
-
增量模型
-
螺旋模型
-
喷泉模型
-
…
概念
将软件生命周期划分为制定计划, 需求分析, 软件设计, 程序编写, 软件测试 和 运行维护六个基本活动, 并且规定了它们自上而下, 相互衔接的固定次序如同瀑布流水, 逐级下落
图示
组成阶段: 6个角色和产出
小结
-
特点: 线性模型, 是其他模型的基础
-
应用场景: 需求清晰的大型项目, 如: 建筑, 银行, 保险等
-
优点: 阶段清楚
-
缺点: 返工量大, 不适用于需求变化的项目
面试题
软件的生命周期?[1]
立项 -> 计划 -> 需求分析 -> 设计 -> 编码 -> 测试 -> 运行维护
-
敏捷开发
90%以上的公司采用敏捷开发
背景
-
是一种20世纪90年代后逐渐引起广泛关注的新型软件开发方法
也叫 敏捷方法 敏捷过程 敏捷模型
-
它的具体名称, 理念, 过程, 术语都不尽相同
-
它是一种以人为本, 迭代, 循序渐进的开发方法
图示
基本原则
-
以人为本: 相信自己的团队, 规律的反省/优化, 重视客户胜过合同
-
一切从简: 简化流程, 文档, 交流方式等
-
迭代: 持续交付, 周期越短越好
-
项目构成[补充]
说明
一个项目基本都是由前端, 后端 和 数据库 三个部分构成
-
前端: 用户所使用的浏览器或客户端
-
后端: 运行在应用服务器上, 作为前端和数据库的中间人, 处理业务和数据
-
数据库: 运行在数据服务器上, 用于存储数据
图示
中间件概念
介于系统和应用之间的一类软件
可以简单理解为, 中间件可以在系统上帮助应用开放端口
常用的中间件
-
Tomcat: 主要运行 Java 程序
-
Apache: 主要运行 PHP 程序
-
软件测试流程
-
软件测试模型分类
-
V模型 (重点)
-
W模型 (重点)
-
X模型
-
H模型
-
V模型
-
概念: 以”编码”为黄金分割线, 把整个过程分为开发和测试, 并且开发和测试之间是串行的关系
-
图示
-
特点: 开发与测试串行, 测试介入过晚, 返工量大
-
W模型
-
概念: W模型是由两个V模型组成, 一个是开发阶段, 一个是测试阶段, 又称为双V模型
-
图示
-
特点: 开发与测试并行, 测试可以提早介入, 但是总体流程依然是串行, 不支持迭代
-
最佳实践流程
团队角色介绍
-
产品经理/项目经理 (负责人)
-
UI
-
前端开发
-
后端开发
-
测试
-
运维/运营
图示
-
软件测试分类
-
按阶段划分
单元测试的概念
指对软件中的最小可测单元 (一般可以理解为是函数) 进行检查和验证
集成测试的概念
在单元测试的基础上, 将所有模块按照设计要求组装成子系统或系统, 进行测试
系统测试的概念
系统测试是将 软件, 操作系统 和 硬件 看作一个整体, 在实际运行环境下进行测试
验收测试的概念
对完成的系统是否满足 最开始的需求 进行验证
分类
按用户对象划分
项目验收: 甲方发起, 验证乙方系统是否满足甲方业务需求
产品验收: 产品经理发起, 验证自研软件是否满足用户需求
按阶段划分
α测试 (内测): 只有公司内部成员参与
β测试 (公测): 由用户完成
测试阶段 — 负责人员 — 项目环境 的关系
单元 — 开发人员 — 开发环境
集成 — 开发人员 — 开发环境
系统 — 测试人员 — 测试环境
验收 — 产品经理/甲方 — 预生产环境
主要的项目环境
-
开发环境
-
测试环境
-
预生产环境
-
线上环境/生产环境
-
按是否考虑代码逻辑划分
黑盒测试
-
概念: 把测试对象看作一个黑盒子, 测试时, 测试人员不用考虑盒子里的逻辑结构, 只需检查程序的功能是否符合需求文档
-
重点: 验证程序的功能是否符合需求文档
-
测试依据: 需求文档
-
分类
-
界面测试/UI测试: 检查页面元素是否符合UI设计, 页面是否美观
-
功能测试: 检查产品功能是否满足需求
-
易用性测试: 用户体验
-
兼容性测试: 验证软件在各个环境下功能是否正常
-
性能测试: 模拟用户场景, 测试系统的各项性能指标, 查看是否满足需求
-
…
白盒测试
-
概念: 与黑盒相反, 这种方法是把测试对象看作一个透明的盒子, 测试时, 测试人员会对程序的所有逻辑路径进行测试, 检验每条路径是否都能走通
-
重点: 验证源代码的逻辑结构是否符合设计
-
测试依据: 代码规范, 详细设计文档
灰盒测试
-
概念: 介于黑盒与白盒之间的一种测试方法, 需要了解代码逻辑, 重点验证程序的功能
-
案例: 商城中, 用户支付时可以使用优惠券
-
黑盒角度, 考虑各个用户, 各个商品, 各种价位, 各种金额大小的优惠券
-
灰盒角度, 先了解业务逻辑, 再进行测试
-
# 业务逻辑 if 商品金额 >= 优惠券金额 减去即可 if 商品金额 < 优惠券金额 付0元
与各测试阶段的对应关系
单元 –> 白盒
集成 –> 白盒
系统 –> 黑盒/灰盒
验收 –> 黑盒
面试题
白盒测试和黑盒测试的区别?[1]
-
首先, 策略不同, 黑盒不考虑代码逻辑, 白盒需要考虑
-
其次, 阶段不同, 白盒进行较早, 单元和集成测试都属于白盒, 黑盒进行得较晚, UI/功能/易用性等都属于黑盒
-
再次, 上手难度不同, 白盒要求具备代码能力, 上手难度较大, 黑盒要求测试/用户思维, 上手难度较小
-
最后, 我想说, 黑盒和白盒不能互相替代, 都是不可或缺的
-
按是否运行划分
静态测试
-
概念: 指不运行被测程序本身, 检查文档或者源程序的语法, 结构, 过程等
-
测试对象
-
文档 (需求文档, 各类设计文档)
-
源程序
-
数据
动态测试
-
概念: 指通过运行被测程序, 进行测试
-
测试对象
-
源程序
-
目标程序
-
数据
-
按是否自动化划分
手工测试: 手工的方式去执行测试
自动化测试: 需要借助工具或代码去执行测试
-
其他
冒烟测试
针对最基本的功能或者流程进行的测试
回归测试
-
概念: 修改代码后, 重新进行测试
-
应用场景
-
bug回归: 当前迭代的bug修复后, 需回归, 以前的版本中概率性出现的bug, 可能需要连续跟踪几个版本
-
旧功能回归
面试题
回归测试的重点?[3]
我做回归测试的方向主要有两个: bug回归和旧功能回归
-
如果是bug回归, 重点是修改过的功能或者模块, 还有与之关联的功能或模块
-
如果是旧功能回归, 重点是分清重要的核心功能, 以及使用频率高的功能
随机测试[了解]
随机去测试其他人没有测到的部分
探索性测试[了解]
测试设计与测试执行同时进行
-
最佳实践流程
-
测试流程
-
需求分析, 需求评审
-
编写测试计划
-
编写测试用例以及发起用例评审
-
[可选]搭建测试环境, 冒烟测试
-
系统测试, 编写测试报告
-
第一轮 –> 新功能的功能测试
-
第二轮 –> bug回归测试
-
第三轮 –> bug回归测试
-
…
-
最后一轮 –> 旧功能的回归测试
-
验收测试, 编写测试报告
-
线上, 点点点
测试报告一般保留上线前的那一份即可
-
时间规划
需求分析 + 需求评审 — 0.5天
测试计划 + 测试用例以及评审 — 2.5天
系统测试 — 1.5天
验收测试 — 0.5天
关注我！每天不定时分享计算机编程干货！
一、软件测试所有阶段视频资源
（从测试基础理论开始、测试工具、功能测试、App自动化测试、接口测试教程、liunx教程、Mysql教程、python语言、接口自动化、自动化测试框架、持续集成、性能测试、测试开发、安全测试）应有尽有（都是免费分享的）
（部分视频资源）
二、软件测试面试题PDF版本
{1}测试理论篇
{2}Liunx篇
{3}MySQL篇
{4}Web测试篇
{5}接口测试篇
{6}App测试篇
（部分面试真题）
领取「软件测试」资料包
三、软件测试全学习路线
（部分学习路线）
四、简历模板
五、面试小程序
对于自学软件测试的的朋友来说应该是最全面最完整的备战仓库，为了更好地整理每个模块，我也参考了很多网上的优质博文和项目，力求不漏掉每一个知识点，很多朋友靠着这些内容进行复习，拿到了BATJ等大厂的offer，这个仓库也已经帮助了很多的软件测试的学习者，希望也能帮助到你。