Simdep Beta版本测试报告

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程
这个作业的要求在哪里	团队项目-Beta阶段测试报告
我们在这个课程的目标是	熟悉并掌握软件工程
这个作业在哪个具体方面帮助我实现目标	Beta阶段测试发现bug，提供稳定可靠的软件

测试项目

具体的测试方案请参考‌‍测试方案Beta⁣‌‌⁢⁤‍‍⁢⁣⁡‬⁢⁡‌⁢‬⁡⁤⁤⁤⁢‍⁣⁢⁡‬‬⁤‍⁣‬‬⁡⁢，这里仅报告测试矩阵及结果。

前端测试

前端仍然是首先测试兼容性和内容正确性，同时兼顾易用性/交互性/引导性和美观性的评审。

测试条例\操作系统，浏览器，设备	Windows Microsoft Edge 版本 112.0.1722.58(正式版本)(64 位)	Windows Google Chrome 版本 112.0.5615.138(正式版本)(64 位	MACOS Apple Safari 版本 16.4 (18615.1.26.11.23)
页面元素检查，是否还原原型	通过	通过	通过
页面布局、缩放适应度检查	缩放25%, 50%元素折叠	缩放25%, 50%元素折叠	缩放25%, 50%，75%元素折叠
管理员视图	通过	通过	通过
项目视图	通过	通过	通过
触发器与文件视图	通过	通过	通过

后端测试

单元测试

单元测试在开发过程中编写，用于保证后续开发不会影响之前接口的正确性。我们使用Github Actions将单元测试运行集成进ci中，自动生成，发布测试报告。由于Beta版本和k8s深度绑定，因此对于涉及调用k8s接口的代码的单元测试较为困难（fake-client适配性问题等等）。因此我们的单元测试覆盖率目标在60%以上。

场景测试

针对Beta版本新增的两个用户使用场景，我们进行部署测试。

1.1 典型用户：平台管理员

姓名	管员理美
年龄	20-30
用户市场比例	10%
用户重要性	重要
典型场景	部署平台，并对其进行配置，以满足平台用户的需求
动机	需要尽可能配置服务器来满足一个群体的使用需求，并且降本增效
困难	Alpha版本的函数平台部署很麻烦而且没有对私有化部署做支持功能上放权不够，自由度并不高
特点	可以承担一定的学习成本，但是需要自由度

典型应用场景：平台管理员需要对于一个服务器集群寻找一个合适的管理平台，调研到了SimDep平台决定选择该平台作为集群管理平台。

利用平台提供的文档安装上了Kubernetes集群，根据集群拓扑结构信息编写好配置文件后，利用平台提供的yaml文件将平台部署到了集群中。

apiVersion: v1
kind: Service
metadata:
  name: container-manager
spec:
  selector:
    app: container-manager
  ports:
  - port: 80
    targetPort: 8080

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: container-manager
spec:
  selector:
    matchLabels:
      app: container-manager
  template:
    metadata:
      labels:
        app: container-manager
    spec:
      replicas: 2
      containers:
      - name: container-manager
        image: docker.io/realssd/simdep-manager:latest
        resources:
          limits:
            memory: "256Mi"
            cpu: "500m"
        ports:
        - containerPort: 8080
...
# 容器管理样例，详情参见发布版本提供的配置文件

部署完成集群后，管理员制作了几种用户需要的基础镜像，并配置了对应的工程模板，根据配置文件中设置的用户名和密码登录上平台后将基础镜像添加到了平台上，为机构用户创建了账户。

1.2 典型用户：平台用户

姓名	揩发褶
年龄	20-30
用户市场比例	50%
用户重要性	重要
典型场景	在平台上配置对应的函数，可能用于调试，也可以用于使用
动机	需要一个开箱即用，上传即跑，跑完就丢的部署环境
困难	配服务器好烦，不想搞了为什么这么穷，不能每个人一台思聪级别的服务器我自己建的环境，为啥还要自己清理啊
特点	有点懒，但是不完全懒

在拿到管理员给的初始用户名和密码后，开发者登录上平台对密码进行了修改。并下载了自己需要部署的函数类型的工程模板，把自己的代码适配工程环境后，将目录压缩为一个zip包，选择基础镜像、

之后进行部署时，在Webshell即可访问自己上传的文件

性能测试

负载测试

该部分仍旧沿用JMeter，对Beta版本的新增接口进行压力测试。测试配置如图：我们通过设置线程组的线程数来控制并发量。

对于管理员API，因其大部分不涉及多用户交互，且启动停止函数已经在Alpha版本进行过压力测试，因此仅对具有代表性的几个接口测试。

Beta版本的接口大部分由Go编写，相较于python，稳定性和性能有了足量的提升。甚至对于Beta版本目标用户极少会遇见的1000高并发场景，我们仍然能保持较Alpha版本更高的稳定性（76.80% vs. 20.81%），并且查询类的服务保持了0.00%的异常率。

压力测试

除Alpha版本关于在线人数与响应服务之外。Beta版本由于是To B的用户群体，因此首先关注稳定性，针对下面两个常用设置进行稳定性测试：

条目	方法	1h	24h	备注
WebShell运行稳定性	长时间连接，测试连接的可靠性。	🆗	🆗	该项对稳定性要求较高，因此我们仍然在进行测试以探索其边界。
计算服务运行稳定性	部署简易深度学习镜像，测试容器服务的稳定性。	🆗	🆗	该项保证了用户服务运行稳定性，对于如深度学习训练等应用场景，我们期望其保持30天以上的稳定性

安全性由于平台目标是部署在本地网络因此暂未考虑进行测试。

问题回答

测试过程中发现了多少BUG

我们将测试过程中的BUG共享到Beta前后端联调问题中。针对这些BUG，我们分配给专员进行处理。

场景测试

参考后端测试下的场景测试，以及后续待发布的最佳实践环节。

测试矩阵

测试矩阵请参考前端测试中的兼容性测试。

出口条件

相较于Beta版本，我们首先重构了前端的UI\UX、操作逻辑和用户引导，使其更加人性化，更富有交互性。

除此针对Beta版本的核心API，我们都使用了Go语言进行编写，并维护服务的高稳定性，确认其在大多数环境下运行良好。

因此我们的出口条件由Alpha版本转变为：

• 具备功能齐全的前端页面 ——> 具有简洁，美观的前端页面
• 提供功能文档、教程 ——> 提供功能文档、教程 + 体现良好的用户交互设计，上手简单
• 面向小规模用户服务 ——> 稳定，处理的服务系统，本地部署的

我们定义该版本的软件需要满足以下条件：

• 提供简洁、容易交互的前端页面
• 通过功能测试，无高优先级bug，无重大功能缺失。
• 通过兼容性测试，适配高频浏览器应用和主流的PC环境。
• 通过场景测试，能够部署上述典型的应用场景。
• 通过压力测试，提供稳定、可靠和高效的服务。

对于上述条件，我们Beta版本的软件已经达到。因此作为测试人员，我认为我们的项目达到了Beta版本的发布条件。