ERP監理方法系列：編碼、測試階段的監理工作

編碼監理

　　軟體編碼監理的主要目的是為了控制軟體編碼階段的工程進度，監督軟體編碼的程式設計風格和品質，使得軟體編碼階段的工作能可靠、高效地實作軟體設計的目标，同時符合承建機關的軟體過程規範的要求。

　　一、軟體編碼監理的目标

　　1）監督承建機關定義和綜合軟體編碼任務，并在生産軟體的過程中始終如一地執行這些任務。

　　2）監督使得軟體工作産品彼此間保持一緻性。

　　3）監督使得軟體編碼的工作進度與計劃保持一緻性。

　　4）監督使得軟體編碼的工作品質達到計劃的要求。

　　二、軟體編碼監理的活動

　　1）監督承建機關将合适的軟體編碼工程方法和工具內建到項目定義的軟體過程中。

　　（1）依據項目定義的軟體過程對軟體編碼任務進行綜合。

　　（2）選擇軟體編碼可用的方法和工具，并将選擇專用工具或方法的理由寫成文檔。對備選方法和工具進行選擇的依據是：

　　● 機構标準軟體過程

　　● 項目定義的軟體過程

　　● 現有的技術基礎

　　● 可得到的教育訓練

　　● 合同需求

　　● 工具的能力

　　● 使用的友善性和提供的服務

　　（3）選擇和使用适合于軟體編碼的配置管理模型。配置管理模型可能是：

　　● 入庫出庫模型

　　● 組合模型

　　● 事務處理模型

　　● 更改處理模型

　　（4）将用于軟體編碼的軟體産品和工具置于配置管理之下。

　　2）監督承建機關依據項目定義的軟體過程，對軟體編碼進行開發、維護、建立文檔和驗證，以實作軟體需求和軟體設計。

　　（1）參與軟體編碼的人員評審軟體需求和軟體設計，以確定影響編碼的各種問題得到識别和解決。

　　（2）使用有效的程式設計方法編制軟體代碼。程式設計方法可能是：

　　● 結構化程式設計

　　● 代碼重用

　　（3）根據一個計劃制定代碼單元的開發順序，該計劃考慮諸如關鍵性、難度、內建和測試問題；合适時，還要考慮客戶和最終使用者的需要。

　　（4）每個代碼單元完成編碼時，通過評審和單元測試。

　　（5）将代碼置于配置管理之下

　　（6）每當軟體需求或軟體設計更改時，适當地更改代碼。

　　3）軟體監理組跟蹤和記錄軟體編碼産品的功能性和品質。跟蹤和記錄的内容有：

　　（1）跟蹤、累計的軟體編碼産品缺陷的數量、類型和嚴重程度

　　（2）軟體編碼産品工程活動的狀态

　　（3）有關問題嚴重性和持續時間的報告

　　（4）用于分析每個更改建議的工作量及彙總統計量

　　（5）按類别（如界面、安全性、系統配置、性能和可用性）被納入軟體基線的更改數量

　　三、軟體編碼監理的方法

　　1）定期審查軟體編碼的工程活動和工程進度。

　　2）根據實際需要對軟體編碼工程活動、工作進度進行審查。

　　3）對軟體編碼工程活動和産品進行評審和（或）稽核，并報告結果。這些評審和（或）稽核至少應包括：

　　● 軟體編碼工程任務的準備就緒和完成準則得到滿足。

　　● 軟體編碼符合規定的标準和需求。

　　● 已完成所需的測試。

　　● 檢測出的問題和缺陷已建立文檔，并被跟蹤和處理。

　　● 通過軟體編碼，對設計的跟蹤得以實施。

　　● 在軟體産品送出前，依據軟體基線驗證了用來管理和維護軟體的文檔。

　　四、軟體編碼走查的監理

　　程式實際上也是一種供人閱讀的文章，有一個文章的風格問題。應該使程式具有良好的風格。表現在：源程式文檔化，資料說明的方法，語句結構和輸入／輸出方法。是以在進行編碼監理時重點從一下幾個方面把握：

