问题描述
单元测试需要实现路径遍历吗？假如有一个函数，该函数带有一个参数，参数有边界值1和100我是否需要写五个测试函数？1。fun(0)2。fun(1)3。fun(50)4。fun(100)5。fun(9999)所以单元测试的目的是什么？仅仅只要传递一个参数，让它过就可以了吗？还是要实现路径的遍历，边界值的遍历？谢谢！
解决方案
解决方案二：
1、保证代码质量、可维护性、可扩展性2、还要测试变量没有初始值、无法值的情况
解决方案三：
我的理解单元测试算黑盒测试给参数，看结果，怎么实现不关心
解决方案四：
自检，发现一些低级问题，如数据验证、字符长度、异常操作导致的系统出错
解决方案五：
你说的是测试覆盖率吧。就是说测试的代码路径是否覆盖所有的分支条件以及它们的组合。一般我们的实践是，测试用例要100%覆盖你的代码，同时尽可能多的覆盖条件的组合。VisualStudioUnitTest和很多测试工具都可以辅助帮你测量测试覆盖率。
解决方案六：
就你的测试用例，没有函数的代码，无法判断覆盖率如果是两个极端情况：intfun(inta){returna;}那么一个测试用例足以保证覆盖了全部代码如果是intfun(inta){if(a>10000)return1;elsereturn0;}虽然你的测试用例很多，但是还是只覆盖了50%。
解决方案七：
引用楼主wxcnl的回复:
单元测试需要实现路径遍历吗？
如果你做的是课堂练习，那么答案可能是“可以做”。但是实际项目中，比如说有着1万行的代码中，其实如果你去先去穷举什么“路径”，你试试看要多久？而且人家每天随便修改几百处代码，那么路径就会由10亿条中少了2欠条，而多了3千条。请问有哪个测试人员保证更得上这个节奏？其实空谈各种测试指标，是手工测试人员的毛病。不实际。她们可以整天在那儿对着老板说理论，然后“自己”实际做到的只有千分之一。实践告诉我们，也许是不是需要覆盖路径（注意不是代码覆盖，是“路径”覆盖）我不知道，但是我知道哪一个人给她1年时间闭门研究也搞不定一年前的什么路径覆盖，更别提更上开发的节奏了。
解决方案八：
如果你只是一个“跟在开发人员屁股后边”的测试人员，你问“单元测试的目的是什么”，我只能告诉你“并不需要这样的测试人员”。单元测试的目的首先是驱动出开发进度，但凡重要的开发“基线”都应该先写测试后实现，而不是先实现然后才写测试。单元测试的第二个目的就是发挥某些有经验的测试人员的“创意”，他们可以预见到某些测试可以深入到系统内部的某些机制，因而“故意”埋下一些测试。第三个目的就是保证每天都可以把全部测试运行几千遍，可以打乱次序进行测试，可以并发多线程测试，用任劳任怨的机器去而避免手工测试人员那种“假装挺忙，其实根本不能经常进行回归测试”的毛病。第四个目的，当然就是保证先测试后提交到代码管理系统上，一边保证代码都是可以编译、可以随时发布（beta测试）的产品代码，而不会因为某个人的胡乱提交有冲突或者测试不通过的代码而造成别人的代码无法工作。
解决方案九：
测试不仅仅是保证产品质量的办法，实际上也有一些开发方法使测试成为了产品生产环节的比较重要的一环，7楼所说的TDD测试驱动开发就是一个很好的例子。
解决方案十：
如果你感觉你写程序只能保持3~5分钟清晰地思路，那么你就以3~5分钟为界，你可以写1。fun(0)2。fun(1)3。fun(2)4。fun(10)5。fun(11)6。fun(99)
其中前3个用于在10分钟内得到基本的架构，后边的用于重构、研究、测试，使得这个fun在20分钟内“搞定”。你写的这个，不是传统的单元测试，这明显是测试驱动。传统的“手工”测试理论往往死抠各种“覆盖率”指标理论，但是缺乏真正的测试开发技巧。一帮手工测试人员整天想着如何到互联网上去下载“测试工具”，然后这个根本没有什么东西，转而整天嚷嚷着测试理论。可是当你真正编写能够体现大部分“开发进度”的测试程序时，你需要面对大量挑战，你的一半精力应该用于去思考“如何写测试程序”上，这种开发习惯的养成，可以把一个菜鸟迅速变成一个独立的程序设计人员。比如说你面对一个别人开发的地图引擎，你如何测试“当你加载一幅地图时，相应的名为x的图层加载了，而且x上一共有不多不少正好1250个图形加载了”？这是你应该研究的，你需要研究别人的源代码，甚至重构它，使之更适合分解单元进行测试。所以编写测试程序是极高超的编程艺术，测试程序虽然短小但是都是精华。许多人因为这有难度，浅尝辄止，转而整天去研究理论，而不去实践了。
解决方案十一：
我再次强调之前首先声明的一点，我不是为“测试人员”来提供单元测试说明的，我只是针对开发人员。比如说上面我举的那个简单的“验证a地图上x层必定有1250个图形被加载”的测试用例，这是面向进度规划的，也是面向验收的。如果有人为了提高语句覆盖率而写一堆单元测试，很可能尽可能地用机械的思维方式去“硬凑”测试，而不是从这个层次的角度去设计测试用例。这就好像有许多人整天把90%以上的时间纠结于“增删改查”而不会先从用户喜好的操作行为上进行大胆创意一样，看似做到了教条上的80%，但是连实际的应该达到的水准的20%也没有做到，用户感觉花钱请人做出来的东西“档次太低”可是又不知道还能指望怎样修改。同样地，当提出这个问题的人的全部意见都在围绕着那些根本只有在51tesxxxxxx之类的网站上才会反复罗列的一些东西上的时候，当不是站在一个项目开发的角度而是站在“跟在开发人员屁股后边”的测试人员的角度思考这些问题的时候，学不到敏捷开发技术（或者极限编程技术），只能是无功而返。因为我们心目中的单元测试技术根本就不是给手工测试人员准备的测试技术。