2022-03-07(周一)
一. 软件
1.软件: 程序+ 数据+ 文档
程序: 算法 数据结构
数据: 包含系统设计产出的数据
文档: 设计文档 需求文档 用户操作手册.
2.软件的分类
按层次划分: 系统软件, 应用软件
按结构划分: 单机软件, 分布式软件(B/S, C/S)
按组织划分: 开源软件, 闭源软件(商业软件)
C/S: C: Client客户端 S: Server 服务器
B/S: B: Broswer浏览器 S: Server 服务器
总结: 软件测试既要关注程序的逻辑及数据结构, 还要关注数据(设计数据及用户相关数据), 及文档(设计文档, 需求文档, 用户手册.)
二.缺陷(*)
缺陷: defect
1.软件未实现产品说明书要求的功能
2.软件出现了产品说明书明确指明不应该出现的功能
3.软件实现了产品说明书未提到的功能
4.软件未实现产品说明书虽未明确提及但应该实现的目标
5.软件难以理解,不易使用,运行缓慢,或从测试角度最终用户认为不好的
一句话总结: 所有不满足需求或超出需求的都是缺陷
没有不存在缺陷的软件, 只有迄今为止尚未发现的缺陷
真正的测试从发现缺陷开始.
三: <<软件测试的艺术>>: 测试是为了发现错误而执行的一个程序或系统的过程.
四. 软件测试的定义和目的
正向思维: 使自己确信产品是能够正常工作的. 测试人员验证软件的功能和特性是否达到预期结果,而执行的任何行为.(第一视角: 认为软件是正常的, 再来发现软件中的缺陷.)
反向思维: 出发点: 测试是为了发现错误而执行的一个程序或系统的过程.
测试是为了发现问题, 而不是证明程序没有问题.
一个好的测试用例在于发现了以前未发现的错误.
一个成功测试是发现了以前未发现的错误的测试.
IEEE定义的测试:
测试在规定的条件下(测试环境)运行系统或构件(功能)的过程:
观察和记录结果, 并对系统或构件的某些方面给出评价.
分析程序的运行, 观察实际运行结果是否与预期结果一致.
广义软件测试定义:
软件测试是对软件开发过程中的所有工作产品, 指 程序, 数据,文档进行的测试, 而不仅仅是对程序的运行进行测试.
软件测试是贯穿整个软件开发生命周期, 对软件产品(包括阶段性产品)进行验证和确认的活动(V&V)
软件测试的目的: 尽快尽早的发现软件中隐藏的缺陷.
确认: 软件实现了产品说/明书中的功能
验证: 测试功能是否满足软件运行的目标.
确认 就是确定软件按照产品说明书的要求实现了功能;
验证 就是确定,实现的功能能够正常运行达到预期结果.
五. 软件测试的目的(*)
以最少的人力,物力和时间,找出软件中隐藏的缺陷和风险, 并保障缺陷得以修复,避免因为隐藏的缺陷上线后带来的商业风险.
利用测试过程中得到的测试结果和测试信息, 作为后续项目开发和测试过程改进的重要输入, 避免在将来的项目开发和测试中重复出现同样的错误.
软件测试的目的: 尽可能早的找出软件中隐藏的缺陷,并确保其得以修复.
六. 测试和调试的区别
1.对象不同
测试: 程序 数据 文档
调试: 代码
2. 目标不同
测试: 零缺陷(允许有缺陷,但不影响用户的正常使用)
调试: 零Error(0错误)
3.过程不同
测试: 全过程
调试: 开发过程
调试依赖于开发,可以理解为调试是开发的子过程; 测试是贯穿整个软件开发生命周期的, 所以测试是一个独立的过程.
七. 软件测试的生命周期
单元测试: 测试内容就是代码开发
集成测试: 系统与系统之间, 模块与模块之间的接口.
确认测试: 整个程序(模拟正式环境下进行的)
系统测试: 整个程序(正式环境下进行的)
验收测试: 交付测试
三种不同的环境: 测试环境 预发环境 线上环境
软件经过测试后,能够提高软件的质量?
软件测试是软件质量的重要保障手段之一, 要提高软件的质量,主要还是依赖于开发, 支撑点是测试.
对软件测试的误解:
1. 测试是全员参与的, 不是由测试一个人就能彻底解决掉所有问题的
2. 随着行业的发展, 企业对于软件测试人员的技能要求,越来越高.
甚至高级测试开发工程师是非常稀缺的, 薪资普遍高于开发人员.
3. 在测试工作中, 尽可能按时间和要求完成自己的工作, 但如果客观条件不允许,则需要及时向上反馈与沟通.不能因为时间问题, 少测 或 漏测.
==================================================================================================================================================
2022-03-08(周二)
软件工程:
软件开发技术
软件项目管理
软件危机最重要因素: 软件质量问题, 软件工程就是解决软件质量问题的.软件测试是解决软件质量问题重要手段之一.
软件生命周期:
立项----需求分析---设计, 编码, 测试---发布--- 运维---淘汰
一.软件开发过程模型:
1.瀑布模型(*)
瀑布模型的特点(优缺点):
(1) 只有当前一个阶段的完成, 才是下一个阶段的开始
(2) 每个阶段都会进行评审, 只有评审通过后才会进行下一阶段的工作
(3) 每个阶段都会产生大量的文档, 增加了很大的工作量
(4) 测试介入的时间较晚, 在编码后才开始进行测试,缺少对需求与设计的测试
(5) 瀑布模型不适用于用户需求的变化
(6) 项目的开发成果, 在整个过程的末期才能看到, 从而增加了开发的风险.
2. 增量模型:
特点:
增量模型就是把软件/程序进行模块化划分, 把每一个模块看成是一个增量组件, 从而对每个组件分批次进行分析、设计、编码、测试.
优点: 开发不需要一次性将整个软件产品交付给用户, 可以进行分批次提交;
可以抢占市场, 其它的模块可以等待后续版本迭代继续开发.
支持用户需求的变动.
缺点: 待开发的软件是允许进行模块化划分的; 对项目管理人员的要求较高.
3.螺旋模型：
基于风险驱动的模型
4.迭代模型：
(1) 迭代模型也属于增量模型的特点， 将程序、系统模块化
(2) 在迭代模型中所有的模块由一个团队完成， 将模块划分出优先级
(3) 降低了在一个模块的开发风险
(4) 降低了产品无法按照既定进度交付的风险
(5) 迭代模型 适用于需求频繁变动的开发场景。
5.敏捷宣言(*)
敏捷开发以迭代模型为基础。
(1) 产品经理提出需求---> 由产品经理发起需求评审会议
(2) 有各个不同的团队认领当前需求的任务. 预估项目任务排期.
(3) 各个团队细化任务细节, 拆分任务安排. 给出具体的任务详细进度安排及人员安排.
(4) 开发进行设计与编码, 测试进行设计与测试
每日站立会(早晚), 尽可能短, 将当天需要进行的任务及需要解决问题进行阐述, 能够在会议解决的/产生解决方案的就立即解决, 不能够解决的就延后, 不用在会议中对没有结论的内容进行过分的讨论.
持续1-4周的开发周期, 确保当前需求得以开发完成及测试完成.
(5) 演示成果与总结回顾
项目开发与测试过程改进.
(6) 迭代下一个需求
敏捷开发强调沟通与交流, 轻文档化, 在每个环节都有专项会议, 会议中都会对达成共识的任务或安排进行确认, 没有进行确认的,重新经过确认后再次召集会议即可.
二.软件测试流程(*)
1.需求分析与评审
2.编写测试计划要做什么
3.制定测试方案要怎么做
4.设计与开发测试用例
5.执行测试
6.提交缺陷报告
7.测试分析与评审
8.提交测试总结
9. 准备下一版本的测试
==================================================================================================================================================
2022-03-09(周三)
一.软件测试过程模型:
一个标准的软件测试过程中, 应当包含但不仅仅包含以下测试活动:
测试分析、测试计划、测试设计、测试执行、测试总结。
1.V模型：
解析：
- V模型揭示了 开发过程与测试过程中各个阶段的对应关系 V模型体现的测试工作是在编码之后进行的。
从开发阶段来划分测试的分类：
单元测试：测试的系统每个模块对应的函数(代码)
集成测试: 将系统的每个模块集成在一起进行测试(接口)
系统测试: 把项目/软件放在真实的线上环境下进行功能正确性的验证与确认
验收测试: 通过验收测试, 确认项目是否达到了需求规格说明书中明确的交付要求.
特点:(*)
1.测试活动在编码之后, 测试介入的较晚.
2.没有体现尽早和不断的测试的原则
3.需求的满足情况直到验收测试才被验证
4. 忽略了对于需求分析、概要设计、详细设计的验证
2.W模型:(*)
(1) W模型由两个V模型构成, 分别代表开发与测试, 揭示了开发与测试是并行的关系.
(2) 测试的对象不仅仅是程序还包括需求与设计.
(3) 测试的介入从需求阶段就开始, 尽早的发现缺陷可降低软件开发的风险
(4) W还是上一个阶段的结束才开始进行下一个阶段的工作, 不满足迭代的需求.
3.H模型:
原理: 将测试活动完全独立出来,形成一个单独的流程.
特点:
在H模型中体现出测试应该尽早准备, 只要达到了测试的就绪点,就可以开始测试工作的开展.
工作中一般采用: W+H
W模型体现的是测试应尽早的介入; H模型体现的是测试的介入点的灵活性.
4.X模型:
1.x模型将程序片段进行相互分离的编码和测试, 通过频繁的交接, 通过集成最终合成为可执行的程序.
2. X模型中每个程序片段都是相互分离的, 设计, 编码,测试, 每个程序片段执行完成之后, 最终集成为可执行的程序.
二.软件测试过程模型理念:(*)
1.尽早测试: 测试人员介入项目开发阶段要尽早.(需求分析阶段)
2.全面测试: 对软件的所有产出物都进行测试(程序、数据、文档)， 测试的参与者， 不仅限于软件测试人员，还应该包括开发和产品经理。
3. 全过程测试： 软件测试贯穿于整个软件生命周期，测试人员应该关注到开发的每个阶段
4. 独立的，迭代的测试
测试活动是独立的---> H模型
测试活动应该是循环的， 不断的进行 ---> 提交测试总结--->准备下一版本的测试
三.软件测试分类:
1.按照开发阶段划分
单元测试: 又被称为模块测试. 参照依据是 详细设计说明书.
对程序模块进行正确性的检验的测试工作. 目的是为了 检查每个模块都正确实现了 详细设计说明书中的需求要求.
集成测试: 又被称为组装测试. 参照依据是 概要设计说明书.
是在单元测试的基础上, 将程序模块进行有序的,递增的集成测试. 逐步集成为符合概要设计说明书要求的程序部件或整个系统.测试的内容为系统与系统之间, 模块与模块之间的接口.
确认测试: 又被称为有效性测试, 参照依据是 产品需求规格说明书
是在模拟环境下(预发环境), 验证软件所有功能和性能是否满足用户的预期要求.
系统测试: 参照依据是 产品需求规格说明书
是在真实的系统环境下, 检查完整的程序系统能够和 外部设备,硬件, 网络等正确配置,连接,并最终满足用户的所有需求.
验收测试: 参考依据是 项目的任务书或合同
是软件产品检验的最后一个环节. 按照项目的任务书或合同, 供需双方依据约定的验收文档进行的对整个系统的测试与评审, 决定是否接收或拒收系统.
甲方验收(客户自己验收)
第三方检测机构验收
2.按测试技术划分(*)
1.黑盒测试: 通过软件的外部表现来发现其缺陷和错误.
黑盒测试把软件看做一个黑盒子, 完全不考虑程序的内部结构和处理过程.
只关注输入的数据, 对于输出的结果的正确性的判定.
2.白盒测试: 又被称为结构测试
白盒测试把软件看做一个透明的盒子,检查程序的所有结构和逻辑路径都是正确的. 只关注程序的内部结构, 而不关注程序的外部输入数据和外部结果.
白盒测试主要是观察结构与逻辑是否满足 详细设计的要求.
3.灰盒测试: 介于黑盒与白盒测试之间的测试.
灰盒测试既关注于输出对于输入的正确性; 同时也关注内部表现. 但不如白盒测试那么详细和完整.
3. 按照代码运行划分
(1)静态测试: 指不运行实际被测对象. 只是静态的检查程序代码, 界面和文档是否存在错误.
代码测试: 主要测试代码是否符合相应的标准和规范
界面测试: 主要测试软件实际界面与需求中的说明是否相符
文档测试: 主要测试用户手册和需求说明是否真正满足了用户是实际需求.
(2)动态测试: 指运行实际被测对象, 输入响应的测试数据,检查实际结果与期望结果相符的过程.
判断静态测试与动态测试, 只需要观察是否运行被测软件/程序即可.
4. 按照软件特性划分(*)
1.功能测试: 属于黑盒测试, 它检查的实际软件的功能是否符合用户的需求.
(1) 逻辑功能测试
(2) 界面测试
(3) 易用性测试
(4) 安装/卸载测试
(5) 兼容性测试
功能测试不完全等价于黑盒测试, 只关注功能的实现, 不关注输入数据与输出数据的正确性的校验.
2. 性能测试
功能的另一个指标, 主要关注软件中的某一个功能在特定的时间、空间条件下， 能够正常使用
时间： 在某个特别小的时间段内，多用户批量性进行功能使用，能否正常使用
空间： 在一个较大的访问量的情况下， 持续较长时间使用某些功能， 功能能否正常使用
3.安全性测试 程序、数据是否安全
4. 其它测试
(1)回归测试(*)
回归测试:对软件的新版本测试前, 重复执行之前某一个重要版本的所有测试用例.
a.执行测试以后会发现软件中的缺陷
b.提交缺陷(真正的测试从发现缺陷开始,确保其得以修复)
c.开发修复缺陷以后(将缺陷状态修改为: 已解决/已修改)
d.测试人员对已解决/已修复缺陷进行复测
验证: 验证之前版本产生的所有缺陷,全部被修复
确认: 确认修复这些缺陷没有引发新的缺陷.
(2)冒烟测试(*)
也叫可测性测试. 指对一个新版本系统进行大规模的测试前, 先验证一下该系统的基本功能是否实现, 是否具备可测性.
(3)随机测试
测试人员基于经验和直觉的测试.
(4)猴子测试
把自己看成不懂产品的"小白", 进行随机操作, 从而产生一些意想不到的操作结果,观察是否会产生缺陷.
总结: 拿到一个软件新版本时,测试必须要做的几件事(*)
1. 冒烟测试
2. 执行该版本所有测试用例
3. 回归测试 (验证与确认;防止开发拆东墙补西墙)
4. 大范围的随机测试
5. 该版本测试总结==================================================================================================================================================
2022-03-10(周四)
一.软件测试的原则:
1.只要是测试相关的问题,从需求角度出发, 绝对不会错.
2.时间服从质量
3.项目启动,测试就开始了, 尽早介入到测试阶段.
4.测试 是有范围的.
5.测试用例是设计出来的, 不是写出来的.
6.一段程序中出现错误数越多,存在错误的概率越大
7. 重视文档, 妥善保存一切测试过程文档.
8. 应当把"尽早和不断地测试"作为测试人员座右铭.
9. 要重视回归测试
10. 测试应从"小规模"开始,逐步转向"大规模"
二.软件需求:
功能性需求
非功能性需求
三.IEEE软件工程对于需求的描述:(*)
1.需求主要表述的是 未来这个软件去解决各种用户实际问题时,应该具有的条件, 软件能够做什么事
2. 需求将来一定要形成文档
四.软件需求分类:
1.业务需求
从业务层面分析相应内容, 包括了业务场景, 业务流程, 要实现的业务目标及约束条件.
2.系统需求
(1) 功能性需求:将业务需求转化为功能需求,也就是将业务转化为具体的功能
(2)非功能性需求:主要关注点在于软件的性能;产品必须遵循的标准,规范和约定,及质量属性的设计要求
例: 业务需求: 用户可从个人相册上传一张照片到个人头像.支持500个人同时上传
功能性需求: 开发一个上传头像的功能
非功能性需求: 支持500人同时上传
3.测试需求:(*)
测试需求是测试人员从需求阶段开始时, 经过多方渠道(需求规格说明书,项目合同书,会议记录)收集的具备可测性的需求, 称为测试需求.
软件需求分析的意义:
1.明确测试范围: 明确需要测试的功能点, 阐述不需要测试功能点的原因
2.明确测试类型和测试阶段: 明确要进行功能测试还是 非功能测试(性能);
不同的测试类型需要放在那个阶段去进行?(单元,集成,系统,验收)
3.识别需求的优先级: 确定优先级, 可以使测试人员了解核心的功能, 特性和流程有那些, 客户最关注的是什么, 由此可以确定测试工作重点.
==================================================================================================================================================
2022-03-11(周五)
一. 测试需求跟踪矩阵表的提取与编写:
1. 满足规则就是正向思维, 故意破坏规则就是反向思维.
2. 从缺陷角度来说, 反向更能有效发现缺陷, 反向思维更具备有效性.
二. 软件需求分析步骤(*):
1.根据软件需求规格说明书逐条列出开发需求, 并判断其可测性
2.形成可测试的描述并界定测试范围
3.根据质量标准,逐条制定质量要求, 即测试通过标准
4.分析测试执行时需要实施的测试类型
5.建立测试需求跟踪矩阵, 并对测试需求进行严格有效的管理
三. 编写测试需求跟踪矩阵表的步骤(*):
1.阅读理解各类需求
2.结合界面原型图理解软件各个功能
3.从叶级别功能点开始编写矩阵
4.只写清测试的思路和预期结果, 不用具体展开
5.保证每个功能点都有正反测试思路覆盖, 正反测试比达到1:4(部分功能没有反向测试)
6.写好的测试需求跟踪矩阵表必须通过评审才能最终完成.
四. 测试需求如何覆盖的所有从产品需求(*):
从叶级别功能点开始逐条进行覆盖, 然后叶级别覆盖完成后覆盖子功能级别(树枝), 子功能覆盖后覆盖主要功能模块(树干), 最后覆盖到整个项目(整棵树)
数据测试第二点: 对数据的测试一定要结合业务需求, 进行数据的增删改操作.
五. 软件缺陷的8020原则(*):
从需求阶段到集成测试阶段引入测试活动, 能够发现所有缺陷中的80%;
从系统测试阶段引入测试活动, 能够发现剩余缺陷的80%;
在系统上线后,持续运行的过程中能发现剩余缺陷的20%.
六. 需求评审意义:
1.需求评审可以将需求中, 不一致,遗漏和错误的需求审查出来.
2.缺陷在需求阶段修复的成本非常低
3.缺陷在需求规格说明书阶段比代码阶段发现的问题更多
七. 需求评审的内容:
1.需求文档中的所有描述是否完整,清晰,准确的反应了用户的实际需求
2.与其它系统之间的重要接口是否实现
3.所有的图表设计是否清楚,在不补充时能否理解
4.要考虑需求的变更情况
5.有没有遗漏的, 重复或不一致地方
6. 软件所实现的功能是否和需求要求的功能是一致的.
八. 需求评审的形式:
1.交叉评审
2.走查
3.小组评审(实际工作重点需求评审形式)
九. 需求评审参与的人员(*):
产品经理, 开发团队, 测试团队(一般是所有人),项目相关人员(运维,设计,DBA)
十. 需求管理工具:
1.ALM === HP QC项目管理工具
2.禅道 ===开源的
3.JIRA == 商业软件
