文如标题。其实这应该是一个老生常谈的问题，然而因为太老了，所以它差不多已经在不断涌现的“后浪”（新问题）推动下死在了“沙滩上”，而答案也变得更加的模糊。
可是这个问题其实每一个测试人员都无从逃避。也许我们每个人都在心里有一把尺子，只是尺子的最小单位和最大丈量范围不同，但是确实就那么存在着。我也有，从我做测试的第一天起其实就已经有了，只是每次用这把尺子算出结果的时候，我都会或多或少的担心过是否自己计算错误。想想看，一个以测试为职业一个习惯对任何事物先进行怀疑的人怎么能不去怀疑自己的计算结果，更何况这个结果产生的影响足以值得我们去测试这个结果。
算算看自己做测试也快要3年了，可是每次修改任务状态为测试通过时，都会有种“心虚”的感觉，可以说这感觉跟了我近3年了。尤其是在最近的一次较为紧急的日常需求测试中，这种感觉似乎愈演愈烈。当开发人员不停的询问测试进展和情况时，总有种不知如何回答的感觉，即使是以测试用例的执行情况来作为判定标准，但是我们都知道随着测试的深入，用例本身也需要强化和修改，尤其在这种周期短的日常测试中更让人难以预估，因为对需求理解的深度和相关业务的广度都受到了时间上的制约，但是这同时并不能成为我们测试人员遗漏问题的借口，因为凡是经过我们的测试都必须有一定质量的保证。所以我习惯把我想不明白的问题与开发做交流，同时在自己测试完成后明确的通知开发人员我测试了哪些内容，并让他们分析是否还有遗漏。尽管我知道开发人员未必能给出很多提示，但是我希望我们测试人员并不是独自战斗，更不应该只是时时向开发人员汇报进度，我们需要开发人员的支持和帮助。尤其是我会把自己在测试中无法保证的情况也向他们说明，并请求他们分析我所怀疑的问题是否程序能够处理，或者提供我某种验证的思路、方法以便让我对这些情况进行测试。
其实可以换一个角度想，开发人员也非常需要得到测试人员的认可，并且这认可越早得到他们得到的鼓舞就越高。可是测试人员并不能以满足开发人员的“成就感”为第一目标。因为一个有缺陷的东西测试人员首当其冲的要为其负责。所以即便开发人员认为测试已经足够时，测试人员还应该要拿出自己的尺子再次定夺。
我们都知道bug无处不在，它的生命力是比小强还强。那么“测试通过”的意义为何？很多时候我们可能会回答询问测试情况的人“基本没有问题”、“差不多了”。可是天晓得我说这话的时候有多么难受，因为曾经就看过这样一篇文章说很多人都会为了逃避责任喜欢讲“基本如何如何”，可是什么是“基本”，究竟差了多少没有任何的说明。所以我们在任务的状态里也只能看到通过或者不通过，而不是基本通过、基本不通过。科学是严谨的，它决定了我们不能摸棱两可的做事。
于是我喜欢在日常需求发布表的备注里具体的写些自己的测试情况，哪些测试了，哪些考虑了却无法进行测试等等我在测试过程中遇到的问题。因为这样做会缓解我对标明“测试通过”的心理压力，因为我觉得单靠一个测试状态并不能真正反映测试的情况。所以，在我没有得到判定“测试通过”的标准答案前，我会一直这么做下去。假如还有其它测试人员也和我一样有类似的困惑，不妨可以试试我的方式，或者我们再交流、再切磋，不让我们彼此孤单的承受这“折磨”。
