1. 什么是软件？

软件是程序、数据、和相关文档的集合，指挥硬件完成特定的任务。简而言之，软件 = 程序 + 数据 + 文档（我认为测试人员应该对此有基本的了解，测试并非只是提bug，我们应该在自己的能力范围内，确保软件各组成部分的质量；当然我知道这绝非易事，作为一名初级软件测试人员，我的话语权较少对于软件产品影响不大，但这并不妨碍我对于软件工程每个阶段的思考，使得自己的每条建议都有价值）

1. 程序

定义：

程序是用编程语言写出的，可被计算机执行的一组有序指令，支撑起需求的业务逻辑。

内容包括：

• 后端逻辑代码（如Java、Python、C#）
• 前端的页面代码（如 HTML、CSS、JavaScript）
• 移动端应用代码（如 Kothin、Swift）
• 脚本/任务（如Shell、Python脚本、Groovy脚本）

2. 数据

定义：

数据是程序运行所需要输入、处理和输出的信息，也是系统位置状态的重要部分。

内容包括：

• 数据库中的业务数据（用户信息、产品信息等）
• 配置数据（如应用配置文件、运行参数、环境变量）
• 静态资源文件（图片、视频、地图等）
• 临时数据（缓存、会话、日志等）

3. 文档

定义：

文档是对软件的说明与记录

内容包括

类别	文档名称	内容举例
需求类	需求文档（Software Requirements Specification，简称SRS）	说明功能要做什么、业务背景、目标人群等
设计类	架构设计说明、数据库ER图	模块如何分布、数据表如何设计
开发类	接口文档、类注释、代码规范	接口的调用逻辑、各个模块的功能
测试类	测试用例文档、测试报告	怎么测、测了什么、测试周期、测得怎么样
运维类	部署说明、配置文档	系统如何上线、运行环境该如何配置
用户类	用户手册、使用指南	用户怎么操作、注意事项

4. 三者之间的联系

软件组成	比喻	说明
程序	机器的电路	控制机器的运行流程
数据	机器原料	机器加工的对象、决定产出
文档	机器的使用说明书	告诉你怎么装配、操作、修理

2. 什么是软件的生命周期，什么是软件的开发模型？

1. 软件生命周期的过程：

1. 可行性研究（Feasibility Study）：团队有没有这个能力干（技术可行性）、干了有没有赚头（经济可行性）、注意隐私协议，个人信息保护等（法律/社会可行性），输出《可行性研究报告》（能参会最好参不上会的这个阶段测试人员有机会就打听一下，知道我们将要做哪个赛道的产品，有功夫就找找类似产品瞅瞅，心里有个数）。

2. 需求分析：明确用户和系统的功能/非功能需求，此时产品和项目就要开会收集用户的合理需求。

• 编写需求规格说明书（SRS）：仔细看看需求说明书，消除模糊需求，这是测试的一把尺。比如需求说"系统响应要快",你就问产品响应时间控制在几秒内；需求文档中的内容应量化，需求文档写的越好，测试用例写的就越快；我们有的冲刺项目使用Jira的冲刺建立一条条任务附上UI设计图，来指导开发，我就觉得很舒服，开发和测试能够直接在评论中向产品澄清需求，消除信息差，还能够留痕，每日bug每日清，很利索；需求分析会议不要关注什么错别字，序号什么的，别讨人嫌。
• 出原型图：（我们产品用mastergo画）快速验证产品功能逻辑和用户流程，帮助团队和用户对齐需求，减少理解偏差。修改原型，确认需求。
• 进行需求优先级排序：这块儿，咱们应该好好记录，对应用例的优先级。

3. 概要设计（High-Level Design, HLD）：开发人员定义系统架构与模块划分，输出《概要设计文档》（对技术很感兴趣的别只盯着文档，没事儿的时候跟开发撩闲的时候，捧捧开发，问问技术难点啥的了解了解技术，因为写出来的能叫心里话儿？）：

• 选择什么技术栈（如前端：Vue.js + 小程序、后端：Spring Cloud微服务）
• 绘制系统架构图（如UML组件图）
• 数据库ER设计
• 概要设计的后期和详设初期，要产出UI设计图（我们单位产品用蓝湖画），这是测试的另一把尺，但是如果是MVP产品的话可能跳过高保真UI，直接用原型图开发。

• 测试人员要编写测试计划：这里面最重要的测试的排期问题，概要设计阶段开发会与产品频繁的确定需求，这时候很容易出现需求不同步的情况，这时候咱们自己一定要多长点精神头，问产品设计方案是否存在变更未同步情况。
• 概要设计主要目的是什么，我们可以将其比作画房子的整体蓝图，：
  • 先确定房子长啥样，比如：是别墅还是平房？（技术选型：用微服务还是单体架构？）；几层楼？每层干嘛用？（模块划分：用户模块、支付模块…）；水电怎么走？（数据库和接口大概怎么设计？）
  • 为啥要做？：避免盖到一半发现“厕所没地方放”！（防止后期大改）；让施工队（开发人员）知道先干啥后干啥。（分工协作）

