在这篇文章里，以下一些观点我相当的赞同，我再按照我自己的理解为自己也为各位读者做一个总结

　　首先一点，测试只是在反馈信息。换个方向来说，测试不是用来做其他事比如排错什么的。这个观点在原文里用了一个非常好的比喻：测试好比是在体检，他只会给你一个身体的状况报告，至于你是否健康，跟体检没有任何的关系。这个问题的实质其实是牵涉到一个责任的问题。在我目前的项目中，后都会有一个流程，项目组长问测试人员是否还有问题，可不可以上线。表面上看测试是质量把关的后一道关卡，但这道关卡不应该有责任说产品是否能上线。还是以体检为例子，测试人员的主要职责是告诉你身体的一个状况，但身体是否健康，到后还是由自己说了算，体检人员不会也不能帮你做决定说你是否需要治疗，他只能给你体检数据让你作为参考。回到软件开发来说，后的流程应该是项目组长决定是否能上线因为这本来是他自己的责任，测试人员也不应该给出是否能上线的意见，只用反馈测试结果行。

　　第二点，测试要跟随着开发进度走，从一开始开发甚至开发还没开始，测试应该开始了。我目前的项目有这么一个问题，因为测试人员不够的原因，测试只能被安排到后，这样做有个大的缺点，原文说得很好我直接引用一下：如果开发的产品本身质量低劣，进行测试你不觉得是浪费大家的时间吗？一段时间发现的缺陷越多，并不意味着剩下的缺陷越少，而是意味着会出现更多的缺陷。公司目前重做之前做的一个项目。这个项目在重做之前，测试回馈的错误很多，但都有计划得在修改，但是测试回馈的bug，并没有随着时间减少，这个项目组的开发人员压力相当得大，却始终做不出完全合格的产品来，加上需求也不固定，整个项目是混乱两字。后来实在受不了排错的压力，上层决定将其重做。这个项目照理说不会有这么多问题，一开始规划都定得很好，但还是难免会出现这种情况，除了跟程序员的素质有关，跟需求的变动有关（这个说起来应该算是公司常犯的问题），大的原因我想还是出测试的安排上。项目开始的时候，如果没有测试的规范，程序员会开始有不自信的感觉，这种不自信会导致更严重的失去信心，导致敷衍完事，反正后有测试嘛。这样做出来的程序，说出去能让用户安心使用吗？

　　第三点是属于我自己的认识，重视测试，重视自动化测试，重视TDD。这个观点我接着上个观点说：很多公司都有一个毛病（从我自己的角度来看），需求爱变动，不喜欢按照以前定好的计划实施。但是我们必须承认，变化总会是有的，我们应该时刻拥抱变化，这里又会说到敏捷开发了，我会在以后的文章里分享一下我对“敏捷”的认识。回到变化这个问题。变化意味着代码的变动，代码的变动意味着出错的风险，风险会给程序员以及整个项目组带来不自信。而测试正是带来自信的良药。所以一定要重视测试。但在目前公司，由于以上说的各种原因，另外加上测试都是人肉式手工测试，导致测试人员压力颇大。任何人在这样的团队，谁不会担心“我还有什么没有测到？”，谁又能给测试人员带来自信呢？我觉得作为一个程序员，忽视自动化测试是一个很愚蠢的行为。程序员是什么？程序员是利用电脑给人类带来劳动解放的职业。如果不进行自动化测试，那是程序员连自己都不知道怎么利用电脑为自己解放劳动力，这样的程序员又哪来的素质去想着帮别人解放劳动力呢？当TDD这个概念出来的时候，所有的程序员都应该兴奋，团队需要的自信，团队需要的劳动力解放，都在里面体现了。当我们面对更快的变化，当我们重构更多的代码的时候，请一定要想起使用TDD。

　　我们是程序员，我们在用电脑改善别人的生活前，一定要先学会用电脑改变自己的生活