了解你的被测系统（why？）
一如既往的，你会想到在一个测试之前，你需要做测试计划，你需要做测试策略、方案。但在这之前你首先要了解你的被测系统。
这里讲的被测系统不仅仅指的软、硬件系统自身。你还需要理解系统所处的上下文环境这包括：所有干系人，项目周期，相关文档（过程文档，技术文档），部署，相关技术，商务合同，历史信息，业务知识，法务、文化相关的东西。
获取的信息越多，越有助于我们做出正确的判断。上述信息都相当重要，有时候会影响到系统集成测试的成败，甚至项目的成败。下面举2个例子：
1.某电信项目的总包商对某个分包商拿到的子系统业务的复杂度认识不足，签署的项目主计划中确定在项目较晚阶段才开始做集成测试，结果发现大量问题，造成项目延期5个月。而合同中项目逾期的赔款规定让总包商没有赚到利润。
2.某大型项目（系统升级类型），在集成测试团队花费了很多精力梳理业务场景（BPS）后，一名业务分析师发现：有一份非常好的业务场景定义文档静静的躺在配置管理库的历史文档区，这份文档几乎可以直接被拿来使用。这时候，几十个人月已经被浪费了。
3.某大型项目，在集成测试进行过半后，得到一个消息，某个测试过的主业务场景，这令工作了几个星期的测试人员十分沮丧。而造成这一切的是因为一次变更会议，测试经理没有参加，也没有得到相应的邮件或者其它形式的变更通知（我们当然要责怪项目管理的不堪，但没有及时获取变更也是浪费造成的主要原因）。
有人肯定要问了，这些信息都要掌握？岂不是头都要爆了？上述的信息量肯定会让一个测试经理头大，但，这就是他的工作。负责集成测试的测试经理50%以上的时间应该方法信息的获取与分析上。你也许要说：如果严格依照软件工程，测试经理根本不用那么费劲就能获取这些信息。我只能说这么想图样图森破，或者你是神仙。在我和我认识的所有测试经理经历过的系统集成测试案例中，过程非常顺畅，结果非常成功的不足1%，也许不足0.1%。涉及的干系人越多，干系方越多，问题也就越多，有时候是指数级增长。这些不都是测试经理能够搞定的，但没有非常好的信息获取能力，分析能力，没有很强的管理协调能力，是很难做好系统集成测试的。
了解你的被测系统（how？）
那怎么能有效获取这些信息呢？下面我给出一些常用建议：
1.尽量参加所有项目相关的重要会议，这些会议会确定很多重要的事情：项目范围，周期，投入，干系人职责。这些都对你后续工作带来直接影响；如果你级别不够，尽量争取，或者让你的上级或者干系人同步给你相关信息；依靠配置管理工具获取这些会议的纪要；保存重要相关邮件，并纳入配置管理（如果你维护测试相关的配置管理）。
2.获取风险信息，并管理风险。具体的方法论可以参考James Bach这篇文章，里边给出了非常好的方法论（不仅仅是获取信息，还有怎样利用风险进行测试，如何管理风险）：http://www.satisfice.com/articles/hrbt.pdf
3.配置管理！配置管理！配置管理！重要过程文档基线化，重要文档基线化（需求，涉及，测试用例等），尽量让干系人使用一套配置管理系统。
4.干系人访谈：这里的干系人可能包含一切有利于你工作的人，子系统测试经理，子系统项目经理，总体项目负责人，最终用户，业务分析师等等。一个建议是：从风险问起，让他们从自己的角度谈谈项目的最大风险是什么（有可能非常有启发性）。
5.尽早进行文档收集与梳理，对你最重要的文档有：系统总体的需求、总体技术架构（可能以概要，主要功能点描述之类的非正式文档出现，很多时候你拿不到提纲挈领的东西），业务场景分析（如果是业务密集系统），各子系统测试用例（可以复用），测试报告（帮助你分析风险及测试深度）