(Alpha)Let's-版本测试报告

测试中发现的Bug

　　我们在测试之前发布了新的版本Version1.1

• 修复了上传图片画质问题的Bug
• 修复了搜索功能的部分Bug
• 增加了下拉刷新的功能
• 修复了部分界面跳转之间的问题
• 支持了部分低版本安卓系统

　　在测试中，我们发现了尚未解决的Bug，如下表：

场景测试

典型用户阿王和阿强的个人信息

场景测试1

1）典型用户：阿王

2）用户的需求/迫切需要解决的问题：

　　a）阿王想去健身房锻炼，但是卧推等动作需要有他人进行保护。

　　b）他不想雇私人教练，所以希望有个同伴一块去锻炼，两个人互相帮助，完成锻炼。

3）场景描述

　　a）阿王首先打开软件，点击“登陆”按钮，输入自己已经注册好的账号和密码，完成登录

　　b）进入到首页，然后他有两种选择：

　　　　i）下拉首页的活动列表，寻找其中是否存在符合自己要求的健身

　　　　ii）点击首页中部的“运动”图标，进入检索结果页面，显示运动类别的活动，寻找是否存在符合自己要求的健身活动

　　　　iii）点击首页上方的“搜索框”或者“放大镜”按钮，进入搜索输入界面，输入健身，点击“放大镜”按钮，在搜索结果中挑选自己喜欢的活动

　　c）找到自己想参加的活动后，点击该活动图片，进入到该活动信息页面，可以看到活动的详细信息，活动的发起人以及已经参加的用户。阿王觉得这个活动实在是很赞、很好、很符合自己的要求，然后立即点击了?按钮，看到“活动加入成功”的提示信息，并跳回主页面。

　　至此，阿王完成了在我们软件上的操作，等待健身活动那天的到来。

场景测试2

1）典型用户：阿强、阿文

2）用户的需求/迫切需要解决的问题：

　　a）阿强交际圈小，他希望能够在现实生活中多接触些女孩，找到自己的另一半，可是却没有扩展交际圈的途径。

　　b）阿文最近特别想打羽毛球，可是闺蜜都在和男朋友约会，于是她想在网上找一个人陪她一起打羽毛球。

3）场景描述

　　a）阿文在主页面，点击右下角的?，跳转到创建活动页面，首先她选择一张打羽毛球的图片，吸引其他羽毛球爱好者，然后她输入活动标题“好想打羽毛球啊”；活动时间“某日下午14时30分”；选择“运动”类型；点击“活动地点“，进入地图页面，搜索”北航羽毛球馆“，并点击确认结果，返回创建活动页面；在活动详情中输入活动的详细信息，最后点击右上角“发布“按钮，看到”活动发布成功！“的提示信息，完成发布活动。

　　b）阿强经朋友推荐，知道了”Lets“这个同好活动app，可以扩展交际圈。他从百度手机市场下载了app，他打开软件，点击“注册”按钮，进入注册页面；输入自己的手机号“130****7251”，并设置了自己的密码，点击“发送验证码”按钮，收到验证码短信，填入验证码，点击“注册按钮”，然后进入完善信息页面；他选择一张图片作为自己头像，输入自己的昵称、年龄和三个兴趣类别，点击完成，进入主页面。

　　c）阿强一个一个的浏览着活动，发现了阿文发起的“好想打羽毛球啊”这个活动，他很擅长打羽毛球，看时间地点都很合适，然后就参加了该活动。

场景测试3

1）典型用户：老刘

2）用户的需求/迫切需要解决的问题：

　　a）老刘忘记了自己参加的“寻同好一起去看移动迷宫2啦啦啦”活动的活动时间。

3）场景描述

　　a）老刘打开软件，登录自己的账号，在主页面向右滑，点击“参与的活动”的活动按钮，进入查询结果页面，寻找“寻同好一起去看移动迷宫2啦啦啦”活动，查看活动时间。

测试矩阵

Alpha版本的出口条件

　　首先，“好”是一个模糊的形容词，如何评价一个软件的好坏，我们很难找到一个明确的标准。更何况，不同的软件使用者，他们的用户需求与个人好恶存在着差异。同样一款软件，不同的用户关注的点可能会有所不同，在使用过程中的具体感受，都将会受到多方面因素的影响，这些因素很多并不由软件本身导致。

　　既然如此，我们的评价标准也自然很难有一个泾渭分明的出口条件，我们只能在立足于之前对于阿尔法版本的项目整体规划的基础上，结合自己实际开发中遇到的情况不断进行调整。并且，在实际开发过程中，随着DeadLine的逼近，我们必须要在功能的优先级之间进行取舍。软件的出口条件也就有了一个动态的变化过程。

　　就拿我们的项目为例，我们在后台基本功能大体上基本完成的情况下，开始将工作重心转移到了前台，着手美化已有的界面，加入一些较为美观的动态效果，使得原来静态的画面活动起来，之所以会做出这样的决定，完全是从用户的角度出发，界面的美观程度决定了用户对软件的第一印象，从社会心理学上讲，第一印象是主体首次认知客体而在脑中留下的感受，称之为首因效应，许多心理学实验已经证明了第一印象的重要性。

　　因而我们在基础功能基本完成的情况下，就将软件的出口条件定位为：界面的整体效果较为美观，具有一些动态的效果。

　　因此在接下来的几个工作日里，我们实现了侧边栏的加入，将搜索结果分类显示并且加入滑动转换的动效，并且将许多时间投入在按钮图标的设计上。

　　工作效果是令人鼓舞的，我们的软件整体美观程度上有了极大的提升，至少从视觉上取得了长足的进步。

　　即便如此我们还是不满足，我们还想要加入诸如下拉刷新这样的效果。然而，随着要求的发布截止日期日益临近，以及其他的几门课程的作业任务逼迫，我们工作的重中之重，就从写出一个拥有美观华丽外表的软件变成了写出一个没有功能性问题，稳定不会崩溃的软件。

　　于是我们就开始了艰辛的debug之旅，在对前端进行了颠覆性的修改后，与后台程序的耦合也会产生一些意想不到的问题，图片的加载出现了问题，百度地图接口的调用出现了问题，搜索结果的点击显示也有问题。一时间，许多问题涌现出来。

　　于是此时，我们的出口条件变得很简单：没有Bug。

　　经过大家的呕心沥血，通力合作，我们终于能够将绝大多数的bug修复，虽然软件还有很多能够提高改进的地方，我们对于许多功能还有期待。但我们的软件终于到达了它的出口：界面外观较为美观，程序功能基本稳定正确，或许这样的出口条件并不称得上苛刻，但在短短几周的时间里，这是我们大家经过团队合作得到的结果。

　　总结起来：我们的出口条件经过了一个动态变化的过程，做出改变的出发点很简单，就像木桶的短板效应，我们在各个阶段，都将解决当前版本软件中存在的最主要问题作为工作的中心，从用户的感受出发， 不断完善软件功能，修复软件漏洞，美化界面。以期找到一个现有条件限制下我们能够到达的，最优的出口。

(Alpha)Let's-版本测试报告

原文：http://www.cnblogs.com/Chronos/p/4966968.html