[开发测试]BUAA 软件工程 第一次作业

BUAA 软件工程2022 第一次作业

阅读提问

Q1：单元测试真的能产生可重复、一致的结果吗

单元测试应该产生可重复、一致的结果

如果单元测试的结果是错的，那一定是程序出了问题，而且这个错误一定是可以重复的。

在第2章中，有如上的结论，但是以我在OO第2单元时的测试来说，我不认为测试结果可重复，在多线程中，往往出现各种多线程的小问题，而这些小问题都是在程序运行了非常长的时间后，在某一种非常苛刻的情况下触发的bug，而重复运行这一段代码，极有可能不会再次触发这个bug，结果也自然不一致了，我想在现在的各种软件项目中，多线程的项目应该占了绝大多数，这在测试中难免出现一些概率极低的bug且无法复现。

Q2：单元测试应该谁来写？

单元测试必须由最熟悉代码的人（程序的作者）来写。

第2章中有如上的说明，但是我认为最适合写单元测试的人应该是最熟悉该模块需求的人，或者说由提出该需求的人来测试，这是因为程序的作者可能只是按需求完成了代码，那么在测试时，也会按自己的代码的理解来完成测试，而如果他在写代码时已经误解了该需求，那么无论如何去测试，都是测不出问题的，因为在他眼中这就是正确的，而在真正的需求上，可能该功能是有问题的，因此我认为应该由最熟悉需求的人来写测试。

Q3：在完成时间上使用六西格玛方法是否正确？

但是从标准方差来看，Al的方差是5.3，而Bob是1。

第3章中有一个比较交付时间的分析，在实际完成时间与估计时间上进行六西格玛来评价，我个人认为不是很妥。我们看看六西格玛的定义：(百度百科)

六西格玛（Six Sigma，6 Sigma）是一种管理策略，它是由当时在摩托罗拉任职的工程师比尔·史密斯（Bill Smith）于1986年提出的。这种策略主要强调制定极高的目标、收集数据以及分析结果，通过这些来减少产品和服务的缺陷。六西格玛背后的原理就是如果你检测到你的项目中有多少缺陷，你就可以找出如何系统地减少缺陷，使你的项目尽量完美的方法。

我们可以看到，这个方法实际上是对项目的缺陷作评价的，6个西格玛=3.4失误/百万机会，也就是说对项目的失误率来作评价，而一个程序员过早完成任务，也能算失误吗，我个人认为用平均时间和超出时间来作评价更恰当。

Q4：真的建议使用goto吗？

问：我们能不能用goto？

答：函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。

第4章中，代码设计规范中，有如上描述。但是在我个人开发来讲，我从未使用过goto，正如评论所说：

goto语句使程序的静态结构和动态结构不一致，从而使程序难以理解，难以查错。

goto语句的结果：在C/C++等高级编程语言中保留了goto语句，但被建议不用或少用。在一些更新的高级编程语言，如Java不提供goto语句，它虽然指定goto作为关键字，但不支持它的使用，使程序简洁易读；尽管如此后来的c#还是支持goto语句的，goto语句一个好处就是可以保证程序存在唯一的出口，避免了过于庞大的if嵌套。

goto往往会使得程序结构变得奇怪，结对的另一方应该也很少使用goto，这就加大了理解难度。我认为goto可以使用其他东西来代替，不是很习惯在代码中看到goto。

Q5：PM是否真的能做到与大家平等？

Program Manager 和一些公司的 Project Manager 的区别:

Project Manager	Program Manager
是团队的行政领导, 带领大家在项目中工作。	和大家平等工作, 推动团队完成软件的功能。
通常是团队和外界打交道的唯一代表	一个团队可以有很多PM
对项目的功能有最后的决定权	和其他团队成员一起形成决议
管事也管人	管事不管人
不一定做具体工作	一定做具体工作

