逆转海绵组测试文档

1.引言

本部分介绍测试基本情况和要求,包括编写目的、项目背景和术语等。

1.1 编写目的

为软件测试建立计划,供软件测试人员作为软件测试实施时的参考。

1.2 项目背景

《海绵宝宝》是一部1999年发行的美国喜剧动画,可以说是一部和我们同龄,陪伴我们成长的一部动画,它的内容搞笑,轻松解压。《逆转裁判》CAPCOM公司制作的法庭辩论型AVG游戏,在游戏中玩家扮演辩护律师,在假象规则的序审法庭上与检察官进行辩论,通过追问和质疑嫌疑人和证人,为委托人获得无罪判决是最终的胜利目的。

2 任务概述

本部分描述测试的目标、测试环境、软件的基本需求,以及测试的条件和限制等。

2.1 目标

能够让玩家顺利地推进剧情,显示文本和动画,根据指证和威慑的动作作出不同反馈,得到无罪判决后,最终结束游戏。拥有一章完整的逻辑通顺的剧情及法庭辩护中的数个剧情分支和玩家互动/选择的部分。

2.2 测试环境python 3.8 pygame

2.3 需求概述

标题界面:展示主要角色,有开始游戏、选择章节继续游戏、其他选项等按钮;

能够让玩家顺利地推进剧情,显示文本和动画,根据指证和威慑的动作作出不同反馈,得到无罪判决后,最终结束游戏。要求在询问环节以外的操作与其他场景的交互区模式相同。询问时,下方的按钮变为威慑与指证。播放按钮也提供回退功能,可以自由切换证言。

威慑时应有相应的逻辑判断,有时需要通过对证言的威慑引出新的证言,再通过指证通过某一询问关卡。威慑应产生一个对话分支,分支结束后回到证言状态。

在询问证人环节进行胜负的判定。每次如果用户指证错误,就播放裁判长生气的画面,扣掉用户的血量。当用户血量为0后,跳转到失败部分,海绵宝宝获得有罪判决,返回标题,游戏失败。

2.4 条件与限制

2.4.1 对性能的规定

输入、输出精度

输入:以像素为精度

输出:一帧画面

时间特性要求

游戏帧数:每秒30次

2.4.2  设备

处理器: 1 GHz Single Core

内存: 512 M RAM

显卡: NVIDIA GeForce GT 640

应用程序接口: Version 9.0c

硬盘: 500 MB available space

支持软件

操作系统:Windows 7以上

编译程序:python 3.x

3 计划

本部分描述测试方案、测试的项目、测试前的准备工作和人员配备等。

3.1 测试方案

测试方案包括测试策略、测试过程、测试内容、要采用的测试技术,以及技术标准等。

3.1.2 测试过程

熊思明负责测试整个剧情流程,模拟用户进入游戏,选择各个关卡游玩

叶青负责测试动画和音效。

3.1.3 测试内容

3.1.4 测试技术

黑盒测试

3.1.5 技术标准

结合游戏本身内容以测试实现功能为准。

3.2 测试项目

包括功能测试、回归测试、界面测试、负载测试和文档测试

3.2.1功能测试

检查各按钮的响应功能是否正确,各页面中文字信息显示正确,对操作的判定显示正确,审判长对举证的反馈正确,游戏能正常结束宣读判决。

3.2.2界面测试

检查界面设计是否规范合理,包括:界面风格、表现形式、字体选择、字号选择、字体颜色等等,是否规范,是否协调一致,是否便于用户操作。

3.2.3性能测试

测试帧率是否达到30fps要求,游戏内处理和响应时间应不超过2s。

3.2.4负载测试

在资源少、有效资源竞争的情况下,测试本系统的使用情况。可同时打开多个应用程序,使cpu和内存占用率较高,剩余资源略高于最低要求测试是否能正常运行。

3.2.5回归测试

即在修改后重新测试系统是否有Bug,测试系统是否满足相关功能、性能、界面等的要求

3.2.6文档测试

根据需求分析文档,对本系统进行测试,检查是否满足需求。

3.3 测试准备

1.与各模块的主要负责人共同协商讨论;

2.阅读软件规格说明书、概要设计说明书、详细设计说明书,并以此作为总的提纲;

3.选择合适的输入/输出数据;

4.编写测试用例。

3.4 测试机构及人员

舒凡诚(组长):根据设计手册指导测试过程,根据测试反馈修复bug,改进完善软件。

