跟其他小组的情况一样，我们的团队项目爬虫到目前为止已经有了一个初步的开发，下周一应该可以有一个小的展示了。

我在团队项目中被安排做测试部分。上周和这周的课老师讲的是测试部分需要做哪些工作，有哪些需要注意的地方。

为此我制定了一个测试计划，主要分为两部分：

第一部分是单元测试，也就是分模块进行。PM分工时，一共划出了5个模块。对每一模块给出若干样例输入，观察输出结果是否达到预期效果。

在设计样例的时候，应该首先在本地爬取，并使样例具有很好的可重复性。

第二部分是总体功能测试，需要数据源和服务器支持，对代码的总体效果和性能进行分析。

看了几篇阅读材料后，我对测试工作又有了一些新的认识。

如果这是事实，软件开发总是非常苦难的，天生没有银弹。（If this is true, building software will always be hard. There is inherently no silver bullet.）

国外的神话故事不太懂，狼人是无敌的，只有银弹可以射杀狼人……不过用在软件开发方面到是很贴切，没有一个像万能钥匙一样的模式，能解决我们工作中出现的所有问题。“我们必须看到这样的畸形并不是由于软件发展得太慢，而是因为计算机硬件发展得太快。从人类文明开始，没有任何其他产业技术的性价比，能在30年之内取得6个数量级的提高，也没有任何一个产业可以在性能提高或者成本降低方面取得如此的进步。软件的特性本身也导致不大可能有任何的发明创新——能够像计算机硬件工业中的电子器件、晶体管、大规模集成一样——提高软件的生产率、可靠性和简洁程度。”Frederick P. Brooks, Jr.先生在原文中也很好的解释了这一点。

系统需求—软件需求—软件分析—程序设计—代码实现—软件测试—运行维护

这是一个较完备的瀑布模型，它的特点是，每一步都是在其上一步和下一步的基础上实现的。前一步是后一步的基础，后一步是前一步的反馈。虽然各步互相依存，但是非相邻的两步却没有太大的联系。我们的团队项目目前还没有到最后一步，关于软件测试的环节，我之前的想法是等各模块的代码完成后再发给我，我整合到一起做测试，当然这样的想法是错误的。测试工作应该反馈到每一个环节上。

大泥球方法很符合我们的工作进展。其实我觉得测试要做的就是就是把蔓延到每一个分支的小泥球想办法打扫干净。每一个团队都希望代码的开发能够像瀑布模型那班行云流水，飞流而下三千尺。实际中总是各种各样的混乱，测试工作应该像打通关节疏散拥塞那样，让团队项目的泥球越滚越小。

大泥球发生的主要原因可以归结为：

• 一次性代码
• 碎片式增长
• 为了让软件不出问题
• Copy/paste导致问题转移（有问题的代码被复制到很多地方，不断蔓延）

关于敏捷编程，实际上我们的项目进展中非有意的就使用了这种思想。因为并不是所有人都能像规划中的那样按部就班，有条不紊，按照计划好的分工认真而勤恳的完成自己的工作。实际中大家写作业的时候都是这样，发现软件工程课有个团队大作业，然后要写代码，然后PM指定了模块内容，然后去学习相关理论知识，然后分析代码样例，然后边写边改。不过敏捷还是非敏捷，大泥球总是会出现。敏捷是一种思路和方法。

总体来讲，把几个阅读材料综合在一起，从大的方面来看，我似乎从时间和空间两方面略窥到了目前整个IT行业和市场的一些情况。

时间上，一个代码的开发过程就好像先建立一个较完备的瀑布模型，具体执行时又会出现大泥球，然后使用敏捷方法解决这些问题。

空间上，在开源软件运动盛行的今天，我们的IT行业就好像欧洲古典的城镇中心，一座座别有异域风格的大教堂小教堂周围，又摆满了各种各样大的小的摊子。你手里拿着一张全城地图，穿梭在密集的跟你一样目的和职业的人群中，寻找需要的艺术品。