课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
单元测试是目前大多数软件测试程序员都在使用的一种测试方法,下面我们就通过案例分析来了解一下,单元测试的概念与管理方式。
一、什么是单元测试
单元测试(unittesting),是指对软件中的小可测试单元进行检查和验证。对于单元测试中单元的含义,一般来说,要根据实际情况去判定其具体含义,如C语言中单元指一个函数,C#里单元指一个类,图形化的软件中可以指一个窗口或一个菜单等。
总的来说,单元就是人为规定的小的被测功能模块。同时,
单元测试是在软件开发过程中要进行的低级别的测试活动,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
在实际研发中,很多团队浪费大量的时间和精力编写单元测试,那么“好的”单元测试是什么样的呢?
好的单元测试可以覆盖应用程序行为的不同情况和方面
好的单元测试应该结构良好的代码,包含测试准备、执行、断言、测试清理
好的单元测试每个都只测试一个新的功能、代码单元
好的单元测试是独立和隔离的:什么都不依赖,不访问全局状态,文件系统或数据库。
好的单元测试是可描述的:见名知意。
好的单元测试是可重复执行的:无论何时运行,无论在何处运行都通过。
好的单元测试运行的很快
二、如何管理、评估单元测试的覆盖率和通过率
业界通常的做法有:
1.代码行数覆盖率
2.类、方法、条件分支覆盖率
3.单元测试类型覆盖情况:正常、异常、性能、边界
4.业务场景覆盖情况
但是会产生对单元测试一些误区、错误理解:
覆盖率数据只能代表你测试过哪些代码,不能代表你是否测试好这些代码。(比如上面一个除零Bug)
不要过于相信覆盖率数据。
不要只拿语句覆盖率(行覆盖率)来考核研发交付质量
路径覆盖率>判定覆盖>语句覆盖
开发人员不能盲目追求代码覆盖率,而应该想办法设计更多更好的用例,哪怕多设计出来的用例对覆盖率一点影响也没有
经过内部架构师团队的技术交流和讨论,我们达成了以下共识:
我们如何写好、用好、管好单元测试?
面:覆盖核心微服务的实现,即:核心重要的微服务必须覆盖单元测试
点:单元测试场景要尽可能地覆盖
结构:单元测试要有完备的断言
类型:单元测试尽可能的覆盖正常、异常、性能、边界
可设计评估:概要设计时,确定并录入功能的单元测试场景,开发完成提测时保证单元测试覆盖率
管理:单元测试情况能全面上报管理起来,以进一步控制开发交付的质量
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。