熊思明、叶青:编写测试用例、测试文档、根据测试用例在软件上进行模拟测试,协助改进软件。

4 测试项目说明

4.1测试项目名称及测试内容


测试编号


测试内容


01


标题界面


02


局内基本操作测试

 

4.2测试用例


背景音乐



标题界面按钮


光标移动上去有变化效果


点击有音效并作相应跳转


背景采用一个大图片的形式


显示位置、分辨率正确


制作人名单的效果


采用淡出的模式


测试用例编号


01


测试内容


标题界面


测试目标和测试数据状态


达到预期目的


序号


测试内容


操作


预期结果


01-1


游戏开始界面


鼠标点击“开始游戏”


开始进入游戏


01-2


游戏开始界面


鼠标点击“结束游戏”


退出游戏


01-3


游戏结束界面


提示关闭游戏窗口


关闭游戏

1.引言

本部分介绍测试基本情况和要求,包括编写目的、项目背景和术语等。

1.1 编写目的

为软件测试建立计划,供软件测试人员作为软件测试实施时的参考。

1.2 项目背景

《海绵宝宝》是一部1999年发行的美国喜剧动画,可以说是一部和我们同龄,陪伴我们成长的一部动画,它的内容搞笑,轻松解压。《逆转裁判》CAPCOM公司制作的法庭辩论型AVG游戏,在游戏中玩家扮演辩护律师,在假象规则的序审法庭上与检察官进行辩论,通过追问和质疑嫌疑人和证人,为委托人获得无罪判决是最终的胜利目的。

2 任务概述

本部分描述测试的目标、测试环境、软件的基本需求,以及测试的条件和限制等。

2.1 目标

能够让玩家顺利地推进剧情,显示文本和动画,根据指证和威慑的动作作出不同反馈,得到无罪判决后,最终结束游戏。拥有一章完整的逻辑通顺的剧情及法庭辩护中的数个剧情分支和玩家互动/选择的部分。

2.2 测试环境python 3.8 pygame

2.3 需求概述

标题界面:展示主要角色,有开始游戏、选择章节继续游戏、其他选项等按钮;

能够让玩家顺利地推进剧情,显示文本和动画,根据指证和威慑的动作作出不同反馈,得到无罪判决后,最终结束游戏。要求在询问环节以外的操作与其他场景的交互区模式相同。询问时,下方的按钮变为威慑与指证。播放按钮也提供回退功能,可以自由切换证言。

威慑时应有相应的逻辑判断,有时需要通过对证言的威慑引出新的证言,再通过指证通过某一询问关卡。威慑应产生一个对话分支,分支结束后回到证言状态。

在询问证人环节进行胜负的判定。每次如果用户指证错误,就播放裁判长生气的画面,扣掉用户的血量。当用户血量为0后,跳转到失败部分,海绵宝宝获得有罪判决,返回标题,游戏失败。

2.4 条件与限制

2.4.1 对性能的规定

输入、输出精度

输入:以像素为精度

输出:一帧画面

时间特性要求

游戏帧数:每秒30次

2.4.2  设备

处理器: 1 GHz Single Core

内存: 512 M RAM

显卡: NVIDIA GeForce GT 640

应用程序接口: Version 9.0c

硬盘: 500 MB available space

支持软件

操作系统:Windows 7以上

编译程序:python 3.x

3 计划

本部分描述测试方案、测试的项目、测试前的准备工作和人员配备等。

3.1 测试方案

测试方案包括测试策略、测试过程、测试内容、要采用的测试技术,以及技术标准等。

3.1.2 测试过程

熊思明负责测试整个剧情流程,模拟用户进入游戏,选择各个关卡游玩

叶青负责测试动画和音效。

3.1.3 测试内容

3.1.4 测试技术

黑盒测试

3.1.5 技术标准

结合游戏本身内容以测试实现功能为准。

3.2 测试项目

包括功能测试、回归测试、界面测试、负载测试和文档测试

3.2.1功能测试

检查各按钮的响应功能是否正确,各页面中文字信息显示正确,对操作的判定显示正确,审判长对举证的反馈正确,游戏能正常结束宣读判决。

3.2.2界面测试

检查界面设计是否规范合理,包括:界面风格、表现形式、字体选择、字号选择、字体颜色等等,是否规范,是否协调一致,是否便于用户操作。

3.2.3性能测试

测试帧率是否达到30fps要求,游戏内处理和响应时间应不超过2s。

