一、企业软件开发常识

1. 公司的技术部门组织架构

产品部 产品经理：
负责产品形态
与用户（甲方）沟通，或市场调研，整理提炼需求，形成文档给开发、测试人员。

UI = User Interface 用户界面设计

负责的界面的可视化效果

前端（前端开发）
负责网页的开发，可视化效果的实现

研发（后端开发）
负责后端代码开发，处理业务逻辑、与数据库的交互

测试
找出软件的缺陷，并反馈、跟踪这些缺陷，直至缺陷解决。

运维
软硬件的部署、维护，解决或反馈用户现场软件运行中出现的问题。

2. 软件质量概念

质量就是一组固有特性满足要求的程度。 要求有明示的，也有隐含的。

3. 软件质量的特性

广义性：不仅仅只是产品的质量，还包含过程的质量，质量管理体系的质量

时效性：用户对产品的要求是不断提高的，所以产品质量是有时效性的，而且随着时
 间的变化，有一些新的产品出现，旧的产品可能不能继续得到之前用户的认同。

相对性：不同用户，对同一款产品的需求也可能是不同的，对于同一个功能的要求也
是 不一样的。

质量的优劣是满足要求程度的一种体现。它必须在同一等级基础上作比较。

4. 常见的软件质量管理体系

ISO9000, CMM/CMMI, 6 西格玛

每种质量管理体系，都规定了一些标准过程和工作产品；如果公司参与评级，公司需要组
织员工呈现、提交规范的工作产品。

CMMI 一共有 21 个过程域

CMMI 有阶段型与连续型两种表示方法。
CMMI 阶段型表示法有以下几个级别，由低到高：
1. 初始级
2. 已管理级
3. 已定义级
4. 定量管理级
5. 优化级
可参考下图：

5. 软件质量模型

从哪些角度去衡量一个软件或其他产品的质量。如图所示
功能性：当软件在指定条件下使用时，软件产品提供满足明确和隐含需求的功能的能力。

适合性：软件产品为指定的任务和用户目标提供一组合适的功能的能力。

准确性：软件产品提供具有所需精确度的正确或相符的结果或效果的能力。

互操作性：软件产品与一个或更多的规定系统进行交互的能力。

保密安全性：软件产品保护信息和数据的能力，以使未授权的人员或系统不能阅读
或修改这些信息和数据，而不拒绝授权人员或系统对它们的访问。
功能性的依从性：软件产品遵循与功能性相关的标准、约定或法规以及类似规定。
if(1==a){
}

可靠性：在指定条件下使用时，软件产品维持规定的性能级别的能力
成熟性：软件产品为避免由软件中错误而导致失效的能力
容错性： 在软件出现故障或者违反指定接口的情况下，软件产品维持规定的性能级
别的能力。
易恢复性：在失效发生的情况下，软件产品重建规定的性能级别并恢复受直接影响 的数据的
能力。
可靠性的依从性：软件产品遵循与可靠性相关的标准、约定或法规的能力。

易用性：在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力
易理解性：软件产品使用户能理解软件是否合适以及如何能将软件用于特定的任务 和使用环
境的能力。（最好能自解释）
易学性：软件产品使用户能学习其应用的能力。
易操作性：软件产品使用户能操作和控制它的能力。
吸引性：软件产品吸引用户的能力。
易用性的依从性：： 软件产品遵循与易用性相关的标准、约定、风格指南或法规的能力。
这些标准要考虑国际标准、国家标准、行业标准、企业内部规范等，例如企业内部的界面规
范。
效率：在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力
时间特性：在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐率的
能力。即完成用户的某个功能需要的响应时间
资源利用性：： 在规定条件下，软件产品执行其功能时，使用合适的资源数量和类别
的能力。最主要的资源：CPU 和内存。
服务器 CPU：假设访问用户量可以无限大，CPU 能达到的使用率越（A）越好
A： 高 B: 低
效率依从性：软件产品遵循与效率相关的标准或约定的能力。

维护性：软件产品可被修改的能力。修改可能包括修正、改进或软件对环境、需求和功能规
格说明变化的适应。
易分析性：软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力
易改变性：软件产品使指定的修改可以被实现的能力
稳定性：软件产品避免由于软件修改而造成意外结果的能力
易测试性：软件产品使已修改软件能被确认的能力
维护性的依从性：软件产品遵循与维护性相关的标准或约定的能力。

