軟件工程15我的閱讀做業2

閱讀《構建之法》提出的問題

Q一、經過好的單元測試就能說明程序是好的嗎？

本書第21頁，做者提到

「如何能讓本身負責的模塊功能定義儘可能明確，模塊內部的改變不會影響其餘模塊，並且模塊的質量能穩定的、量化的保證？單元測試就是一個頗有效的解決方案。"

對此我產生疑惑，經過好的單元測試就能說明程序是好的嗎？單元測試有什麼作不到的地方嗎？
(1)單元測試解決不了設計失誤帶來的問題，即便最低劣的設計也可能經過單元測試。單元測試只是能測試模塊的質量好壞，至於設計的好壞是沒法測試出來的。
(2)單元測試不能解決產品的可用性和易用性問題。產品的可用性和易用性跟用戶有關，單元測試的測試數據也這是機器產生或開發者自行設計的數據，並不包括圖形界面的美觀，功能界面的設計。書後面有提到能夠用迴歸測試解決。在書第13.1.1節也就是281頁，做者提到

另外一個例子是軟件的「易用性測試」，在設計此類測試時，不必糾纏於程序的內部結構，而是應該着重於軟件的界面和行爲。

這句話也說明了對於解決易用性，單元測試是不適用的，這時候就要用到黑箱測試，同時做者也提到軟件易用性測試須要不少專業知識。

(3)單元測試解決不了因爲設計和編碼不當帶來的性能問題。
(4)單元測試一般不能解決類和類的一些邏輯問題。
(5)單元測試不能用來測試須要很長時間才能完成的操做(例如：數據鏈接超時)

我認爲單個模塊質量高當然好，可是軟件是總體，應該經過多種測試，而不是單一對某個模塊或功能進行測試。（在第13章有詳細給出其餘測試的方法和做用。）

下面是對好的單元測試不理解的地方：
在這本書第26頁，做者在講好的單元測試的標準其中一個標準是

「單元測試事後，機器狀態保持不變」。

我當時看到這個標準第一反應是什麼是機器狀態？單元測試不是測試程序，怎麼跟機器狀態扯上關係？雖做者有解釋說這樣就能夠不斷地運行單元測試。對於這個解釋，我仍是很不理解做者是怎麼提煉這個標準，如何作到這個標準。
我以爲我首先要先明白什麼是機器狀態。爲此我上網查了一下，並無一個系統的解釋。（有可能我查閱的資料不夠多。）我大概理解爲內存、寄存器等的狀態。也就是說機器狀態不變應該是說代碼運行過程當中，怎麼調用，變量放在哪一個內存，地址是啥，測試單元不能進行干預。換句話說測試單元不會改變程序運行的總體功能。因此測試單元應該作到只是提供測試的數據，而不能有改變被測試程序的語句或者記錄。可是測試單元原本就是測試，通常人不會在測試單元寫能夠執行改變程序的代碼。後來看到做者提到測試單元建立了臨時的文件或目錄應該在Teardown階段刪除。那什麼是Teardown階段？

teardown標記單元測試完成並開始回收初始化數據垃圾

Teardown階段的理解仍是不是很清楚，可能須要本身實際動手寫一次單元測試纔會清楚。

Q二、關於迴歸測試最好要自動化的問題

在本書2.1.3節也就是書第29頁，做者有寫道

「迴歸測試最好要自動化。」

