昨天测试第四小组，没有发现bug，目前bug总数为：24.

今天测试第四小组，发现了2个bug，一个建议修改的。总bug数为：24个。

1. 建议修改：

Bug名称	管理我的寝室—修改寝室信息失败时，清除原来所有的信息
测试目的	为了验证修改的寝室信息不合法时的问题
测试步骤	1.       我的寝室，点击管理 2.      输入所有信息 3.    上传图片为txt 4. 修改失败，但是原来修改的信息全部恢复成未修改的消息
期望输出	修改失败，但是原来修改的信息还在
实际结果	修改失败，但是原来修改的信息全部恢复成未修改的消息
Bug描述	建议修改成期望输出

2.

Bug名称	新建联谊活动—上传错误logo时程序出错
测试目的	为了验证新建联谊活动功能是否正常
测试步骤	1.       新建联谊活动 2.       输入所有信息 3. 上传图片时，选择txt文件 4.    点击已上传
期望输出	提示上传的logo错误
实际结果	出现错误，参见下图
Bug描述	程序出错

 

Bug名称	找联谊活动—点击城市时出错
测试目的	为了验证找联谊活动功能是否正常
测试步骤	1.      找联谊活动 2.      点击活动名旁边的城市
期望输出	正常跳转到该城市的所有活动
实际结果	出现错误，参见下图
Bug描述	程序出错

今天没有发现第四小组的新的bug。发现bug数为0.
到目前为止，发现第四小组总的bug数为21.

 

“问码”公开测试至今，收集到一些反馈信息，整理如下：

用户体验：

1.    整体界面看起来很舒服，清晰明朗，不过可以再丰富一些，更专业一些。

2.    相关标签的提示框可以稍微修改一下，目前那些标签的排列是无序的……看着很不好看，最好改成

按字母表顺序排序

按关联问题的个数从多到少排列

3.    在IE下，有些标签不可见，需要选中才可见

Bug：

1.    当“内容”没填写就提交时，一直停留在“正在提交中…

2.    在回答的框框里面，输入答案，然后连续狂点“提交答案”，就可以提交很多个……

3.    在这个简要面上应该只显示文字，而不是显示设置的格式。

其他建议与意见：

1.    "标题"输入框失去焦点时,不管输入框内容有没有变化,就会触发与数据库的交互,.在交互前应该先判断下输入框内容是否变化

2.    要么别让非登陆用户可以查看用户个人信息了吧，感觉这样对注册用户的信息保护不够到位

3.    搜索出来的问题相关度比较小，建议对搜索出的内容的keyword要用不同颜色标识出来

4.    主页的右边，“欢迎”字眼底下有“开发博客”，容易引起误解，会让用户感觉到可以开发一个自己的博客。建议改成“我们的博客”。

 

总结：项目进展的主方向是在按时完成项目的前提下，完成满足需求文档中的功能和非功能需求，这也是出现一些问题的原因，比如搜索相关度不高。这一个阶段公开测试的反馈信息，我们将主要作出以下几方面的修改：

1.    提高搜索和提问问题的相关度。

2.    修改bug，对建议和提议进行有选择的修改。

 

2.

Bug名称	新建联谊活动—新建失败
测试目的	为了验证申请新建联谊活动功能是否正常
测试步骤	1.       最新新建联谊活动 2.       正确填写所有信息 3.    点击提交
期望输出	新建成功
实际结果	出现错误，参见下图
Bug描述

今天测出bug数：1

新建测试联谊活动

       输入正确的活动时间，正确的地点，可是提示“输入错误”

 

 

 

 

14. 主页面—找寝室联谊----选择5204—邀请联谊

       输入正确的活动时间，可是页面提示"日期错误"

 

 

15. 主页面--邀请好友参加—可是好友没有收到邀请

 

 

 

16. 主页面—找寝室联谊----选择5204—邀请联谊

       正确输入所有信息，可是无法创建联谊活动。

 

17. 我的寝室

       寝室介绍有的内容被遮盖，不美观。建议修改！

 

 

我们测试了第四小组的校内网的第三方应用，测试出如下bug：

1. 建立自己的寝室功能

       城市填写部分显示存在问题

 

2. 建立自己的寝室功能

       图片为txt文件的时候，无法创建成功，正确，可是同样没有错误提示……

 

3. 显示界面

       在成功建立完寝室，跳转之后，界面不美化，出现none

 

4. 寝室头像莫名消失

       在点击修改按钮后，修改任意属性，寝室头像消失。

 

