问题、目标与实现

这是2022年初写的。

一、要点

二、难点

编辑三、痛点

四、近点

五、远点

编辑六、细点

6.1 裸机构建

6.1.1 资源、人员、工时

6.1.2 说明

6.2 文档整理

6.2.1 资源、人员、工时

6.2.3 说明

6.3 项目助理

6.4 独立测试环境、演示环境和压力测试

6.5 SCM工程师

6.6 评审

6.7 邮件和即时通讯

6.8 QC质量控制

编辑6.9 深度修改

一、要点

二、难点

三、痛点

四、近点

五、远点

六、细点

6.1 裸机构建

6.1.1 资源、人员、工时

        资源：编译不需要专门资源，个人电脑上装虚拟机即可。测试验证可临时借用现有设备。
        两个人员：当前发版员，整理出操作方法写成文档；测试员，根据文档重现过程。
        工时：没有解决不了的问题的话应该能在一周时间内完成，可能的麻烦是不知道现在的编译主机是怎么回事、用的软件从哪里来的，这样就尴尬了。

注意：必须包含系统基本功能的测试，以便证明确实可用。

6.1.2 说明

安装部署的规范化：
1，所有涉及到的安装包存放在指定位置（不允许使用其它来源，特别是不可以从互联网下载，必须指定版本）
2，安装包要从裸机开始，明确指出系统需求（OS、CPU、最小内存、最小硬盘等）
3，按照顺序的逐个编译目标，源代码所在位置、编译位置、编译命令、编译输出
4，安装包制作，每个文件的来源位置（svn的位置、系统位置、哪个编译位置的输出）
5，安装流程，停止、清理、替换、初始化、恢复运行
6，以上全部单一文档化，以实现根据单一文件完成从裸机开始的全套安装部署流程
7，由不相干人员操作验证正确性

关于依赖的安装包：
公司有正规存放位置就放正规存放位置，指出版本即可，否则就放在svn里面，虽然大但是不更新，也就占那么大空间
操作系统和第三方系统改变版本可能带来兼容问题，所以要保存完整安装源，确保能在任何时候重建

关于编译输出：
不能取别人编译好的东西，必须亲自编译，哪些文件是编译输出的、哪些是从系统复制过来的必须分清楚
严格地说，直接复制操作系统的dll或so放在当前目录用是不规范的，可能引起问题，当然部分软件这么用可以

关于不相干人员：
只有别人来验证才能证明文档的有效性，这是基本原则，任何取巧行为都会失败

6.2 文档整理

6.2.1 资源、人员、工时

资源：不需要额外资源，就是日常工作
人员：每份文档都有一个主写人员，全员参与
工时：当成个事的话一个月总该完成了，毕竟，这里面没什么迈不过去的坎。

6.2.3 说明

        从现有的文档入手，把每个人手里的传来传去的文档集中到版本库里面，然后从外事人员开始，审查文档，要求外事人员只从版本库获取文档。
        再要求测试组将文档视同程序一样的测试对象，严格审查文档的正确性。
        最终所有人应该对全部文档无异议。

重点：区分外部文档和内部文档，外部文档可以吹，内部文档必须写清楚哪些是吹的。目的是让商务人员能够直接和用户谈细节，不需要跑回来问，更不要发生商务人员理解错误。
最怕就是文档丢进去没人看，自然没人管对不对。

6.3 项目助理

汇总需求和故障信息，组织评审，发送报告。由于现实中多用即时通讯软件，要求项目助理必须在所有的业务群里，以免遗漏发生的故障和问题。
这个一般都是女的，比较容易工作。

故障分析会议

6.4 独立测试环境、演示环境和压力测试

        独立测试环境需要较少资源，想办法完成特定功能测试即可。
        演示环境需要专门设备，但性能不需要达到生产系统水平，可能需要专门网络以供互联网接入。演示环境需要独立，以保证随时可用。
        压力测试环境需要一个与生产系统尽量相同的环境，包含至少两个接入层和一个汇聚层。

最好不要发生等环境这种情况，特别是处理BUG的时候。