資訊工程系.pptVIP

13.7.4　改正錯誤 一旦發現一個臭蟲，它必須要被改正。 臭蟲的改正可能引進其他的錯誤，損害因此會比好處多。 Van Vleck提出三個在進行移除臭蟲起因的「更正」前，每位軟體工程師應該要問的問題： 臭蟲的起因會在程式的其他部分重新產生嗎？ 在許多情形中，程式的錯誤是由邏輯的錯誤模式所造成，它也可能在其他地方重新產生。 明顯地考慮邏輯模式可導致其他錯誤結果的發現。 改正錯誤 由於我所修定而可能引起的「下一隻臭蟲」是什麼？ 在改正之前，原始碼(或更好的是設計)應該評估已確定的邏輯與資料結構的耦合。 如果在程式高度耦合的部分進行改正，當進行任何改變時，必須要特別的謹慎。 開始的時候我們可以做什麼以避免臭蟲嗎？ 此問題的第一個步驟是朝向建立一個統計的軟體品質保證方式。 如果我們改正流程與產品，臭蟲將從現有的程式中移除，也可能從未來的所有程式中移除。 13.5.3 Alpha與Beta測試 對一位軟體開發者實際上是不可能預知顧客將如何實際地使用一支程式。 使用的指令可能會被誤解； 可能習慣性地使用奇怪的資料組合； 對測試者似乎很明確的輸出，對現場的使用者可能是難以理解的。 驗收測試 當為顧客建造客製軟體時，一系列的驗收測試(acceptance tests)會被導入以讓顧客可以確認所有的需求。 由終端使用者所主導而非軟體工程師，此驗收測試範圍可以從非正式的「測試驅動(test drive)」到有計畫與有系統地執行一系列的測試。 驗收測試可能被導入超過數個星期或數月之久，因此可以揭發出可能降低系統的累積錯誤。 Alpha與Beta測試 如果軟體被展發成為一個讓許多顧客所使用的產品，但要對每一個人進行正式的驗收測試是不務實的。 大多數軟體產品的建構者使用稱為alpha與beta測試的流程，以揭發出只有終端使用者可能發現的錯誤。 Alpha測試由終端使用者在開發者的地方所導入的。 軟體在很自然的設定下，開發者仔細檢查典型的使用者並記錄其錯誤與使用問題。 alpha測試在一個受到控制的環境中被導入。 Beta測試在終端使用者的地方被導入。 不像alpha測試，開發者通常是不在的。 beta測試是一個軟體「活的」應用，它在不受開發者所控制的環境中。 終端使用者記錄在beta測試期間遇到的所有問題(真正的或想像的)，並向開發者定期報告。 在beta測試期間問題報告的結果，將令軟體工程師進行修改，然後準備將軟體產品對整個顧客市場發行。 13.6 系統測試 軟體只是一個很大的、以電腦為基礎系統中的一個元素。 軟體與其他的系統元素(例如，硬體、人、資訊)一起併入，且導入一系列的系統整合與確認測試。 這些測試落在軟體流程的範圍外，且不是由軟體工程師獨自所主導。 在軟體設計與測試期間所採取的步驟，可以大幅地改進在大系統中軟體成功整合的機率。 「如同死亡與稅金一樣，測試既是不愉快的，也是不可避免的。」 Ed Yourdon 潛在的介接問題 一個傳統系統的測試問題是「千夫所指(finger-pointing)」。 這發生在當某個錯誤被揭發時，每位系統元素的開發者都為此問題而責備其他的人。 軟體工程師應該預先考慮潛在的介接問題，和： 設計錯誤處理路徑以測試來自系統其他元素的資訊。 導入一系列的測試，模擬錯誤資料或在軟體介面的其他潛在的錯誤。 記錄測試的結果，如果千夫所指的情況確實發生時，可以使用做為「證據」。 參與系統測試的計畫與設計，以確保軟體充分地測試。 系統測試 系統測試(system testing)實際上是一系列不同的測試，其主要的目的是完整地操練這個以電腦為基礎的系統。 雖然每項測試都有一個不同的目的，所有的工作都是要驗證系統元素已經適當地整合，並實行所配置的功能。 13.6.1 恢復測試(Recovery Testing) 許多以電腦為基礎的系統必須要在預先指定的時間內從錯誤中恢復並重新處理。 某些案例中，系統必須是可容錯的(fault tolerant) 。 處理錯誤必須不能導致整體系統的功能終止。 在其他的案例中，系統的錯誤必須要在一段指定的時間之內改正，否則會發生嚴重的經濟損失。 恢復測試 恢復測試(recovery testing)是一種系統測試，它以各種方式迫使軟體失去作用，並驗證恢復能被適當地實施。 如果恢復是自動的(由系統本身實行)，重新初始化、檢查點機制(checkpoint mechanisms)、資料恢復和重新啟動等會被評估其正確性。 如果恢復需要人為的干預，則平均修復時間(mean-time-to-repair, MTTR)被用來評估，以決定它是否在可接受的限度中。 13.6.2 安全測試 任何管理敏感性的資訊或導致對個人不正當損害(或益處)動作的電腦系統都是非法侵入的目標。滲透跨越範圍廣大的活動：電腦駭客為了娛樂而