UltraSoft - Beta - 测试报告

UltraSoft - Beta - 测试报告

1. 在测试过程中发现了多少Bug？有哪些是Beta阶段的新Bug？有哪些是Alpha阶段没有发现的Bug？

   很多Bug在开发阶段就已经经过测试了，我们在Beta阶段采用了Pull Request的协作方式，前后端完成新功能需要进行连接测试之后才会merge到主分支Master，所以在连接测试的过程中就可以发现Bug并修复解决，在完成的覆盖测试中并没有特别多的Bug出现。

   1. Beta阶段的Bug

      1. 在Beta阶段，我们增加了对后端数据库API调用的验证，如果请求中没有我们需要验证的数据则拒绝，所以在每个后端函数的开头加上了一个判断，然而在用户个人设置中，取出验证数据的方式有误，导致调用会出现 500 Internal Error 的错误，由于平时使用不多，没有发现，在覆盖测试中该bug才被揪出来。

         

   2. Alpha阶段没有发现的Bug

      在更新课程信息的爬虫中，在爬取个人课程ddl时使用了作业的url作为主键，然而在Beta开发阶段中发现存在同一个作业被创建了两次的情况——完成作业前和完成作业后，经过对比发现是课程中心的作业链接发生了变化：在完成作业前所有人是统一的链接，在完成作业后每个人的提交生成了一个submissionId被插入到了作业的url中，所以用url当作主键的情况下，完成作业前后的url不同，所以出现了两份作业的情况。

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

   场景测试又称为场景法，主要用于测试软件的业务过程或业务逻辑，场景法是一种基于软件业务的测试方法。测试人员在测试时要模拟用户在使用软件时的各种场景，大致模拟两类：

   1. 模拟用户正确的业务操作过程—验证的是功能是否正确
   2. 模拟用户错误的业务操作过程—验证的是程序的异常处理能力（健壮性）

   场景法主要测试软件的业务逻辑和业务流程。当拿到一个测试任务时，我们并不是先关注某个控件的细节测试（等价类+边界值，判定表等），而是先要关注功能的主要业务流程和主要功能是否正确实现，这就需要使用场景法。当业务流程和主要功能没有问题，我们再从等价类、边界值、判定表等方面对控件细节进行测试（先整体后细节）

   我们在开发过程中会对新增的需求进行测试，并不在最后的覆盖测试中进行，原因是场景测试所需要模拟的操作组合众多，堆积在一起测试会造成任务量的繁重，所以需要走一步测一步。

   在新功能的场景测试中，我们会对所有的可以点击的按钮进行组合点击（因为按钮少所以可以人力全覆盖），包括一些错误的业务操作，如填写日程之后点击关闭而不是取消，在个人信息修改界面修改密码之后没有确认保存直接退出等等。因为我们的大多数操作都是点击响应的，页面以静态页面为主，没有动态的内容，点击静态页面的按钮才会发送API请求，不设置前端的缓存，所以基本没有错误操作流程。

   我们提供的新功能有：

   1. 邮件提醒个性化设置：

      

      点击立即发送API，没有前端缓存，不存在错误的操作

   2. 如课程视图加入课程通知等：

      

      大多界面都是静态资源请求没有可以错误操作的按钮

   3. 设置重复提醒事项

      

      创建新日程前端不设置缓存，错误的操作如填写后点击取消会取消所有的已写内容。

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

   我们的Web应用一直投入使用，所以我们的回归测试一部分可以说是交给了用户来替代我们执行，用户的操作会在后台留下操作记录，如果有错误发生会进行记录，从结果来看运行良好，由于功能之间耦合低，大多都是独立功能，所以不会有新功能对原有功能的影响。至于测试用例的话，我们团队日常的使用就是测试用例，核心功能如创建日程，同步课程中心资源等，都是在我们使用后可以发现是否有错误的，比如我们就在使用过程中发现了创建重复日程的Bug并进行了修复。

   对于系统的覆盖测试，我们也有一套测试流程，测试结果如下：

   

   其中覆盖率低的有：

   • automail.py：0% 这是因为这不是后端调用的函数，而是定时发送邮件提醒的脚本，由Crontab每分钟自动执行。
   • webScrap.py：课程中心爬虫脚本，是由Views.py进行传入参数调用，不能自动化执行。
   • admin.py：这是Django后端数据库管理页面显示的页面，是面向开发者的界面，里面根据我们调试的需要增加了一些冗余的字段显示，对用户的使用完全没有影响。
   • apps.py：这个是Django的声明，未使用。
   • views.py：76% 其中存在部分未上线的功能，已经预留接口，所以未测试。

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

   测试使用的浏览器	字体字号 图片大小	日历显示	登陆界面 修改密码界面 注册界面	保存图片	添加任务界面	查看任务界面	个人信息修改页面	课程界面 (作业/资源/通知)	消息中心	用户反馈
   Microsoft Edge	正常	正常	正常	正常	正常	正常	正常	正常	正常	正常
   Google Chrome	正常	正常	正常	正常	正常	正常	正常	正常	正常	正常
   Firefox	正常	正常	正常	正常	正常	正常	正常	正常	正常	正常
   Safari	正常	正常	正常	正常	正常	正常	正常	正常	正常	正常

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

   1. 服务器运行正常
   2. 核心功能正常
   3. 新增功能对原有功能无影响