先交代一下写作背景：这二年在软件项目中非常流行一个词——敏捷。大大小小的项目，通常都打着敏捷的旗号招摇过市，有自我感觉良好的，有感觉很坑爹的，也有更多的公司是为了利益，披着敏捷的外衣，却做着浮躁的事。其实我觉得敏捷本身是一种很好的思想，是当软件工程发展到一定阶段后必然出现的事。面对风云变幻的市场，谁都想自己身手矫健，迅速响应市场或客户的变化。但如何真正在项目中做到敏捷，却不是想得那么容易，除了方法论之外，还有各种外部条件的制约。而现实是很多研发团队只注重了方法论的学习，而没注意组织结构应该如何变化才能适应敏捷测试的需要。就像人类的进化史一样，大脑在逐渐变得发达和更加善于思考，但如果手脚不能进化到可以独立行走，把双手解放出来劳动，那人类根本也就走不到今天。有的童鞋可能又想说了，敏捷强调的不是人人都应该是开发和测试吗？OK，我不反对，但我们不是活在童话世界中，你的理想有多丰满，现实就有多骨感。在真实项目中，肯定还是存在测试和开发的分工的。所以本文想谈谈在敏捷测试中，我们的测试组织应该如何建设，才能合理将工作进行分工，充分发挥组织内部每个人的长处。再说直白点就是，在敏捷测试环境中，我们应该用什么样的人，去做什么样的事，才能获得最大的效率。

　　当考虑团队的组织结构的时候离不开两点考虑：要做什么事和要什么样的人去做这些事。其实很多人对敏捷测试并不太熟悉，甚至不知道谈到敏捷测试，我们究竟指的是哪些测试，要怎么做才能使测试敏捷起来。所以我们先来看看第一个问题：要做什么事，也就是说当我们谈到敏捷测试时，我们究竟谈了些什么。

　　在一本比较著名的讲敏捷测试实践的书《A Practical Guide for Testers and Agile Teams》中，明确将敏捷测试的所有测试类型划分为了四个象限的测试，按照测试内容来分，可以主要分为面向技术（Technology-Facing）和面向业务（Business-Facing）的测试。在面向技术的测试中，主要包括我们熟悉的Unit/Component测试，PSR（Performance， Security， Reliability）测试，Usability测试等等。而在面向业务的测试中，主要包括手动的探索性测试，User-story和系统测试，以及自动化的BAT和回归测试等等。由于这里所讲的测试类型的特点都会跟什么样的人去做有很大的联系，所以在接下来的部分我再详细讨论各种测试的特点。

　　OK，知道了敏捷测试究竟在做什么，也就是它所指的范围（Scope）之后，我们接下来就可以根据所要做的这些事的特点，再去甄选合适的人去完成它。这里需要注意的一个原则是：尽量发挥每个人的特长，让专业的人去做专业的事，杀鸡用牛刀或者杀牛用匕首都是不可取的。我先给出具体的组织架构图，再来看看为什么安排这些人去做这些事。

　　先来看看面向技术的测试。为什么是面向技术呢？因为这些测试类型都是需要深入到代码级或者是需要工具去实现的，而且跟具体的业务逻辑和业务流程关系不大。

　　Unit/Component测试（负责人：开发人员）

　　这部分的测试应该由开发人员自己去完成。原因很简单，谁最清楚代码的结构和代码逻辑？开发人员。我们完全不必专门安排所谓的白盒测试或者单元测试工程师去帮开发去完成这些事，这些是他们应该完成的事，往大了说就是每个人都应该为质量负责。而且，特别是在测试驱动开发的模式中，我们更是绝对不能让测试人员越俎代庖地去做这些事，那样做是得不偿失的。因为如果不是由开发人员自己去写的测试代码，那么到时出了错，要想debug或者是找rootcause的话，将会花费更多的代价。所以记住在测试驱动开发模式下，开发和测试那块根本就没测试人员什么事，作为测试人员大可不必想着一定要读懂代码才牛，从老板或者是组织管理者的角度看的，那简直就是浪费钱，测试人员应该做的是，如何更好地帮助开发去理解需求，也就是敏捷中常说的user-story，以及如何设计测试来验证产品是否真正完成了这个user-story，接下来面向业务的测试中还会说到这点。

　　PSR以及各种“ility”测试（负责人：相关测试类型专家）

　　性能、安全性以及各种用户体验啊，易用性健壮性测试对产品的重要性不言而喻，而这些测试类型往往又是非常专业的，复杂性程度相当高。要想做好，不仅仅是会用一点工具，会录制下脚本，或者是懂看代码就能实现的。它要求测试人员不仅对工具使用非常娴熟，更重要的是要深入了解系统架构以及系统所运行环境的具体情况，如桌面程序，在安全性方面往往跟系统本身的安全性紧密相关，要求测试的人对所在的系统也要了如指掌，web程序，性能瓶颈更是跟系统软硬件，所用协议等密切相关，没有对这些相关方面有系统地把握和学习，根本做不好。所以如果是组织内部有条件，可以由专门做这些非功能性系统测试的专家或者资深工程师负责这些类型的测试，才能得到比较理想的测试效果，不然最大的可能性就是走走过场而已，得不到实际的效果。

　　再来看看面向业务的测试。面向业务的测试是大部分测试人员所熟悉和了解的，但测试工程师也有好几种类型，初级的，高级的，做自动化的，做手动的，该如何按照不同的测试类型来进行分配？

Tags：数控编程培训,plc编程培训,计算机编程课程,asp软件下载,网络编程课程设计,三坐标编程培训