4. 详细设计（Low-Level Design, LLD）：细化模块实现逻辑。

• 类设计（UML类图）。
  • 明确代码怎么“分家”：就像规划家里的家具，床放卧室、冰箱放厨房，避免所有东西堆一起。这里面家具就是属性代码，放在哪就是行为代码
  • 防止程序员互相打架：A写“用户类”时，B不会重复造轮子。
  • 举例：设计“外卖订单”类：属性：订单号、金额、状态；方法：计算运费()、取消订单()
• 算法设计（伪代码/流程图）。
  • 把“脑子里的逻辑”写清楚：避免程序员写代码时卡壳，比如“优惠券折扣到底先减满减还是先打折？”
  • 提前发现坑：像做题先写解题步骤，能提前发现算不明白的地方，否则开发边写边想，最后性能可能很差
• 接口定义（API文档）。
  • 规定模块之间怎么“打电话”：就像外卖小哥和商家约定：“到了必须喊‘您的外卖到了！’”，而不是随便敲门。
  • 防止前后端互撕：前端说“我要订单数据”，后端返回一坨看不懂的，接口文档就是“翻译协议”。
• 输出：《详细设计文档》。
• 确定编码规范（讲究点的话）
• 软件测试人员根据UI原型图页面，进行测试用例的设计。使用开发Postman工作台中的Mock API，提前验证逻辑（如果有的话）。

5. 实现（Implementation/Coding）：编写可运行代码。

• 遵循编码规范
• 单元测试（JUnit/pytest）
• 版本控制（Git分支策略/或者SVN）
• 使用代码扫描工具进行代码扫描（偶尔做）
• 最终输出可执行代码与单元测试报告（关于单元测试报告，有的公司所谓的单元测试就是分模块的功能测试，不进行模块之间的测试/或者是测试的左移与开发并行，还是以公司实际为主）

6. 集成测试（Integration Testing）：验证模块间交互，集成测试是技术验收。

• 接口测试（Postman、Jmeter）

7. 确认测试（Validation Testing）：确保系统符合用户需求,确认测试是业务验收。

• 用户验收测试，通常是手工测试，根据用例执行的业务测试、UI测试、以及用户体验；手工点一点后，可以让用户进行体验测试。
• 性能测试（JMeter）
• 安全测试（Burpsuite）

8. 维护（Maintenance）：修复问题并优化系统。

9. 退役（Retirement）：

• 数据迁移（如旧系统用户数据导入新系统）。
• 通知用户（停服公告）
• 归档代码和文档。（里程碑）

2. 软件的开发模型

1. 瀑布模型：将软件生命周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品的项目

2. 敏捷开发模型：

1. 以人为核心、迭代、循序渐进的开发方法、小步快跑
2. 强调开发人员与业务人员紧密合作、面对面沟通
3. 采用迭代思想频繁交付新版本
4. 重点：每日都要开站会每位成员都要交代三件事：

• 昨天完成了什么
• 今天计划完成什么
• 是否有困难需要帮助

模型特点及适用范围

模型名称	技术特点	适应范围
瀑布模型	分阶段，阶段间存在因果关系，各阶段完成后都有评审， 允许反馈，不支持用户参与，要求预先确定需求	需求完善定义且不易变更的软件系统
敏捷模型	个体和互动高于流程和工具；工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划	对系统开发限制期限，复杂度较高的项目

3. 软件开发模型的作用

• 直观地表达软件开发全过程，明确了每个阶段的工作内容和规范的文档
• 开发人员就可以根据这些文档和过程，高效、合理的进行软件开发
• 大家遵循相同的流程和文档，避免不一致的问题

3. 为什么需要软件测试

1. 什么是软件测试

1. 定义：通过人工或自动化的方式来验证软件的实际结果与用户需求是否一致的过程

2. 软件测试常见分类：黑盒测试、白盒测试、灰盒测试。

3. 软件测试的目的：

• 从用户的角度：希望软件容易操作
• 从开发者的角度：希望软件产品正确实现了用户需求
• 从领导者的角度：希望测试出所有的问题并得到解决

2. 软件测试对象

1. 程序（代码逻辑）：

• 测什么：
  • 代码功能是否正常（如点击按钮能否提交订单）。
  • 性能是否达标（如每秒能处理1000个请求吗？）。
  • 安全性是否有漏洞（如SQL注入能否防住？）。
• 怎么测：
  • 手工测试：点点按钮，看看结果对不对。
  • 自动化测试：用脚本批量验证接口返回值。

2. 数据（输入/输出/存储）

• 测什么：
  • 输入数据：用户提交的表单、API参数是否被正确处理。
  • 输出数据：数据库记录、页面显示结果是否准确（比如空字段应显示“-”，而不是“null”）
  • 数据流：A模块到B模块的数据传输会不会丢字段？
