第13章 軟體測試
1.名詞解釋
bug ：軟體的缺陷
test case ：測試用例。測試用例描述了乙個完整的測試過程，包括測試環境、輸入、期望的結果等
2.bug解釋與例項
<1>、bug可以分解為：症狀（symptom）、程式錯誤（fault）、根本原因（root cause）
症狀：即從使用者的角度看，軟體出了什麼問題
程式錯誤：即從**的角度看，**的什麼錯誤導致了軟體的問題
根本原因：錯誤根源，即導致**錯誤的根本原因
<2>、bug例子
症狀：使用者報告，乙個windows應用程式有時會有在啟動時報錯，繼而不能執行
根本原因：**並沒有確保建立子視窗，因此子視窗的handle變數有時會在訪問時處於未賦值狀態（為空），導致出現**錯誤
3.測試方法
<1>、黑箱：指的是設計測試的過程中，把軟體系統當做乙個「黑箱」，無法了解或使用系統的內部結構及知識。乙個更準確的說法是行為測試設計，即從軟體的行為，而不是從內部結構出發來設計測試
<2>、白箱子：指的是在設計測試的過程中，設計者可以「看到」軟體系統的內部結構，並使用軟體的內部結構及知識來選擇測試資料及具體的測試方法。
4.提問：我們軟體測試，是為了使用者使用時，少出先問題，但一些情況，自己在測試軟體時，有些問題是自己沒考慮到也沒測試出問題的，當使用者使用時，這時才不經意發現了這個錯誤，這種情況我相信是存在的，如何才能盡量避免這種錯誤呢？
第14章 質量保障
1.軟體質量
軟體 = 程式 + 軟體工程
軟體（質量） = 程式（質量） + 軟體工程（質量）
2.軟體質量的保障與軟體的測試
軟體測試：運用一定的流程和工具，驗證軟體能實現預先設計的功能和特性，工作的流程和結果通常是可量化的
軟體質量的保障工作：軟體團隊為了讓軟體達到事先定義的質量標準而進行的所有活動，包括測試工作
3.提問：軟體測試沒問題，那軟體的質量保障不也就沒問題了麼？？
第15章 穩定和發布階段
1.提問：從**完成到發布，這是乙個漫長的過程，但如果在一定困難下，中途停止了這個專案，並且在沒有其他資源的幫助，你會怎麼做？
第16章 it行業的創新
1.創新的源泉（個人感覺）
創新的源泉，來自於生活、實踐。比如：阿基公尺德，在洗浴城裡泡澡，發現浮力定律；牛頓，在蘋果樹下休息發現萬有引力理念等等
程式設計師的世界不是只有**，程式猿的世界不是只存在電腦和**，他們同樣也需要生活，他們也是普通人，創新的**，正是他們從生活中獲取靈感，轉化成他們手中的一把利劍（**），將之實現出來
2.提問：比如（假設而已），現在我有乙個非常好的靈感，認為這是乙個非常好的軟體，但所能實現出來是非常困難的，非我們學生能力所能做出來的，這時我們怎麼辦？
第17章 人、績效和職業道德
1.rasci模型
r：responsible，負責把具體事情做好
s：support，對任務提供支援，輔助任務的完成
c：consulted，諮詢，擁有完成專案所需的資訊或能力的角色
i：informed，知會者，應該事後及時通知結果的角色
2.團隊合作的階段：
<1>、萌芽階段，就像小苗破土而出，柔弱但充滿希望
<2>、磨合階段，就像乙個人的青少年時期，充滿了對個人、同伴和團隊的疑惑和衝突
<3>、規範階段，從磨合階段畢業，進入規範階段的團隊，成員們意識到光爭吵時沒有用的，大家還是要協同作戰
<4>、創造階段，經歷了萌芽、磨合、規範階段，現在團隊終於可以創造一些有意義的東西
3.不管從事哪乙個職業，不管你是屬於哪個崗位上的，都必須具有職業道德，軟體工程師同樣也需要
閱讀《構建之法》第10,11,12章
在10.3中提到團隊開發定製開發計畫 但我們在現實中不斷遇到的是在不斷變化的情況，有技術層面的，有系統衝突的，還有各種各樣的，如何才能從一開始就定製乙個永恆不變的計畫 在11.2.4中有寬嚴皆誤一說 我認為寬一定會助長消極情緒，倒不如在把時間直接分為兩部分前面嚴直到完成百分之80 85為止再去放鬆造...
閱讀《構建之法》第13 17章
第13章 通過場景內容進行測試驗收能很好讓人了解程式的 可用 度，能很好的反饋資訊給客戶 第14章 14.2.2問題1 既然有專人負責，那我就不用負責了 即使在開發的過程中有明確的分工，但不同人員之間要有密切的聯絡，而不是做完自己的部分就直接交個下一位，因為軟體的開發並不能如流水線生產一樣。第15章...
閱讀《構建之法》第8,9,10章
第八章 需求分析 本章節講述軟體需求的4個步驟，講述了9種使用者調研方法，nabcd模型和四象限方法，我覺得使用這幾個方法分析出來比較的具體，比自己空想要好，因為使用者的需求才是我們開發軟體的方向，如果方向錯了，只能是白做工。提出的問題 如果使用者需求很多很多，我們應該全部滿足，還是側重滿足?第九章...