针对业务功能点的学习思路

针对业务功能点的学习思路：

1 案例描述

   有句话说的很好：不少学者对人类思维的实际运动过程以及解决实际问题的过程进行过研究。总结这些研究成果，发现高效思维者与低效思维者思考过程的区别在于，前者思考问题条理清晰，后者则混乱无头绪。那么高效思维的方法有哪些呢？

   这个命题太大，并且针对不同的知识，具体有效的学习方法还有细微的差别（比如学习语言和学习艺术、学习驾驶等）。那么，针对测试人员学习业务，有没有一些好的思维方法，和一些小技巧，让学习过程高效一些？

   本文部分方法具有通用性，部分方法是针对测试职业的特性总结而成，其他工作岗位的同事可以参考一二。

2 案例分析

   大学里面学到的什么能力最重要？不是专业知识、也不是初步的人情练达，大学里面我们学到的最重要的，应该就是学习能力。

   一门辅修课，大多数人可能需要在考试前突击学习，一门知识由不懂到一知半解，或者到初步掌握，只需要几天的时间，这种突击学习的能力，快速了解一门知识，才是大学里面我们掌握的最重要的知识。

   每个人的学习方法不尽相同，有的人习惯自己翻书遍历，有的人习惯先阅读大纲，有的人习惯直接做习题，一边参考解题步骤一边提炼知识点，有的人习惯抄书，把知识点都自己誊录一边……这种归属于个人的，经过长期实践的学习方法，我们不做统一的要求。

   但是，还有一些通用的学习方法，是经过很多人提炼出来，可以提高自己学习效率的，我们把这类方法和实际的业务知识学习，并进行概括总结，形成此文。

概括来讲，即为三个要求，三种思路，七种方法，一套完整的学习展示思路。

2.1 三个要求：

 第一个要求：用生活中的例子来讲述你学习的业务知识点。

 第二个要求：文档更新要求——从培训文档中学习，并不断的完善培训文档。

 第三个要求：针对新人，能动手时，尽量多动手进行实际操作，一边看一边学习。

第一个要求：用生活中的例子来讲述你学习的业务知识点。

   在我们测试部门的sos的培训子项中，我放了这么一篇文档《如何在三个月内获得三年的工作经验》，其中一个核心的思想就是：你自己把某一门技术，或一个行业的资料大量的搜集起来，然后自主的编写行业分析报告。通过这种方法，你能快速的获得别人几年才能积累的工作经验。

   在学习中，我们认为只有自己理解的知识，才是自己真正掌握的知识。比如商场的导购员，什么纳米技术，什么最新科技，什么名词、数字量一套套，但是他们不理解，所做的也就是背熟了台词而已。同样，在学习业务知识和新功能规格时，不仅仅要求我们会背诵，而是要求我们能理解。

   新测试工程师面对一大堆系统说明书，业务规格书，很多拗口的专业名词，每天都看到大家对着ppt或者word文档猛看，实际的效果怎么样？这些知识点怎么才能说是你理解，并掌握了？

   证明你掌握的方法，就是你用自己的话重新把这个知识点进行重构描述（七种方法的重新描述法）。更进一步的要求，即使采用联想的方法，用自己生活中的例子来讲述你学习的业务知识点。要求触类旁通，扩大大家的思路，也通过联想记忆的方法，让业务知识，业务逻辑的学习理解更直观。

 重构描述的例子：

 举例1 系统框架

   在新员工入职后，第一门课是系统架构。面对一张架构图，对着图反复的看，死记硬背下来是很低效的方法。板卡太多，囫囵吞枣的记忆可能会串功能。比较清晰的做法，那就是自己找张纸，从零开始，一个个的单板添加上去，然后描述这个单板的作用，直到最后完成一张完整的架构图。这种重构的方式，可能会加深你的记忆。同时，你重构出来，也可以很好的证明自己掌握情况。

   还有员工个人总结的经验方法，也是重构描述中，自己方法的总结。

   掌握知识点，要求自己能重新描述，即：当你能够自己一二三四的讲明白后，才能说这个知识点你学会了。

  用自己生活中的经验来联想记忆、扩展描述的例子

  举例1 TCP/IP，包传输

   什么是切包传输，什么是丢包重传？结合生活经验，比如寄快递，你从北京寄一辆摩托车到上海。但是东西太大，一个包打不下，那么你就把摩托车拆分，打成一个个的包并编上号码：1/2/3/4/5……，然后一次寄到上海，可能途中还会分成几个批次，走不通的方式发到上海。然后上海收到货物后，确认所有的包都收到，然后拆包，重新组成一辆完整的摩托车。

   如果这些包里面，到达上海后，第3包不见了，你通知北京，少了一包，这包的东西配件再重新发一份给我。然后一个新的第三包里面的配件重新发到你手里，从而组成一辆完整的摩托车。

   通过这种方法，可以加深较为枯燥的业务知识学习。

  举例2 能力级和同时能力级

   协议中，能力级交互，结合生活经验，可以理解为打牌时，两个人约定游戏规则。游戏内容是打牌，你会什么都说出来，他会什么都说出来，大家商议一种玩法。每种玩法，各个地方细节的规则可能不一致，那么你把你的规则拿出来，我把我的规则拿出来，有些规则可能是互斥的，所以能放在一起的规则组成一个个的规则包，大家约定好一系列规则，然后就开始打牌。

  举例3 质量优先速度优先

   结合实际，用喝珍珠奶茶的概念即可。大的珍珠就是高画质的图像，在吸管较细时，那么要享受大珍珠，可能速度会比较慢。小的珍珠是低质量的图像，在吸管较细时，速度很快，但是每颗给人的享受较少。结合工作就可以这么理解：质量优先，就是在带宽有限的情况下，如果要享受清晰的图像，那么图像的连贯性就较差；如果要享受连贯的图像，那么图像的质量就相对较为模糊。

