对于很多人来说，工作中往往会忽略一个很重要的环节，那就是总结。一项任务不管当时完成的好与坏，过去了好像就过去了，很少有人专门去思考，做好了为什么做的好，没做好又为什么没做好，而好不容易总结了一次，往往又是迫于上司的要求。不管是一个人还是一个团队，要想持续的做好一件事，做好一个项目，善于总结得失，总结经验，绝对是一个必不可少的环节。
很多人写总结的时候其实最大的问题是不知道写什么，不知道有什么可总结的，迫于要求的总结往往流于形式，没有什么实际价值。我们经常说总结得失，其实这句话严格来说是有问题的，总结并不是仅仅总结得失，汇报才说得失，总结一定是说自己或者团队，遇到了什么问题，采用了什么方法，结果怎样，这个方法是好是坏，是否可以再改进、复用或者推广。
对于测试来说总结尤其重要，因为大部分情况下，我们做的是重复性极高的工作，不管是测某个功能，还是制定某个计划。比如一个功能在不同的版本下很可能要重复测试，可能是有优化或者相关功能的改动，但基础要测试的那部分内容一点都没变，所以测试的时候很可能使用的是同一份测试用例。再说不同的项目可能都有聊天系统，针对A项目写的聊天系统的测试用例，很多时候大部分逻辑功能的测试点其实可以沿用到B项目。如果我们把这些可复用的测试点、测试经验总结储备下来，以供多项目使用，就省去了很多不必要的重复工作，即节省了时间又提高了效率。
所以不管是个人还是团队，平常一定要善于总结形成自己的知识经验库，以备遇到同类问题时复用，下面我列举一些常用储备项。
一、用例库的储备
可以说用例是测试行走江湖的最基本装备，一份好的用例不仅可以在同一个项目反复使用，而且在别的项目也很有参考价值，所以不管是个人还是团队，都要把用例系统的储备起来，形成自己强大的可以迅速高效测试任何系统的储备知识。
用例总的来说可以分为四大类，逻辑功能用例、内容用例、冒烟用例、通用用例。
1、逻辑功能用例
逻辑功能测试用例指的是随着项目的开展，每一个新的系统功能被设计开发出来时测试设计的测试用例，功能用例侧重于逻辑实现层面，包含大量的异常测试，比如某个游戏的好友系统玩家最多可以添加200个好友，当我们测试这个200个上限的逻辑功能时，不需要按照他实际的需求去真的给测试帐号添加200个好友，通常在技术的代码实现里200这个值是可以修改的，我们测试的时候只要把他改成一个比较小的值，比如2（玩家最多只能添加2个好友）这样只需要测试1、2、3三个很小的边界值即可。
理想情况下逻辑功能测试只需要测试一遍全部测试项通过即可，但实际上某个功能开发制作出来后往往需要大量的反复修改优化，所以对应的逻辑功能点除了要测试修改部分后，还要经常测试相关联的功能块，这时候维护好一份功能用例，用于重复测试就变得很有意义。
2、内容用例
内容用例指的是在保证逻辑功能没有问题的情况下，对于特定配置玩法的测试，就拿上面例子中的好友上限来说，当已经保证上限这个功能没问题的时候，如果设计需求是100或者200，我们只需要在游戏中核对好友列表客户端显示出来的值是否是100或者200即可。不过通常来说不是所有的游戏系统都需要设计内容用例，只有一些内容多样化的功能才需要，比如商店中出售的道具、时装、副本等。就拿时装来说，我们在测逻辑功能的时候对整个时装系统已经有过全面的测试，比如时装的购买，时限，数据落地等等，而我们测试时装系统的内容其实测试的是某个具体的时装，在测这个具体的A时装的时候，不用对诸如出售价格边界值等等逻辑层面的很多异常点的测试，只需要关注这个时装特有的内容，比如出售价格是确定的20，展示图标正确、各种场景的展示没有问题等等。通常在设计功能用例的时候应该同时设计内容用例，以备后续测试使用。
3、冒烟用例
冒烟用例是涵盖所有系统功能的最精简测试用例，冒烟用例是用来做保底测试的，尤其是游戏正式发布后线上的每个版本更新前除了测试具体的更新内容，还要做冒烟测试，冒烟用例的设计原则是保证每个系统的基本功能正常，不同的项目设计原则可能不一样，这里提供一个思路即将客户端所有表现出来的可以直接点击交互的功能都编写进用例里。冒烟用例的设计同样最好在设计逻辑功能用例的同时设计出来，以备后续使用。
4、通用用例
通用用例是偏向于方法层面的用例，通用指的是适用于多个项目的某个功能的测试方法，所以通用用例涉及到的功能往往在很多游戏里都有，只是具体表现或者实现逻辑上有不太大的差别，比如基本上每个网络游戏都有登录，聊天、好友系统等。那么针对这些都有的系统我们就可以总结出一些基本的测试方法，以供其它项目直接使用。
二、问题储备
任何项目不管是游戏还是别的，从立项到上线与用户见面的整个过程中，肯定会遭遇各种各样的问题，同样对于测试部来说也会遇到问题，这些问题可能是漏测，可能是延误不能按时完成任务等。那么对于这些问题就非常有必要把它记录下来分析原因，总结出更好的方法来，当下次再测试类似功能，或者遭遇相同情景的时候，可以避免同样问题的发生。
三、流程方法
很多团队我发现除了项目经理，往往最熟悉整个研发流程的是测试部门，这可能是由于测试处于整个研发流程的最后一环（发布属于运维团队），要保证游戏的质量，除了游戏本身的功能没有问题外，整个研发到测试的流程是否合理正确也非常的重要，所以测试往往不得不对这个流程进行把控和负责，比如测试经常会遇到在测试环境测的好好的，到了发布环境就出了问题，导致这一问题的原因很可能就是发布的流程出了问题。而不同的研发阶段，研发到测试再到发布的流程也会不太一样，这个流程往往需要测试管理者参与制定，那么测试管理者包括组员就要根据自己以往的经验，总结出适用于不同阶段的测试流程策略，以保证测试团队，乃至整个研发团队能高效运转。
上面列举了一些不管是团队还是个人，在平时工作中都要善于总结和积累，主要包括用例、问题、流程等方面的经验储备，当然对于一个测试团队来说，要积累和储备的远不止这些，大家可以根据自己的项目特性进行总结。
<完>
个人浅见，欢迎留言交流。♪(＾∀＾●)ﾉ
