拿互联网产品和传统的桌面产品来比较，对桌面型产品来说，缺陷的修复成本足够高(只能通过软件召回或是发布补丁的方式)，因此对缺陷的容忍度低;而对于互联网产品来说，由于其产品的修复成本足够低(对一个已知的缺陷，可能只需要花上几分钟到几十分钟能完全修复了)，因此相对而言，其对缺陷的容忍程度更高(当然，对于那些会导致用户数据损失或是带来其他不可逆破坏的缺陷，那又另当别论了)，对互联网产品开发来说，及时识别缺陷(发现那些用户已经遇到的缺陷)，快速定位缺陷和快速修复缺陷的能力往往要比在系统测试阶段发现缺陷的能力更重要。而要能有强大的识别缺陷和定位缺陷的能力，必须依靠产品内建的“开发质量”了。
　　再以医疗行业的某些软件为例，对涉及到医疗器械的控制软件(如自动注射器，心脏起搏器等)，其对缺陷的容忍程度非常低，原因很简单，因为这类缺陷可能带来的后果太严重。
　　3.第三个因素是“有效的测试方式”。
　　对互联网产品来说，有效的测试方式也许并不是找一堆专职的测试工程师在公司内部尽可能地覆盖每一个功能细节，让真正的用户来对产品进行测试在很多情况下也许是更好的选择。无论是FB，Google等公司提倡的dog food(让全部员工来进行测试)，还是在实际产品上进行的a/b testing，或是游戏公司通常喜欢采用的内测方式，都是典型的让用户参与测试的方法。另外，根据产品不同的特性，适合采用手工测试还是自动化测试的方式来进行测试也是一个值得考虑的点。
　　4.第四个因素则是“产品的开发团队所处的状况”，因此，对同一个组织来说，在组织发展的不同阶段，所需要的测试也是不同的。
　　“苦逼的团队是做不出有爱的产品的”，自然，“苦逼”的团队也不可能达成好的测试。因为让每个人疲于奔命的是总也无法完成的任务和无止境的加班，恐怕都没有停下来思考如何改进的机会。
　　以上是我对“什么样的产品需要什么样的测试”这个问题的理解。在这四个因素的指导下，再回头来考虑不同软件产品的测试，很容易理解为何不同的产品，不同的企业会采用很不相同的测试方式。例如，FB没有专职的测试工程师，因为通常意义上关注“用户质量”的测试工程师并不能在这个组织中发挥大的价值，只有对开发有深入了解的开发工程师才能真正的在提高“开发质量”方面发挥作用。而对于许多国内的以“做项目”为主的软件企业来说，也很好理解为什么他们只需要“能像客户一样发现产品中的缺陷的”的测试了。