构建之法阅读笔记05
又偷了几周的懒，阅读笔记的步伐又跟不上进度了，反省…..
上次看到了关于典型用户与场景的设计，跟着老师的步伐慢慢的走到了软件测试这个单元，对于这个部分，通过老师课堂的讲解印象最深的就是BUG，感觉这就是整个软件测试的核心。课下的阅读发现并不是这样的，BUG知识测试方法的一部分，但这依旧让我感受最深，可能这是对贴近我们生活的，也是目前我们软件接触到最常出现的问题，也是我们最常用的测试方法。
记得上课最开始老师就说过，对于编程能力较弱的同学来说，软件测试也许是一个新的方向，这让我心里有点小激动呢，因为我就是编程道路上的小菜鸟(真不是谦虚O(∩_∩)O)。也许一谈到软件测试在我们的印象中就是找几个特殊的数据测试一下就好了，在我们的潜意识里，我们对软件测试是存在误区的。比如，测试在项目的最后进行就可以了，测试就得根据规格说明书（spec）来测，所以是很机械的，测试人员当然也写代码，但是质量不一定要很高，测试只是被动地接受别人的产出，然后开始自己的工作，比较被动，不能发挥创造性。
对于软件测试，以前就是觉得这都是后续的工作了，需要程序编写完成后才可以进行测试，而且测试工作需要对程序很了解才知道如何下手进行测试，有时甚至都没有想过测试，觉得程序编写出来后就万事大吉了，有什么样的问题也不知道，最后导致程序出现局限性，就像老师说的：我编写的程序只能我自己用，别人一用就错。现在看来以前的认知都是错误的，对软件测试的理解不能停留在这样的表面。虽然我们不能更专业的去测试，也没有“黑箱”和“白箱”，但是我们可以从最基本的入手，发现一个问题是一个问题，改正一个问题对程序来说就是一件好事。做出来的作品是要给别人应用的，不能自己用着“完美”，别人用着“垃圾”啊。在以后的程序软件编写中，要随时进行测试，有些局部的小问题是不需要等到全部程序编写完成后才能测试出来的，多做测试程序就会更完善，获得别人的认可，这样做一个程序员才更加有价值啊。