2、哪些属于测试模块的主要功能？对于测试人员有哪些途径去积累判断测试模块的主要功能？

　　对于第一个问题，看起来很简单，但是执行起来不容易，有时即使对于有经验的测试人员也很容易在测试过程忽略掉每一轮测试的重点，陷入一个小模块进行详细测试，而忽略了对这轮测试总体测试侧重点的把握。所谓测试主线就是该轮测试我们的测试重点，如冒烟测试我们主要看测试模块主要功能在正常情况下能不能实现，影不影响项目进入系统测试；本地化测试时，当主要功能较稳定时，我们关注的更多的是字符，乱码，拼写，提示信息，标点等等是否已本地化；测试后期我们更多的是验证bug，而不是进行详细的系统测试。实际测试中，我经常看到同事对每轮的测试主线把握的不是太好，如我们公司对每个项目每轮测试都要进行冒烟测试，在冒烟测试问题反馈中，经常看到上报的有些小的控件问题，如按钮没有完全展示出来，输入框对特殊字符及快捷键没有做处理等，这些确实是问题，但是这不是我们进行冒烟测试的初衷；一个项目的最后一个Build有时会看到同事会提好多建议，提建议固然很好，但是我们应该清楚，最后一个Build测试重点一般主要放在验证上轮Bug上，对于建议应该在前几个Build来提，而不是最后一轮，因为最后一轮意味着项目要投向市场，面临着市场压力，即使提了建议，开发人员为了保持主要功能的稳定性及降低风险，一般也不会修改这些建议的。

　　那么我们如何知道每轮测试的侧重点？拿我们公司来说，每轮测试都会有更新文档和本轮测试重点描述的相关文档；如果没有这方面的文档，这时候就可以去询问测试项目负责人或测试执行负责人。当我们知道该轮测试重点后，结合测试时间，大致划分下每个时间段测试哪些模块，具体执行中牢记本来测试重点，从负责的整个测试模块来把握测试主线，尽量避免被一个小模块拖累了整个项目的测试进度。

　　关于第二个问题：哪些属于测试模块的主要功能？我的理解是这里的主要功能是由用户的使用频率和这个功能失效对用户的影响共同决定的，举个简单例子，我们经常提到的UI测试，一般UI的关注点在于美观性，控件类等问题，如进入tab页后信息的展示，这个对功能的使用没有影响（功能已经实现），但是用户进行相关操作时直接就可以看到这些信息如何的展示，用户看到和使用到的频率很高，如果信息的展示不是很好，就会直接影响用户对我们产品的使用信心。决定主要功能的是用户，所以对于测试人员有哪些途径去积累判断测试模块的主要功能也是从如何了解用户习惯展开的，总结了以下途径：

　　1、直接与用户接触了解用户使用习惯，了解用户主要关注哪些模块，这些模块这些点就是我们所说的主要功能。（对于我们公司很少有这种机会）

　　2、关于1是个很理想的状态，但是大多数情况下，我们测试人员是很少有机会接触到用户的。这个时候可以间隔性的请技术支持或者销售人员给我们介绍用户主要关注哪些模块及哪些问题的出现会使用户非常恼火以及现场问题收集等等，技术支持和销售人员对于用户的了解一般会比我们测试人员多。（这个途径也像老大建议过，但是一直没有做起来，导致现在对现场问题及用户习惯处在模模糊糊的状态）

　　3、看需求，这里的需求有产品需求说明书和用户需求说明书，通过需求说明书我们就可以知道用户的需求，优先级等，这些也是我们判断是否是主要功能的依据。

　　4、经验，这个主要就看我们对测试模块的熟悉程度。大家可能有这个经验，就是一个模块测试久了，对这个模块的总体把握，哪些相对重要在心里会有大致的区分，这个就要求我们在测试执行过程中，其他时间多了解我们的测试项目，哪些是主线，哪些是次线。（这种途径个人感觉存在一定风险，有时只是自我感觉是不是主要功能，实际上是不是）

　　5、向以前测试该模块的测试人员学习，询问；向小组领导请教，一般测试领导对模块主要功能的把握比较准

　　6、看产品使用说明书，当我们刚接手一个新模块时，还没有对该模块形成所谓的经验，这时候我们可以看看使用说明书，了解该模块，使用说明书一般是技术支持人员来写（我们公司如此，其它公司不太清楚），写的角度也可能是从用户角度出发，对我们对一个模块主要功能的判断有一定的启示意义。

　　测试过程中，也遇到对主要功能把握不准的情况，请教老员工，老员工说过最多的就是：经验。其实我很反感这句话，对于新人能不能告诉我们掌握主要功能的途径，或者说经验积累的方法，通过哪些途径去积累这些经验，而不是动不动就那经验来显摆，这样才能让新员工快速积累这方面的经验，抓住主要功能，少走些弯路，快速成长起来，这里谴责下这些不负责任的老员工，呵呵。