我一直认为自己是一个有点儿“选择困难症”的人，尤其表现在购物时，看到一排排大体相同又形形色色的鞋子，脑袋立马就空白了。在测试过程中我们面临更多的选择困境，从开始的需求到结束时的发布，每个选择都会导致不同的结果，从这一视角来看，如何运用理论（别人的经验）和实践（自己的经验），做出“正确”的选择，是做好测试的关键成功因素之一。
困境1：信任 vs 怀疑
你收到一个需求，某人告诉你这个是关键特性，很重要，客户的需求很强烈，市场的要求很紧迫，涉及到几百万美刀。所以你暂停/减少了其他“非重要”特性的投入，先做这个特性的测试。过了几个月之后，你发现这个需求连实验局都找不到，并且从发布范围中悄悄地删掉了。这是一次不太好的选择。
有些时候，测试需要懂点儿需求工程，知道如何找出需求的价值。
困境2：坚持 vs 妥协
你发现一个问题，并且认为它是一个很重要的问题，但是提交后，你的开发认为这种场景有点儿天方夜谭，结论是不修改。但是你不甘心，你找到技术支持，翻出去年一个类似问题引发的网上问题，然后语气沉重、面带悲痛地向你的开发讲述了那次事故，第二天问题就修改了。这是一次很不错的选择。
有些时候，测试需要懂点儿心理学，知道如何找出别人心里的软处。
困境3：广度 vs 深度
你接到一个版本，开发修改了100行代码，你向他征求测试建议，结果得到了一个很明确的建议：全测！于是你需要测试4000个用例，在和安排两班倒之后的人力匹配后，你选择用例中标有“基本功能”属性的3000个，在15天内按时完成了这次任务。这是正确的选择吗？
有些时候，测试需要懂点儿架构设计，知道如何找出系统的风险。
困境4：感觉 vs 证据
你测完了一个特性，所有想到的地方都“挖”了一遍，你对这个特性的开发质量感到很满意，网上应用前景一片光明。但是，这个特性上一共只发现了5个缺陷，不满足发布标准中的“基线”要求，于是你被要求再做若干“专项”测试，反复折腾5天后，伴随着10个“提示性”缺陷，终于能够发布了。
有些时候，测试需要懂点儿统计学，知道如何找出真正有意义的数字。
某天和几位同事闲侃如何探知宇宙的边界，这个问题与测试有些类似，测试的组合是无穷尽的，在未踏到那一个“边界”时，你永远不能宣布：我看到了世界的全部。所以，这里列出的也并非测试所面临的全部选择难题，在测试书籍中也不会给出所有解决方法。不记得有多少次，我看到各种各样的测试技能模型，或者被要求提供一个测试技能模型，我想这些模型只是一个“起始”，而不是一个“终止”，任何学科的知识，只要能够解决我们面临的问题，都应该为我所知，为我所用，因此，我们应该并且必须从其他学科找出解决我们问题的方法。
最后，测试还面临一个永远存在的选择难题：
困境5：眼前 vs 长远
测试的资产要伴随产品的整个生命周期，而不仅仅是开发阶段。我们应该更关注发现问题，还是关注如何获得长期收益；我们应该拼凑人力来机械测试，还是构筑一个强有力的团队来支撑未来的产品演进？ 这个难题没有理论方法可以解决，只是，测试需要有一个梦想。
