我们采访了使用“问码”社区的两名用户，他们对我们的社区提出了一些看法与建议，对于这些评价归纳如下：

1.     “问码”社区界面简洁自然，清晰明朗，能够很快知道网站有哪一些功能以及如何去使用这些功能。与国内一些比较有名的程序员社区相比，例如csdn，“问码”让用户更容易找到所需要的信息，查找也更加方便。但是有一些细节比较粗糙，例如标签框比较简陋，还有问题首页显示的用户信息比较容易让人产生误解。界面的美观程度可以再改善，因为没有让人有深入了解这个社区的热情。

2.    “问码”借鉴维基百科的可编辑内容这一功能特点，是一大特色。国内很多程序员社区，答案质量参差不齐，并且有很多重复的内容。可编辑问题与答案，可以在一定程度上减少信息冗余度，提高问题与答案的质量。不过要考虑用户观点与知识水平不同，可能造成的好的帖子被修改或删除的危险。

3.    “问码”社区给人初始印象是一个小的网站。而且社区刚发布时内容很少，当社区不能满足用户的需要时，用户找不到所需要的问题的答案时，很可能会放弃使用这个社区。

4.    问题与答案编辑框不容易上手，无法很快知道应该如何正确使用。

5.    建议增加最佳问题和最佳用户的排行榜，以此来增加用户的热情。

 

总结：

“问码”社区的一个主要目的是为了让用户能够快速方便的找到所需要的信息，因此设计页面时，是以简洁清晰的风格，让用户对社区首页的信息一目了然。他们戏称道：“CSDN虽然看起来乱，但是至少让人感觉有东西，你们的网站风格这么简洁，很容易让人觉得里边什么都没有”。这是一句大实话，不过多少让我们啼笑皆非，我们的网页长期以来的风格都是花花绿绿塞满了内容，飘来飘去的全是各类闪闪发光让人一不小心就误点的小广告。广大网民虽然对此深恶痛绝但是竟然在不知不觉中也习惯了这种风格。

     对最佳用户/问题设立一个排行榜看来是一个有效而且非常简单的鼓励机制。这样一方面可以让别人快速找到优质的信息，同时也可以起到鼓励的作用。我们很愿意在下一版加入这一功能。

很多人第一次听说我们的社区可以自由编辑问题都很惊讶，他们的担心是合理的。不过我还是愿意重申一下维基百科的一些哲学(原文请见这里)：

• “最正确的”文档只要有一份就够了
• “最正确的”文档应该放在一起才更有意义
• “最正确的”文档往往需要一个以上的人或者甚至一个以上的团队才可能完成

这就是为什么我们一方面采用各种机制避免重复问题的产生，另一方面采用协作的方式进行问题的维护。尽管投票机制能够让我们鼓励最优秀的帖子浮上来，但是“最佳答案”往往也不是最佳的，如果能够进行修改的话就有机会能让“最佳答案”更佳。

不过两名采访者仍提出了修改者可能因为个人一些主观感受而错误的编辑或删除了一些在别的用户严重有价值的文章。这个建议很好，我们希望能够增加一个版本记录工具记录问题的每一版修改，可以对历史版本进行回滚，这样大家都有机会对做出的修改进行评价,一些错误的修改就有机会被撤销了。我们将在下一版本加入这一功能。

问题与答案的编辑框是借鉴维基百科的编辑器，使用的方便度与其差别不大。熟悉维基百科编辑器的用户也会对“问码”社区的文本编辑器比较熟悉。

四名团队成员，两周多的公测，十几个bug，“问码”项目终于迎来了RC版。


在这一版本我们做了如下的改进

1. 重新改善了UI，使页面更加的友好
2. 修复了在IE8下的一些显示问题，比如页面不对齐，图片无法正常显示等问题。
3. 改善了分词器，这样在搜索，提示相关问题的时候能得到更精确的结果。
4. 能够直接在搜索框按回车进行搜索（之前只能通过点击“搜索”按钮进行搜索）
5. 修复了在某些情况下编辑器无法进行代码高亮的bug。
   

 

项目从在6月5号在校内发布Release Beta版本，公测至今，发现了一些的bug，这些bug有其他小组成员发现的，也有其他同学发现的，也有我们自己小组发现的，这些bug整理如下：

 

Bug	原因	解决方案
当“内容”没填写就提交时，一直停留在“正在提交中…”	在升级的时候，引入了一个潜在的bug（因为变量名更改）	修复
IE6下显示有问题	IE6对标准支持不太好； 网页方面的经验不足；	不准备修复，很多大网站都不支持了
没有找回密码功能	不在第一版的需求中	下一版增加
问题太长的时候（大约超过400字），出现异常	分词器出错	已经修正分词器越界错误。
首页的颜色白色占了很大一部分，长期看比较刺眼	在需求分析时，没有考虑到长时间看问题的情况没有考虑到用户的感官需求	重新设计UI，换成比较护眼的颜色
首页的“相关标签”有时候会越界	之前未考虑到太长的标签	修改
搜索的时候只能点“搜索”按钮，不能像一般搜索框一样直接点回车就进行搜索	Asp.net为每个输入控件注册了回车事件，而这段代码对我们是不透明的，所以之前没有做这个功能	搜索相关资料，修复此bug
问题和答案的“可信度”，在每次修改之后，没有重新计算。	在实现的时候被忽略了，在检查的时候也没有被发现。	修复
IE8 无法正常显示页面。	网页方面经验不足；不同浏览器的一些细节不同；测试时，IE8不是我们使用的测试浏览器之一。	修复

以上列出的bug几乎都已经修复，明天发布RC版本。敬请关注！

 

今天测试第四小组的应用程序，没有发现bug，不过似乎功能不全。

1.    无法管理自己的寝室成员。

2.    无法申请加为其他寝室成员。

今天测试，发现第四小组的5个bug，当前发现bug总数为29.
1.

Bug名称	找寝室联谊—点击学校或城市时没有翻译
测试目的	为了测试找寝室联谊相关功能是否正常
测试步骤	1.       找寝室联谊 2.      点击寝室旁边的学校或学校所在城市
期望输出	页面转到相关学校或城市的寝室
实际结果	页面没有反应
Bug描述	两个无效链接

2.

Bug名称	联谊活动—人数显示错误
测试目的	为了验证找新建联谊活动是否功能正常
测试步骤	1.      我的寝室 2.      查看联谊活动
期望输出	接受方人数应该是3
实际结果	接受方人数是1
Bug描述	新建联谊活动后与新建联谊活动时的应征人数不符

3.

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

昨天测试第四小组，没有发现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.      该阶段主要运用探索性测试，并且准备配置与部署，为发布做准备。同时计划下一个版本的工作。