标签：blog http ar 使用 strong sp on art 问题
纯个人总结：
单元测试(UT)、功能测试(FT)：
目的：1、尽量避免写的代码测试人员频繁的来找你其他地方又出问题了；2、提供的接口不可用；3、一个bug修复了引入了其他的bug或者其他用例变红了；
理解：在实现函数功能的时候编写对应的测试代码，尽量保证”输入-输出”的正确性，在测试用例比较多的时候对系统有强身健体的功效，适用的人群是：非大牛者
优点：
保证函数基本功能
修改代码后批量跑UT保证修改的代码对其他逻辑无影响
修复bugs后增加用例代码，更加强壮
有利于代码重构
可以支持nightly build,检验前天代码质量，检查代码覆盖率
测试代码是函数的说明书，轻文档
减少bugs数量和排查修复时间精力
缺点：
需要花时间去搭建一个测试代码平台和维护
前期需要很多的时间维护UT,FT代码（但后期系统越大作用越明显）
不适合使用的或者作用微小的场景
小项目，内容少一个人就能把握全部细节
记忆力合理都很棒的牛人，写每句代码都了如执掌，就不用浪费精力写ut了
已经记录好久且项目大的工程，一直没ut，突然闻到理解到ut 的作用就想开始的，晚了
不喜欢敏捷思想的，就算开始了ut工程，后面会因为没维护而成为拖累和一滩项目死水，也别使用，以免成为敏捷的悲观者
http://blog.csdn.net/linxuping/article/details/16968141
标签：blog http ar 使用 strong sp on art 问题
原文地址：http://www.cnblogs.com/softidea/p/4048299.html
