|
2 | 2 |
|
3 | 3 | | 测试case | 测试名称 | 测试步骤 | 预期效果 | 测试结果 | 备注 | |
4 | 4 | | -------- | ------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | -------- | ---- | |
5 | | -| 1 | 首次评论区信息抽取 | 构造2个任务列表，每个任务列表包含5-10个任务构造至少2个github账号，按照规定格式报名若干任务，任务均已发布规定格式：【报名】: 2、3`【报名】: ` 后直接是报名的任务序号，多个任务之间需要用中文顿号、分隔，多个连续任务可以用横线表示`2-5`。首次运行脚本 | 报名信息正确更新到表单中 | | | |
6 | | -| 2 | 二次评论区信息抽取 | 基于case1，在评论区按照规定格式二次构造若干报名信息，任务均已发布在case1的基础上运行脚本 | 新增报名信息正确更新到表单中 | | | |
7 | | -| 3 | 新增/删除/修改任务列表信息 | 在任务列表中随机删除1个任务（md中划掉）在任务列表中随机增加1个任务（新增一行，任务编号不重复）在任务列表中随机修改1个任务的难度和issue描述文案在task_list中补充增加的任务编号任意github账号报名删除任务的编号任意github账号报名新增任务的编号在case2的基础上运行脚本 | 新增/删除/修改任务列表信息保留报名信息正确更新到表单中 | | | |
8 | | -| 4 | 评论区负样本信息抽取与报错提醒 | 构造规定格式以外的评论信息，包括：不按照规定格式的报名信息，如【取消报名】：2、3【链接】：1-5报名：https://github.com/Tomoko-hjf/paddleviz/issues/1报名：1111111非报名信息，如问答或闲聊信息在case3的基础上运行脚本 | 准确识别负样本信息，记录log@github id，提醒对方未成功报名 | | | |
9 | | -| 5 | PR状态抽取（含负样本） | 已报名的github账号在community下提交一个pr，pr标题按照规定格式规定格式：在`PR`的标题中以`【Hackathon No.xxx】`开头未报名的github账号在community下提交一个pr，pr标题按照规定格式已报名的github账号在任意监控范围内的repo下提交一个pr，pr标题按照规定格式，但编号不在task_list中未报名的github账号在任意监控范围内的repo下提交一个pr，pr标题按照规定格式在case4的基础上运行脚本 | 准确更新 1 2 4的PR信息3记录log，@github id，提醒对方编号有误 | | | |
10 | | -| 6 | 更改PR标题后的状态抽取 | 更改case5中不符合规范的PR标题，使其正确在case5的基础上运行脚本 | 修改后PR被正确更新到表单中 | | | |
11 | | -| 7 | PR状态变更后抽取 | community下合入一个pr监控范围内的repo合入一个pr在case6的基础上运行脚本 | rfc和pr状态被正确更新为完成设计文档和完成任务备注：rfc和pr合入由黑客松组委会管理，可以**人工避免**要求rfc的任务绕过rfc提交直接合入pr的情况，因此不测试这个case | | | |
12 | | -| 8 | 多个PR指向一个任务，且具有不同状态（open/close/merge） | 构造5个pr，标题中的任务序号指向同一个任务合入其中3个pr，其中2个pr由同一个github id提交关闭其中1个pr在case7的基础上运行脚本 | 5个pr的状态可以被准确更新到表单中备注：用于应对一个任务对应多个pr的情况 | | | |
| 5 | +| 1 | 首次评论区信息抽取 | 1. 构造2个任务列表，每个任务列表包含5-10个任务</br>2. 构造至少2个github账号，按照规定格式报名若干任务，任务均已发布</br>规定格式：【报名】: 2、3，`【报名】:` +任务序号，多个任务之间需要用中文顿号分隔，多个连续任务可以用横线连接`2-5`。</br>3. 首次运行脚本 | 报名信息正确更新到表单中 | | | |
| 6 | +| 2 | 二次评论区信息抽取 | 1. 基于case1，在评论区按照规定格式二次构造若干报名信息，任务均已发布</br>2. 在case1的基础上运行脚本 | 新增报名信息正确更新到表单中 | | | |
| 7 | +| 3 | 新增/删除/修改任务列表信息 | 1. 在任务列表中随机删除1个任务（md中划掉）</br>2. 在任务列表中随机增加1个任务（新增一行，任务编号不重复）</br>3. 在任务列表中随机修改1个任务的难度和issue描述文案</br>4. 在task_list中补充增加的任务编号</br>5. 任意github账号报名删除任务的编号</br>6. 任意github账号报名新增任务的编号</br>7. 在case2的基础上运行脚本 | 1. 新增/删除/修改任务列表信息保留</br>2. 报名信息正确更新到表单中 | | | |
| 8 | +| 4 | 评论区负样本信息抽取与报错提醒 | 1. 构造规定格式以外的评论信息，包括：</br> - 不按照规定格式的报名信息，如</br>①【取消报名】：2、3</br> ②【链接】：1-5</br> ③报名：https://github.com/Tomoko-hjf/paddleviz/issues/1 </br>④报名：1111111</br> -非报名信息，如问答或闲聊信息</br>2. 在case3的基础上运行脚本 | 1. 准确识别负样本信息，记录log</br>2. @github id，提醒对方未成功报名 | | | |
| 9 | +| 5 | PR状态抽取（含负样本） | 1. 已报名的github账号在community下提交一个pr，pr标题按照规定格式</br>规定格式：在`PR`的标题中以`【Hackathon No.xxx】`开头</br>2. 未报名的github账号在community下提交一个pr，pr标题按照规定格式</br>3. 已报名的github账号在任意监控范围内的repo下提交一个pr，pr标题按照规定格式，但编号不在task_list中</br>4. 未报名的github账号在任意监控范围内的repo下提交一个pr，pr标题按照规定格式</br>5. 在case4的基础上运行脚本 | 1. 准确更新 1 2 4的PR信息</br>2. 3记录log，@github id，提醒对方编号有误 | | | |
| 10 | +| 6 | 更改PR标题后的状态抽取 | 1. 更改case5中不符合规范的PR标题，使其正确</br>2. 在case5的基础上运行脚本 | 修改后PR被正确更新到表单中 | | | |
| 11 | +| 7 | PR状态变更后抽取 | 1. community下合入一个pr</br>2. 监控范围内的repo合入一个pr</br>3. 在case6的基础上运行脚本 | rfc和pr状态被正确更新为完成设计文档和完成任务</br>备注：rfc和pr合入由黑客松组委会管理，可以**人工避免**要求rfc的任务绕过rfc提交直接合入pr的情况，因此不测试这个case | | | |
| 12 | +| 8 | 多个PR指向一个任务，且具有不同状态（open/close/merge） | 1. 构造5个pr，标题中的任务序号指向同一个任务</br>2. 合入其中3个pr，其中2个pr由同一个github id提交</br>3. 关闭其中1个pr</br>4. 在case7的基础上运行脚本 | 5个pr的状态可以被准确更新到表单中</br>备注：用于应对一个任务对应多个pr的情况 | | | |
13 | 13 | | 9 | 看板功能 | | 验证上述测试样例中，看板统计是否正常 | | | |
14 | | -| 10 | | | | | | |
| 14 | +| 10 | | | | | | |
0 commit comments