閱讀《構建之法》第13-17章（包含讀後感）

第十三章 軟件測試

問題：軟件測試的步驟有哪些？

答：測試步驟

 　　　軟件測試的主要步驟有單元測試、集成測試和確認測試。

　　1.單元測試（unit testing）

　　單元測試也稱模塊測試。一般單元測試可放在編碼階段，程序員在編寫好一個模塊後，總會（也應該）對本身編寫的模塊進行測試，檢查它是否實現了詳細設計說明書中規定的模塊功能和算法。單元測試主要發現編碼和詳細設計中產生的錯誤，一般採用白盒測試。

　　測試一個模塊時須要編寫一個驅動模塊和若干個樁（stub）模塊，以下圖所示。驅動模塊的功能是向被測試模塊提供測試數據，驅動（即調用）被測模塊，並從被測模塊中接受測試結果。樁模塊的功能是模擬被模塊所調用的子模塊，它接受被測模塊的調用，檢驗調用參數，模擬被

　　調用的子模塊功能，把結果送回給被測模塊。在模塊結構圖中，頂層模塊測試時不須要驅動模塊，最底層的模塊測試時不須要樁模塊。

　　2.集成測試（integration testing）

　　集成測試也稱組裝測試，它是對由各模塊組裝而成的程序進行測試，主要檢查模塊間的接口和通訊。集成測試主要發現設計階段產生的錯誤，一般採用黑盒測試。

　　集成的方式可分紅非漸增式集成和漸增式集成。非漸增式集成是先測試全部的模塊，而後把這些模塊集成在一塊兒對整個程序進行測試。漸增式集成是將單元測試和集成測試合併在一塊兒，它根據模塊結構圖，按某種次序選一個還沒有測試的模塊，把它同已經測試好的模塊組合在一塊兒對整個程序進行測試，每次增長一個模塊，直至全部模塊所有集成在程序中。

　　漸增式集成又可分紅自頂向下集成和自底向上集成。自頂向下集成先測試上層模塊，再測試下層模塊。因爲測試下層模塊時它的上層模塊已測試過，因此能夠用其上層模塊做爲它的驅動模塊，而沒必要另編驅動模塊。自底向上集成先測試下層模塊，再測試上層模塊。一樣道理，在自底向上集成時可用下層模塊做爲上層模塊的樁模塊，而沒必要另外編寫樁模塊。

　　3.確認測試（walidation testing）

　　確認測試的任務是檢查軟件的功能、性能及其餘特徵是否與用戶的需求一致，它是以需求規格說明書（即需求規約）做爲依據的測試。確認測試一般採用黑盒測試。

　　確認測試首先測試程序是否知足需求規格說明書所列的各項要求，而後要進行軟件配置複查，特別是文檔是否齊全，各方面的質量是否符合要求等。若是一個軟件是爲某個客戶定製的，那麼最後由客戶來實施驗收測試（acceptance testing），以便客戶確認該軟件是否他所須要的。若是一個軟件是做爲產品被許多客戶使用的話，那不可能爲每一個客戶進行驗收測試。大多數軟件生產者使用一種Alpha測試和Beta測試的過程，來揭露僅由最終用戶才能發現的錯誤。

　　Alpha測試是在開發者的現場由客戶來實施的，被測試的軟件是在開發者從用戶的角度進行常規設置的環境下運行的。Beta測試是在一個或多個客戶的現場由該軟件的最終用戶實施的。與Alpha測試不一樣的是，Beta測試時開發者一般是不在場的。Alpha測試和Beta測試除了進一步發現程序中的錯誤外，還能發現使用上的問題。通過確認測試後的軟件一般就可交付使用了。

 

第十四章　質量保障

問題：軟件質量包括哪些方面？如何衡量軟件工程的質量？

答：軟件質量包括程序的質量，軟件工程的質量，軟件工程的質量體如今一下方面：

1.軟件開發過程的可見性

2.軟件開發過程的風險控制

3.軟件內部模塊，項目中間階段的交付質量，項目管理工具的因素

4.軟件開發成本的控制

5.內部質量指標的完成狀況

         運用CMMI模型管理項目，不只下降了項目的成本，還提升了項目質量和定期完成率

問題：測試人員如何體現工做的價值？

答：

1. 首先在需求討論上，測試人員能夠站在客戶角度上來闡述本身的觀點，和產品人員、開發人員等進行充分的交流和討論，使本身在用戶體驗、業務邏輯等等方面的經驗充分體現出來。
2. 在開發過程當中，測試人員不只扮演「用戶表明」角色，並且能夠及時提供更全面的質量反饋，包括代碼質量、接口一致性等。測試人員不寫代碼，能夠參與代碼複審（code review），將質量問題及時提交給項目組，保證在產品構造的整個過程當中質量受到足夠的關注，提升質量改進的持續性和可視性。
3. 測試人員仍是能夠參與單元測試。即便單元測試由開發人員作，測試人員能夠推動開發人員進行單元測，檢查單元測試狀態，如確保單元測試達到80%以上覆蓋率，以及幫助開發人員開發出具備良好可測試性的代碼。
4. 即便在敏捷方法中，集成測試、端到端（end-to-end）測試、性能測試等是不可少的。由於在敏捷方法中，每每將一個大的系統開發分解成多個小的子系統（模塊/組件），集成測試和端到端（end-to-end）測試顯得更重要。測試人員在功能測試上工做量會下降，但在這些測試上發揮更大的做用。
5. 隨着迭代的不斷深刻，迴歸測試的工做量很大，這也是測試人員的用武之地。 測試人員能夠針對穩定的產品特性開發自動化測試腳本，這也是一種持續的努力，使迴歸測試自動化。
6. 測試人員對缺陷進行分析，總結出一些規律，幫助開發人員創建良好的習慣，改進代碼的質量。

 

