軟工實踐——第三次做業數獨測試總結

軟工實踐——第三次做業數獨測試總結

一、測試流程圖

二、測試狀態分析

程序的狀態枚舉https://github.com/numb-men/software_test/blob/master/src/main/java/cn/hengyumo/SoftwareTestStatus.java

程序的日誌https://github.com/numb-men/software_test/blob/master/log.json

一、預備動做可能出現的狀態日誌

// 沒在共享文檔填寫倉庫地址，按照老師預先聲明的軟工實踐記分規則視爲做業沒交/-18.0
    EMPTY_GITHUB_REPO("空，未填github倉庫地址"),

    // 倉庫地址不符合規範 http://github.com/xxxx/xxxx
    // （這一錯誤我能改的都幫着改了）
    BAD_GITHUB_REPO_URL("不合法的github倉庫形式"),

    // 進行下載
    WAIT_TO_DOWNLOAD("連接無誤，等待下載"),

二、下載解壓動做可能會出現的狀態日誌

// 下載成功，部分同窗沒有按照做業要求忽略倉庫的無用文件，
    // 致使倉庫好幾十MB，有兩位同窗一個四十幾MB，一個六十幾MB...
    // 實際上只上傳源代碼，應該就只有幾KB。
    // 進入解壓
    DOWNLOAD_SUCCEED("下載成功"),

    // 下載失敗，這一錯誤表明着，你在共享文檔填的倉庫地址不存在
    // 或者有的同窗建了github帳號，卻沒有上傳倉庫，而填倉庫，那訪問確定404了
    // 或者有的同窗填了倉庫地址，但實際上"http://github.com/後面那個用戶名"都沒法訪問
    // 這種狀況表明着該同窗未創建帳號
    DOWNLOAD_FAIL("下載失敗"),

    // 保存的時候失敗，未出現
    SAVE_FAIL("保存失敗"),
    
    // 解壓的時候失敗，未出現
    UNZIP_FAIL("解壓失敗"),

    // 解壓成功，進入編譯
    UNZIP_SUCCEED("解壓成功"),

    // 未知錯誤，未出現
    UNKNOWN_ERROR("未知錯誤"),
    
    // 鏈接超時，未出現
    TIMEOUT_FOR_CONNECT("鏈接超時"),

三、編譯動做可能會出現的狀態日誌（狀態不表明執行前後）

// 這一錯誤是未找到主程序 Sudoku/Suduku/sudoku/suduku (後綴是.c或者.cpp或者.java)
    // 這些是測試程序會嘗試查找的主程序文件名，做業要求中已經明確規定了項目結構。
    // 這一階段失敗，編譯停止
    MAIN_PROGRAM_FILE_NOT_FOUND("主程序未找到"),

    // 查找到主程序，等待編譯
    WAIT_TO_COMPILE("等待編譯"),
    
    // 編譯查找文件出現IOException，未發生
    COMPILE_DIR_OR_FILE_NOT_FOUND("待編譯文件夾或文件未找到"),

    // 編譯C/C++失敗，詳情能夠查看編譯日誌
    // 失敗的緣由，大體有這些：
    // 一、頭文件引入失敗：程序所需的.h/.cpp文件未包含在主程序所在文件夾
    // 二、使用了不安全的函數，如fscanf_s等致使編譯失敗
    // 三、程序自己語法錯誤，致使編譯失敗
    COMPILE_CCPP_FAIL("編譯C/C++失敗"),

    // 轉入測試
    COMPILE_CCPP_SUCCEED("編譯C/C++成功"),

    // java都編譯過了（跨平臺語言就是niu）
    COMPILE_JAVA_FAIL("編譯Java失敗"),

    // 轉入測試
    COMPILE_JAVA_SUCCEED("編譯Java成功"),

    // 該狀態未使用
    PACK_JAR_FAIL("打包jar失敗"),

    // 該狀態未使用
    PACK_JAR_SUCCEED("打包jar成功"),

    // 使用了除c/c++/java以外的編程語言寫了代碼，未出現
    UN_SUPPORT_COMPILE_TYPE("不支持編譯類型"),

四、測試動做可能會出現的狀態

// 測試全部用例的總時間 > 5分鐘，視爲超時
    // 有查看部分超時同窗的代碼，是由於用了cin或者system paues致使的緩衝區阻塞
    // 還有部分多是出現了死循環
    TEST_TIMEOUT("測試超時"),

    // 編譯成功的項目，進入準備測試
    WAIT_TO_TEST("準備測試"),

    // 測試失敗（全部測試用例所有失敗）
    // 緣由可能有：
    // 一、代碼自己出錯，沒有處理好輸入，或者其餘緣由，編譯的exe或class運行失敗
    // 二、使用太高的vs版本，或者太低的vs版本，致使的不兼容
    // 三、沒有按照要求根據-i、-o讀取輸入輸出路徑，致使程序沒有正確的輸出結果
    TEST_FAIL("測試失敗"),

    // 恭喜，測試成功
    TEST_SUCCEED("測試成功");

