流程|单元测试工具┃单元测试的测试前置驱动条件_程序|符号执行|需求|驱动|Uni

什么是TDD？
TDD ，即测试驱动开发，是一种利用测试受益的方法论（或者说实践准则）。简单地说， TDD就是在写代码前先写测试，并严格遵循red => green =>refactor（错误=>正确=>重构）的流程，所以才叫做“测试驱动开发” 。其中， “驱动”这两个字才是TDD的核心思想。

文章图片

传统编码方式 VS TDD编码方式：
【流程|单元测试工具┃单元测试的测试前置驱动条件】传统编码方式

需求分析阶段未仔细推敲就着手编码
当需求细节不明确时，才去与业务人员沟通
多次确认终于写完所有逻辑
运行测试→程序不执行功能→调试
经过长时间调制，程序终于执行预期功能
转测试→QA测试bug→debug→打补丁
程序终于运行成功
代码一团糟不敢改→改了还得手工测试→让 QA测试、加班...

TDD编码方式

先分解任务，分离关注点
列 Example ，用实例化需求，澄清需求细节
写测试，只关注需求，程序的输入输出，不关心中间过程
写实现，不考虑别的需求，用最简单的方式满足当前这个小需求即可
重构，用手法消除代码里的坏味道
写完，手动测试一下，基本没什么问题，有问题补个用例，修复
转测试，小问题，补用例，修复
代码整洁且用例齐全，信心满满地提交

TDD 的好处有哪些？
降低开发者负担
通过明确的流程，让我们一次只关注一个点，思维负担更小。
提前澄清需求
先写测试可以帮助我们去思考需求，并提前澄清需求细节，而不是代码写到一半才发现不明确的需求。
得到快速反馈
有很多人说 TDD 时，我的代码量增加了，所以开发效率降低了。但是，如果没有单元测试，你就要手工测试，你要花很多时间去准备数据，启动应用，跳转界面等，反馈是很慢的。准确说，快速反馈是单元测试的好处。
TDD 的难点在哪？

并非所有类型的代码都适合TDD ，尤其是那些不能由机器简单的判断对错的情形，比如图形UI和数据库设计。
TDD需要让管理层意识到TDD的价值，为TDD预留额外的开发时间，并且强制每个开发人员按TDD的流程来写代码，需要自上而下的管理和开发流程的支持。
测试人员不会写有效的单元测试：有很多人写测试，连到底在测什么都不清楚，也可能连断言都没有，通过控制台输出，肉眼对比来验证。

单元测试任务太重？效率太低？
工业嵌入式系统单元测试工具
由上海控安自主研发的SmartRocket Unit作为一款单元测试工具，可以自动生成满足语句、分支、MC/DC准则的测试用例，自动执行测试驱动。通过使用SmartRocket Unit ，用户可快速对安全攸关的代码进行单元级别的白盒测试和回归测试，从而进一步提升单元测试的效率。

文章图片

SmartRocket Unit 通过智能模拟测试人员进行覆盖率测试时的思路，实现其核心功能:
l 测试用例自动生成
动态符号执行求解引擎，采用自动推理与符号执行技术，可自动分析程序路径，产生可满足特定覆盖率准则的测试用例。
l 程序打桩技术
对被测模块中的函数调用自动进行打桩，自动生成测试驱动。
l 测试用例的执行及分析
测试驱动将测试用例作为输入，自动执行测试用例，记录并分析执行结果，最终产生测试报告，包含覆盖率分析结果及测试用例数据等。