last blog——期末评比作业
by banana.totolv
一、用户使用情况报告
1、都在哪里推广了你们的产品：
我们在紫荆1#楼由电机系学生会进行了推广，使用包括海报以及学生会内部推广等等手段。但是由于电机系学生会面临期末考试，不能在期末考试附近耗费大量人力试运行这一个网站，所以该网站虽然已经正式运营，但是暂时先不进行大量的推广。
因此，为了保证电机系的学弟们能够平安地度过期末考试，我们也无法按照老师的要求在水木bbs的新软版发布自己的软件。
但我们除了自己测试以外，还联系无77等兄弟班级的同学进行外部评测，有超过50人使用后给予了反馈。
这些反馈中绝大多数中肯地赞赏网站的简洁，当然也对大量尚需要改进的细节给出了建议。
2、有多少人下载，多少人使用：
显然下载量不是我们的指标，而至于使用量，由于网站没有正式运营，也无法统计。但是我们至少邀请了多于50人进行了简单的评测。由于我们的网站本来就是电机系学生会的项目，其主旨便是服务一个系的同学。所以我们认为评测充分，而且根据用户的反馈我们预期将会有相当多的同学使用我们的网站。
3、用户反馈如何：
用户反馈有长有短。长篇大论出自某些热爱评测的人之手，绝大多数用户都只是简单地在三言两语之中描绘出他们对该网站的初步印象以及意见。
User 1:
这个网站很具有实际意义。之前很多次想买水果吃，但是一直都不想出去，毕竟有的时候呆在寝室习惯了就不想出门。后来出现了水果吧，学生会负责统计我们需要水果的数量、日期等，这个时候我就开始每周找学生会负责的同学订购。并且每周学生会同学都会准时送给我们，这个让我感觉确实方便了很多。后来听说有了一个网站让我们进行内部的使用评测，估计后来会应用到我们订购水果上，因此我很高兴能够参加这次的评测，自己使用的结果如下：
首先我打开了网站，“天天吃水果”五个大字映入眼帘，加上一副水果的图画感觉挺亲切的，然后我打开了登录注册的页面，成功完成注册后我开始正常的水果订购了。
在订购页面，我看到了许多种水果，有苹果、梨、香蕉和西瓜等，每一种水果都有相应的图片和价格，我看了一下感觉价格很合理，就西瓜而言比市场价低一些，也许具体的价格在网站正式推广的时候会做一些调整吧。订购水果只需要改变后面的数量就可以了，即可以按上面的按钮进行增减，也可以自己输入相应的数量，在输入数量后后面的价格也自动变了，挺人性化的，能让我们及时发现订购了多少钱的水果。我选了3斤苹果和2斤香蕉以后拖动网页到了下面的地址信息，然后我填了自己的姓名、地址联系电话等，另外我发现这个居然可以自己选择开始送水果和最后送水果的时间，并且可以选择在周几送，这样在我有课的时候就可以选择不让他们送，感觉这样很方便。另外我也注意到了备注信息，由于总价是10.8元，自己没有零钱，所以在备注信息里面加入了“我只有100元，麻烦带零钱找我”。填完上面的信息进入了确认的网页，确认网页上我仔细看了自己需要的水果清单，确认完毕以后生成了一个自己的List，然后我可以查看和维护这个List，比如我想删除某一个订单的时候可以很轻松进行删除，在订单的管理上自己觉得这个网站做得还是比价不错的。最后没有看到付款的地方，估计这个应该是和水果吧结合起来然后进行货到付款吧。。。
在我使用了这个网页进行水果订购以后，我发现了下面几个优点和不足的地方，首先是优点。
- 网页的界面设计很不错，图片看上去很亲切，logo很赞，同时网页的颜色和布局都挺不错的；
- 注册环节很方便，同时我自己测了一下如果我注册过一个用户名，然后注册另外一个是不能成功的，看上去这点做的不错，注册也比较快，不会浪费太多的时间；
- 订购水果的时候很方便，上面基本囊括了平时所需要的所有水果种类，订购的时候感觉数量修改很方便，比较人性化；
- 选择送水果的日期和星期这个创意很好，这样我就可以在自己想取水果的时候让他们送了，这个和紫荆公寓送水的人对比起来好很多啊；
- 在管理自己的订单上比较不错，我可以很方便地删除订单，这样就可以避免自己填错以后不知道怎么办了；
- 网页容错性不错，自己小测了一下还没有发现有什么很大的问题。
下面是使用过程中决定可以改进的地方：
- 水果种类太固定了，如果还是用这样的设计方式，水果种类一旦变多那么网页就会显得很累赘；
- 选择送水果日期的时候，最好还能选择时间，比如我下午有课就不想下午送过来，这样应该好一点吧；
- 这个网站仅仅是做校内水果的销售，如果能推广到更多的销售就好了，比如一些事物啊或者其他什么日常需要的东西，有时候太懒而不想自己去买这类的，希望能扩展这个网站的范畴，不仅仅局限在卖水果上。
- 网站几乎全是英文的页面，个人感觉希望能改成中文版的吧。。。
User 2:
网页界面清晰明朗，有亲和力。对我们这样第一次上“水果吧”的人还是有一定吸引力的。对我们用户来说，网购的第一感觉往往很关键。
网站的水果种类很全，基本上囊括了时鲜的水果，据此选择和下订单也很方便。由于平时很少碰到以水果为主题的网购站点，“水果吧”给人印象不错，有眼前一亮的感觉。
建议：由于是第一次接触水果网购，我们最担心的还是水果的质量（是否新鲜）问题，而在“水果”吧上我们得不到更多的信息，希望水果信息能够更加透明（可以实时上传些水果的拍摄图片）。
User 3:
在上个月问卷调查的时候我就知道了有这个“水果吧”，今天来逛了一圈，谈谈自己的几点想法：
1) 面建议更丰富些，只是校内平台的话，内容还差强人意，如果要对外作推广，还需要更吸引人的网站内容。
2) 然的使用界面很适合我们这些宅男（O(∩_∩)O……），这点很喜欢。另外问一下是不是只有长期定制的方式呢？我希望能够尝试定制，有时还需要改变水果类型，这样可以吗？
网站上看不到你们开发团队的信息，希望能对你们的开发过程和成员有更多的了解。
User 4:
用了一下，流程简单，异常方便，赞！只是网站为什么一会儿中文，一会儿英文。
User 5:
用这个网站貌似的确可以天天吃水果，但是每天每种水果至少订一斤……有木有一个一个买的功能啊！有木有啊！
User 6:
方便是方便，就是粗糙了一点。至少也得给我们看一下每个水果的详细图片吧。那么小一个图片咋看得出这个水果好不好吃喃……
User 7:
一个页面就搞定所有的功能！太快捷了！
User 8:
这个网站要说订购水果本身这个任务还是能够完成的，也还算精简方便，就是外观配色上差了一点。而且水果就那么几种，感觉太单调了。如果能够提供更多的选择的话我还是会考虑长期用这个网站的。
User 9:
注册了一个账户，下了几个订单，过程还算流畅。只是看不到更多水果的照片以及水果的详情，感觉不是很放心，害怕网上的和实际的差距较大。另外修改订单太不方便，必须先把前一个删除，重新下订单。这一点有点不可理喻。
User 10:
用了一下网站，大体不错，细节待斟酌。感觉的确是一门课程作业的质量：）
User 11:
操作挺快捷的，下了几个订单，发现不能够对订单中的水果的状态进行跟踪，也不能看到它人对水果的评价，无法判断商品的质量。以后一定要加上这些功能啊！
User 12:
该网站出人意料地把购买水果的所有流程整合在了一个页面上，一目了然不需要跳转便可以完成购买水果的整个流程。注册、登录、购买、查询的设计都遵循着最简化的原则，使得整个网站的所有操作都意想不到地简单明了。虽然网站已见雏形，细节还非常值得推敲。
User 13:
下单是没有问题，只是很好奇要是送到我寝室的时候寝室没人怎么办？
4、用户使用情况和原来的估计有什么异同? 为什么?
我们认为用户可能会更多地抱怨网站的购物体验，但是意想不到的是用户对于网站购物体验基本满意，但是最为担心的是所购买水果的味道质量的保证以及水果送货等物流问题，这告诉我们网站本身的技术不是最大的难关，把这个水果网站运营好，重要的是建立起强大的货物渠道以及物流资源。
二、beta 阶段的postmortem 报告
1、每个成员在beta 阶段的实践和alpha 阶段有何改进?
Team Member 1:
1、 （时间安排）在alpha的团队中，不够积极主动抢着做简单的任务，而复杂的任务（苹果UI以及pdf详细解析）由于时间安排（那个时候还有pair project和individual project）多次没能在PM预期的时间中完成，最后充满挫败感，心灰意冷之际放弃Alpha项目。而在beta的团队中，我吸取教训，合理安排时间，提前认真学习简单的html，css，java script，diango以及dreamweaver，同时与PM及时沟通，汇报进度，最后在UI上能够为团队做出实实在在的贡献。
2、 （沟通交流）在alpha团队中，没能及时向PM反馈自己的意见，没能主动适应alpha团队中的氛围。在一个自己不喜欢的氛围里，我没有选择真诚地交流，而是选择了躲避，这也是alpha失败的原因之一。而Beta中，我尽量勇敢地说出自己心中的意见，在团队沟通上取得了良好的效果。
3、 （任务合理）在alpha团队中，自己总是在做一些自己觉得不靠谱的任务，而靠谱的任务自己又没有争取到，导致的结果就是自己在不能完成复杂任务的失落感与挫败感中挣扎不前。而在beta团队中，有一些超出自己能力范围又没有时间学习的任务，我和PM沟通之后选择了放弃，而集中精力快速完成了一些我能够简单上手但是又不那么trivial的任务，最后为团队做出了更大的贡献。
Team Member 2:
1、Beta版时对技术的掌握程度比alpha版时更加好，不像alpha版时的一头雾水。
2、Beta版时对自己的具体分工也更加地清楚。
3、UI部分使界面变的更漂亮。
4、除了开始的网页，还增加了其他的几个网页，使网站更加完善。
Team Member 3:
alpha阶段我参与了django前段的设计。在重新分配belta阶段的工作后，我负责渠道和外围调查的，工作包括照澜院、超市和水果摊的市价和销量调查，询问进货渠道，以及对（潜在）用户的网络问卷调查。而这方面的工作一直是有延续性的和时效性的，可以说从belta阶段开始后开始就一直在进行。
这方面的工作是简单而繁杂的，主要分三个方向，一是每周去照澜院、超市和水果摊，并询问摊主每种水果的销量和市价，以方面我们对此作出反应；二是和经管学院联系进货渠道，这方面我主要负责一部分联络工作；三是和一些认识或不认识的朋友进行一些简单的问卷调查，以总结用户的喜好和建议。工作难度不大，但颇有些工作量。
2、每个成员在beta 阶段的实践和alpha 阶段有何改进?
1、 放弃deadline driven的方式，而是合理安排好时间，提前动手。
2、 人员分工更加明确，通过切割网站的方式使得工作原子化，每个人都可以认真工作。而不像alpha的时候大量工作堆积在少数人手中使得工作安排较为模糊。
3、 沟通方式更加注重朴实刚健的语音以及当面交流，淡化了email等貌似现代的通讯手段在team communication中的作用。
4、对整个网站的设计情况要有清晰的了解，与底层要有充分的沟通，不要写出不符合整个工程的无用的代码。
3、12条敏捷开发原则中，团队做得最好和最不好的各列举两点
团队做得最好的两点：
6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
10: Simplicity--the art of maximizing the amount of work not done--is essential.
做得最不好的两点：
3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale
4: Business people and developers must work together daily throughout the project.
4、对照 The Cathedral and the Bazaar (大教堂和集市), 你的团队开发模式是哪一种, 优势/劣势在哪里?
我们的团队是cathedral模式，因为我们必须要从无到有搭起一个全新的网站，而Bazaar模式要去的成功的必要条件是至少要以一个可以运行的原程序作为起点在其基础上大家一起加工。
另外我们的工作模式是在每个人通过自己的终端通过putty连接到服务器进行工作，所以如果所有人都任意地修改同一份代码，网站本身难以成形，而且会出现访问权限的问题，这也是我们选择cathedral模式的另一个原因——每个人都在完成自己部分的部分工作之后交给特定两个同学进行修改。
优点显而易见，能够保证每时每刻总有一个成形的网站可以运行，而且不会突然被污染导致网站崩溃。
但缺点是每个人不能完全地领会整个网站的代码框架，所以在完成自己的一部分工作之后，整合到整个网站的工作会变得非常繁琐而且没有效率。
三、beta测试报告：
在beta 阶段的实践和alpha 阶段有何改进
bata版的测试基本沿用了alpha版本的目标，有一定的改进。改进的主要方面在测试手段和流程上，有了很大程度的提高。beta版的测试报告详见
http://www.cnblogs.com/banana-totolv/archive/2011/05/30/2062612.html
1. 测试目标
本项目的测试目标主要是网站GUI的正确性，我们需要用各种各样变化的输入来对页面的反馈进行监测。比如，登陆界面的测试主要集中在登录正确性以及注册的正确性，又比如，水果选购的页面的测试主要集中在订单确认的正确性。
组内的测试工作虽然由少数同学完成，但测试的目标都经过了PM和主要成员的认可，所以测试目标具有一定的针对性。
alpha版测试与beta版在目标上的区别是更加强调了GUI正确性。在alpha版中，我开始希望用test-driven的方式进行开发，但遇到很大的困难。一方面，自己不是作为主要开发人员，对django的代码并不熟练，无法写出很高效的测试程序，可能反而会增加其他人的负担。另一方面，在alpha的开发过程中，很多功能虽然一开始确定，但后来又经过了多次修正，所以没有办法得到一个完整的spec。起先我想自己写一个spec，但组员觉得固定的spec可能无法对实现难度有所把握，对于我们这些初级开发人员要求太高。比如，开始我觉得登录密码过于简单这个问题可以在alpha开发时作为一个spec，但其实这个问题到了beta版的时候才得以解决，原因如下。alpha版开发的最大难点之一是登录/注册程序，只有董沛同学对django这一块的内容比较熟悉，但这项任务开始时是由吕曰洲同学接手的，所以花了很长时间也没有完全解决，这个问题就一直拖了下去。
beta版较alpha版更强调GUI的另外一点主要原因是对于开发过程的更深入理解。一开始，我希望将课上所学的模块化测试应用到我们组的测试工作中，但在网站开发几个月之后，我发现我们网站程序很难产生明确的模块接口。比如，我们开始计划将网站的数据库，页面，以及逻辑完全分开，这也是django架构所支持的，但后来发现虽然这三者可以分开，但无法得到详细的接口。一方面，模块之间都是使用不同的语言，比如页面用的js，而逻辑用的python。另一方面，django虽然自带有模块之间的功能测试，但这样的测试需要各个模块的程序满足一定的需求，而这些需求很多是对于各个组员的额外要求，在时间不允许的情况下，我选择放弃这样的测试方法。
在beta版中，测试主要集中在了GUI正确性的优势有三点：首先我意识到我们网站的页面有着一贯清晰的接口，比如，水果的订单数量一贯是一个变量名。虽然这些变量的后台实现经常会发生变化，但由于变量不会变，所以自然而然地有了清晰的测试接口。这样一来，我不用约束同组同学遵守一定的spec，也可以保持我的测试程序不变，而且即使变量名发生了一定变化，我也可以很快修改测试程序。其次，GUI正确性有专业化的工具可以使用，比如HttpUnit，这样我也可以进行自动化测试（详见第二节）。最后，GUI是我们网站对于用户的唯一界面，也是管理员操作数据库的唯一接口，所以它的正确性非常重要。所以强调GUI的正确性符合我们网站的实际需求。
综上，测试目标在alpha版和beta版中虽然主要目标相同，更强调了GUI的测试，而弱化了test-driven的比例。
2. 自动化测试
自动化测试的最重要动机是希望能测试网站的流量承受能力，这一点是alpha中所不能做到的。虽然这一项测试最后没有得到什么结果，但自动化测试带来的好处却帮助了GUI测试取得了成功。
流量承受能力测试是为了防止发生DoS攻击，从网络安全的角度看，这时网站最重要的问题之一。在alpha版本的测试中，我主要进行了网站在各个用户环境下的使用情况。其方法是用各种浏览器，在各个操作系统和各个浏览器设置下进行测试。这种手动的测试方法显然无法满足流量攻击测试的要求。为此，我找了一些自动化的软件进行尝试，但将同时访问人数设到10000还是没有发生问题。后来在请教PM的时候，他说django框架可能已经防止了这些情况。因为django是一款通用的网站编写程序，所以肯定考虑了诸如防止DoS这样的通用需求。
虽然DoS的问题不需要测试，但我却发现了自动化测试的很重要好处之一：可以批量进行测试，并保存测试过程。
批量测试的重要性在于可以对某一功能的各个情况在很短时间内逐一进行验证。在测试中，我使用的HttpUnit，HttpUnit这是一个基于java的类包，可以模拟几乎所有浏览器的行为。同时HttpUnit的测试用的是java代码，所以可以用循环的方式对操作中的参数进行调整。比如，在以下代码中，用户名的参数用的循环生成，而密码则用的是随机数生成，这样可以批量十次测试登录这一功能在不同输入下的反应。而同样的测试如果人工进行需要手动输入10次，非常耗时。
for (int i = 0; i < 10; i++){
String username = i + "testnewcomer";
form.setParameter("username", username);
form.setParameter("email", username + "@gmail.com");
Random r = new Random();
String password = String.valueOf(r.nextInt(10000000)); //随机生成一个1-6位的数字密码
form.setParameter("password1", password);
form.setParameter("password2", password);
requestLogin = form.getRequest();
responseLogin = browser.getResponse(requestLogin);
System.out.println(responseLogin.getText());
}
保存测试结果的好处在于，如果测试的结果进行了一定改进可以立刻进行测试。这一点在有效密码测试中得到了一定的印证。首先，用测试程序发现某一接口有问题，其次，针对这个问题找出错误的根源，进行修正后，用同样的测试程序进行测试（见第4节）。
3. 生成测试样例
在上一部分中，我介绍了beta版测试最重要的自动化测试。我希望自动化测试可以找到GUI中的问题。这一步的关键是如何生成测试的样例。这也是beta版相对于alpha版的最重要改进之一。在alpha版中，有一个test matrix的测试计划，这其中包括各个变量和参数的可能取值，这些取值之间是分别独立的，所以需要测试的次数就是所有可能性的乘积。但在自动测试中，这样的目标显得太弱，很快就能实现，更好的目标应该是利用自动测试批量的特点生成尽量有代表性的参数和变量取值，用程序检查得到的结果。
拿水果选购功能测试为例。每种水果的选购数量和选购日期的取值都可以任意，这其中会发生的问题需要通过程序随机地选择可能的值进行组合验证。
for (int i = 1; i <= 10; i++){
numberList[i] = r.nextInt(5); //对每种水果，随机选购一定数量
form.setParameter("number" + i,
String.valueOf(numberList[i]));
price += uprice[i-1]*numberList[i]; //实际价格
System.out.println("number" + i + " is " + numberList[i]);
}
requestBuylist = form.getRequest();
responseBuylist = browser.getResponse(requestBuylist);
String totalPrice = responseBuylist.getTextBlocks()[11].getText();
String[] contents = totalPrice.split(" ");
double responsePrice = Double.valueOf(contents[contents.length-1]); //网站反馈价格
System.out.println("实际价格"+price+"，反馈价格"+responsePrice);
if (Math.abs(responsePrice-price) < 1){ //允许正负一元之间的误差
System.out.println("Pass!!");
passCount++;
}
4. 改进方案
针对测试结果进行改进也是beta版相对于alpha版的一个重要提高。alpha版本由于时间过于紧张，错过了进行改进的时间。在beta版中，测试的结果得以部分地被改进采纳。比如，过于简单的密码问题在5.29号的日志中已经被纠正。当用同样的测试程序（见第二节最后的程序）进行测试的时候，结果返回就是希望的结果。
改进方案的提出可以是由测试人员给出，也可以是开发人员自行给出。在我们网站的django架构下，最好的方式是由开发人员自行解决。因为代码并不分开，所以需要进行改进的部分可能同时在进行其他功能的开发。其实这也是我们组经常出现的问题，代码文件并不多，但是有很多人需要进行修改。所以这个时候测试人员如果直接提出代码修改的方法甚至自行修改，将会对其他开发人员的工作造成不必要的影响。
posted on 2011-06-16 23:27 banana.totolv 阅读(954) 评论(1) 编辑 收藏 举报