第二个要求：文档更新要求——从培训文档中学习，并不断的完善培训文档。

   在新员工培训中，实际遇到这么一个问题：一些培训课件教材于2008年编写完成，随着产品业务的发展，产品种类的增多，已经和目前的系统架构不匹配。一些新员工在学习中，反馈了这个问题：我们的课件需要更新。

   每个公司在培训方面，都有自己的实际情况。参考业内的一些培训方法，我们采用的方法是导师制度，在实习期内，导师会安排学习培训计划。新员工在技术层面的问题，都可以在导师处获得初步的指点和解答。

   但是在实际执行中，导师一般都是骨干员工，他们本身肩负的工作任务就很多。在培训阶段，没有充足的时间做到一对一的展示ppt，讲解系统业务架构，类似于学校那种，知识点逐一讲解的方法，在目前公司的现状内不现实（如果有那种专人的培训，肯定也会有专门的闭卷考核，这种方式对新员工肯定也会有淘汰名额）。更多的时候，是新员工根据已有的学习培训文档，自行对业务知识进行学习，然后不断汇总记录疑难问题点，抽时间和导师碰头，对疑难问题一一沟通交流。

   在这种实际情况下，依赖于产品线或者导师定期更新培训课件，无疑是不太现实的。

   那么，怎么才能提高新员工的学习培训效果，提高大家的学习积极性呢？我们采用的方法是，反向提出要求：要求新员工完成对课件的增补，修订。

   这也是希望新员工发挥自己的主动性，并在实习期内，证明自己能力，展示自己工作业绩的一个方式。

   试想一下，大家都知道培训课件需要更新，但是一直没有更新，这说明肯定存在人力或投入方面的困难。作为一个刚加入团队的新人，同样在学习阶段，如果仅仅表现为：我没学好，是因为课件没有更新，我学不到新的知识————这种态度，可能无法展示自己的能力和态度。换个思路，你发现了课件本身和实际环境中的一些设备、业务知识存在差异性，你能把这部分标明出来，然后根据目前实际情况进行增减，然后展示给导师、负责人和产品/部门经理————这种态度，对自己的提升，对自己下一步的工作的帮助可能更大一些。

 举例：

   A员工获得培训课件——学习阶段——输出：掌握情况一般，借口课件不全

   B员工获得课件——学习阶段——输出：掌握较全面，形成课件增补文档，提交导师评审，帮助导师和团队完善课件。

   不同的积极性以及不同的交付结果，从导师和团队的角度，对待A、B两个新人，可能看重度和倾向度是有区别的。

