软工实践——第三次作业数独测试总结
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、附测试 手动阶段
这一阶段主要目的是：
- 对测试阶段超时的程序进行记分
对于出现版本不兼容的程序尝试用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 —— 测试日志，可以根据你的学号搜索查看你的测试日志
测试用例
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内在博客底部评论回复）