五、附測試 手動階段

這一階段主要目的是：

1. 對測試階段超時的程序進行記分

2. 對於出現版本不兼容的程序嘗試用vs 2017手動編譯，進行從新測試。

   我和一位編譯失敗的同窗聊天以後，發現個人vs的windows sdk版本和他的不同，這是由於最近一段時間vs更新了，他們有的遇到這個問題的都是剛下的vs或者近期更新過。這算是一個預期以外的錯誤。我只好更新vs並從新編譯和測試一遍。這裏感謝陶同窗協助我找到緣由。重測的依據是運行出現:
   

然而致使出現圖片所示錯誤的緣由並不僅是vs的windows sdk版本。更多的是vs版本不是2017
（使用2017 這是做業強調的，不可能爲了誰特意再下一個201九、201三、2015）

這一階段的狀態和編譯、測試階段一致，故省略。

六、總結階段

根據測試輸出的表格，結合附測試階段的結果，生成最終結果。

如何查看本身程序的錯誤

程序編譯/測試輸出日誌：https://github.com/numb-men/software_test/tree/master/log
其中
compile.log.main.txt —— 編譯日誌，能夠根據你的學號搜索查看你的程序的編譯命令行輸出
test.log.main.txt —— 測試日誌，能夠根據你的學號搜索查看你的程序的測試命令行輸出

測試用例

https://github.com/numb-men/software_test/tree/master/test_case
https://github.com/numb-men/software_test/tree/master/test_case2

test_case
        ├─3
        │      input1.txt
        │      input2.txt
        │      input3.txt
        │      input4.txt
        │      input5.txt
        │      output1.txt
        │      output2.txt
        │      output3.txt
        │      output4.txt
        │      output5.txt
        │
        ├─4
        ...
// tase_case 中包含7個文件夾，分別存放3-9宮格的輸入和答案
// 每一個子文件夾，存放五個輸入和五個對應的答案
// 其中input1 input2 input3都是單個錶盤，input4 5個錶盤，input5 10個錶盤

測試用例一共有5 * 7 = 35個，因爲以前助教在發佈做業時描述的數獨分隔符是一個空格，
可是提供給你們測試的測試用例是2個空格，爲了防止助教工做失誤致使的程序錯誤，
因此每個程序會用1個空格的測一遍，兩個空格的測一遍，結果取正確的那個。

記分標準

3宮格，每一個測試用例5分，總分5 * 5 = 25
4-9宮格，每一個測試用例0.6分，總分0.6 * 5 * 6 = 18分
3-9宮格所有正確加分：2分

第三次做業：做業記分 55（博客） + 45（程序） = 100，折算成千帆競發圖得分40分；
故而此次程序做業的測試滿分得分爲 45 * 0.4 = 18分

不少同窗都是很小的錯誤（不符合目錄結構/使用了system pause、cin等致使阻塞），得了0分好惋惜，爲何不重測一遍，再給一次機會？

助教的內心話：

個人建議仍是如今的評分結果保持不變。對成績有疑問的的同窗，能夠在規定的時間（好比成績發佈24h）內發起申述，羣裏艾特請求助教從新自動化測試程序。不按照要求提交做業，就按照要求不給分。我我的做爲學生和做爲助教的旁觀經歷是隻有教訓足夠痛，才能讓同窗們真正記住此次教訓和有所提升。換個角度考慮，讓同窗們從新提交做業，從新按照此次做業的規則來完成做業，做業成績能也許有所提升，但同窗們下次做業、下下次做業呢？會嚴格按照做業的要求來完成嗎？給從新提交做業的機會，我想對於學生而言有害無益，既然我不按照要求來，反正不少同窗都會這樣，那老師又會給從新提交做業的機會。如此反覆，惡性循環。零分不算是差，還有負分。第一次這麼給成績，估計會有同窗「反抗」，但對於以後的做業而言，我想會是好的。而對於有意見的同窗，能夠按照他們的要求從新自動化測試做業，看看是否與當前的結果有差別或者給出爲何扣分。反覆給機會，不利於以後的做業要求，對學生而言也沒好處，或許分數有提升，或者助教是好人，但這沒啥意義。

最後

此次做業的結果可能不是不少人滿意。可是但願你們明白：分數只是手段，教學纔是目的。但願你們在此次做業中有所收穫。（若是能回過頭再去完善一次本身的做業，想必你會收穫更多）

此次自動測試的代碼使用java編寫，累計代碼2000行左右，由於時間有限，還存在着不足。若是有同窗對自動測試感興趣的話，歡迎加入我，一塊兒維護這份代碼：https://github.com/numb-men/software_test

最後的最後

個人分數爲負是否是必定會掛科了，我好絕望，我以後做業都不想寫了：

助教：莫慌，最後總分映射到同一個大的區間話，差距不會很大，除非極其優秀。單個點對全局影響不大。

（ps：對分數存在異議，請於2019-10-9 中午 12:00 前在羣內@助教）