相信大家在测试工作过程中一定遇到许许多多的问题，而且每个人的问题都不太一样。总结小编在测试过程中经常遇到的几个方面与大家分享一下。
　　1.测试执行方面
　　测试过程中，我们常常会担心测试不够全面，覆盖不全。因为我们知道测试不足（没有覆盖到足够的度）极有可能带来严重的后果，但过多的测试能够在解决这个问题的同时不带来弊端吗？显然不是的。设计测试用例本意是为了规避测试的随意性，让我们测试时既不多测也没有少测。
　　很多测试行业的前辈或同事都会在总结测试的时候分析出在测试过程中有些功能可以不需要测试得那么详细，有些用例存在的意义很小（甚至是冗余）。将容易的、明显的模块/功能进行详细的测试而复杂的功能没有得到充分测试，这属于明显的资源分布不均，会带来严重的浪费。
　　在测试用例设计的过程中也存在过多的执行的现象。比如为了覆盖一个功能点，有人会在设计测试用例的时候持有“宁可多，不可少”的观念，算是存在着大量重复的测试用例，也不进行删除和精简。比如同样都是测试“地区短信黑名单不拦截联系人发来的短信”功能，那么测试一个联系人发来一条“晚上一起吃饭吧？”和发来一条“一起打球吧？”的短信，是一种重复。还有一种测试用例设计中得过多执行现象是，在用例设计过程中写过多的重复（冗余）用例，评审的时候再进行删除，这也是不可取的。
　　在测试过程中，这样的过多测试，我们多少都会碰到，这样的重复测试对我们的能力提升和行为优化是没有帮助的，因此在测试过程中我们应该留意，主动去克服这些问题。
　　2.测试范围方面
　　对于测试人员来说，漏测风险是难免会存在，这让所有的测试人员都感到不安。有时候会出现因为怕承担责任去做超出测试范围的事情，无形中加大了测试的工作量，而不是去按照开发的功能实现去分析测试边界、测试重点。
　　比如有的时候，开发只是去修改了一个模块中得一个很小的功能点的实现逻辑（甚至是改动了UI上面的布局，更甚至只是替换了UI资源文件），这个时候不去与开发确认修改范围，而对整个模块进行功能的测试是一种超出范围的测试。这样的超出范围的测试，也是一种测试能力不够的表现，而且这也不是 一个追求卓越的测试人员应有的态度。 这种情况下，我们应该及时的去了解开发的实现思路与修改逻辑，对测试范围进行一个评估，终得到一个合理的测试范围。
　　3.测试文档方面
　　一个的测试团队，一定存在着许许多多凝聚了许多人智慧的文档。也一定会有更多的人编写更多的文档。在编写文档的时候，首先要明白所编写的文档的作用，不顾文档编写初衷也是不可取的。文档重要的作用一方面是保证信息传递的有效性、便捷性，保证文档在查看过程中信息不失真；另一方面是对既有的测试经验的一种总结和传承。如果文档在辛苦编写后再无查看，那么该文档失去了存在的意义。对于许多技术岗位上得同学来说，可文档可能是一件不太招人喜欢的任务，但是文档的整理和编写对于一个的测试人员来说确实必不可少的一项基本能力。而且对于项目中经验的积累和传承，对于工作任务的传达都具有十分重要的意义。
　　但是，并不是所有的文档是越详细越好，比如一项文档的面向对象是一个工作经验一年以上的项目组成员，那么给他一份包含了详细测试步骤、具体操作、甚至每一步都带有截图和标注的文档反而是一种过度的行为。再有比如在测试执行过程中，有时候需要记录测试的执行。一份包含所有过程、步骤、截图、风险的详细文档有时候也不是必须的，而且还有可能降低执行的效率。
　　4.沟通方面
　　相信大家一定见过这样的场景：同一个办公室里或者隔着几道工位的同事，经常会因为一个可能三两句话说完的事情而在QQ（或其它通讯工具）上聊半天。这种不合理沟通方法，很大程度上降低了工作的效率，而且也不利于同事之间沟通上的了解。
　　沟通方面还存在一种不同角色间的问题。各方面的进度（可能会给测试带来Delay压力）的推进中，有一种不主动去推进，而是等待进度反馈的现象。假如前面的角色进度都正常的话，整理进度对测试的压力影响不大；但是若前面的角色进度存在着阻塞或者其他情况的Delay，那么测试的工作往往会收到很大的影响。项目上的排期需要重新制定，测试任务的展开也会出现混乱。倘若上线的时间是定死的，那么测试的压力会非常大，风险也会非常大。
　　因此沟通上面，能够尽量的完成当面沟通，及时推进，把可能的突发情况尽可能早的发现并暴露出来，让各方面都有提前准备，对于测试方面，甚至是各方面的工作都是百利无害的。
　　5. 问题发现与创新
　　任何的工作都是在前人工作的经验的基础上展开的，从而进入到一片带有自己色彩的天地。测试工作也不例外。（当一个新人）在进入到一项测试工作中时，往往发现该团队的工作模式，流程文档，例行产出等都已经存在着成熟的规范或者约定。而这些约定也并不一定是完整的，甚至有时候随着时代的不同，可能也不见得正确（比如传统PC软件的测试到移动APP的测试）。这个时候有的人可能处于对既有流程的尊重，或者对前辈同事的尊重，而不敢提出自己创新的观点和看法。这个其实从长远来看，对项目和团队也是不利的。
　　比如我们现在的QWERTY键盘布局，是机械打字机时代为了解决打字过快而造成卡键问题而发明的，它初的目的是为了大程度上降低打字的速度。除去商业和制造业上的一些原因不谈，如今大部分人对这种键盘模式采取的是适应的态度。但这种键盘布局对于打字速度的提升和打字时手指的受力方面存在着极大的不合理。因此才会有DVORAK和MALT这两种按键布局方案的产生。
　　测试工作中，也应该有这种创新的思路和对问题的发现能力。并积极的思索和提出解决方案。