大家肯定都有這種經歷，老師給了程式**模板，我們稍稍去該一些地方，完成需要的實驗任務，然後丟到一邊置之不理，從來沒有過軟體測試的概念。，閱讀之後發現軟體測試的方法很多，比如單元測試，**覆蓋率測試，構建驗證測試，驗收測試，探索式的測試，回歸測試，場景/整合/系統測試，夥伴測試，效能測試，壓力測試，內部/外部公開測試易用性測試等等，當我們只是為了某個目的去看待乙個**的時候，目光就會很淺，不能發現程式本身的錯誤與不足，於是我們就需要一些比較合適的測試方式來對我們的**進行測試以達到更好的水準。
在我們的產品出世之後，我們需要進行使用者場景分析，到底我們的軟體產品，會有什麼樣的使用者？這些使用者會用它來做什麼？他們會怎麼來進行操作？我們需要盡可能詳細的場景分析，從使用者角度出發，設身處地的去考慮，去揣摩使用者的心理，把握使用者的使用者體驗，檢測到使用者在使用過程中會遇到哪些問題以便我們解決，以及在任何環境下或者使用者（外行人）的任何操作都必須讓軟體看起來是正常的，也就是傳說中的換位思考，把自己當場乙個不太了解電腦的使用者來做軟體。
關於"寫文件"這件事,王老師也一直在強調寫文件的練習，可以看得出"寫文件"對於我們也很重要，這與**注釋一樣代表我們願意與人交流，願意與人合作，這樣才會有人願意跟我們共事，通過寫文件來對自己的工作或者一段**的總結很有必要，而且要寫的讓別人能看懂，能讓別人知道你都做了什麼，是怎麼做的，甚至達到它能去接著你的做，這樣的文件才是好文件，這樣總結不僅對自己是乙個提高，也是團隊合作的一種形式。
在今後的學習中，我也要漸漸學會去寫文件，打打這種基礎，對自己的程式也要做一些測試，進步是一點一點的。
構建之法閱讀筆記05
時隔多日，自己又重拾 構建之法 今天對需求分析這部分進行了閱讀。當我們程式設計師在編寫軟體之前要做的就是了解使用者的需求，準確而全面地找到需求主要有以下幾個步驟 1 獲取和引導需求 elicitation 我們需要找到軟體的利益相關者，了解和挖掘他們對軟體的需求，引導他們表達出對軟體的需求。很多時候...
構建之法閱讀筆記05
本次閱讀了第十三 軟體測試 十四章 質量保障 在軟體發布前基本沒有進行測試，直到上台講述的之前的一段時間才發現了一些問題，甚是著急 第十三章中excel計算1900閏年錯誤的例子給了我乙個全新的概念 要服務於最主要的功能.傳說中的拐點 小飛 我聽說在軟體專案中，有這樣乙個拐點存在 在這一點之前，新的...
構建之法閱讀筆記05
這是構建之法的最後一篇閱讀筆記 這幾天主要閱讀了it的創新這一章，創新在現代的社會中是乙個被說爛了的詞語，各行各業都在提倡創新，就連學校裡也在提倡什麼創新創業大賽 在 構建之法 的創新迷思一節，列舉出了七個迷思，接下來分別作出乙個簡要的概述。迷思之一 偉大的創新總是靈光一現。迷思之二 大家都喜歡創新...