第十五章 穩定和發佈階段

問題：如何應對軟件發佈前軟件出現的各類問題？

答：1.會診小組：軟件團隊的各個角色表明組成會診小組。處理每個影響產品發佈的問題

2.複雜項目的會診：在穩定階段的初期，團隊只要決定須要修復哪些缺陷，而後團隊成員就會進行必要的設計、實現、測試工做，並簽入代碼修改

3.招數：設計變動：重寫或重構

4.招數：ZBB：把這一版本的構建把全部已知的Bug都解決掉

五、招數：最後迴歸測試：項目臨近結束時，全部人員（開發，管理，測試）都要回歸測試全部的Bug

6.招數：砍掉功能

7.招數：修復Bug的門檻逐漸提升

8.招數：逐步凍結，隨着程序功能的完善，咱們要讓程序的各個方面有次序地「凍結」，這樣才能把穩定的軟件交付給用戶。

 

第十六章 IT行業的創新

問題：創新的時機和創新的招數

答：任何技術都有自身的發展規律，隨着一個新技術經歷不一樣的階段，工總對它的指望值、炒做值也有很大的差異

1.技術觸發期

2.指望膨脹期

3.迷茫期

4.低調發展期

5.主流發展期

      接下來會列舉各類因素、原則分析問題的框架，並討論。

1.框架介紹：SWOT分析

2.棟樑和加速度

3.技術產品的發展週期  圖在書本321

4.效能過剩和競爭的各個階段  表格在書本322

5.影響產品競爭的各類因素    產品行業因素 公司和市場因素 團隊執行因素

6.四個象限劃分產品     （1）四種處理方式 維持，抵消，優化，差別化

                                 （2）把招數組合成套路‘打出組合拳 

第十七章 人，績效和職業道德

問題：團隊成長有幾個階段？

答：萌芽階段

磨合階段

規範階段

創造階段

連載《一個程序猿的生命週期》讀後感

談談若是本身處於那樣的位置，會怎麼辦？博主的經歷對本身有什麼啓發？   

      若是我處於主人公那樣的位置，我也會選擇D公司，或者是可以轉型的公司，總之不想作七年作的那樣重複的工做。

由於這也是對本身各方面能力提升的一次機會，若是不是很喜歡作程序員或者能力很好的話，始終有一天會厭倦，並且

很快被淘汰。第二，本身剛結婚，孩子也不大，換個輕鬆一點的工做仍是有必要的，這樣既能夠知足本身轉型的想法，

又能照顧好妻子和孩子。若是公司工資開始第一點仍是問題不大的，由於之後還有升值的空間，只要本身作的開心，認

真作，並且主人公原本就是個勤奮的人。

     主人公的工做前的經歷，我讀得比較慢，並且印象深入，由於本身和他有點類似，家裏由於一些特殊狀況，經濟不

是很好，要勤工儉學。可是這個過程的確學到不少東西，固然也經歷了不少，承受了不少壓力，有得有失，不是患得患失。

但願本身可以堅持，堅強，主人公文章中有不少道理都是從本身的實踐中得出來的，也是頗有用的，下面是一些文章一些

我認爲比較好的句子，但願能和你們一塊兒共享，努力在計算機這個行業有所成就。

 

１人生可能歷來未曾選擇過，只能一步一步走着，揹負着「山哈巴兒」的名聲開始人生新的階段。

２有時候人沒法改變本身，多是由於對現實還抱有幻想或心裏對本身的恐懼。

３人生老是曲折的，做爲個體是很好理解的，可是生活每每不只僅是以個體存在的，因此活着的意義也不僅是爲了本身，

不過咱們要堅信前途是光明的。

5人生總會有低谷，重要的是你可否承受光明到來以前的黑暗。

6人生中每次的努力都是播種下的種子，老是有收穫的時候，只不過收穫的週期有長有短。

7畢業的起點確認很低，不一樣層次的起點，能夠走入社會的心態不太同樣，我將以什麼樣的心態走進社會呢，磨練剛剛開

始。

8每一個人，總會有一段時期是要忍的，可是要知道本身的目標在哪？本身忍的底線在哪？本身給本身制定的原則是不能輕

易改變的。人是要本身規劃本身的道路的，可能會受到客觀因素的影響，可是不起決定因素，謀事在人、成事在天，經歷

的過程是你最大的財富。

     主人公畢業後的生活也是令我印象深入，由於他感覺到了社會的壓力，還有家庭的壓力，這樣的壓力是很恐怖的，不是

每個人都能承受，我相信要不是主人公從小開始獨立，他確定會崩潰的。從工做，戀愛到結婚，一路過的都不容易，可是

咱們不難發現，他仍是慢慢獲得了本身想要的生活。其實無論本身是什麼背景，身處那裏，只要本身肯勤奮，努力，堅持，

命運 不會把咱們逼上絕路。咱們的生活必定會愈來愈好。