【软件测试理论】有效帮助你了解什么是软件测试！

1 软件测试概述

1.1 什么是软件

硬件概念

硬件是计算机硬件的简称，是指计算机系统中由电子，机械和光电元件等组成的各种物理装置的总称。

这些物理装置按系统结构的要求构成一个有机整体为计算机软件运行提供物质基础。

特点 :

看得见摸得着

软件概念

软件是一系列按照特定顺序组织的计算机数据和指令的集合。

特点 :

看得见摸不着

1.2 软件分类

按开发规模划分

小型 -- 开发周期 4 个月内 -- 参与人数 10 人以下

中型 -- 开发周期 1 年以内 -- 参与人数 10~100 人

大型 -- 开发周期 1 年以上 -- 参与人数 100 人以上

按用户对象划分

产品软件 : offiffiffice / wechat / qq / 百度

项目软件 : 为企业定制的 OA 系统等

按技术结构划分

单机版 : 计算机 / 画图工具

C/S 架构 : qq / LOL

B/S 架构 : 新浪 / 百度 / 搜狐

按功能划分

应用软件 : 京东 / 金山词霸

系统软件 : 数据库管理系统 / 各种驱动软件

操作系统比较特殊 , 也属于系统软件

1.3 什么是软件测试

概念

在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评

估的过程。

核心 : 在规定的条件下对程序进行操作，以发现程序错误的过程 测试对象

源程序

目标程序

数据

文档 ( 需求文档 / 设计文档等 )

测试目的

找缺陷

2 软件开发流程

模型 : 规范化的流程

开发模型？测试模型？软件开发模型？软件测试模型？

2.1 软件开发模型

概念

软件开发包括需求 , 编码 , 测试等阶段 , 软件开发模型是规范化的软件开发流程

测试人员为什么要了解开发模型 ?

了解何时介入 , 何时退出工作

了解各阶段工作重心 , 明确自己各阶段的工作内容

分类

1. 边做边改模型

2. 瀑布模型

3. 快速原型模型

4. 增量模型

5. 螺旋模型

6. 喷泉模型

7. 智能模型

8. 混合模型

9. RUP 模型

10. IPD 模型

2.2 开发模型之 - 瀑布模型

概念

将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活

动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

流程图 组成阶段 : 6 个 ( 如图 )

时序 : 自上而下 , 互相衔接 , 如同瀑布

角色与产出

制定计划

参与角色 : boss , 产品经理

产出 : 可行性分析报告

需求分析

参与角色 : 产品 , 开发 , 测试

产出 : 需求文档

一切软件测试活动的依据

软件设计

概要设计

参与角色 : 开发 ( 老大 )

产出 : 概要设计说明书

详细设计

参与角色 : 开发

产出 : 详细设计说明书

程序编写

参与角色 : 开发

产出 : 待测程序

软件测试

参与角色 : 测试

产出 : 测试报告 / ( 操作手册 )

运行维护

参与角色 : 运维

产出 : 运维手册 2.3 开发模型之 - 快速原型模型

概念

在开发系统之前，先做一个原型 (demo/ 小样 ), 然后让用户参与进来从而收集整理相关反馈信息 , 在该原

型的基础上，逐渐完成整个系统的开发工作

原型的分类

可运行的软件

图

原型图

交互图

思考 :

分别由谁负责 ?

成本问题 , 最常见的原型是什么 ?

2.4 小结

瀑布模型

特点

线性模型，是其他模型的基础

优点

阶段清楚

一个阶段只执行一次，当前阶段结束后，只需要关注下一个阶段的工作

文档驱动

缺点

不适用于需求变化的项目

返工量大

应用场景

需求清晰的大型项目，建筑、银行、保险等

快速原型模型

优点

用户参与

降低了需求变化带来的项目失败的风险

缺点

不适用于大型项目

应用场景

需求变化的中小型项目

2.5 敏捷开发

背景 敏捷方法是一种 20 世纪 90 年代后开始逐渐引起广泛关注的新型软件开发方法。它们的具体名称、理念、

