google 一下，这些吧。
https://apps.apple.com/cy/developer/g-net-cloud-service-co-ltd/id687212942

@x86 #10 看来得入个正了。

回收二手卫星飞船废金属，地上躺的天上飘的都收。

调试这种拔尖硬件+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 和销售。

@kristofer #25 😂确实后入场的更容易背上锅，因为在领导看来，明明定好的逻辑定好的功能（他们认为开发完成到测试之前就已经酸完成了，测试只需要一点点时间和修改就可以了，重心要投入到下一个功能的开发上去了），为什么你进场就要求改呢（改要时间成本和金钱成本的，打乱原本就紧张的计划的）。

@zhazi #16
1.确实正常做法是我应当介入，但是实际这份文档是 10 月份编写的，而我是 11 月进场的，这就很无力了。
2.业务边界无啊，这种赶工外包项目，业务细节都只在项目组成员的脑子里，那几位的说法都在我进行测试过程中变化呢。（一会说离职再入职得复用旧工号，一会说离职再入职得分配新工号，那么测试的场景都在测试过程中变动呢，我真的无法掌控这些变化啊）

@someday3 #21 在外包项目中，一切都可以省的，我当然明白锅不在我，用例要评审，开发要了解业务。
可是实际实施时，什么都可以节省，什么都可以越过。我要能决定/项目组成员各个角色都完美完成工作，我就不苦恼这开发质量这么差无法进行测试了。😂

@codeself #18 因为这就和外包项目成员的奇葩处境有关了。
乙方的项目组领导其实本质上是不关心实施质量的，其实上线前更多关心能不能完成阶段里程碑（里程碑的时刻点又不是由分解的工作量决定的，有时为了抢到单子就会答应一些离谱的工期），上线后更多关心能不能收到钱（这时候才和质量有一部分关系）。
所以在测试时，此功能测的业务场景丰富了，人天投入多于预期了，这类领导的想法（上线前）是“你测的那么细干嘛，能上就行了，项目成本增加了，锅在你测太多”，所以测试背锅；那么如果你测试的业务场景稍微只覆盖常见的几个，按期上线了，出生产 BUG 了，这类领导的想法（上线后）是“都是你测得不够完备，影响交付质量了，锅在你测得不够细”。
你明白了吗，这是很多 to B 的外包项目的现状，毕竟分锅的人又不会那么客观去分析，他想的是多收钱少承担成本。

@fregie #13 确实场景和边界条件考虑不全的锅是顾问的，但是这个顾问不是我，而在外包项目中，PM 可能本身就不达标，他只会将导致延期的锅放到阻碍力最大的人身上，那么调研的顾问、设计的顾问和开发的顾问明显是推动力，而阻力就变成了测试的顾问。
我和在座的各位 V 友当然分得清是调研和设计时考虑不周全导致的，但是整个项目组没有这么清晰的领导者，我想我没别的办法挽救了只能跑路了（当然项目能不能上不看质量，我们的 PM 能诓住客户的话，还是能上的）。

@zhazi #16 其实大部分外包项目都是草台班子，没有那么严格的实施方法论啥的。
从定位上分析，确实我是实施顾问，只负责根据调研文档进行配置以及编写增强功能的功能分开发说明书（以及测试），但是我们项目成员的目的还是能做好实施并上线（拿到钱跑路），在这个前提下，每个顾问都会承担一些本不属于自己的职责。
我很难解释为什么我要自己开发，因为这是很多个因素导致的。
但是如果有这么两个选择放在面前：1.自己开发+测试，1 天搞定无 BUG 上线稳定运行 2.他人开发我测试，来回修改来回重测，一个星期搞定上线偶有 BUG 。
我还是会选 1 的，纯粹是我不想因为别人的（拉胯）能力浪费我的生命。

@someday3 #7 😂所以你能理解我为什么看了代码就不想继续测试了吗，我就像 rick 和 morty 里拿到了死亡水晶一样，可以提前看到自己注定死翘翘的结局了，那我还能开心得起来吗。

@someday3 #7 这两个组合拳下来，xx 测试就只能祈祷虽然我没测那么细但是上线可别出大 bug 啊。