Day 1 何为软件测试
Part1：软件测试:就是验证程序的开发是否满足预期，确认质量，另一方面是提供信息，找出问题，反馈问题
需求测试：SRS，简称：“需求”，全称：需求规格说明书，就是描述我们软件需要实现的功能
界面测试：当前页面元素是否存在缺失，所有的元素拜访的位置是否合理，页面图片与文字是否正确，页面颜色与行距是否合理，简单理解就是页面的美观性
UI设计：页面设计人员，主要是对页面进行设计的，前端开发（开发分为前端和后端）
功能测试：验证软件的功能是否符合预期
金融-------涉及到财产的安全
政府-------涉及到信息的安全
安全性测试：安全测试，确保软件在不安全的环境下，不允许使用
可靠性测试 / 可用性测试：
可靠性测试：在规定的时间内完成规定的事情
可用性测试：产品可以使用
eg1：电梯可以在2分钟之内完成升降
eg2：电梯可以完成升降
可靠性包含可用性
可移植性测试：确保软件在不同的硬件环境下都可以正常使用
开发环境（dev）：开发人员写程序代码的服务器环境
测试环境（sit）：测试人员对软件进行测试的服务器环境
生产环境、真是环境、线上环境（prod）：给广大用户使用的服务器环境，是公司盈利的环境
兼容性测试：确保软件在不同的软件环境下可以正常使用
平台兼容、浏览器兼容、操作系统兼容
易用性测试：用户可以非常简单的使用，主要是是大众体验（尼尔森十大定律），结合界面测试一起做
压力测试--性能测试中的一个小类
压力测试：在不断地对系统施加压力直到突破临界值，找到临界值
负载测试--在临界值的位置，持续地运行一段时间，确保系统可以在临界值范围内稳定地运行
需求：电梯限重2000kg（1900-2000-2100-2200kg不断测试电梯的重力临界值）
硬件：存在实体的东西
软件：存在实体里面的东西，是虚拟的，数据化的
PC机--个人电脑
物理机--大型的实验室里面，配置是非常高的，作为公司服务器使用
便携机--我们的笔记本电脑（配置一般）
移动工作站（配置非常高，很贵）
OS：操作系统
win7，win10，win11--微软公司的操作系统
MACOS---苹果公司的操作系统（基于unix开发的系统）
Linux--开源系统，免费，开放源代码的系统
dos命令（命令行界面）：通过键盘驶入指令进行操作的，存在一定的专业性
图像化界面：有图形的界面。基本操作直接通过鼠标点击就可以完成，操作简单
文件：包含着内容的东西，打开文件后会调起某些程序去进行执行的
文件夹：用来存放文件或者文件夹的东西
目录：也就是文件夹
路径：（路径分为绝对路径和相对路径）用来判断计算机位置的东西
绝对路径：具体的位置（eg：和陌生人讲家庭住址）
相对路径：相对于本身位置去描述其他位置（eg：和熟人讲家庭住址）
面试题：你们公司的系统是什么架构的？
C/S架构（客户机与服务器架构）：（eg：微信，需要下载微信的客户端）
C/S架构特征：
1.需要下载客户端才能使用
2.客户端是要进行更新
3.用户少，安全性高
4.能对服务器减轻压力，对服务器性能要求低
5.上传和下载速度
B/S架构（浏览器与服务器架构）：（eg：京东网页版）
B/S架构特征：
1.直接通过浏览器进行访问的 ；
2.不需要用户进行更新；
3.用户多，安全性低
4.对服务器性能要求高，因为用户所有的操作都是发送到公司服务器，由服务器进行处理
5.上传和下载速度慢
客户提出他的需求（客户需求），之后就可以分解为项目需求，又了项目需求就可以展开项目
我们所谓的公司部门：研发部、软件研发部、软件开发部
测试（TE）：软件测试工程师，助理，初期工程师，中级工程师，高级工程师，测试架构师，专家，顾问
TC：测试用例，测试案例
TE：软件测试工程师
TL：测试组长
TPM:测试经理--管理测试人员，上下级沟通，安排测试进度
开发：编写代码
开发经理：管理开发人员，安排开发进度，技术指导
项目经理：统筹整个项目。 eg：管理项目的上线，项目人员的安排
产品经理：负责收集客户需求，整理为我们的项目专业的需求文档
需求分析师：协助产品对需求进行分析的人员
运维人员：维护公司的环境，负责项目软件程序的发布和部署
DBA：数据库管理员
Part 2：
缺陷bug：导致软件在运行过程出现的问题的简称
L1--A：致命
L2--B：严重
L3--C：一般
L4--D：建议，提示
测试用例：测试工程师根据需求文档，分析出需要测试的测试点，根据测试点去编写相关的测试步骤，对应的预期结果并且执行
测试用例：描述功能，显示操作步骤，已知预期结果的一个文档
瀑布模型：
1.测试是最后才介入，软件的问题是在最后面才发现
2.该模型的前一个阶段和后一个阶段是互相关注的，不能跨阶段的关注
3.适合需求稳定，不经常变动的
4.每个阶段都会生成对应的文档
V模型：主要是知道项目各个阶段生成的文档有哪些
1.需要说明：分析需求规格说明书（SRS），在公司中通过澄清会议对需求中的问题进行说明。
2.系统功能实际阶段：主要考虑整个系统需要实现什么功能。
3.概念阶段（概要设计阶段，HLD）：把系统的功能划分为多个模块，以及模块和模块之间接口设计。
4.详设阶段（详细设计阶段，LLD）：面向着某个模块里面的内容实现过程。
5.编码：根据详设的要求去编写相关的代码。
6.单元测试（UT）：主要测试具体一个模块里面的代码有没有满足详细设计的要求，检查代码的逻辑，一般由开发人员去做。
7.集成测试（IT）：将整个项目的模块拼接在一起，看各自模块是否正常运行
8.系统测试（ST）：不单保证当前模块是否正常，而且要保证相关联的模块之间的业务是否正常。一般只在公司里面集成测试和系统测试是一起做，称为i而兄台那个集成测试（SIT）
9.验收测试（UAT）：分为正式验收和非正式验收
（1）非正式验收又分为两种
α（alpha）验收：公司内部组织的一个验收测试。有开发和测试在场，有问题马上解决。
β（beta）验收：由特定用户进行用户测试，开发和测试都不在场，有问题就同意反馈统一修复。
（2）正式验收：正式版本，由广大的用户使用
10.一般公司由哪些环境存在
开发环境（dev）：开发人员写程序代码的服务器环境
测试环境（sit）：测试人员对软件进行测试的服务器环境
验收环境，预发布环境（uat）：验收人模拟生产环境的数据对软件进行验收
生产环境、真实环境、线上环境（prod）：给广大用户使用的服务环境，是公司盈利的环境。
11.V模型的优缺点：
优点：
（1）：改进了瀑布模型
（2）反应的测试活动与开发阶段由对应关系
（3）添加了测试策略，分别对底层的代码进行了测试，也对用户的需求进行测试
缺点：
（1）还是一个串行模型，前期阶段出现的问题只能在后期发现
（2）测试接入的时间较晚，在我们的软件开发周期的编码阶段之后才介入
W模型：
H模型==重中之重
主要分为两个阶段：前期准备阶段，后期执行阶段
准备阶段：
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.输出测试报告，需要达到测试准出条件（ 0 BUG上线），当然可以遗留1-2个建议性的缺陷，遗留的BUG必须明确后续的版本进行修改
12.回归测试分为两种情况：
（1）SIT过程的回归测试，除了SIT1以外的测试都叫回归测试
（2）SIT过程以外的回归测试，主要是对整个系统进行回归
面试题：你了解冒烟测试和回归测试的区别吗？
冒烟测试：又称为版本构建测试，提交测试，每一次版本构建（代码提交）时都要进行的测试，对版本的基础功能和主体功能进行的测试，一般不会超过半天，两个小时左右。
回归测试：系统维护阶段进行，对原有的功能，缺陷进行验证测试
区别：两者的区别在于测试阶段的不一样，冒烟测试是在版本提交时进行的，回归测试则是在系统维护阶段执行
在测试过程，执行测试用例时，发现一个问题（用例不通过）就要及时进行提交BUG的操作，叫做提单。
敏捷模型：交付的周期很短（游戏抢占市场用的比较多）
1.重点明确，及时调整（往着一个目标去开发，出现偏差就及时进行调整）
2.倾听用户的声音，相信用户的直觉（面向市场用户的需求进行开发）
3.勇于创新，小步快跑（头脑风暴，什么相关的功能都可以提出来，由问题，不适合就减掉，适合用户就继续进行改进）
4.持续不断地发现问题，解决问题（频繁迭代，保证主体的功能无误，允许小问题，但需要及时进行修改）
5.持续提升整个团队的产品能力
页:
[1]