# 在项目各个部分整合之后，本组成员作为测试人员对项目进行了测试，其具体过程与分析如下：
测试分类与分工
1. 功能测试
| 测试名称 | 测试内容 | 测试人员 |
| 单元测试 | 在最基本的功能/参数上验证程序的正确性 | 相应开发人员 |
| 功能测试 | 验证模块的功能 | 相应开发人员 |
| 集成测试 | 验证几个有依赖关系的模块的功能 | 相应开发人员 |
| 场景测试 | 验证几个模块能够完成一个用户场景 | 相应开发人员 |
| 系统测试 | 对整个系统功能的测试 | 相应开发人员 |
| Beta测试 | 外部软件测试人员在实际用户环境中对软件进行全面的测试 | 全组成员 |
注：在Alpha版本验收之后，新增或修改了某些部分，所以需要重新测试
2. 非功能测试
| 测试名称 | 测试内容 | 测试人员 |
| 压力测试 | 测试软件在负载情况下能否正常工作 | 全组成员 |
| 效能测试 | 测试软件的效能 | 全组成员 |
| 配置测试 | 测试软件在各种配置下能否正常工作 | 全组成员 |
| 易用性测试 | 测试软件是否好用 | 全组成员 |
| 安全性测试 | 测试软件是否具有一定的安全性 | 全组成员 |
结合本项目的实际情况，暂不进行可访问性测试、本地化/全球化测试以及兼容性测试（本项目基于Android）
测试方法
基于MSF敏捷模式，我们采用场景来规划测试工作。部分测试报告如下：
1. 管理员页面测试报告
| 场景ID | 场景名 | 测试结果 | Bug ID |
| 10001 | 管理员登陆 | 成功 | |
| 10002 | 通过手机号搜索用户 | 成功 | |
| 10003 | 添加新的用户信息 | 失败 | 20001 |
| …… | …… | …… | …… |
2. APP端测试报告
| 场景ID | 场景名 | 测试结果 | Bug ID |
| 30001 | 用户登陆 | 成功 | |
| 30002 | 用户注册 | 失败 | 40001 |
| 30003 | 用户修改昵称 | 成功 | |
| …… | …… | …… | …… |
注：每个Bug ID有对应的说明，例如bug 40001代表用户手机号不合法
测试准备
1. 制定测试计划
本项目的测试计划是基于需求文档制定的，分为：管理员页面测试计划与APP端测试计划。主要测试每个功能是否按照预期实现，尤其关注容易出Bug的地方，例如：用户手机号的记录。
2. 测试用例
测试用例是基于功能点编写的，包括如何操作以及预期结果。例如：输入手机号111应提示手机号不等于11位数，操作失败。
测试结果
测试之后的Bug数量远超我们的想像：管理员页面与APP端较为明显的Bug就分别有20多个。综合分析，原因有两点：
1. APP端的开发小组与管理员端的开发小组对接不好，很多东西没有沟通清楚，比如：用户密码在管理员端强制为6-12位，而在APP端域不同，对数据进行操作的时候就会产生异常；
2. 细节关注度低，可能是经验不足，开发人员在实现时只关注主要功能，忽略很多细节，比如：管理员页面通过新增用户插入的用户密码，与列表中显示的用户密码应该具有相同的约束。
分析总结
在进行测试的时候，如下两种方式让我们的测试效果很好：
1. 每个小组成员都对APP端和管理员端分别测试，这样相当于进行了5次不同程度的测试，再把整理后的测试结果发在群里，事实证明这种分工方法效率很高；
2. 测试人员在测试时尤其关注另一开发小组的功能点，比如：管理员端开发人员对APP端进行详细测试。因为开发人员很容易有定式思维。
# 测试过程，除了让我们对整个项目结构更加了解之外，还感受到了每个开发小组的工作量，还是挺感人的。
# 总之，经过测试、修改、再测试这样反复迭代的过程，本学期的项目工作就接近尾声了，最后就希望验收顺利！表面队加油 >_<