测试活动的本质是给项目提供产品质量信心的依据，那么如何做到在有限的时间内完成什么样的测试才能给予信心那？
第一步在做测试设计之前要去了解围绕着被测对象(功能)的产品，用户，用户使用场景，开发项目的人员(包括测试人员)，和最后交付物的信息，输出本次测试任务的测试环境，测试时间，测试范围，测试点和发布版本。
第二步 根据测试范围梳理测试覆盖大纲，使用结构化的信息图进行梳理。主要由3部分组成:1单功能测试设计分析与测试设计,2功能交互测试分析与设计，3质量属性测试分析与设计。
如何划分单功能?根据当前被测试对象或者需求，基于对当前风险大小的识别，选择合适的粒度。举例需求是性能查询，对于性能查询它的单功能是普通查询，分组查询和复杂查询。由于复杂查询功能复杂性导致它风险比较高和容易出问题，还需要对复杂查询再进行划分。
功能交互是比单功能更复杂的场景测试，可能出现无穷多个，选择优先级比较高的场景进行验证。这里有一个小技巧，使用表格法梳理出与单功能交互的其他常见的功能。
针对质量属性测试，根据产品的特点找到常用的质量属性，比如我所在的产品对于1浏览器兼容性 2 大数据量下的性能 3产品的安全性 4 产品的可靠性 5产品的易用性。
第三步 对单功能进行建模
对单功能做测试分析，根据单功能特点选择不同的建模方式(流程图，状态图，判定表等)
刚好收到一个测试任务是测试一个组件切换数据库的任务。接受任务后首先想去了解数据库信息，但是被告知组件是一句代码都没有变动，是底层接口有变动，然后主动找开发经理沟通需要测试什么，经理与我把需要测试的功能梳理了一遍，在与经理梳理的过程中发现其实测试点有1数据存入和读出的正确性 2特殊数据的排序正确性 3查询语句的拼接的正确性 (获取了测试点)。
到了下午想通过脑图根据开发经理说的测试功能梳理测试内容，在梳理过程中突然灵光一线，本次测试内容的重心实际是数据库的表，应该根据表的内容来做具体的功能测试。分析完有什么表每张表存储的内容是什么后我发现开发经理给我讲的测试功能是有遗漏的，事实证明分析表的做法是正确的。(得出了所有的测试内容)
到了下午4点半，参加测试cop活动，把我本次的收获分享给大家，在分享的过程中发现，因为本次测试需求实际只改了对表操作的方法，如果有相似表结构的表，那么实际只需要测试一个就可以了。
收获:动手测试之前多问几个问题，分析挖掘出本次需求改动的本质，然后找出测试点（操作表）和测试内容(组件的10几张表)。
第二天找到底层的开发人员与他确认测试点，又增加了创建表的测试点，既然有创建表那就有删除表，但是底层开发人员表明没有删除接口，因为之前的数据库就没有提供删除接口，我又咨询了应用团队的开发经理他说之前的数据库的表如果数据和索引删除掉后表会被自动删除，我把这个信息提供给了底层开发人员，结果他发现之前的这个数据库自动删除表的代码实际上是代码封装好的，但是他没有做这个封装。也就是说通过本次沟通，我在没有测试之前已经发现了一个大故障，为自己点赞。(这里隐含了一个信息，数据库接口底层开发人员有变化，不是同一个人，这个故障实际就是人员变动带来的。）
相似的表测试一种，也与应用的开发经理确认，可以这样做，那么测试工作量直接就减半了。
收获：直接收获是没有测试通过分析就发现了一个故障，并且通过分析测试工作量直接减半。其他收获是有变动的东西就有风险，通过做测试分析让我感受到了测试之前心中有数的自信。
继续深挖本次需求的测试，换数据库的测试点其实就是表的增删查改，而查又包括了sql语句的拼接和查询返回结果的排序。这样就形成了一种类型的测试点模板，下次再遇到类似换数据库的测试，直接使用该测试点模板就可以了。
