我正在做一个学术项目,我不是在寻求帮助,只是在测试方面对内容提出建议:
基本上我已经制作了一个游戏,并且有人建议我避免写关于低级测试的内容,而只写一个专门用于测试的简短部分。但是我到底包括了什么?我的游戏非常复杂,所以可能只是主要功能的测试用例表,说明它们可以正常工作?如果是这样,是不是在测试试图使软件崩溃?
当然,我经常测试我的应用程序作为构建它,但没有真正的结构。如果我在高级测试中只填写一页或两页,人们会建议什么?我得把东西放进去。
谢谢!
我正在做一个学术项目,我不是在寻求帮助,只是在测试方面对内容提出建议:
基本上我已经制作了一个游戏,并且有人建议我避免写关于低级测试的内容,而只写一个专门用于测试的简短部分。但是我到底包括了什么?我的游戏非常复杂,所以可能只是主要功能的测试用例表,说明它们可以正常工作?如果是这样,是不是在测试试图使软件崩溃?
当然,我经常测试我的应用程序作为构建它,但没有真正的结构。如果我在高级测试中只填写一页或两页,人们会建议什么?我得把东西放进去。
谢谢!
这一切都取决于项目的类型。如果您从科学的角度写作,也就是说,您的程序旨在展示某些理论的可行性或产生数值结果,那么关于测试存在的单个段落和测试方面的表格就足够了。
如果你是从工程 POV 开始写作(例如,一篇面向工程的 CS 课程的论文),你应该只写下你的方法:你是如何选择测试用例的?您是否执行了单元测试、系统测试或两者兼而有之?测试是否自动化且可移植?简而言之,从软件工程 POV 讨论你的方法,简要概述发生的事情,然后通过讨论这个过程的优点、缺点和经验来表明你学到了你的行业。
我希望他们主要希望您展示某种系统的测试方法。他们可能不希望您具备商业软件测试中使用的专业知识。
您可以做的一件基本事情是编写测试脚本 - 基本上是涵盖游戏中各种情况的步骤清单。您应该测试“快乐路径”,即正常成功的游戏方式、游戏以及任何“替代路径”,您可以在其中尝试一些意想不到的东西,并验证系统的行为是否正确。在游戏中,这可能类似于试图让你的角色穿过墙壁。
测试不仅仅是试图使软件崩溃:这相对容易测试:只需检查所有决策结构(如果是其他情况等)。测试实际上是关于“应用程序是否按照它的设计目的进行?” 对于一款游戏,这意味着您可能会扮演不同的用户角色(游戏玩家、游戏评论者、游戏配置者)并处理各种场景。列出你的“游戏目标”、“互动方式”和“预期结果”。在“预期结果”中,您将列出技术和用户界面结果。谈论场景可以让您了解应该测试什么。在“玩家”角色中,可以进一步细分为“普通用户”、“专家用户”。这些只是考虑测试设计的一些起点:网上有很多关于测试哲学的文章:使用这个资源。以此为生的人可能会给你更好的建议,但这只是初学者......祝你好运!