这是测试魔咒还是人为疏忽的借口

这几天遇到一个线上问题，关于开发修改代码以后提交影响点测试，其中有一点是关于版本的兼容性测试，场景：有AB两个版本，A新版，B为旧版， 然后这个影响范围需要分为四种情况进行测试，A版四种测试完没有问题，然后B版测试两种情况，就认为了没有问题，就没测试了，主观的认为 没有问题，但刚好，偏偏就是出现问题，用户反馈了，并且刚好是其中一种没有测试的情况。我想这种场景，作为测试，应该会经常碰到。对于这种说好听的就是风险评估预测不充分，说不好听点，偷工减料被发现。对于这种情况就是对测试责任心和能力的一种表现。我之前在测试交流群里，看到很多人发版本前会很焦虑，怕测试不完全，没测试够，尽管测试计划已充分按照计划和方案执行，还在头脑风暴的进行更全面的测试，怕没有考虑全，生怕漏掉了什么，这是一种责任感的表现；

对于以上两种场景的情况，我说下我个人见解：

1.对于开发修改提交的影响范围点，要设计好用例，考虑周全，切不可说，前面几种情况没问题，就不测，其实，这种就是漏测了，对于测试来讲，能给你列出影响的范围，已经非常好了，有的团队，直接说你这个模块测测就好了，让你摸不着头脑。能列出影响范围说明开发有考虑过了，所以不要去漏测，如果你要减少一些场景，就需要了解修改地方原理，然后跟开发确认下，再根据进度来评估，是否减少范围，切不可自己随意减少测试范围；其实对于开发自己列出修改影响点的范围，自己也是不全的，也是无法评估，这个是业界通病，也是难点，有时开发自己修改了都不知道影响到了其他点，所以测试自己要对开发点也要自己分析，补充，确认，再进行测试，这是业务测试最可靠的方案（排除精准测试）；

2.对于发版时，怕漏测的焦虑，其实不要焦虑，如果已按照你所认知，并按照计划和方案来执行了，漏测了就漏测了，漏测不可怕，怕的是一直重复的漏测同样问题，漏测就是检验你的能力的最好方式，也是提高你能力的机会，所以要漏测中分析原因，进行改进，避免，提高自己。软件测试不可能穷尽测试的，并且对于每个人的认知能力不一样，所以不要过于焦虑，对自己能力 要有信心，绝对可以满足用户需要；

所以对于测试不充分而被发现，这不是魔咒，这是早晚的事，只是有时是刚好你没测完全，又刚好被发现而给自己造成的表象。所以作为一位软件测试工程师，时刻要保持头脑清晰，分析到位，责任到位，执行到位，反馈到位，最终就是奖金到位。