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

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

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:对分数存在异议,请于24h内在博客底部评论回复)

猜你喜欢

转载自www.cnblogs.com/hengyumo/p/11635229.html
今日推荐