关于“开发把时间都花在编码上，还要写测试么？”的讨论

以下文章来源于DevOps ，作者冬哥  

• 开发进度很紧张，不把时间用在代码上，还考虑测试的工作，是不是不太好？开发把测试活儿干了，那测试干啥？写代码么？
• 测试负责质量监查。
• 为啥一定要开发写测试用例呢？
• 先人工自测下，后补doc不行么？

• 不管进度是否紧张，开发都需要调试代码，都需要花时间定位缺陷，以及修复缺陷，和验证缺陷是否真的修复了。恰当的单元测试，可以很大程度上改善以上的时间。
• 单元测试就是开发的一部分，排除出来算进度本身就是错误的。
• 开发先自测，写不完换测试。
• 聪明的孩子都会把编程的一部分时间用来做单元测试。
• 测试用例要看是什么测试用例吧，例如单元测试就是开发写的，其他则是由测试人员编写的。
• 单元测试不是开发写谁写，让测试把开发代码看完理解了再写么？

• “据书上说，测试前移能极大缩短修复BUG时间，要不咱试试？”
• TDD不是标准答案吗？
• 结对编程，一个写功能，一个写测试。
• 测试覆盖不到，CI挂掉，提不了PR。
• 代码评审的时候必须提供对应的测试用例，否则代码不予合并到发布分支。

• 没有测试用例，如何及时反馈代码的正确性？代码要的是数量，还是质量？
• 如何保证开发人员投入足够的时间写功能，而不是把时间花在写BUG上呢？
• 这样不可能做到高质量，这种问题，提问的人自己也很清楚，不必搭理。

• 产品生命周期阶段而定，如果早期，或者产品本身生命周期就很短的，其实是不是不一定要写那么多单测。开发能保证冒烟测试全通过，我觉得就OK；可以考核开发的一次性提测通过率。冒烟之后，就是提测，测试同学测出bug，开发修！如果Bug可控，其实ok；如果Bug太多，增加冒烟比例。
• 如何在业务和时间紧张的情况下，进行测试的安排。要分两个维度来看，个是看产品的性质。如果产品本身是快速迭代的例如2C端的，那么我们就做快速交付，可以通过灰度来做。换句话讲，让客户帮我们做2C端的测试，就算有问题，对整个的影响和风险是可控范围的；如果有问题，可以通过快速上线新版本进行修复的。还有一种，是类似金融、航空航天、医疗等，对人的生命安全或金融安全有重大影响的，这种就不适用了，尽可能在研发环境里把问题找出来，要把资源和时间做一个平衡。如果有风险，要在产品、测试、研发以及老板之间把这个风险暴露出来，发版的责任大家共担。
• 时间紧是伪命题，不信你看看大家每天依旧有时间聊微信、刷微博。所以问题的核心在于：开发人员为什么非要写测试用例？对他们有什么好处？不写有什么损失？大家有这样的痛点和诉求吗？如果不能解答这个问题，那就没必要写，即使以政治任务强压，只能让大家怨气加深，各种糊弄，当形式主义去完成。
• 鸡贼点：或者可以在DevOps平台上增加一个类似门限提交的卡点，去尝试用工具改变一下大家的行为作为尝试，看看效果再做决定。把怨气引到工具上，让工具唱红脸，人唱白脸，加以引导，去探索适合的“平衡点”。
• 如果存在甩锅，说明动到一方的利益了，那么就要反问实施方，你知道大家的核心KPI是什么么？各方做此事的利益共同点在哪里？不然为什么大家“浪费时间”陪你玩？搞不定这个问题，后实施者自己就会变成“众矢之的”的瓶颈点。
• 什么工具都打不通“部门墙”，唯有“人”！这个“人”要有足够的信息量，了解各角色、各部门的核心KPI，当然获取信息的途径可以多方面，比如在酒桌、闲聊、八卦等各种方式。用“信息差”创造“影响力”，谁信息多，谁有主导权，然后找大家“利益共同点”去引导大家共识，让做这件事的每个人都能从中收获实打实的好处，如此才能跨角色或跨BU的把大家凝聚在一起。

• 把测试也写在需求里面。
  