可移植性：软件产品从一种环境迁移到另外一种环境的能力
适应性：软件产品无需采用有别于为考虑该软件的目的而准备的活动或手段就可能适应不同
的指定环境的能力 - 兼容性，兼容性测试
易安装性：软件产品在指定环境中被安装的能力 - 安装、卸载测试。
共存性：软件产品在公共环境中同与其分享公共资源的其它独立软件共存的能力
易替换性：软件产品在同样环境下，替代另一个相同用途的指定软件产品的能力
可移植性的依从性：软件产品遵循与可移植性相关的标准或约定的能力。

6. 软件度量

11.1 概念 ：

度量：对事物属性的量化表示

软件度量：是指计算机软件中范围广泛的测度,包括对软件系统、构件或生命周期过程
具有的某个给定属性的度的一个定量测量

11.2 目的
提高软件生产率，缩短产品研发周期，降低研发成本、维护成本。
提高软件产品质量，提高用户满意度。

为组织持续改进提供量化的指标和反馈。
11.3 软 件 度 量 的 作 用

理解：就是通过度量，获得对过程、产品、资源等的理解，确定以后预测的基线和

模 型。对于不同的软件组织和软件类型，过程模型都不一样。这是评估、预测、改进

活动的 基础

预测：根据所理解确定的模型，由已知的要素推算、估计其它要素，以便合理分配

资 源、合理制定计划

评估：分析活动与计划的符合度，确定是否有偏差，以便控制其执行

改进：根据得到的量化信息，可以帮助我们识别要因、查找问题的根源，以及能提

高 产品质量和过程效率的其它方法；与以前的量化信息比较，可以验证这些方法是否

有效。

11.4 软 件 度 量 的 分 类 ：

四个基本度量项

规模(size)：软件工作产品的大小 。 代码行数： 10w 行 1w 行

工作量(effort)：完成各软件工作产品和活动所用人时（或人天

等）

10 人天 2人 5天 5人 2天

进度（schedule): 各软件工作产品和活动开始和结束的时间

质量（quality)-缺陷（defect）：在各软件工作产品和活动中产生

的缺陷数
7. 软件开发生命周期

（1）瀑布模型

瀑布模型介绍

瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测
试 和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑
布流水，逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺
序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此
如果有 信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，
瀑布模型的优缺点

瀑布模型的优点：为项目提供了按阶段的检查点，当前一阶段完成后，只需要去关

注后 续阶段。

缺点是，测试在产品开发完成之后再去介入，上游阶段没有完成时，下游人力会出

现空 闲，并且，测试在最后进行，一些问题可能在前期已经形成并被覆盖，直到准备发

布或者上 线后才可能发现。

（2）V 模型

V 模型介绍

V 模型是瀑布模型的变种，主要反映测试活动和分析设计开发的关系。

V 模型体现的主要思想，开发任务和测试任务是对应的，软件开发过程中每一阶段

性成果都需要得到验证。
名词解释：

需求分析

由产品经理完成。
工作内容：对开发的软件进行详细的定义，由需求分析人员（产品经理）和用户共同

讨论决定，哪些需求 是可以满足的，并且给予确切的描述，写出需求规格说明书

SRS(Software Requirement Specification)或用工具做出需求原型。

工作成果：需求规格说明书（SRS）或需求原型
SRS 的内容：主要描述功能（输入，处理，输出），性能，外部接口，外在约束等

概要设计（概设）

由开发完成。
工作成果：概要设计说明书 HLD（：High Level Design）
HLD 的内容：主要将软件开发分解为子系统或模块，每个模块中的内容（函

数）

详细设计

由开发完成。
工作成果：详细设计说明书 LLD (Low Level Design)
LLD 的内容：模块内函数的调用关系。

编码

研发人员编写代码。

工作成果： 代码-> 软件产品

单元测试
 对软件中最小的可测单元进行验证，这个单元可以是一个函数等。

实际在企业中，经常由开发人员完成自测。

集成测试

重点检测各个模块的功能，基本可测单元组合后的功能是否正确。接口测试相当于集

成测试。

系统测试

系统测试是对整个软件系统进行测试，以验证系统的功能和性能满足需求规格说明书所

指定的要求。

验收测试

正式版本发布前，有用户参与的测试。

详细地说，就是旨在向软件购买者展示该软件系统满足用户的需求，它的测试数据常
常是系统测试数据的子集，所不同的是，验收测试常常有软件系统的购买者在现场，甚至
是在软件安装使用的现场，它是软件使用之前最后的测试。

验收测试分为 α 测试和 β 测试。

α 测试一般在开发结束的时候进行测试，针对测试结果还可能做一些修改，α 测试

由用 户，开发人员或测试人员共同参与，α 测试的目的是看用户体验如何，是否能让用

户满意。