过程、术语都不尽相同，相对于 “ 非敏捷 ” ，更强调团队协作、面对面的沟通（认为比书面的文档更有

效）、频繁交付新的软件版本、能够很好地适应需求变化，也更注重软件开发中人的作用。

基本原则

个体和交互 胜过 过程和工具

可以工作的软件 胜过 面面俱到的文档

客户合作 胜过 合同谈判

响应变化 胜过 遵循计划

特点

一切从简 ( 流程 / 文档 / 交流方式等 )

尽早交付

持续迭代 , 持续交付 , 周期越短越好

以人为本 ( 相信自己的团队 , 规律的反省 / 调整 / 优化 )

90% 以上的公司采用敏捷开发

模型

3 软件测试流程

3.1 软件测试模型

概念

规范化的测试流程

分类

V 模型 ( 重点 )

W 模型 ( 重点 )

X 模型

H 模型

3.2 V 模型

概念

以 “ 编码 ” 为黄金分割线，将整个过程分为开发和测试，并且开发和测试之间是串行的关系

流程图 特点

开发与测试串行

缺点

测试介入过晚 , 返工量大

3.3 W 模型

概念

W 模型是由两个 V 模型组成，一个是开发阶段，一个测试阶段 , 又称为双 V 模型

流程图

特点

开发与测试并行

优点

测试可以提早介入

缺点

虽然开发与测试并行了 , 但总体流程仍然是串行 , 不支持敏捷开发

4 最佳实践流程 -1 迭代周期是多久 ?

一个周期内 , 各个环节的时间占用多少 ?

5 软件测试分类

5.1 按阶段划分

5.1.1 单元测试

概念

指对软件中的最小可测试单元进行检查和验证

应用场景

测试某个函数实现的功能是否正确

5.1.2 集成测试

概念

在单元测试的基础上 , 将所有模块按照设计要求组装成子系统或系统，进行测试

原因

实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作

5.1.3 系统测试

概念 系统测试是将经过集成测试的软件，和 操作系统 / 硬件 看作一个整体，在实际运行环境下进行测试

举例

百度在浏览器和手机上都能打开 , 那么根据不同环境 , 我们都需要进行测试

5.1.4 验收测试

概念

客户组织的基于最开始的需求进行的验证性测试，主要检验乙方（软件实施方）完成的系统是否满足甲

方（付款方）的 业务 需求

分类

按用户对象划分

项目验收

产品验收

按阶段划分

α 测试（内测版本）

β 测试（公测版本）

γ 测试（待发布版本）

负责人（扩展）

客户（甲方）

委托第三方评测机构（中国软件测评中心）

乙方（软件实施方）

5.2 按是否考虑代码逻辑划分

5.2.1 黑盒测试

概念

黑盒，顾名思义就是：把测试对象看作一个不能打开的黑盒子。测试时，测试人员完全不用考虑盒子里

面的逻辑结构和具体运作，只依据需求文档，检查程序的功能是否符合它的功能说明，检验输出结果对

不对

测试依据

需求文档

重点

以 用户 的角度，从 输入数据 与 输出数据 的对应关系出发进行测试的。

分类 功能相关

功能测试 : 检查产品功能是否满足需求

界面测试 : （又称 UI 测试 ） , 检查页面元素是否符合 UI 设计 , 页面是否美观 ( 测试界面各元素布

局是否合理 , 整体风格是否一致 )

易用性测试 : 用户体验

专项测试 , 如 : 安装 / 卸载 / 升级测试 , 网络专项测试

性能相关

性能测试 : 模拟用户场景 , 测试系统的各项性能指标 , 查看是否满足需求

压力测试 : 在高压 ( 高负载 / 资源少 ) 的情况下运行测试 , 找出性能隐患

负载测试 : 不断增加负载 , 测试软件吞吐量上限 , 以验证系统的负载能力

5.2.2 白盒测试

概念

