軟件工程第五次做業

 

         嘀嘀嘀——                              倒車！請注意！倒車！請注意！        

         Bilibili：非職業天使   戰網國服：圖南#51221   Steam：屍體A         

         前排廣告君表示要辭職了!!!   這個up根本不更新還處處發廣告！        

 

1、簡述

• 題目要求

  • 可以自動生成四則運算練習題
  • 能夠定製題目數量
  • 用戶能夠選擇運算符
  • 用戶設置最大數（如十之內、百之內等）
  • 用戶選擇是否有括號、是否有小數
  • 用戶選擇輸出方式（如輸出到文件、打印機等）
  • 最好能提供圖形用戶界面（根據本身能力選作，以完成上述功能爲

• 任務分配

  • 駕駛員：<X司機>   代碼地址：<Pair_Programming>     
  • 領航員：<J指揮>   代碼地址：<Pair_Programming_Test>

（點♂擊♂名♂字♂打♂開♂鏈♂接）

2、代碼測試

一、測試用例

• 測試對象：getOperatorArray()，buildItems()，dealError()

• 覆蓋標準：針對方法的每個傳出結果進行條件組合覆蓋
• 用例設計：
  • getOperatorArray()有四個傳入參數，一個傳出參數，全是布爾變量。因此結果只有兩種，true和false。當全部傳入爲false時，結果爲false。所以共16種用例。
  • buildItems()有一個傳入參數，一個傳出參數。當傳入爲正數，傳出1；其餘傳入時傳出皆爲0。所以只有兩種用例。
  • dealError()裏面每一個if下都是直接返回，而且不一樣的if之間斷定條件有交叉，不能單純的畫出流程圖判斷都覆蓋了哪些條件。所以針對每一種結果進行條件組合覆蓋。
    • 當結果爲0時，全部輸入合法，一組用例便可；
    • 當結果爲1時，max、sum輸入不合法。各自不合法+同時不合法共三種，還有最後一個布爾斷定，因此有六種用例。
    • 當結果爲2時，max、sum值能經過程序（即字符串轉換成 int 和 float），可是sum值太大。此時斷定條件與以前有交叉，理論上也屬於「不合法」。max值固定合法，sam爲大數，後面布爾有兩種狀況。所以共兩種用例。
    • 當結果爲3時，sum、max必須合法，最後條件必爲false，只有一種用例。

修改建議：

        若是想細分「不合法」的條件就應該sum爲一類，max爲一類。sum裏包括輸入不爲正和輸入太大；max包括輸入不爲正。否則合併在一塊兒你們都是不合法，寫成交叉數學邏輯上沒錯，可是不符合邏輯習慣。

        順便max也可加入「不能過大」的條件。小學數學不須要太多大數，萬之內就足夠了。

二、自動測試

• 測試技術：採用Junit進行自動測試。
• 代碼：<Coding>

 1 public class MainActivityTest {  2 
 3     @Test//動態處理運算符數組並返回checked值
 4     public void getOperatorArray() {  5         assertEquals(true,new MainActivity().getOperatorArray(true,true,true,true));  6 
 7         assertEquals(true,new MainActivity().getOperatorArray(true,true,true,false));  8         assertEquals(true,new MainActivity().getOperatorArray(true,true,false,true));  9         assertEquals(true,new MainActivity().getOperatorArray(true,false,true,true)); 10         assertEquals(true,new MainActivity().getOperatorArray(false,true,true,true)); 11 
12         assertEquals(true,new MainActivity().getOperatorArray(true,true,false,false)); 13         assertEquals(true,new MainActivity().getOperatorArray(true,false,true,false)); 14         assertEquals(true,new MainActivity().getOperatorArray(false,true,true,false)); 15         assertEquals(true,new MainActivity().getOperatorArray(true,false,false,true)); 16         assertEquals(true,new MainActivity().getOperatorArray(false,true,false,true)); 17         assertEquals(true,new MainActivity().getOperatorArray(false,false,true,true)); 18 
19         assertEquals(true,new MainActivity().getOperatorArray(true,false,false,false)); 20         assertEquals(true,new MainActivity().getOperatorArray(false,true,false,false)); 21         assertEquals(true,new MainActivity().getOperatorArray(false,false,true,false)); 22         assertEquals(true,new MainActivity().getOperatorArray(false,false,false,true)); 23 
24         assertEquals(false,new MainActivity().getOperatorArray(false,false,false,false)); 25  } 26 
27     @Test//構建隨機式，成功則返回1,失敗則返回0
28     public void buildItems() { 29         assertEquals(1,new MainActivity().buildItems(10)); 30         assertEquals(0,new MainActivity().buildItems(-10)); 31  } 32     @Test//出錯邏輯處理,返回出錯類型並返回出錯類型,返回0則無錯,1爲max、sum輸入不合法，2爲sum太大，3爲沒選操做符
33     public void dealError() { 34         assertEquals(0,new MainActivity().dealError("10","10",true)); 35 
36         assertEquals(1,new MainActivity().dealError("10","-10",true)); 37         assertEquals(1,new MainActivity().dealError("10","-10",false)); 38         assertEquals(1,new MainActivity().dealError("-10","10",true)); 39         assertEquals(1,new MainActivity().dealError("-10","10",false)); 40         assertEquals(1,new MainActivity().dealError("-10","-10",true)); 41         assertEquals(1,new MainActivity().dealError("-10","-10",false)); 42 
43         assertEquals(2,new MainActivity().dealError("999999999","10",true)); 44         assertEquals(2,new MainActivity().dealError("999999999","10",false)); 45 
46         assertEquals(3,new MainActivity().dealError("10","10",false)); 47  } 48 }

