【项目管理一点通】（41） 集成测试

很多人误以为项目经理没多少事情，很清闲，这是错误的。实际上项目经理非常累，身累心累，尤其是经验比较缺乏的项目经理，会面对很多的问题，每个问题都很棘手。部门经理只需要面对主管副总或者老板，项目经理不一样，不仅要向客户负责，还要向公司负责，主管领导负责，项目做成了，发些项目奖金，大家一起乐呵乐呵就完了，一旦项目失败，项目经理基本上就得打点行李了，所以说项目经理的职业风险还是非常高的，因此，我们如果要吃这碗饭，不仅要有扎实的功底，而且还要快速积累项目经验，同时也要磨炼自己的意志。所以我们以后不要错误的评价项目经理，这里我向我的项目经理同行们致敬！
接着回归正题，本节接着聊测试，本不打算长篇的去描述测试，无奈测试的内容太多，而且一般的项目经理对测试内容基本上不是很了解，所以有必要让他们有个初步的认识，同时，测试也是把控项目质量的重要手段，所以，适当增加一些章节描述一下测试的细节。
集成测试本质上就是联合测试，我们提到集成测试，一般都是基于模块、系统或者平台来说的，在模块组装完成后，我们做一个测试，可能需要分头编写功能的若干人进行联合调试，另外一种情况就是和第三方系统提供的接口进行联合调试。实际情况比我们想象要复杂一些，模块比较大的情况下，功能、流程都很复杂，一般会先有开发人员进行联调，这种联调就是一种白盒，然后可能需要测试人员与开发人员一起调试，这实际上黑盒白盒兼而有之，最后，才是测试人员分成几组进行调试，这种情况很常见，所以，如果执意用一种测试方式去界定测试工作，是不可取的，我们应以测试目标来界定测试工作。
我这里不去讨论集成测试的界定，只结合实际的测试场景提一些建议：
1、集成测试在实际工作中更多的是一种测试方法，是相对于单个功能接口测试而言的，由于需要测试复杂流程和复杂的接口响应，一个测试工程师是无法完成的，同时，我们需要在测试过程中模拟完整的业务场景，也需要将相关的功能测试整合到一起，形成有机的测试过程，可见，集成测试是必须要做的，模块级、系统级、平台级都需要。
2、集成测试的用例不是对功能测试用例的简单搬迁或整合，而是要做到有机，即按照实际的业务需求和完整的业务逻辑来编排。换句话说，功能测试通过了，不等于集成测试就能通过，很多边界问题都会在这里出现，很多程序员最害怕联调，一旦联调，总是如临大敌，表面上满不在乎，心里却惴惴不安。
3、集成测试工具。一般的测试软件都可以进行集成测试，但是要想做得比较好，可能需要会写自动化测试的脚本，通过脚本将业务流程完整的体现出来，这就与每个公司的测试框架有关系了，很多公司可能不具备这样的条件，那就只能人工去测试了，人工测试的话，工作量会比较大，如果再算上回归测试，工作量会让很多测试工程师出离状态了。
4、谁来测试？这是一个老话题了，实际上如果设计没问题的话，并且之前也做过业务测试了，集成测试应该不会有太多的问题，但是事与愿违，实际工作中，大量的问题出现在这个阶段，经常会出现不同模块的开发工程师互相抱怨。正因为这些特殊情况，一般情况下，可能需要测试工程师与开发工程师混合测试，然后再由测试工程师独立测试，也就是先白盒，后黑盒。但是我们一般将开发工程师参与的前期工作称之为调试，由测试工程师主导的工作才是真正的测试。两项工作不可或缺，也不要武断的杜绝开发工程师参与前期的调试（实际上在测试过程中也会存在调试现象），如果我们将其理解成测试迭代就会心安理得一些。
总之，集成测试是重要环节，贯穿了模块、系统和平台。项目经理应给予足够重视，尤其在测试用例上要评审一下，看看是否符合实际的业务逻辑。
非常感谢大家的阅读。天气炎热，大家多注意防暑降温。