与黑盒恰恰相反，这种方法是把测试对象看作一个打开的透明盒子。测试时，测试人员会利用程序内部

的逻辑结构及有关信息，通过在不同点检查程序状态，检验程序中的每条通路是否都能按预定要求进行

正确工作

测试依据

源代码

重点

必须检查程序的内部结构，从程序的逻辑着手，得出测试数据

5.2.3 灰盒测试

概念

介于黑盒测试与白盒测试之间 , 只关注一部分代码逻辑

黑盒 / 白盒和灰盒的区别

黑盒和灰盒的区别：

黑盒测试无需关心软件系统内部各个模块之间如何协作

灰盒测试，需要关心模块与模块之间的交互

白盒和灰盒的区别：

灰盒测试无需关心模块内部的实现细节。对于软件的内部模块，灰盒测试依然把它当成一个

黑盒来看待 白盒测试则不同，还需要再深入地了解内部 模块的实现细节和各个分支

应用场景

常用于集成测试 , 系统测试

5.2.4 小结

各测试阶段对应关系

5.3 按是否运行划分

5.3.1 静态测试

概念

静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序

的正确性。

测试对象

文档

需求文档

各类设计文档

源程序

5.3.2 动态测试

概念

动态测试方法是指通过运行被测程序，进行测试

测试对象

代码

软件

系统

思考 : 动态测试的基本过程 ( 步骤 )

分析一下要测什么

写写你怎么测

运行软件

然后你就去测

最后说明一下测试结果

5.4 按是否自动化划分

单元测试 --> 白盒

集成测试 --> 白盒 / 灰盒

系统测试 --> 黑盒 / 灰盒

验收测试 --> 黑盒 5.4.1 手工测试

手工的方式去执行测试

5.4.2 自动化测试

需要借助工具或代码去执行测试

5.5 其他

5.5.1 冒烟测试

针对最基本的功能或者流程进行的测试

5.5.2 回归测试

概念

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

应用场景

bug 回归

旧功能回归

回归原则

每一个版本都需要进行前一个版本的回归测试工作

需要轮次

取决于实际项目计划、开发计划、测试计划和项目本身规模与复杂度

缺点

工作量大

解决方案

自动化

5.5.3 随机测试

测试其他人没有测到的部分

测试一些重要功能

需要一定经验

需要熟悉被测软件

5.5.4 探索性测试

测试设计与测试执行同时执行

依赖测试思维

6 最佳实践流程 -2

7 测试用例 7.1 概述

概念

指导对软件进行操作 , 帮助证明软件功能或发现软件缺陷的一种说明 , 最终形成文档

7.2 登录案例

软件测试用例的 8 大要素

编号 ID （唯一性）

项目 / 模块

标题（见名知意）

前置条件

外在环境（网络、系统服务正常与否）

本模块的前置模块

测试数据

测试步骤

预期结果

需求文档

优先级（在资源受限制（时间、人员）时，测试用例执行的先后顺序）

7.3 作用

便于理清测试思路，确保需覆盖测试的功能点无遗漏

便于测试工作量的评估

便于提前准备测试数据

便于把控测试工作进度

便于回归测试

便于测试工作的组织，提高测试效率，降低测试交接成本

8 测试用例设计方法

8.1 总体介绍

应用场景

我们知道 , 黑盒测试的测试用例是无法穷尽的 , 我们需要科学的方法帮我们把无限变为有限

常见的 8 大测试用例设计方法

等价类（五星）

边界值（五星）

判定表（五星）

因果图（二星） 正交法（三星）

场景法（五星）

流程图（五星）

错误推测法（二星）

8.2 等价类划分法（五星）

应用场景

有数据输入的地方就可以使用 , 如 : 输入框

为什么要用等价类划分法 ?

从大量数据中划分范围（等价类），然后从每个范围中挑选代表数据，这些代表数据要能反应这

个范围内数据的测试结果。

步骤

1. 需求分析

2. 划分等价类 : 有效等价类 / 无效等价类

满足需求的输入范围为有效等价类 , 反之为无效等价类