public class MainActivityTest

• 測試結果：全部測試用例都經過測試。截圖以下。

三、代碼審查表

 

重要性	激活	級別	檢查項
總計
命名
重要	Y	20	命名規則是否與所採用的規範保持一致？
	Y	20	是否遵循了最小長度最多信息原則？
重要	Y	50	has/can/is前綴的函數是否返回布爾型？
註釋
重要	Y	10	註釋是否較清晰且必要？
重要	Y	10	複雜的分支流程是否已經被註釋？
	N	10	距離較遠的}是否已經被註釋？
	N	10	非通用變量是否所有被註釋？
重要	Y	50	函數是否已經有文檔註釋？（功能、輸入、返回及其餘可選）
	Y	10	特殊用法是否被註釋？
聲明、空白、縮進
	N	20	每行是否只聲明瞭一個變量？（特別是那些可能出錯的類型）
重要	Y	40	變量是否已經在定義的同時初始化？
重要	Y	40	類屬性是否都執行了初始化？
	Y	20	代碼段落是否被合適地以空行分隔？
	Y	20	是否合理地使用了空格使程序更清晰？
	Y	20	代碼行長度是否在要求以內？
	N	20	折行是否恰當？
語句/功能分佈/規模
	Y	20	包含複合語句的{}是否成對出現並符合規範？
	N	20	是否給單個的循環、條件語句也加了{}？
	Y	20	if/if-else/if-else if-else/do-while/switch-case語句的格式是否符合規範？
	Y	40	單個變量是否只作單個用途？
重要	Y	20	單行是否只有單個功能？（不要使用；進行多行合併）
重要	Y	40	單個函數是否執行了單個功能並與其命名相符？
	Y	20	操做符＋＋和— —操做符的應用是否複合規範？
規模
重要	Y	20	單個函數不超過規定行數？
重要	Y	100	縮進層數是否不超過規定？
重要	Y	100	是否已經消除了全部警告？
重要	Y	40	常數變量是否聲明爲final？
重要	Y	80	對象使用前是否進行了檢查？
重要	N	80	局部對象變量使用後是否被複位爲NULL？
重要	Y	70	對數組的訪問是不是安全的？（合法的index取值爲[0, MAX_SIZE-1]）。
重要	Y	20	是否確認沒有同名變量局部重複定義問題?
	Y	20	程序中是否只使用了簡單的表達式？
重要	Y	20	是否已經用（）使操做符優先級明確化？
重要	Y	20	全部判斷是否都使用了（常量==變量）的形式？
	Y	80	是否消除了流程懸掛？
重要	N	80	是否每一個if-else if-else語句都有最後一個else以確保處理了全集？
重要	Y	80	是否每一個switch-case語句都有最後一個default以確保處理了全集？
	Y	80	for循環是否都使用了包含下限不包含上限的形式？（k=0; k<MAX）
重要	Y	40	XML標記書寫是否完整，字符串的拼寫是否正確?
	Y	40	對於流操做代碼的異常捕獲是否有finally操做以關閉流對象?
	Y	20	退出代碼段時是否對臨時對象作了釋放處理?
重要	Y	40	對浮點數值的相等判斷是不是恰當的？（嚴禁使用==直接判斷）
可靠性（函數）
重要	Y	60	入口對象是否都被進行了判斷不爲空？
重要	Y	60	入口數據的合法範圍是否都被進行了判斷？(尤爲是數組)
重要	Y	20	是否對有異常拋出的方法都執行了try...catch保護？
重要	Y	80	是否函數的全部分支都有返回值？
重要	Y	50	int的返回值是否合理？（負值爲失敗，非負值成功）
	Y	20	對於反覆進行了int返回值判斷是否認義了函數來處理？
	Y	60	關鍵代碼是否作了捕獲異常處理?
重要	N	60	是否確保函數返回CORBA對象的任何一個屬性都不能爲null?
重要	N	60	是否對方法返回值對象作了null檢查，該返回值定義時是否被初始化?
重要	N	60	是否對同步對象的遍歷訪問作了代碼同步?
重要	N	80	是否確認在對Map對象使用迭代遍歷過程當中沒有作增減元素操做？
重要	N	60	線程處理函數循環內部是否有異常捕獲處理，防止線程拋出異常而退出?
	N	20	原子操做代碼異常中斷，使用的相關外部變量是否恢復先前狀態?