5. 邀请联谊

       正确输入活动时间，提示日期错误

 

6. 邀请联谊

       正确点击选择城市，提示错误

 

7. 找联谊活动

       点击标题，错误链接页面，全部错误，无法正确打开  2009-6-11 15:14

 

8. 主页面-创建联谊活动-日期

       点击创建新联谊活动，正确输入日期，错误提示

 

 

9. 主页面-创建联谊活动-城市

       点击创建新联谊活动，正确点击输入城市，错误提示

 

10. 主页面-创建联谊活动-无法创建

       按照要求填写内容，点击新建，无法创建，提示错误。

参见截图：创建联谊失败-正确填写截图.bmp

 

11. <建议修改>讨论区--建议

       在输入评论之后，没有选择评分，系统自动提示请评分，但是清空了评论的内容，建议保留评论内容

 

 

 

经过四个多月的努力，“问码”项目终于发布啦。

“问码”程序员问答社区，用户可以在上面方便快速提问问题，回答问题，快速查找所需的程序员相关的知识。社区没有严格意义上的管理员身份。 通过积分运作，每个用户都有权限创建标签，进行对所有问题、回答的投票、编辑、关闭等操作。

    社区宗旨：用户就是管理员，好的社区需要大家的共同维护。

    从6月5号开始公测到现在已经收到一些反馈信息，在收集到一定的信息，并进行一定的更改后，预计在下周将软件做成开源。有兴趣的可以将该社区修改成其他主题的社区，而不一定是程序员社区。我们认为这一类型社区只要宣传运营得当，能够成为较高质量的社区，这也是我们开源的目的。

       以下是“问码”项目的地址，欢迎体验并提出建议，谢谢！

http://192.168.201.149:9090/askma/Community/index.aspx

 

ps：由于现阶段学校里发布，因此只能在校园网访问。只是用个人电脑当服务器，因此访问速度和访问人数会受到很大程度的限制。

刘凯 - 第八小组

这几年随着XP的流行越来越多的企业开始尝试XP所推荐的实践，比如测试驱动开发，结对编程等。相对于其他的实践，结对编程可能受到的质疑最多，很多人怀疑这种方式只是用双倍的人力去做原来一个人就能做的事情，而且两个程序员在一起会无法集中精神专注思考。

我一直以来也对结对编程非常好奇。结对编程听起来还是挺违反直觉的，但是Kent Beck在《探索极限编程》里对结对编程的描述又让我很想尝试。而且据说大名鼎鼎的JUnit就是Kent Beck有一次在飞机上和Ward Cunningham你一言我一语写出来的。

前几节邹老师给我们布置了一个结对编程解决泡泡问题的任务，我终于能够一睹传说中的“结对编程”了。

我是和冀托同学结对的。第一天（4.月28日）我们俩坐在小板凳上先讨论算法的设计。我们对着棋盘研究了一下，把各种想法写在了一个小本本上，把分治，动态规划，贪心法都想了个遍，但是似乎效果都特别不大好。

不知道是那位大牛说的：如果不确定用什么算法，就用蛮力法。这句话还是挺在理的，一方面很多时候我发现有时不太确定时可以通过蛮力法来理清思路，另一方面我们可以把蛮力法作为一个起点，先通过蛮力法解决小规模的问题来发现问题本身的一些模式，然后不断优化降低其复杂度。

而且在小棋盘测试时蛮力法至少可以给一个正确的结果，可以为别的算法提供评价基准。

那天晚上我们也提出了一个基于贪心的算法，这个算法虽然不一定能得到最优解，但是疑似可以的到较优解。

这个算法的思路很简单：

1. 给当前棋盘算分。算分规则就是给每个块算分，然后累加所有块的总分（比如有三个泡泡的块就是6分，4个泡泡的块就有12分）。

2. 然后找出能够给周围棋子加分最多的块(即新棋盘的总分+所消除块的分数)并消除之。

3. 重复步骤1，直到任意相邻的泡泡颜色均不同。

比如上面这幅图，如果将绿色那块消除，那么原来零散的三个黄色块和两个红色块就会连起来，可以看出，在消除绿色块之前

三个离散黄色块的总分为：3*2+2*1+2*1=10

两个离散红色块的总分为：4*3 + 1*0 = 12

而将绿色块消除之后：

黄色块的总分为：7*6 = 42

红色块的分数为：5*4 = 20

所以这个消除绿色块将会给棋盘带来额外的40分(42+20-10-12)

不过这种算法究竟实际效果如何？我们心中仍然觉得有些不靠谱。