緣由是能夠對於每個構建快速運行全部迴歸測試，以保證儘早發現問題。對於爲何有迴歸測試咱們是知道了，可是如何作到迴歸測試自動化和何時不須要自動化（由於做者用了「最好」這個詞，也就是說也能夠不用）做者並無詳細說明。
那我仍是以爲先知道什麼是迴歸測試?做者對迴歸測試中的「迴歸」，理解爲「迴歸到之前不正常的狀態」。我當時看到這句話，腦中只有不理解。你代碼改進後，哎呀你狀態還還有迴歸到不正常的狀態。這是啥意思？這個不正常的狀態應該是指未修改程序以前的狀態。我以爲這句話很讓人誤解。我以爲迴歸測試是修改了舊代碼後，從新進行測試以確認修改沒有引入新的錯誤或致使其餘代碼產生錯誤的時候作的。那你既然修改了代碼，而一些測試用例可能會失去針對性和有效性，而另外一些測試用例可能會變得過期，還有一些測試用例將徹底不能運行，也就是說你的測試數據也會有改變，怎麼能回到不正常的狀態呢？那我不是又回去了？我認爲是測試的態度是要像第一次測試的態度才比較合理。
那回來講一下自動化迴歸測試怎麼自動？以我如今目前所瞭解是可使用自動測試工具。基於沒有真正使用自動測試工具，我仍是說一下爲何最好自動化的問題。爲何要自動化？由於每次重複的的迴歸測試所需時間太長，並且每每被證明功能並沒有明顯變化。我以爲關鍵仍是懶吧！！那自動化後，你就不用手動作，多爽啊，爲何不用？可是你要懶也要必須知道怎麼懶？自動化迴歸測試你須要知道測試將覆蓋哪些功能、自動測試架構還要選擇迴歸測試自動化所使用的工具。再知道這些狀況下你才能夠作到自動化測試，否則你測試出來的結果你可能本身都不相信是對的。因此不知道如何自動化測試的時候，不用硬要自動化（固然能夠學習後使用）。並且也不是手動就很差。在迴歸測試:人工測試仍是自動化?的博客有提到

手工測試的優勢是清楚地看到 - 它不依賴於任何東西，能夠在全部的時間完成。拋棄手動測試不會帶來什麼好處。自動和手動測試是相互聯繫，相輔相成的測試方法，每一個人都有優勢和缺點。思考迴歸方案的自動化以前先考慮爲其編寫測試和支持的時間支出。另外，要注意手動測試專家一般薪水比那些擁有將測試自動化技能的人要低。

可是我我的認爲仍是要自動化，畢竟科技再進步。（可能我也懶吧）

Q三、對開放-封閉的原則的理解？

做者在書38頁，提到了

開放-封閉的原則，對其解釋是「軟件實體應該是能夠擴展的，同時是不可修改的」。

個人理解應該就是擴展是開放的，修改是封閉的。雖然字面上的意思能懂，可是仍是比較抽象。但願有具體的例子能夠更好的解釋這句話？或者說具體該如何作到？

可能我的緣由對於這種一對矛盾的詞語的原則，感受這真的很矛盾。你說讓人有開放又封閉的，是要開放仍是封閉？糾結啊！可是想到這一對矛盾的詞說的是不一樣的動詞就不會以爲矛盾。也就是說這個原則能夠分爲兩個原則，一個是模塊擴展原則，一個是模塊修改原則。我認爲這樣比較好理解。

Q四、有關敏捷流程的問題

做者在第六章詳細的寫了敏捷流程。對於這個章節，在敏捷流程第二步是決定當前的衝刺須要解決的事情，那若是在這互相關聯的階段出現bug是不是直接進入下一階段仍是停留該階段直到解決？那這樣是否就不夠敏捷？做者在介紹敏捷流程的問題其中一個是

各個需求和任務之間是有複雜的依賴關係的，除了優先級外，咱們還要考慮相互依賴關係。怎麼在計劃中體現依賴關係？

是否意味着沒法分析細化關係，敏捷流程只能停留在第一步？或者若是在第一步沒有計劃好，是否致使整個項目的失敗？

Q五、對於軟件測試方法的理解

做者在第13章寫了不少關於軟件測試的方法，共有12個測試方法。可是我看完之後以爲有的測試本質實際上是差很少的，就是可能叫法不一樣側重點不一樣。那爲何把差很少的測試方法歸爲一種，把測試方法分爲代碼前期測試，代碼完成後測試，可用性測試等。我我的認爲構建驗證測試跟迴歸測試沒什麼很大的區別，都是再修改代碼後進行的測試。那我作了迴歸測試後還須要作構建驗證測試嗎？還有「小強」大掃蕩測試跟「探索式的測試，若是在公司作了「小強」大掃蕩測試，公司成員已經作了能夠稱爲「探索式的測試的測試（由於公司成員在大掃蕩過程能夠就是隨機的測試），那麼還須要在特地的作「探索式的測試嗎？對於現實生活中的項目，這十三種測試都須要一個個測試嗎？

附加題

豆瓣連接：https://book.douban.com/annotation/54370216/