　　1）源程式文檔化

　　（1）符号名的命名

　　符号名即辨別符，包括子產品名、變量名、常量名、标号名、子程式名、資料區名以及緩沖區名等等。這些名字應能反映它所代表的實際東西，應有一定實際意義。例如，表示次數的量用Times，表示總量的用Total，表示平均值的用Average，表示和的量用Sum等等。

　　名字不是越長越好，應當選擇精煉的意義明确的名字。必要時可使用縮寫名字，但這時要注意縮寫規則要一緻，并且要給每一個名字加注釋。同時，在一個程式中，一個變量隻應用于一種用途。

　　（2）程式的注釋

　　夾在程式中的注釋是程式員與日後的程式讀者之間通信的重要手段。注釋決不是可有可無的。一些正規的程式文本中，注釋行的數量占到整個源程式的1／3到1／2，甚至更多。注釋分為序言性注釋和功能性注釋。

　　序言性注釋通常置于每個程式子產品的開頭部分，它應當給出程式的整體說明，對于了解程式本身具有引導作用。有些軟體開發部門對序言性注釋做了明确而嚴格的規定，要求程式編制者逐項列出。有關項目包括：程式标題；有關本子產品功能和目的的說明；主要算法；接口說明：包括調用形式，參數描述，子程式清單；有關資料描述：重要的變量及其用途，限制或限制條件，以及其它有關資訊；子產品位置：在哪一個源檔案中，或隸屬于哪一個軟體包；開發履歷：子產品設計者，複審者，複審日期，修改日期及有關說明等。

　　功能性注釋嵌在源程式體中，用以描述其後的語句或程式段是在做什麼工作，或是執行了下面的語句會怎麼樣。而不要解釋下面怎麼做。要點：描述一段程式，而不是每一個語句；用縮進和空行，使程式與注釋容易差別；注釋要正确

　　（3）标準的書寫格式

　　視覺組織用空格、空行和移行來實作。恰當地利用空格，可以突出運算的優先性，減少發生編碼的錯誤；自然的程式段之間可用空行隔開；移行也叫做向右縮格。它是指程式中的各行不必都在左端對齊，都從第一格起排列，這樣做使程式完全分不清層次關系。對于選擇語句和循環語句，把其中的程式段語句向右做階梯式移行。使程式的邏輯結構更加清晰。

　　2）資料說明

　　在設計階段已經确定了資料結構的組織及其複雜性。在編寫程式時，則需要注意資料說明的風格。為了使程式中資料說明更易于了解和維護，必須注意以下幾點。

　　（1）資料說明的次序應當規範化

　　資料說明次序規範化，使資料屬性容易查找，也有利于測試，排錯和維護。原則上，資料說明的次序與文法無關，其次序是任意的。但出于閱讀、了解和維護的需要，最好使其規範化，使說明的先後次序固定。

　　（2）說明語句中變量安排有序化

　　當多個變量名在一個說明語句中說明時，應當對這些變量按字母的順序排列。帶标号的全程資料也應當按字母的順序排列。

　　（3）使用注釋說明複雜資料結構

　　如果設計了一個複雜的資料結構，應當使用注釋來說明在程式實作時這個資料結構的固有特點。

　　（4）語句結構

　　在設計階段确定了軟體的邏輯流結構，但構造單個語句則是編碼階段的任務。語句構造力求簡單、直接，不能為了片面追求效率而使語句複雜化。

　　比如：在一行内隻寫一條語句；程式編寫首先應當考慮清晰性；程式要能直截了當地說明程式員的用意；除非對效率有特殊的要求，程式編寫要做到清晰第一，效率第二，不要為了追求效率而喪失了清晰性；首先要保證程式正确，然後才要求提高速度，反過來說，在使程式高速運作時，首先要保證它是正确的；避免使用臨時變量而使可讀性下降；讓編譯程式做簡單的優化；盡可能使用庫函數；避免不必要的轉移；盡量采用基本的控制結構來編寫程式；避免采用過于複雜的條件測試；盡量減少使用“否定”條件的條件語句；盡可能用通俗易懂的僞碼來描述程式的流程，然後再翻譯成必須使用的語言；資料結構要有利于程式的簡化；程式要子產品化，使子產品功能盡可能單一化，子產品間的耦合能夠清晰可見；利用資訊隐蔽，確定每一個子產品的獨立性；從資料出發去構造程式；不要修補不好的程式，要重新編寫。

