也许是职业病，测试人员似乎比其他岗位的人员对问题会更敏锐，能够发现很多问题。但因为缺少很多方面的知识，比如：操作系统、硬件结构、架构设计等等，定位/解决问题的能力弱于发现问题的能力。我自身是有很深刻的体会，近期工作中遇到一些疑难杂症，都是跟被测对象有关。也许多深入挖掘，就能收获很多。
问题1、系统可靠性测试，同样的接口做同样的事情，接口耗时不同。
因系统版本暂不稳定问题较多，当前的系统可靠性测试（时间段：头一天下班～第二天上班）不属于 性能测试 范畴，更多的还属于功能测试。同样的流程，重复执行N遍，流程跑不通。根据报错信息完全看不出来CC组件有问题，但是仔细抠log日志，不同时间段同样的接口耗时不同；同一时间段同样的接口耗时也有差异。
最简单的做法：根据log日志，对比差异，确认内部哪个地方耗时较多。
排查过程：先从log日志抠出AA组件（最容易看出有问题）同样的接口耗时有差异（最开始耗时40s多，最近耗时1min12s），发现调用BB组件接口的函数耗时不同（最开始耗时10s，最近耗时1min）；再从log日志抠出BB组件同样的接口耗时有差异，同样的排查手段；最终确定CC组件（BB组件和CC组件不存在直接调用关系，但是CC组件接口返回的数据需要通过通道给到BB组件）写文件操作导致接口返回不稳定。
排查结论：CC组件位于下位机（vxworks操作系统），使用NFS功能向上位机（linux系统）指定目录的文件里实时写内容引发的用时不稳定。
即使现在知道了问题出在哪，但是对一些原理性的东西还是不理解。测试对象依赖的平台，相对来说是个工具/框架，我们只知道怎么去使用/操作，一旦涉及到平台相关的问题基本就束手无策。
问题2、同一个组件不同的测试范围，同样的功能使用效果不同。
我负责该组件本地场景功能测试，另外一个测试人员负责该组件远程场景功能测试。本地场景功能测试时，验证XX正常场景，功能使用正常且不影响后续场景验证；远程场景功能测试时，验证同样的场景，需要增加“信号交互检查项”，发现信号交互不正确且会影响后续场景验证。
严格意义上，这个问题应该要在本地场景验证时就要发现的。
惯性思维一：觉得流程没问题不影响后续场景验证，就是没问题的。这个遗漏缺陷引发出另外两个本地场景细节探讨，竟然又是我遗漏的场景。
惯性思维二：没有纯粹的用户思维，一直用测试思维。测试思维知道这个地方有问题，自动跳过这个坑；用户思维不管有没有问题，反正就是要这么用。
问题3、很容易看到单独的点，却看不到组成的面。
这是大多数人都会有的毛病。可能视角问题，只能看到这个点；可能是思维模式简单，只看到表面；也可能是不了解背景，无法全局评估。就像测试人员提交一个缺陷，测试人员基于场景验证，发现这个场景有bug，但因为测试覆盖率不达标，可能会忽略周边其他相关场景；开发人员修复缺陷或者分析缺陷的时候，也会分析不全面。
前两天提交一个缺陷，看似很简单就是改一个地方，只要定下来需求。但实际上深入分析，因为这个缺陷引发对XX需求的讨论，涉及多个功能接口多个组件。
问题4、好方案很多，但选择适合的方案很难。
现在做的项目没有具体的用户需求。很多时候，测试过程中发现有问题，会因为问题而逆向寻找需求。因为没有参考基准/依据，只能拿有经验的项目做参考。项目A针对这个问题是设计方案1，项目B针对同样的问题使用的是设计方案2。追溯源头会发现每个方案各有千秋，都是细节上的差异性。如何从用户操作角度考虑，方便快捷使用，提醒/提示恰到好处。这个度真的很难把控，别的项目好的设计方案很多，关键要选择适合我们自己的。
源自公众号 WorkingIsLearning