在第二天的讨论中，一个“流氓”的想法浮现出来，与其挖空心思设计一些不那么靠谱的算法还不如用直接用随机算法算个一亿编遍然后取最优解呢。因为当时我想起了一个笑话，如果让一个猴子在打字机前敲足够久，那么它终将打出一部莎士比亚的剧本。

这个想法刚开始不过是戏语,不过仔细想想其中还是有一定道理的，这个道理我们用一个假说描述如下

冀托-刘凯假说：在泡泡游戏中，虽然其解集非常庞大，但是较优解的比例其实是比较高的（如下图所示）。回溯的问题在遍历了所有解，因而花费了大量的时间。

按照这个假说，所以只要我们随机求解一定次数，就有很大的概率得到最优解。

这个假说最大的挑战在于“较优解的比例其实是比较高的”，那么究竟较优解的比例有多高呢？如果是百万分之一以上这个算法就不靠谱了（但仍然比回溯好一些）……最好的办法是先用回溯法在小棋盘求出最优解，然后分别检查多次随机法和贪心法的效果。

虽然不知道随机法效果如何，但是其简单低耗无污染的特性吸引了我们，我们把原来的贪心法抛在一边，先实现随机法。

算法实现后出现了一个惊人的结果，在7*7的棋盘中我们花费了若干分钟得出了一个最优解，然而采用随机算法计算4000次以后几秒就得到了那个最优解，最为诡异的是，执行了几次都得到了最优解。

这个结果太振奋人心了，我们当时就寻思，这样的话贪心法是不是就可以丢了。

不过我们还是实现了贪心法，毕竟是随机法，如果不幸得了一个太低的低分似乎也不是不可能，所以我们决定用贪心算法来保底。贪心法效果也不错，比较接近最优解（这句话在邹老师改变规则以后就不适用了）

8*8以上的棋盘我们就没有再用回溯了（时间太长了），不过一般来说随机算法的运行结果总是要比贪心法高，看来我们的冀托-刘凯假说还是经得起考验的。

所以在最后我们将这两个算法并陈，贪心法用来保底（至少得分不会太可怜），随机法用来获取更高分。

当然整个算法设计过程也非一帆风顺，我们在中途发现了不少泡泡游戏的一些特性，也枪毙了不少方案，虽然有些心疼，但是我们至少知道了那些方案是不行的（爱迪生同学对此句亦有贡献）。

另外还碰到了一个问题，每次产生的随机数是泡泡的坐标还是“ 块”的编号呢？无疑产生随机坐标，会更简单一些，但是这样的话泡泡多的块被消除的概率会比其他块大得多。这样是不是就会退化成另一种贪心算法——每次挑块 最大的消除（根据我们玩泡泡的经验，得高分的手段之一就是把大的泡泡变得更大，挑最大的块消除之无疑是杀鸡取卵啊）。

不过这毕竟也是一个猜想，我们试了这个方案，结果发现产生结果的速度虽然快了，但是平均得分确低得多。就算给相同的时间求解原来的方案仍然要更甚一筹（10*10，平均高了300多分。）

和冀托同学一块编程真是件愉快的事情。在讨论过程中思考的过程 似乎非常流畅，通常是你一言我一语就形成了一个完整的想法。不过我倒以为解决算法问题并不是结对编程的最佳场景。这次结对编程我最喜欢的部分就是和冀托同 学讨论算法，我们花最多的时间也是在讨论算法上，真正抡起键盘敲代码的时间反而更少。为什么呢？因为如果完整的理解算法就贸然编程后果会很严重的。我原先 倒是像结对编程就是两个人一起讨论程序结构然后慢慢将代码重构得越来越漂亮。不过这可能是我的偏见，因为我对结对编程的第一印象就是Uncle Bob在《敏捷软件开发》中的“保龄球程序”，所以觉得只有长得像那样的结对编程才是结对编程。

好代码如好文章，都是需要改出来的。在写完程序之后我们也花了大量时间重构代码。觉得顺眼之后就高高兴兴的上传了（好吧我承认，前几天又看了一下代码，发现还有一些地方仍看不顺眼，就像隔了几个月看自己写得文章一样，一下子就能看出毛病在哪）。

结对编程，感觉还不赖！

Bubble break结对编程体验之二

 

成员：林育景，梁爽

 

    自从上次和梁爽进行讨论设计之后，我们又找了一个时间一起编程。上次讨论的结果是回朔法+优化。怎么优化呢？初始想到的是贪心法，我们能想到的贪心策略如下：