• 怎么测：
  • 构造边界值数据（如输入“姓名”字段超长字符串）。
  • 检查数据库表字段是否匹配设计文档。（数据存的是字符串还是浮点数，这块都是开发自查，测试人员顶多拥有产品数据库的查询权限，你要是测试平台开发，那是你自己的数据库，你随意）

3. 文档（配套材料）:

• 测什么：
  • 需求文档：是否清晰无歧义？（比如“用户”是指买家还是卖家？）
  • 设计文档：接口定义是否完整？（如返回字段少了个order_id？）
  • 用户手册：操作步骤是否和实际系统一致？
• 怎么测：
  • 对照文档逐条检查系统行为（俗称“走查”）。
  • 模拟用户按文档操作，看能否完成任务，操作文档得讲述明白，专有名词得有注释（否则客服会被用户咨询电话轰炸，“我们按照你们文档操作，怎么不好使”；“文档中的XXX是什么意思”）。

3. 软件测试的原则

原则一：尽早进入软件测试

举个例子，我们在测试APP的时候，如果是在没上线时改个普通bug加打个新包大约30分钟到1小时，如果上线了，出现bug那就得按天来算了，因为有些因素团队无法控制，就比如APP重新上线应用商店前的审核。

原则二：穷尽测试是不可行的

这句话是领导们最不喜欢的一句话，但是事实就是如此；比如：即使一个简单登录功能，输入组合也近乎无限（用户名长度、特殊字符、并发请求…）。这就要求测试人员要有一个场景优先级策略。

原则三：程序员应避免检查自己的程序

咱讲实话，这个原则，大多数公司没法做到，咱倒是听说过有这么做的，那确实不是一般团队，刀尖向内，那代码不是能跑起来就行，有说法。

原则四：充分注意测试中缺陷的群集现象

这点很重要，bug总是扎堆出现的。

原则五：严格执行测试计划，排除测试的随意性

咱那个测试用例得好好写，我觉得测试人员的水平就体现在用例的设计上，咱说实话，要将用例全面覆盖需求，还是很有难度，明确范围、资源、进度、准入/准出标准，至于是采用作者自测、还是交叉测试，就看项目的大小与业务的难度，你比如说关于金融方面的业务那必须得交叉。

原则六：应当对每一个测试结果做全面的检查

原则七：妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便

原则八：设计测试用例时，应当包括合理的输入数据和不合理的输入数据

原则九：测试用例应由测试数据和与之对应的预期输出结果这两部分组成

4. 软件测试的流程

大多数项目中，软件测试的流程都是：

1. 需求澄清，理解需求，理解功能点，才知道测什么怎么测
2. 编写测试计划，包括什么时间测试组中用哪些人测哪些模块
3. 编写测试用例/点
4. 开发提测，执行冒烟测试准入
5. 执行全量测试，提交、验收BUG
6. 编写测试报告，输出测试结果，归档测试文档
7. 生产环境回归测试，关注线上问题

4. 软件测试模型

1. 什么是软件测试模型

定义：测试模型是将测试活动进行了抽象，明确了测试与开发之间关系的模型

2. 常见的软件测试模型

1. V模型

• 缺点：
  • 容易使人理解为测试是软件开发的最后一个阶段。没有明确指出对需求、设计的测试，没有尽早进入软件测试
  • 由于它的顺序性，当编码完成之后，正式进入测试时，这时发现的一些bug修改起来成本较大。
  • 实际中，由于需求变更较大，导致要重复变更需求、设计、编码、测试。返工量大。
• 优点：
  • 有底层测试又有高层测试
  • 将开发阶段清楚的表现出来

2. W模型

• 优点
  • 测试与开发是同步进行的，从而有利于尽早的测试、发现问题
  • 强调了测试计划等工作的先行和对系统需求和系统设计的测试
  • W模型有利于尽早地全面的发现问题
• 缺点：
  • 仍把开发活动看成是从需求开始到编码结束的串行活动，只有上一阶段完成后，才可以开始下一阶段的活动，不支持迭代

3. H模型

1. H模型强调软件测试是一个独立的流程，贯穿整个产品的周期
2. H模型的关键点在于测试的准入条件，通常有以下几个准入条件，满足才能进行全量测试
   • 测试点/测试用例编写完成，且通过了评审
   • 开发提测通过，通过的前提：
     • 冒烟测试通过
     • 测试环境搭建完成，提供环境IP、测试账号密码
     • 如果设计借口测试，要提供借口测试文档与数据库文档
     • 给出测试建议
     • 开发自测记录（提测前，由测试人员提供一份冒烟测试用例，开发在提测前自己先执行一遍，这是最理想的情况下）
3. 开发提测的意义在于，避免不负责任的开发将质量不好的版本随意丢给测试人员，造成经常冒烟测试不通过，频繁打回，浪费时间降低工作效率。
4. 流程中的准出原则一般指剩余BUG量，如果剩余BUG暂时无法修复，但是bug对产品使用整体影响不大，可将其挂起，待下版本修复。bug等级共四级，3级bug不超过3个，四级bug不超过4个，每个公司的标准有所不同。