軟體工程測試心得體會

　　軟體工程經濟是近年來出現的嶄新的研究方向，是軟體工程和經濟學相互融合深入的產物。下面是有，歡迎參閱。

　　範文1

　　時間飛逝，不知不覺間《軟體工程》的學習已經過了大半了。在這將近半學期的學習中，雖然我不能說我將《軟體工程》學習的有多麼的好，但是通過學習，我還是受益良多。

　　在以前，我一直對軟體存在一些偏見或則是誤解，認為軟體就是程式，軟體的開發就是編寫程式，只要編完了程式，一切也就ok了，而且我還片面的認為只要我掌握了時下最新的語言和工具，那麼我就能寫程式了。一個人，只要會程式設計，就能寫軟體，就是程式設計師;一個公司，只要招聘一些程式設計師，就能開發好的軟體產品。只要有幾個有經驗的程式設計師，再找些兼職的大學生，就能組成一個軟體公司。

　　但是通過了《軟體工程》這門課的學習，使我認識到了我以前的錯誤。軟體其實不僅僅是程式，軟體開發其實也不僅僅是編寫程式，軟體是思想在硬體上的載體和體現，處理的是邏輯和資訊。唯有對軟體和軟體的開發過程，有充分的認識，才能更好的開發出，過程受控、質量受控的軟體產品。

　　而且在以前，我一直以為軟體的開發其實是一件很輕鬆快樂的事情，只要一天坐在電腦旁敲敲鍵盤，那麼一切就可以了，但是現在我才發現，我以前的很多的思想是多麼的膚淺可笑。程式設計其實是一種樂趣和苦惱共存的一項創造性活動。因為程式設計不僅能夠滿足我們內心深處進行創造的渴望，而且還能愉悅我們內在的情感。

　　而且通過學習《軟體工程》，我還學到了很多其他的東西。比如通過學習《軟體工程》，特別是老師每次用實際的軟體現場的講解，為我提供了一個儘早接觸世界工作和真實專案的機會。讓我知道如何在以最小的成本中，訓練自己的基本工程素質和能力，如何激發自己的積極性等。而且通過學習《軟體工程》，還讓我認識和培養了我的團隊協作能力，特別是對於我們這些在校的學生來說，這種學習更是能讓我在以後工作中少走很多的彎路。

　　所以，通過《軟體工程》的學習，我是真的學習到了很多有用的東西，讓我明白了很多的道理。在此我對老師的辛勤教育表示感謝，因為是你讓我學習到了這些，是我獲益良多。

　　範文2

　　在本學期的軟體工程課程的學習中，我們學習了十一章的內容。第一章軟體與軟體工程的概念，這一章主要講解的是一些概念性和基礎性的內容，例如軟體的概念、特性，軟體危機的主要表現，軟體工程的概念以及軟體生存期、典型生存期模型等等。第二章軟體工程方法與工具，這一章主要對軟體工程方法進行介紹，包括三種方法：傳統方法、面向物件方法、形式化方法。還引出了工具UML。第三章軟體需求獲取與結構化分析方法，本章詳細介紹了需求獲取與需求分析階段的任務以及結構化分析方法，畫分層的資料流圖、E-R圖以及狀態圖式本節的重點。第四章結構化分析方法，這一章重點講解了使用變換型對映方法和事務型對映方法生成初始的模組結構以及模組結構的改進。第五章編碼，這一章重點講解了編碼的風格及規範，還告訴我們編碼規範說帶來的好處，並告誡我們將來一點要形成好的編碼風格。第六章軟體測試方法，本章講解了軟體測試相關的概念及重要性，軟體測試與開發各個階段的關係;還介紹了白盒測試技術以及黑河測試技術。第七章統一建模語言UML概述，本章詳細介紹了UML的基本模式、事物、關係及建模時用到的各種圖進行了介紹。第八章面向物件分析，這一章主要講解了面向物件分析的3種模型，包括功能模型、靜態模型和動態模型。第九章軟體體系結構與設計模式，本章對軟體體系結構的基本概念、典型風格等進行了講解。第十章面向物件設計，本章的重點是對面向物件分析時建立的物件模型進行調整和細化。第十一章軟體維護，本章主要介紹軟體維護的任務、軟體維護活動以及軟體維護方法進行了介紹。

　　要學習軟體工程，學會如何系統的思考，以及養成良好的編碼習慣，想學好軟體工程，就必須知道軟體工程的目標、過程和原則：軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文件為使用者可用的程度。開銷合宜是指軟體開發、執行的整個開銷滿足使用者要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。

　　軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構，包括子系統、模組以及相關層次的說明、每一模組的介面定義。詳細設計產生程式設計師可用的模組說明，包括每一模組中資料結構說明及加工描述。實現活動把設計結果轉換為可執行的程式程式碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足使用者的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支援過程、培訓過程等。

　　軟體工程的原則是指圍繞工程設計、工程支援以及工程管理在軟體開發過程中必須遵循的原則。

　　我們學習了詳細設計的方法，其原則是過程描述是否易於理解、複審和維護，進而過程描述能夠自然地轉換成程式碼，並保證詳細設計與程式碼完全一致。包括程式流程圖、N-S圖、PAD圖、HIPO圖

　　程式流程圖：程式流程圖又稱之為程式框圖，它是軟體開發者最熟悉的一種演算法表達工具。它獨立於任何一種程式設計語言，比較直觀和清晰地描述過程的控制流程，易於學習掌握。在流程圖中只能使用下述的五種基本控制結構：順序型;選擇型;while型迴圈;until型迴圈;多情況型選擇。

