[软工顶级理解组] Beta阶段测试报告

1. 在测试过程中发现了多少Bug？

   • 测试阶段发现并已修复的bug：

     

     

   • 尚且存在，但是难以解决或者不影响使用的bug：

     • 计算重修课程的时候，如果重修课程的课程号和原课程号不同，则GPA计算会出现误差。但我们无法验证两门课是否存在重修关系。
     • 发布课程评价时，可能会出现评价页面没有显示自己的评价，需要退出去重进才能显示的情况。
     • DDL推送功能需要后台保持程序在线才能提醒，是因为我们使用的推送框架是收费才能离线提醒，而我们使用了免费版。

2. 你是怎么进行场景测试（scenario testing）的？包括你预期不同的用户会怎样使用你的软件？他们有什么需求和目标？你的软件提供的功能怎么组合起来满足他们的需要？

   在Alpha阶段已经提到的用户类型，此处不再提及。此处提及预期用户会如何使用我们的新功能。

   • 北航普通学生

     用户信息	用户情况
     姓名	东方仗助
     用户身份	很想了解课程评价，以及参与评价的同学
     用户动机	希望能有一个有学校开设课程信息的软件，供大家分享不同课程的口碑
     用户困难	目前市面上没有这种东西，只能靠大家在微信群口口相传
     典型场景	通过航胥来查询课程评价

   • 场景测试：东方仗助

     • 需求分析：东方仗助要选课了，但它不知道这些选修课的口碑如何，必修课也不知道要选择哪个老师，很想了解他们的评价。
     • 使用场景：东方仗助打开了航胥APP，在课程评价功能中找到了上过这门课的同学对其的评价，成功的获取到了自己想要的信息。

   • 经常忘记DDL的冒失同学

     用户信息	用户情况
     姓名	广濑康一
     用户身份	对日期和DDL不敏感的同学
     用户动机	希望能有一款产品时刻查看、提醒自己作业DDL，且无需手动导入
     用户困难	课程中心没有手机相关的适配，且电脑端访问课程中心比较麻烦
     典型场景	通过手机端直接收到了作业DDL的截止信息，立马投入工作

   • 场景测试：广濑康一

     • 需求分析：广濑康一是一名经常忘记DDL的学生，在疫情期间，所有的作业都通过课程中心发布，他经常担心自己有没有漏交作业或者忘记作业。而课程中心外网访问非常慢，还要在许多课程中一一切换，他很不愿意每次都上课程中心。
     • 使用场景：广濑康一打开了航胥APP，轻点两下，就看到了课程中心的所有DDL信息，而且，还和校历结合了起来，让他能够更加清晰的看到自己的DDL分布情况。

3. 你是否有回归测试确保新功能的加入没有影响已有功能？请给出一到两个测试用例并解释。

   典型的回归测试用例有如下几个例子：

   • 加入了课程评价功能，会使用学生选课的课表信息。在加入这些功能之后，学生课表没有受到影响，且可以通过对应关系，直接从课表页面跳转到评价页面。
   • 加入了DDL提醒功能和校历功能，会使用学生的DDL信息，加入之后，学生可以在校历页面看到自己的DDL，且原有功能不受影响。

4. 给出你的测试矩阵（test matrix），也即在什么样的平台、硬件配置、浏览器类型……上对你的软件进行测试？

   • 测试覆盖率

     前端测试主要依赖邀请身边的同学进行测试来进行，后端使用了单元测试，总覆盖率达到了88%。

     

   • 测试矩阵

     我们使用了几台主流的安卓机型进行测试，测试矩阵如下。

   测试机型	Android版本号	登录功能	Alpha版本各项功能	校历功能	空教室查询功能	课程评价搜索功能	课程评价功能
   小米 Max 2	7.1.1	正常	正常	正常	正常	正常	正常
   小米 8	8.1.0	正常	正常	正常	正常	正常	正常
   红米 K20 Pro	10	正常	正常	正常	正常	正常	正常
   OPPO R11 Plus	7.1.1	正常	正常	正常	正常	正常	正常
   魅族 16th	8.1.0	正常	正常	正常	正常	正常	正常
   华为 Honor 9	9	正常	正常	正常	正常	正常	正常

   • 压力测试

     在我们的服务器中，大多数操作为并行转串行操作，通过维护消息队列使得任务有序进行。这样虽然使得课表信息获取较慢，但是起到了维护服务器稳定的作用。

     我们此处主要对前端同时登录的用户数进行了压力测试，结果如下：

   同时登陆用户数	服务器状态
   6	正常
   10	偶尔出现连不上教务
   15	稳定出现一两个连不上教务

   此处出现的连不上教务的情况，我们判断可能是服务器的出口带宽已经到达限制，也有可能是给了教务服务器过大的压力，但考虑到总用户数只有百人级别，所以并没有很大的影响。这部分登录失败的同学会收到正常的错误提示，只需错开登录高峰期，即可成功登陆。

5. 你的软件Beta版本的出口条件（exit criteria）是什么？也即在什么条件下，认定你的软件已经足够好，可以发布Beta版本？

   • 兼容性：对于几乎所有Android机型和主流版本都能够实现兼容。

     我们的产品目前已针对竖屏分辨率进行了适配，在竖屏机器上使用时不会产生显示问题。兼容性方面可以认为已经达到了出口标准。

   • 易用性：按钮功能明确，功能入口醒目，弹窗提示易懂。

     目前我们的功能比较简单，对每个功能也有较为清楚的文字说明。在出现可能让用户迷惑的现象时，我们也有响应的文字进行说明，没有误导性按钮和操作，可以认为达到了出口标准。

   • 稳定性：所有功能都能正常运行，进行常规操作时几乎不出现运行时Bug。

     在我们对机型的大量测试中，闪退和崩溃的问题没有出现，测试过程中出现的bug也一一修复。可以认为达到了出口标准。

   • 及时性：后端能及时更新学生的信息变化，并反馈给前端。

     学生的信息变化更新的及时性受制于服务器性能限制和教务平台的网络限制。我们没有办法做到非常及时，只能保证在一天之内能够更新所有同学的信息一次。这里可以认为达到了出口标准。