SimonOne

调试这种拔尖硬件+BUGOS 的感受就是这么难。

以为自己时间线跳动了，一查确实看到过很多次类似的主题，哈哈哈
https://www.v2ex.com/t/941333
https://www.v2ex.com/t/899029

@tool2d #37 其实我这一行做功能设计的，大都没有软件工程的底子，做出来的东西都是健壮性低耦合度高可拓展性低的功能。
我是很抵触这样的（一方面觉得这样不道德，别人花了钱交付一坨垃圾；一方面是，有时候会运维到这样的项目，觉得实在是恶心），但是我不是领导没法去改变什么。

有些项目是我一个人做 PM 和实施的，我就要求领导别给我配开发了，我自己兼了，反而全包干下来功能代码都能跑得很好。因为我自己设计自己开发，只要别人 20%的人天就能做完不加班（当然会搭配摸鱼/看技术文档，看起来每天都在满负荷干活🙈），干起来也很轻松；交付给客户时，有些 It 出身的甲方也说说我代码思路很清晰，考虑了很多纯业务或者纯开发都不会想到的检查。
这么一来更不适应和不懂业务的开发做项目了（ sap 开发理论上都是跟模块的，按理应该至少是了解通用的模块业务的）。

@tool2d #37 确实，我现在急了也没用，PM 都不急，我自己急也徒耗心力。
我刚也问 PM 了，到底我要覆盖多少场景才算测试 ok ，还是说我只要持续测试直到上线能覆盖多少是多少。
他默认后一种，笑死了。😂

@tool2d #35 我是这么想的，如果出问题了再改，数据治理很麻烦（有些覆盖了也没法轻易恢复，basis 说的是 sap 恢复只能全机回滚，那存档后的数据又丢了）。
所以我测试一般都以理论上能出现的操作进行的，奈何这个项目的开发质量经不起我的这个测试法啊。我稍微了解下业务后，提出了一些特殊场景，都是没覆盖的😅。

@wildman9527 #32 问题在于，这个测试用例不是固定的（说点难听的，PM 到时候逼急了，不测直接上生产都有可能），我不就在平衡“测试用例的场景丰富度”上犯难了吗。
我写的多了要背影响上线进度的锅，写的少了要背影响功能稳定性的锅。测试过程中，业务还在变化，给的 deadline 却不变。

我真的要裂开了，除了跑路别无他法。

@qingshui33 #29 确实，我目前看下来，整个项目做成这样啊，主要原因就是实施时间不足，里程碑定的是 12 月初上线，而按照目前我了解的工作内容来说，定到 2 月 1 号都很赶了，所以整个项目风气就是业务细节了解不充分就开始干活。
sap 项目的话，有些业务细节对后续方案的影响是很大的，比如就拿离职再入职是否复用旧 id 来说，就严重影响所有的人员信息入职、异动、离职、和七八个外围系统增量全量同步的接口、所有的人事信息查询接口、所有的人头相关报表的取值逻辑。只要他们变一下说法，那么这些都得重写。

结果就在我测试中，我不断得向设计功能的顾问提出这个问题，他们不断得变化说法😂。

说到底，都怪 PM 和销售。