OO第四次博客作業
一． 單元測試與正確性論證
　　在最后一階段的作業中，我們使用Junit進行單元測試，并且通過劃分分支來論證自己程序的正確性，相較于以前盲目的黑箱測試，這兩種方式更加科學，覆蓋面也更加廣泛，能找到黑箱測試難以找到的問題。
　　兩種測試方法其實都是通過對每一個類的方法的每一個分支進行測試，通過程序執行情況和預期情況的比較來判斷方法的正誤，相對比而言，單元測試注重每一個分支的正確性，更加細節一點；而正確性論證則是應對不同的輸入，從大的方向上說明方法行為的正確性，更加具有全局性。
單元測試的細節性決定了進行單元測試是一個及其耗費精力的工作，要做到分支的100%覆蓋，我們需要對代碼的每一個分支有詳盡的了解，對于以前寫過的代碼，要反復閱讀理解全部含義，這樣才能做到不遺漏，每一組測試樣例的構造都要下一番辛苦來保證所有的節點都能通過。除此以外，測試時有時還會遇到某一個分支永遠無法覆蓋的“有趣”現象，而這個分支的情況自己也很難判斷是否存在。。。。。。我們在寫代碼時遇到某一個分支難以判斷是否會發生的時候，往往會做一個比較保險的決定——假設它會發生然后處理掉，于是測試的時候你就不得不絞盡腦汁把這個奇葩的情況想出來。同時，單元測試的細節性往往會讓人忘記一些情形，比如電梯指令我們直接輸入一個RUN，首先它是合法指令，所以合法判斷是通過的；但是在后邊相應的處理函數中，我們默認輸入的都是合法指令，而第一條指令規定必須是(FR,1,UP,0)，往往容易忘記直接輸入RUN的情況，出現錯誤可能就直接crash了。這也是細節測試帶來的弊端——忘記程序的整體性。
　　正確性論證相較來說更加有全局性，對于方法的行為能有一個很好的預料，因此在整個論證過程中，方法與方法之間的配合也能很周全的考慮到，這樣的情況下我們就能一定程度保證全局的正確性，而且相較于細節性的單元測試來說，正確性論證能省下一些構造樣例的麻煩，但也同時可能會忽略一些細節性的錯誤。
二． OCL與JSF
　　OCL（Object Constraint Language），對象約束語言，是一種指示用戶建模系統中的限制方式，可以更好地定義對象的行為，并為任何類元指定約束。
　　OCL與JSF一樣都是形式化語言，具有無二義性的特點，但是它的語言介于自然語言與邏輯語言，所以更加容易理解。OCL還提供了很多的關鍵字、基本數據類型和容器。
三． UML
（1） 類圖

（2） 時序圖

（3） 狀態圖

四． 學期總結
（1） 個人總結
　　這十五次作業恰好以四次博客作業為劃分，大致可以分為《Java從入門到懵逼》、《多線程從懵逼到折磨》、《規格化設計從折磨到放棄》、《單元測試正確性論證從放棄到解脫》（小皮一下）。。。。。。四階段可以說很貼切的讓我們體會到作為程序員要和語言斗智斗勇，要和算法斗智斗勇，要和需求斗智斗勇還要和測試斗智斗勇。不過也正是在這個斗智斗勇的過程中，我逐漸掌握了java這門語言的基本知識，多線程的運行規則以及算法，還有作為工程化開發時需要的規格和測試。。。。。。種種技能匯聚一起其實可以總結為一個程序員的應該具備的基本素養。
（2） 工程化開發
　　工程化開發給我的第一個印象就是——規范。因為當需要合作的時候，規范能保證彼此之間能聽懂彼此的話，能在同一套規范中了解同伴的意思，這是開發高效性的一個保證，只有在這樣的保證下，才能讓大家七手八腳“拼湊”出來的程序正常的跑起來；工程化開發給我的第二個印象是——詳細，它與一般的編程作業或者競賽時寫的代碼有很大差別，因為你不知道你面對什么樣的用戶，所以他會用盡各種奇怪的輸入來測試你的程序，要保證程序的魯棒性，就要保證每一個方法，在每一種輸入或者每一種情況下都有可以預見性的行為，因此就需要專門為一些非法的輸入考慮相應的處理方式，對每一個方法的規格就要詳盡到每一個分支。
（3） 一點點建議
　　OO已接近結束，就把我們做作業過程中遇到的問題反映一下吧。
　　首先是指導書的問題，我對比上屆感覺指導書本身沒有特別大的變化，也就是說作業基本沒有太大變化，所以是否可以推導出大家問的問題也大致相同呢。所以我希望在給下一屆的指導書中，參考我們這屆issue的一些問題，把相應的不甚明了的話語盡可能描述明白。
　　然后。。。。。。沒了，大苦大難我也結束了，那就讓學弟們好好享受OO的美好吧（壞笑）。

　　最后還是要感謝各位老師和助教，若干次測試，我問了不知多少蠢問題。。。。。。這百多天，也曾欣喜也曾生氣，但最終還是會成為在沙河一段美好的回憶吧。

轉載于:https://www.cnblogs.com/wishes/p/9218715.html

總結

以上是生活随笔為你收集整理的OO第四次博客作业的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。