这几天一直都在思考新项目中，如何促使公司能够最终真正使用上单元测试。前几天发的一篇《单元测试之关键问题解答 》主要写的是我在实践过程中，针对我遇到的一些非技术问题的思考。后来我看到一篇和我博文一样标题的文章《单元测试之关键问题解答》。拜读了之后，发现他对我的思考方向有些误解。虽然这样，因为这些导致他的失望，我还是表示十分的道歉。补充一下，这篇文章不错，推荐大家阅读一下。

前几天和我的微软同学聊起微软的自动化测试的时候，他向我提到了几个概念BVT(Build Verification Test)和Smoke Test，这让我注意到一个问题，TDD中并没有解决好复杂系统的全面测试问题。要知道大多数人的单元测试概念，是有KENT BECK的测试驱动开发中带来的。但是，要让单元测试完整应用起来，是需要相当的组织结构保障的。

在聊天的过程中，有一点非常值得关注，那就是微软的Software Design Engineer in Test (SDET)角色。据他讲，在微软，SDET和开发的待遇是一样的。显然，微软是非常重视测试的。

在开篇提到的另一篇同名称的文章中，也对单元测试做了诠释，而且从文章来看，他应该是一位咨询师。我这里不说其他，但从单元测试需要咨询，就说明了一个问题，单元测试不是只靠技术和理念的认识就能简单做起来的。

从很多公司的尝试未果，就可以看出，我们相对于微软这类成功应用了自动化测试的公司相比，我们并没有很好的组织保障。让公司里的开发来做测试，一来会感觉实在浪费，二来重复性工作和创造性工作的不一样，会让很多人止步。

这两年，我一直被领导困扰着。他们在思考问题的时候，总是说什么组织结构。而我却更重视技术解决问题。想想看，如果能完全靠技术解决问题，那么就不需要管理那么麻烦了。我相信很多人也会和我有同样的观点。

可是，不要忘了，单元测试的主体是人。大凡是人，就必须有管理。我这里所说的管理，不是领导的管理，而是组织结构的保障。在最近的工作过程中，我逐步意识到了保障的力量。忽视组织保障，团队的工作会变得松散而无方向；反之，大家会知道做什么会得到鼓励，做什么会得到批评。

因此，相对于大讲那些测试理论，最先要解决的是组织结构。这才是保障单元测试成功实施的重要措施。我这里主要是从推动单元测试的工作入手的。因此考虑其组织结构，可以由公司的技术高手成立，辅助项目开发。这个组织在项目相对独立，直接对项目经理负责，而不对项目进度负责。

在组织结构问题中，我重点说明一下进度和质量的问题。大家很容易明白，项目中对进度的反应是如何的强烈。事实上，由于质量的衡量标准相对比较复杂和不明确，导致质量在进度面前，经常容易被牺牲。反过来，我们现在的单元测试就是要从质量入手，因此其组织机构一定要相对独立于保障进度的组织。这样，我们的工作才容易进行下去。

以前单元测试往往是开发的Leader提出来的，但是，Leader往往需要对进度负责，单单从这点来看，单元测试往往会以失败告终是不足为怪的。

在建立了单元测试机构之后，就是建立测试流程规范。在推广初期，并不一定需要建立完备的流程。只需要考虑好几个关键点，让单元测试工作起来。好多机制就是越转越好！否则，再完备的机制也容易因为磨合不好而最终失败。

重要的是，建立单元测试报告的优先处理机制。对于单元测试的失败，应该有考核机制来保障必须在第一时间得到处理。在初期，细节的处理，并没有那些测试理论中讲得那么重要。关键要与你的现有组织磨合顺利。

等到你的项目中的单元测试成功运作之后，再重新考虑如何优化流程。流程和组织一般来说是相辅相成的。可能在优化流程的时候，再修改组织结构。

关于微软如何进行自动化测试，推荐大家阅读我整理转载的《微软的软件测试方法》。

评论

#   wlh80 发表于2007-05-08 11:27:56  IP: 61.144.62.*

"对于大讲那些测试理论，最先要解决的是组织结构。这才是保障单元测试成功实施的重要措施" 前辈的这句话我十分赞同，我也是做软件测试，苦于无法开展单元测试，测试工作的进展一直十分缓慢，虽然领导也强调需要改善，但要从组织结构上进行改动又不是我们普通职员能够做的，我们能够有一些想法，但末上升到把握全局的地步，顶多只能算是一个房间的装修工人，而不能做为一个大厦的设计师。此种情况下不知如何是好呀！ 希望可以与前辈多多交流学习：wlhhhh@sina.com

#   xiammy 发表于2007-05-08 12:48:30  IP: 59.108.103.*