α 测试是公司专门指定的或者有选择的用户群体，在公司指定的环境下测试，如果
发现

bug，一般反馈给开发，开发就会修复 bug，可能会给用户支付一定的费用。
 β 测试一般是开发和测试根本完成时所做的测试，也就是一般说的公测，这种介质

包一 般标记为 Beta 包，目的是在正式发布之前找到最终的错误和问题，这类测试一般

由最终用户或 者其他人员完成，在真实用户环境下完成。不能由开发人员或者测试人

员完成。发现问题时一般通过互联网在线反馈问题。一般不支付费用。

α 测试先进行，β 测试后进行。

通过验收测试后发布的版本成为正式版本（release）。

问题： alpha 测试和 beta 测试的区别是什么？

（1）介入时间不同；alpha 测试 beta 测试
（2）参与人员不同：
（3）目的：alpha beta
（4）测试环境：
（5）是否需要费用：

（3）双 V 模型（W 模型）

V&V 模型，代表开发阶段与测试设计阶段同步进行，体现了测试真正意义——存在于
软件生命周期的各个阶段。， 测试执行的顺序与开发的活动相反。
二、Git 使用

1. Git 安装

搜索
Git for windows
Git
找到安装包

如果 C 盘空间不足，可以改下安装路径：

此后一路 Next，安装完成。
2. Git 工作原理

三个工作目录 + 远程仓库

3. Git 工作流程和操作命令

(1) 初始化 Git 目录

git init
初始化后目录下生成.git 目录。若不显示，做如下系统设置：
(2) 查看目录下文件状态

git status -s

各种状态：
?? 该文件未纳入管理 - 需要执行 git add
A 文件已经添加到暂存区 added
AM 文件本身已经在暂存区存在，但修改后未暂存 - 需要再次 git add
M 提交到本地仓库后又做了修改，但未暂存
M 提交到本地仓库后又做了修改，且已暂存

问: git 下的文件有哪几种状态?
未暂存(新建或修改)
已暂存
已提交

(3) 把文件添加到暂存区

git add readme.txt 指明具体文件，或

git add . 把当前目录下所有未管理的文件纳入 git 管理。

(4) 把文件提交到本地仓库

git commit -m “提交说明”

提交说明一般写：新增文件，或修改的文件内容和方式
默认提交暂存区中所有未提交的文件。

首次提交前会提示“Please tell me who you are.”

需要做用户名和邮箱配置，用来区分不同的提交者。
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
设置完成后再重新提交。
(5) 查看本地仓库的版本日志

git log

(6) 文件恢复

① 丢弃本地工作目录中的修改

——恢复到与暂存区或本地仓库一样

git checkout .
git checkout 目录名 或 文件名

例如，
git checkout xxx.txt 意思就是，把 xxx.txt 文件在本地工作目录的修改全部撤销。
如果 xxx.txt 提交本地仓库后做了修改，但修改未暂存，则执行 git checkout 后会恢复到
和本地仓库中的内容一样；（注意：提交到本地仓库后就不在暂存区中了）
如果 xxx.txt 添加到暂存区后做了修改，则执行 git checkout 后恢复到与暂存区中的内容
一样。

例 1：d.txt
例 2：a.txt

注意：如果不确定是否要保留本地目录中的文件，最好再恢复前先备份本地目录文件。

② 恢复到与本地仓库最新版本一致

git reset --hard HEAD

e.txt

注意：如果不确定是否要保留本地目录中的文件，最好再恢复前先备份本地目录文件。
③ 恢复到本地仓库中的上一个版本

git reset --hard HEAD^

注意！需确保不覆盖本地文件，强烈建议执行恢复前先备份文件。

同样的，上上个版本：
git reset --hard HEAD^^

也可以加版本号，回溯到任意一个历史版本。版本号可以在 git log 结果中查到。

回退后，本地仓库的 HEAD 版本是某个历史版本。如果回退后还想前进到某个版本，可以用 git

reflog 命令查看所有曾经存在的版本，再使用“git reset --hard 简写的版本号”前进到相应版本。

注：查看日志时，输入 q 即可退出。
(7) 注意事项

 千万不要手动修改“.git”目录里面的文件，不然改乱了，就把 Git 仓库破坏了。

 不用每次修改都 commit，可以多次 add，一次 commit

 每次修改，如果不 add 到暂存区，那就不会加入到 commit 中。

4. Git 远程仓库操作

作用：备份、统一、共享

采用 git 文件管理方式管理，作为中心服务器部署在网络上的产品。

git 文件存储和工作方式

Github - 免费服务-代码公开；代码私密托管-付费。
公司内部，一般搭建私有服务器：

