集体测试
也许专业测试里讲这种方式，很可能不叫“集体测试”。因为我根据的自己的理解起了大概符合意思的名词叫集体测试“集体测试”。
这种测试模式就是，公司里所有的测试人员抱成一团儿，来一个项目，所有测试人员就集中测试一个项目。
优点：每个测试成员的思维不同，各有优缺点，可以更快更全面的找出软件中的BUG。
缺点：人力成本高、有多个项目需要测试时，只能按顺序来、同一个缺陷可能被多个测试发现（工作重复）、漏测是整个团队的责任
总的来说集体测试的缺点太多，建议使用其他的分工方式
按测试内容划分
一个项目的测试报货文档测试，易用性测试，逻辑功能测试，界面测试，配置个兼容性等多个方面。我们可以根据人员的特点为每个人员分配不用的测试内容。
优点：
1.分工明确，每位人员都清楚自己的测试的内容重点。
2.责任到位，通过漏测的缺陷就可明确是谁的责任。
按测试流程划分
我们的项目测试流程一般需要，指定测试计划，编写测试用例，执行测试用例，输出参数报告等工作，我们可以根据流程中的各个阶段来进行划分。
优点：
1.流程清晰，就想瀑布式项目开发流程，不同阶段的工作由不同的人员担任。
2.划分流程的每个阶段难易程度和所需要的技能
编写测试计划人员需要对整个项目的工作时间、资源分配、测试内容，实施过程有整体的把控能力
用例编写人员，需要对项目需求，测试方法，测试点有深入的了解
用例执行人员需要细心，使用缺陷系统，沟通，协助开发定位缺陷
输出参数报告人员需要对项目的测试过程，缺陷数量，类型，分布。用例执行情况等进行统计，也可以有测试执行人员担任
按项目模块划分
对重大型的项目，这种划分就非常必要了，项目的模块非常多，功能也非常多。不同的测试人员负责不同模块的功能测试，这样会使测试工作变得更加的清晰。
优点：
1.人员利用率高，不用的人员负责的功能不一样，就不会存在交叉与重复
2.更容易挖掘深度缺陷，假如A人员今天测试这个功能，明天测试那个功能，他就不可能对测试功能内部逻辑与业务有深入了解。找到的也只是表面的缺陷。反之那么发现深度缺陷的可能性就会增大很多，而往往深度的缺陷是致命的。
按测试类型划分
我们知道除了功能测试以外，软件在编码阶段需要单元测试，接口测试等，在系统测试阶段，为提高测试的效率，可能对某些模块进行功能自动化，我们还要考虑软件的性能、安全性等问题。z这些类型也是我们项目中常见的分类。我们可以根据这些类型为测试人员分配测试工作。当然，起专业性对测试人员的要求也比较高。
优点：
1.专业技能要求较高，在这些分类中除了手工测试要求较低，其他分类都需要较高的专业技能。例如：安全性测试需要掌握网络协议，编程技术，脚本攻击，sql注入，漏铜分析等方面的技能。
2.不同分类之间交互性低，不同的分类需要的技能不同，虽然都是“测试”工作，但一个做单元测试的人就无法让其做性能测试。
分类方法的疑问
看了这些分工方式，你是不是觉得每一种方式都似曾相识，但又没有哪个公司是单一的按照上诉某种分工方式工作。
一个长期的互联网公司，产品功能比较多，每位参赛人员负责不用的功能模块，测试人员从测试计划到测试报告都基本由一个人来完成。当然对于比较大哥晋级的版本迭代，也会多人协作对版本进行测试（协作的方式一般会将版本功能再次细分到每个测试员身上）。安全性测试由专业的安全人员指导功能测试人员对自己负责的功能进行安全撒扫描与分析。有独立的性能测试小组，对需要进行性能测试的产品版本进行性能测试。在独立的功能自动化人员，对于适合自动化的功能进行自动化工作。
一般大一点的公司都会包含了上面所有的分工方式。那么，为什么要进行上面那么单一的划分呢？这样有助于我们理清对测试工作的各种分工方式。在实际工作中，有大型项目、小型项目、有客户端软件、也有互联网产品、有短到几天的项目，也有长期的项目。有一次开发完交付的，也有不断迭代更新的。根据项目的情况，我们可以选择合适的分工方式在应用于项目中。