阅读第9章项目经理篇时，有如上的表格，其中描述Program Manager为与大家平等工作、与其他成员一起形成决议、管事不管人。但是在我大学里实际的项目中，我认为这是很难做到的。在我第一次当项目组长时，我最初的想法也是大家应该是平等的，共同对项目提出建议，然后投票决定项目的走向等等，我应该起到一个类似于主持人的作用，项目会议应该是所有人一起参与进来，各抒己见，然而，实际上，大部分项目到了最后都是我开一个会，全程也是我在说明，这个地方应该如何去完成，这个地方应该需要注意什么细节，这个地方有前人的博客可以借鉴，其他人可能基本不发言。就算这样，已经把相关博客找好了，实现的功能输入输出描述好了，干起活来，还是得催，比如我曾经有一个项目，在寒假便安排好了任务，要求两周内完成后给我看一下效果，但是这个任务硬是拖到了暑假，最后我花了一个晚上把之前发给他的博客复现了一遍，实际上按那篇来做根本不会出现很奇怪的问题。我认为不管人的话，至少在大学是很难完成一个类似于PM的任务的。当然在工作上可能不一样，但是我还是对PM可以于大家平等表示怀疑，PM理应对每一个项目中的人进行管理，对没有跟上进度的也理应去push，如何才能实现真正的平等呢？

调研源代码版本管理软件

参考wiki、知乎，此处主要选取了以下代码版本管理软件作分析：Github、GitLab、Gitee、Bitbucket、Plastic SCM。其中除了Bitbucket外本人均使用过，Github、GitLab、Gitee主要是在写课程代码时使用，不过目前Github在国内连接不稳定，体验不如之前了；另外Plastic SCM是在做unity开发时使用的，这是由于游戏中往往有大量的模型文件，这在其他不支持超大单个文件的代码版本管理软件中很难进行版本控制。

相同点

实际上目前大部分版本管理软件都实现了这些非常基础的功能：

• 拉取请求
• 代码审查
• 内联编辑
• 问题跟踪
• Markdown支持
• 双向认证
• 高级权限管理
• 托管的静态网页
• 功能丰富的API
• Fork / Clone Repositories
• 代码段
• 第三方集成

不同点

• 使用人数

从下表中可以看出，单从使用人数来说，Github和Gitlab都远远超过其他软件，其中Github最多。（该表格摘自wiki）

• 开源与收费（部分借鉴博客）

• 缺点与优点

调研持续集成/部署工具

采用本人之前数据库的后台管理系统，该系统由vue编写，可实现线上编译并将编译结果保存至仓库，同时可设置在线访问该系统（由于后端未部署目前只能看到首页，无法登录）。下面作详细示范。

Github Action

这里我采用了推荐博客的教程，只是该教程是部署一个react应用，实际上大部分的操作是相似的。

首先，我们需要编写一个action的workflow文件，如下：

name: Build and Deploy
on: [push]
jobs:
  build-and-deploy:
    concurrency: ci-${{ github.ref }} 
    runs-on: ubuntu-latest
    steps:
      - name: Checkout 🛎?
        uses: actions/checkout@v2

      - name: Install and Build 🔧 
        run: |
          npm install
          npm run preview
      - name: Deploy 🚀
        uses: JamesIves/github-pages-deploy-action@v4.2.5
        with:
          branch: gh-pages # The branch the action should deploy to.
          folder: dist # The folder the action should deploy.

这里我借用了开源库，其可以将生成的文件push到一个新的分支，这样我们就可以通过GitHub pages来进行在线查看我们的网站了。该代码主要是先将我们的代码拉下来在虚拟机中build（即npm install && npm run preview），之后再将生成的html、css等等静态网页资源push到指定分支上。

当我们对库进行了push操作时，将会自动重新build，并覆盖在gh-pages分支中，如下所示：

在这一步中值得注意的是，我们需要更改一下vue的配置文件：将publicPath: ‘/’,修改为publicPath: ‘/admin_frontend/’,否则网页无法正常显示（因为找不到css等文件）

之后配置一下pages，将source改为之前设定好的分支（gh-pages）。

于是访问该网站即可看到build好的项目：

Gitlab CI

