对于以上两种场景的情况，我说下我个人见解：
1.对于开发修改提交的影响范围点，要设计好用例，考虑周全，切不可说，前面几种情况没问题，就不测，其实，这种就是漏测了，对于测试来讲，能给你列出影响的范围，已经非常好了，有的团队，直接说你这个模块测测就好了，让你摸不着头脑。能列出影响范围说明开发有考虑过了，所以不要去漏测，如果你要减少一些场景，就需要了解修改地方原理，然后跟开发确认下，再根据进度来评估，是否减少范围，切不可自己随意减少测试范围；其实对于开发自己列出修改影响点的范围，自己也是不全的，也是无法评估，这个是业界通病，也是难点，有时开发自己修改了都不知道影响到了其他点，所以测试自己要对开发点也要自己分析，补充，确认，再进行测试，这是业务测试最可靠的方案（排除精准测试）；
2.对于发版时，怕漏测的焦虑，其实不要焦虑，如果已按照你所认知，并按照计划和方案来执行了，漏测了就漏测了，漏测不可怕，怕的是一直重复的漏测同样问题，漏测就是检验你的能力的最好方式，也是提高你能力的机会，所以要漏测中分析原因，进行改进，避免，提高自己。软件测试不可能穷尽测试的，并且对于每个人的认知能力不一样，所以不要过于焦虑，对自己能力 要有信心，绝对可以满足用户需要； 所以对于测试不充分而被发现，这不是魔咒，这是早晚的事，只是有时是刚好你没测完全，又刚好被发现而给自己造成的表象。所以作为一位软件测试工程师，时刻要保持头脑清晰，分析到位，责任到位，执行到位，反馈到位，最终就是奖金到位。
