认识达内从这里开始

我们在前几期的文章中给大家简单介绍了软件测试自动化等技术应用方法，而本文我们就再来学习一下，单元测试常见问题都有哪些。

为什么要进行单元测试?

单元测试保证局部代码的质量

单元测试改良项目代码的整体结构

单元测试降低测试、维护升级的成本

单元测试使开发过程适应频繁变化的需求

单元测试有助于提升程序员的能力

由谁进行测试?开发部门还是测试部门?

应该由开发部门进行单元测试!

由测试部门进行单元测试的问题：代价高，人手不足，耽误了测试部门对其他测试的准备工作。

由开发部门进行单元测试的问题：担心影响开发进度，程序员不习惯做单元测试，测试自己编写的代码，难于保证测试的效果。

无论由哪个部门做单元测试，都要面对一些问题，但开发部门所面对的问题可以借助工具来解决，而由测试部门进行单元测试，要么无法真正实施，要么代价昂贵。

由测试部门进行单元测试为什么成本昂贵?

需多次重复理解程序

反复沟通需要大量时间成本

不利于发挥单元测试对代码结构的约束机制

耽误测试部门对其他测试的准备工作

即使测试部门人手充裕，仅仅从效益来考虑，也不应该由测试部门进行单元测试。如果测试部门本来就人力不充裕(进行单元测试的人员需具备编码能力)，勉强由测试部门进行单元测试，结果往往是----没有结果。

由开发部门进行单元测试能保证测试效果吗?

程序员测试自己编写的代码，往往只考虑“正常状况”，这当然会影响测试效果。但如果所用的单元测试工具能够统计各种白盒覆盖率，就能检查测试效果。当然，只做到这一点还是不够的，因为白盒覆盖具有逾后逾难的特点，达到一定的覆盖率后，覆盖率的提升会很困难。如果测试工具功能足够强大，能提供工具帮助用户快速地设计测试用例，达到完整的白盒覆盖，那么测试效果就能得到完全的保证。

实际上，如果没有充分的统计数据，没有达到足够的测试完整性，那么由谁做单元测试，效果都不能保证。

边编码边测试会影响编码进度吗?

传统的单元测试是很费时费力的工作，主要时间消耗在于：编写测试代码、设计测试用例，如果开发工具能自动生成测试代码，并且具有快速设计测试用例的功能，那么测试费时就很少;另一方面，如果测试工具还能提供数据，帮助程序员整理编程思路、快速发现错误，更高效地调试，那么就能大量提高开发效率，抵销测试所消耗的时间，不但不会影响编码进度，甚至加快编码进度。

实施单元测试需要改变开发流程吗?

边开发边测试，单元测试是编码行为而不是测试行为，测试代码看作是项目代码的一部分，程序员提交产品代码时也要提交测试代码和测试报告，其他流程可以不作任何改变。

另一方面，在充分单元测试的基础上，由于具有高质量的局部代码，良好的整体代码结构，保证了代码的可扩展性和可复用性，同时，自动回归测试支持对代码的频繁修改而不用担心引入新的错误，因此，开发流程自然会变得敏捷，可以适应频繁变化的需求，使系统分析、架构设计和后期测试的压力减轻，自然而有效地改进了开发流程。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。