• 软工实践——第三次作业数独测试总结


    软工实践——第三次作业数独测试总结

    1、测试流程图

    2、测试状态分析

    程序的状态枚举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

    1、预备动作可能出现的状态日志

    	// 没在共享文档填写仓库地址,按照老师预先声明的软工实践记分规则视为作业没交/-18.0
        EMPTY_GITHUB_REPO("空,未填github仓库地址"),
    
        // 仓库地址不符合规范 http://github.com/xxxx/xxxx
    	// (这一错误我能改的都帮着改了)
        BAD_GITHUB_REPO_URL("不合法的github仓库形式"),
    
        // 进行下载
        WAIT_TO_DOWNLOAD("链接无误,等待下载"),
    

    2、下载解压动作可能会出现的状态日志

    	// 下载成功,部分同学没有按照作业要求忽略仓库的无用文件,
    	// 导致仓库好几十MB,有两位同学一个四十几MB,一个六十几MB...
    	// 实际上只上传源代码,应该就只有几KB。
    	// 进入解压
    	DOWNLOAD_SUCCEED("下载成功"),
    
        // 下载失败,这一错误代表着,你在共享文档填的仓库地址不存在
    	// 或者有的同学建了github账号,却没有上传仓库,而填仓库,那访问肯定404了
    	// 或者有的同学填了仓库地址,但实际上"http://github.com/后面那个用户名"都无法访问
    	// 这种情况代表着该同学未建立账号
        DOWNLOAD_FAIL("下载失败"),
    
    	// 保存的时候失败,未出现
        SAVE_FAIL("保存失败"),
    	
    	// 解压的时候失败,未出现
    	UNZIP_FAIL("解压失败"),
    
        // 解压成功,进入编译
        UNZIP_SUCCEED("解压成功"),
    
        // 未知错误,未出现
        UNKNOWN_ERROR("未知错误"),
    	
    	// 连接超时,未出现
    	TIMEOUT_FOR_CONNECT("连接超时"),
    

    3、编译动作可能会出现的状态日志(状态不代表执行先后)

    	// 这一错误是未找到主程序 Sudoku/Suduku/sudoku/suduku (后缀是.c或者.cpp或者.java)
    	// 这些是测试程序会尝试查找的主程序文件名,作业要求中已经明确规定了项目结构。
    	// 这一阶段失败,编译中止
    	MAIN_PROGRAM_FILE_NOT_FOUND("主程序未找到"),
    
        // 查找到主程序,等待编译
        WAIT_TO_COMPILE("等待编译"),
        
        // 编译查找文件出现IOException,未发生
        COMPILE_DIR_OR_FILE_NOT_FOUND("待编译文件夹或文件未找到"),
    
        // 编译C/C++失败,详情可以查看编译日志
    	// 失败的原因,大致有这些:
    	// 1、头文件引入失败:程序所需的.h/.cpp文件未包含在主程序所在文件夹
    	// 2、使用了不安全的函数,如fscanf_s等导致编译失败
    	// 3、程序本身语法错误,导致编译失败
        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("不支持编译类型"),
    

    4、测试动作可能会出现的状态

    	// 测试所有用例的总时间 > 5分钟,视为超时
    	// 有查看部分超时同学的代码,是因为用了cin或者system paues导致的缓冲区阻塞
    	// 还有部分可能是出现了死循环
    	TEST_TIMEOUT("测试超时"),
    
    	// 编译成功的项目,进入准备测试
        WAIT_TO_TEST("准备测试"),
    
    	// 测试失败(所有测试用例全部失败)
    	// 原因可能有:
    	// 1、代码本身出错,没有处理好输入,或者其他原因,编译的exe或class运行失败
    	// 2、使用过高的vs版本,或者过低的vs版本,导致的不兼容
    	// 3、没有按照要求根据-i、-o读取输入输出路径,导致程序没有正确的输出结果
        TEST_FAIL("测试失败"),
    
    	// 恭喜,测试成功
        TEST_SUCCEED("测试成功");
    

    5、附测试 手动阶段

    这一阶段主要目的是:

    1. 对测试阶段超时的程序进行记分
    2. 对于出现版本不兼容的程序尝试用vs 2017手动编译,进行重新测试。

    我和一位编译失败的同学聊天之后,发现我的vs的windows sdk版本和他的不一样,这是因为最近一段时间vs更新了,他们有的遇到这个问题的都是刚下的vs或者近期更新过。这算是一个预期之外的错误。我只好更新vs并重新编译和测试一遍。这里感谢陶同学协助我找到原因。重测的依据是运行出现:

    然而导致出现图片所示错误的原因并不只是vs的windows sdk版本。更多的是vs版本不是2017
    (使用2017 这是作业强调的,不可能为了谁特地再下一个2019、2013、2015)

    这一阶段的状态和编译、测试阶段一致,故省略。

    6、总结阶段

    根据测试输出的表格,结合附测试阶段的结果,生成最终结果。

    如何查看自己程序的错误

    程序编译/测试输出日志: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 前在群内@助教)

  • 相关阅读:
    PAT Advanced 1067 Sort with Swap(0, i) (25分)
    PAT Advanced 1048 Find Coins (25分)
    PAT Advanced 1060 Are They Equal (25分)
    PAT Advanced 1088 Rational Arithmetic (20分)
    PAT Advanced 1032 Sharing (25分)
    Linux的at命令
    Sublime Text3使用指南
    IntelliJ IDEA创建第一个Groovy工程
    Sublime Text3 安装ftp插件
    Sublime Text3配置Groovy运行环境
  • 原文地址:https://www.cnblogs.com/hengyumo/p/11635229.html
Copyright © 2020-2023  润新知