軟件

 一用C#寫的winform調用webservice天氣預報小軟體教程用C#寫的winform調用webservice天氣預報小軟體教程我們來研究c#在winform上調用webservice實現一個的執行個體，開始之前先羅嗦幾句，對於webservice我之前從來沒有接觸過，今天突然想為自己的手機做個天氣預報小軟體，所以才開始看資料，上網查別人做的教程，很多都是一帶而過，大體的說該怎麼做，具體的卻很少，所以象我這樣的菜鳥基本是一頭霧水，沒辦法只有不斷的試，經過一中午的努力終於做出來了。下面我把

總體設計的任務根據使用者需求分析階段得到的目標系統的邏輯模型確定一個合理的軟體系統的體繫結構.包括劃分組成系統的模組,模組間的調用關係及模組間的介面關係,軟體系統所用的資料結構或者資料庫結構.軟體結構和過程軟體結構是軟體元素(模組)間的關係表示,而軟體元素間的關係是多種多樣的,如調用關係,內含項目關聯性,從屬關係和嵌套關係等,這些關係都可以表示為層次形式.階層是軟體結構廣泛應用的一種表示形式,因為它結構清晰,可理解性好,從而使可靠性,可維護性和可讀性都得到提高.以模組為軟體元素的階層是一種靜態階

   需求工程的基本任務是確定系統的目標和範圍,調查使用者的需求,分析系統必須做什麼,編寫需求規格說明書等其他相關文檔,以及需求工程審查.除此之外,還包括需求變更的控制,需求風險控制,制定需求過程的基本計劃等工作.    需求是指系統必須實現什麼的規格說明,他描述了系統的行為,特性或屬性,是在開發過程中對系統的約束.    不知道看到這樣兩個比較權威的定義,你被嚇到了沒有,我們往往是以謹慎+恐懼的態度對待官方的文檔和說明.我想寫一下自己對需求工程中各種問題的理解.  

寫這篇Blog，是為了記錄自己學習的過程。To be a senior software engineer,也許途中會留下很多辛勤的汗水與美好的回憶。也許，每個人都有自己心目中軟體工程師的樣子。我想把這些故事好好地寫下來，與大家一起分享。我並不那麼專業，所以這篇Blog可能看起來更像是一篇學習心得。我會按不同的主題寫成不同的章節。如果某一章涉及到的知識你不感興趣，你可以直接跳過。也希望這篇Blog對你有所協助。                                           

2.單薄的小人   上一節中我們展示了如何建立一個看似立體的情境，當然，我們只是靠一些紋理貼圖讓它看起來立體，而不是真正的去構建3D 模型。在這一節中，我們要在前面的情境中加入一些元素。我們把這些加入的元素想象成人、汽車或者是其他的一些東西。而我們的目標是讓它們看起來是在情境中移動。  

3.看起來不那麼像的汽車  讓我們回顧下上一節，我們構建了一個單薄的小人，可它看起來並不讓我們滿意。這一節中，我們將介紹：①構建一個三維情境，且裡面的物體也是立體的，我們的小人也是立體的。如果我們構造的物體看起來都差不多，我們會考慮使用displayList顯示列表②構建其他的三維情境，並且我們可以在需要的時候切換這些情境。這裡，我們學會構建一些類，用它來儲存

4.從milkshape3D匯入情境   前兩天突然就生病了。打完針輸完液慶幸只是國產的感冒。看來要加強運動啦。這一節我們將會在上一節的基礎上，研究構建我們三維情境的更高效途徑。首先，讓我們迴歸一下之前我們都完成了哪些：1.建立了一個三維情境2.用自訂檔案及資料格式的方式構建了我們需要的簡單對象(立方體，貝塞爾曲面)3.在以上的建模及編程中，我們用到了諸如顯示列表的一些東西  

