目录
★六个特性 功能性、可靠性、易用性、效率、维护性、可移植性 (功考，易效，可维）
1.软件介绍
1.1 什么是软件
国际定义：与计算机系统操作有关的计算机程序、规程、规则以及可能有的文件、文档和数据
教科书：
运行时，能够提供所要求功能和性能的指令或计算机程序集合
程序能够满意地处理信息的数据结构
描述程序功能需求以及程序如何操作和使用所要求的文档
即：软件=程序+数据+文档
2.软件开发过程模型
基本开发过程：可行性分析、需求分析、总体设计、详细设计、编码、测试、维护阶段。即软件生命周期
2.1 瀑布模型
瀑布模型：软件计划（可行性分析）-需求分析-设计-编码-测试-维护
知识参照博主：软件生命周期模型——瀑布模型-CSDN博客
- 瀑布模型
- 原型模型
- V模型
- 螺旋模型
- 迭代模型
2.2 V模型
★V模型：
无法回溯，只需要关注该环节的工作内容即可，不支持反复修改需求。 例如航空航天项目
需求分析：产品经理撰写：需求分档说明书 评审会议设计开发、测试、UI等
概要设计：参照博主：软件设计过程--概要设计&&详细设计_概要设计和详细设计的内容-CSDN博客
详细设计：产品经理：设计产品原型图 开发：开发文档
编码：写代码
单元测试：又称模块测诚，针对软件设计中的最小单位—程序模块，进行正确性检查的测试工作。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。测试代码，（看代码）
测试技术：白盒测试 大部分由开发来完成
单元定义：C中指一个函数，Java中指一个类，在图形化的软件中，单元一般指1个窗口，1个菜单。
集成测试：又叫组装测试，通常在单元测试的基础上，将所有程序模块进行有序的、递增的测试。重点测试不同模块的接口部分。开发人员将开发的各独立模块集成起来，实现某一功能的测试。例如淘宝：登录-浏览商品-加入购物车-下单-结算 （看接口）
测试技术：灰盒测试（接口测试）大部分由开发人员完成，测试工程师协助测试
系统测试（功能测试）：已经有成型的测试软件，由测试工程师来完成 （看界面）主要验证产品的各个模块是否可以正常使用
测试技术：黑盒测试
验收测试：整个系统测试阶段完成后，由开发，产品及甲方客户验收，给客户完整演示产品的各个模块。客户通过，可以安排部署上线
注：四大测试可参照：软件测试的四个阶段（单元测试、集成测试、系统测试、验收测试）_测试阶段-CSDN博客
2.3 迭代模型
迭代模型：
把一个复杂且周期较长的开发任务，分解成很多小周期内可完成的任务。每一个小周期就是一次迭代，每一次迭代都会交付或开发一个可以交付的软件产品。
与传统瀑布式开发相反（需求经常变动），弥补了弱点。成功率和生产率提高
特点：
- 线性开发模型，但是将一个大系统分为若干个迭代分析模型逐次上线，极大缩短迭代周期。
- 每个版本需求根据产品上线后的反馈来制定
- 因为上线周期短，所以文档轻量化
特点：
- 进一步压缩上线周期，把串行的开发方式改为并行方式。但人力成本较高
- 每个版本的需求仍然是根据产品上线的反馈来制定的
- 因为上线周期短，所以文档轻量化
迭代式模型开发的特点：
- 降低风险（人多速度快不易延期）
- 得到早期用户反馈
- 可以持续地测试和集成
- 快速地更新迭代，上线周期短，文档轻量化
- 迭代频率高
- 每个迭代地版本是由单独的小组来完成的
- 上线周期较短，文档比较轻量化，所以比较注重人与人之间的高度协作（沟通表达，理解能力）
2.4 敏捷开发模型
敏捷开发模型：以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发
快速迭代，小步快跑。比迭代开发模型周期更短，上线频率更高，更需要协作 [2--3周]
可参照博主：软件开发模式之敏捷开发（scrum）-CSDN博客
敏捷模型是一种迭代和增量的开发方法，它强调灵活性、快速反应和客户协作。在敏捷模型中，需求被分解成许多可以增量开发的小部分，每个增量部分都是在迭代中开发的。这种方法的主要目的是促进项目的快速完成，通过使过程适应项目，删除对特定项目可能不是必须的活动来实现敏捷性，避免任何浪费时间和精力的事情。
2.5 总结
四者对比：
瀑布式 ， V模型 ：都是需求-设计-编码-测试-交付的大致顺序流程。都要求每一个开发阶段都要做到最好，特别是前期阶段，错误越少积累则成本损失越低
迭代式：不要求每一个阶段的任务都做得最好，接受不完美。而是追求以最短的时间，最少的损失先将主要功能搭建起来，尽早交付一个“不完美的成果物”，得到客户和用户的反馈信息后再去完善
敏捷开发，迭代式开发：两者都强调在较短的周期内提交软件，但是周期更短，因此也更加强调队伍素质和协作
扩展可以参照博主：10种软件开发模型整理_软件开发模型的分类与应用-CSDN博客
3.软件质量模型
软件质量是客户满意的主要因素，而软件测试就是软件质量保证的一个重要手段
软件质量，即软件与明确地、隐含地定义的需求相一致的程度。软件质量模型是评价软件质量的国际标准。
★六个特性 功能性、可靠性、易用性、效率、维护性、可移植性 (功考，易效，可维）
功能性：客户对于软件功能性的需求，软件所实现的功能达到它的设计规范和满足用户需求的程度
可靠性：软件持续运行的能力，在规定的时间，规定的条件下软件不发生错误的概率
易用性：对于一个软件，用户在学习、操作和理解过程中所做努力的程度。客户易上手易理解
效率：产品的性能，在规定条件下，用软件实现某种功能所需的计算机资源(包括时间)的有效程度
维护性：产品可被修改的能力，当环境改变或软件运行发生故障时，为使其恢复正常运行所做努力的程度
可移植性：软件产品从一种环境迁移到另一种环境的能力，为使一个软件从现有运行平台向另一个运行平台过度所做努力的程度
扩展知识，可看博主：
测试工程师需求的是：
- 功能
- 性能
- 易用性
- 兼容性
- 安全
4. 环境介绍
开发环境：开发人员为了联调程序而搭建的环境
测试环境：测试人员为了测试程序而搭建的环境
准生产环境：也称为预发布环境/灰度环境，测试人员为了模拟生产环境而搭建的环境
生产环境：也称为线上环境，用户访问的系统所部署的环境
什么软件测试？
软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验他是否满足规定的需求或弄清楚预期结果与及时结果之间的差别。
！测试的本职工作必须且自需保障实际结果达到了需求的预期结果 ！
注：
需求：需求说明书中的规定功能
预期结果：按照需求说明书中规定的结果
实际结果：软件开发人员开发出的程序执行结果
1. 软件测试分类
1.1 按测试阶段划分
单元测试 -------> 集成测试 -------> 系统测试 ------> 验收测试
单元测试、集成测试、系统测试的比较：
1. 测试技术不同
单元测试：白盒测试
集成测试：灰盒测试
系统测试：黑盒测试
2. 评估基准不一样
单元测试：基准是逻辑覆盖率
集成测试：基准是接口覆盖率
系统测试：基准是对需求的覆盖率
3.考察范围不一样
单元测试：单元内部的数据结果，逻辑控制，异常处理等
集成测试：模块与模块之间，接口与接口数据传递，以及各模块能否完好的集合在一起
系统测试：这个系统相对于需求的符合度
验收测试：确保软件实现能够满足用户的需求（实际是产品来做）
α测试：Alpha测试
内测版本，通常只在公司内部进行测试，有可能是测试人员，有可能是公司其他部门参与进行
β测试：Beta测试
公测版本，针对所有用户开发的测试版本
目的：更多的收集用户的反馈和线上的BUG，然后进行修正，为正式版本做准备
1.2 按是否查看源代码
黑盒测试：
- 黑盒测试也称为功能测试，测试中把被测的软件看作一个黑盒子，不关心盒子的内部结构是什么，只关心软件的输入数据和输出数据，更多是站在用户角度去测试。测试
例如：输入5 + 2，查看输出为7，黑盒测试人员只关心输出是不是7
白盒测试：
- 白盒又称结构测试或者逻辑驱动测试或基于代码的测试。白盒指的打开盒子，去研究里面源代码的逻辑实现。开发
灰盒测试：
- 介于白盒和黑盒之间的一种测试。灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，也关注主程序内部的情况。开发主导，测试辅助
1.3 按是否运行分类
静态测试：
- 静态测试是指不运行被测程序本身，仅通过分析或检查源程序的语法、结果、过程、接口来检查程序的正确性。对需求规格说明书PRD、软件设计说明书、源程序进行结构分析、流程图分析、符号执行来找错
动态测试：
- 动态测试是指按预先设计好的数据和步骤运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能。 由三部分组成：构造测试用例、执行程序、分析程序的输出结果
1.4 按是否自动化分类
手工测试（Manual）
- 手工测试就是人工按照测试用例的步骤执行被测程序，然后观察结果从而比对软件的输出和测试用例的预期结果是否相一致
如：测试用例的编写，测试用例的评审，测试用例的修改等
自动化测试
- 自动化测试是指把以人为驱动的测试行为转化为机器执行的一种过程，即模拟手工测试步骤通过程序员编写的测试脚本自动地测试软件，包括所有测试阶段，跨平台兼容且是进程无关的
其他
★冒烟测试Smoke：（评审开发人员交付测试的程序是否满足用来测试的标准）
- 冒烟测试目的是确认软件基本功能正常使用，一般会从所编写的用例中选取一组最基本的用例进行执行，一般通过冒烟测试来衡量开发提出测试版本是否达到测试标准
注：重点是最核心的功能模块（一般是主干流程）
随机测试Ad-hoc Testing：（主要是对被测软件的一些重要功能进行复测，也包括测试哪些当前用例没有覆盖到的测试）经验
- 随机测试主要是根据测试者的经验对软件进行功能抽查，没有约束性的随便进行测试，更多的依据经验和尝试性地进行测试
探索性测试Exploratory：（一种测试思维，强调人的主观能动性）
- 探索性测试旨在促使测试人员抛弃繁杂地测试计划和测试用例设计过程，在碰到问题时及时改变测试策略。
回归测试：
- 回归测试旨在针对提交给开发的BUG，在开发修改后，除了进行BUG是否解决的验证，同时还要测试是否有新的BUG被引发，有没有影响到其他功能
★软件测试流程
软件测试流程：需求评审--->需求分析（测试人员）--->编写测试计划---->提前测试点---->编写测试用例和评审用例---->冒烟测试----> 执行测试用例---->bug提交与管理
1. 需求评审（产品主导）
需求分析：
2. 编写测试计划
提取测试点：
注：业务流程：单独功能穿起来形成主要功能 VISIO梳理业务流程图
技术方法：
- 等价类划分：根据需求说明书规定的输入范围划分，符合规定条件的称为有效等价类
- 边界值分析法：专注于测试输入或输出的边界值，等于略高于最小值，等于略低于最大值称为有效边界值
- 状态迁移法：通过状态的变化反应不同业务流程
- 场景法：又称为流程设计方法。通过运用场景来对系统的功能或业务流程进行描述，从而模拟实际用户的操作流程 涉及三种场景：基本流，备选流，异常流
- 错误推断法：一种基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试法。错误推断法要素共有三点，分别为:经验、知识、直觉。
- 因果图
- 决策表
- 正交检验法
场景法
基本流：系统按照正确有效的业务执行完毕的一条流程。一般是用户操作最频繁的一种操作
备选流：系统按照无效或错误的业务执行的一条流程，一般是用户可能会有的一种操作
场景法测试用例的写作步骤：
1. 分析基本流和业务场景（用ProcessOn在线或Visio软件进行流程图绘制）
淘宝购物流程：购物
基本流：登录账号--浏览商品--加入购物车--支付--生成订单
备选流1：登录--忘记密码--找回密码流程
备选流2：登录--忘记密码--密码输入错误次数超过3次--账户被锁定
备选流3：登录--账号未注册
备选流4：商品支付，余额不足--充值
备选流5：商品支付，切换支付方式
2. 根据基本流和备选流组合成不同的业务场景，场景要具有一定的业务意义
场景1：基本流
场景2：基本流+备选流1
·
·
·
3. 将无意义的业务场景去掉
4. 最后将每个业务场景生成相应的测试用例
技术方法的详细描述具体可参照博主：软件测试方法精讲-CSDN博客
3. 设计测试用例与用例评审
测试用例
测试用例的定义：是为了验证软件是否符合需求而设计的一组由输入、执行条件、预期结果的文档
测试用例的编写流程：需求分析---提取测试点--编写测试用例--评审--修改
测试用例的作用：
- 验证软件是否满足需求
- 提高测试覆盖率，避免遗漏一些测试场景
- 测试人员工作内容的衡量
★测试用例要点：（编块描 前优入 步果 ）
具体案例可参照博主：一文教你如何编写测试用例_测试用例八大要素-CSDN博客
作业1：分别运用等价类划分、边界值分析法。针对邮箱地址编写测试数据
等价类划分：
作业2：依据场景法的定义给出ATM柜台取款的基本流和备选流
- 基本流：插卡-输入密码-查询余额-输入金额-输入密码-取款
- 备选流1：插卡无效
- 备选流2：输入密码错误
- 备选流3：输入密码错误次数过多，锁定账户
- 备选流4：输入金额大于账户余额
- 备选流5：输入金额大于当日限额
- 备选流6：输入金额不符合要求
作业3：针对禅道的登录功能设计一条测试用例，包含构成测试用例的八大必要元素
练习：针对登录功能编写两条测试用例，一条登录成功，一条登录失败！
用例评审
参与人员：测试，开发，产品
冒烟测试
冒烟测试通过，则测试人员全面进入执行测试用例阶段
4. 执行测试用例
时间充足情况下：执行全部测试用例
时间不充足的情况下：按照优先级从高到低执行
5. BUG提交与管理
5.1 软件缺陷
5.1.1 软件缺陷的定义
软件缺陷又被叫为Bug，是软件或程序中存在某种破坏正常运行能力的问题，错误或者其他隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需求。
5.1.2 软件缺陷的常见类型
- 功能，特性没有实现或部分实现
- 设计不合理，存在缺陷
- 数据不正确，精度不够
- 运行出错，系统报错、退出、界面混乱
- 用户不能接受的问题，查看时间过长，界面不美观，不易理解等
5.1.3 软件缺陷产生的原因
- 需求设计错误，如业务逻辑考虑不全面
- 系统架构设计不合理，如没有考虑多并发，数据库字段设计不合理
- 程序代码问题，如错误的算法，业务逻辑判断不准确
5.1.4 软件缺陷中包含的信息
软件缺陷的类型：
- 功能问题
- 界面UI问题
- 兼容性适配问题
- 易用性问题
- 性能问题
- 安全问题
缺陷的优先级：
- 紧急：立即修复，例如系统闪退
- 高：四小时内修复，例如支付功能异常
- 中：两天内修复
- 低：版本上线前修复或不修复
- 无关紧要：可以延期修复或者不修复
缺陷的严重程度：
- 致命：系统宕机，程序退出，核心功能不可用
- 严重：阻塞流程，主要功能不可用，数据错误，主要性能指标不达标
- 一般：不太严重的bug，次要功能不可用
- 提示：某些界面提示，例如密码规则提示
- 建议：用户体验、界面优化的建议型bug
可参照博主：软件缺陷主要包含哪些要素？_缺陷要素有哪些-CSDN博客
5.2 bug的整体流程
bug的整体流程：测试人员执行测试用例发现bug，提交bug，开发人员修复bug，测试人员回归测试，确认bug是否修复，选择关闭bug，或重新激活bug让研发继续修复
BUG描述总结：
难点：想要写出一个好的bug，其实最难的就是如何准确、简洁、完整的描述
解决方案：
- 1标题+1图片
- 1标题+1视频（难以复现的bug）
- bug描述的总结：所属模块+执行动作+出现现象
5.3 项目管理工具：禅道/JIRA
禅道的使用
使用步骤：
1. 创建用户
- 1. 创建用户
- 2. 设置权限
- 3. 自定义权限
2. 基本流程
- 1.创建产品
- 2.创建项目
- 3.设置团队成员
- 4.创建版本
3. 测试人员使用 见TPshop实战项目
6. 编写测试报告
测试报告是指把测试过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件存在的质量问题提供依据，同时为软件验收和交付打下基础。是测试阶段最后的产物
6.1 作用:
对测试来说：
- 测试结束的一个标志
- 形成一份可以参考的材料
- 对于整个测试过程或设计方法的一些改进建议
对整个项目和团队来说：
- 把关
- 预防
- 报告
- 改进
6.2 主要内容
测试过程和结果写成文档 发现的问题和缺陷进行分析 + 软件存在的风险说明 和 总结与改进建议
- 测试工作的过程与结果
- 风险说明
- 缺陷汇总与分析
- 测试工作的总结与改进