项目经理要求每次提交代码的时候，都要100%的信任

这种情况下，我应该如何回答他的问题，又不显得无能？说实话，我从来没有100%的信心，但我对自己的测试方法很有信心。而且，作为一个开发者，我也知道，这些核心的改动，后期出现意想不到的bug并不罕见。

这位项目经理对软件不够了解，当然对测试也不够了解。也许他需要接受教育。

如果你有一个专业的QA部门，我会告诉你争取QA经理的支持，向这位项目经理解释软件的本质，BUG的本质，以及测试的本质。我会让QA经理说明为什么不可能对每一个条件都进行测试，以及发布/不发布是一种商业活动，如何通过测试的结果来帮助发布/不发布是一种商业活动，但绝不是完美的信息。在第三章（"为什么不只是测试一切？"）中，温伯格有一节叫做 “有无限多的可能测试。”

他讲到了一个后门，在一个高度安全的程序中，只要输入W后加三个空格，然后M后加三个空格，然后J后加168个按键，就可以绕过普通的密码保护，而不需要使用L。如果你没有猜到详尽地测试软件所需的测试次数是无限的，或者至少是 “比我这辈子能跑的次数还多"，那你就不明白本章的重点。现在你明白了。”

向你的项目经理解释说，每一天的额外测试都会在一定程度上提高你对代码的信任度，然而它永远不可能达到100%。告诉他，你很乐意以牺牲你的其他生产性工作为代价继续测试。然后问他，他希望你多花多少天时间在测试上，以及你的其他工作中的哪些应该推迟。

如果你的项目经理还是不明白，而你又觉得有点轻浮，那就问他，他是否100%地相信他发布的每一个估计都是准确无误的，并且永远不会错过最后期限。问他是否百分之百有信心，从现在开始到永远，他写的任何一封邮件都不会有错别字。问他是否百分之百地相信他现在和将来都不会出错。

老板：*您是否100%有信心这个修复不会破坏任何现有的功能，也不会对用户体验造成不良影响？

我：不，由于我们没有100%覆盖率的测试套件，所以没有办法验证任何代码的更改都会避免应用的破坏或不良影响。但是我已经执行了以下操作，以保证它不太可能以非预期的方式执行。

• 我已经将更改的范围限制在它所影响的模块上
• 我已经阅读并相应地更新了文档
• 我已经运行了这个模块和受影响的模块的单元测试
• 我已经创建了单元测试来检查新增的功能，以及由于更改而不再相关的废弃测试

虽然我不能给你100%的保证，但我已经在我认为合理的时间范围内提供了尽可能多的保证，以实现这个功能。事实上，我已经到了回报率递减的地步了。我可以再花5个小时再给你提供0.1%的保证，但这样的可能性已经很低了，这样的努力是不值得的。不过，这个项目和时间框架都是你说了算，让我知道我应该在这个功能上多花多少时间，

现在，球在他的手里。如果他真的想让我把我的个人估计从，比如说，95%的确定度提高到95.1%的确定度，多做几个小时的工作，那么嘿嘿–我可以这么做。

如果他继续在这个问题上厌恶，我就和他和项目的 “业主 "通过电子邮件谈一谈这个 "100%测试 "的要求，以及我认为需要什么资源来满足这个要求。

作为一个开发者，你是在对你的代码进行UNIT测试修改。在我看来（作为一个开发者），就是检查有没有明显的错误，所有的东西都编译好了，所有的错误都被困住了。你没有办法知道一旦代码上线后会遇到什么情况（坏的数据，意外的输入，客户端软件的变化，不胜枚举）

要想100%的相信改动不会影响到任何东西，你需要一个测试环境，完全镜像实时环境（数据，硬件，权限，连接性），以及一套测试脚本，覆盖每一种情况。众所周知，由于各种原因，这是一个几乎不可能创建的环境

如果他期望100%的信心，那么他需要提供环境和人力来支持他的期望

这有点像项目经理和客户要求东西要面向未来的时候

这有点像项目经理和客户要求东西要面向未来的时候

听起来，他好像养成了一个坏习惯。他在问一个问题，他知道自己在某种程度上是愚蠢的。但有一点强迫症的成分。我的猜测是，他的行为是基于一种潜在的焦虑，而问一个不合理的问题会让他觉得自己更有控制力。