Chapter 11

     三國中的諸葛亮能看破天象，對敵軍的破綻之處也更是了如指掌，死孔明嚇跑活仲達的笑話無人不知，無人不曉。作為軟體測試員就應該有孔明先生這樣的本領，測試員能該把軟體當作自己的敵人，兵法雲知己知彼方能百戰不殆。本節將總結黑箱測試中的又一常用方法——錯誤推測法。        在錯誤推測法中，測試員的角色就相當於三國中孔明的角色，測試員要根據自己的經驗，預測出軟體中哪些地方容易出現缺陷，我們應該怎樣發現缺陷，確保缺陷得以修複。    常見的輸入與輸出錯誤推測情況：     

     軟體測試是軟體生存周期中必不可少的環節，軟體的典型生存周期可以用來形容：                      軟體測試的目的是儘可能早的發現軟體缺陷並確保其得以修複，因此軟體測試是提高軟體品質的重要手段，大量的經驗實踐證明，軟體測試越早參與到軟體開發過程中，開發出來的軟體品質相對越高，時間和物力也越經濟。    根據軟體工程的基本理論，多模組程式的測試共包括以下4個層次：     各階段測試的具體內容會在以後章節具體介紹，下面介紹一下軟體測試的經典技術。   

   前面總結了軟體測試層次的各階段目標和任務等相關內容，接下來將總結軟體測試的經典方法，即黑箱測試和白盒測試。其中黑箱測試有等價分類、邊界值分析、錯誤推測和因果圖等經典分析方法，本節先介紹黑箱測試中的等價分類，也稱等價分配或等價劃分，即分步驟的把過多（無限）的測試案例減小到同樣有效小範圍過程。   

                從這一節開始即將總結白盒測試的常用經典技術。前面詳細總結了黑箱測試和一些常用的黑箱測試技術，但是都沒有開啟軟體的代碼進行測試，黑箱測試的概念就是針對白盒測試技術命名的，那麼什麼是白盒測試呢？白盒測試也稱結構測試，白盒測試是針對被測單元內部是如何工作進行的測試，深入程式碼細節，它根據程式的控制結構設計測試案例，主要用於軟體程式驗證。             

    經過了單元測試和整合測試的學習，組裝測試已經完成，接下來要進行的就是確認測試，那麼本節就主要介紹確認測試。確認測試又稱有效性測試或合格性測試，其任務是驗證系統的功能、效能等特性是否符合需求規格說明。如：   有效性測試和軟體配置審查是確認測試最重要的兩項工作。  

    經過了前面的總結，今天該到層次測試的最後一步——系統測試了，系統測試是驗收工作的一部分，應由使用者單位組織實施。軟體開發單位應該為系統測試創造良好的條件，負責回答和解決測試中可能發現的一切品質問題。   系統測試是在更大範圍內進行測試。除被測試程式外，系統還可能包括硬體和原有的其他軟體。系統測試的目的在於把軟體產品順利安裝到系統中以後，保證軟體與系統其餘部分協調工作，並且符合軟體需求說明書的要求。    下面說一下整合系統的測試，是整合系統測試的測試內容：          其中：   

            快世界末日了，不知道這軟體測試在傳說中的末日來臨之前還能總結完不，不管末日來不來，軟體測試的總結還得進行下去。好了今天開始總結邏輯覆蓋中的語句覆蓋。    什麼是語句覆蓋呢？從字面上理解，就是把程式碼每條語句都覆蓋了，至少都要執行一遍，其實意思也差不多。語句覆蓋是一個比較弱的測試標準，意在選擇足夠的測試案例，使得程式中每條語句至少都能被執行一次，下面舉一個小程式作為執行個體，希望大家能夠在這個例子中領會其中的思想。    程式的代碼：#include

 本節主要介紹一下層次測試的第一步——單元測試。在瞭解單元測試之前先看一個簡單的主程式樹狀模組圖：        所謂模組測試就是在底層進行的測試，如，單元測試就是測試中紫色的模組。單元測試是整個測試的基礎，單元測試中發現的錯誤約佔程式總錯誤數2/3，單元測試的目標是通過對程式底層模組的靜態和動態測試使底層模組達到模組說明的要求。   單元測試主要測試5方面的的問題：

前些時間學寫了軟體工程， 軟體工程總結分了兩個大的模組  面向過程 物件導向   的管理過程之後緊接著就是UML 的學習，這個是對軟體工程的進一步補充 ，是對設計中的一些類圖，部署圖等的設計。再後來就是C#,設計模式的學習 這些都是對物件導向的進一步理解 ，發現他們之間或許應該有些聯絡，這個也是有人問起我的，雖然知道它們之間有聯絡，但是也沒有什麼總結的，只有別人問起來才去總結，真的有些慢的呀。 畫了一個小小的圖先簡單描述下它們的關係啦

        說到雲端，大家可能並不太熟悉，我瞭解雲端，是從我的C盤“變紅”開始的，由於安裝軟體時經常不小心選擇預設安裝，導致C盤慢慢被不必要地“佔領”。於是我開始接觸到了雲端，並搜集整理了一些資料供大家參考。         雲端概念        所謂“雲端”其實就是泛指“網路”，名稱來自工程師在繪製時，常以一朵雲來代表網路。凡是運用網路溝通多台電腦的運算工作，或是透過網路連線取得有遠端主機提供的服務等都可成為雲端服務。              解決我所遇到的軟體佔用了磁碟空間的問題通過

點擊開啟圖片連結軟體專案計劃（Software Project Planning）是一個軟體項目進入系統實施的啟動階段,主要進行的工作包括:確定詳細的項目實施範圍、定義遞交的工作成果、評估實施過程中主要的風險、制定項目實施的時間計劃、成本和預算計劃、人力資源計劃等。　在軟體專案管理過程中一個關鍵的活動是制定專案計劃，他是軟體開發的第一步，專案計劃的目標是為項目負責人提供一個架構，使之能合理地估算軟體項目開發所需的資源 、經費和開發進度，並控制軟體項目開發過程按此計划進行。

文章目錄 2.3.1程式2.3.2文檔2.3.3服務2.3.4非移交的產品 1. 引言1.1編寫目的1.2背景1.3定義1.4參考資料2.項目概述2.1工作內容2.2主要參加人員2.3產品2.3.1程式2.3.2文檔2.3.3服務2.3.4非移交的產品2.4驗收標準2.5完成項目最遲期限2.6本計劃的批准者和批註日期3.實施計劃3.1工作任務的分解與人員的分工3.2介面人員3.3進度3.4預算3.5關鍵問題4.支援條件4.1電腦系統支援4.