xiaocb204

測試代碼（測試是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求）

在具體測試中，發現了兩個bug，一個是在判斷不及格時沒有要求大于等于零，另一個是沒有考慮100的情況。因此要添加grade<0的報錯以及修改grade<100為grade<=100。因此一般情況下測試代碼要比產品代碼要長一些。

(2)TDD(Test Driven Devlopment,測試驅動開發)

  測試驅動開發(TDD):先寫測試代碼，再寫產品代碼，從而寫出來的代碼就是正確的

步驟如下:

   明確當前要完成的功能,記錄成一個測試列表

   快速完成編寫針對此功能的測試用例

   測試代碼編譯不通過(無產品代碼?)

   編寫產品代碼

   對代碼進行重構,并保證測試通過(重構下次實驗練習)

   循環完成所有功能的開發

Eclipse->File->New->Java Project新建一個TDDDemo的Java項目

TDDDemo->右鍵->New->Source Folder新建一個測試目錄test

Test->右鍵->New->JUnit Test Case新建一個測試用例類MyUtilTest并輸入代碼（由于沒有建立MyUtil類以及percentage2fivegrade方法，所以有紅字出現）：

在TDDDemo的src目錄中新建MyUtil的類，并實現percentage2fivegrade方法：

我們把鼠標放到MyUtilTest.java上，單擊右鍵，選擇Run as->JUnit Test。測試結果出現了一個紅條（red bar）,說明測試沒通過：

問題出現在第十行55期望結果是不及格，但是沒有具體的代碼，所以只能報出錯誤，因此要修改一下MyUtil.java，再次進行測試時，得到了綠條，說明測試已通過：

在這個基礎上我們對測試進行拓展優化，增加異常情況用例和邊界用例，出現錯誤后有增加了一條語句出現綠條：

TDD的編碼節奏是：

　　·增加測試代碼，JUnit出現紅條

　　·修改產品代碼

　　·JUnit出現綠條，任務完成

(二)面向對象三要素

(1)抽象

抽象是指人在認識思維活動中對事物表象因素的舍棄和對本質因素的抽取。包括兩個方面，一是過程抽象，二是數據抽象。過程抽象的結果是函數，數據抽象的結果是抽象數據類型（Abstract Data Type，ADT）

(2) 封裝，繼承與多態

面向對象三要素：封裝、繼承、多態。面向對象的思想涉及到軟件開發的各個方面，如面向對象分析（OOA）、面向對象設計（OOD）、面向對象編程實現(OOP)。OOA根據抽象關鍵的問題域來分解系統，關注是什么（what）。OOD是一種提供符號設計系統的面向對象的實現過程，用非常接近問題域術語的方法把系統構造成“現實世界”的對象，關注怎么做（how）,通過模型來實現功能規范。OOP則在設計的基礎上用編程語言（如Java）編碼。貫穿OOA、OOD和OOP的主線正是抽象。

封裝實際上使用方法(method)將類的數據隱藏起來，控制用戶對類的修改和訪問數據的程度,從而帶來模塊化(Modularity)和信息隱藏(Information hiding)的好處；接口（interface）是封裝的準確描述手段。

首先嘗試一下封裝：

我們可以用UML中的類圖來描述類Dog,首先我們在實驗樓的環境中打開shell，在命令行中輸入umbrello，打開UML建模軟件umbrello.

UML建模之后的模型如下：

對應測試代碼和運行結果如下：

實踐發現Dog.java和Cat.java中有很多冗余的地方，所以重新定義了一下uml中繼承表示：

(三)設計模式初步

(1)S.O.L.I.D

面向對象三要素是“封裝、繼承、多態”，任何面向對象編程語言都會在語法上支持這三要素。如何借助抽象思維用好三要素特別是多態還是非常困難的，S.O.L.I.D類設計原則是一個很好的指導

基于OCP，利用面向對象中的多態性（Polymorphic），更靈活地處理變更擁抱變化，OCP可以用以下手段實現：（1）抽象和繼承，（2）面向接口編程

LSP的核心思想是父類型對象可以被子類型對象所取代

(2)模式與設計模式

模式是某外在環境下﹐對特定問題的慣用解決之道，其中最重要的是設計模式

(3)設計模式實示例

設計模式提供一個用于細化軟件系統的子系統或組件，或它們之間的關系圖，它描述通信組件的公共再現結構，通信組件可以解決特定語境中的一個設計問題

(四)練習

使用TDD方式設計并實現復數類Complex

偽代碼：

　　設計一個復數類，將復數的實部和虛部分別用變量表示。

　　通過實部和虛部分別相加減實現復數的相加減。

　　按照復數的格式將復數打印出來。

產品代碼：

步驟	耗時	百分比
需求分析	0.5h	10%
設計	1h	20%
代碼實現	1.5h	30%
測試	1h	20%
分析總結	1h	20%

單元測試的好處：

　　經過單元測試的代碼，質量能夠得到保證。

　　單元測試發現的問題很容易定位。

　　修改代碼犯的錯，經過單元測試易發現。

(五)總結

實驗收獲：

　這次實驗盡管花了很多時間，但是我也收獲了很多。首先，通過這次實驗，我對虛擬機的使用更加熟悉，也更加適應這種實驗模式，對于虛擬機內代碼編碼更加熟悉迅速。學習到單元測試這個方便快捷并且高質量的測試方式，同時實驗中一步一步地引導我學會處理可能出現的種種問題，同時也教會我以后在編寫程序的時候要考慮到各種可能性，以提高代碼的安全性。

出現的問題和解決方案：

　　　首先由于內網原因，實驗樓的UML沒有安裝上，通過詢問老師并自己實踐，用update語句和--fix-missing語句成功安裝上。

　　　其次由于網絡很慢，實驗樓內總是卡，所以浪費了很長的時間，解決方案是我在Windows下下了一個eclipse，然后用自己的eclipse進行編碼，節省了不必要的時間浪費，大大加快了速度。