年初的一个PPT，围绕着软件测试整理出来的几个观点
全面测试
已发布软件的所有功能都将进行测试，如果不是由我们自己测试，那就要由最终用户测试。为了避免这种情况发生，我们要对软件进行全面测试，无情测试。
一定要期待我们的软件当中有问题，测试是努力发掘这些错误的过程。测试是技术，更是一种态度。要理解和接受我们自己肯定会犯错，关键是要尽早发现，在发布前修复它们。任何软件团队都会犯错误，优秀的团队有勇气面对自己的错误并不断改进。
早测试，常测试
随着项目的进行，软件的功能越来越多，越来越复杂，发现遗留BUG的成本就会越高。一个BUG存在的时间越长，发现他的成本就会越高。
我们可以进行增量迭代式开发，完成一个模块的编码后就要进行充分测试，持续集成。写一点程序就测一点，早测试、常测试，去降低发现bug的成本。
加强研发内部测试（成本考虑）
我们假设一方测试后修复一个bug的成本是1，那么二方是3，三方是10，到了客户那儿发现的问题，它的修复成本就有可能达到100。越靠近我们研发，牵扯的人员越少，造成的影响越小，修复成本也越低。越往后，不仅仅是修改代码的时间成本，还要加上人员之间、部门之间、客户之间的沟通成本，还要有客户关系损失等这些高昂的隐形成本。最理想的情况就是发现和修复缺陷的人就是制造缺陷的人。想要提高效率，就要将测试的工作量向上游推进，加强研发内部测试。
加强研发内部测试（项目进程考虑）
测试驱动项目
测试可以作为项目的心跳去驱动项目的进程。我们开发一个功能，只有完成了测试，我们才能这个功能完成了。测试是集成在开发中的持续行为，而不是单独的活动。传统上，我们很自然地会更重视编码，但只要提升对测试的重视程度。为测试所付出的努力，一定会收到事半功倍的效果。
测试获取项目状态
测试衡量当前项目产出、度量质量、暴露项目风险、为我们提供持续反馈，我们要利用这些反馈去调整项目前进的节奏和方向，控制项目正常进行。反馈非常重要，反馈的越早，留给我们的时间越多，我们的风险就会越低，反馈的越频繁，我们改进产品、积累经验的机会就会越多。一方测试为我们提供这种最直接的反馈。
以上说明的是我们研发内部测试的重要性。软件开发与足球比赛有一点相似，就是防守做的好的球队，一定不是仅仅依靠几个优秀的后卫，从前场丢球后的反抢，防守就已经开始了。测试也一样，要贯穿到整个开发进程。
第三方测试
研发面对三方测试要建立我们的乙方心态，将验证组看做是我们的最终客户。提交三方测试前一定是研发内部进行了充分测试，主观认为软件已经达到了可以直接下发到客户使用的程度。
不要依赖于验证组，当依赖于别人帮我们发现错误的时候，我们犯错的勇气和概率一定会更大。将验证组看做是最后一道防线。清楚他们的重要性，但不依赖验证组。不依赖于验证组发现我们基本的程序错误。要将三方测试发现的每一条BUG当成是我们的研发的意外收获和额外收获，要反思为什么我们没有发现。一个事实就是：我们提交的质量越高，他们的起点就会越高，最终我们产品的发布标准也会更高。
产品发布
产品发布的同时，也发布了我们的名声。团队的名声在公司内部传播，公司名声在客户中间传播。只有实现公司内部的部门之间的客户满意度，才能有公司外部的客户满意度。研发团队和测试团队都要对发布的产品有信心，测试就是帮我们是建立这种信心的过程。
如果我们付出努力，不轻易妥协。即使用户还能反馈bug，那我们也只能接受，下一个轮次继续改进。测试也是资源的综合权衡。不存在完美软件，但我们可以训练我们自己发布足够好的软件 --- 对于当时的时间段，当时的市场环境，对于未来的开发者，关键是对于我们自己内心的安宁来说足够好。
每个人都会犯错，人们一般可以原谅错误。我们所处的行业也不是对错误零容忍的行业。关键在于我们的产品给客户留下的什么样的印象。如果我们以往的记录良好，偶尔犯错客户也能容忍，但如果我们没有一个良好的记录，或错误太多或作为市场后来者，那想要扭转这个局面，我们就要付出比一开始成几倍的努力。
测试的扩展
前面关注的这些只是软件测试中的程序方面的测试。像需求评审，架构评审，界面评审这些都是软件测试。并且这些阶段引入缺陷的修复成本会更大。
任何时候只要我们想提交或发布一些东西，那这些就需要有测试。不管是对内还是对外，阶段或成品。同样对于软件测试的认识和态度可以扩展到其他领域。我们发送一个电子邮件也需要进行测试。