3.2.4负载测试

在资源少、有效资源竞争的情况下,测试本系统的使用情况。可同时打开多个应用程序,使cpu和内存占用率较高,剩余资源略高于最低要求测试是否能正常运行。

3.2.5回归测试

即在修改后重新测试系统是否有Bug,测试系统是否满足相关功能、性能、界面等的要求

3.2.6文档测试

根据需求分析文档,对本系统进行测试,检查是否满足需求。

3.3 测试准备

1.与各模块的主要负责人共同协商讨论;

2.阅读软件规格说明书、概要设计说明书、详细设计说明书,并以此作为总的提纲;

3.选择合适的输入/输出数据;

4.编写测试用例。

3.4 测试机构及人员

舒凡诚(组长):根据设计手册指导测试过程,根据测试反馈修复bug,改进完善软件。

熊思明、叶青:编写测试用例、测试文档、根据测试用例在软件上进行模拟测试,协助改进软件。

4 测试项目说明

4.1测试项目名称及测试内容


测试编号


测试内容


01


标题界面


02


局内基本操作测试

 

4.2测试用例


背景音乐



标题界面按钮


光标移动上去有变化效果


点击有音效并作相应跳转


背景采用一个大图片的形式


显示位置、分辨率正确


制作人名单的效果


采用淡出的模式


测试用例编号


01


测试内容


标题界面


测试目标和测试数据状态


达到预期目的


序号


测试内容


操作


预期结果


01-1


游戏开始界面


鼠标点击“开始游戏”


开始进入游戏


01-2


游戏开始界面


鼠标点击“结束游戏”


退出游戏


01-3


游戏结束界面


提示关闭游戏窗口


关闭游戏

界面上半部分为游戏海报,包含了主要角色——成步堂龙一和海绵宝宝,以及联动的两部作品的LOGO,旨在让玩家了解游戏的主要内容。

4.1.2.  进入游戏后游戏界面及操作


界面布局


根据用户的屏幕分辨率不用,打开的游戏程序的窗口大小也不同。保证游戏宽高为3:4


场景区布局


场景区下方的位置用带边框矩形覆盖,矩形上方有小标题表示对话的人物,矩形内将文字还原逆转裁判播放的模式,按打字机般的效果播放。


根据对话的进行,需要对场景区的人物图像帧进行切换,以实现动画。人物应悬浮与场景之上,置于合适的位置。


文字及音效


根据不同角色和语气,有不同字体和颜色效果

场景切换时切换背景音乐。根据人物语气不同设置不同的文字显示速度


点击推进按钮有音效


交互区布局


询问环节以外


和场景区相同


询问时


下方的按钮变为威慑与指证。播放按钮也提供回退功能,可以自由切换证言。


游戏成功与失败的判定


在询问证人环节进行胜负的判定。每次如果用户指证错误,就播放裁判长生气的画面,扣掉用户的血量。当用户血量为0后,跳转到失败部分,海绵宝宝获得有罪判决,返回标题,游戏失败。


测试用例编号


02


测试内容


局内基本操作测试


测试目标和测试数据状态


达到预期目的


序号


测试内容


操作


预期结果


02-1


剧情推进


点击继续图标


剧情向前推进


02-2


资料袋展示


单击资料袋


显示资料袋内容


02-3


威慑与指证


单机按钮


威慑时应有相应的逻辑判断,有时需要通过对证言的威慑引出新的证言,再通过指证通过某一询问关卡。威慑应产生一个对话分支,分支结束后回到证言状态。

上半部分负责显示背景、人物(有各种表情动作)、文字(包括对话、独白、叙述等)内容。下半部分为玩家的操作区。最初,操作区中间有一个资料袋,右下角有一个控制对话的按钮。按钮的具体作用为:在文字打印中途点击直接打印完整行文字;在文字打印完成后点击进入下一行文字。单击资料袋将由文本控制状态变为证物检查状态。

在文本控制状态点击档案袋,会切换到证物检查状态。此时,档案袋消失,下半屏幕的中心出现证物信息。同时多出了三个按钮,分别为向左切换证物按钮、返回按钮、指证按钮。当单击返回按钮时,将返回文本控制状态。

5 评价

5.1 准则

