摘要：
新入职的测试工程师，以及测试工程师面对新产品开发时，总有一些强相关的业务知识需要学习理解。
本文给出一些小的技巧，一些在思考逻辑方面的总结，以便测试工程师能够更系统的思考、学习，提高效率。
有句话说的很好：不少学者对人类思维的实际运动过程以及解决实际问题的过程进行过研究。总结这些研究成果，发现高效思维者与低效思维者思考过程的区别在于，前者思考问题条理清晰，后者则混乱无头绪。那么高效思维的方法有哪些呢？
这个命题太大，并且针对不同的知识，具体有效的学习方法还有细微的差别（比如学习语言和学习艺术、学习驾驶等）。那么，针对测试人员学习业务，有没有一些好的思维方法，和一些小技巧，让学习过程高效一些？
本文部分方法具有通用性，部分方法是针对测试职业的特性总结而成，其他工作岗位的同事可以参考一二。
有一些通用的学习方法，是经过很多人提炼出来，可以提高自己学习效率的，我们把这类方法和实际的业务知识学习，并进行概括总结，形成此文。
概括来讲，即为三个要求，三种思路，七种方法，一套完整的学习展示思路。
1.三个要求
第一个要求：用生活中的例子来讲述你学习的业务知识点。
第二个要求：文档更新要求——从培训文档中学习，并不断的完善培训文档。
第三个要求：针对新人，能动手时，尽量多动手进行实际操作，一边看一边学习。
- 第一个要求：用生活中的例子来讲述你学习的业务知识点。
网络上有一篇文章，非常有意思——《如何在三个月内获得三年的工作经验》，其中一个核心的思想就是：你自己把某一门技术，或一个行业的资料大量的搜集起来，然后自主的编写行业分析报告。通过这种方法，你能快速的获得别人几年才能积累的工作经验。
在学习中，我们认为只有自己理解的知识，才是自己真正掌握的知识。比如商场的导购员，什么纳米技术，什么最新科技，什么名词、数字量一套套，但是他们不理解，所做的也就是背熟了台词而已。同样，在学习业务知识和新功能规格时，不仅仅要求我们会背诵，而是要求我们能理解。
新测试工程师面对一大堆系统说明书，业务规格书，很多拗口的专业名词，每天都看到大家对着ppt或者word文档猛看，实际的效果怎么样？这些知识点怎么才能说是你理解，并掌握了？
证明你掌握的方法，就是你用自己的话重新把这个知识点进行重构描述（七种方法的重新描述法）。更进一步的要求，即使采用联想的方法，用自己生活中的例子来讲述你学习的业务知识点。要求触类旁通，扩大大家的思路，也通过联想记忆的方法，让业务知识，业务逻辑的学习理解更直观。
掌握知识点，要求自己能重新描述，即：当你能够自己一二三四的讲明白后，才能说这个知识点你学会了。
比如用自己生活中的经验来联想记忆、扩展描述的例子
举例1 TCP/IP，包传输
什么是切包传输，什么是丢包重传？结合生活经验，比如寄快递，你从北京寄一辆摩托车到上海。但是东西太大，一个包打不下，那么你就把摩托车拆分，打成一个个的包并编上号码：1/2/3/4/5……，然后一次寄到上海，可能途中还会分成几个批次，走不通的方式发到上海。然后上海收到货物后，确认所有的包都收到，然后拆包，重新组成一辆完整的摩托车。
如果这些包里面，到达上海后，第3包不见了，你通知北京，少了一包，这包的东西配件再重新发一份给我。然后一个新的第三包里面的配件重新发到你手里，从而组成一辆完整的摩托车。
通过这种方法，可以加深较为枯燥的业务知识学习。
- 第二个要求：文档更新要求——从培训文档中学习，并不断的完善培训文档。
怎么才能提高新员工的学习培训效果，提高大家的学习积极性呢？我们采用的方法是反向提出要求：要求新员工完成对课件的增补，修订。别人写的文档再漂亮，你不懂脑子的看，也只能是别人会的东西。自己写出来的，才是真正属于自己的知识。
这也是希望新员工发挥自己的主动性，并在实习期内，证明自己能力，展示自己工作业绩的一个方式。
- 第三个要求：针对新人，能动手时，尽量多动手进行实际操作，一边看一边学习。
绝大部分人在学习业务知识时，都是第一次接触这个行业，这种业务（或是第一次参加工作，或是从事其他工作）。针对这种全新知识技能的学习，绝大部分人采取单纯的阅读文档，这种方式收到的效果很微乎甚微。
我们不是超人，能够通过阅读文档就能掌握一门语言或者业务。我们原有的学习经验和这种业务知识的快速学习快速掌握要求也是不一样的。很多同事已经用自己的实际证明了，单纯阅读文档的低效，那么我们为什么还要一次次的犯这个错误。
所以我的建议就是：大家能动手时，尽量多动手进行操作，一边看一边学习。
在针对这个要求的沟通上，也试图在大家生活中寻找类似的学习方法和学习效果，让大家来实际体会一边阅读一边动手的快速性。
例子一：学习word
大家一开始接触word这门课，估计没有人先去看书，一页页的阅读教材，工具栏是什么，每个图标的作用是什么等等，而是会随手输入几个字，然后直接每个功能点过去，特别是字体、字体特效这部分，更是玩的不亦乐乎。自己折腾了几次后，趣味性降低，才会拿起书，看看到底写的什么。
例子二：学习一款新游戏或一个新的副本
玩一个新的游戏，也很少有人真的把键盘说明、操作快捷键先看完背下来后，再动手游戏。大多数人是直接上手开始玩，感到自己需要什么的时候，才会回过头来看帮助。
同样，副本和任务也是一样，很少有人选择静态的看文档攻略，看完背熟后在动手玩游戏，大多数人会选择边玩边看，走一步看一步。
2.三种思路
从用户的角度来思考：
这个功能会满足我的什么需求，如果我花了买了设备，我希望这个产品的功能是什么样子的
从产品设计人员、开发人员的角度来思考：
有一个功能要我实现，根据软件工程的常规架构，我应该怎么做，或者应该设计成什么样子？
从测试设计人员的角度来思考：
功能目前是这样设计实现的，或者从黑盒的角度，功能有几个参数，预期会产生什么效果。那么，大家从测试设计人员的角度，去思考，如果是我设计测试用例，我大致的设计思路是什么？
有可能这个行业是大家第一次接触，甚至有可能测试工作是大家第一次接触。但是平时日常生活中，大家用过的软件肯定不少，比如QQ，比如BBS，比如各类游戏，那么，在一些面向客户的人性化、易用性，甚至一些模糊的思考，下意识的念头总是存在的。所以这三种思路，就是希望大家把原来那种随机的、模糊的念头想法，思路化和系统化，能够快速的拓展自己的测试思考能力。
例子：
时间显示功能：
1、 用户的角度：这个功能我需不需要，我要怎么使用？
——在会议中可以关注会议已经进行的时间。
——这个类似一个电视频道的按键，我需要时按一下就出来，再按一下就没有，或者显示一段时间，自动没有
2、 软件设计人员的角度：这个功能，我要实现，应该怎么考虑？
——增加定时器
——获取与会时间
——遥控器是定性的，怎么新增一个快捷按键，或者复用？
3、 测试设计人员的角度：这个功能点，我如何设计测试思路，构建测试用例？
——操作的实现性，最基本的黑盒，两个测试步骤。
——会议时间的准确性，召开不同时长的会议，进行功能验证。
——临时入会、不停退会的冲击：在不同的时间段多次加入、退出，看每次的时间显示
——如果有类似10秒自动消失的逻辑，进行验证：10m内不操作，10m内不停操作等。
3.七种方法
联想扩散法
对比记忆法
重新描述法
实践操作法
主动思考法
测试大纲提炼法
Bug单阅读法
联想扩散法、重新描述法、实践操作法，已经分解为我们的三个要求。主动思考法已经分解为我们的三种思路。在此，重新提出方法论，是希望大家可以从业务知识的学习中升华出来，变成一种通用的学习方法。
在本章节，我们重点说一下其余的几种方法：对比记忆法、测试大纲提炼法、bug单阅读法。
对比记忆法
业务学习中，会存在大量的类似点。比如不同型号的产品规格等。通过对比记忆，可以通过已经掌握的知识快速的推导出新的知识。同时自己整理出对比结果，也可以让自己的记忆理解加深，也可以使自己深入的掌握业务知识。
测试大纲提炼法
在网络上，测试入门的文章大多会提到这种方法：通读测试用例，通过测试用例的通读，掌握测试用例的设计思路。结合实际情况，所以在学习和测试阶段，也是重点推荐这种方法。
上图是如何快速掌握一个业务功能点的测试方法，建议分为两步去进行，一是自己构建自己的测试思路，另外就是通过阅读，执行已有的测试用例，提炼出测试用例的设计思路，两者进行互相借鉴印证，从而不仅学习到了业务功能知识点，还能掌握业务功能点的测试设计方法。
实际大家阅读或执行的用例可能是细化的用例，也许很多的用例都是通过用一种设计思路设计的，如何提炼出测试用例设计思路，这点要依靠大家个人的能力以及相关经验。
Bug单阅读法
缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现，同时也是软件产品问题的集中体现。
基本要求：
一般来说，缺陷报告单中最关键的几个部分包括：
第一部分是发现缺陷的环境，包括软件环境、硬件环境等；
第二部分是缺陷的基本描述；
第三部分是开发人员对缺陷的解决方法。
通过对上述缺陷报告单的三个部分作仔细分析，不知不觉你已经吸收了其他软件测试人员的工作经验，并掌握了软件产品常见的基本问题。这是迅速提高软件测试经验的好方法。
扩展要求：
根据阅读已有的bug单，总结提交bug的描述方法和注意事项；
根据bug单反馈的问题分布，对软件问题的分布和层级有初步概念；
根据bug单本身的深度，对测试团队个体的工作能力和工作效率，以及开发团队个体的工作能力和工作效率有初步了解。
4.一套完整的学习思路
结合上文中提到个各种方法：三个要求，三种思路，七种方法。在此形成一套基准的，针对业务功能点的学习思路：
最后，诚如本文分享的一样。无论多么好的学习方法，如果你不自己去使用，它也仅仅是一种看起来非常美妙的方法而已，而不是你自己的知识或技能。
每个人的学习方法和习惯是不一样的，如果真是的是主动思考的人，上述的种种方法，也仅仅是抛砖引玉而已。