1)      在每一次消除中都是首先消除个数最多的泡泡。

2)      在每一次消除中都是首先消除个数最少的泡泡，将个数多的泡泡尽量留到最后。

3)      每一次消除都首先找消除后的棋盘的贡献最大的泡泡，也就是消除后得到的棋盘的所有可消除泡泡的总分最多。

可是，没有办法证明按照某一种贪心算法就能保证得到的分数就会比较高。与其如此，不如回朔法+随机算法，然后看看结果一般都分布在那个阶段，以此分数作为参照。

    回朔多少步数，再用随机算法？我们发现当回朔步数为4的时候，产生结果就要等一分钟以上。之前之所以选择回朔法再加随机法主要是为了尽可能的扩大结果的覆盖面，可是怎么保证一定步数的回朔就能有较优呢？一定步骤的回朔保证结果树的上层路径全部被覆盖，然而，这种覆盖是否就是比较好的呢？

    于是我们试着使用全部随机法，发现在同样的时间里，产生的结果居然不比回朔法+随机算法的结果差。

 

小结：

这次结对编程的最大体验是解决问题的过程中思路很多，因为两个人共同讨论过程中，解法能够相互补充。可能由于是第一次结对编程，效率不是很高。感觉结对编程对于人的要求比较高，不仅技术水平要高，更重要的是沟通交流能力要强，是否能够很快理解对方的想法，并且准确表达自己的想法是很重要的。

    关于程序，有一些看似可能的答案往往是不靠谱的，回顾我们的想法，从最初回朔法，到贪心法，再到回朔+随机法，我们的估计都是有偏差的，最后的结论是随机法比其他解法都更靠谱一些。

   

   

 

 

 

问码项目功能

功能序号	功能名称	功能说明
1	用户修改问题	用户修改问题的标题，内容，标签，系统则进行修改，而且记录相应的内容
2	用户修改答案	用户修改问题的答案，则系统记录最新答案，并且记录原来的答案
3	用户删除问题	具有一定权限的用户可以删除问题，当然连同答案也一起删除，系统会记录这个被删除的问题
4	用户删除答案	具有一定权限的用户可以删除答案，系统会记录被删除的答案
5	用户提问问题	用户须输入问题标题，内容，标签（可选），系统增加一个问题
6	用户回答问题	用户输入内容，提交即可
7	用户给问题评分	用户在问题旁边评分，只有加一分或减一分两种选择
8	显示相关问题	用户输入问题时，会在旁边自动显示相关的问题。
9	搜索问题	用户在搜索栏内输入关键字，即可搜到相关问题
10	选择感兴趣标签	用户选择一到多个感兴趣标签，系统将该标签的问题优先显示
11	选择不感兴趣标签	用户选择一到多个不感兴趣标签，则该标签的问题被过滤了，不显示。
12	按照问题得分高低查看问题	用户选择后，系统按照问题的得分从高到低显示
13	按照问题的提问日期查看问题	用户选择后，系统按照问题的提问的日期显示问题
14	按照活跃度查看问题	用户选择后，系统按照问题的查看次数显示问题

 

 

Persona表

	刘璁	陆田	罗伟铭	李存锐	牛未鹏
年龄	21	24	24	26	34
职业	学生	学生	学生	初级程序员	高级程序员
学历	本科	研究生	本科	本科	硕士
从网上搜索问题的频率	经常使用	经常使用	很少使用	经常使用	较常使用
最需要的功能	多标签查找，对问题排序	感兴趣标签，	搜索，相关问题匹配，各种检索方式	搜索，相关问题匹配，各种检索方式	1修改问题与答案
用户主要特点	要求问题的种类比较齐全	要求问题的答案会比较深入，能有高质量的问题与答案	路过问问，只想知道答案，不想参与讨论	只想快速找到答案，偶尔参与讨论	喜欢讨论技术问题，在网上有一定影响力

 

 

使用场景（刘璁）：在学习过程中，需要查询课程相关问题的答案，主要包括java， c#, c, c++, 数据库，操作系统等。希望能够有对问题的归类，以及对问题质量优劣的归类，以方便快速的找到想要的答案，并且方便提问问题。

 

使用场景（陆田）：在学习过程中，需要查询信息安全相关问题的答案，希望某个领域的问题比较全面，而且质量比较好。可以方便快速的查询到想要的答案，最主要的是问题的质量要高。

 

使用场景（罗伟铭）：很少有到社区去查找问题答案的习惯，只是偶尔使用社区。他希望在偶尔的查找中能够快速找到所需的信息。

 