同理，使用相同的项目，把库转移到gitlab上，在线编译+在线展示，CI脚本如下。这里我借鉴了博客、vue官方文档。

image: node:latest   # 表示使用有 nodejs 环境的 docker，python等也有其他的 docker。

stages:     # 定义阶段顺序
  - build   # 先 build
  - deploy  # 再部署

build:                   # 定义一个 job 叫 build
  stage: build           # 它属于 build 阶段
  tags:
    - "runner1"
  script:                # 该 Job 要执行的命令行
    - npm install        # npm 安装项目依赖
    - npm run preview      # build 项目

pages:                   # 定义一个 job 叫 pages，最后一个阶段一定要叫 pages，这样 gitlab-pages 才会开始工作
  stage: deploy          # 他属于 deploy 阶段
  tags:
    - "runner1"
  script:                # 该 Job 要执行的命令行
    - mv public public-vue # GitLab Pages 的钩子设置在 public 文件夹
    - mv dist public 	 # 重命名 dist 文件夹 (npm run build 之后的输出位置)
  artifacts:             # 定义工件，在 jobs 执行完了后，gitlab-pages 会把工件目录下的文件自动部署到 pages 服务器中
    paths:               # 将项目中的文件夹定义为工件目录
      - public           # 要想部署到 pages 服务器中，这个文件夹必须叫 public ,所以前面一定要把打包结果复制到 public 文件夹
    expire_in: 30 days   # 工件有效期为 30 天，工件到期不会影响 pages

cache:                   # 定义缓存文件，从一个 job 到另一个 job ，除仓库外的文件都会被删除，然后把缓存文件复制到下一个 job
  paths:                 # 定义缓存文件的路径
    - node_modules       # 这里要缓存 node_modules，在下一次触发 gitlab-ci 时，缓存会被还原，就不用重复安装依赖。
    - dist               # 同时把 build 阶段生成的 dist 文件夹也缓存起来，在 deploy 阶段会用到。

不过仅仅如此是不能运行的，因为我们没有runner，原本是有共享的免费runner，但是这需要一张银行卡认证，所以只能自己部署一个本地的runner了。部署过程也比较简单：（这里对一些本人的token就作打码处理了）按这个token注册后可以在列表中看到我们的runner，使用他就可以了。

之后一旦对库进行了更新，就会自动build并发布至gitlab pages上。

待build完成后自动将页面部署至gitlab pages。得到下面页面：

使用总结

在此调研中我使用了自己数据库课设的库（两个库均在上面已给出），同时也阅读了前几届大佬们的笔记，测试了一下两种工具在库上的使用，实现了自动build的功能，并在线访问build后的结果，简化了开发过程中反复手动build的过程，实现了持续集成部署功能。下面简要说说两者的优缺点：

• Github Action
  • 从使用体验上来说，我认为Github Action更方便，特别是对于手里没有服务器的开发人员来说，因为其只需要我们写一个脚本，他便会提供服务器运行脚本，与Gitlab CI不同，Gitlab CI需要自己部署一个runner，这花费了我大量时间，相比之下，如果我没有提前部署好一个runner的话，我肯定是会选择Github Action来作为自己的持续集成部署工具的。
  • 从运行速度上来说，Github Action也运行的更为迅速。
  • 另外Github上提供了很多action的集成插件，可以直接使用他人写好的插件来完成自己的功能，无需自己重复编写。
• Gitlab CI
  • 对流水线的管理要更加简单易懂，各阶段的定义和阶段之间的依赖关系显式列在配置文件中，因此可以有多种自定义选择方式，而Github Actions则显得较为复杂
  • 没有国外银行卡的话无法使用共享的runner，因此只能在自己部署自己的runner，虽然麻烦了点，不过这在某种意义上也实现了我们可以使用更强大和符合我们要求的服务器来当作runner，同时也有了一定的保密性。

下面给出更详细的对比（来源）

综上所述，就目前我个人的使用体验来看，我更倾向于使用github action。主要是其无需部署服务器即可一键使用，而且也有大量的action开源库可调用（调包侠罢了）。