组名：SE真香队
项目：基于网络爬虫的小湖知识图谱系统
组：软件1602班第6组
在这个学期，我们组做了基于网络爬虫的小湖知识图谱系统，在做项目的过程中，团队成员都觉的很完美，然而，最后一个周进行测试的时候（虽然是手动测试）发现我们的这个系统仍然存在很多bug，有些bug及时修改了，而有些bug则很难改，或者来不及改，如下是我们组的测试报告：
第1章引言
1.1目的
本测试报告的具体编写目的，指出预期的读者范围。
本次测试报告的目的是，记录项目测试历史，保留项目测试数据以及测试方法，将本项目仍存在的不足之处记录下来，方便接下来的开发者了解项目历史。
1.2名词解释
列出本计划中使用的专用术语及其定义。
列出本计划中使用的全部缩略语全称及其定义
1、白盒
白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作
2、黑盒
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能的情况下，通过测试来检测每个功能是否都能正常使用的一种测试方法。
3、爬虫
网络爬虫（又被称为网页蜘蛛，网络机器人），是一种按照一定的规则，自动地抓取万维网信息的程序或者脚本。
1.3参考及引用的资料
列出本计划各处参考的经过核准的全部文档和主要文献。
无
第2章 测试概述
2.1测试对象
本项目的测试对象分为两个：爬虫程序及网站。
2.2项目背景
学生们在小学或者初中，高中的时候，每天都可以和老师接触，这样自然很容易就可以了解到自己的任课老师们的信息或者是和老师们取得沟通，但我们到了大学以后，学生与老师的交流机会减少了，那么学生们想要了解到老师们的信息就会变得困难，本项目就是为了解决学生这一困境而产生的。本项目主要的功能就是从各学校的官网上爬取教师们公开的信息，并以知识图谱的方式展现在网站上，方便学生查阅。
2.3测试目的
1、爬虫方面：测试爬虫程序是否能够成功的从网站上爬取到我们所需要的教师相关的信息。
2、网站：
①以用户身份测试是否能够顺利使用网站上的各种功能，并成功的查询到所需要的相关信息。
|
测试要点 |
测试范围 |
测试 |
|
用户登录 |
输入错误的账号密码，输入正确的账号密码 |
确保只有输入正确的账号密码才能完成用户登录 |
|
用户修改信息 |
修改用户账号上资料中的昵称等信息 |
确保用户可以正常的修改信息 |
|
用户查看教师信息 |
用户点击教师管理后，查看教师信息 |
测试是否能够看到教师信息 |
|
用户搜索教师信息 |
输入正确的教师信息，输入错误的教师信息 |
确保只有在用户输入了正确的教师信息的情况下，才会显示相应老师的相关信息 |
|
用户查看知识图谱 |
点击知识图谱按钮 |
确保用户可以正常的查看知识图谱 |
|
用户查看学院信息 |
用户点击学院管理，查看学院信息 |
测试是否能够看到已有的学院信息 |
|
用户搜索学院信息 |
用户输入学院相信信息 |
测试是否能够看到学院的相关信息 |
|
用户搜索学校信息 |
用户输入学校相关信息，点击搜索 |
测试是否能够看到学校的相关信息 |
|
用户查看学校信息 |
用户点击学校管理，查看学校信息 |
测试用户是否能够看到已有的学校信息 |
②以管理员身份测试是否能够根据需求进行各种数据管理以及权限分配。
|
测试要点 |
测试范围 |
测试 |
|
管理员登录 |
输入正确的账号密码，输入错误的账号密码 |
测试是否只有输入正确的账号密码时才能登录入系统 |
|
管理员修改信息 |
修改账号上的昵称等信息 |
测试是否管理员可以顺利的修改账号上的信息 |
|
管理员重置密码 |
输入新的密码 |
测试是否管理员可以顺利修改密码 |
|
管理员添加学校 |
管理员填写学校的相关信息后添加学校 |
测试是否有必填项提示，测试是否可以顺利添加，测试是否不能输入空数据 |
|
管理员修改学校 |
管理员选中一个学校后点击修改，修改学校的相关信息点击确定后更新学校相关信息 |
测试是否有必填项提示，测试是否可以顺利修改，测试是否不能输入空数据，测试是否提示选中一个学校 |
|
管理员删除学校 |
管理员选中一个学校后，点击删除以删除学校 |
测试是否提示选中学校，测试正确操作后是否能够顺利删除学校 |
|
管理员查询学校 |
管理员输入相应信息后点击查询 |
测试是否能够成功输出相关学校信息 |
|
管理员添加学院 |
管理员填写学院相关信息后点击添加 |
测试是否有必填项提示，测试是否可以顺利添加，测试是否不能够输入空数据 |
|
管理员修改学院 |
管理员选中一个学院后点击修改，修改学院的相关信息点击确定后更新学院相关信息 |
测试是否有必填项提示，测试是否可以顺利修改，测试是否不能够输入空数据，测试是否提示选中一个学院 |
|
管理员删除学院 |
选中一个学院，点击删除 |
测试是否提示选中学院，测试正确操作后是否能够顺利删除学院 |
|
管理员查询学院 |
管理员输入相应信息后点击查询 |
测试是否能够成功输出相关学院信息 |
|
管理员添加教师信息 |
管理员填写教师信息后点击添加 |
测试是否有必填项提示，测试是否可以顺利添加，测试是否不能够输入空数据 |
|
管理员修改教师信息 |
管理员选中一个教师后点击修改，修改学校的相关信息点击确定后更新学校相关信息 |
测试是否有必填项提示，测试是否可以顺利修改，测试是否不能够输入空数据，测试是否提示选中一个教师信息 |
|
管理员删除教师信息 |
选中一个教师，点击删除 |
测试是否提示选中教师信息，测试正确操作后是否能够顺利删除相关教师信息 |
|
管理员查询教师信息 |
输入相关信息后，点击查询 |
测试是否能够成功查询 |
|
管理员查看知识图谱 |
管理员点击查看知识图谱 |
测试是否能够正确显示出知识图谱 |
|
管理员添加反馈信息 |
管理员添加相关信息后点击添加。 |
测试是否有必填项提示，测试是否可以顺利添加，测试是否不能够输入空数据 |
|
管理员删除反馈信息 |
管理员选择一条信息后点击删除。 |
测试是否提示选中反馈信息，测试正确操作后是否能够顺利删除反馈信息 |
|
管理员进行系统管理 |
进行系统管理的相关操作 |
测试相关操作是否能够生效，是否符合要求。 |
|
管理员任务管理 |
管理员进行任务管理的相关操作 |
测试任务管理的相关操作是否能够实现，是否符合相关要求 |
2.4测试时间
测试开始时间：2018年12月31号
测试结束时间：2019年1月3号
2.5系统结构
第3章 测试方法
测试方法和测试环境的概要介绍，包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介。
2.1测试用例设计（略）
（略）
3.1
3.1.1硬件环境
3.1.2软件环境
windows xp及以上系统，IE 10及以上版本浏览器。
3.2 测试工具
使用了开发工具idea进行了测试，除此之外，我们没有使用其他的测试工具。
3.3测试方法
1.白盒测试法
白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作
这部分的测试由组内相关部分开发人员在写完代码时进行。
2.黑盒
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能的情况下，通过测试来检测每个功能是否都能正常使用的一种测试方法。
在本次的测试中，我们组采用的主要技术就是黑盒测试。在测试过程中有意不考虑程序内部结构，站在用户及管理员的角度对项目进行测试。
第4章 测试结果及缺陷分析
这是测试报告的核心，主要汇总测试各种数据并进行度量，度量包括对测试过程的度量和能力评估、对软件产品的质量度量和产品评估。
4.1 覆盖分析
4.1.1需求覆盖分析
需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到100％的目标。
根据测试结果，按编号给出每一测试需求的通过与否结论。
需求覆盖率=测试通过需求点/需求总数×100％
经过分析比较，我们可以很轻易的得出如下结论，凡是在需求所明书上的需求都经过了我们的测试，所以本次测试，我们的需求覆盖率应当是100％。
4.1.2测试覆盖分析
（如无测试用例部分，该部分可忽略）
测试覆盖是指根据经过测试的测试用例和设计测试用例的比值，通过这个指标获得测试情况的数据。
测试覆盖率=执行数/用例总数×100％
测试通过率=通过数/执行数×100％
无测试用例。
4.2 缺陷统计与分析
对测试过程中产生的缺陷进行统计和分析。
在本次的测试中，我们总共统计出了8个缺陷，这些缺陷分布在重置密码的短信验证，任务管理，任务运行，知识图谱生成等模块
4.2.1缺陷统计
4.2.1.1所有bug列表
这部分主要列出测试过程中的所有bug，并对其进行描述。
1、添加信息时没有必填项提示。
2、在添加各种信息时，可以输入空数据
3、任务管理修改开始时间时，只能读取到年月日的数据，但是数据库能够保存到时分秒
4、任务不能到点自动运行，任务设置了运行开始时间及结束时间，但是到了时间并不能执行相关操作。
5、在重置密码时，第一次不能发短信，必须要输入完整信息有错误用例之后才能发送验证短信。
6、当用户输入不对应自己的手机号的时候修改失败，但是没有提示
7、知识图谱展示时，搜索相关实体时，无法显示其附近的三元组。
8、爬虫部分结果无法写入数据库，因为网站上面的数据格式不同，虽然已经对不同格式进行了处理，但是仍有部分数据无法写入。
9、当输入的信息过多时，知识图谱显示会出现重叠。
10、删除信息时，没有确认删除的提示框
4.2.1.2重要解决bug列表
这部分主要列出测试过程中产生关键的并且解决了的bug，对于重要的bug，需要对其产生的原因和解决方法进行分析说明。
1、添加信息时没有必填项提示。
2、在添加各种信息时，可以输入空数据
4.2.1.3遗留bug列表
3、任务管理修改开始时间时，只能读取到年月日的数据，但是数据库能够保存到时分秒
4、任务不能到点自动运行，任务设置了运行开始时间及结束时间，但是到了时间并不能执行相关操作。
5、在重置密码时，第一次不能发短信，必须要输入完整信息有错误用例之后才能发送验证短信。
6、当用户输入不对应自己的手机号的时候修改失败，但是没有提示
7、知识图谱展示时，搜索相关实体时，无法显示其附近的三元组。
8、爬虫部分结果无法写入数据库，因为网站上面的数据格式不同，虽然已经对不同格式进行了处理，但是仍有部分数据无法写入。
9、当输入的信息过多时，知识图谱显示会出现重叠。
10、删除信息时，没有确认删除的提示框
4.2.2缺陷分析
本部分对上述缺陷和其他收集数据进行综合分析。
部分缺陷因为改动影响过大所以没有改。
4.2.2.1缺陷综合分析
缺陷发现效率 ＝ 缺陷总数/执行测试用时
可到具体人员得出平均指标
用例质量 ＝ 缺陷总数/测试用例总数 ×100％
缺陷密度 ＝ 缺陷总数/功能点总数
缺陷密度可以得出系统各功能或各需求的缺陷分布情况，开发人员可以在此分析基础上得出那部分功能/需求缺陷最多，从而在今后开发注意避免并注意在实施时予与关注，测试经验表明，测试缺陷越多的部分，其隐藏的缺陷也越多。
本次测试时长持续三天，缺陷发现效率为：8/3（个/天）
缺陷密度为：8/29
4.2.2.2测试曲线图
描绘被测系统每工作日/周缺陷数情况，得出缺陷走势和趋向。
无
4.3 性能数据与分析
这部分简要地列出性能测试结果，并对测试结果进行分析说明，以说明是否符合软件需求。该部分也可以在性能测试报告中进行说明。
无
4.3.1性能数据
记录测试输出结果，将测试结果的数据表格，图表如实的反映到测试结果中。用于数据分析。
无
4.3.2测试结论
测试通过，能够正式发布。
第5章 测试总结和建议
这部分是测试报告中最关注的内容，主要是对测试过程产生的测试结果进行分析之后，得出测试的结论和建议。这部分为测试经理、项目经理和高层领导最关心的部分，因此需要准确、清晰、扼要地对测试结果进行总结。
5.1软件质量
说明该软件的开发是否达到了预期的目标，能否交付使用。
本项目虽然还存在一些小问题，但是我们基本达到了预期的目标，已经能够交付使用
5.2软件风险
说明测试后可能存在的风险，对系统存在问题的说明，描述测试所揭露的软件缺陷和不足，以及可能给软件实施和运行带来的影响。
软件可能存在的风险应该是知识图谱展示方面，如果展示数据过大，会导致知识图谱出现严重的重叠
5.3测试结论
对测试计划执行情况以及测试结果进行总结，包括：
1．测试计划执行是否充分（可以增加对安全性、可靠性、可维护性和功能性描述）
2．对测试风险的控制措施和成效
3．测试目标是否完成
4．测试是否通过
5．是否可以进入下一阶段项目目标
本次测试的计划执行的十分充分，解决了项目中的一些问题，而且测试目标基本完成，项目的测试可以通过，项目可以进入下一阶段的开发与测试。
5.4 测试建议
对软件的各项缺陷所提出的改进建议，如：各项修改的方法、工作量和负责人、各项修改的紧迫程度、后续改进工作的建议、对产品修改和设计的建议、对过程管理方面的建议等。
接下来的测试应该偏重知识图谱的展示以及短信验证方