Alpha阶段测试报告_阿尔法测试流程

Alpha阶段测试报告

声明：如果需要查看具体的测试报告和测试用例，可以联系本组的PM-林子杰。

一、测试矩阵

测试使用的工具为LAMBDATEST，针对多种浏览器内核进行了测试。

二、API测试报告

采用ApiFox进行前端api测试。

测试用例构造

在ApiFox测试工具中输入参数，向后端发送请求，后端会返回便于判断的处理信息。通过设置断言，判断后端返回值是否正确。

对于需要token的操作，可以使用ApiFox中全局变量的功能。编写完单个测试点，将多个测试点合并为测试用例，将测试用例合并为测试套件，进行综合测试。

由于ApiFox会真实的对数据库进行操作，因此测试时要尽量保证无后效性，测试用例一般是闭环设计。

对于地图点的测试流程如下：插入-查询-修改-删除

对于用户个人信息测试流程如下：登陆-查询-修改信息-修改密码-还原密码-登出

测试其余功能时，我们设置了一个永久有效的Token用于测试（Token非常复杂，不易泄露）

测试结果

测试结果表明，所有api接口均能够正确传值且返回值均符合要求。

网页性能测试报告

总览

我们的网站主要有四个网页，我们针对这四个网页使用Google的Lighthouse插件进行了性能测试。该插件从以下几个方面对网页进行了评价：

• 性能（Performance）：衡量页面的加载速度和响应性能的指标
• 可访问性（Accessibility）：衡量页面是否易于访问和使用的指标
• 最佳实践（Best Practices）：衡量页面是否遵循最佳实践的指标，如安全性和可维护性等
• SEO（Search Engine Optimization）：衡量页面在搜索引擎上的排名和可见性的指标

在报告中，我们会根据报告侧重分析一些指标的可改进性。

登陆界面

• 性能：由于登陆界面的BUAA图标是存放在腾讯云COS上的，故而读取速度偏慢，这影响了性能分数；另外，还有一些无用的样式和老旧的CSS影响了性能，这可能是全局引入Element-Plus和编码方式表示的；最后，Lighthouse认为我们可以尝试使用更长的缓存时间，以便于用户重复访问
• 最佳实践：主要的丢分点在于没有使用HTTPS协议进行传输。但是使用HTTPS协议貌似需要购买SSL证书，并且价格比较昂贵，不知道有没有别的办法

注册界面

• 性能：问题同【登陆界面】
• 最佳实践：问题同【登陆界面】

地图界面

• 性能：大部分问题和登陆界面相同；另外，Lighthouse认为网站最好使用被动监听器，而不是普通监听器，以提高网页性能
• 可访问性：Lighthouse认为，对于可点击按钮和图片，最好有文本表描述以提高可访问性。不过实际上，在我们的设计当中辅助性的描述文本不是很有必要。另外，报告指出网页背景色和前景色的比较不足，我们认为这是一个可改进的问题
• 最佳实践：问题同【登陆界面】

个人信息界面

• 性能：问题同【登陆界面】
• 最佳实践：问题同【登陆界面】

另外，对于SEO，LightHouse认为网页的robots.txt不合法；并且网页缺少meta描述标签。

对于上述的问题，在测试完成之后已经开始了陆续的改进，这些改进未必会更新到此文档中。

附上一张测试报告的截图：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-koqpQV8h-1682508153368)(null)]

压力测试

后端API压力测试通过JMeter工具实现。

本测试选取两个具有代表性、现实场景访问次数可能最多的API测试，分别为用户登录API和主页获取所有地图钉API。

用户登录

经测试，当线程并发数超过4000后，便会出现请求超时导致失败的现象：

获取所有地图钉

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EuegnQ6v-1682508153315)(null)]

同样，并发数超过4000后，服务器难以处理所有请求。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mBk2HrRG-1682508153347)(null)]

测试结论

1. 我们服务器能稳定支持的并发数在4000以下，最适合的并发数在1000以下。相对于我们项目的预估使用人数，这一现象是可接受的。
2. 服务器在不同时间段处理请求的能力有差距，处理请求的速度会有波动。
3. 不同API的请求速度不同，登录API相对更慢可能因为其中具有密码加密、判断功能，更耗时，但总体来说服务器能处理的最大并发数相似。

安全性测试

xss攻击

由于前端路由内并没有可传递参数，所以不存在xss攻击的可能性

SQL注入

防护原理

后端SpringBoot通过Mybatis方式操作数据库，利用MybatisX插件自动化生成对应SQL语句，格式如下：

<select id="findAllByEmail" resultMap="BaseResultMap">
    select
    <include refid="Base_Column_List"/>
    from user
    where
    u_email = #{email,jdbcType=VARCHAR}
</select>
1
2
3
4
5
6
7

可以看出，对于可能存在安全隐患的用户输入在SQL语句里以${}引用，确保了变量为SQL格式，也不会被当做SQL语句执行。

除了上述安全性测试外，我们还通过别的技术增强了应用的安全性：
SpringBoot利用腾讯云COS实现图床
Spring Security+JWT实现用户验证与授权
最后，附上本组进行修复时的Bug目录，该链接链向一个Notion文档：
Bug汇总