• 应该要解决需求方的焦虑，老板也有压力。如果工具、资源、流程不行那还好说，增加资源、改进工具和流程。作为执行方要控制老板的预期。
• 如果不能delay的话，就减scope。
• 凭什么啊！减需求啊！
• 让开发进度别那么紧张。
• 我一直觉得敏捷就是用来管理一些过于贪心的老板或甲方的好工具。
• 双周迭代的话，开发编码时间都紧凑，没时间写用例，除非人员很充足。
• 进度紧张，又要有足够时间写测试？本身两个就是相悖的，看写代码人的个人能力了。
• 如果不能为开发团队争取来足够的时间，又不愿意砍功能，那就做完项目优先级高，功能交付了再说。
• 需求人员说：啊，都急着要产量了，还测什么~
• 
  

• 我司没有测试人员，在敏捷的模式下BA能及时赶出下个冲刺的需求就很nice了，开发人员需要承担测试的工作，但是没写测试用例，会先对着需求验收标准写开发思路，然后开发自己冒烟后让BA进入测试，BA会小本本记录SIT阶段有多少bug，UAT阶段有多少bug，以及上线后是否出现生产环境bug。考核的时候，以单个冲刺间开发人员的bug率进行交付质量打分。“打分是矮子里选高个儿么”？有一个红线SIT：多少个bug以内，UAT多少个bug以内。触碰红线的绩效就别想多好啦。

• 被其他人测出千行代码的BUG数目，直接和开发的奖金成反比，有点邪恶~

• 如果时间线往前延伸，方案多。如果只是基于当前时间点，这个好难，放弃在测试用例上投过多时间是一种选择，只关注核心、频发业务。另外，尝试把测试引入救急，转变下原有方式。这样不是佳方案，只是应急措施。

• 拉长时间线，把上线回滚风险和单位上线时长做个回归分析，应该可以算出来花多少精力实现测试AI化。

• 体会过单元测试的会主动去写，但也是覆盖部分关键方法；提升覆盖率还是要靠绩效辅助。

• 如果一个公司一直属于紧急状态。那这个公司估计也活不长久了。

• 向领导反馈，如果说现阶段软件质量要求不太高，反而交付时间是重要的情况下，可以暂且牺牲质量，后面再还债。

• 如果测试用例是交付物中必须的，那会有人写，毕竟是上线必须的条件，加班也得写啊。往往就是因为可有可无，反正不写也不影响系统上线，那肯定先紧着上线要做的事情完成啊，其他等以后再做，然后上线后觉得反正都上完了，其他做不做都一样。

• 就是纯粹为了让开发写的话，不如就故意找他们麻烦，开发完代码之后鸡蛋挑骨头全算BUG，博弈一下很快估计就写了...这个开发写，本质上类似编写完成的定义。

• 讲个故事，没过生产跳伞包的厂家合格率永远无法到，后来每次跳伞都带上几个厂家生产人员，然后，结果大家都知道了，合格率马上。

• 架构足够，这测试代码的时间就不会花太多。业务代码也是一样，花太多时间写业务代码，说明架构优化还不够。

• 功能精简，构思好代码逻辑再动手。

• 如果大家都认可写测试用例的价值，时间紧张的时候，问题就变为如何高效写测试用例，否则是不是不宜在进度紧张的时候做强要求？

• 不是不给写测试的时间，而是不给学习测试的时间。

• 从后续发现的缺陷看他们交给测试人员时的代码质量，怎么保证质量他们自己决定。特性团队内部小范围沟通，应该还好，比较真正的目标就在眼么前儿。另外，判断什么时候该写，该怎么写测试用例，这个能力本身的培养也很重要。有些时候觉得没用所以不愿意写，其实是因为不会写胡写才没用。

• “开发进度很紧张”：为什么会紧张？哪些时候不紧张？如何可以不紧张？
• “投入足够的时间写测试用例”：目前投入多少时间？都写哪些测试用例？你认为多少是合理的足够时间？如果有足够的时间，你觉得开发人员写哪些测试用例？为什么？
• “把时间都花在编码上”：代码质量如何？如何衡量？出现过哪些质量问题？回溯来看可以做哪些改进？
• 其他相关的问题：系统是什么类型？缺陷目前如何分布的？上线出现缺陷如何修复？会有哪些影响？