to wlh80:对于开拓类任务（就如单元测试一样），推动起来确实非常不容易。对于这类事，我不能够告诉你如何去做，但是有一句话可以送给你：To Be, To Do。正如你说的，你现在不是以为大厦的设计师，但是你现在应该把自己当成设计师去考虑问题，去和领导交流，去推动事情发展。否则，你只能感慨自己的能力有限。

#   xiammy 发表于2007-05-08 12:50:36  IP: 59.108.103.*

一起共勉吧

#   soloecho 发表于2007-05-08 16:54:40  IP: 207.46.50.*

我感觉单元测试的工作取决于PM的要求和权利。TEST LEAD是否有足够的技术资源和人力资源进行单元测试，才是问题的核心.而DEV LEAD 很有可能不太想单元测试，也许想整合后全部交给TEST TEAM去测试呢？（比如项目时间很紧的时候）。我在做ms的外包，测试的方式有一定的灵活性。我只是一个小dev,我的单元测试都是自己写了demo code，交给和我关系好的tester，让他们在空闲时间帮我测。经常能发现很严重的bug呢.....现在的tester普遍能力有限制，编程能力薄弱啊..

#   1073X 发表于2007-05-19 10:51:31  IP: 222.209.223.*

>>让公司里的开发来做测试，一来会感觉实在浪费，二来重复性工作和创造性工作的不一样，会让很多人止步。 >>我这里主要是从推动单元测试的工作入手的。因此考虑其组织结构，可以由公司的技术高手成立，辅助项目开发。这个组织在项目相对独立，直接对项目经理负责，而不对项目进度负责。 **你这两点提的没啥意义。你以为找帮黑衣人就可以把单元测试作好吗？试问除了progromer自己还有谁更了解自己写的代码。所谓高手在这种情况下也要打个折扣。 >>TDD中并没有解决好复杂系统的全面测试问题 **TDD为何不可以解决复杂系统的全面测试的问题？Kent Beck自己都说过TDD中的Unitest与通常意义上的单元测试不同，个人以为是与XP中验收测试对应的说法。TDD中的测试用例不仅测试独立的函数，也可以测试函数的组合。

#   xiammy 发表于2007-05-19 12:01:36  IP: 221.216.20.*

to 1073: 你说的非常对，可是我们应该考虑推广一项技术或方法，和正常使用一个方法是不一样的。高手的加入，是为了保障推广的效果，一旦推广开，项目中的实施工作就简单多了。 另外，我在说TDD没有解决问题的时候，重点在于说明，TDD思想没有在这方面细化。而不是否定TDD本身的作用。毕竟方法的有效性和实践的有效性，还是需要验证的。

#   1073X 发表于2007-05-21 09:11:39  IP: 222.212.141.*

我不同意你关于组织高手进行单元测试的策略，是我认为这样很容易会在公司内部形成一个新的特权阶层。他们很可能不能发挥相应的作用，但拥有左右一个普通程序员工作绩效的权利。这不是一个好办法。我倒认为强迫程序员进行TDD是不错的选择。以我自己的经历来说，我开始实践TDD并不是因为吹的神乎其神的XP，而是因为我厌烦那些没有水品的测试人员在一旁指手画脚。不过话说回来，也许黑衣人团队也可以起到与不合格的测试人员同样的效果。 我不太理解你所说的“TDD思想没有在这些方面细化”指的是什么。测试是获取反馈的一种方式，除此之外它还有什么其他的本质特性吗？至于这种反馈意味着什么，还是需要进行分析才可以得出结论。个人认为如果没有测试技术和分析技术，TDD是无法发挥它的全部功效的。程序员往往在不缺乏后者，但是往往不注重前者。

#   xiammy 发表于2007-05-21 14:54:17  IP: 59.108.103.*

to 1073X:非常感谢你再一次贡献你的想法。 关于高手进行单元测试，我的意思是指单元测试在公司初步推广阶段，在后期，应该按照你的方式进行，因为这就是工作的一部分。 TDD细化的想法，我其实更是指在组织结构中如何实施的问题。在Kent的书中，重点描述的是TDD如何实现，但是没有具体考虑组织中的实施方案。说的白一点就是现在很火的“咨询”部分。所谓咨询，就是要将公司的现有状况和TDD思想融合在一起而要做的努力

#   1073X 发表于2007-05-21 16:13:25  IP: 222.209.223.*

或许你可以告诉你的Programer，为了让tester都下课，我们自己来作测试。一家之言，仅供参考，我坚持程序员的测试比专职的测试人员更有效率。

来自：http://blog.csdn.net/xiammy/archive/2007/05/04/1595863.aspx

分类： 软件测试 软件工程