使用场景（李存锐）：在工作过程中，需要查询各种网页的相关问题的答案，希望能够快速的找到自己所需的问题的答案，最主要的是速度。

 

使用场景（牛未鹏）：在C++社区颇有名声，较有影响力，有自己的博客，有自己的讨论组，热衷于与网友讨论各种技术话题。

感谢

感谢接受采访的同学，感受提供相关信息的朋友，在百忙之中仍抽出时间认真的考虑我们的问题，给予我们项目极大的帮助！！

 

 

测试计划
从下面这几方面进行：
一、用户界面测试
二、功能测试
三、性能测试
四、安全测试


一、用户界面测试
1. 页面(要求：测试所用分辨率下全部正确显示)
包括首页、二级页面、三级页面的页面在各种常用分辨率下有无错位;
图片上有没有错别字;
各连接是否是死连接;
各栏目图片与内容是否对应。
PS：
测试用电脑分辨率：    1280*800宽屏
                1280*768宽屏
                1024*768普通屏幕
                1680*1050宽屏
2. 整体界面测试(要求：70%参与的测试人员认可)
    请部分同学、和部分现在已经参加工作的同学来进行。当用户浏览我们的社区时是否感到舒适，是否凭直觉就知道要找的信息在什么地方?整个社区的设计风格是否一致?



二、功能测试
1、链接测试(要求：全部链接正确)
　　    1)遍历性地测试所有链接是否按指示的那样确实链接到了该链接的页面;
    2)测试所链接的页面是否存在;
    3)保证系统上不存在没有链接指向该页面。
2、表单测试(要求：表单提交信息正确)
    在用户注册和修改个人信息的时候进行
    在用户提交问题和修改问题的时候进行
    在用户对问题评分的时候进行
3、Cookies测试(要求：全部通过)
    测试Cookies是否起作用
    是否按预定的时间保存
    刷新对Cookies有什么影响
4、数据库测试(要求：基本读取和修改、写入正确)
    a. 这些请求转换成能够被数据库处理的格式，服务器端的数据转换功能生成SQL，对这个过程进行测试。然后存储进数据库，检测是否能够正确存储。
    b. 测试远程web页面获得数据库信息过程中是否出现数据通信的错误。


三、性能测试
1、连接速度测试
    Web Page Analyzer from Website Optimization
    一个很好的工具，它在分析完一个网页后，会为减少加载时间提出优化建议。
2、负载测试
    测试多个用户同时在线的时候系统的承受能力
    同时针对不同的页面进行并发测试，看多用户同时进行操作的时候会不会出现连接速度过慢或者其他异常情况。
3、压力测试
    在我们的网站发布以后，在实际的网络环境中进行测试。
    压力测试的区域包括表单、登陆和其他信息传输页面等。


四、安全测试
1.登录
    我们采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，对大小写敏感，两次成功登陆之间可以有10次错误的密码输入，如果超过限制，将冻结账户并以邮件的形式通知用户。用户登陆的时候要正确显示在这之间出现过多少次密码错误登陆记录。
2.Session
    系统有超时的限制，也就是说，用户登陆后在一定时间内(15分钟)没有点击任何页面，则需要重新登陆才能正常使用。
    不允许重复登陆，即一个用户已登陆，在未出现该用户的注销状态之前，不允许该用户的再次登陆。

上次老师布置得作业，bubble，让我们采取结对编程，之前我发过一篇日子，包括网络上对结对编程的一些问题等，这里我就稍微描述一下我们的结对编程过程，也可以说明一些问题。
布置作业后的周六，我们第一次碰面，晚上，在我宿舍，聊了一下关于bubble的想法。最先说的肯定就是遍历了，哈哈，包括破解别人密码什么的，不少都用暴力方法，我们也开玩笑采用暴力，哈哈。
后来讨论结果是 变化的贪心 和 随机。

考虑到实际情况，这么多点，随意点任意一块，消除之后面板会出现不少变化，这样就会出现需要重新计算的问题。计算的话，我们可以针对有所改变的部分，进行重新判断，可是考虑到我们消除的块的时候，随机性很高，很可能我们要消除的最大块或者我们打算消除小块而凑出来的大块的过程，是在右下角进行，这样还是导致基本要重新计算所有球球。

考虑变质贪心，是一种对速度的这种办法，首先消除比较大的块，大于4的，然后消除最后一行的块，是面板发生比较大的位置移动，然后再寻找大于4的块，这样做。不过这样大部分情况是做不出来最好效果的。

