基于JUnit进行的项目测试
对不同功能点进行测试：
检测忘记密码功能、注册功能能否正常使用
脚本文件：registerTest.java
1.检测忘记密码功能。事先注册好一个账号用于测试
测试步骤：输入账号
输入电子邮箱
输入验证码
1）用例标题：验证码错误情况
测试数据：账号 2021127
电子邮箱 [email protected]
验证码 1234
预期结果：验证码错误
实际结果：Verify Code Wrong!
2）用例标题：验证码正确情况
(由于验证码会变化，这里手动输入验证码来完成正确的填写)
测试数据：账号 2021127
电子邮箱 [email protected]
验证码 （手动填写）
预期结果：进入忘记密码下一级操作
实际结果：向邮箱发送验证信息
2.检测注册功能
测试步骤：输入用户名
输入昵称
输入密码
重复输入密码
输入学校（可选）
输入邮箱
1）用例标题：用户名重复情况
测试数据：用户名 2021127
昵称 clkr
密码 123456
重复密码 123456
邮箱 [email protected]
预期结果：用户存在无法注册
实际结果：
2）用例标题：正常注册情况
测试数据：用户名 2021008
昵称 cll
密码 123456
重复密码 123456
邮箱 [email protected]
预期结果：成功注册并登录
实际结果：成功注册并登录
登录功能测试
脚本文件：loginTest1.java
分出正确账号密码，不正确账号正确密码，正确账号不正确密码，全部不正确账号密码四种用例测试。
错误输入包括缺位，错误输入，多输入，大小写错误，空格输入
用例举例如下
正确：
错误输入：
不正确账号正确密码，正确账号不正确密码，全部不正确账号密码无法登录
输入出现缺位，错误输入，多输入错误,密码大小写，密码空格错误无法登录。
测试界面稳定：
脚本文件：Test1.java
通过测试长时间处于同一页面是否会造成卡顿
打开页面并进行休眠
uoj项目部署中题目管理的相关学习
一.概述
1.新建题目和管理界面
只有超级管理员有权限新建题目，每次新建题目都必须由超级管理员完成。
在题目页面，超级管理员或该题目的管理员可以通过管理按钮进入题目管理界面。题目管理界面分为三个选项卡：
编辑：题面编辑页面
管理者：题目管理员管理页面
数据：题目数据管理页面
以及用来退出题目管理界面的返回按钮。
2.编辑题面
UOJ 的题面使用 Markdown 编写。
理论上，题面是可以自由编写的，但还是有一些推荐的格式和规则：
中文与英文、数字之间加一个空格隔开。
输入输出样例视为代码块，使用Markdown的 ``` 语法。
题面中最高级标题为三级标题。
一切数字、数学符号、运算符、变量名、公式应当用 LaTeX 语法编写。UOJ 自带 MathJax 插件来显示数学公式，行中公式用$
3.编辑标签
直接填入文本框即可，用英文半角逗号分隔多个标签。
理论上，标签是可以自由标定的，但还是有一些推荐的规则：
标签的目的是标出题目类型，方便用户检索题目。一般来说，标签顺序基本为从小范围到大范围。
最前面的几个标签是这题所需要的前置技能，这里假定 “二分查找” 之类过于基础的技能选手已经掌握。
接下来是这道题的大方法，比如 “贪心”、“DP”、“乱搞”、“构造”、“分治”……
接下来，如果这道题是非传统题，用一个标签注明非传统题类型，比如 “提交答案”、“交互式”、“通讯”。
接下来，如果这道题是模板题，用一个标签注明 “模板题”。
接下来，如果这道题是不用脑子想就能做出的题，例如 NOIP 第一题难度，用一个标签注明 “水题”。
最后，如果这题的来源比较重要，用一个标签注明。比如 “UOJ Round”、“NOI”、“WC”。
前置技能中，“数学” 太过宽泛不能作为标签，但 “数论” 可以作为前置技能。
如果有多个解法，每个解法的前置技能和大方法都不太一样，那么尽可能都标上去。
“乱搞” 标签不宜滥用。
请注意，如果您加入了“模板题”这一标签，这道题目便会进入模板题库。这一特性不能推广。
4.zip 数据包上传
这里上传时要打包为一个数据包，例如：
二.传统题配置
1.数据
对于传统题，上传的×.zip数据包应当包括这些内容：
题目配置文件
测试数据
额外测试数据（包括题面中所给的测试样例）
（开启 hack）数据检验器
（开启 hack）标准程序
2.题目配置文件
题目配置文件应当命名为problem.conf。这是一份配置的样例：
- [n_tests 10
n_ex_tests 1
n_sample_tests 1
input_pre www
input_suf in
output_pre www
output_suf out
time_limit 1
memory_limit 512
output_limit 64
use_builtin_judger on
use_builtin_checker ncmp ]
测试点
- [ n_tests 10
n_ex_tests 1
n_sample_tests 1]
这三行分别代表标准测试点、额外测试点和测试样例的数量。其中，额外测试点的前几个一定是测试样例，所以你必须把题目中给出的测试样例放到额外测试点当中。
UOJ 的 extra test 是指在 AC 的情况下会测额外数据，如果某个额外数据通不过会被倒扣3分。
- [input_pre www
input_suf in
output_pre www
output_suf out ]
这四行分别指明了每个测试点输入文件的前缀、扩展名、输出文件的前缀、扩展名。
标准测试点的文件名应当形如：www1.in、www1.out、www2.in、www2.out……
额外测试点的文件名应当形如：ex_www1.in、ex_www1.out、ex_www2.in、ex_www2.out……
限制
time_limit 1
memory_limit 512
output_limit 64
这三行配置了评测时对选手程序的时间限制、内存空间限制和输出限制。
时间限制的单位为秒，不能为小数。内存空间和输出限制的单位为 MB。
校验器（checker）
校验器用来检查选手程序的输出是否正确。
use_builtin_judger on
use_builtin_checker ncmp
第一行表示使用内建校验器，第二行表示使用的校验器类型。testlib 提供了很多奇奇怪怪的校验器。
三.特殊需求配置
由于很多题目有乱七八糟的配置，uoj用了一些不清真的方法来实现。
1.子任务
子任务模式中，必须把某个subtest的数据全部通过才能拿到对应的分数。
在problem.conf中，可以设置每个子任务在哪个测试点结束，并给每个子任务分配对应的分数。
它的写法如下：
- [ n_tests 40
...
n_subtasks 6
subtask_end_1 5
subtask_score_1 10
subtask_end_2 10
subtask_score_2 10
subtask_end_3 15
subtask_score_3 10
subtask_end_4 20
subtask_score_4 20
subtask_end_5 25
subtask_score_5 20
subtask_end_6 40
subtask_score_6 30]
每个测试点不同分值
如果需要对每个测试点给不同的分数，可以在problem.conf中用point_score_x实现。
它的写法如下：
- [n_tests 7
...
point_score_1 5
point_score_2 10
point_score_3 15
point_score_4 30
point_score_5 10
point_score_6 15
point_score_7 15 ]
2.ACM模式
ACM模式的题目，如果错掉任何一个测试点就不得分。
可以通过将所有的数据都放进一个subtask来实现。
四.数据检验器
uoj的数据检验器(val.cpp)使用testlib。
下面是A+B Problem的检验器：
#include "testlib.h"
using namespace std;
int main(void)
{
registerValidation();
inf.readInt(0,1000000000,"A");
inf.readSpace();
inf.readInt(0,1000000000,"B");
inf.readEoln();
inf.readEof();
return 0;
}
上面的代码是这样工作的：
registerValidation()：初始化。
inf.readInt(0,1000000000,"A")：读入叫做“A”的整形变量，范围必须在[0,1000000000]以内。如果不满足要求，则判定数据无效。
inf.readSpace()：读取一个空格。
inf.readEoln()：读取一个换行符。
inf.readEof()：读取文件结束符。
上面的读取中，只要有任意一个出现了偏差，则判定数据无效。
如果数据需要保证某个要求，可以使用ensuref()：
ensuref(cmd=='Q' || cmd=='A' || cmd=='C' , "您输入的操作不合法");
在上面的代码中，如果cmd既不是'Q'，也不是'A'或'C'，则判定数据无效，并提示您输入的操作不合法。
五.答案检查器
本文将引导您写一个自定义的checker（chk.cpp）。
按照套路，uoj的校验器也应该使用testlib编写。
下面是A+B Problem的校验器：
#include "testlib.h"
int main(int argc, char* argv[])
{
registerTestlibCmd(argc, argv);
int pans,jans;
pans=ouf.readInt(); // 读取选手输出
jans=ans.readInt(); // 读取答案
if (pans == jans)
quitf(_ok, "Correct.");
else
quitf(_wa, "WA! expect=%d recieve=%d", jans, pans);
}
在调用registerTestlibCmd之后，我们可以使用下面的三个流：
inf ： 输入数据
ouf ： 选手输出
ans ： 标准输出
从流中读取数据的方式，和【数据检验器】一致。
如果程序AC或者爆零，可以使用quitf()。但是如果想给选手部分分，使用下面的代码：
quitp(ceil(100.0 * p / a) / 100, "QAQ");
uoj概述
一、基本工作原理
UOJ 主要由两部分组成：网页端和测评端。顾名思义，网页端就是用来通过网页与用户交互的，测评端则是在用户发出测评请求时负责测评并将结果发送给网页端的。
- 网页端
什么是网页端？顾名思义，就是管网页的部分。网页端又分为网页前端和网页后端。所谓网页前端，就是你打开浏览器能看到的那部分。不过浏览器是如何知道自己要显示什么东西的呢？这就是因为服务器上还有网页后端，会以 HTML 代码的形式告诉浏览器它要显示些什么。
下面我们来理一下你从输入网址到看到网页的全过程。首先，你输入了 UOJ 的网址，然后浏览器就会根据你的网址去找到对应的服务器，并发一个消息给该服务器。这种消息称为 HTTP 请求（HTTP Request）。当然了，这取决于你的网址是以什么开头的。如果是 https 开头那么就是个加了密的 HTTP 请求，称为 HTTPS 请求。一个 HTTP 请求报文会包含很多很多信息，例如你输入的网址啦，例如你的 IP 啦。
服务器收到 HTTP 请求之后，会根据请求的内容进行相应的处理，并生成一个 HTTP 响应（HTTP Response），然后发回给你的浏览器。HTTP 响应报文也会包括很多信息。比如会包括状态码，正常情况下是 200，但如果对应的网址上没有东西可显示，那么会返回一个喜闻乐见的 404。当然最重要的是 HTTP 响应报文里面会包含一份 HTML 代码，这份代码会指示你的浏览器如何渲染出一个完整的网页。只要你在浏览器里鼠标右键，点击审查元素，就能看到这份 HTML 代码了。实际上，HTML 代码中可能还会内嵌有其他的元素，例如内嵌一些 JavaScript 代码就可以做一些动态的页面效果，内嵌一些 CSS 代码就可以更好的控制网页的排版。
总而言之，想要理解网页端，就得理解两部分：第一，浏览器是如何把 HTML 代码变成你所看到的网页的；第二，服务器是如何根据 HTTP 请求报文生成 HTML 代码的。前者属于网页前端的范畴，而后者属于网页后端的范畴。
- 测评端
光有网页端是不够的，因为如果用户提交了一份代码，UOJ 就得负责评测，而这往往不是几秒钟内能完成的，所以不能用 HTTP 响应的方式快速返回结果。因此，UOJ 的网页端服务器得把该测评请求发给另一个被我们称之为测评端的服务器，让它测评之后将测评结果发回，再通过网页端告知用户。
UOJ 官网的网页端和测评端服务器是分别部署在两台机器上的，不过为了方便起见，在我们发布的这版 UOJ 里网页端和测评端是放在同一台机器上的。
测评端又分为负责通信的部分和（真正）负责测评的部分。顾名思义，负责通信的代码控制的是和网页端服务器的交互，而负责测评的代码则是给选手交过来的文件打分的，最后负责通信的部分会将测评结果发回网页端。
二、网页端代码简介
下面我们稍微展开讲一讲 UOJ 网页前端和网页后端分别是如何实现的。
- 网页后端
UOJ 使用了一款开源的网页服务器软件，叫作 Apache。Apache 支持使用 PHP 语言来实现网页后端。进入 UOJ 的 docker，网页后端的代码就位于 /opt/uoj/web/ 目录下。Apache 收到一个 HTTP 请求之后，会运行 index.php（这一行为其实是由同目录下的 .htaccess 指定的）。index.php 会加载所需的函数库和类库，然后根据路由文件（route file） 去给请求中的网址匹配用于生成响应报文的 PHP 代码。所谓路由文件其实也是 PHP 代码，只不过这种文件记录了一个从网址到代码文件路径的映射。控制主站路由的是 app/route.php，控制博客路由的是 app/controllers/subdomain/blog/route.php。
我们称路由文件中被映射到的代码为控制器（controller），位于 app/controllers 目录下。index.php 给请求中的网址匹配到对应的控制器后，控制器会根据用户的 HTTP 请求报文的具体内容生成一个 HTTP 响应报文，交由 Apache 负责发回给作出 HTTP 请求的浏览器。
早期 UOJ 的网页后端是我们一点一点自己写的，架构上没有参考任何的现有开源项目。后来我们发现有些架构的设计思路理不太清楚，于是去学习了一下著名的 Laravel 框架。所以代码架构实则是介于早期 UOJ 架构和 Laravel 之间的一种架构，没有像早期架构那么乱，也没用像专业的 Laravel 那样包装得很深，希望这样能兼顾代码的可维护性和可阅读性吧。
- 数据库
数据库是网页后端的一部分，但又是较为独立的一部分。通常我们在 OI 中会使用数组来存储数据，但一旦你把程序掐了，或者电脑关机了，数组里的内容就丢失了。这是因为数组通常是存储在内存里的，而非机械硬盘、固态硬盘等可持久存储的介质上。那么如何把数据保存在硬盘上呢？你可能已经开始摩拳擦掌准备写个 B 树了，但是且慢 —— 如今有很多数据库软件已经帮你写好了。
UOJ 使用的是 MySQL 数据库。在 UOJ 的后端 PHP 代码里，你可以通过访问 DB 这个静态类来跟数据库进行交互。交互使用的是 SQL 语言，一种专门为数据库中数据的查询、修改、插入、删除而设计的语言，你可能需要稍微学习一番这种特殊的语言。DB 是对 SQL 的一种简单包装，请参照现有代码调用 DB 的方式来更好的理解其用法。
- 网页前端
大部分的网页前端代码实际上是由 PHP 一行一行输出出来的。负责这种输出的代码一部分位于各个控制器代码中，一部分 app/views 目录下。理想情况下，如果一段 PHP 代码能生成一长段 HTML 代码，且生成的过程不包含任何控制逻辑或者数据库查询，那么该 PHP 代码就应该放在 app/views 里作为一种视图（view）；否则就应该放在 app/controllers 下作为一种控制器。例如，每个页面都会包含的页头和页尾就写在了 app/views/page-header.php 和 app/views/page-footer.php 这两个视图文件里。当然了，严格遵守这样的规则会让一些简单的代码变得结构很复杂，所以目前的 UOJ 代码并没有严格遵守这一点。
其实，并非所有前端代码都是 PHP 一行行输出出来的。HTML 代码中通常会内嵌一些 CSS 和 JavaScript 来控制页面排版和制造一些动态页面效果，而这些部分往往是跟页面具体内容独立的。所以有很多优秀的前端框架，例如 Bootstrap。UOJ 目前使用的是 Bootstrap 3。所以，要想完全理解前端的代码，你不仅需要阅读对应的控制器和视图的内容，还要学习一下 Bootstrap 的使用方式。如果你尚未接触过前端开发，不妨先找点前端开发教程，试着做一点不需要 PHP 的静态小网站，然后再回过头来阅读 UOJ 的代码。
- 重要文件目录
网页端的代码和相关文件主要在 /opt/uoj/web/ 目录下。下面列出了一些重要的文件和子目录：
app/：UOJ 主要的后端 PHP 代码目录
controllers/：存放控制器文件的目录
locale/：存放页面上的文字在不同语言下的翻译的目录
models/：UOJ 运行所需的一些 PHP 类
storage/：存储一些文件数据的目录
submissions/：存放用户提交的测评请求中附带的文件的目录
tmp/：存放临时文件的目录
views/：存放视图文件的目录
route.php：主站路由文件
uoj-*-lib.php：一些 UOJ 运行所需的函数库文件
vendor/：一些 UOJ 使用的第三方 PHP 代码库，由 Composer 管理。
public/：一些可以不经过 PHP 直接访问的资源
css/：存放部分 CSS 代码文件的目录
fonts/：存放字体文件的目录
js/：存放部分 JavaScript 代码文件的目录
libs/：一些 UOJ 使用的前端库，例如 Bootstrap，jQuery 等等
pictures/：存放部分图片文件的目录