跟其他小組的情況一樣，我們的團隊項目爬蟲到目前為止已經有了一個初步的開發，下周一應該可以有一個小的展示了。

我在團隊項目中被安排做測試部分。上周和這周的課老師講的是測試部分需要做哪些工作，有哪些需要注意的地方。

為此我制定了一個測試計劃，主要分為兩部分：

第一部分是單元測試，也就是分模塊進行。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行業就好像歐洲古典的城鎮中心，一座座別有異域風格的大教堂小教堂周圍，又擺滿了各種各樣大的小的攤子。你手里拿著一張全城地圖，穿梭在密集的跟你一樣目的和職業的人群中，尋找需要的藝術品。

轉載于:https://www.cnblogs.com/fenglq/archive/2012/11/14/2769239.html

總結

以上是生活随笔為你收集整理的阅读作业二：团队项目与测试工作的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。