总的来说,游戏的剧情为本游戏的重中之重。本游戏属于推理类小游戏,为了让玩家获得更好的游戏体验感,游戏剧情以及对于各主人公的印象至关重要。即不能让剧情过于简单太没有戏剧性和互动性,也不能使得剧情过于复杂使玩家思绪不清,既要让玩家保持对游戏的新鲜感,也不能一味地追求困难。所以,对于剧情的设计,互动的设计,主人公的选择为本游戏最重要的环节,需要开发者反复思考、反复揣摩、反复调试。

5.2 结束标准

当本软件开发、修改到符合标准时,经老师验收合格、组长批示,本项目可以结束。

界面上半部分为游戏海报,包含了主要角色——成步堂龙一和海绵宝宝,以及联动的两部作品的LOGO,旨在让玩家了解游戏的主要内容。

4.1.2.  进入游戏后游戏界面及操作


界面布局


根据用户的屏幕分辨率不用,打开的游戏程序的窗口大小也不同。保证游戏宽高为3:4


场景区布局


场景区下方的位置用带边框矩形覆盖,矩形上方有小标题表示对话的人物,矩形内将文字还原逆转裁判播放的模式,按打字机般的效果播放。


根据对话的进行,需要对场景区的人物图像帧进行切换,以实现动画。人物应悬浮与场景之上,置于合适的位置。


文字及音效


根据不同角色和语气,有不同字体和颜色效果

场景切换时切换背景音乐。根据人物语气不同设置不同的文字显示速度


点击推进按钮有音效


交互区布局


询问环节以外


和场景区相同


询问时


下方的按钮变为威慑与指证。播放按钮也提供回退功能,可以自由切换证言。


游戏成功与失败的判定


在询问证人环节进行胜负的判定。每次如果用户指证错误,就播放裁判长生气的画面,扣掉用户的血量。当用户血量为0后,跳转到失败部分,海绵宝宝获得有罪判决,返回标题,游戏失败。


测试用例编号


02


测试内容


局内基本操作测试


测试目标和测试数据状态


达到预期目的


序号


测试内容


操作


预期结果


02-1


剧情推进


点击继续图标


剧情向前推进


02-2


资料袋展示


单击资料袋


显示资料袋内容


02-3


威慑与指证


单机按钮


威慑时应有相应的逻辑判断,有时需要通过对证言的威慑引出新的证言,再通过指证通过某一询问关卡。威慑应产生一个对话分支,分支结束后回到证言状态。

上半部分负责显示背景、人物(有各种表情动作)、文字(包括对话、独白、叙述等)内容。下半部分为玩家的操作区。最初,操作区中间有一个资料袋,右下角有一个控制对话的按钮。按钮的具体作用为:在文字打印中途点击直接打印完整行文字;在文字打印完成后点击进入下一行文字。单击资料袋将由文本控制状态变为证物检查状态。

在文本控制状态点击档案袋,会切换到证物检查状态。此时,档案袋消失,下半屏幕的中心出现证物信息。同时多出了三个按钮,分别为向左切换证物按钮、返回按钮、指证按钮。当单击返回按钮时,将返回文本控制状态。

5 评价

5.1 准则

总的来说,游戏的剧情为本游戏的重中之重。本游戏属于推理类小游戏,为了让玩家获得更好的游戏体验感,游戏剧情以及对于各主人公的印象至关重要。即不能让剧情过于简单太没有戏剧性和互动性,也不能使得剧情过于复杂使玩家思绪不清,既要让玩家保持对游戏的新鲜感,也不能一味地追求困难。所以,对于剧情的设计,互动的设计,主人公的选择为本游戏最重要的环节,需要开发者反复思考、反复揣摩、反复调试。

5.2 结束标准

当本软件开发、修改到符合标准时,经老师验收合格、组长批示,本项目可以结束。

原文地址:https://www.cnblogs.com/DeerTong/p/12074587.html

时间: 2024-11-05 18:51:29

逆转海绵组测试文档的相关文章

测试文档和用户说明书

最近把项目编写的差不多了,然后组长让我写测试文档和用户说明书,说明书给了一个以前他们写过的,然后就想着先把用户说明书写完,过程还好,但是在我写测试文档的时候发现自己真是一波三折. 说明文档的时候,大概有4个窗体,然后呢,我就是先把窗体界面截出来,然后就会在文档上写1-->2-->3-->4,第一步,单击某个按钮,弹出某个窗口,然后选择数据.... 很快,用户说明书写完了,感觉好简单,但是测试文档以前没有好好的写过,所以这次写的时候我还特意要了一个别人写过的文档,但是我对人家的项目也也没什

