1· 在测试过程中总共发现了多少Bug？每个类别的Bug分别为多少个？
- a.修复的bug；
账单数据读取的错误，界面跳转时数据读取出现异常
- b.这个bug的确应该修复，但是没有时间在这个版本修复，延迟到下一个版本修复。
账单记录的金额没有和舍费进行同步；
舍费余额重新打开小程序时会清空；
修改账单暂未实现
2· 场景测试（scenario testing），包括以下内容：
- 你预期不同的用户会怎样使用你的软件？他们有什么需求和目标？你的软件提供的功能怎么组合起来满足他们的需要？
- 在校大学生甲一一是他们宿舍的宿舍长，他除了督促大家共同学习共同进步的同时，还负责记录宿舍的费用的管理。有些时候账目很是琐碎，在传统的纸质账本中总是有遗漏，并且宿舍成员们看到的账单也不是很细节。所以这时候他选择了我们宿舍费用管理小程序，从微信就一键登录，并且记录方式简单易操作，账单清晰明了，方便了一个宿舍所有的同学，宿舍费用管理过程中种种的小差错也可以完完全全避免。
3· 你们在什么样的平台、硬件配置、浏览器类型等条件上对你们的软件进行测试？——测试矩阵（test matrix）
4· 非功能测试
- 性能指标（响应时间和吞吐量，需要给出截图和测试实例以及结果）
- 系统资源监控（CPU、内存占用情况，需要给出截图和测试实例以及结果）
- 压力测试（不同并发用户数，需要给出截图和测试实例以及结果）
- 疲劳度测试（测试服务器持续运行的能力，需要给出截图和测试实例以及结果）
- 安全测试（从三个角度来看，即保密性、可用性、完整性。需要给出截图和测试实例以及结果）
| 序号 | 所完成的测试 | 系统所期望的性能指标 | 实际测试结果 | 差别分析 | 性能问题及其改进建议 |
|---|---|---|---|---|---|
| 001 | 性能指标 | 响应时间应为毫秒级别 | 初次渲染耗时：28ms | 测试结果与预期结果差别不大 | 实测结果符合预期指标 |
| 002 | 系统资源监控 | 由于是微信小程序，cpu、内存占用不能过高 | cpu:19%,内存293m | 测试结果比预期要坏不少，在较少功能和少量数据情况下的硬件资源消耗较大 | 代码设计结构和质量问题，在后续的开发升级中改进 |
| 003 | 压力测试 | 能实现多用户同时操作 | 由于本次版本是能实现单用户本地使用，还未能实现多用户并发使用 | ||
| 004 | 疲劳度测试 | 小程序应该能长期运行不崩溃 | 长时间运行情况良好 | 无 | 小程序的运行较为简单，并没有太大的疲劳度压力 |
| 005 | 安全测试 | 只有宿舍成员才能对账单进行修改，充值界面只有管理员(舍长)同意后才可更新 | 本次版本暂未实现安全功能 |
5· 你认为你们团队的软件在什么条件下，就可以认定其已经足够好，可以发布Alpha版本？——出口条件（exit criteria）
在当下，具体到管理宿舍流水的程序还是很少的，所以我们的小程序很多的市场空间。当然在记账功能能较为完美实现和响应的bug数量基本为0，用户调研体验良好，便具备了发布的条件。应当下潮流作为微信小程序，不占据手机内存，并且操作易上手、界面一目了然。程序本身贴合实际生活，为使用中带来极大的便利。
发布
1· 软件发布的同时，在团队博客上写一个发布说明
列出这一版本的功能（在原有项目基础上开发的列出新功能）
以原有项目为基础开发的，列出这一版本修复的缺陷
对运行环境的要求
安装方法
描述系统已知的问题和限制
说明软件的发布方式以及发布地址