再者就是随机，随意点击，然后遍历一定得次数，这样拿到最高分的概率最高，而且速度还很不错。第一次就这么结束了，我们打算针对贪心和随机进行设计和code。

再一次还是在我宿舍，周二晚上，我们开始了贪心的实现。定义了一些结构体，我们一起讨论具体实现，最后用链表，做了两个结构体，一个用来表示某个点的所有信息和相关的flag，第二个结构体用来存储我们遍历得出的颜色块的结构。这样做了几条链表。

从周二到周四，我们碰了2次，然后周四晚上下课后，在我宿舍继续，11点左右终于搞出来了，能跑，能出数据，可是会爆一个堆栈错误……也奇怪了，他是在代码所有任务结束后报的这个堆栈错误，后来研究了一下，没解决……问了一下助教，助教说，虽然程序能出结果，不过最后弹出的这个对话框就稍微有点……， 同时，我们考虑到还有一个方案需要实现，这个就被搁置了。

因为5月2日晚上大家去一个fun run的的李宁组织的演唱会，所依我们5月1号晚上搞了一下第二个方案，大家都说结对的时候要有证据，所以这次我们找了宿舍的朋友帮忙拍了几张照片。呵呵。


对于随机的做法，我们使用数组来搞，使用两个数组来进行过程计算，图片上这天晚上我们就是先设计了一下框架，然后又花了一个晚上才搞出一个原型。

随机的效果是比贪心的那种要好很多，而且随机的速度也不慢，如果随机20000次的话，也就30秒左右，基本上就能出来一个很不错的效果了。

结对编程的过程中，出现过意见不合，解决了，因为是两个人，当面沟通还是比一个小组内沟通要好要快的多。

因为这学期课程压力很大，所以共同时间很难凑，所依我们大多数都使用晚上的时间来一起做。

做的过程中，发现技能互补是很实际的一个东西，一个人做的时候，很多东西都是记一个大概，有些可能都忘记了，两个人在一起，对部分不太熟悉的函数用起来就很快了，节省了不少时间。

结对编程，总的来说，是很不错的，不像小组那样，存在沟通问题，因为我上学期做了两个课程项目的小组长，所以知道组内人员沟通是个很困难也很现实存在的问题，两个人，更好沟通。

结对编程比一个人来也要好不少，毕竟旁边多了一个脑子，不是经常说 1 + 1 > 2 吗？这就是一个例子。

PS:
    关于结对编程的这两个我们体会最大的有点，也是我们两个总结出来的，哈哈，可能结对编程还存在第三个大优点，就是写文章比较快，呵呵。

项目小结与前瞻

                   

项目雏形初见，需求的功能已经基本完善，界面还需要再完善，前台和后台的交互还需要处理些许问题。

    到目前为止项目的进度与最初的里程碑计划基本一致，项目进展比较顺利。以下对后面的工作和阶段安排再列一个较为详细的清单:

序号	目标	时间
1	1)        项目alpha版本发布	5月5号之前
2	1)        收集alpha版本的用户反馈，整理分析，并且修改 2)        发布beta版本	5月6日 ~  5月14日
3	1)        收集alpha版本的用户反馈，整理分析，并且修改 2)        发布beta版本	5月15日 ~  5月21日
4	1)        最后验证所有功能，准备发布 2)        计划下一个版本的工作…	5月22日 ~  5月28日

其中，每一个阶段的工作如下：

1.      继续完善界面，以及前后台的交互。通过场景测试，集成测试，确保功能基本完善，稳定性比较高。

2.      小范围试运行系统，并且收集用户的反馈情况，对用户的反馈进行分类：bug，非功能要求，功能要求…。确定需要修改与添加的功能，并且需要消除的bug。该阶段的测试方案除了场景测试，集成测试，还有回归测试以及bug bash。

3.      小范围发布修正后的版本，同样收集用户的反馈，修正后，运用回归测试，同时注重效能测试。

4.      该阶段主要运用探索性测试，并且准备配置与部署，为发布做准备。同时计划下一个版本的工作。

 

   

 

 

    这次老师留了一个结对编程的作业，以前只是听过，但是自己从来没用过，所以先上网搜索了一些资料，看了一下结对编程

这种模式的特殊之处，在一个地方发现了一些网友对它的有点的评述：
　　1、直接的、连续的代码回顾。
　　2、与别人工作会增加责任和纪律性。
　　3、同时理解一个问题。
　　4、在有人盯着的时候去偷懒要困难得多！
    　两个程序员具有相同的缺点和盲点的可能性很小，所以我们当我们采用结对编程的时候会获得一个强大的解决方案。而这