3. 设计测试用例

举例

1. 需求分析 : 输入条件

A: 6~10 位

B: 自然数

2. 划分等价类

有效等价类 ( 同时满足条件 A 和 B)

无效等价类

不满足 A: 不足 6 位的自然数 或 10 位以上的自然数

不满足 B: 非自然数 ( 比如带字母 )

都不满足 : 不足 6 位的非自然数 或 10 位以上额非自然数

3. 设计测试用例 (demo 只有格式 )

8.3 边界值（五星）

应用场景

与等价类划分法组合使用

为什么要用边界值法 ?

边界值法是等价类划分法的重要补充

大量程序错误往往容易发生在边界上

需求 : QQ 账号输入 , 6~10 位自然数 步骤

1. 需求分析

2. 划分等价类

3. 确定边界值 : 找出上点 / 内点 / 离点

4. 设计测试用例

边界值

上点：边界之上的点（比如两位数加法器的 99 ）

内点：边界之内的点（比如两位数加法器的 -99<x<99 ）

离点：离边界最近的左右两点（比如两位数加法器的 -100 ， -98 ， 98 ， 100 ）

举例

1. 需求分析 : 略

2. 划分等价类 : 略

3. 确定边界值

位数

上点： 6 10

内点： 8

离点： 5 7 9 11

4. 设计测试用例

设计输入数据

有效等价类 : 代表数据 , 分别输入 6/ 7/ 8/ 9/ 10 位自然数

无效等价类 : 代表数据 , 分别输入 5/ 11 位自然数 ; 8 位字母

练习

8.4 判定表（五星）

应用场景

# 需求 : QQ 账号输入 , 6~10 位自然数

# 需求 : 填写文章标题 , 要求标题长度 10~20 用于处理较复杂的业务逻辑 , 能避免遗漏测试点

要求 : ( 需同时满足 )

输入项之间互相独立 , 输入值只有 2 个取值 ( 或是和否 )

输出项之间互相独立 , 输出结果只有 2 个取值 ( 或是和否 )

组成

条件桩： 输入

条件项： 输入值

动作桩： 输出

动作项： 输出值

步骤

1. 需求分析

2. 通过判定表法 , 列表分析

3. 设计测试用例，每列数据对应一条测试用例

举例

1. 需求分析

分析输入 / 输出 , 查看是否符合判定表的应用场景

1

2

3

4

输入条件 1

欠费 ?

Y

Y

N

N

输入条件 2

关机 ?

Y

N

Y

N

结果 1

允许主被叫

√

结果 2

不允许主被叫

√

√

√

2. 通过判定表 , 分析

如何简化判定表 ?

3. 设计测试用例，每列数据对应一条测试用例

练习

https://www.cnblogs.com/feng0815/p/8794400.html

8.5 因果图（二星）

应用场景

输入条件或输入条件的组合比较多，组合使用判定表与因果图。

为什么要用因果图 ?

借助图像手段去分析判定表

步骤

需求 : 若用户欠费或者关机，则不允许主被叫 将数字标识输入和输出

画出因果图

将因果图转换为判定表

生成测试用例

举例 ( 了解 )

说明 :

恒等（

- ）：条件满足时，结果成立

非（

~ ）：条件不满足时，结果成立；条件满足时，结果不成立

或（

V ）：只要有一个条件满足，结果就成立

与 / 且 (^) ：多个条件都需要满足时，结果才成立

8.6 正交法（三星）

概念

是一种古希腊就有的实验设计方法 , 基于数学概率学知识 , 设计最经济的实验路径

应用场景

输入条件较多 , 每个条件的取值的可能性也比较多时 , 可以使用正交法

步骤

需求分析

采用正交法设计测试用例 ( 一般使用工具 )

设计测试用例（一行就是一条测试用例）

举例

# 需求 : 如果想对文件进行修改，

输入的第一列字符必须是 A/B ，第二列字符必须是一个数字，

如果第一列字符不正确，则给出信息 L ；

