需求&原型改进：
1. 针对课堂讨论环节老师和其他组的问题及建议，对修改选题及需求进行修改 （5分）
没有问题及建议
2. 修改完善上周提交的需求规格说明书（10分）
上周的《需求规格说明书》初稿的不足：界面以及功能缺少界面回退功能选项。
具体改进内容：在功能以及界面的需求上，均添加了界面回退的功能/选项按钮。
场景（1）：小明双击图标打开了小游戏，进入了初始界面，开始选择模式，把鼠标移至基础模式时鼠标图标变作手指时点击选项进入基础模式的游戏，因为小明是第一次玩2048基础模式，所以他点击了玩法介绍了解了一番玩法，然后选择新游戏开始了新一轮的2048基础模式小游戏。一开始界面上有两个数值“2”，小明通过按住鼠标左键然后拖动鼠标左右上下滑动或者敲击键盘的方向键来把两个“2”合成一个“4”，然后界面上又出现了一个“2”，在一轮空操作后，又出现了一个“2”，小明把两个“2”合成一个新的“4”后，又通过各种操作把两个现存的“4”合成了一个“8”......经过一段时间后，游戏界面上的每一个格子都填满了数字且每相邻的两个格子里的数字都不相同，游戏结束。游戏界面上出现了一个弹框，前面提示小明输入昵称，后面显示着小明的本次游戏分数。小明输完昵称后，退出目前界面回到模式选择界面，点开排行榜，看到了自己刚输入的信息。
场景（2）：小红双击图标打开了小游戏，进入了初始界面，开始选择模式，把鼠标移至纸牌模式时鼠标图标变作手指时点击选项进入纸牌模式的游戏，因为小红是第一次玩2048纸牌模式，所以她点击了玩法介绍了解了一番玩法，然后选择新游戏开始了新一轮的2048纸牌小游戏。一开始界面下方出现了两个纸牌，右边的纸牌数值为“256”，左边的纸牌数值为“16”，只能先把右边的纸牌用鼠标按住左键后移动至界面上方的空牌位后，左边的纸牌会往右边进一位，左边补充上一张新的纸牌“16”，然后当小红把两张“16”都移到同一个牌位上后（一张“16”在上，一张“16”在下），两张“16”可变为一张“32”，后一张纸牌消失，经过一段时间后，每个纸牌位的纸牌数等于所允许的最大叠牌数，且没有上下相邻的两张牌数值相同，游戏结束。游戏界面上出现了一个弹框，前面提示小红输入昵称，后面显示着小红的本次游戏分数。小红输完昵称后，退出目前界面回到模式选择界面，点开排行榜，看到了自己刚输入的信息。
场景（3）：小明双击图标打开了小游戏，进入了初始界面，开始选择模式，这次小明选择了自定义模式，他查看了玩法介绍后，按照指示将一张一张图片上传至游戏，并且保存了样式，然后开始了游戏，这次游戏结束后没有弹框弹出，但界面上出现了最高分。
3. 参考《构建之法》8.5节功能的定位和优先级，给出功能分析的四个象限（2分)
WBS+系统设计：
Alpha任务分配计划
甘特图
测试计划
一．首先了解以下几个问题：
1.为什么要编写测试计划？
１）领导能够根据测试计划做宏观调空，进行相应资源配置等；
２）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等；
3）便于相关人员了解测试人员的工作内容，进行有关配合工作
2.什么时间开始编写测试计划？
（测试需求分析前总体测试计划书／测试需求分析后详细测试计划书）
3.由谁来编写测试计划？
具有丰富经验的项目测试负责人
4.测试计划编写6要素？（5W1H）
1）why——为什么要进行这些测试；
2) what—测试哪些方面，不同阶段的工作内容；
3) when—测试不同阶段的起止时间；
4) where—相应文档，缺陷的存放位置，测试环境等；
5) who—项目有关人员组成，安排哪些测试人员进行测试
6) how—如何去做，使用哪些测试工具以及测试方法进行测试。
二．测试计划主要内容：
1.引言
1.1项目背景
该文档的目的是描述204游戏的系统测试的总结报告，其主要内容包括：系统环境的介绍、功能的实现的测试、系统结果评估。本文档预期读者包括：开发人员，项目管理人员，测试人员。
1.2参考资料
（计划编写依据：可行性分析报告／软件需求定义／软件概要设计／软件详细设计／用户使用说明书／……）
《2048JAVA小游戏概要设计文档》
1.3测试术语
功能性测试：按照系统需求定义中的功能定义部分对于系统实行的系统级别的测试；
非功能性测试：按照系统需求定义中的非功能定义部分对系统实行系统级别的测试；
测试用例：测试人员设计出来的用来测试软件某个功能的一种情形。
1.4有关项目人员组成
项目经理：曾祎祺
开发人员：邓画月，梁沛诗，梁子君
测试人员：于可欣，何颖琪
2.任务概述
2.1测试范围
测试用例覆盖
|
序号 |
功能项目 |
测试用例 |
|
01 |
打开游戏 |
test-1 |
|
02 |
新游戏建立功能 |
Test-2 |
|
03 |
游戏存档功能 |
Test-3 |
|
04 |
数字合并功能 |
Test-4 |
|
05 |
数字随机出现 |
Test-5 |
|
06 |
数字移动功能 |
Test-6 |
|
07 |
得分功能 |
Test-7 |
|
08 |
鼠标功能 |
Test-8 |
|
09 |
记录玩家名功能 |
Test-9 |
|
10 |
游戏结束判断功能 |
Test-10 |
|
11 |
重新开始功能 |
Test-11 |
|
12 |
设置键功能（音量，音效） |
Test-12 |
|
13 |
皮肤更改功能 |
Test-13 |
|
14 |
自定义模式图片添加功能 |
Test-14 |
|
15 |
排行榜功能 |
Test-15 |
2.2测试目标
选择一些易于发现程序所含错误的测试数据，证明程序中有错。
2.3 测试用例编写
|
测试用例 |
Test-1 |
打开游戏 |
|
① 按Enter键后能进入游戏选择模式界面。 ② 在不同系统的电脑上能成功运行。 |
||
|
测试用例 |
Test-2 |
新游戏建立功能（三种模式都要测试） |
|
① 选择新游戏按钮后能进入新游戏中。 ② 基础2048页面游戏开始时随机出现两个模块，数值为2或4。 |
||
|
测试用例 |
Test-3 |
游戏存档功能（三种模式都要测试） |
|
① 按返回上一级按钮后，游戏存档。 ② 按关闭游戏按钮后，游戏存档。 ③ 重新进入游戏后，选择继续游戏键，与退出时游戏存档相同。 |
||
|
测试用例 |
Test-4 |
数字合并功能（三种模式都要测试） |
|
① 基础模式和自定义模式每次作出移动控制时所有模块一起移动。 ② 全部模式两个相同数值的模块碰撞到一起转变为一个新的模块，数值为前两个模块数值的和。 ③ 全部模式数值达到2048后即消失，空出位置。 |
||
|
测试用例 |
Test-5 |
数字随机出现功能（三种模式都要测试） |
|
① 基础模式和自定义模式每一次进行移动后皆随机出现一个模块，数值为2或4。 ② 纸牌模式在底部显示两张纸牌，纸牌数值均为2^n（n∈6），两张纸牌叠合起来，前一张为可拖动纸牌，后一张为不可拖动纸牌。 |
||
|
测试用例 |
Test-6 |
数字移动功能（三种模式都要测试） |
|
① 基础模式和自定义模式，玩家可通过键盘方向键来控制游戏，也可以通过按住左键的鼠标移动方向来控制游戏。 ② 纸牌模式通过鼠标左键点取以及拖拽纸牌来进行游戏，表面的纸牌可以拖动，后面的纸牌不能拖动。 |
||
|
测试用例 |
Test-7 |
得分功能（三种模式都要测试） |
|
① 每合成一张新纸牌，分数增加，增加数值为新纸牌的数值。 |
||
|
测试用例 |
Test-8 |
鼠标功能（三种模式都要测试） |
|
① 鼠标移到任何可选选项（按钮）的地方变为手指符号。 |
||
|
测试用例 |
Test-9 |
记录玩家名功能（三种模式都要测试） |
|
① 游戏结束时，出现输入记录者姓名的界面，并能把最后得分和姓名成功录入排行榜。 |
||
|
测试用例 |
Test-10 |
游戏结束判断功能（三种模式都要测试） |
|
① 纸牌模式：判断纸牌位置是否超出底线，若不能与前面纸牌合并，则游戏结束，记录分数。 ② 判断有没有相邻的同数值数值模块，后判断有没有空的位置出现新的随机模块，若都没有，游戏结束，记录分数。 |
||
|
测试用例 |
Test-11 |
重新开始功能（三种模式都要测试） |
|
① 游戏过程中，按返回上一级按钮再按新游戏按钮后，能重新开始新一轮游戏。 |
||
|
测试用例 |
Test-13 |
皮肤更改功能 |
|
① 选择皮肤按钮，能分别为基础模式和纸牌模式改变界面。 ② 不影响原有游戏功能。 |
||
|
测试用例 |
Test-14 |
自定义模式图片添加功能 |
|
① 选择自定义模式选项后，玩家可自主上传图片，一个数值对应一张图片，要标明限定格式以及大小。 ② 自定义完后可以保存当前样式。 ③ 可删除已保存的样式。 |
||
|
测试用例 |
Test-15 |
排行榜功能 |
|
① 基础模式和纸牌模式初始界面可打开排行榜界面。 ② 排行榜可保存得分和记录者，且按得分高低顺序排名。 |
||
3.测试策略
3.1测试人员需求、分工
2人分模块完成
3.2测试方法
（自动化测试／手动测试；白盒测试／黑盒测试；中断测试／临界测试／压力测试等）
黑盒测试：
又叫功能测试或行为测试，只需考虑各个功能，不需要考虑整个软件的内部结构及代码。
1）功能错误或遗漏；
2）界面错误；
3）数据结构或外部数内容据库访问错误；
4）性能错误；
5）初始化和终止错误；
3.3工具引用及测试培训
（内训／外训）
无
3.4测试阶段计划
（工作内容、人员安排、起止时间等）
|
工作内容 |
人员安排 |
起止时间 |
|
测试三种模式 |
2 |
1天 |
|
测试其他功能 |
2 |
1天 |
3.5测试停止及恢复条件
出现错误情况立即停止
分析产生意外结果的原因
记录错误信息
完善程序
恢复测试
3.6测试文档及缺陷提交管理等
|
文档说明 |
作者 |
文档位置 |
3.7测试环境
Eclipse
4．测试资源
4.1硬件资源需求
PC机
4.2软件资源需求
无
4.3测试环境需求
无
4.4测试人员需求
了解客户需求，了解程序，按照分工完成任务
4.5其他（仪器、服务器等）
无
5．风险评估
5.1人力方面；
情况较多无法判断人员是否充足
5.2时间方面；
任务重，时间可能会不够
5.3环境方面；
无
5.4资源方面
网络可用资源有限
5.5部门合作方面
双方思维方式可能有差异
6．其他内容
除以上内容有关项外，还要包括测试计划制定者、日期、修改记录、评审人员（开发负责人／测试负责人／项目经理）等信息
|
测试计划制定者 |
日期 |
修改记录 |
评审人员 |
|
何颖琪、于可欣 |
20181026 |
无 |
三．编写测试计划注意事项
１．测试计划不一定要尽善尽美，但一定要切合实际，要根据项目特点、公司实际情况来编制，不能脱离实际情况；
２．测试计划一旦制定下来，并不就是一层不变的，世界万事万物时时刻刻都在变化，软件需求、软件开发、人员流动等都在时刻发生着变化，测试计划也要根据实际情况的变化而不断进行调整，以满足实际测试要求．
３．测试计划要能从宏观上反映项目的测试任务、测试阶段、资源需求等，不一定要太过详细．
四．评审总结
1.计划评审
测试计划编写完成后，一般要对测试计划的正确性、全面性以及可行性等进行评审，评审人员的组成包括软件开发人、营销人员、测试负责人以及其他有关项目负责人。
2.计划总结
项目完成后，应该对计划的执行情况进行评审，看有哪些不合理的地方，以便为编写下一个项目测试计划做经验积累。
