单元测试之组织保障 软件测试
这几天一直都在思考新项目中，如何促使公司能够最终真正使用上单元测试。前几天发的一篇《单元测试之关键问题解答 》主要写的是我在实践过程中，针对我遇到的一些非技术问题的思考。后来我看到一篇和我博文一样标题的文章《单元测试之关键问题解答》。拜读了之后，发现他对我的思考方向有些误解。虽然这样，因为这些导致他的失望，我还是表示十分的道歉。补充一下，这篇文章不错，推荐大家阅读一下。
前几天和我的微软同学聊起微软的自动化测试的时候，他向我提到了几个概念BVT(Build Verification Test)和Smoke Test，这让我注意到一个问题，TDD中并没有解决好复杂系统的全面测试问题。要知道大多数人的单元测试概念，是有KENT BECK的测试驱动开发中带来的。但是，要让单元测试完整应用起来，是需要相当的组织结构保障的。
在聊天的过程中，有一点非常值得关注，那就是微软的Software Design Engineer in Test (SDET)角色。据他讲，在微软，SDET和开发的待遇是一样的。显然，微软是非常重视测试的。
在开篇提到的另一篇同名称的文章中，也对单元测试做了诠释，而且从文章来看，他应该是一位咨询师。我这里不说其他，但从单元测试需要咨询，就说明了一个问题，单元测试不是只靠技术和理念的认识就能简单做起来的。
从很多公司的尝试未果，就可以看出，我们相对于微软这类成功应用了自动化测试的公司相比，我们并没有很好的组织保障。让公司里的开发来做测试，一来会感觉实在浪费，二来重复性工作和创造性工作的不一样，会让很多人止步。
这两年，我一直被领导困扰着。他们在思考问题的时候，总是说什么组织结构。而我却更重视技术解决问题。想想看，如果能完全靠技术解决问题，那么就不需要管理那么麻烦了。我相信很多人也会和我有同样的观点。
可是，不要忘了，单元测试的主体是人。大凡是人，就必须有管理。我这里所说的管理，不是领导的管理，而是组织结构的保障。在最近的工作过程中，我逐步意识到了保障的力量。忽视组织保障，团队的工作会变得松散而无方向;反之，大家会知道做什么会得到鼓励，做什么会得到批评。
因此，相对于大讲那些测试理论，最先要解决的是组织结构。这才是保障单元测试成功实施的重要措施。我这里主要是从推动单元测试的工作入手的。因此考虑其组织结构，可以由公司的技术高手成立，辅助项目开发。这个组织在项目相对独立，直接对项目经理负责，而不对项目进度负责。
在组织结构问题中，我重点说明一下进度和质量的问题。大家很容易明白，项目中对进度的反应是如何的强烈。事实上，由于质量的衡量标准相对比较复杂和不明确，导致质量在进度面前，经常容易被牺牲。反过来，我们现在的单元测试就是要从质量入手，因此其组织机构一定要相对独立于保障进度的组织。这样，我们的工作才容易进行下去。
以前单元测试往往是开发的Leader提出来的，但是，Leader往往需要对进度负责，单单从这点来看，单元测试往往会以失败告终是不足为怪的。
在建立了单元测试机构之后，就是建立测试流程规范。在推广初期，并不一定需要建立完备的流程。只需要考虑好几个关键点，让单元测试工作起来。好多机制就是越转越好!否则，再完备的机制也容易因为磨合不好而最终失败。
重要的是，建立单元测试报告的优先处理机制。对于单元测试的失败，应该有考核机制来保障必须在第一时间得到处理。在初期，细节的处理，并没有那些测试理论中讲得那么重要。关键要与你的现有组织磨合顺利。
等到你的项目中的单元测试成功运作之后，再重新考虑如何优化流程。流程和组织一般来说是相辅相成的。可能在优化流程的时候，再修改组织结构。
文章来源于领测软件测试网 https://www.ltesting.net/