在这种情况下，我试图通过自信和注入一点幽默来化解这种动态。如果你明白他的问题不是来自于理性，而是来自于焦虑，那么你就可以间接地解决这个问题，而不是直接地解决。

在这种情况下，我通常会通过介绍我为确保质量所采取的所有措施来消除管理层的恐惧。他毕竟是客户，他需要知道你的优先级和他的优先级是一致的。看看这些单元测试。看看这些监控。看这些代码是如何结构化的，以保持局部和模块化的变化等等。如果你能传达出一种自信和控制感，就能打消他的顾虑，你可能会有更理性的对话。

这就是这个业务的艺术所在。不仅仅是 “行不行"，而是客户是否觉得好。

不过，归根结底，这是一种商业关系。如果承包安排对你来说是舒适和有利可图，那么忍受这种怪癖是值得的。听起来他并没有那么认真，只是有点执着。就像我说的，他已经养成了一个讨厌的习惯。如果他开始有了不良反应，语气变得更有敌意，那么业务安排的平衡可能会让你不值得。但从你的简短描述来看，听起来你还是可以有效地处理好这段关系的。

很多人说这是教育问题，我并不是说他们错了，

也有可能是政治问题。这个问题实际上可能意味着什么，就是项目经理希望免除任何错误的责任。

我承认这是我的猜测，但在职业生活中，掩耳盗铃的做法并不罕见，你必须要处理好。所以，如果这句话是真的，那么你要解决这个问题需要做的不仅仅是教育这位经理，让他知道100%的信任是不可能的。你还需要说服他，让他相信bug不是灾难—-对他个人或公司来说都不是灾难。

这可能意味着，例如，提供一些以合理的成本处理bug的例子，而且没有任何指责的情况下，bug被处理的例子。这可能意味着要审视自己的公司文化，如果出了问题，公司里是否有其他人会把不公正的责任推给他。这也可能意味着要尽可能快速、低成本地处理未来的BUG。如果公司真的对代码有100%的信心，那么这样的程序是没有意义的，因为它准备好了在未来没有bug的情况下赌上一大笔钱！

作为最终的制裁，如果他（雇主）要求你（承包商）向他推销你不能提供关于你的工作的保证，而在这一点上没有什么能改变他的想法，那么你能做的就是明确地说明你不能提供这种保证，如果他认为有谁能提供这种保证，他可以雇佣其他人。当然，这当然是一条漫长的路要走，但你不妨在开始之前先了解一下你的BATNA。

严格来说，我们永远无法100%确定一个提交不会破坏一个程序。

即使有各种可能的测试（单元测试、集成、组件、系统、手工、UI、fuzz、安全、渗透………..你说了算）。这是由于一个Halting problem。以下是维基百科中的相关摘录。

在可计算性理论中，Halting问题可以这样表述。"给定一个任意计算机程序的描述，决定该程序是结束运行还是继续永远运行"。这就相当于给定一个程序和一个输入，决定程序在有了该输入的情况下，最终是停止运行还是永远运行的问题。

艾伦-图灵在1936年证明，对于所有可能的程序-输入对，不可能存在一个解决停顿问题的一般算法。这个证明的一个关键部分是对计算机和程序的数学定义，后来被称为图灵机；停顿问题在图灵机之上是不可判定的。

如果你的PM在乎价值和稳定可预测的交付，你或许可以说服他看一看SCRUM框架。就我个人而言，我建议和你的PM和团队开个会，讨论一下你的流程。我非常赞成SCRUM，所以这主要与SCRUM有关。

我会尝试解释一下，100%的目标是难以捉摸的。它不可能达到。绝不可能。在整个宇宙中。历史上已经看到了很多这样的例子，Windows 95的发布的演示比如说。很久之前？那么，看看在公开的CI服务器开源项目的红色构建有多少；如果你在那里没有账号，就以访客身份登录。

其次，我建议采用一种做法，在那里你可以提供_价值，而不是一个提交的信心。东西，客户关心的东西。反复地、反复地、可靠地传递价值。现在，你可以把PM的视角从100%的保证转移到真正重要的东西上。那就是：软件在使用中，你的产品在改进，团队在向客户交付价值。

