江名峰(34854615) 15:39:04
我一直在想，虽然国际上，大师们认为单元测试要由程序员自己写，但是我觉得，在一个小团 队里，需要专人来做单元测试，开发人员需要捕获程序设计的灵感，有时候根本无心去写测试，有时候解决一个问题缺少一个好的思路，那么写出来的代码也不会是 最优的结果，虽然它经过单元测试没有BUG。
燕双龙(85709616) 15:40:48
大师们所在的团队和我们的团队不同，他们的算是“团队”，而我们只能算是“作坊”。如果相提并论就会有问题。
燕双龙(85709616) 15:41:16
我们之所以叫“作坊”，根本原因就是钱太少。
江名峰(34854615) 15:43:35
怎么样做才省呢？开发人员捕获灵感的时间往往都是一闪而过，而且去实现一个优化的思路更需要时间，这是时候写代码就跟打草稿一样的。需要有人提供专职的单元测试服务，帮助开发人员完善代码。
燕双龙(85709616) 15:44:59
很难
江名峰(34854615) 15:46:16
如果有专职代码测试人员，一人可以为多个开发人员提供测试服务，其实开发人员自己写测试往往是走过场的。
燕双龙(85709616) 15:46:50
我想最多有个检查单元测试写的是否标准的人，如果要让专人去测试代码。那么也就必 须保证代码是在写之前就已经设计成功，否则是没法达到的。如果设计和算法都实现没有定好，那么一旦写出来，也只有程序员自己知道怎么测试才是最好的。不然 测试人员还要花比程序员设计的时间更长的时间去学习这个算法和设计，才能写出好的测试。
江名峰(34854615) 15:48:26
但是测试人员的专业技能十分精通的话，这些问题都是可以克服的。
刘忠(29435460) 15:49:27
开发人员写单元测试走过场是开发人员的问题
如果让其他测试人员为开发人员写单元测试，那还不是累死人的活，要通读代码，完全了解，才能写出好的测试，这个测试人员的水平要高出开发人员很多才行
江名峰(34854615) 15:49:55
开发人员写代码本身就是要让团队读得懂的，这是最起码的要求，另外，开发人员的代码自然是在自己手中不存在明显的问题了，单元测试往往是为了检测代码的深层问题。
刘忠(29435460) 15:50:44
是要让团队读懂，可是让测试人员去承担这个任务，代价太大
燕双龙(85709616) 15:50:51
对于简单代码，或者是一些通用代码交给别人测试可能可以。但是一旦算法复杂，估计别人就很难测试了。
江名峰(34854615) 15:51:09
我们都希望每个开发人员都尽职地写测试，事实上是办不到的
刘忠(29435460) 15:51:59
同理，要求每个测试人员尽职的这样写测试，事实上也是办不到的
燕双龙(85709616) 15:52:18
其实做不到是因为现在都没有写单元测试的习惯，另外也是因为现在没有几个团队重视这个。如果所有代码都以单元测试是否通过为考核标准，那么我想所有程序员都会写，因为不写就不给工资。
江名峰(34854615) 15:52:38
你把测试任务单列出一个职位，会更有效率
江名峰(34854615) 15:53:22
依赖工资的克扣来实施管理，往往是最差的管理
燕双龙(85709616) 15:53:34
在VSTS中，就有专门的模块管理单元测试，项目经理可以设置任务完成的级别，比如所有编译都通过并且没有警告的情况下所有单元测试都通过了，说明程序员工作完成了。经理就可以进行考核。
刘忠(29435460) 15:53:44
等于测试人员重写了一遍要测试的单码，更关键的是，设计思想还不是自己的，比自己重写一次的任务难度和程度都要大
燕双龙(85709616) 15:54:51
其实举个很简单的例子，我想现在没有一个人能够写Epassion架构的单元测试，除了我。
刘忠(29435460) 15:55:09
嗯，BUG应该分级管理，允许出现多少数量内，多少级别内的BUG，进行考核，总要进行此行政手段，完全依赖自觉的执行，太理想了，是道家的思想，太理想化了
江名峰(34854615) 15:56:10
测试人员不需要重写被测试的代码，他一般检查被测代码的输入与输出，依赖合理的断言
燕双龙(85709616) 15:56:22
不是别人不能写，是因为他们都不动我里面都用了什么算法和原理，那么如何测试？方法就有上千个，哪个方法重要哪个方法不重要，哪些方法是开发期才创建的？哪些方法是设计期就有的？这些都很不确定，那么第三者就必须搞清楚这些才能进行单元测试的编写。
刘忠(29435460) 15:56:43
真正的单元测试要做到逻辑覆盖，语句覆盖等
这需要对原码进行研究
江名峰(34854615) 15:57:40
事实上，在没有单元测试前，测试员已经在做类似的工作了
燕双龙(85709616) 15:57:41
呵呵，我在现在公司讲过代码覆盖率怎么写，怎么用，但是真正要达到代码覆盖率100%，就只有编写这个代码的人才能写出。
刘忠(29435460) 15:58:01
你认为你的输入输出做到所有覆盖情况了，实际上有可能没做到
只是做了些边界条件，异常条件的测试
刘忠(29435460) 15:59:02
开发人员估计也要想破头才能做到100%啊
江名峰(34854615) 15:59:08
这都是相对的，你自己写测试也不可能做得到100%
燕双龙(85709616) 15:59:18
其实真正的单元测试，应该是编程人员在未开始实际编码之前写出的。然后根据单元测试的条件来编写实际代码，这样不但代码覆盖率可以提高，也可以提高实际代码的健壮性。例如不能抛出异常的方法就必须对所有异常进行处理。
燕双龙(85709616) 16:00:37
能做到100%的，只要细心。VS中有专门的覆盖率模块，该代码执行的所有代码都会被显示为各种颜色，当一个单元测试执行完毕你就可以看到哪些代码没有执行到。
刘忠(29435460) 16:01:25
其实测试人员只能进行些黑盒测试，功能测试，性能测试等
如果要求单元测试，变成还要去了解一门语言
实际上专职的测试人员，一般不会写程序
燕双龙(85709616) 16:01:58
其实在方法都明白作用很清晰的情况下，大多数程序员还是不会去写单元测试的，更不会去看他的单元测试覆盖率是多少。关键在于整个项目都没有安排单元测试的时间，大多数项目经理也都不会去关注单元测试。
江名峰(34854615) 16:02:28
你说的是产品测试跟代码级的测试不一样
江名峰(34854615) 16:03:42
关键就是闯荡说的这种现状，所以，考虑到测试的必要性，有专人负责也许是必要的
刘忠(29435460) 16:04:05
负责抓，不是负责写吧
江名峰(34854615) 16:04:57
你没给开发人员测试时间，那你为什么要抓？当然是找专人负责写了
刘忠(29435460) 16:05:03
要把单元测试提到和开发一样重的地位来，才能改变这种局面
刘忠(29435460) 16:05:38
没给是项目管理不重视的问题
燕双龙(85709616) 16:06:12
如果都没有给开发人员分配单元测试的时间，那么再分配一个专门进行单元测试人员的必要性也是打折扣的。
江名峰(34854615) 16:07:08
节省五个开发人员的测试时间，让一个人全职测试是一种解决的途径
江名峰(34854615) 16:07:34
也许是两个人
刘忠(29435460) 16:07:42
这个全职测试五个人的单元测试人员估计会疯掉，天天在公司加班，他的进度永远也敢不上开发人员
江名峰(34854615) 16:07:47
但是在GOOGLE，他们都是一对一
燕双龙(85709616) 16:07:57
其实为什么大多数项目不会安排单元测试？主要原因并不是项目经理真的不重视，而是他们认为项目的潜在风险没有那么大，也就是说项目即便出现一些BUG或者延期，他们也能够接受。所以没有必要去写单元测试来“浪费”时间。
江名峰(34854615) 16:08:33
往往是因为如此，他们才浪费了更多的时间
燕双龙(85709616) 16:08:44
如果一个项目签下合同的时候，明确的说出现一个错误杀死一个程序员。那么我想所有项目都会去写单元测试的。呵呵
江名峰(34854615) 16:09:04
那样的话，你招不到一个程序员
刘忠(29435460) 16:09:47
一对一倒是个好办法
两个人写相同的功能代码，交替写，休息的写单元测试
刘忠(29435460) 16:10:14
这种也不算配专职测试人员，但是能达到不错的效果吧
燕双龙(85709616) 16:10:16
很多人都不理解这一点，因为传统开发思路中没有单元测试这么个东西。而大部分的项目经理也都不知道什么是真正的单元测试，而且很可能他们根本就没看到过单元测试，也从来没有看到过他的好处。所以大多数人不会冒险的，因为单元测试其实耗费还是不小的。
江名峰(34854615) 16:10:23
想用自己的“强势”来管理别人，只会陷入泥潭
燕双龙(85709616) 16:11:18
双人编程应该可以解决很多类似问题。例如可以两个人进行设计和编码，然后另外一个去写单元测试，一个去写实际代码。这样代码健壮性肯定很好。呵呵
江名峰(34854615) 16:11:30
是的
燕双龙(85709616) 16:11:55
不过，最根本问题还是钱。我想大部分项目经理手下都不会有足够的人员。那么再好的想法都没法实现。
燕双龙(85709616) 16:15:01
这又回到那句话了，“财政不能独立，人格就无法独立。”一个项目经理也是如此，如果开发经费不够，人员不够。那么再好的开发模型和管理模式，也都是空谈。他最多也就是用作坊式开发去开发一个项目。
江名峰(34854615) 16:15:22
这些成本是省不了的，因为他们往往会在后期进行大强度的测试，大量的BUG会在那时集中出现，那么一样省不了钱，而且因为连锁的BUG反应增加了调试难度，要花更多的资源去查BUG。
江名峰(34854615) 16:16:37
你愿意每天搞定几个BUG，还是某天接到几千个BUG的报告要去处理？
江名峰(34854615) 16:17:23
我想信前者比较容易，后者比较痛苦
燕双龙(85709616) 16:17:42
但是从顶层来将，他们所关心的是硬性成本，很少关注隐性成本。虽然可能不采用标准 的、好的方法，可能造成系统延误或者维护费用增加。可是这些成本都是不可知的，所以高层就总也看不到这些。他们所关注的就是眼前，你每个月要支付多少工资 和奖金？每个月的水电费是多少？每个人的保险交多少？等等。这些东西每加一个人都会表面上增加很多。这些都是上层不能承担的。
江名峰(34854615) 16:18:54
郎咸平说了，国内的企业最大的弱点就是思想落后
燕双龙(85709616) 16:19:30
人员的培训费用，培养的潜在风险。这些都很难把握，这就让现在的很多软件企业都只能走作坊开发。最根本原因就是这些企业的老板都是写作坊老板而已。
江名峰(34854615) 16:22:06
适合卖包包，不适合搞软件
燕双龙(85709616) 16:24:51
其实国内很多软件开发者都是在意淫这些高超的技术。很少有人真的应用起来，这也正 是国外的优势，他们搞出一个一个的好东西，而国内总也应用不起来。搞得国内普通开发人员都变成了疯子，当年龄大了发现很多梦想和当年学习的“高超”技术无 法应用，他们就退缩了。国外希望看到我们的这一点。他们就可以趁此进一步垄断我们的基础应用。
江名峰(34854615) 16:26:45
哈哈，所以我决定在这一行继续奋斗几十年
燕双龙(85709616) 16:27:47
等待着你开发一个完全基于单元测试的项目
燕双龙(85709616) 16:29:19
不过我感觉，要从一个大学生过渡到能够理解单元测试和写出好的单元测试来，可能需要6个月到1年的培训。很多软件公司承受不了这些。
江名峰(34854615) 16:29:32
只会做有限的测试，针对那些任务复杂的对象，十分必要，小而简单的对象可以不必单元测试，平时DEBUG就可以了
燕双龙(85709616) 16:30:45
然后大学生要能够过度到写安全代码，则需要2到3年。这也很困难。所以现在软件公司也很头痛的。高手经常跑，新手上不了，死手一大堆，烂手管天下。这种现状也很恐怖。
江名峰(34854615) 16:31:16
说得真形象
燕双龙(85709616) 16:33:31
我以前讨论的时候，曾经说过，程序集中public必须写单元测试。internal的建议写单元测试，privaete的不必写单元策划四。这样最大好处就是大大减少了public对象和public方法。呵呵