　　3）輸入和輸出

　　輸入和輸出資訊是與使用者的使用直接相關的。輸入和輸出的方式和格式應當盡可能友善使用者的使用。一定要避免因設計不當給使用者帶來的麻煩。是以，在軟體需求分析階段和設計階段，就應基本确定輸入和輸出的風格。系統能否被使用者接受，有時就取決于輸入和輸出的風格。輸入／輸出風格還受到許多其它因素的影響。如輸入／輸出裝置（例如終端的類型，圖形裝置，數字化轉換裝置等）、使用者的熟練程度、以及通信環境等。不論是批處理的輸入／輸出方式，還是互動式的輸入／輸出方式，在設計和程式編碼時都應考慮下列原則：

　　（1）對所有的輸入資料都要進行檢驗，識别錯誤的輸入，以保證每個資料的有效性；

　　（2）檢查輸入項的各種重要組合的合理性，必要時報告輸入狀态資訊；

　　（3）使得輸入的步驟和操作盡可能簡單，并保持簡單的輸入格式；

　　（4）輸入資料時，應允許使用自由格式輸入；

　　（5）應允許預設值；

　　（6）輸入一批資料時，最好使用輸入結束标志，而不要由使用者指定輸入資料數目；

　　（7）在互動式輸入時，要在螢幕上使用提示符明确提示互動輸入的請求，指明可使用選擇項的種類和取值範圍。同時，在資料輸入的過程中和輸入結束時，也要在螢幕上給出狀态資訊；

　　（8）當程式設計語言對輸入／輸出格式有嚴格要求時，應保持輸入格式與輸入語句的要求的一緻性；

　　（9）給所有的輸出加注解，并設計輸出報表格式。

　　測試監理

　　目前國内資訊ERP應用系統建設過程中，在此階段常發生未經過嚴格系統測試就匆忙上線試運作的情況，這往往會造成不穩定的新系統對實際工作環境的影響，在某些情況下會阻礙系統的正式上線運作。

　　是以監理機關在此階段主要檢查承建機關是否按照設計中制定的規範與計劃進行測試。但切忌由監理機關進行單元、內建或确認測試而取代開發方的内部測試，這種方法并不能保證工程的品質。

　　如果監理機關具有豐富的測試工作資質與經驗，可以考慮在此階段由監理方在業主機關、承建機關的配合下具體進行系統測試工作。由于監理機關對工程建設啟動階段、需求分析階段、設計階段、實作階段的工作有深入的了解，由監理機關進行系統測試工作往往能夠得到較好的效果。

　　一、軟體測試監理的目标

　　1）監督和控制承建機關的軟體測試過程，確定軟體測試按照承建機關的測試文檔規範和業主的軟體要求實施；

　　2）軟體測試反映出、記錄着軟體産品的真實情況；

　　3）軟體測試的各個階段按計劃步驟實施；

　　4）對于軟體測試反映出的問題能有效地按回歸測試規範進行處理；

　　5）最後得到符合軟體任務書（或合同）要求的軟體産品集；

　　6）軟體測試的進度與計劃保持一緻性。

　　二、軟體測試監理的活動

　　1）監督承建機關将合适的軟體測試工程方法和工具內建到項目定義的軟體過程中。

　　（1）依據項目定義的軟體過程對軟體測試任務進行綜合。

　　（2）選擇軟體測試可用的方法和工具，并将選擇專用工具或方法的理由寫成文檔。對備選方法和工具進行選擇的依據是：

　　（3）選擇和使用适合于軟體測試的配置管理模型。配置管理模型可能是：

