第五次寫閱讀筆記了。
第十三章：軟體測試
這章講了各種測試方法和測試的設計方法。一些基本的名字解釋：bug：軟體的缺陷，可分為：症狀、程式錯誤、根本原因；test case：測試用例，描述完整的測試過程；test suite：測試用例集。按測試方法可分為黑箱和白箱；按測試目的可分為：功能測試、非功能測試；也可以按測試的時機和作用分類。測試方法有前面提過的單元測試和**覆蓋率測試，也有構建驗證測試、驗收測試、「探索式」測試、回歸測試、場景/整合/系統測試、夥伴測試等。測試的目的便是保證軟體的美觀、執行穩定等。實戰中測試的核心任務是：在滿足最低接受條件的前提下，提高各個部分的質量。測試中也有一些似是而非的觀點，測試中也需要建立一些文件：測試設計說明書、測試用例、錯誤報告、測試修復，關閉缺陷報告、測試報告。軟體的開發很難，會出現很多問題，我們要學會改錯、交流測試經驗。
第十四章：質量保障
軟體由使用者的需求而生，可它的質量是否完美呢？軟體質量=程式質量+軟體工程質量。軟體開發過程有三個主要特性：好、快、便宜。軟體工程的質量體現在：軟體開發過程的可見性、軟體開發過程的風險控制、軟體內部模組，專案中間階段的交付質量，專案管理工具的因素、軟體開發成本的控制、內部質量指標的完成情況。cmmi的實施能夠提高企業的管理水平，降低企業的成本。swebok特別定義了軟體質量成本的組成成分，其中包括預防、評審、內部故障、外部故障四個方面，作者認為還要加上流程分析改進、投資改進等各種成本。軟體質量保障工作：軟體團隊為了讓軟體達到事先定義的質量標準而進行的所有活動。測試的角色應該有，獨立的測試角色存在也會出現各種問題。
第十五章：穩定和發布階段
乙個團隊經歷多個階段，達到**完成這一目標，然而軟體生命週期的最後階段往往是最考驗團隊的。軟體團隊的各個角色代表會組成會診小組，處理每乙個影響產品發布的問題。在穩定階段的初期，團隊只要決定需要修復哪些缺陷，但是隨著專案的進展和發布日期的臨近，團隊還要保證修改方案不會給產品帶來負面影響。會診會議也有了更高的要求，包括：開發者提交參加會診的bug和修改方案；會議決定是否同意修改方案；執行。設計變更、zbb、最後回歸測試、砍掉功能、修改bug的門檻逐漸提高、逐步凍結都是常用招式。不同頻率和不同覆蓋範圍的漸進發布，大約一月一更。發布之後，也要開會議，稱為事後諸葛亮會議。
軟體測試也很重要，做好軟體開發的每一步。
個人感受
1.在以前的程式設計中，測試的用例並不是很全面，有一些東西都沒有想到。
2.軟體質量=程式質量+軟體工程質量。軟體開發過程有三個主要特性：好、快、便宜。
3.以後會多考慮一下情況，完善用例。
構建之法閱讀筆記05
時隔多日，自己又重拾 構建之法 今天對需求分析這部分進行了閱讀。當我們程式設計師在編寫軟體之前要做的就是了解使用者的需求，準確而全面地找到需求主要有以下幾個步驟 1 獲取和引導需求 elicitation 我們需要找到軟體的利益相關者，了解和挖掘他們對軟體的需求，引導他們表達出對軟體的需求。很多時候...
構建之法閱讀筆記05
本次閱讀了第十三 軟體測試 十四章 質量保障 在軟體發布前基本沒有進行測試，直到上台講述的之前的一段時間才發現了一些問題，甚是著急 第十三章中excel計算1900閏年錯誤的例子給了我乙個全新的概念 要服務於最主要的功能.傳說中的拐點 小飛 我聽說在軟體專案中，有這樣乙個拐點存在 在這一點之前，新的...
構建之法閱讀筆記05
這是構建之法的最後一篇閱讀筆記 這幾天主要閱讀了it的創新這一章，創新在現代的社會中是乙個被說爛了的詞語，各行各業都在提倡創新，就連學校裡也在提倡什麼創新創業大賽 在 構建之法 的創新迷思一節，列舉出了七個迷思，接下來分別作出乙個簡要的概述。迷思之一 偉大的創新總是靈光一現。迷思之二 大家都喜歡創新...