第三，应该是一个完成的定义。东西，是一个开发团队想出来的东西。这可能包括：文档、实施、测试、质量门等。这一点非常重要，因为你现在可以把subjectivity（即 “你是否100%确定？"）转移到objectivity（即完成了定义中的所有ded的子弹头点）。但所有这些步骤都可以让开发人员减轻这种挫折感，并让他们能够提供客观可量化的结果，而不是主观的保证。

1) 不要把任何东西提交到生产代码流中，直到不只是作者，还有一个或更多的其他程序员都对其进行了理智检查，以确保它只修改了必要的东西，它符合所有公认的良好编码实践标准，并附带一个测试，让你有足够的机会检测到后面的修改是否再次破坏了逻辑，等等。

2) 在所有的回归测试被重新运行，并且证明不会破坏任何测试的东西之前，不要将任何东西提交到生产代码流中。如果在测试过程中出现任何故障，则必须将更改的内容退掉，直到可以清楚地确定不会造成问题。客户会用你的代码做一些你从未预料到的事情。

这些都不是100%，也不是它们的组合。但它们能让你更接近。它们确实需要投入大量的额外资源。与skunkworks的 “只要做了，当它坏了，我们就会修复它 "的编码实践相比，它们确实拖慢了开发速度。但是，如果你真的想要无bug的代码，认识到人类是很容易出错的，并且在故障到达客户之前就把实践放在那里，可能比这些成本更值得。如果你做的是大型企业的基础架构，那就值得投资；你不想成为一个BUG毁掉一家价值几十亿美元公司的业务流程的人。直到它第一次拯救了他们的后脑勺。

事实是，这就是差劲的测试。现实情况是，一个不愿意投资QA团队的公司，其测试效果会很差。好的测试是昂贵的，而且需要时间。公司不授权时间和金钱，就已经接受了风险。

即使是QA团队也不能保证每一种可能性都被测试到，因为一个复杂的程序可能的路径基本上是无限的。然而，他们会让你比你现在更接近。原因之一是，一个dev不可能充分测试自己的代码。他们知道它做什么，所以他们倾向于围绕着他们认为它应该做的事情来设计测试。他们错过了边缘案例，他们错过了用户做的一些愚蠢的事情，而这些愚蠢的事情是开发人员永远不会做的，因为他们知道它是如何工作的，他们有时会错误地解释需求，但他们所有的测试都会反映出他们最初错误的解释。他们经常会错过需求中的错误，只做了要求他们做的事情，而不做他们应该做的事情（这就是大量BUG的原因，而这些BUG都是在实际用户[在定义需求时往往没有征求过用户的意见]尝试使用软件后才发现的）。他们错过了应用程序的部分效果，尤其是那些由专家完成的部分（比如一个表的改变对应用程序来说是有意义的，但却破坏了一个自动导入流程或报表）

如果他想要更高的质量，他必须付出时间和金钱的代价。即使有了完整的QA，你也无法达到100%的质量，虽然NASA和它的承包商们肯定会接近。他们还花了大的钱比你们公司花的多。

如果他想要的是保证任何问题不会对他的客户造成伤害，那就谈谈你的测试流程（给他看你的测试清单），你认为会受到什么影响，你是如何检查的，你的流程是如何恢复一个坏的推送和记录错误的流程，这样你会在大多数客户注意到它们之前看到它们。给他信心，即使有问题，也可以修复。谈谈快速推出代码（新功能或修复）的价值，而不是花更多的时间来进行更彻底的测试。

你也可以要求他在每次修改的时候提供系统的彻底回归测试，因为一个开发者不可能完全测试自己的工作（你知道你的假设是什么，如果假设不对，你永远不会测试）。确保他知道他必须测试应用程序的每一个页面，以及每一个可能在一个页面上做的每一件事，都要测试。哦，对了，测试任何导入/导出、报表、自动作业。以及任何可能受到影响的相关应用。一旦他尝试过一次彻底锻炼系统，他就会意识到为什么你不能做出这样的保证。