如果第二列字符不正确，则给出信息 M 。

# 需求 : 假设有一个用户筛选功能，有 3 个输入分别是体型、年龄段、性别，

体型有 3 个取值：胖、适中、瘦；

年龄段有 3 个取值：老人、青年、儿童；

性别有 2 个取值：男，女； 使用 allpairs 工具自动生成

其他示例了解地址 : https://www.cnblogs.com/killmyday/archive/2011/05/30/2063557.html

8.7 场景法（五星）

应用场景

用于各种测试阶段 , 比如系统测试 / 验收测试阶段 , 模拟用户操作场景 ( 测试多个功能组合 )

步骤

1. 需求分析

2. 确定基本流与备选流设计测试场景

基本流 : 模拟用户正常流程或操作的场景

备选流 : 模拟用户错误操作或流程的场景

图解 : 3. 一个场景就是一条测试用例

举例

1. 分析用户操作微信发红包可能遇到的情况

2. 分析场景如下 :

场景 1: 成功发红包 === 基本流

场景 2: 余额不足 === 备选流 1

场景 3: 被删除好友 / 被拉黑 === 备选流 2

场景 4: 网络异常 === 备选流 3

...

3. 编写测试用例

练习

使用场景法 , 为例图设计测试用例

8.8 流程图法（五星）

应用场景

用流程图的方式去展现基于用户使用场景

步骤

1. 需求分析

2. 绘制流程图

常用符号

开始或结束：椭圆

方向或路径：箭头

处理或操作：长方形

判断：菱形

输入或输出：平行四边形

# 需求 : 测试微信发红包的功能 , 用场景法设计测试用例 3. 设计测试用例（一条流程路径就是一条测试用例）

举例

8.9 错误推断法（二星）

应用场景

测试人员使用经验或直觉去发现程序的错误

问题 : 有经验的老鸟 , 是如何使用此方法的 ?

举例

新开发的功能，与其相关的业务，或者数据，容易出现问题

分页功能，页码搜索

新功能的，异常场景

列表功能，为空时，是否报错 ？

文本框， “ 空格 / 特殊字符 ” 的处理

8.10 测试用例设计方法总结

原则

具有输入功能，但输入之间没有组合关系 == 》推荐是等价类划分法

输入有边界如长度、类型 == 》用边界值法补充测试用例

多输入、多输出、输入与输入之间存在组合关系、输入与输出之间存在依赖和制约关系 == 》推荐

使用因果图和判定表

# 需求 : 根据生活中的 ATM 取款功能 , 画出业务流程图 用最少的测试用例获得最大测试覆盖率时 == 》推荐使用正交法

多个功能的组合测试 == 》流程图与场景法

最后推荐使用错误推测法来进一步补充测试用例

9 软件缺陷与缺陷管理

学习目标

掌握软件缺陷的定义

掌握缺陷报告的基本内容

掌握缺陷的跟踪过程（缺陷的生命周期）

掌握 SVN 的常用操作

了解 JIRA 的基本使用

9.1 软件缺陷概述

概念

软件缺陷就是软件的毛病 , 它可能存在于功能 / 性能 / 易用性等各个方面 , 包括已发现和未发现的

业内经常把缺陷称为 bug, 故事背景如下 :

从电脑诞生之日起，就有了电脑 BUG 。第一个有记载的 bug 是美国海军的编程员格雷斯 · 霍波发现

的。

1945 年 9 月 9 日，下午三点。霍波中尉正领着他的小组构造一个称为 “ 马克二型 ” 的计算机。这还不

是一个完全的电子计算机，它使用了大量的继电器。机房是一间第一次世界大战时建造的老建

筑。那是一个炎热的夏天，房间没有空调，所有窗户都敞开散热。

突然，马克二型死机了。技术人员试了很多办法，最后定位到第 70 号继电器出错。霍波观察这个

出错的继电器，发现一只飞蛾躺在中间，已经被继电器打死。她小心地用镊子将蛾子夹出来，用

