团队作业3——需求改进&系统设计
一、需求&原型改进
1、给目标用户展现原型，与目标用户进一步沟通理解需求。
我们的软件为实验报告查重，主要服务人群为是老师以及助教，帮助他们查看学生报告完成情况，减少工作量。
用户场景如下：
（1）、助教
|
名字 |
小张 |
|
性别 |
男 |
|
职业 |
某校计算机学院大三学生 |
|
物理知识层次与能力 |
计算机编程大神 |
|
生活情况 |
大三的课也非常多，还要处理学生们的报告作业等，忙啊！ |
|
动机 |
减少工作量 |
|
目的 |
希望能够帮助自己处理好实验报告 |
|
困难 |
学生报告较多，从好几份相似度差不多的报告中找出优秀的报告比较困难 |
|
用户偏好 |
简洁即可 |
|
用户比例 |
约占用户40% |
|
典型场景 |
登陆查重软件，查看重复率较低的报告，挑选优秀报告 |
（2）、教师
|
名字 |
何老师 |
|
性别 |
男 |
|
职业 |
某校计算机学院资深教师 |
|
物理知识层次与能力 |
对计算机知识了解非常深入 |
|
生活情况 |
带领学生做实验，检查实验报告，退回不合格实验报告，且平常还要上理论课 |
|
动机 |
希望能够剔除抄袭报告，从优秀的报告里看出学生存在的问题，并且不需要自己一个个手动下载报告 |
|
目的 |
剔除抄袭报告 |
|
困难 |
学生多报告也多，然而报告的相似度太高了，学生抄袭严重 |
|
用户偏好 |
操作简单 |
|
用户比例 |
约占用户60% |
|
典型场景 |
登陆查重软件，学生报告已经提交完毕了，查看重复率，剔除抄袭报告并打回重写，选出优秀报告查看学生存在问题 |
2、修改完善上周提交的需求规格说明书。
3、参考《构建之法》8.5节功能的定位和优先级，给出功能分析的四个象限。
杀手功能：学生可以上传文件，无须老师一个个手动加入文件，减少了很多麻烦；
外围功能：良好的界面设计，以网页形式呈现，给用户良好的使用感受；
必要需求：核心的计算重复率的功能，能够给老师直观的感受到学生的报告完成情况；
辅助需求：设置了学生和老师两个不同的权限用户，且老师可以打开学生报告查看。
4、任务分解WBS
a. 团队项目的WBS；
二、系统设计
我们小组的项目是报告查重系统，我们准备以网页版的形式来呈现，经过小组的商议，决定采用JSP来开发网站。
- 由于小组成员对Java语言掌握的会比较好，所以我们决定组内分工用Java 来完成报告查重部分的代码。
- 数据库我们准备用My sql来写，创建两个表，学生登陆系统和教师登陆系统，其属性有登陆账号和登陆密码。
三、Alpha任务分配计划
经过本周一的会议，我们小组总结了到目前为止，所完成的系统功能，以及接下来需要完成的任务，在此，我们小组使用Alpha任务分配计划：
第一步: 找出完成产品需要做的事情（Product Backlog, Backlog翻译成“积压的工作”,“待解决的问题”, “产品订单”都可以）
完成产品所需要做的事情：
1、对产品进行需求分析、原型设计并制作需求规格说明书
2、编码规范、平台环境搭建
3、编写并测试功能代码、美化界面、发布并调研总结
截止目前，我们已经在第7周，对我们的产品进行了详细的需求分析、原型设计以及代码规范，在初步制作了需求规格说明书的同时，我们也基本搭建了平台环境；本周，在老师的建议下，改进我们的需求分析和原型设计，取消了一对一、一对多、多对多等不明确查重功能，改为直接实现查重功能，同时完善了需求规格说明书。
第二步: 决定当前的冲刺需要解决的事情（Sprint Backlog）
就目前我们小组所需要解决的事情：实现查重系统功能----用户注册，用户登陆，文件修改，文件上传，文件浏览，文件储存方式，文件查重。
1、用户注册以及登陆：小组派出一人完成，编写相关代码，主要是与数据库进行相关联，估计用时2小时，要求周二之前完成。
2、数据库连接与调试：小组派出一人完成，建立数据库，估计用时2小时，要求周一完成。
3、文件修改、文件上传以及文件浏览：小组派出两人合作完成，编写相关代码，文件存储在相关的文件夹当中，估计用时2小时，要求周三之前完成。
4、文件查重：作为主要功能，小组派出两人合作完成，编写相关代码，针对如何实现查重（查重的具体方法），查重后如何显示，判断查重文件的是否抄袭，用时4小时，要求周三之前完成。
5、对于以上方式的测试与修改：小组派出两人合作完成，针对功能实现的bug排查，代码规范化，估计用时3小时，要求周四之前完成。
6、界面美工：作为一个门面工作，小组派出两人合作完成，主要是每个界面的优化，估计用时4小时，要求周四之前完成。
针对以上六项任务，由小组成员根据自身兴趣自行认领任务。为防止成员对某个任务都不认领情况发生，小组会适当降低任务难度----增加任务人数；为防止忙闲不均情况发生，对于一些任务很少的成员，小组会根据实际情况要求这些成员对别的任务进行帮助。
第三步: 冲刺 (Sprint).
每天中午利用午饭后的30+分钟开一个每日例会，小组成员总结昨天做啥，今天要做啥以及遇到问题和讨论如何去解决问题，并且小组6人轮流发表博客（内容包括daily scrum）。
冲刺阶段中，大家互相监督，杜绝流于形式的忽悠，对此，在http://www.cnblogs.com/xinz/archive/2012/10/05/2712602.html中有两个很好的改进的方法：一个改进是, 定义好任务究竟是什么? 任务的完成 (done) 到底意味着什么? 另一个改进是, 要在每一个任务中记载我们完成这个任务还需要多少时间。对于我们冲刺到一半的时候，如若有重要改动，我们会即时开临时会议，大家决断。
四、测试计划
|
人员 |
测试内容 |
时间 |
|
林莹 |
数据库连接 |
1天 |
|
洪世豪 |
用户的登陆 |
1天 |
|
王震 |
用户的注册和修改 |
1天 |
|
王杰 |
文件上传 |
1天 |
|
尤少辉 |
查重方法 |
2天 |
|
林晨昕 |
测试所有的内容 |
1天 |
（1）测试计划：
（2）测试设计规格说明书：
1.功能：登陆界面;查重系统
2.测试的方面：登入方式；查重方式；
3.如何测试：采用test方法测试：
4.测试的标准：重复率的差错不会高于百分之1；
调用数据库的不会出错；
（3）测试用例：
1.正确输入（用户输入了合法并正确的用户名和密码），预期结果是用户能够正常登录。
a.用户名又有多种情况（数字、字母、中文）。
b. 用户登录“记得我的账户和密码（remember me）”功能可以正常使用。
c. 用户的密码是否隐式显示，转送。
2.错误输入，预期结果是系统能给出相应的提示。
a. 用户名不存在；
b.用户名存在，但密码错误；
（4）错误报告的要求：
1.Bug的标题，要简明地说明问题。
2.Bug 的内容要写在Description中，包括：
a. 测试的环境和准备工作；
b. 测试的步骤，清楚地列出每一步做了什么；
c. 实际发生的结果；
d. （根据spec和用户的期望）应该发生的结果。
3.如果需要其他补充材料，例如相关联的Bug、输出文件、日志文件、调用堆栈的列表、截屏等，都要保存在Bug 相应的附件或链接中。
4.还可以设置Bug 的严重程度（Severity）、功能区域等，这些都可在不同的字段中记录。下面是九条创建的一个Bug：
（5）测试修复，关闭缺陷报告：
当开发人员修复了一个缺陷并签入代码后，一个新的构建就会包含这一个修复（Bug fix）。
测试人员所要做的就是验证修复，并且搜寻有无类似的缺陷，验证修复有没有导致其他的问题（回归，regression），了解修复的影响（是对一个简单的显示文字的修改，还是内部算法的改变），
并且检查系统的一致性是否受影响（例如：修改了默认的/是/否/取消/选择次序，要检查整个产品中其他的对话框是否遵循同一模式）。在完成了测试之后，测试人员可以关闭缺陷报告，同时在“历史（History）”
这一栏内说明是如何做的验证。当测试人员验证了一个Bug被正确修复了之后，还要考虑是否把这一个Bug变成一个测试用例，这样可以保证以后的测试活动会包括这个Bug描述的情况。这是一个很重要的步骤。
（6）测试报告
对于测试报告不需要太多文档，只需要列出一些数字即可；如：
对于某些功能，我们要收集下列数据：
1.多少测试用例通过？
2.多少测试用例失败？
3.多少测试用例未完成？
4.多少在测试用例之外的Bug被发现？
所有功能的测试报告相加，我们就能得到整个项目的统计信息。这样的信息能帮助我们从宏观上了解还有多少事情没办完，各个功能相对的质量如何。
（7）运用测试工具
1.新建立相应的测试方法：
2.新建立一个文件：填下以下的内容：
a. 测试的标题（Test Title）——简明的标题。
b. 测试的详情（Test Details）——测什么。
c. 测试的对象（Test Target）——测试什么功能。
d. 测试的步骤（Test Steps）——提供详细的测试步骤和每一步期望的结果。
e. 修改的记录（Revision History）——对这一测试进行修改的历史记录。
3.运用工具记录自动测试
对于网络程序，我们可以把对网页的访问和操作像录音一样录下，“录音”主要是记录HTTP请求的URL，以及header和body中的各个参数。
记录是否成功取决于服务器返回的状态码。当然，我们也可以自己定义pass/fail的条件。这样以后测试的时候重新放录音带即可。
4.新增加一个 Web Test
nternet Explorer 就会打开，同时Web Test Recorder 也会激活[2]，测试人员就可以按照场景测试网站的各项功能了，
同时注意到Web Test Recorder 会记录每一个网页的地址，以及可能的参数。
其中值得提出来的是，测试人员可以选中“Generate Code”，生成测试脚本，可以在脚本一级开发测试。测试人员可以用脚本建立循环测试，或者根据某一步测试的结果选择不同的测试分支（path），更加灵活。
另外，我们还可以用C#作为测试代码的语言，这个比其他通用工具的脚本强大许多，这也是用VSTS做测试的好处之一。不同的测试可以把不同的次序结合起来运行，测试人员可以用“Ordered Test”来管理这样的测试集合。
可以用和创建Web Test 类似的方法创建 Ordered Test。
5.测试效能
除了功能方面的测试外，我们还要测试那些“服务质量”。如效能测试、负载测试、压力测试。
1.效能测试：在100个用户的情况下，产品搜索必须在3秒钟内返回结果。
2.负载测试：在2 000个用户的情况下，产品搜索必须在5秒钟内返回结果。
3.压力测试：在高峰压力（4 000个用户）持续48小时的情况下，产品搜索的返回时间必须保持稳定。系统不至于崩溃。
效能、负载、压力这些方面的测试会产生很多数据，这些数据最好保存在数据库中，以便于跟踪分析。这些数据为以后做网站容量规划（Capacity Planning，又称容量规划，能力规划）提供重要的依据。
负载的各种参数：
1.停顿时间（Think Time）：在每次请求之间和一批测试之间的停顿。
2.负载模型（Load Pattern）：模拟的用户量是恒定在一个数值的（如：总是30 个用户），或者是分级进行的（如：开始是5个用户，每分钟增加10个用户，直到最高50个用户）。
3.测试混合模型（Test Mix）：此次负载测试要运行多少种测试，每种测试所占的比例是多少。
4.浏览器混合模型（Browser Mix）：各种浏览器的选择及比例。
5.网络混合模型（Network Mix）：各种带宽的网络及比例。
6.收集效能数据：
这些效能数据会反映在负载测试中。最后一步是设置运行负载测试中的各种参数。