Hello World!这是一篇测试文档

这是用Windows Live Writer写的一篇测试文档仅供测试

五种方式来消除你对测试文档的仇视

据我所知,测试人员还没有一个专门的吐槽论坛.但是如果有的话,我相信我们中的很多人会承认对撰写测试文件有多么厌恶. 我工作的一部分是不断叨扰别人去写测试文件.我要他们去写文档模板,去查看团队写出的大量测试文档.我可以告诉你,想要在测试过程中发现一个有趣的bug让你的测试工作充满乐趣这只存在于想象中. 更糟糕的是,由于我是一个公司做测试文件的头儿,那么我就必须时刻标榜自己,成为别人的榜样,才能下属心甘情愿为我做事.即使我真的不喜欢,我也不能直接忽视我所负责要做的测试文件. 然而,即使测试并不是一份最

测试文档锁:doc.LockDocument()

/// <summary> /// 总结:用到DocumentManager.Open(filePath)时,如果是ForWrite,就需要用到lock文档锁. /// </summary> [CommandMethod("T38")] //测试文档锁 public void T38() { //Document doc = Application.DocumentManager.MdiActiveDocument; //如果是MdiActiveDocument

ASP.NET WebAPI使用Swagger生成测试文档

ASP.NET WebAPI使用Swagger生成测试文档 SwaggerUI是一个简单的Restful API测试和文档工具.简单.漂亮.易用(官方demo).通过读取JSON配置显示API .项目本身仅仅也只依赖一些html,css,js静态文件.你可以几乎放在任何Web容器上使用 捣鼓了好久最终效果如下 1.API控制器和action描述 2.测试接口 使用swagger 1.创建webapi项目解决方案 2.引用swagger nuget包 swashbuckle和swagger.NET

测试人员必掌握的测试文档

软件测试文档一般是提供测试信息的一组文档,可以是测试人员的工具,也可以是项目开发团队的开发辅助工具. 一般情况下,与项目相关的测试文档主要有以下几个 ~ 1.测试计划.(详情可参考一份标准的测试计划包含哪些要素文章)测试计划由测试小组编写完成后,需同项目中相关人员进行评审,以确保当前的计划与项目进度等方面是一致的. 2.测试策略.一般情况下,较大型的项目会有附加的测试策略文档 ,即详情测试设计.与开发小组中的概要设计文档类似.测试策略文档编写完成后也需要由相关项目经理.开发人员进行评审 .了解测

RUC自习助手_测试文档

文档编号:2016052601 版本信息:v1.0 开发小组:找不到地方上自习组 成员:王丹丹.赵安.吴婧.杨轹丹.孟启飞.彭宇清 版本号 编写人 修改描述 修改时间 V1.0 吴婧 编写初稿 2016-5-30 I.   引言  i.   编写目的 编写这份需求分析规格说明书的目的是为了明确需求,规范化产品的编写,提高开发过程中的能见度,便于控制和管理产品的开发过程,同时安排项目规划与进度,便于程序员与用户之间的交流.协作,并进一步定制产品开发的细节问题,组织产品开发与测试,便于用户与开发商协

软工测试文档

一.软件测试部分 (一) 软件测试计划 引言 本部分介绍测试基本情况和要求,包括编写目的.项目背景和术语等. 1.1编写目的 为网页测试建立计划,供网页测试人员作为网页测试实施时的参考. 1.2专案背景 介绍项目的背景和范围等. 本项目由华中农业大学软件工程学习小组提出,由华中农业大学信息学院2017级计算机科学与技术专业学生完成. 本项目应用范围为对果蔬饮食感兴趣的师生. 1.3术语定义 包括软件和测试方面的基本术语. 白盒测试:白盒测试是一种测试用例设计方法,盒子指的是被测试的软件,白盒指的

Swagger-UI 基于REST的API测试/文档类插件

现在多数的项目开发中,网站和移动端都需要进行数据交互和对接,这少不了使用REST编写API接口这种场景.例如我目前的工作,移动端交由了另一团队开发,不同开发小组之间就需要以规范和文档作为标准和协作基础.良好的文档可以让开发事半功倍,而作为又懒又要效率又能交代的码农,当然最希望一切自动化,或用小聪明来找到最适合的工具. Swagger-UI简单而一目了然.它能够纯碎的基于html+javascript实现,只要稍微整合一下便能成为方便的API在线测试工具.项目的设计架构中一直提倡使用TDD(测试驱