第三个要求：针对新人，能动手时，尽量多动手进行实际操作，一边看一边学习。

   绝大部分人在学习业务知识时，都是第一次接触这个行业，这种业务（或是第一次参加工作，或是从事其他工作）。针对这种全新知识技能的学习，绝大部分人采取单纯的阅读文档，这种方式收到的效果很微乎甚微。

   我们不是超人，能够通过阅读文档就能掌握一门语言或者业务。我们原有的学习经验和这种业务知识的快速学习快速掌握要求也是不一样的。很多同事已经用自己的实际证明了，单纯阅读文档的低效，那么我们为什么还要一次次的犯这个错误。

   所以我的建议就是：大家能动手时，尽量多动手进行操作，一边看一边学习。

   在针对这个要求的沟通上，也试图在大家生活中寻找类似的学习方法和学习效果，让大家来实际体会一边阅读一边动手的快速性。

  例子一：学习word

   大家一开始接触word这门课，估计没有人先去看书，一页页的阅读教材，工具栏是什么，每个图标的作用是什么等等，而是会随手输入几个字，然后直接每个功能点过去，特别是字体、字体特效这部分，更是玩的不亦乐乎。

   自己折腾了几次后，趣味性降低，才会拿起书，看看到底写的什么。

  例子二：学习一款新游戏或一个新的副本

   玩一个新的游戏，也很少有人真的把键盘说明、操作快捷键先看完背下来后，再动手游戏。大多数人是直接上手开始玩，感到自己需要什么的时候，才会回过头来看帮助。

   同样，副本和任务也是一样，很少有人选择静态的看文档攻略，看完背熟后在动手玩游戏，大多数人会选择边玩边看，走一步看一步。

三种思路：

1、从用户的角度开始思考   

2、从开发人员的角度开始思考

3、从测试人员的角度开始思考

   一开始大家学习业务阶段，对公司测试工作上手阶段，肯定是从执行测试用例，黑盒测试开始，这种工作，我们认为只是测试执行人员，黑盒测试执行范围的工作，距离我们的岗位要求“系统测试工程师”还差的很远。

   这三种思路，就是让大家快速成长为系统测试工程师的三种思路：

     1.、从用户的角度来思考：这个功能会满足我的什么需求，如果我花了买了设备，我希望这个产品的功能是什么样子的？

     2、从产品设计人员、开发人员的角度来思考：有一个功能要我实现，根据软件工程的常规架构，我应该怎么做，或者应该设计成什么样子？

     3、从测试设计人员的角度来思考：功能目前是这样设计实现的，或者从黑盒的角度，功能有几个参数，预期会产生什么效果。那么，大家从测试设计人员的角度，去思考，如果是我设计测试用例，我大致的设计思路是什么？

   有可能这个行业是大家第一次接触，甚至有可能测试工作是大家第一次接触。但是平时日常生活中，大家用过的软件肯定不少，比如QQ，比如BBS，比如各类游戏，那么，在一些面向客户的人性化、易用性，甚至一些模糊的思考，下意识的念头总是存在的。所以这三种思路，就是希望大家把原来那种随机的、模糊的念头想法，思路化和系统化，能够快速的拓展自己的测试思考能力。

例子1：视讯软件发送静态图片功能：

1、用户的角度：这个功能我需不需要，我要怎么使用？

   ——在会议开始前发送静态图片，比如单位logo或会议主题，类似于cctv的静态图片或重要通知类。

   ——在无信号时，播放静态图片进行知会，类似电视信号中断时的提示信息。

   ——思考功能点的应用场景和是否满足我（客户）的需求

   ——如果有这个功能，我希望它做到什么功能？比如能随意替换，方便应用于各种场景，比如通过快捷的方式替换（类似BBS或QQ换自己的头像）

2、软件设计人员的角度：这个功能，我要实现，应该怎么考虑？

   ——这个功能实现，UI方面设计应该怎么排布？

   ——这个功能实现，是否存在参数范围，或性能范围？如果有相关限制，有可能的瓶颈点在那里？

　　      比如图片的格式？图片大小等。如果要做限制，应该在那里进行限制？

   ——是否有已有的模型，组件进行参考？

3、测试设计人员的角度：这个功能点，我如何设计测试思路，构建测试用例？

　　——功能目前设计为勾选模式，第一步肯定测试两种状态的实现性，最基本的黑盒测试

