测试理论及测试模型
软件测试就是验证程序的开发是否满足预期，确认质量，另一方面是提供信息，找出问题，反馈问题[*]需求测试：SRS，简称‘需求’，全称 需求规格说明书，就是描述我们软件需要实现功能
界面测试：当前页面元素是否存在缺失，所有的元素摆放的位置是否合理，页面图片与文字是否正确，页面颜色与行间距是否合理；简单理解就是页面的美观性
UI设计：页面设计人员，主要是对页面进行设计的，前端开发（开发分为前端和后端）
[*]功能测试：验证软件的功能是否符合预期
金融---涉及财产的安全
政府---涉及信息的安全
[*]安全性测试：安全测试，确保软件在不安全的环境下，不允许使用
[*]可靠性测试：在规定的时间内完成规定的事情
[*]可用性测试：产品可以使用
电梯可以在2分钟之内完成升降
电梯可以完成升降
可靠包含可用
[*]可移植性测试：确保软件在不同的硬件环境下都可以正常使用
1.开发环境（dev）：开发人员写程序代码的服务器环境
2.测试环境(sit）：测试人员对软件进行测试的服务器环境
3.生产环境 真实环境 线上环境（prod）：给广大用户使用的服务器环境，是公司盈利的环境
[*]兼容性测试：确保软件在不同的软件环境下也可以正常使用。平台兼容 浏览器兼容 操作系统兼容
[*]易用性测试：用户可以非常简单的使用，主要是大众体验（尼尔森十大定律），结合界面测试一起做
[*]压力测试：在不断地对系统去施加压力，直接突破临界值，找到临界值
[*]负载测试：在临界值的位置，持续地运行一段时间，确保系统可以在临界值范围内稳定地运行
IT常见基本术语
硬件：存在实体的东西
软件：存在实体里面的东西，是虚拟的，数据化的
PC机--个人电脑
物理机--大型的实验室里面，配置非常高，作为公司服务器使用
便携机--我们的笔记本电脑（配置一般），移动工作站（配置非常高，很贵
OS：操作系统
win7，win10，win11--微软公司的操作系统
MAC OS--苹果公司的操作系统
Linux--开源系统，免费、开放源代码的系统
dos命令（命令行界面):通过键盘输入指令进行操作的，存在一定的专业性
图像化界面：有图行的界面。基本操作直接通过鼠标点击就可以完成，操作洗，简单
面试题：你们公司的系统是什么架构的？
C/S架构（客户机与服务器架构）:
1，需要下载客户端
2，客户端是要进行更新
3，用户少，安全性高
4，能对服务器减轻压力，对服务器性能要求低
5，上传和下载的速度快
B/S架构（浏览器与服务器架构）：
1，直接通过浏览器进行访问的
2，不需要用户进行更新
3，用户多，安全性低
4，对服务器性能要求高，因为用户所有的操作都是发送到公司服务器，有服务器进行处理
5，上传和下载的速度慢
客户提出他的需求（客户需求），之后就可以分解为项目需求，有了项目需求就可以展开项目
我们所在的公司部门：研发部、软件研发部，软件开发部
测试：软件测试工程师--助理，初级工程师，中级工程师，高级工程师，测试架构师，专家，顾问
TC：测试用例，测试案例
TE：软件测试工程师
TL：测试组长
TPM：测试经理--管理测试人员，上下级沟通，安排测试进度
开发：编写代码
开发经理：管理开发人员，安排开发进度，技术指导
项目经理：统筹整个项目。例如管理项目的上线，项目人员的安排
产品经理：收集客户需求，整理为我们的项目的专业的需求文档
需求分析师：协助产品经理对需求进行分析
运维人员：维护公司的环境，负责项目软件程序的发布和部署
DBA：数据库管理员
缺陷bug：导致软件在运行过程出现的问题的简称
L1--A：致命
L2--B：严重
L3--C：一般
L4--D：建议，提示
测试用例：测试工程师根据需求文档，分析出需要测试的测试点，根据测试点去编写相关的测试步骤，对应的预期效果，并且进行执行(描述功能，显示操作步骤，已知预期结果的一个文档）
常见的软件生命周期模型
C:\Users\Administrator\AppData\Local\YNote\data\weixinobU7VjnBbQrlDT_51v2spFu-erbc\2c4d6e7afda74bc9bab445251d78052a\mmc0bteh3u]uq0u{wi(kmfu.png
[*]瀑布模型：
C:\Users\Administrator\AppData\Local\YNote\data\weixinobU7VjnBbQrlDT_51v2spFu-erbc\9b51dd96ba7f4bfb921ba66ceeacd8e8\clipboard.png
1，测试是最后才介入的，软件的问题是在最后面才发现
2，该模型的前一个阶段和后一个阶段是相互关注的，不能跨阶段的关注
3，适合需求稳定，不经常变动的
4，每个阶段都会生成对应的文档
[*]V模型：主要是知道项目的各个阶段会生成的文档哪些
C:\Users\Administrator\AppData\Local\YNote\data\weixinobU7VjnBbQrlDT_51v2spFu-erbc\0a1a40081c6d4cfd80c74b7fe63e1915\@v{y@ami86in})nj7l08}aa.png
1，需求说明：分析需求规格说明书（SRS），在公司中通过澄清会议对需求中的问题进行说明
2，系统功能设计阶段：主要考虑整个系统需要实现什么功能
3，概设阶段（概要设计阶段，HLD）：把系统的功能划分为多个模块，以及模块和模块之间接口设计
4，详设阶段（详细设计阶段，LLD）：面向着某个模块里面的内部实现过程
5，编码：根据详设的要求去编写相关的代码
6，单元测试（UT）：主要测试具体一个模块里面的代码有没有满足详细设计的要求，检查代码的逻辑，一般是由开发人员去做
7，集成测试(IT)：将整个项目的模块拼接在一起，看各自模块是否能正常运行
8，系统测试（ST）：不单保证当前模块是否正常，而且要保证相关联的模块之间的业务是否正常
*一般在公司里面集成测试和系统测试是一起做，称为系统集成测试（SIT）
9，验收测试（UAT）：分为正式验收和非正式验收
（1）非正式验收：又分为两种
α（aerfa）alpha验收：公司内部组织的一个验收测试，有开发和测试在场，有问题马上解决
β（beta）beta验收：由特定用户进行验收测试，开发和测试都不在场，有问题就统一反馈统一修复
（2）正式验收：正式版本，由广大的用户使用
一般公司会有哪些环境存在
1.开发环境（dev）：开发人员写程序代码的服务器环境
2.测试环境(sit）：测试人员对软件进行测试的服务器环境
3.生产环境 真实环境 线上环境（prod）：给广大用户使用的服务器环境，是公司盈利的环境
4 验收环境
C:\Users\Administrator\AppData\Local\YNote\data\weixinobU7VjnBbQrlDT_51v2spFu-erbc\8e1ffce889414230b1cd482b01e02ba8\4]qy]g1(`5p1y(zqi7y(46w.jpg
V模型的优缺点：
优点：
1，改进了瀑布模型
2，反应的测试活动与开发阶段有对应关系
3，添加了测试策略，分别对底层的按代码进行测试，也对用户的需求进行测试
缺点：
1，还是一个串行模型，前期阶段出现的问题只能在后期发现
2，测试介入的时间较晚，在我们的软件开发周期的编码阶段之后才介入
[*]H模型--重中之重
C:\Users\Administrator\AppData\Local\YNote\data\weixinobU7VjnBbQrlDT_51v2spFu-erbc\3cad464556c84117912979f4a0de4906\(h_kn9(uzl4uh2giuy]6iwe.png
主要分为两个阶段：前期准备阶段，后期执行阶段
准备阶段：
1，进行需求澄清会议，由产品经理召开，一般参加人员有：整个项目的所有人员（项目经理，开发经理，开发人员，测试经理，测试人员），需求澄清会议结束后，各方都觉得没啥大问题，就可以输出基线化得需求文档（*基线化：不会再有大改动）
2，分析开发输出的概设和详设文档
3，测试经理输出测试计划或者测试方案
4，测试人员根据自己任务的需求文档编写测试用例，进行用例评审会议（一般由测试经理召开）
组内评审（交叉评审）：测试组内的同事进行相互的评审
组外评审：项目成员进行评审，一般是跟当前需求相关的测试人员和开发人员，产品经理一起进行
5，评审通过之后就会形成用例基线文档，测试经理把这些用例提交到用例管理平台（testlink，禅道），分配给到对应的测试人员
6，搭建测试环境
执行阶段（开发进行提测、转测。也叫做转测试，开发人员把写好的代码进行打包，通过自测之后，提交给到测试人员进行测试，一般不会超过一天）
7，部署项目：把开发的代码包部署到测试环境，并且运行，一般是由测试运维执行，也可以是测试经理或者测试骨干执行
8，冒烟测试：
（1）测试当前版本的主体功能和重要分支功能
（2）一般不会超过半天
（3）冒烟测试不通过就进行版本打回
冒烟测试的用例是怎么进行挑选？
选择和主体功能相关的测试用例和用例级别比较高的测试用例
9，冒烟测试通过之后，可以进入SIT1测试（第一轮系统集成测试），SIT测试一般分为3轮
面试题：
每一轮测试用例是怎么进行挑选的？
SIT1测试选择全量的测试用例（和当前版本相关的所有测试用例）
SIT2/SIT3测试（也叫回归测试，指的是相对于SIT1的回归），选择的是：
（1）上一轮测试出现的bug的测试用例要重新进行验证
（2）bug相关模块的测试用例
（3）每一轮都要进行主体功能的测试 （也就是每一轮都要选择冒烟测试用例）
（4）可以选择你觉得可疑的测试用例和测试场景
（5）测试人员补充的测试用例
面试题：为什么要补充测试用例？
因为开发过程，我们测试人员并不知道最终开发出来的产品是不是我们预期的，所有在开发完成之后才能看到所有的相关页面，为了避免漏测的情况，我们需要及时的补充测试用例
10，整个测试周期，bug的数量应该是呈收敛的趋势
11，输出测试报告，需要达到测试准出条件（0bug上线），当然可以遗留1-2个建议性的缺陷，遗留的bug必须要明确后续的版本进行修改
12，回归测试分为两种情况：
（1）SIT过程的回归测试，除了SIT1以外的测试都叫做回归测试
（2）SIT过程以外的回归测试，主要是对整个系统进行回归
面试题：你了解冒烟测试和回归测试的区别吗？
冒烟测试：又称为版本构建测试、提交测试，每一次版本构建（代码提交）时都要进行的测试，对版本的基础功能和主体功能进行的测试，一般不会超过半天，两个小时左右，不通过就直接打回
回归测试：系统维护阶段进行，对原有的功能、缺陷进行验证测试
区别：两者的区别在于测试阶段的不一样，冒烟测试是在版本提交时进行的，回归测试则是在系统维护阶段执行
在测试过程，执行测试用例时，发现一个问题（用例不通过），就要及时进行提交bug的操作，叫做提单
[*]敏捷模型：
1，重点明确，及时调整（往着一个目标去开发，出现偏差就及时进行调整）
2，倾听用户的声音，相信用户的直觉（面向市场用户的需求进行开发）
3，勇于创新，小步快跑（头脑风暴，什么相关的功能都可以提，有问题，不合适就减掉，适合用户继续进行改进）
4，持续不断地发现问题，解决问题（频繁迭代，保证主体功能无误，允许小问题，但需要及时进行修改）
5，持续提升整个团队的产品能力
页:
[1]