见图记录-驱动设计文档编写

见图记录总结，驱动设计相关文档编写。

一、概念

    整个产品的开发流程，一般大致分为 需求分解、系统设计、接口设计、详细设计、编码调试、测试验收。其中 作为驱动模块开发的模块责任人，有三个文档时非常关键的：场景分解文档、详细设计文档、测试用例文档。（接口定义当然也非常关键，但这其中内容相对较少，此总结省去）

二、内容讲解

1、场景分解文档

    （1）定位：从驱动模块的角度、分析有哪些系统场景落到了自己的模块中、描述清楚这些场景，澄清这些系统场景中各个驱动模块的角色职责/数据流/调用流。目的是加深对业务场景的理解，弄清客户真实需求对场景的关键约束，整理清楚各个相关模块的业务划分，调用流数据流。 

    （2）输入：系统规格到每个模块的业务划分、系统设计对各个模块的定位、针对每个场景各个模块澄清各自约束选择合理系统方案，在这个过程中有许多交互关系需要和相关模块对齐，特别注意整个方案调用流和数据流设计是否合理（不需要到数据结构或者接口定义这些细节），存在什么约束，应对未来可能的需求扩展性如何。

    （3）内容：一般的写法，针对每个自己模块能看到的场景进行分析。每个场景应该包含：1、场景描述：描述清楚客户的使用场景和关注的特性（如 延时、平滑切换、XX特性支持等特殊需求），描述 产品在方案 上是否有其他约束 如 对XXX进行 用户态库保护。2、场景规格：描述整个场景 针对 输入、输出、控制信息、切换到其他场景行为的 使用范围及约束。 3、场景分解：使用框图方式 描述清楚 场景中相关模块的 数据流、控制流，同时描述清楚每个模块的责任划分。

2、详细设计文档

    （1）定位：在规格分解、接口定义完成后，详细设计文档用于描述内部 分层 分模块设计，描述规格的具体实现方案，用于指导开发流程。

    （2）输入：场景分解问文档，接口定位文档，硬件的逻辑功能，在这个过程要解决的关键问题就是如何抽象硬件，硬件是不停的演进的，方案也在引导硬件演进方向，一个合理的硬件抽象过程，能要使用更合理，使用约束更少。

    （3）内容：主要需要描述清楚以下几方面：1、设计编码约束：（软）软件编程规范、开发标准；（硬）代码size、内存size、堆栈size；（产品策略）开发平台、前后兼容性要求、编译配置支持。  2、运行时许说明： 使用UML图画出每个场景时序流程、加以简易说明。 3、分层分模块设计：层次一 驱动模块在系统中的层次 关系、和哪些模块由交互、各种承担的角色功能划分。层次二 驱动模块内部模块划分 如接口/策略/组件/逻辑封装层。 层次三 针对复杂的内部模块进行划分。 4、关键设计：对一些相对复杂的子模块设计 或者 算法设计，配合流程图加以重点说明。 5、可靠性设计： 说明 一些并发资源保护、异常流程保护 的设计  6、可维可测设计  7、性能设计 最小cpu、最小内存、最低延时时间（线程设计、接口耗时、中断耗时是否合理、调用方式数据是否及时）

3、测试用例文档

    （1）定位：描述驱动模块 如何用例设计，澄清测试方法和覆盖范围，支持指导用例开发和测试工作。（要注意用例集成，当后期维护过程，发现用例设计遗漏一定要及时添加）

    （2）输入：1、测试策略制定：在系统设计阶段，产品需要制定整个产品的测试策略，比如覆盖率、测试重点规格、测试环境平台，在这个基础上模块责任人需要设计自身模块的测试策略，同时要结合自身模块特性、规格复杂度、新增和变动的部分进行补充调整。 2、测试用例分解：测试用例都是从规格出发分解而来，每一条规格必须要有对应的测试用例 保证覆盖完整，如果这个规格能打桩自测不依赖外部模块 还是建议自测，消除外部依赖，如果无法做只能进行集成测试用例设计。 3、测试输入选择：当实现规格的接口定义完成后，规格测试过程也要对接口要进行详细的入参和调用流程测试，测试要考考 异常值/边界值/典型值，异常流程/正常流程 的测试覆盖，特别注意异常流程的资源回收，同时注意接口压力测试用例设计。4、测试自动化：在用例设计初期一定要考虑自动化，提升自动化覆盖率。

    （3）内容：每个用例 一般包括：1、用例名称、用例编号 2、用例描述（测试的什么规格 或者 什么借口） 3、测试条件（用例执行前 对环境有什么预置条件）  5、测试输入&&步骤（简单描述用例是怎么测试的、XX异常输入、XXX异常流程） 5、测试输出（测试步骤的预期，如XXX返回失败、XXX成功）