简单来说，就是先要明确谁在什么时间做完什么，然后，在出现异常时，进行调整。
当然，这个交付目标的达成需要很多支持。
首先，要明确做什么，根据我们的策略定义测试范围，比较粗略的分类，可能会有单元测试、集成测试、系统测试，以及辅助性的文档、报告、评审之类的工作。这些内容之间可能会有依赖关系和前后次序等。同时，也要识别出责任人，根据我的项目经验，没有明确到具体的人的任务99%会延期。
接下来，要确认资源（Resource），这里包括人员和设备及样品，再细分还要看人员是否充足与人员能力是否足够、设备及样品是否充足和可用。比如，可能考虑到软件测试工程师、系统测试工程师、具备特殊测试能力的专家，以及台架、ECU、线束、CAN工具、诊断仪、示波器等等。当这些有问题时，就需要管理人员进行调配。
对于执行人而言，会提出工作包的完成时间（Duration），这个也是经常在测试人员和管理人员之间针锋相对的地方，测试人员希望As long as possible，管理人员希望As soon as possible。就看实际工作中，如何论战和平衡了。
如果成本管控比较好的公司，还会考虑成本（Cost），一般包含人员工时和材料成本。特别是涉及到第三方公司或其他独立结算团队时。
对于项目经理而言，最关心的是完成的截止时间及监控，也就是催催催。根据整个项目的进度和前面的一些梳理，就可以得到详细的计划。至于所需的详细程度，取决于产品的复杂性和所涉及的测试人员的数量等。
然而，出问题和延期几乎是必然的，基本没有哪一个项目能够完全避免，解决这些问题也是管理人员最主要的任务了。或拿出自己的Buffer，或减少测试，或调整优先级，或谈判，或带风险并行，或升级管理层支持。
整个管理过程会有不同的工具支持、流程部署、模式风格，暂不详述，各有各的做法。
这里给一个我所见到的众多做法中做得比较严谨的案例。
简单思路是，在测试之初，定义一张完整的测试全量计划表，这里面包含系统、软件、硬件、结构等所有的测试条目，以及每个条目测试与否、不测试的分析理由、通过与否、对应缺陷和报告链接等。由项目经理或测试经理作为总负责人，组织相关人员进行测试范围识别、测试计划排定、测试进度跟踪、测试报告提交完善等。每次迭代都对应这样一份统一的测试汇总表，通过这种方式可以系统地将测试管理起来。
3、测试过程
上面的阐述都属于规划管理性质，下面开始进入具体操作层面。
测试的分类方法有很多种，比如：
按照测试时序，可以把整体的测试过程分为需求分析、测试计划、测试设计、测试环境搭建、测试执行、测试报告这几大部分。
按照测试类型，可以分为功能测试、性能测试、负载测试、压力测试、冒烟测试、安全性测试、兼容性测试等。
按照是否执行程序，可以分为静态测试和动态测试。
按照对软件内部信息的了解程度，可以分为黑盒测试、白盒测试、灰盒测试。
按照测试层次呢，又可以分为单元测试、软件集成测试、软件需求测试、系统集成测试、系统测试、验收测试这几大部分。
从另外一个工程应用的思路，我们将测试层次还能做一个整合，单元测试、集成测试都属于“设计”层（Technical），软件需求测试和系统测试属于“功能”层（Functional），而验收测试属于“方案”或“问题解决”层（Solution）。
五花八门，不一而足。
粗略来看，从测试层次的角度，基本也能够覆盖到其他分类的内容。为了理解起来比较清晰，而且业内讲得非常多的V模型或ASPICE也是按照层次来划分的，所以我们着重从测试层次逐一铺展开。
3.1 单元测试
单元测试是软件验证的最低级别，是对软件的最小可测单元进行验证的工作。
但如何定义单元一直是争论的焦点，通常我们会说是一个函数，可有的函数代码段很短，这样去做又会显得很浪费，经常也会将单元异化为具有独立功能的组件。
总之，单元是一个人为定义的最小测试点，去针对软件的详细设计（即代码）来进行的，一般是开发自己去完成的。
测试方法会有静态代码分析，如熟知的基于MISRA C规范的静态代码扫描，或者关注代码覆盖率的测试，如语句覆盖率、分支覆盖率、MC/DC覆盖度等。
在这个阶段之后，软件组件可以被集成了。
3.2 软件及系统集成测试
软件集成测试的目的是为集成的软件组件与软件架构的一致性提供证据，包括组件之间的接口。
测试的内容可能包括通过接口的数据是否丢失、组件组合后能否达到预期父功能以及一个组件是否会对其他组件造成影响等。
此外，非功能的测试会涉及到CPU负载率、内存占有率等资源消耗的内容。
在测试思路的选择上，一般有两类：增量式和非增量式，主要差别在于是一次性集成完毕后一次性测试，还是边集成边测试。前者容易造成大量缺陷报出而难以定位原因的问题，而且修改过程也会不断引入新问题，造成混乱。
系统集成测试呢，是沿着HW/SW的接口进行的，通过物理引脚（物理层）和逻辑协议（逻辑层）连接的HW/SW接口构成系统内部接口。
因此，系统集成的先决条件是已经集成的软件和硬件。从技术上讲，系统集成只需根据BOM在硬件上刷新软件即可。这和软件集成过程中功能集成是逐步进行的有些不同。
尽管理论上，软件集成测试是侧重于软件模块之间的接口的，系统集成测试是着眼于软硬件之间的接口的，但是系统不会单独悬浮于软件和硬件之上，硬件需要软件驱动，软件也需要运行在硬件上，所以系统集成测试的用例往往来源于软件或硬件各自的测试，有时也会来源于系统测试。
此外，还可以提的一点是，系统可以分几个层级的，比如，ECU能作为一级系统，ECU加传感部件能作为二级系统，ECU加传感部件再加执行部件能作为三级系统，三级系统集成于整车环境里还能被定义为四级系统。
宏观来讲，系统集成测试需要考虑到这所有的系统及对应接口，只不过越往上走，就越不是单一的软件范畴了。
3.3 软件及系统需求测试
软件需求测试，顾名思义，就是为在芯片上运行的集成软件符合软件需求提供证据，证明软件功能满足需求。
系统需求测试呢，习惯被简称为系统测试，也是类似，是确保测试集成系统，以提供符合系统需求的证据，并确保系统已准备好交付。
与软件需求测试的差别，主要是系统需求测试要在集成软件、标定、硬件、外设设备、数据乃至人员的系统下进行的，这也是最常见的最终交付前的测试。
测试内容上，主要是针对需求、风险、特定用例或其他高层级系统行为的描述进行的功能测试与非功能测试（如性能、负载、压力、可靠性、鲁棒性、恢复性、安全性、兼容性等各类测试）。