只是看书看到了一句话：测试优先，单元测试有利于解耦，系统测试有利于架构。
测试优先，对于一个刚跨出学校，跨入软件测试行当的学生来讲，有着致命诱惑。因为作为软件工程的学生，选择做测试好像就是专业没学好的意思。在软件测试课程上，我对软件测试产生浓厚兴趣，但老师说，测试啊？门槛低，我们是做开发的。但我不这么认为。软件开发行业现在的效率很高，但在我看来，仅仅是效率很高罢了。软件质量，一直以来都是困扰开发人员的一大障碍。对于自己的代码，开发人员，可能仅仅是我，有着足够的信心，在bug出现的时候，很难发现自己代码中的缺陷，因为我并不相信我的代码在很简单的地方出问题，我也只会去看那些复杂算法哪里有错。但出错最多的，往往是开发人员认为最不可能出错的地方（也可能仅仅是我）。这时需要一个白盒测试人员。
搞测试的，我相信没有人不知道测试要和开发同步进行才最好，如果只是系统测试和交付测试，发现了质量问题也只能想办法掩盖（是掩盖，不是修改）。因为软件已然成型，一些“小问题 ”没必要大动干戈去重构代码，这个不太重要按钮不能按，工期很紧，那怎么办？反正在我的经验里，直接注释掉按钮。以后有时间了，下个版本把注释取消修改修改还多个功能呢！！可能就是这个注释，导致了极差的用户体验。我站在用户的角度上来说，你开发的有多难关我毛事，你产品不好，又不是只有你能做。。。。。。好吧，这个产品作废了，然后开会会怎么讲呢？我并不想说出来。我只是想说，如果从需求开始测试，然后设计上测试，单元测试，集成测试，系统测试…………这个问题可能不会出现。就算出现了，有集成测试和单元测试的底子，找出问题并予以解决会很容易。
进行全面测试代价很高，很多公司只进行功能测试。就算如此，功能测试搭建自动化测试平台和自动化脚本库也很费成本。测试行业在兴起，但貌似又举步维艰。测试之路，我才刚刚开始。
我只是一个新人，认识可能不到位。发发牢骚，继续加班。第一篇日志，就算做和各位前辈打个招呼吧。