重要	Y	100	函數對錯誤的處理是恰當的？
可維護性
重要	Y	100	實現代碼中是否消除了直接常量？（用於計數起點的簡單常數例外）
	Y	20	是否消除了致使結構模糊的連續賦值？（如a= (b=d+c )）
	Y	20	是否每一個return前都要有日誌記錄?
	Y	20	是否有冗餘判斷語句？（如：if (b) return true; else return false;）
	N	20	是否把方法中的重複代碼抽象成私有函數?

 

3、UI測試                                        ——參考自<APP的UI測試>

• 歡迎界面美觀。

• 標題欄文字描述正確，背景顏色合理。

• 背景顏色與字體顏色和背景色相搭配.

• 佈局合理。控件，文字，線條位置，數量，顏色合理，跟總體風格搭配。

• 界面文字無錯別字。文字大小，顏色，位置一致。

• 控件大部分使用正常。

• 提示框設計合理，提示語友好，簡明。

• 列表型界面有上下滑動效果。

• 窗口適應差，不能橫向。

• 功能入口不明顯。

修改建議：

        一、右上角菜單爲無效菜單，需刪除。

        二、右下角生成按鈕圖標不明確，更像是「刷新」。建議按鈕上標註文字「生成題庫」。

        三、界面窗口不能自動適應各類類型的屏幕。

        四、應提示用戶點擊算式查看答案。

4、功能測試

APP本體：點擊下載APP

測試環境：榮耀暢玩6X Android7.0

測試流程：安裝->運行->基本功能測試->異常處理測試

測試截圖：

 

進入APP：歡迎界面美觀，停留時間合理。

輸入非法字段，彈出提示。

題數過多，彈出提示。

 

生成題目

 

測試結果：

• 可以自動生成四則運算練習題 √
• 能夠定製題目數量 √
• 用戶能夠選擇運算符 √
• 用戶設置最大數（如十之內、百之內等）√
• 用戶選擇是否有括號、是否有小數 √
• 用戶選擇輸出方式（如輸出到文件、打印機等）×
• 最好能提供圖形用戶界面  √

5、評價

        個人小夥伴果真超級厲害，很快就寫完了程序，並且還作出了界面，已經能夠發佈了~ 可是有一些細節須要處理。好比對「不合法」條件的理解，斷定條件之間有交叉；還有界面右上角無效菜單，右下角生成按鈕圖標不明確，界面窗口不能自動適應各類類型的屏幕，也沒提示用戶查看答案的方法。

        還有最重要的是不能導出生成的題目。這應該在開發的最一開始就決定的。咱們的題意實際上是想給老師作一個程序，讓他們出題方便。可是個人小夥伴沒有考慮這一點，只完成了基本的功能，這樣只能讓學生本身下載app而後使用了。可是小學生怎麼可讓他們隨便玩手機呢！理想的狀況應該是導出一個.txt或者.doc，老師能夠再進行編輯，而後打印出來當卷子給學生使用。並且能夠把正確答案再單獨導出一份，方便老師批改卷子。

        若是隻是這樣的app給學生使用的話，其實還能夠作成自測小程序，讓學生本身輸入算的答案，最後點擊提交，程序能夠對比答案，直接給出分數。

6、總結

        過此次做業，我對敏捷編程有了初步的認識和體驗。兩我的一塊兒可以互相監督，互相幫助。說來慚愧，代碼都是個人小夥伴獨立完成的，我只能看看，再研究研究是怎麼寫的。畢竟當初選修的Android課是全英文授課，沒聽懂就算了，本身也沒課後研究，如今有點想吃後悔藥了orz

        原本做業中測試的本意是想鍛鍊咱們熟練掌握覆蓋標準和自動測試，可是最初咱們的程序沒有能測試的地方。整個功能的實現都在一個大類裏，並且咱們生成的隨機算式是沒辦法進行測試的。輸出是一個隨機的數，咱們怎麼可能肯定咱們的指望值呢。爲了可以測試，個人小夥伴又特地把程序大改了一遍，所有劃分紅小方法，設好了傳入參數和傳出參數，好讓我可以有測試的東西。

        咱們一塊兒預定了研修室，改了一下午程序，後來又預定了一小時，最後總算是有點成果了。想一想其實若是準備工做充足，把程序的結構和功能提早設計明白，就沒這麼多麻煩事了。果真開發初期的工做真的很重要啊，大的方向把握好了才能走向成功的道路。我做爲領航員卻沒有準備好初期工做，是個人失誤。現在有了經驗教訓，之後必定不再犯這個錯誤了。

        時間緊迫，做爲做業，咱們只能這樣把它提交了。可是做爲一個成品，它還須要更多的修改和完善。若是有機會，咱們能夠把它好好作完，並投入使用。