透明胶布帖到 “ 事件记录本 ” 中，并注明 “ 第一个发现虫子的实例 ”

通俗的理解

业内标准 :

软件未实现需求文档 要求 的功能

软件实现了需求文档 未提到 的功能

软件未实现需求文档 虽未明确提及但应该实现 的目标

软件 难以理解 / 不易使用 / 运行缓慢 或 ( 从测试人员角度看 ) 最终用户会认为不好

概括的说 : 实际结果与预期结果不一致

思考

只有在测试阶段才去发现和解决 bug 吗 ?

9.2 缺陷产生的原因

需求原因 : 文档错误 / 有疏漏等

编码原因 : 设计有误 / 编码错误等

其他原因 : 时间紧 , 沟通理解有问题 , 甚至如立项就是个错误等

缺陷的产生 , 有没有测试的原因 ? 9.3 缺陷的描述

应用场景

测试人员发现 bug 后 , 应准确无误的描述 bug, 描述的内容应该具有规范性

要素

编号（ ID ） : 唯一性

模块

缺陷标题 : 见名知意 / 让开发人员理解 / 唯一性

严重程度

严重 : 主功能不可用、 crash 问题、闪退、不能启动

一般 : 次要功能不可用，边界、异常未进行处理等

微小 : 易用性问题、界面展示，小的性能问题等

建议

优先级

高 : 阻塞性问题 , 影响继续测试

中 : 正常流程 , 本次迭代上线修复即可

低 : 可以延期到下个版本解决

复现步骤

预期结果

实际结果

缺陷类型 : 代码错误 / 界面错误 / 兼容性错误 / 性能问题 / 安全问题 / 易用性问题

缺陷状态

新建

已指派

打开

修复（已解决） / 拒绝 / 延期

完成 / 再次打开

9.4 缺陷报告

概念

一个记录缺陷的文档

组成

包括了缺陷描述的全部内容 , 附加测试日期 , 解决人员 , 解决日期 , 解决方案 和 文档本身的说明信息 等 Bug ID

测试日期

测试人员

Bug 类型

功能模块

环境 ( 系统 / 浏览器 )

严重程度

优先级

Bug 标题

步骤 / 结果

解决者

解决日期

解决方案

注意事项

一个缺陷一个报告

尽量确保缺陷可以重现

简洁、准确、完整

9.5 BugList

概念 ?

作用 ?

9.6 缺陷的统计

应用场景

统计数据需要整理到测试报告中，方便项目相关负责人知悉当前测试版本的整体质量

作用

了解隐患 绩效考核

统计维度

按照缺陷的活动分布统计 : 第几轮测试 ? 验收测试 ? 上线后 ?

按照缺陷的严重程度分布统计 : 严重的多 ? 建议的多 ?

按照缺陷引入源分布 : 需求引入 ? 编码引入 ?

按模块统计 bug: 哪个模块 ?

按负责人统计 bug: 哪个开发盛产 bug?

按解决方案统计 : 已解决 ? 不是 bug? 无法重现 ? 设计如此 ? 不予解决 ? 外部原因 ?

图例 :

9.7 缺陷管理 - 禅道

9.7.1 总体介绍

背景

工作中 , 测试人员需要用 BugList/ Bug 统计等形式去汇报工作 , 那么是用手动的方式去管理吗 ?

当然不是 , 我们可以借助工具帮我们管理 Bug: 如 BugFree/ Bugzilla/ Mantis/ Jira/ 禅道等

为什么选择禅道

其中 Jira/ 禅道属于项目管理工具

禅道是国产的

9.7.2 禅道安装

安装环境

双击提供的 phpStudy20161103.exe 进行安装 , 好处是纯绿色解压

安装禅道

1. 解压提供的开源版压缩包到指定目录下 , 如我的是 : D:\phpStudy\WWW\zentaopms 也可以从官网下载

2. 配置服务目录信息 , 即去哪个项目下找服务

打开 httpd-conf, 配置 DocumentRoot "D:\phpStudy\WWW\zentaopms"