另一个可以尝试的事情是，事先告诉他，不，你不能做出这样的保证，但如果他授权X个测试时间，你就可以更接近于做出这样的保证。给他一个额外的测试项目清单，以及设计和运行每一项测试所需的时间。告诉他执行完所有这些测试后，你现在有多少百分比的信心，告诉他你现在有多少百分比的信心。所以，如果你现在有1000个单元测试，每个单元测试需要5分钟的时间来设置和运行并评估结果，那就是83个小时。请他授权去做，把这个时间消耗掉。

如果他在整个项目建设的过程中，实际上是在微观上管理你，并且在整个项目建设的过程中都在关注你，那么有一个简单的方法可以确保你可以 “保证 "100%的信心，而不需要他以后再向你推销。

如果你是你自己的代码的唯一测试者，这不是没有道理的–你已经全身心地投入到项目中，如果他想要完美，那么他应该自己负责确保完美。

如果因为任何原因，你认为这样做会不顺利（比如说，如果要求他做更多的工作是你已经知道的事情，那将是灾难性的），你能做的就是尽可能多的硬性错误测试，在你的报告中写上你知道的一切正确的工作，并给他100%的保证，'在我的测试范围内，我对这些修改有100%的信心'。

不幸的是，你可能会遇到一个对你的工作理解有限的'老板'，当你试图解释纠错是不可能保持100%的信心时，这总是很痛苦的。所以，总结一下，你最好的办法可能只是尽你所能，把所有的事情都记录下来，并让人明白，你在自己的能力范围内做的事情。

相当不错的回答，PM肯定需要接受教育，学习一下写软件的意义。

我不想重复什么，但抛出另一个相当不寻常的想法。这个方法是相当有风险的，很大程度上取决于你的名气有多高，你的技术有多好（或者说更多的是如何看待你的技术），以及你和你的PM的人品都有很大的关系。我假设你没有误解他的意思，他的意思真的是100%（我经常看到有人说100%，但真正的意思是 “尽力而为"）

对我来说是有效的，这也是我在这里提到的唯一理由。我已经警告过你了。

有时，一个PM（或任何其他经理）不想听，所以你必须在某个地方让他（或团队）撞墙，让他（或团队）停下来思考一下。在这种情况下，它的意思是。尽可能地工作，尽可能地试探，尽可能地试探。

如果你非常幸运，就不会出现任何bug，大家都很高兴，但实际上会发生的是：有一个bug。你现在该怎么做呢？你承认自己犯了错误。把错误与BUG联系起来，把错误与100%确定的错误联系起来。人类是不完美的，也会创造出软件中的BUG。人类是不完美的，也会在测试中产生bug。因此，人类是不完美的，也会在100%确定没有bug的认知中 "制造出bug"。

呈现这一点很好，而且100%不漏水（哈哈，J/K，又是100%）。确保做完这一切后，过去的信息是 "我不能对自己的测试有100%的把握"。如果当时的PM不能做到 "这对所有的开发者都是一样的 "这样的逻辑步骤，那么所有的希望可能都是泡汤了……

不过，请你先试试其他的东西吧

关键的指标是，这是最近的变化。某事（或某人）很可能给你的PM带来了不好的经历，现在他每当有什么变化时，他就会紧张起来。

如果你能让PM告诉你他的故事（也许是在他选择的饮料上），你就能引起他的共鸣，他可能会接受 “创新"，也就是健全的软件工程实践。谈论不同的测试方法、同行代码评审、正式的方法（又名正确性–by-construction）所带来的信心、质量、资源和进度上的权衡。

说出他的语言。用比喻来说明问题的大小。是4万行代码吗？告诉他，这就像一本600页的外语谋杀悬疑小说。如果你想在第12章中段改变一些东西，你如何确保它不会造成与故事其他部分的连续性中断？

在合理的经济范围内寻找买入的方法，向着一个可以接受的目标增加信心。你不可能一夜之间就能实现SEI能力成熟度模型5级。但你可能会从目前的问题变成 "自动回归测试套件是否通过？"和 "我们如何在回归测试系统中表达这个新的要求？”

我会用最数学的方式回答，考虑到他要求的是一个100%的概率，完全忽略了统计分布对这个数字的影响：你应该给他2或3个数字，并附上相关的置信度。1周为90%，2周为95%，6个月为100%。最后一个数字是夸张的，但我相信你已经明白了。

参见【维基百科关于置信度区间的文章】(https://en.wikipedia.org/wiki/Confidence_interval)，更多阅读。