叶子坚--实践课：案例分析
| 这个作业属于哪个课程 | 至诚软工实践F班 |
|---|---|
| 这个作业要求在哪里 | 实践课：案例分析 |
| 这个作业的目标 | 从使用者和开发者两个角度对软件进行测试分析 |
| 学号 | 212106792 |
第一部分、找Bug
Bug发生时的测试环境
使用的操作系统环境和版本：HarmonyOS 2.0.0
i至诚APP版本：3.2.8.80430（202111081003）
Bug的量化标准
- 非常严重：极其影响用户体验，需要用户自身去对app妥协，每次使用都会受到影响
- 严重：影响用户体验，稍微需要用户去对app妥协，但使用次数不多或长时间下来稍微可以接受
- 一般：并不影响用户体验，对用户毫无影响
Bug的可复现性及具体复现步骤、Bug具体情况描述及其分析
（1）健康打卡：时间
可复现性：必然发生
具体复现步骤：打开健康打卡
具体情况描述：健康打卡的时间和全国通用的北京时间有数分钟差异，以至每日打卡需要用户自行调整时间
分析：可能是读取了服务器的本地时间，而服务器的时间并未矫正
严重性：非常严重，体验极差
（2）健康打卡：地区选择
可复现性：必然发生
具体复现步骤：打开健康打卡
具体情况描述：健康打卡的地区选择默认选中福建省福州市鼓楼区，但若要更改则在未切换省级选项时，需要自行输入
分析：应该是监听了用户的点击事件，而在初始化时，并未有点击操作，因此表现出用户选择所在市和所在县区时，只出现了默认值。若是重新选择省市，才会自动显示出所在省的市，所在市的县区列表
严重性：非常严重，体验极差
（3）首页：APP公告
可复现性：必然发生
具体复现步骤：打开首页
具体情况描述：首页中的APP公告列表中，用户点击查看，详情页的观看次数增加而首页的次数依然不变
分析：首页的内容应该是在获取数据后就不再发起请求，而后点进详情页面时，发起了更新请求，此时首页并未发起请求重新获取数据
严重性：一般，i至诚app并不是一个阅读app，也不需要对阅读数进行统计
（4）服务
可复现性：必然发生
具体复现步骤：打开服务
具体情况描述：服务中，分类杂乱，同时可以出现在多个分类
分析：服务的选项可能存在多个分类标识，但并没有一个优先显示的分类标识，因此查询数据库时会一并显示结果
严重性：一般，每个选项都能使用，只影响美观
（5）服务：校园一卡通
可复现性：必然发生
具体复现步骤：打开服务：校园一卡通
具体情况描述：进入界面后页面上方显示内容和服务页面中的按钮显示内容不一致，并且离线码是无用的
分析：离线码页面可能一开始存在，后面弃用；也可能是留待更新，而后搁置。并未进行后续处理
严重性：严重，用户通常并不使用该界面
（6）服务：返校申请
可复现性：必然发生
具体复现步骤：打开服务：返校申请
具体情况描述：没有反馈信息，用户在此页面时并不知道审核进度，可能会造成多次提交，且不知道若是辅导员通过返校申请的同时学生再次提交造成记录覆盖时是否能够通过审核
分析：该页面只是对服务器发起一次提交请求，并不查询是否已存在记录
严重性：一般，用户可能会多次提交请求，通常并不会造成什么影响
（7）日程
可复现性：必然发生
具体复现步骤：打开日程
具体情况描述：日程只相当于是日历，并且显示节次无效
分析：日程页面可能是用于占位，也可能是后续并未跟进处理
严重性：一般，用户并不使用app查看课表，更多使用微信公众号
（8）我的：系统设置
可复现性：必然发生
具体复现步骤：打开我的：系统设置
具体情况描述：只有一个退出登录却占据了整个页面
分析：系统设置页面可能是用于占位，也可能是后续并未跟进处理
严重性：一般，通常用户每天都需要健康打卡因而并不会去退出登录
（9）事务
可复现性：必然发生
具体复现步骤：打开事务
具体情况描述：事务的展现并不清晰，例如用户返校申请通过与否，需要点击事务——发起——已结束，且并没有展示全部的页面
分析：设计时并未理清逻辑
严重性：严重，大部分人甚至都不知道该页面是做什么的
第二部分、功能分析
1、根据软件已有的功能，评估其做到这个程度大约需要多少时间？
团队人数6-8人左右，计算机大学毕业/有app开发经历，会使用UI模板或公共库
| 开发阶段 | 时间 |
|---|---|
| 可行性研究阶段 | 2-3周 |
| 需求分析阶段 | 2周 |
| 软件设计阶段 | 3-4周 |
| 软件测试阶段 | 2周 |
| 软件交付阶段 | 1周 |
2、分析这个软件目前的优劣
- 优势：
1、功能相对于微信公众号至诚教务助手来说，功能更加丰富，提供了健康填报、出入校申请，以及新生开学的申请，如选宿舍，缴费等
2、i至诚是APP，因此界面设计更契合移动端 - 劣势：
1、i至诚本身的相关功能和微信公众号至诚教务助手相比，并不是那么的详细，存在部分功能缺失，还需要到公众号上使用
2、i至诚有许多功能只是用来展示的，是徒有其型的存在，并且因为APP的特性，进行维护更新更为麻烦，并且在各大应用商店平台中，提交审核和通过审核的时间长，难以及时更新，而有些功能又需要保持最版版本
3、从各方面的问题，推理出这个软件团队在软件工程方面可以提高的一个重要方面
这个团队在设计开发这款软件时，应该是脱离学生时期太长或者是没有在需求分析时，充分进行调研，造成许多功能未考虑到实际的使用情况，并且出现了许多不应该存在的bug。同时，从使用者角度上，该团队应该并没有详情的对该软件进行测试，许多功能是一次性就能发现的问题，然而并未对其进行修复。从开发者角度上，许多接口并未进行处理，使得部分学习过相关内容的同学可以直接获取大部分的数据，包括身份证，家庭地址等！
4、在第一部分发现的bug，为何软件团队不能在发布前修复？
有些bug可能是服务器问题导致的，例如压力上限和时间，相对而言不修复的问题应该是时间，成本，以及使用频率三者的问题，例如进出学校的功能，在疫情之前出入并不需要申请，这是一个临时功能，并且作为一个只面向教师和学生群体的软件，它并不需要高频率去更新，因此许多问题可能就此搁置而后被遗忘。
第三部分 建议和规划
1、市场现状
- 目前市场上是否有其他类似功能的产品、竞品？
几乎每个大学都存在类似的产品。 - 上述产品的定位、优势与劣势在哪里？
定位：方便师生，对老师而言能更好的管理学生，对学生而言可以更少的去麻烦老师。
优势：由于是学校的app，它并不会缺乏使用者，并且也确实在部分功能上方便了师生
劣势：功能并不完善，许多功能可以进一步简化，或者拓展 - 上述产品之间呈现什么样的关系，哪些为竞品关系？以及竞争中的各方态势如何？
并不存在竞争关系。每个产品都是为对应的学校师生量身定做的，并不会因为你使用了这个APP你就是这所学校的学生，更大可能是连注册都无法注册。
2、市场与产品生态
- 产品的用户群体之间是否存在一定的关系？是否有利用其相互作用二次构成特定用户生态的可能性？
使用该产品的人只可能是该学校的相关人员，如安保人员，教师，学生，以及校内人员。
不会，这类产品是依托于特定关系的，对其他人而言并不存在使用价值，或者微乎其微，例如观光等。 - 产品的子产品，以及其他相关产品之间是否存在一定的关系？是否有利用各个产品特性之间的相互关系二次构成产品生态的可能性？
都是依托于学校而衍生出来的产品，对于特定人群而言，这类产品越简单越好。
3、产品规划
- 你要在当前软件的基础上设计什么样的新功能？为何要做这个功能，而不是其他功能？为什么用户会用你的产品/功能？你的创新在哪里？可以用NABCD分析。
将微信公众号至诚教务助手的功能融入i至诚，以此完善它的功能，并在该方面上，进行提示，例如凌晨12点半登录i至诚，可以提示第二天早上是否有课等 - 如果你是项目经理，可以招聘6个人，并且有4个月的时间，你认为应该如何配置角色(开发，测试，美工等等) 才能在第16周如期发布软件的改进版本，并取得预想中的成绩。
美工2名，开发3名，测试1名
在开发初期，应该明确各类需求，并让开发者以此写出概念代码，同时由美工进行页面设计，测试者则尽可能罗列出各种通用情况的意外，提前告知开发人员以避免 - 请为你的团队设计16个周期每周的详细规划
| 开发阶段 | 时间 | 开发阶段 | 时间 |
|---|---|---|---|
| 可行性研究阶段 | 1周 | 程序编码 | 9周 |
| 需求分析阶段 | 2周 | 程序编码 | 10周 |
| 需求分析阶段 | 3周 | 程序编码 | 11周 |
| 软件UI设计 、通用bug罗列 | 4周 | 软件测试 | 12周 |
| 软件UI设计 、通用bug罗列 | 5周 | 软件测试 、bug修复 | 13周 |
| 软件设计 | 6周 | 软件测试 、bug修复 | 14周 |
| 程序编码 | 7周 | bug修复 | 15周 |
| 程序编码 | 8周 | 软件交付 | 16周 |