个解决方案恰恰是其它软件工程方法学中所没有的。
    我干嘛要把辛辛苦苦很多年积累的经验白白告诉别人?
    这是网络上一个论坛里面关于结对编程讨论中一个人提出的问题，可能很多人都有这种想法，可是如果你将你的经验拿出来一起分享，获得的肯定是对方同样的回馈，不同的人有不同的天赋，你不可能是全才，肯定需要别人的合作。而优良的合作基础，就我个人看来，就是共同的、无遮掩的分享。
    结对编程是 XP 实践中最具争议的一个. 反对它的开发者不在少数, 但更大的阻力来自老板的本能反对。可能老板们都是表面的以为这是对人力资源的一种浪费吧？这次我们分别和别的小组成员结对，和我结对的张翔同学以前也没有结对编程的经验，大家正在一起
边学习这种模式，边通过老师给的bubble程序体验结对编程的特色之处。

        关于我和张翔同学结对编程的具体情况过几日会把我们结对编程的详细过程、体验以及最终我们两个人的收获继续在小组博客上发布。到时候也会包括一些对网络上看到的网友提出的一些关于结对编程的部分疑问的解答。敬请期待。哈哈
 

Bubble breaker 结对编程 之一

林育景

上周四布置了一道程序设计题，题目大意是，给定泡泡游戏棋盘，游戏规则是把泡泡都打破，并且争取得到最高分。玩过Bubble breaker的应该都很熟悉这个游戏规则。这道题目要求两人一组，结对编程使游戏尽量得到最高分。

由于这个程序的一个主要难点在于找到合适的算法，使得时间复杂度和空间复杂度在允许的范围之内，并且尽量得到最高分。寻找这一个算法的过程需要进行一定的深入研究，在这种情况下，一个人独立钻研一段时间是必要的。从这一点来看，在我们对问题尚未有一定认识之前，是不适合结对编程的，刚好梁爽在校外实习，不住校内，因此我们决定在第一阶段主要先通过QQ交流，在第一阶段主要是共同寻找适合的算法。

课后，与梁爽约定先了解一下如何结对编程，并且先各自大致思考一下，对于问题有更深一些的了解，经过两次的共同探讨，已经大致确定了算法，以下是结对编程的过程。

 

结对伙伴： 梁爽

时间：     4月28日晚22：00~23：00， 4月29日上午 11：00~ 13：00

交流方式： 由于梁爽在校外实习，不住校内，并且设计阶段可以远程交流，因此这一阶段的交流是通过QQ。

交流过程：

经过几天的学习，对于结对编程都有了一定的了解，并且对于问题的认识也更深了。4月18日晚，我和梁爽一起讨论，梁爽提出用贪心算法和搜索法。每次先选可以消得最多的，然后分析一下他周围的泡泡分布情况，如果削去它不利于周围泡泡下面的消除，就寻找泡泡数第二多的，依次这样下去。

梁爽 22:42:21

我的想法是这样的，每次先选可以消得最多的，然后分析一下他周围的泡泡分布情况，如果削去它不利于周围泡泡下面的消除，就寻找泡泡数第二多的，依次这样下去

我认为打破泡泡对于周围的泡泡是否有利，难以界定，而且具体的贪心算法难以确定和证明。

我初始想到的是回朔法，即全部遍历一遍，这种方法的时间复杂度是n！,如果棋盘很小时间还可以接受，而随着棋盘的增长，时间指数级上升。梁爽觉得这种方案不可行。于是我们商定再分别想想，隔天再商量。

    这个程序应该是无法用单纯的回朔法来解决的，因为如果有的话，第一，题目不会要求争取得到最高分，并且不会以得分高低来评判程序的等级。第二，如果有的话，这个游戏出现多年，相应的得到最高分的解法应该也可以在网上找到。尽管如此，我认为应该是在回朔法+优化来争取得到最高分。于是我先用初步尝试的写出回朔算法，并且在机器上运行。运行结果是当棋盘为6*6，速度还可以接受，可是当大于6*6时，等待时间就无法接受。

    4月29日，我和梁爽再次讨论，梁爽发现一个规律，即是每个竖排必须有这个颜色的球，并且这个球应该数目较四个颜色的球中要多，分布较紧密。逐渐以把这个颜色的球集中在一起为目的削去其他颜色的球，一直这个颜色的球能够最大数量的连在一起，一起消去。

