unit-testing - 如何最好地向管理层展示单元测试？

Question

关闭。这个问题是off-topic .它目前不接受答案。












想改进这个问题？ Update the question所以它是on-topic对于堆栈溢出。

9年前关闭。




Improve this question




我正在为经理准备一份关于单元测试的演讲。我的团队多年来一直在编写单元测试，但公司的其他领域似乎很难采用它。我可以让开发人员对此感到兴奋，但如果没有管理层的支持，它就不会成为标准。

你们对如何最好地处理这个问题有什么建议吗？您过去尝试过哪些有效的方法？哪些事情没有奏效？

Answer 1

对于非技术经理，我已经回到了盖房子的类比。他们是否会在没有蓝图的情况下 build 一个，只是从一堆砖头中取出一 block block 放在另一 block 上面，心里有一个模糊的房子形状的想法？如果不是，那么为什么他们在编码、设计审查等之前不接受适当的文档？

对于单元测试，您可以尝试将其与将各种房屋组件放在一起(砖、水泥、门、窗、管道)之前单独进行质量测试进行比较

对于那些掌握任何技术的人，我提到 30% 到 50% 处理错误条件和恢复(在关键任务嵌入式系统中)，如果没有单元测试，你就无法测试。例如，如果您仅进行黑盒集成测试，那么您如何以受控和可重复的方式测试当模块 A 无法在给定点分配内存时会发生什么，或者在等待回复消息时模块 C 中的超时到期从某个地方，或者通常会成功的数据库读取。说明通过虚拟化接口(interface)模块，您可以随意模拟它们的错误行为。

当然，我用一个轴上的 $ 符号和另一个轴上的时钟来绘制我最喜欢的图表。我一有机会就用这个来击败管理层，以表明发现错误的成本越晚(更改需求规范中的一行 - 5 分钟；设计文档中的几段 - 小时；几百个代码行数(在代码审查或单元测试阶段)——天；在大海捞针中找到针并在系统测试时纠正它——几周)。

这不仅仅是单元测试——你必须说服管理层——以及你的开发人员——文档、审查、测试的“不必要的开销”......一般的软件流程(包括学习新工具)......实际上节省时间，而不是为项目增加时间。换句话说，出错需要更长的时间和更多的成本。测量两次，切割一次，等等

对于单元测试，告诉他们continuous integration .我强烈推荐 Jenkins，但使用适合你的任何东西。说明常规构建，无论是每晚还是每次 checkin ，都可以自动从您的 VCS 中提取单元测试并运行它们，发送电子邮件或以其他方式提醒新代码，这些代码几乎会在发生时立即破坏现有测试。

如果这些都不起作用，那就找份新工作(如果你在新加坡，或者想成为，跟我谈谈 ;-)