　　（4）将用于測試軟體産品的工具置于配置管理之下。

　2）監督承建機關依據項目定義的軟體過程，對軟體測試進行開發、維護、建立文檔和驗證，以滿足軟體測試計劃要求。軟體測試由靜态測試、單元測試、內建測試、确認測試和系統測試組成。

　　（1）可以客戶和最終使用者一同參與開發和評審測試準則。

　　（2）使用有效方法測試軟體。

　　（3）基于下列因素确定測試的充分性：

　　● 測試級别。測試級别有：單元測試、內建測試、确認測試和系統測試。

　　● 選擇的測試政策。測試政策有：功能測試（黑盒測試）、結構測試（白盒測試）和統計測試。

　　● 欲達到的測試覆寫。測試覆寫方法有：語句覆寫、路徑覆寫、分支覆寫和運作剖面覆寫。

　　（4）對每個級别的軟體測試，建立和使用測試準備就緒準則。确定測試準備就緒準則包括：

　　● 軟體單元在進入內建測試前已成功地完成了代碼的靜态測試和單元測試

　　● 在進入系統測試前，軟體已成功地完成了确認測試

　　● 在軟體進入系統測試前，已對測試準備就緒進行評審

　　（5）每當被測試軟體或軟體環境發生變化時，則在各有關的測試級别上适當進行回歸測試。

　　（6）對于測試計劃、測試規程和測試用例，準備使用前通過評審

　　（7）管理和控制測試計劃、測試說明、測試規程和測試用例。

　　（8）每當軟體需求、軟體設計或被測試代碼更改時，适當地更改測試計劃、測試說明、測試規程和測試用例。

　　3）監督承建機關依據項目定義的軟體過程，計劃和實施軟體的确認測試。

　　（1）基于軟體開發計劃，制定确認測試計劃并寫成文檔。

　　（2）負責軟體需求、軟體設計、系統測試及驗收測試的人員，評審确認測試用例、測試說明和測試規程。

　　（3）依據指定的軟體需求文檔和軟體設計文檔的指定版本，進行軟體确認測試。

　　4）計劃和實施軟體系統測試，實施系統測試以保證軟體滿足軟體需求。

　　（1）盡早配置設定測試軟體的資源，以做好充分的測試準備。所需的測試準備活動包括：

　　● 準備測試文檔

　　● 準備測試資源

　　● 開發測試程式

　　● 開發模拟程式

　　（2）編制系統測試的計劃文檔，如果合适，該測試計劃由業主機關進行評審和認可。此測試計劃包括：

　　● 全面測試和驗證的方法

　　● 測試職責

　　● 測試工具、測試裝置和測試支援需求

　　● 驗收準則

　　（3）由一個獨立于軟體開發者的測試小組來計劃和準備所需的測試用例和測試規程。

　　（4）在測試開始前，對測試用例建立文檔，并經評審和認可。

　　（5）依據已納入基線的軟體及其軟體任務書（或合同）和軟體需求文檔，實施軟體測試。

　　（6）對測試中發現的問題建立文檔，并跟蹤到關閉。

　　（7）建立測試結果文檔，并以此作為判斷軟體是否滿足需求的基礎。

　　（8）管理和控制測試結果。

　　5）軟體監理組跟蹤和記錄軟體測試的結果。跟蹤和記錄的内容有：

　　（1）跟蹤、累計的軟體産品缺陷的數量、類型和嚴重程度

　　（2）軟體測試工程活動的狀态

　　三、軟體測試監理的方法

　　1）定期審查軟體測試的工程活動和工作進度。

　　2）根據實際需要對軟體測試工程活動進行跟蹤、審查和評估。

　　3）對軟體測試工程活動和産品進行評審和（或）稽核，并報告結果。這些評審和（或）稽核至少應包括：

　　● 軟體測試工程任務的準備就緒和完成準則得到滿足。

　　● 軟體測試符合規定的标準和需求。

　　● 通過軟體測試，軟體産品符合軟體需求的要求。