梁爽 12:23:03

我先选好一种颜色，然后想办法削去其他颜色尽量使这个颜色的球尽可能多的连在一起。然后一次性削去，得到的分是最大的。

    然而这样仍然没有办法保证能够将相同颜色的球聚在一起。

对这两次的讨论总结如下：

1)      单纯回朔法时间复杂度n！，太高，不可行

2)      对于贪心法难以找到并且证明是比较好的贪心策略

3)      找一个颜色的球，并且将这一些球尽量聚在一起，从实现上也是不可行的，因为难以找到哪个颜色的球，通过什么步骤可以将其聚在一起是最好的。

最后，我们确定应该是在回朔法的基础上寻找优化方案，可以采用概率法+回朔法，并且再加上适当的剪枝法。

第一阶段主要通过讨论确定算法。接下来是第二阶段，第二阶段是结对程序设计，结对编写测试计划。

    虽然这个阶段还未开始一起设计与编程，而只是一起讨论。然而我稍微能感受到这种开发方法的好处。

1)   自己一个人想问题经常会有一些疏漏或者不完善的地方，甚至是完全错误。

2)  通过这样讨论，在表达自己的想法过程中，会反思自己的想法，渐渐的产生一些新的想法。讨论的过程会让自己对问题加深认识。

 

 

关于silverlight的一点疑问，这是课后想到的，关于JavaScript的

    上节课，两位微软来的工程师给我们讲解了silverlight和wpf两个技术，虽然只是概要地讲解了一下，不过还是了解了这两个技术的大致效果。
    记得其中一个工程师说他很喜欢zoom这个特色。上课的时候大家就提到了关于google map的实现问题。因为google map也是和他说的效果一样，开始是很快速地连接服务器，给用户一个比较模糊的图片，然后随着时间的流失，慢慢地将该模糊的图片用更加细致的图片慢慢覆盖。这个应用极大地提高了用户体验。和工程师们的讨论结果是，google map可能是用JavaScript做的。但就zoom这一点来说，我觉得不能说是微软silverlight的一个特色吧。同样的技术，在linux操作系统下面，adobe reader这个软件业实现了。adobe reader这个软件是大家经常使用的阅读电子书，尤其是pdf格式文件的工具。在linux下adobe reader 8里面，可以很明显地看到它的zoom效果。adobe reader里面有个放大功能，当我快速地点击它时，因为处理稍微慢一些，所依它开始给人的效果就是一个很模糊的图片，然后慢慢地变成更加清楚的文字。
    回宿舍后上了一下工程师给的那个人名联系的网站。效果的确很炫。silverlight在网页上面给我们带来了一个比较新的体验。可是JavaScript是不是也能实现那种效果呢？因为我对JavaScript方面学的不够深入，所以不知道具体是什么情况，但是当堂课的时候，工程师说，google map是以JavaScript实现的zoom效果，那是不是silverlight的其他功能都能用JavaScript来实现呢？希望某位老师或者比较懂的能够回答一下，我个人也会继续进行一定的搜索，希望能在以后的日志里面解答这个问题。
   

项目进展情况汇报

 

       自上周确定了需求与设计方案之后，项目又有了一些进展。社区的基本功能已经基本完善，包括用户模块、问题模块、标签相关模块，具体如下：

1. 用户模块
2. 用户可以自己添加问题和回答问题
3. 用户可以对问题和答案进行评分
4. 用户能够根据关键字搜索问题
5. 提问问题时相关问题的匹配

未完成的模块：

1. 问题查看方式
2. 按照标签进行过滤
3. 友好的界面

在实现后台功能的过程中没有遇到太大的问题，只有在设计数据库的时候小组成员之间有一些分歧。经过讨论，我们采用操作视图和存储过程而不直接操作基本表，这样保证数据库的变动几乎不会影响到上层的功能。

目前遇到的问题：

要做成一个高质量的程序员社区，有一个要点是界面要有良好的用户体验，而这部分是目前比较棘手的问题，我们还需要进行一定的调研，搜集分析具有良好评价的社区的优点，结合程序员社区的特点，在多个阶段的试用和反馈中逐渐完善。

第二个问题是良好的用户体验需要有较快的速度，目前我们后台功能都是直接操作数据库，如果数据量较少，速度是可以满足要求的，但是如果数据量稍大就无法速度应该就无法令用户满意。

 

总结上述分析，接下来要进行的工作是，继续完成未完成的功能，完善界面的设计。