　　——勾选后，肯定是发送图片给自己，给远端的接受人，所以针对会议场景，需要构建自环、点对点、多点，至少三种情况。

　　——基本功能之外，如果对图片可以自定义上传，可以找不同格式、分辨率的图片，对输入限制进行穷举测试。

　　——…………

例子2：与会时间显示：

1、用户的角度：这个功能我需不需要，我要怎么使用？

   ——在会议中可以关注会议已经进行的时间。

   ——这个类似一个电视频道的按键，我需要时按一下就出来，再按一下就没有，或者显示一段时间，自动没有

2、软件设计人员的角度：这个功能，我要实现，应该怎么考虑？

   ——增加定时器

   ——获取与会时间

   ——遥控器是定性的，怎么新增一个快捷按键，或者复用？

3、测试设计人员的角度：这个功能点，我如何设计测试思路，构建测试用例？

　　——操作的实现性，最基本的黑盒，两个测试步骤。

　　——会议时间的准确性，召开不同时长的会议，进行功能验证。

　　——临时入会、不停退会的冲击：在不同的时间段多次加入、退出，看每次的时间显示

　　——如果有类似10秒自动消失的逻辑，进行验证：10m内不操作，10m内不停操作等。

   面对一个业务功能，尝试从客户、开发、测试三方不同的角度去思考，能拓宽测试人员对业务功能的理解，也方便测试人员对客户实际的应用方法、客户需求，软件架构和软件实现方式，测试思路和测试策略做强化训练，提高了测试人员对业务学习的效率，也拓展了测试人员自我发展的能力。

三、七种方法：

联想扩散法

对比记忆法

重新描述法

实践操作法

主动思考法

测试大纲提炼法

Bug单阅读法

   联想扩散法、重新描述法、实践操作法，已经分解为我们的三个要求。主动思考法已经分解为我们的三种思路。在此，重新提出方法论，是希望大家可以从业务知识的学习中升华出来，变成一种通用的学习方法。

   在本章节，我们重点说一下其余的几种方法：对比记忆法、测试大纲提炼法、bug单阅读法。

对比记忆法：

   业务学习中，会存在大量的类似点。比如不同型号的产品规格等。通过对比记忆，可以通过已经掌握的知识快速的推导出新的知识。同时自己整理出对比结果，也可以让自己的记忆理解加深，也可以使自己深入的掌握业务知识。

测试大纲提炼法：

   在网络上，测试入门的文章大多会提到这种方法：通读测试用例，通过测试用例的通读，掌握测试用例的设计思路。

   结合实际情况，所以在学习和测试阶段，也是重点推荐这种方法。

   上图是如何快速掌握一个业务功能点的测试方法，建议分为两步去进行，一是自己构建自己的测试思路，另外就是通过阅读，执行已有的测试用例，提炼出测试用例的设计思路，两者进行互相借鉴印证，从而不仅学习到了业务功能知识点，还能掌握业务功能点的测试设计方法。

   再次强调，我们是系统测试工程师，不要只将自己定位为黑盒测试执行人员。

   注意，实际大家阅读或执行的用例可能是细化的用例，也许很多的用例都是通过用一种设计思路设计的，如何提炼出测试用例设计思路，这点要依靠大家个人的能力以及相关经验。

Bug单阅读法：

   缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现，同时也是软件产品问题的集中体现。

   基本要求：

   一般来说，缺陷报告单中最关键的几个部分包括：第一部分是发现缺陷的环境，包括软件环境、硬件环境等；

   第二部分是缺陷的基本描述；

   第三部分是开发人员对缺陷的解决方法。

   通过对上述缺陷报告单的三个部分作仔细分析，不知不觉你已经吸收了其他软件测试人员的工作经验，并掌握了软件产品常见的基本问题。这是迅速提高软件测试经验的好方法。

   扩展要求：

   根据阅读已有的bug单，总结提交bug的描述方法和注意事项；

   根据bug单反馈的问题分布，对软件问题的分布和层级有初步概念；

   根据bug单本身的深度，对测试团队个体的工作能力和工作效率，以及开发团队个体的工作能力和工作效率有初步了解。

总结：一套完整的学习思路

   结合上文中提到个各种方法：三个要求，三种思路，七种方法。在此形成一套基准的，针对业务功能点的学习思路：