软件测试培训之五个选择困境

软件测试培训之五个选择困境

困境1：信任 vs 怀疑

你收到一个需求，某人告诉你这个是关键特性，很重要，客户的需求很强烈，市场的要求很紧迫，涉及到几百万美刀。所以你暂停/减少了其他“非重要”特性的投入，先做这个特性的测试。过了几个月之后，你发现这个需求连实验局都找不到，并且从发布范围中悄悄地删掉了。这是一次不太好的选择。

有些时候，测试需要懂点儿需求工程，知道如何找出需求的价值。

困境2：坚持 vs 妥协

你发现一个问题，并且认为它是一个很重要的问题，但是提交后，你的开发认为这种场景有点儿天方夜谭，结论是不修改。但是你不甘心，你找到技术支持，翻出去年一个类似问题引发的网上问题，然后语气沉重、面带悲痛地向你的开发讲述了那次事故，第二天问题就修改了。这是一次很不错的选择。

有些时候，测试需要懂点儿心理学，知道如何找出别人心里的软处。

困境3：广度 vs 深度

你接到一个版本，开发修改了100行代码，你向他征求测试建议，结果得到了一个很明确的建议：全测!于是你需要测试4000个用例，在和安排两班倒之后的人力匹配后，你选择用例中标有“基本功能”属性的3000个，在15天内按时完成了这次任务。这是正确的选择吗?

有些时候，测试需要懂点儿架构设计，知道如何找出系统的风险。

困境4：感觉 vs 证据

你测完了一个特性，所有想到的地方都“挖”了一遍，你对这个特性的开发质量感到很满意，网上应用前景一片光明。但是，这个特性上一共只发现了5个缺陷，不满足发布标准中的“基线”要求，于是你被要求再做若干“专项”测试，反复折腾5天后，伴随着10个“提示性”缺陷，终于能够发布了。

有些时候，测试需要懂点儿统计学，知道如何找出真正有意义的数字。

某天和几位同事闲侃如何探知宇宙的边界，这个问题与测试有些类似，测试的组合是无穷尽的，在未踏到那一个“边界”时，你永远不能宣布：我看到了世界的全部。所以，这里列出的也并非测试所面临的全部选择难题，在测试书籍中也不会给出所有解决方法。不记得有多少次，我看到各种各样的测试技能模型，或者被要求提供一个测试技能模型，我想这些模型只是一个“起始”，而不是一个“终止”，任何学科的知识，只要能够解决我们面临的问题，都应该为我所知，为我所用，因此，我们应该并且必须从其他学科找出解决我们问题的方法。

最后，测试还面临一个永远存在的选择难题：

困境5：眼前 vs 长远

测试的资产要伴随产品的整个生命周期，而不仅仅是开发阶段。我们应该更关注发现问题，还是关注如何获得长期收益;我们应该拼凑人力来机械测试，还是构筑一个强有力的团队来支撑未来的产品演进? 这个难题没有理论方法可以解决，只是，测试需要有一个梦想。