TCO 即Testing Coverage Outline 测试覆盖大纲，做TCO是从测试的角度分析当前被测系统有哪些测试需求、测试要点。
一.为什么需要TCO:
在日常的工作交流（需求、方案、实现）或是在做KYM的时候，我们面临着大量的碎片化信息需要梳理。我们需要将碎片化的信息进行提炼、重组和结构化，这就是TCO的过程。（一个好的结构化的TCO也应该便于日后原始信息的还原。）在这样过程中我们就能够对被测系统、测试点做到心中有数。
二.做TCO的形式和内容：
形式上，目前用的比较多的是思维导图（脑图）,也可以是其他任何便于交流和理解的方式。
内容根据项目的上下文特点可能会有一些差异：
1.基于探索的方式学习被测系统和TCO的梳理：
对于小型项目没有规范的研发文档、甚至连方便交流的开发人员、需求人员都找不到时如何获取信息？不妨做一轮ET(探索性测试)，边测试边学习被测系统，TCO可以借鉴James Bach的HTSM（启发式的探索性测试模型）中的产品元素SFDIPOT作个模板进行梳理:
2.基于MFQ的TCO梳理：
MFQ可能更倾向于有相对健全的研发规范的团队，有着可供学习的研发文档（需求文档、设计文档等）和可以交流的DEV、BA、PO，学习文档和与人交流的过程中不断记录、提炼、重组和机构化。在邰晓梅提出的MFQ模型中:
- M即基于模型的单功能（Model based Discrete function）:
M来源于对被测对象的学习；源于KYM的产出；单功能是被拆分出来的可以被独立测试的功能单元。它可以基于流程拆分、可以功能的细化、可以是基于场景的，根据被测对象和项目的特点没有绝对的标准。
- F功能交互（Function Interaction）:
有些功能无法被独立被验证与其他功能存在依赖关系时，这样的功能是认为存在功能交互的。
（M和F有时没有绝对的界限，一个功能在LLT,比如单元测试或基层测试层可以容易的找到M，但在系统测试层面可能无法明确的拆分出单功能。）
- Q质量属性(Quality Characteristic):
指的是软件的非功能测试的相关指标，性能、可靠性、安全…..它的启发模型如下图所示：
三.关于基于MFQ的测试管理：
前端测试团队可以在LLT的层面（UT/FT、IT）更多的关注M单功能的测试，测试成本更低。而在后端ST测试中着重关注F和Q的测试。但MFQ也可以分层来做，比如并不是只有ST才能做Q，LLT同样也可能有需要关注的Q，比如一个接口的性能，一个算法函数的性能这些都更适合用 LLT的方式来进行测试。