3. 配置禅道的运行依赖

打开 php.ini, 删除 extension=php_openssl.dll 前的 ";"

4. 启动 phpStudy

5. 启动禅道的安装

浏览器输入 http://localhost/www/install.php 回车进行安装

注意

安装成功后 , 会要求修改密码 , 如果对于弱口令检查有意见 , 可以登录后关闭该项检查

后台 -> 安全 -> 进行修改

9.7.3 禅道协同工作流

https://www.zentao.net/book/zentaopmshelp/165.html

9.7.4 测试人员使用流程

内容

测试用例管理

Bug 管理

测试用例管理

1. 编写用例

2. 用例评审

3. 用例执行

Bug 管理

1. 提交 Bug

2. 回归测试

回归测试通过则关闭 bug

回归测试不通过则激活 bug

已关闭的 bug 再次出现 , 可重新激活

测试 -> 用例 -> "+ 建用例 "

1. 用例的评审功能，禅道里默认是关闭的 , 可以由管理员到后台 -> 自定义 -> 用例 -- 评审流程里

开启

2. 开启后 , 新建的用例状态为 [ 待评审 ]

3. 用例评审是一个线下活动，线下开会评审用例后，由有权限的人员显示修改用例状态

测试 -> Bug -> "+ 提 Bug" 3. 导出 / 报表

10 SVN

10.1 总体介绍

概念

SVN 是 Subversion 的简称，是一个开源版本控制系统，用于多个人共同开发同一个项目时，实现资源共

享 , 实现集中式管理

管理对象

需求、设计等文档

代码（源程序）

集中式管理的工作流

集中式代码管理的核心是服务器，所有开发者在开始新一天的工作前 :

1. 必须从服务器获取代码

2. 然后开发

3. 最后解决冲突，提交

所有的版本信息都放在服务器上。如果脱离了服务器，开发者基本上可以说是无法工作的

补充概念

服务器集中存放文档 / 代码的地方叫做仓库 / 版本库

10.2 服务端

10.2.1 服务端安装

测试 -> Bug -> 可以看到 "+ 提 Bug" 旁有 导出 / 报表 功能 下载

官方地址 : https://www.visualsvn.com/server/download/

安装

1. 双击安装包 , 一路默认即可

2. 有需要的可以更改部分路径 , 如 : 安装 / 仓库 / 备份路径

10.2.2 添加用户

右键 Users -> Create User...

修改用户密码

右键具体某用户 -> Set Password...

10.2.3 添加用户组

右键 Group -> Create Group... 10.2.4 创建仓库及获取地址

创建仓库

右键 Repositories -> Create New Repository...

获取仓库地址

右键 具体某仓库 -> Copy URL to Clipboard

10.2.5 服务启动 / 停止 / 重启 10.3 客户端

10.3.1 客户端安装

下载

TortoiseSVN, 官方地址 : https://tortoisesvn.net/downloads.html

安装

1. 双击安装程序

2. 一路默认 , 下图稍加注意 , 选择是否安装命令行工具

汉化

TortoiseSVN, 官网下滑会找到 Language packs ( 语言包 ), 选择下载并安装即可 10.3.2 客户端基本操作

检出（ checkout ）

将服务器上的最新的文档或程序代码拉取到本地客户端

更新（ update ）

从服务器更新文件操作

添加（ add ）

客户端新增文件，需要先 svn add 添加到本地仓库；然后运行 commit 真正提交到服务器

删除（ delete ）

先选中文件，然后右键选择 delete ，然后 commit ，填写相关日志信息

提交（ commit ）

客户端文件内容已修改，需要将更新后的文件推送到服务器

更新至版本（ Update to revision ）

更新版本可以使本地副本更新到任意一个历史版本，方便用户详细查看某一版本的具体内容。

注意：只是在客户端临时恢复到以前的某个版本，服务器端文件内容不会发生改变

点个赞加个关注吧~

分享更多项目实际问题，帮您解决更多问题！！！