孟蕾--i至诚案例分析
| 这个作业属于哪个课程 | 至诚软工实践F班 |
|---|---|
| 这个作业要求在哪里 | 实践课：案例分析 |
| 这个作业的目标 | 熟悉软件测试流程，提高思辨、总结能力 |
| 学号 | 212106774 |
对象：i至诚
前言
作为至诚学子，i至诚在我们日常的学习生活中起到了重要的作用，为我们在校内办理生活业务等提供了许多便利，对于日常使用频率高的功能，其实并没有发现什么影响用户体验的地方。我觉得作为一个校园帮手来说，其实是一个十分合格的软件了，但是再好的软件也无法避免有bug，所以我抱着鸡蛋中挑骨头的想法，对i至诚进行如下的测评分析。Part1. Bug
基本情况- 测试环境
- 操作系统：Android
- 测试版本：版本号2.1.1
- 可复现性
- 测试次数：5
- Bug产生次数：5
Bug① 奇奇怪怪的页面跳转
首先是我觉得在测试过程中发现的，对用户体验感影响最大的，就是页面跳转功能的bug。
1.情况描述
当打开某个功能页下面的子页面，再返回时，软件并不是逐层返回上一个页面到首页，而是在功能页，上次打开的页面，之间反复跳转，当遍历了一遍你在这个功能页打开过的所有子页面后，才返回到首页。
例如：从下图的功能列表页面中打开某个功能
打开顺序为：软件首页 → 一卡通功能列表页 → a功能页 → 返回一卡通功能页 → b功能页 → 一卡通功能列表页
如此使用了一卡通功能页内的两个功能后，又返回了一卡通功能页，现在如果点击返回按钮的话，正常情况下，应该是直接返回到软件首页，但是Bug就在这里出现了。
返回顺序为（此操作只点击了软件左上角返回按钮）：一卡通功能列表页 → b功能页 → 一卡通功能列表页 → a功能页 → 一卡通功能列表页 → 软件首页
且下图中，左上角白色的返回按钮不起作用。
2.Bug分析
- 可能成因：返回按钮设置的是返回上一浏览页面，所以就根据你打开的顺序再一个一个重新访问回去，直到回到首页
- Bug严重等级（6颗满）：❤❤❤
- 系统功能：除跳转错误外，并未对系统功能有较大的影响
- 用户体验：用户体验感较差，不能快速返回首页，需多次操作
- 安全性：对安全性无明显影响
- 预期改进：对返回按钮做指定页面的跳转就可以了。
Bug② 只有表面功夫的功能模块
使用过i至诚的都知道，这个软件内有许许多多的功能，但是其实很多功能都只是放了一个按钮在那边，并没有真正可以实现的功能。或者是有一套完整的功能，但是并没有实际投入使用。
1.情况描述
下图中，更换头像的拍照功能是无法打开相机的
下图中，一卡通余额模块，和图书借阅模块没法跳转到详情页面，这里我不知道是本来的设计就是如此还是软件Bug，但是在我的理解里，如果点击可跳转到该模块的详情页面就更好了。
且未读邮件模块，打开是一个报错的空页面，如图所示：
下图中，打开校园社团模块，是一个只有框架的空模块。
下图中，日程模块既没有办法根据学生的班级信息自动生成课程表等日程信息，也没有办法自己添加日程信息，基本上就是一个没有用途的摆设模块。
如此的模块其实还有一些，我只挑选了一些最典型的模块进行展示。
2.Bug分析
- 可能成因：用户不太会使用这些功能，或有学习官网和微信公众号这些有同样功能，又高频使用的地方，所以就没有进行深入开发。
- Bug严重等级（6颗满）：❤❤❤
- 系统功能：只有外壳，无法实际使用
- 用户体验：对实际需要使用的人来说，体验感是比较差的。但是确实使用频率不算高，所以总体体验感只能算较差。
- 安全性：对安全性无明显影响
- 预期改进：许多功能在微信公众号和学校官网都可以实现，但是如果能统一在一个软件上就更加方便了，我觉得主要原因可能还是对软件宣传不到位，不是我这样特意来测评的话，基本上不知道会有这些功能，而且大家还是更习惯用原本的途径使用，建议将功能开发完善，并在日常学习工作中呼吁使用。
Bug③ 摸不到头脑的搜索功能
在事务功能页面内，搜索一串数字，历史搜索记录却显示从单个数字开始搜索，直到显示成一串数字。而且我输入的是申请事件的流水号，但是并没有搜索的结果，不太清楚这里的搜索功能具体是如何判定的。
2.Bug分析
- 可能成因：想要在客户没有输入完整数字的时候就搜索到相应的内容，所以在每输入一个数字的时候就进行自动搜索，但是忘记从历史记录中清除自动搜索的内容。
- Bug严重等级（6颗满）：❤❤
- 系统功能：除了搜索功能的反馈有些让人摸不到头脑外，基本能实现其他功能
- 用户体验：其实是一个提升用户体验感的设计，只是没有把历史搜索记录保留的内容设计好
- 安全性：对安全性无明显影响
- 预期改进：在历史记录中，只保留用户自己从键盘输入后点击搜索按钮的搜索内容，不保留自动搜索的内容。
Bug④ 一些小小的不太影响使用的bug
除了以上所写的比较明显的bug外，其实i至诚中还有一些小小的bug，并不影响使用，是我无意中发现的。
1.情况描述
下图中，公告观看的次数增加时，外面公告缩略部分的观看次数不会增加。
2.Bug分析
- 可能成因：只在每次重新打开软件时才刷新观看的次数
- Bug严重等级（6颗满）：❤
- 系统功能：没有明显影响
- 用户体验：很少会注意到这个部分，所以没什么影响用户体验之说
- 安全性：对安全性无明显影响
- 预期改进：将刷新次数的时间设置在用户每次点击页面时
Part2. 功能分析
1.项目评估
估计需要26周左右，具体分析如下：
| 任务 | 时间 |
|---|---|
| 需求分析 、调研 | 3周 |
| 概要设计 | 1周 |
| 详细设计 | 2周 |
| UI、原型设计 | 2周 |
| 设计复查 | 1周 |
| 软件编码 | 12周 |
| 软件测试 | 2周 |
| 修改编码 | 2周 |
| 总结、交付 | 1周 |
2.优劣势分析
优势：
①操作方便：单独的app，无需借助微信平台，更方便操作。
②结构明了：功能模块的分类更加清晰。
③美观性：更能体现本校的风格，比起公众号来说，外观也可以设计的更加美观。
④时效性：app可以设置通知提醒，比起公众号来说，可以更快的获取到最新的信息。
劣势：
①缺少关键功能：缺少课程表、成绩查询、选课等学生经常使用的关键功能。
②卡顿：用户流量较大时，会出现明显的卡顿，或白屏等情况。
总而言之，虽然其他方面做得较好，但是缺少许多使用频率高的关键功能，基于此，还是教务助手的实用性更高，如果能在App中加入教务助手的功能就再好不过了。
Part3. 建议和规划
1.市场现状
-
目前市场上是否有其他类似功能的产品、竞品？
- 基本上每个高校都会有一个属于自己的校园帮手app，每个产品实现的功能都是类似的。如：福州大学的“福大助手APP”、福建师范大学的“福StarAPP” 、福建农林大学的“iFAFU APP”，“金山通”等等。
-
上述产品之间呈现什么样的关系，哪些为竞品关系？以及竞争中的各方态势如何？
- 福建农林大学的两款软件互为竞品关系，“iFAFU APP”是全校师生共同使用的而“金山通”主要为金山院区的学生提供服务。总体来说还是“iFAFU APP”的功能较为全面，所以使用的用户也更多。
2.市场与产品生态
- 产品的用户群体之间是否存在一定的关系？是否有利用其相互作用二次构成特定用户生态的可能性？
- 产品用户都为师生，已经形成了校内的用户生态。
- 产品的子产品，以及其他相关产品之间是否存在一定的关系？是否有利用各个产品特性之间的相互关系二次构成产品生态的可能性？
- 产品用户局限于一个校区内，彼此之间除了功能类似外，无太大的联系。对于校内的产品来说，可开发一些有与教务无关，但与生活服务有关的功能的产品，实现校内产品生态。但是与外校产品之间，很难构成某种产品生态。
3.产品规划
- 如果你是项目经理，可以招聘6个人，并且有4个月的时间，你认为应该如何配置角色(开发，测试，美工等等) 才能在第16周如期发布软件的改进版本，并取得预想中的成绩。
- 项目经理：负责调研，需求分析，协调沟通、总体规划等。
- 一名美工：负责完成UI设计
- 三名开发人员：负责代码的编写
- 一名测试人员：负责软件的测试
- 一名文档编写：负责阶段文档的编写
- 请为你的团队设计16个周期每周的详细规划。
| 时间 | 任务 |
|---|---|
| 第1周 | 调研、需求分析、需求复审 |
| 第2周 | 产品概要设计、原型设计、编写软件规格需求说明书 |
| 第3周 | 设计复查、修改 |
| 第4周 | 搭建开发环境，确定编码规范、软件体系结构设计 |
| 第5-8周 | 分模块编码、模块测试 |
| 第9周 | 第一阶段测试、根据测试结果修改模块功能设计文档 |
| 第10-12周 | 修改模块功能、完成第二阶段编码 |
| 第13周 | 准备小范围内测、收集用户反馈 |
| 第14周 | 修改内测中产生的bug |
| 第15周 | 完成各项文档 |
| 第16周 | 发布软件 |