　　N-S圖：一種符合結構化程式設計原則的圖形描述工具，稱為盒圖，又稱為N-S圖。在N-S圖中，為了表示五種基本控制結構，規定了五種圖形構件。順序型;選擇型;WHILE重複型;UNTIL重複型;多分支選擇型。

　　PAD圖：它是用結構化程式設計思想表現程式邏輯結構的圖形工具。PAD也設定了五種基本控制結構的圖示，並允許遞迴使用。

　　HIPO圖：HIPO圖是由一組IPO圖加一張HC圖組成。它是美國IBM公司在軟體設計中使用的主要表達工具。

　　HC圖既是層次圖，用於表示軟體的分層結構。HC圖中的每一個模組，均可用一張IPO圖來描述。IPO圖由輸入、處理和輸出三個框組成，需要時還可以增加一個數據檔案框，這種圖形的優點，是能夠直觀地顯示輸入—處理—輸出三者之間的聯絡。

　　還有測試方法:按照測試過程是否在實際應用環境中來分，有靜態分析與動態測試。測試方法有分析方法***包括靜態分析法與白盒法***與非分析方法***稱黑盒法***。

　　靜態分析技術：不執行被測軟體，可對需求分析說明書、軟體設計說明書、源程式做結構檢查、流程分析、符號執行來找出軟體錯誤。

　　動態測試技術：當把程式作為一個函式，輸入的全體稱為函式的定義域，輸出的全體稱為函式的值域，函式則描述了輸入的定義域與輸出值域的關係。

　　還學習了其他很多工具、語言、方法等，雖然不是都學得很透徹，但我相信在今後的學習中一定會慢慢的完善的。

　　範文3

　　軟體工程心得體會未接觸軟體工程之前一直都很想學這門課程，因為覺得這門課很牛，是那些有工程師稱號的高手才擺弄的東西。學了一個學期的軟體工程課，終於知道了個軟體工程的大概。學的時候總覺得很抽象，理解起來好像不難，但總是摸不著頭腦一種很茫然的感覺。曾經以為程式就是軟體，軟體就是程式。學習這門課程第一個收穫是，知道了二者的不同之處。以前做過的一些小型的軟體比如加密軟體，我也只是在程式旁邊附上一個軟體的說明，看來已經很接近作坊了。不過大的專案沒有接觸過，用軟體工程的方法還是第一次。我想也是程式的不斷複雜化導致了軟體危機的發生，使得人們不得不探索新的解決方法。

　　經過倪老師的講解，理解了軟體工程，就是一套用於軟體的團隊開發，以提高軟體質量和程式設計師工作效率為目的的規範。其核心就是，對於軟體開發的5個重要組成部分：需求分析，設計，編碼，除錯，維護，如何組織這5個部分的工作，以及如何完成每一個工作。吾生也有涯，而知也無涯，學習永無止境。起初，對軟體工程處於一知半解的狀態，分工比較混亂。

　　在劃分模組後明確了各自分工，漸漸形成良性迴圈。在學習過程中，知道了團隊合作十分重要，爭議固然存在，但通過討論、協商，群策群力，在不斷磨合中能夠達成一致與默契。團隊成員中能力各有高下，互相尊重，各取所長，不宜妄自菲薄。組長多加協調，組員積極配合，才能合作愉快。學習能力體現在能儘快接受新的知識，順應變化，學為所用。

　　上《軟體工程導論》這門課，我的收穫大概如下：我們為什麼需要軟體工程呢?上面已經給出了一些原因。專業點講，軟體工程最終是為了實現“軟體製造業”的社會化,工業化大生產,提高其勞動生產效率。只有如此,軟體業才能實現社會化,工業化大生產,才能“做大做強”。沒有管理的設計是失敗和混亂的設計，沒有設計指導的程式設計是無序的忙碌的。根據開發的軟體的規模，應該適當程度的運用軟體工程化的思想，需要靈活，畢竟我們開發的軟體大多數是中小型的，大型的並不多見***我是這麼認為的***。但只要涉及人員間的交流和溝通，或多或少都要需要軟體工程才能更有效率，工作成果更穩定。

　　其實開發軟體，就像是解決一個邏輯問題。想想自己平時是怎樣寫程式的。首先是要有一個想法，即我寫的這個程式是要幹什麼的;然後就是對要實現的核心功能大概構思一種或多種實現方法，並從中選出一種自認為是較好的;接下來就是將涉及的各種主要或次要功能分成各個模組;最後就是分模組來編碼和DEBUG。在我看來，除了第一步外，其餘的步驟應該是一個迴圈的過程。在編碼的過程中，你總是需要不斷地回過頭來修改原先的模組設計，甚至最初選定的實現演算法。具體到每一步的工作要怎樣完成，是非常靈活的，只要把握住大體的方向就行。在進行分析，設計，編碼，除錯，維護這幾部分的工作的時候，最核心的就是文件的編寫。1.可行性分析就是關於當前專案能不能幹的分析結果。

　　2.專案描述這是在決定立項以後，對當前專案的一份扼要說明。

　　3.需求分析就是對客戶要求的功能的定義。

　　4.軟體設計這就是對程式的每一個模組的詳細設計的說明文件。

　　5.開發日誌我一直都認為這是文件中最有趣的部分。開發日誌相當於編碼階段的文件，它的形式可以很隨意，主要是記錄一些在寫程式時突然萌發的靈感，或對程式碼的一些微小的修改，或對程式結構的一些微小變動等，還要對上述這些修改變動作些說明。

　　6.測試分析用於指出程式存在或潛在的缺陷和錯誤，以及程式效能的數字描述。

　　
看過的人還：