关于软件测试你都知道什么
第一讲 测试知多少1.什么是软件测试
软件测试就是验证程序的开发是否满足预期，另一方面就是找到问题，提供信息，反馈问题
需求测试：需求规格说明书 SRS，简称‘需求’，就是描述我们软件需要实现的功能
界面测试：当前页面元素是否存在缺失，所有的元素摆放的位置是否合理，页面图片与文字是否正确，页面颜色与行间距是否合理，简单来说就是页面的美观性检查
*UI设计：页面设计人员，主要是对页面进行设计的，前端开发（开发分为前端开发和后端开发）
功能测试：验证软件的功能是否符合预期
*什么类型的机构或者公司更加需要安全测试？
例如银行--涉及金融财产方面
例如政府--涉及国家信息安全方面
例如金融--涉及财产方面的安全
安全性测试：检查密码是否加密，有些功能是不是必须要在登陆之后才可以进行操作，安全测试，确保软件在不安全环境下，不允许使用
可靠性测试：在规定的时间内完成规定的事情
可用性测试：产品可以使用
电梯可以升降，那么这个电梯是可以用的，但是如果电梯直接从10楼下降到1楼是不可靠的，需要相关的要求，例如限制在1分钟匀速完成升降，它才是可靠的
例：
[*]电梯可以在两分钟之内完成升降（可靠性）
[*]电梯可以完成升降 （可用性）
那么可靠性包含可用性，还是可用性包含可靠性？？
可靠包含可用，可用不一定可靠
可移植性测试：确保软件在不同的硬件环境下都可以正常使用
*开发环境（dev）：开发人员写程序代码的服务器环境
测试环境（sit）：测试人员对软件进行测试的服务器环境
生产环境、真实环境、线上环境（prod）：给广大用户使用的服务器环境，是公司盈利的环境
*手机系统：IOS，安卓，鸿蒙
兼容性测试：确保软件在不同的软件环境下也可正常使用，浏览器兼容，系统兼容，平台兼容
易用性测试：用户可以非常简单的去使用软件，主要是结合着大众体验进行（尼尔森十大定律），一般结合界面测试一起进行的
*需求：电梯负重量限制2000kg
慢慢的从1900，2000，2100，2200.。。。直到找到电梯的最大承重能力，去突破找到它的极限（临界值
压力测试（性能测试中的一个小类）：在不断地对系统去施加压力，直到突破临界值，找到临界值，压力测试简单来说就是去突破临界值
负载测试：在临界值的位置，持续地运行一段时间，确保系统可以在临界值范围内稳定地运行
2.IT常见基本术语
硬件：存在实体的东西
软件：存在于实体里面的东西，是虚拟的，数据化，驱动硬件运行的东西
PC机：个人电脑
物理机：大型实验室里面，配置非常高，作为公司的服务器去使用
便携机：我们的笔记本电脑（配置一般）
移动工作站（配置非常高，很贵）
OS：操作系统
win7，win10，win11--Windows微软公司的系统
MAC OS--苹果公司的操作系统（基于unix开发的操作系统）
Linux--开源系统，免费的系统，开放源代码的系统
*在Windows系统，通过‘开始’+r，输入‘cmd’就可以进入Windows系统的命令行界面，在里面操作的指令叫做dos命令
dos命令（命令行界面）：通过键盘输入相关的指令对系统进行操作，存在一定的专业性的
图形化界面：有图像的界面，基本的操作可以通过鼠标点击完成，操作简单
输入D：切换到D盘
C:\Users\Administrator\AppData\Local\YNote\data\weixinobU7VjiqFHbvqudPqzFQrfgIGLh4\5050cfa7d9454a22a00373ad04cdfec5\16mq49f$u9@h6]h94q~a@qu.png
文件：包含着内容的东西，打开文件后会调起某些程序去进行执行的
文件夹：用来存放东西，存放文件或文件夹
共享：同一个文件或者文件夹可以供很多人一起使用
备份：把文件或者文件夹做一个副本进行其他的保存，当原来的文件或者文件夹出现问题，就可以通过备份进行恢复
目录：也就是文件夹
路径：用来判断计算机（文件或者文件夹位置的东西）
绝对路径：具体位置（跟陌生人说地址，需要具体的）
相对路径：相对于本身位置去描述其他位置（跟熟悉的人说地址，差不多就行了）
面试题：你们公司的系统是什么架构？
C/S架构（客户机与服务器 ）
1、需要下载客户端
2、需要用户进行更新
3、用户少，安全性高
4、能对服务器减轻压力，对服务器性能要求低
5、上传和下载的速度快
B/S架构（浏览器与服务器）
1、直接通过浏览器进行访问的
2、不需要用户进行更新
3、用户多，安全性低
4、对服务器的性能要求高，因为用户所有的操作都是到公司服务器去进行处理的
5、上传和下载的速度慢
客户与客户需求：
客户提出他的需求（客户需求），之后就可以分解为项目需求，有了项目就可以展开项目
3.项目角色
测试工程师：简称测试，助理，初级，中级，高级，测试架构师，专家，顾问
TE：软件测试工程师
TC：测试用例，测试案例
TL：测试组长
PM：项目经理：管理项目所有的工作进度
TPM：测试经理：管理测试人员，安排测试进度，技术指导，上下级沟通
DBA：管理公司的数据库
一般我们所属部门：
研发部、软件研发部、软件开发部
开发经理：管理开发人员，安排开发进度，技术指导
开发人员：设计编写代码
前端开发：页面的设计和开发
后端开发：软件的处理逻辑、数据的处理
项目经理：统筹整个项目。例如管理项目的上线，项目人员的安排
数据库管理员（DBA）：管理公司的数据库
UI设计工程师：原型图输出为保真图
产品经理：收集客户的需求，然后整理为我们项目的需求文档
需求分析师：协助产品经理对需求进行分析
运维人员：维护公司的环境，负责项目软件程序的发布和部署
第二讲软件的生命周期
1.为什么要测试
软件的非正常运行或自身的缺陷会引发很多问题，软件又是代码和文档组成的，都是由人来设计和编写的，人都有可能犯错。
BUG（缺陷）：导致软件在运行过程中出现问题的简称
L1--A：致命
L2--B：严重
L3--C：一般
L4--D：建议，提示
2.什么是测试
制造业的定义：以检验产品是否满足需求为目标
软件行业的定义：
[*]验证软件的正确性
[*]发现软件中的缺陷
测试是为了证明程序有错
测试用例：测试工程师根据需求文档，分析出需要测试的测试点，根据测试点去编写相关的测试步骤，对应的预期结果，并且进行执行
测试用例：描述测试的功能，显示操作的步骤，已知预期结果的一个文档
3.软件生命周期概念
从出生到死亡（指的是软件从产生到报废的整个过程，是一种时间概念）
4.软件生命周期的阶段
[*]客户问题
[*]可行性分析
[*]项目招投标
[*]项目立项
[*]需求分析
[*]开发阶段（设计，编码，测试）
[*]维护
5.典型的软件生命周期模型有哪些
瀑布模型：
（1）测试是在最后介入的，软件的问题在最后面才发现
（2）该模型的前一阶段和后一阶段需要互相关注，不能跨阶段去关注
（3）适合需求稳定，不经常变动的
（4）每个阶段都会生成对应的相关文档
C:\Users\Administrator\AppData\Local\YNote\data\weixinobU7VjiqFHbvqudPqzFQrfgIGLh4\3f17020f979141d298e6419a195c7ce0\1638687886(1).png
V模型：主要是知道项目各个阶段会生成的文档有哪些
C:\Users\Administrator\AppData\Local\YNote\data\weixinobU7VjiqFHbvqudPqzFQrfgIGLh4\8cd4dfbf4c474992be774a84bc131978\@v{y@ami86in})nj7l08}aa.png
C:\Users\Administrator\AppData\Local\YNote\data\weixinobU7VjiqFHbvqudPqzFQrfgIGLh4\87cf376b74164aa6b43c99a6f8063ea1\s)l1(ucswhbkua_6d1kfqmd.png
（1）需求说明：分析需求规格说明书（SRS），在公司中通过澄清（由产品经理去说明）会议对需求中的问题进行说明
（2）系统功能设计阶段：主要考虑整个软件系统需要实现什么功能
（3）概设阶段（概要设计阶段，HLD）：把当前软件系统的功能划分为多个模块，以及模块和模块之间接口的设计
（4）详设阶段（详细设计阶段，LLD）：面向着某个模块里面的内部实现过程
（5）编码：根据详设的要求去编写相关的代码
（6）单元测试（UT）:主要测试具体一个模块里面的代码有没有满足详细设计的要求，检查代码里面的逻辑，一般是由开发人员进行自测
（7）集成测试（IT）：将整个项目的模块拼接在一起，看看各自模块是否能正常运行
（8）系统测试（ST）：不单要保证当前模块的功能是否正常，而且要保证相关联的模块之间的业务是否正常
注：一般在公司集成测试和系统测试是一起做的，称作为系统集成测试（SIT）
（9）验收测试（UAT）：对业务进行测试，分为正式验收和非正式验收
非正式验收又分为两种：
[*]α（aerfa）alpha验收：公司内部组织的一次验收测试，有开发和测试在场，有问题马上解决
[*]β（beta）beta验收：由特定的用户进行验收测试，开发和测试都不在现场，有问题统一反馈统一修复
正式验收：正式版本，由广大的用户去使用
C:\Users\Administrator\AppData\Local\YNote\data\weixinobU7VjiqFHbvqudPqzFQrfgIGLh4\49e1c6b496f444c1a175fc8c3be0d7a6\4]qy]g1(`5p1y(zqi7y(46w.jpg
（10）一般在公司里面有哪些环境存在？
[*]开发环境（dev）：开发人员写程序代码的服务器环境
[*]测试环境（sit）：测试人员对软件进行测试的服务器环境
[*]验收环境，预发布环境（uat）：验收人员模拟生产环境的数据对软件进行验收
[*]生产环境、真实环境、线上环境（prod）：给广大用户使用的服务器环境，是公司盈利的环境
（11）V模式一些优缺点：
优点：
[*]改进了瀑布模型
[*]反应的测试活动与开发阶段有对应关系（开发阶段）
[*]划分了测试的阶段，添加了测试策略，分别对底层的代码进行了测试，也对用户的需求进行了测试
缺点：
[*]还是一个串行模型，前期阶段出现的问题只能在后期发现
[*]测试介入的时间较晚，在我们的软件开发生命周期的编码阶段之后才介入
*W模型：是v模型的补充，贯穿整个软件产品的周期，但还是串行的开发模式
C:\Users\Administrator\AppData\Local\YNote\data\weixinobU7VjiqFHbvqudPqzFQrfgIGLh4\fdbbdcfec6e746d1b03f8ae83c46d675\1638691487(1).png
H模型--重中之重：
C:\Users\Administrator\AppData\Local\YNote\data\weixinobU7VjiqFHbvqudPqzFQrfgIGLh4\d4dd63d89e9d477eb1790f516f0b6b91\(h_kn9(uzl4uh2giuy]6iwe.png
主要分为两个阶段：前期准备阶段，后期执行阶段
准备阶段：
1，进行需求澄清会议，由产品经理进行召开，一般参加会议的人员有整个项目的所有人（项目经理，开发经理、开发人员、测试经理、测试人员，（运维人员可来可不来），需求澄清会议结束后，当各方都觉得需求没啥问题，产品经理就会输出一个基线化的需求文档（*基线化：不会再有大的改动）
2，分析开发输出的概设和详设文档
3，测试经理会输出测试计划或者测试方案，安排测试人员的工作，以及输出测试方案，说明本次测试怎么执行
4，测试人员根据自己任务的需求文档编写测试用例，进行用例评审会议（一般由测试经理召开）
（1）组内评审（交叉评审）：由测试组内的同事进行互相评审
（2）组外评审：项目成员参与测试评审，一般是跟当前需求相关的测试人员和开发人员，产品经理一起进行
5，评审通过之后就会形成用例基线化文档，测试经理把这些用例文档提交到用例管理平台（textlink，禅道），分配给到对应的测试人员
6，搭建测试环境
执行阶段（开发进行提测、转测。也叫做转测试，开发人员把写好的代码进行打包，通过自测之后，提交给到测试人员进行测试，一般不会超过一天）
7，项目部署：把开发的代码包部署到测试环境中（理解：把软件包安装在测试环境），并且运行，一般是由测试运维执行，也可以是测试经理或者测试骨干执行
8，冒烟测试：
（1）测试当前版本的主体功能以及重要的分支功能
（2）一般不超过半天，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]