Gitlab 就是一款很好的，通用的 git 私有服务器。其操作与 Github 几乎完全一致。

Gitee

公司内部一般使用 Gitlab 搭建私有服务器。进入公司后请配置管理员，或其他管理

Git 的人，给你分配一个账号和密码。

git clone 把一个远程仓库完全复制到本地，生成一个本地仓库

这是我们用得最多的创建本地库的方式——从远程仓库复制而来。
复制后得到的仓库目录，就是你的本地仓库目录。它与远程仓库遥相呼应。所以，
要特别小心地操作，不要改动其中的目录名、目录层级，也不要改动与你无关的文件。
如果需要改动，最好复制一个自己的文件，再修改。
如果修改了、新增了文件，要提交，需要依次执行
git add 文件名或目录名
git commit -m “新增或修改说明”
git push
git push 支持两个选项参数：远程仓库名 分支名
git push origin master
不加这两个参数，指的也是提交到远程仓库 origin 的 master 分支。
origin - 原始仓库。如果该本地仓库是从某远程仓库 clone 而来，那 origin 就
代表这个远程仓库。
分支 - 开发中会用到的概念，我们不用写这个参数，只用主分支 master。
 git pull
将远程仓库的最新内容同步到本地仓库。push 自己的文件到远程仓库前，往往需要执
行这个操作，否则容易因本地仓库和远程仓库不一致造成 push 失败。（因为别人可能
已经操作过远程仓库）。

执行 git pull 的时候，可能会出现一些信息，使用 vim 的退出方式退出即可。

merge

附录：远程仓库 GitHub 介绍（附账号申请）

官方地址：https://github.com/
注册账号：

设置用户名、邮箱和密码：
 创建 Github 远程库
用 Github 进行代码托管，需要先创建一个仓库。
账号验证完成，会自动弹出创建库的页面，或者登录后点击左上侧绿色的
“New”按钮

配置仓库相关信息(只输入仓库名字，其它的默认)
创建成功，查看指南
 点击库名，就可以进入库中

此时就可以对仓库进行操作
上传本地文件

新建文件

服务器配置（了解）：
详情可以自行搜索。
版本库地址：
http://192.168.0.103/svn/202201/

SVN 操作

1. SVN Checkout 检出 签出

- 从版本库地址下载现有内容，让本地目录变成一个本地版本库（受 SVN 管理的目录）

先新建目录，进入目录，右键选择 SVN Checkout
用户名：
user01 。。。 user10
密码与用户名相同。

2. SVN Update 更新

- 当本地内容不是最新时，从版本库下载最新内容
文件夹中，右键，选择 SVN Update
3. 提交文件或文件夹

（1）添加到本地版本库。文件上（或多选文件）右键，选择 TortoiseSVN-“Add”。
添加成功后文件上会出现一个加号，代表已经添加到本地版本库（已纳入 svn 管理）。
（2）文件上，或空白处右键，选择 SVN Commit，实现提交到服务器的版本库。

4. 修改文件或文件夹

（1）修改后保存。
（2）文件上，或空白处右键，选择 SVN Commit，实现提交到服务器的版本库。

5. 删除文件或文件夹

本地删除后，空白处选择 SVN Commit，提交删除动作。

6. 查看日志

右键“Tortoise SVN”-“show log”查看历史版本日志，可以看到版本号、修改类型、修改人、

修改时间、修改时填入的内容。

7. 恢复到历史版本

右键“Tortoise SVN”-“Update to Revision”，选择“Revision”，填入版本号（可以点击 Show

Log 查看），可以恢复到历史版本。

8. 冲突的成因及解决

多人修改同一个文件时，SVN 提供了保护机制。
如果 A 已经提交了文档修改（服务器版本已更新）；
B 不知情的情况下，在一个旧版本上修改后提交，会因“out of date”提交失败。实际是为
了保护 A 提交的修改不被覆盖。
B 需要在把自己的文件先移走，再通过 SVN update 将服务器上最新文件拉取到本地，再小
心地将自己的修改合并进去，再提交。

若本地文件不移走，直接 update，为了保护你的本地文件，会以冲突形式提醒（黄色的感
叹号图标），并产生临时文件。此时还是把文件移走（.mine 扩展名的文件），再执行 SVN
Update 更新，然后手动把自己修改的内容、增加的内容合并到这个文件中，再提交。

9. 切换用户

登录过的用户是默认保存的，如果要切换成其他用户，需要先清空已有的授权信息。
操作方法为：

任意位置点右键 - Tortoise SVN - Settings ：