为什么每次写完代码提交到生产环境我都要检查四五遍才敢发起 merge reque美国服务器st

测试写到位的话，应该能显著缓解这种焦虑吧？

同，每个文件都要 diff 下才敢提交

哈哈哈，我经常盲改代码直接上线。换成楼主，怕是要原地升天。

写测试，能给自己减压。

测都不测直接提交

单测测试 起码得做吧？

流程做好, 包括方案 review/代码 review/评估测试用例 /联调 /测试 /灰度上线, 严格按照流程办事, 那出了问题锅也不在你这.

这不是测试->运维的工作吗

跟我一样 哈哈哈


小公司 没有那么规范的流程 是公司自己的内部平台

有时候检查没问题发现数据库没同步，炸了。

写 ut 是职业素养，跟公司规模没关系。写好 ut （覆盖率有个七八成）至少能规避六七成的 bug，再出 bug 的话也不是你一个人责任，测试锅更大。

增加测试部门。

没办法百分百正确，灰度吧发布吧。只有不会造成脏数据这种 bug，其他程序错了及时回滚

测试覆盖的全, 倒是不会焦虑上生产
就是每次 commit, 都要一行行选半天

典型的缺少测试引入的问题
如果自己写了单元测试，划好改动范围并且测试用例覆盖了业务需求，就不会有这样的焦虑。

没有专职测试 自己会写一些简单的单元测试

既然如此, 那出了问题关系也不大吧.

极度真实！我也是

都是这样

大倒是不是大 有公司的业务流程在里面 怕崩了没办法正常开展业务


hhhh 同是天涯焦虑人啊

有测试覆盖率就不会焦虑了


写了但是不能保证全部覆盖
我不是老板啊 我也想增加啊 哈哈哈

写测试可解
测试跑通，代码都懒得看了直接提交（

如果重要, 那可以要求加流程防止有问题. 把风险和老板说清楚, 如果老板坚持认为这个风险可控, 那出了问题责任也不全在你. 你已经把可能的风险讲明白了.

那这个问题就无解了。

小公司，改了代码直接上生产，生产没问题再提交
一点不慌

可 roll-update 怕啥（瑟瑟发抖）

因为你有责任心

跟我一样，甚至 commit 时看一眼，push 前再看一眼


测试用例是根据业务写的，而不是根据功能边界写的。
生产环境的需要的业务都有测试用例覆盖，还有啥焦虑的，如果上线发现问题，说明存在测试用例没有覆盖的业务，补上就是了。
所以测试用例的写法更像用户手册，告诉别人这块的实现是解决什么业务的，会被怎么使用。

谁来测试测试代码本身？是不是要给测试代码写格测试？

先做自测试，没问题了再提交就没有焦虑了。盲改盲提肯定出问题，墨菲定律

厉害, 代码直接上生产环境, 不经过测试环节吗?

我膨胀的时候写 C++连编译都不编译直接提交...

为什么代码直接上生产环境？

本地看完，直接 merge

胆大点直接推上去，打个 tag，丢生产跑起，有问题，回滚看看，再来一波前面的操作，以此类推至没坑

干就完了，出问题秒回滚

作为 一个 开发 + 测试 + 运维 来说
就是 一行一行看这个
本地先测试
没问题看功能影响大小
大的话 半夜维护
出了问题 秒回滚

是的 只能这样