c_m*_*ker 10 unit-testing presentation
我正准备向管理人员介绍单元测试.我的团队多年来一直在编写单元测试,但该公司的其他领域似乎很难采用它.我可以让开发人员对此感到兴奋,但如果没有管理层的支持,它就不会成为标准.
你们有什么建议如何最好地处理这方面的管理？你曾经尝试过哪些有用的东西？什么东西不起作用？
Maw*_*awg 10
对于非技术经理人来说,我已经贬低了建造房屋的类比.他们会在没有蓝图的情况下建造一个,只是从一堆砖块中取出砖块并将一个砖块放在另一个上面,并考虑到一个模糊的房屋形状的想法吗？如果没有,那么为什么他们不会在编码,设计评论等之前接受适当的文件？
对于单元测试,您可以尝试将它们与各种房屋组件的质量测试进行比较,然后再将它们放在一起(砖块,水泥,门,窗户,管道)
对于那些完全掌握技术的人,我提到30%到50%处理错误条件和恢复(在关键任务的嵌入式系统中)并且你无法在没有单元测试的情况下测试它.EG,如果你只进行黑盒集成测试那么你怎么能 - 以受控和可重复的方式 - 测试模块A无法在给定点分配内存时发生的情况,或者在等待回复消息时超时在模块C中到期从某个地方,或通常成功的数据库读取.通过对接口模块进行说明,您可以随意模拟其错误行为.
当然,我用一个轴上的$符号和另一个轴上的时钟绘制我的favourriite图.我凭借这一点击败了管理层,每次都有机会证明获取错误的成本会增加后来发现它们(在需求规格中更改一行 - 5分钟;设计文档中的几个小时 - 几个100代码行(在代码审查或单元测试阶段) - 天;在大海捞针中找到针并在系统测试中纠正它 - 周).
这不仅仅是单元测试 - 你必须说服管理层 - 和你的开发人员 - 文档,评论,测试的"不必要的开销"... s/w一般的过程(包括学习新工具)......实际上节省时间而不是为项目增加时间.换句话说,错误需要更长的时间和更多的成本.测量两次,切一次等
对于单元测试,告诉他们持续集成.我强烈推荐詹金斯,但使用适合你的任何东西.说明定期构建,无论是夜间还是每次签入,都可以自动从VCS中提取单元测试并运行它们,发送电子邮件或以其他方式警告新代码,这些代码几乎会在发生时立即破坏现有测试.
如果这些都不起作用,找一份新工作(如果你在新加坡,或者想成为,请跟我说话;-)
| 归档时间： |
|
| 查看次数： |
1965 次 |
| 最近记录： |