作者DrTech (竹科管理处网军研发人员)
看板Soft_Job
标题Re: [心得] 我在科技业遇到的鬼故事之一
时间Fri Jul 28 09:03:08 2023
单纯经验交流一下
我遇到正常的软体UT与品质验证流程吧：
1.开发者写完程式码与UT。
2.在自己电脑上跑UT。
在自己电脑上跑UT，是部门不认的UT。
没人知道你自己电脑的环境与有没有动手脚。
3. Commit and push 到 repository 开发分支。
4. 启动 CI ，CI有个stage会去跑开发者的UT。
由於UT已经不在开发者的电脑或环境跑了。
所以有许多优点：
a. 环境是独立的，而且通常设计成接近 release後的环境。比较容易提早发现问题。
b. 开发者有没有做好UT，Pass UT，是有自动记录，而且自己没有权限修改的。避免了前
5. 所有CI流程都过了，UT过了，开发者以外的工程师或主管，才开始审核程式码 code review。(正常情况，至少两人)
这时审核的人，系统都会自动纪录。
比较大的公司也会有规定，或惯例该review哪些重点。
6. Code review 过了，系统才会自动 merge到 "开发"分支。(因为还没给QA测过，没办法release)
7. QA 测试前，先再次跑CI流程，包含UT，确认开发部门有按照基本品质要求走。(避免被Dev部门黑)。拉取程式与自己的测试程式，在接近生产环境的设备上测试。
8. QA测试出报告，有问题，提issue修改。没问题，上系统或出Mail说验证通过。(为品质背书)
9. 程式码品质Ok了，要将 dev merge到release分支。开发者根本没这权限。只有技术的owner或 Tech lead 有merge权限。有merge权限的人，要对这程式码品质负责。
以上的流程，已经简化蛮多细节了，而且变化很多，同家公司不同部门细节也不同，但大原则没变。
看似复杂冗长，其实大多机器自动化去做，大多写程式就能完成自动化，习惯了就好。两个星期跑release 一个线上版本很正常。
线上系统出问题，谁有责任：
开发者，owner，开发者主管，测试QA工程师，QA工程师主管，PM都可能会有责任。
大家不是靠嘴去争的，拿出Log与证据来讨论吧。
自己开发电脑上有没有Bug或 Log根本没人看。
Bug是否产生，所有Log，都在第三方电脑(或云端)，而且是接近Release环境的。
以上的流程与技术其实也不难，open source都搭建得起来，流程摸久也就习惯了。
简单成本就能大幅提高软体品质与工作效率。最大差异在於，你有没有待过这样的工作环境，学习到这种工作观念而已。
(可以思考一下，以上有哪些点，怎麽改善自己工作流程，不用硬套别人公司做法)
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 42.72.104.143 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1690506190.A.622.html
1F：推 blackrays: 推这篇 07/28 09:23
2F：推 CMJ0121: 依照他遇到的 case 正常 CI 跑应该是采不太到问题 07/28 09:24
3F：→ CMJ0121: 可能需要用 integration test 或者是 behavior test 架设 07/28 09:25
4F：→ CMJ0121: 特定环境 不过从他的文章看不出来有没有这种东西 :) 07/28 09:25
※ 编辑: DrTech (42.72.71.209 台湾), 07/28/2023 09:27:01
5F：→ DrTech: Integration通常有另外的repository，跑其他整合测试才对 07/28 09:31
6F：→ DrTech: ，或是在QA做真实上线环境下的整合测试，变化还蛮多的。但 07/28 09:31
7F：→ DrTech: 原则就是大家都要看得到别人的UT 怎麽做。真的别用嘴巴讨 07/28 09:31
8F：→ DrTech: 论到Dev有没有做UT，太不科学了。 07/28 09:31
9F：→ DrTech: 没有在自己电脑以外，公认的测试环境，跑的UT/IT，一律都 07/28 09:34
10F：→ DrTech: 不能算有做，基本原则。 07/28 09:34
11F：推 CMJ0121: 上面那个完全同意 没上 CI /QA 画押的测试怎麽会是测试 07/28 09:51
12F：推 rayway30419: 人能炸烂线上环境的不检讨制度也是很有趣 07/28 10:11
13F：推 wmtsung: 因为环境很难改变，大家都爱检讨人啊XD 07/28 10:20
14F：推 shibin: 推分享 07/28 10:22
15F：推 yamakazi: 我以为Push後在Jenkins上面会自动跑完git fetch抓分支， 07/28 10:25
16F：→ yamakazi: build code，跑Gtest，自动化测项，Review完後给QA人工 07/28 10:25
17F：→ yamakazi: 测完才merge是基本常识，看来很多公司没这麽做 07/28 10:25
18F：推 luciferii: 看原PO描述，他们公司的UT环境是随需求在随时改，而且 07/28 10:41
19F：→ luciferii: 没有侧录机制。(这也好像是常态，除非非常重视SDLC而 07/28 10:42
20F：→ luciferii: 且真的实作的公司)，所以出事只能靠嘴巴追责任而不是靠 07/28 10:43
21F：→ luciferii: log追踪开发流程。 07/28 10:43
22F：→ luciferii: 而上篇说，B有责任UT自己交出去的东西，他自承没作（无 07/28 10:44
23F：→ luciferii: 论是不是说谎），这样就一定有责任。差在真的没作是轻 07/28 10:44
24F：→ luciferii: 责，作了故意放过是重责。 07/28 10:45
25F：推 xam: 你的1&2是开发者自己测pass不能算有效,但自己测都失败是根本 07/28 10:59
26F：→ xam: 不该commit叫QA帮你试.. 除非有人想看preview 07/28 11:00
27F：→ wtl: 自己pass不算有效那自己fail也不算无效吧 commit後是自动QA 07/28 11:07
28F：→ wtl: 有过就过了 这问题主要是环境 自己电脑环境不一定对 所以才要 07/28 11:07
29F：→ wtl: CI/QA看结果 07/28 11:08
30F：→ luciferii: 自己fail还 commit是有事吗？ 07/28 11:26
31F：推 Vick753: 推推 07/28 11:47
32F：推 Burwei: 推推，整串读完正需要这个 07/28 12:00
33F：推 sniper2824: 笑烂 那跑Test干嘛 07/28 12:08
34F：推 f496328mm: 推这篇，这才是正常的软体开发流程 07/28 12:14
35F：推 puring0815: 笑烂，同推这篇，拜托用制度解决问题而不是一直在解 07/28 12:32
36F：→ puring0815: 决人好不好 07/28 12:32
37F：推 sirlers: 推分享 这样的流程好好导入原原po就无从把自己team的锅 07/28 13:18
38F：→ sirlers: 推给B罗 07/28 13:18
39F：推 Litfal: 原po公司重点在於没有根据客户环境做测试，尤其看起来像 07/28 13:33
40F：→ Litfal: 是做专案的厂商，没有这个环节QA还敢放行真的奇怪 07/28 13:33
41F：→ newhandfun: 比起建立制度，解决人比较轻松（X） 07/28 15:23
42F：推 safe: 感谢大大无私分享 07/28 16:39
43F：→ superpandal: 原PO是事後越想越不对劲 而且也保了B 所以不是解决提 07/28 20:05
44F：→ superpandal: 出问题的人 而是後知後觉发现被坑了上来找人评评理 07/28 20:06
45F：→ superpandal: 况且B是提出问题的人与B犯错不能互相抵销认为B没错 07/28 20:07
46F：推 viper9709: 推分享 07/28 20:23