个人博客系统测试报告

一、项目背景

1 个人博客系统采用了前后端分离的方法来实现，同时也使用数据库来存储相关的数据，并且将其部署到云服务器上。前端主要有四个页面构成：登录页、列表页、详情页以及编辑页，以上模拟实现了最简单的个人博客系统。其结合后端实现了以下的主要功能：登录、编辑博客、注销、删除博客、以及强制登录等功能。

2 但该项目没有设计用户注册功能，只能提前在数据库中存储用户信息后经过校验登录；并且用户头像不能自己设定，在进行前端页面的书写过程中已经将头像的图片写为静态了；而用户信息中的文章数以及分类数也没有在后端中具体实现，直接在前端页面中写为了静态的。

3 该个人博客系统可以实现个人用户简单的博客记录，时间、标题、内容以及发布者等都可以进行详细地查看。

二、项目功能

该系统主要实现的功能：登录、注销、写博客、删除博客等功能。
1.登录功能：用户名以及密码已经在后端写入了数据库，没有实现账户注册功能，即：用户名以及密码是已经存在的。登录成功后就会跳转到列表页面。在右上角存在主页和写博客两个按钮，但是在未登录情况下按下均只会跳转到登录页面。

2.列表页面：可以在列表页查看博客简介，其包括博客标题、发布时间以及内容概要。在左侧可以看到登录的用户以及文章数、分类数等的模块。在右上角有主页、写博客和注销三个功能：主页即列表页，写博客即博客编辑页，注销即注销用户，回到登录页面。

3.详情页面：在列表页面点击“查看全文”按钮就会跳转到详情页，此时就可以看到该篇博客的完整内容。在右上角同样有主页、写博客、删除和注销四个功能：删除即删除该篇博客，删除之后就会跳转到列表页面，该篇博客就被成功删除。

4.写博客：在登录之后的任意界面点击“写博客”之后就会进入博客编辑页面，此时就可以进行博客的编写，点击“发布文章”后就可以成功发布文章，此时就会跳转到列表页。

三 、测试计划

1.功能测试

(1)测试用例

（2）正常登录

（3）写博客

（4）发布成功后的博客

（5）删除博客（即点击删除后，可自动删除完这篇博客）

（6）注销博客（点击注销后，自动回到登录界面）

2.自动化测试

（1）思维导图

（2）代码编写
根据思维导图对每一个页面进行测试
公共属性要单独放一类，方便代码复用
单独创建一个截图存储，因现场截图会频繁复用
添加隐式等待，确保页面正确加载显示

（3）添加相关驱动，如selenium、webdriver-mananger等。

（4）新建包并在包下创建测试类以及公共类
以下common是公共包，test是测试包。

公共类image：
用来保存测试截图
在保存现场截图的时候命名是按时间来进行文件夹的划分，而且图片的名称要体现出测试类的类名，方便进行问题的追溯。
文件名的动态获取，要注意时间格式的设置。
可以在创建驱动的时候修改默认的有头模式or无头模式。

登录页面测试BlogLoginTest：
创建驱动，并打开页面；
测试页面是否正常打开；
测试正常登录：多参数测试；
测试异常登录：用户名/密码错误的情况（此处不测null）；
注意测试的顺序，使用Order注解指定，否则可能会因为执行顺序不对导致测试失败；
注意清空内容后才能再次输入用户名以及密码。

列表页测试BlogListTest：
测试博客列表页是否可以正常打开；
测试列表页的“查看全文”按钮是否可以正常跳转；
测试未登录的直接链接是否会跳转到登录页面，顺便测试了“注销”按钮；
同样注意执行顺序 。

编辑页测试BlogEditTest：
测试编辑页是否可以正确打开；
测试博客是否可以正常发布：元素齐全 or 部分元素；
测试“写博客”按钮是否可以正常使用；
执行顺序。

详情页测试BlogDetailTest：
测试详情页的正确打开：有blogId和没有blogId两种情况；
测试“删除”按钮是否可用，注意比较的是时间，因为标题可能会存在为空的情况；
执行顺序；
一定要注意导航回到列表页的操作。

驱动释放RunCasesTest：
因为驱动的测试是要在最后一个测试类完成之后进行释放的，如果是使用@AfterAll注解，那么每次修改测试类的时候都会需要挪动驱动释放的位置，所以直接新建一个类作为驱动释放，此时只需要在测试套件中放到最后就行。

3.性能测试

登录测试
（1）通过开发者的开发工具来请求所要写的格式，用来进行性能测试的编写。注：用户名和密码要用from形式进行发送.

（2）因为用户名和密码有多个，可以参数化
（3）脚本测试通过

（4）设置并发数量进行性能测试，及导出测试报告和图表
设置好线程组

开始进行运行，性能测试开始（运行中+结束截图）
运行中：

结束后：

生成html报告后，在html报告中查看

报告：
通过率：

随时间推移：

吞吐量：
响应时间：

（5）性能分析（通过三大指标分析性能问题）
响应时间：
如果响应时间超过了要求，代表系统到了瓶颈
注意事项：分析在多少线程的情况下发⽣了超标

错误率：
⾼并发场景下，系统是否能够正常处理业务
要求：99.99%可靠，99.9999%

吞吐量：
吞吐量越⼤，性能越好；吞吐量相对稳定或者变低，可能系统达到了性能瓶颈；
吞吐量变化规律：
波动很⼤：代表系统性能不稳定
慢慢变⾼，再趋于稳定：和并发量强相关。如果并发量⼩于吞吐量，慢慢增⼤并发量，吞吐量也会随 之增加；
慢慢变低，并发量也减少了：要么说明性能测试要结束了，并发减少；也可能是系统变的卡顿，从⽽ 导致响应时间变慢，导致单个线程发起的并发量变少。