游戏测试用例编写方法浅谈[整理]
如何编写一份优秀的测试用例
如何写好测试用例面对这个题目，其实我并不想写，因为去网络上搜索“测试用例”为关健字的东东，出来的太多太多，各个凡有关能涉及或不涉及到的测试有关的都会有很多东西出来。
如果大家仔细研究一下，其实内容大致差不多，只不过看自己是否能消化而已。
在测试几年的过程中，打交道最多的是测试用例，从需求开始到方案，到形成用例，执行过程中与实际的出入，测试完成后用例的修改，维护等，没有一个过程可以说不需要测试用例之说。
但我今天还是写了关于测试用例的，不是写如何设计编写，而是如何写“好”。
让人看了一目了然，就看有新人拿到这个用例，能对程序有一点点基本的了解，就可以按照用例完完整整的执行下去。
在短信回执的测试用例里，我没有修改过的用例是很少的，在组员编写测试用例过程中我总会强调简单明了，其实就是精华。
我认为有以下几点要关注：1、对功能的理解。
这个是最重要的，也是能反映出每个人对同一功能描述而有不同的理解方式，故一定要深刻理解功能。
2、编写用例永远要考虑两面性。
事物都是两面的，只有一面的事物那是“怪物”，所以在编写测试用例时先要心中有数。
3、确定测试用例的目的。
如果不了解为何要写这个用例，那你达到的目的就是按需求或者按任务来完成而已，这样的用例是否适用还有待于商榷；只有了解这个功能的来源，为什么要做这样的功能，希望最后的结果是什么，这些通通考虑清楚了，就不会为了完成任务而去编写出“普通”的测试用例，而是一份优秀合格的测试用例，这样会大大提高工作效率及审核打回的次数。
4、测试用例所包含的内容：最基本最简单的测试用例应该包含四项内容，即描述、预置条件、操作步骤、预期结果。
一般为更好的管理及维护测试用例，我们会增加测试用例的编号及功能。
1）测试用例的描述项，一般人在写的时候根本不去关心这到底有何用，有的甚至为空，更有甚者把需求中的几个字直接复制过来，不管是否通顺与否都放在那里认为就可以了，预置条件可以说是一个总结语，即你要明白这个用例是要验证什么的，因为一个功能有很多用例，你不可能每个描述都是一样的，那这样还不如不要描述。
游戏测试用例-设计步骤
游戏测试用例-设计步骤1.确定测试目标：首先需要明确测试的目标，即想要测试的是游戏的哪个方面，如功能、性能、兼容性等。
根据测试目标确定测试用例的覆盖范围。
2.收集需求和功能列表：与游戏开发团队沟通，了解游戏的需求和预期功能。
根据收集到的信息编制出功能列表，列出游戏的各项功能。
3.划分功能模块：将收集到的功能列表进行分类，划分为不同的功能模块，如登录、注册、游戏关卡、游戏角色等。
划分功能模块有助于更好地组织测试用例。
4.定义测试条件：针对每个功能模块，确定测试所需的条件，包括输入数据、预期结果、预期行为等。
测试条件的定义应尽量详细和准确。
5.设计测试用例：根据测试条件，设计出能够验证功能模块是否正常工作的测试用例。
每个测试用例应包含测试步骤、输入数据、预期结果和实际结果等信息。
6.确定测试优先级：根据功能的重要性和影响程度，确定测试用例的优先级。
通常情况下，越重要和常用的功能，其测试优先级越高。
7.确定测试环境：确定进行测试所需的硬件设备和软件环境。
包括操作系统、浏览器、网络等。
测试环境要和实际用户的使用环境保持一致。
8.执行测试用例：按照设计好的测试用例，逐步执行测试步骤，并记录下实际结果。
测试的过程中要注意记录问题和异常情况，以便后续的修复和改进。
9.分析测试结果：将实际结果与预期结果进行比对，分析测试结果的差异，找出问题的原因和根本原因。
可以使用一些测试工具和报告来辅助测试结果的分析。
10.报告测试结果：将测试结果整理成报告并进行汇总，包括问题的描述、复现步骤、截图等。
向开发团队提供详细和准确的测试报告，以便问题的修复和改进。
11.追踪问题：对于发现的问题，要及时追踪其解决进度，并进行反馈和确认。
在下一轮测试中，要验证问题是否已经解决。
12.优化测试用例：根据测试过程中的经验和反馈，不断优化测试用例，提高测试的效率和准确性。
根据测试结果和用户反馈，进行持续的测试改进。
总结来说，设计游戏测试用例的步骤包括确定测试目标、收集需求和功能列表、划分功能模块、定义测试条件、设计测试用例、确定测试优先级、确定测试环境、执行测试用例、分析测试结果、报告测试结果、追踪问题和优化测试用例。
如何编写有效的测试用例
测试用例（Test Case）是将软件测试的行为活动做一个科学化的组织归纳。
目的是能够将软件测试的行为转化成可管理的模式；同时测试用例也是将测试具体量化的方法之一。
可以说测试用例是软件测试的核心。
作为一位功能测试人员，其主要的职能就是进行测试用例的设计，并根据测试用例执行测试，通过全面的测试来验证产品的质量。
因此测试用例也从侧面反映了一个测试人员的测试思路的严密和发散性。
不同的测试人员，编写测试用例的方法五花八门，各有千秋。
两种观点：第一种观点：一个好的测试用例，做到以下几点：当一个不熟悉业务的人，看到你的用例后，要知道用例的测试目的什么，知道你要做什么，怎么做，为什么这样做，取得了什么什么成果。
即越详细越好，做到每一个操作都考虑到。
第二种观点：用简单的语言描述测试case的输入和预期的输出结果。
好的测试用例应具备的五个要素：一是测试用例对需求覆盖的完整性；二是测试用例的有效性；三测试用例的可理解性；四是测试用例的清晰性；五是测试用例的可维护性。
一、一个标准的测试用例应该包含以下元素：1测试名称(Test Name)：测试用例编号和测试用例名称。
A）用例根据各用例的功能来命名，尽量做到简洁明了。
B）一级目录使用各项目的顶级菜单名称来命名，如功能、业务、查询三大类；C）二级目录使用顶级菜单下的二级菜单名称类命名，用户可根据名字判别该用例是测试哪个模块的。
2测试目的3测试方法选择依据4用例执行的前提条件：即执行用例需要满足的前提5创建日期(Creation Date)：测试用例创建时间，系统自动产生。
6设计人员(Designer)：测试用例设计人员7状态(Status)：测试用例状态8描述（Descrīption）：测试用例详细描述要用通俗易懂而又简洁的语言描述描述用例的设计目的，让其他人能够明白我们在什么9步骤名称（Step Name）：测试步骤名称10步骤描述（Step Descrīption）：测试步骤详细描述。
浅谈测试用例分析和设计
浅谈测试用例分析和设计测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据。
下面我们来浅谈下测试用例的分析和设计过程。
一、测试用例分析阶段测试用例设计的基础文档是需求文档，如果测试人员能拿到一份完整的准确的需求文档，那么对测试人员来说，工作量可以减轻大半，工作效果会大幅提高。
但是我们在需求分析阶段，即便是在需求评审之后，我们拿到的需求文档，仍然是存在一些疑义的或者是分析不透，表达不清的一些需求文档。
这样的时候，测试人员是否有自己的分析方法，显得尤为重要。
测试人员对付需求文档，从操作策略上来说，可以从以下两点出发：（一）、对于需求规格全面、完整的需求文档来说，我们可以采取“切割策略”，把需求按一定的粒度进行分解，来编写测试用例。
（二）、对于简单不全面、需求规格含糊的需求文档，我们可以采取的策略：“联想策略”。
这点还是主要来自工作经验及对该行业的理解，把一些含糊的内容补充起来。
在参与需求文档阅读的过程中，我们还可以采用一些小方法，把需求吃透。
例如：1、在参与需求阅读的过程中，我们可以把需求中的一些边界或者异常的情况列出来，这些往往是以后bug的多发地带。
2、对于需求文档中的一些隐式缺陷，我们需要补充清楚质量属性，例如一些安全性、性能、UI等的一些质量属性内容，我们需要补充清楚。
3、对需求文档的阅读，我们还可以采用一些工具：思维导图工具及UI界面设计工具，把图给画出来，有助于我们理解需求，找到测试点。
例如思维导图工具，通过名词+动词的方法，可以把测试数据和操作动作列出来，有利于理清测试的要点。
通过以上的一些策略和方法，我们大致上可以把需求测试分析做的比较到位了。
测试人员对需求文档分析后，接下去还需要对设计文档进行分析，大部分的测试人员，不是太注重开发组的这份设计文档，觉得与己无关，其实，理解设计文档，有利于降低我们的测试规模，降低劳动负荷。
一般来说缺陷会与内部结构映射，如果你了解了代码的结构，一般来说，我们都可以找到缺陷出现的真正原因了。
游戏测试的用例设计
、
测 试 用例 设 计 基础
先 来 介 绍 一 下 游 戏例 子 中 ， 由 于达 到 对 ３ ０这 个值 就 要 进 行 边界 测 试 ，即 要
类， 另外 的功能键 ， 比如空格 、回车、 ｔ ｃｌ ｒ
、
１ 通 过 测 试 和 失败 测 试 ．
Ｐ 取 各种 手 段进 行 一 些 异常 测试 。 比如 ， 况 。比 如 从 Ｎ Ｃ处 买 人物 品 ，点 击 后 预 判断 ，这 就意 味 着 ，客 户端 的逻 辑和 会 弹 购买 数 量 的输 入 框 ，该 输 入 框 服 务 器端的 逻辑 要分 开测 试 ，而且 ．服 个 没 有 加 入 过 帮 派 的 角 色 ，针 对 其
所 以 软 件 测 试 的 一些 方 法 理 论 同样 适
用 于 游 戏 。软 件 测 试 分 黑盒 测 试 和 白
进 行 测 试 会 有 怎 样 的 结 果 呢 ？ 针 对 角 测 试 中 需 要 注 意 的 ， 当然 也 需 要 反应
色等 级 ：“ 用一 个 ２ 级 的 没有 加入 过 在 用 例 设 计 上 。 使 ９ 帮 派 的 角 色 ，执 行 加 入 帮 派 的操 作 。 ３ 等 价 类 的 划 分 ” ．
盒 测 试 。黑 盒 测 试 是 指 软 件 测试 员只
需 知 道 软 件 的 功 能 即可 ， 只 要 进 行 一 预期 结 果 ：“ 能 加入 帮 派 ，给 出相 应 不
由于 人力和 时 间的限 制 ，在测 ｉ 中 式 。针 对 角色身 份 ：“ 使 不可 能把 所有 的数 据都 输入 一遍 ，这 样 些输 入 ，就 能得 到某种 输 出结果 ，对软 的等 级限 制提 示” 件 的 运 行 过 程 和 步 骤 都 不 用 了 解 而 用 一 个 ３ ０级 以 上 的 、但 是 已经加 入 帮 显 然是 低 效 的 ，并 且 大部 分 是 无 用功 ， 白盒 测 试 ，是 指软 件 测试 员需 要 查 看 派 的 角色 ，执 行加 入 帮派 的 操 作 ” 。预 所 以 合 理 的 划 分 等 价 类 就 显 得十 分 重 和 阅 读 程 序 代 码 ， 并 通 过 检 查 代 码 来 期结 果 ：“ 能 加 入 帮派 。提示 已经 是 要 ，划分好 等价类 后 ，在 一 不 个等价 类中 ， 进 行测试 。在本 文 中 ，笔者将 介绍 － 种 帮 派 成 员” 当然 ，以上 只 是 说 明测 试 只 要 抽 取 ｌ２个 样 本 进 行 测 试 就 可 以 一 。 一
测试用例编写方法
测试用例编写方法测试用例的编写是软件测试的基础，它的完整性与合理性影响着软件测试的质量，本文结合实际和专业知识，介绍测试用例的编写方法，帮助读者更好地掌握软件测试流程。
1.试用例编写前期准备在测试用例的编写前，最重要的就是要做好充分的准备，这样才能使测试用例的编写更加高效，更能反映出测试的要点。
在准备的过程中，需要收集测试用例所需的信息，包括测试范围、测试标准、测试环境以及实施测试所需要的工具。
除此之外，还需要根据需求文件和测试计划，设计出需要测试的具体功能；测试用例的编写前期还需要确定测试类型和测试方法，让测试有正确的定位和走向。
2.试用例的编写在完成准备工作之后，就可以正式开始测试用例的编写了。
测试用例的编写要按照一定的格式和流程，要根据项目的需求文件和测试计划来编写，并要多考虑用户的实际使用情况，以及一些特殊条件下的功能测试，以满足用户的实际需求。
测试用例的编写一般包括以下几个部分：1）测试用例编号：根据测试用例的具体功能，编写对应测试用例的编号；2）测试用例描述：简要描述本测试用例的具体功能和目的；3）测试用例步骤：详细描述测试用例的执行步骤；4）测试用例输入：通过简要描述测试用例的具体输入；5）测试用例期望结果：明确描述本测试用例的期望结果；6）测试用例实际结果：描述本测试用例的实际结果，以便于进行性能检查。
3.试用例的审核在测试用例的编写完成之后，需要进行一定的审核，以确保测试用例的完整性和正确性。
审核的过程一般包括准确性审查、质量审查以及时效性审查。
在审查的过程中，可以通过面对面的沟通、回答查询问题的方式，检查测试用例是否记录完整，以及测试结果是否与期望结果一致；还可以通过进行特殊的测试环境和特殊场景的测试，检查是否存在遗漏的测试步骤以及遗漏或不清楚的步骤说明。
审核完毕后，会制作出审核报告，把审核过程中发现的问题进行汇总，以作为审核结果和测试负责人之间的交流和对策。
总之，测试用例是软件测试的重要工具，编写测试用例的过程要考虑到软件测试的目标以及测试人员的能力，要全面的考量测试的关键点和重点，不仅要充分准备测试的资料，更要注重测试用例的完整性和可执行性，以及审核的质量，以保证测试的成功。
如何编写高质量的测试用例
如何编写高质量的测试用例测试用例是软件测试过程中非常重要的一环，它用于验证软件系统的正确性和稳定性。
编写高质量的测试用例对于确保软件质量和提高测试效率具有至关重要的作用。
本文将介绍如何编写高质量的测试用例，以帮助测试人员在实际工作中提升测试能力。
1. 确定测试目标在编写测试用例之前，首先要明确测试目标。
测试目标可以是用户需求、功能特性或者性能指标等。
明确测试目标有助于确定测试用例的范围和方向，避免测试遗漏或者测试冗余。
2. 划分测试等级根据软件系统的复杂程度和重要程度，将测试用例划分为不同的测试等级。
常见的测试等级包括单元测试、集成测试、系统测试和验收测试等。
不同的测试等级需要编写不同类型的测试用例，确保每个等级的测试的可靠性和有效性。
3. 设计测试用例在设计测试用例时，应该考虑测试覆盖的全面性和有效性。
测试用例应该覆盖软件系统的各个功能模块、用户操作路径和异常处理情况等。
同时，测试用例的设计应该符合等价类划分、边界值分析和错误推理等测试设计技术，以提高测试用例的质量。
4. 使用清晰的测试步骤测试用例应该具备清晰的测试步骤，让测试人员能够按照步骤执行测试。
每个测试步骤都应该明确操作和预期结果，以便测试人员能够准确执行和判断测试结果。
测试步骤的清晰性有助于提高测试的一致性和可重复性。
5. 考虑多个测试场景在编写测试用例时，应该考虑多个测试场景。
测试场景是指不同的环境和条件下的测试情况。
通过设计不同的测试场景，可以验证软件在不同情况下的兼容性、稳定性和性能等方面。
测试场景的考虑可以通过使用测试数据生成工具、模拟实际用户行为或者模拟网络环境等方式实现。
6. 使用易于理解的测试用例命名规范为了方便管理和使用测试用例，应该使用易于理解的命名规范命名测试用例。
测试用例的命名应该包含测试目标、功能模块和测试场景等信息，以便在后续的测试执行和结果分析中快速定位和管理测试用例。
7. 定期维护和更新测试用例随着软件系统的迭代和演化，原有的测试用例可能会失效或者无法覆盖新的功能特性。
游戏协议测试用例分析
游戏协议测试用例分析一、测试概述二、测试目标1.验证游戏服务的注册与登录协议的正确性，包括用户信息的输入验证和账号密码的正确性验证。
2.验证用户信息保护协议的执行情况，包括个人信息收集和使用的合法性、信息保护和隐私政策的执行情况等。
3.验证游戏交易与支付协议的正确性，包括虚拟物品交易和支付功能的安全性和可靠性。
4.验证用户行为规范协议的执行情况，包括用户在游戏中的行为规范、禁止行为和违规处理等方面的合规性和执行情况。
三、测试用例设计1.注册与登录协议测试用例1.1验证用户名的输入合法性，包括用户名的长度、字符类型等限制条件。
1.2验证密码的输入限制条件，包括密码的长度、字符类型等限制条件。
1.3验证账号密码正确性验证的准确性，包括正确的用户名和密码、错误的用户名和密码等情况。
1.4验证注册功能的正确性，包括用户输入正确的注册信息后的成功注册场景、用户已存在的情况下的注册失败场景等。
1.5验证登录功能的正确性，包括使用正确的用户名和密码的成功登录场景、使用错误的用户名或密码的登录失败场景等。
2.用户信息保护协议测试用例2.1验证个人信息收集和使用的合法性，包括个人信息的采集方式、合理性和合规性。
2.2验证用户信息保护和隐私政策的执行情况，包括用户信息的保密性、数据安全性和用户权益保护等方面。
2.3验证用户对个人信息的授权和管理功能的正确性，包括用户是否能够授权或拒绝个人信息的使用、是否能够修改或删除个人信息等。
3.游戏交易与支付协议测试用例3.1验证虚拟物品交易功能的正确性，包括用户购买虚拟物品的流程、用户选择的物品是否正确、虚拟物品是否成功收到等。
3.2验证支付功能的安全性和可靠性，包括用户支付金额是否正确、支付方式是否正确、支付流程是否正常等。
3.3验证交易记录的准确性和完整性，包括用户购买记录是否正确、支付金额是否一致、交易状态是否处理正确等。
4.用户行为规范协议测试用例4.1验证用户在游戏中的行为规范执行情况，包括用户是否能够遵守游戏规则、是否存在作弊、刷分等违规行为等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
游戏测试用例编写方法浅谈[整理] 游戏软件功能测试——测试用例的编写方法浅谈
一、游戏软件与通用软件的区别
a) 通用软件的需求明确，游戏软件需求理想化
i. 通用软件中用户每步操作的预期结果都是明确且有规范可参考的，而网游中并
不是所有的需求都有一个明确的预期结果，拿技能平衡性来说，我们所谓的平衡也只是相对的平衡，而非绝对的平衡。
没有什么明确的参考参数。
只能根据以往游戏的经验获得一个感知的结果。
ii. 网络游戏中的某些功能是有预期结果可参考的。
例如组队、交易，而另外一些
带有策划创意的功能，却是根据策划个人的理解，来确定其预期结果的。
人的思考力都是有限的，所以不能保证在他的创意中会考虑到各种各样复杂的细节。
也不能够保证这个创意就可以完全被用户所接受。
当你作为游戏测试人员时，很多时候你需要做的不仅仅是验证功能。
也需要帮助开发者和用户找到一个互相容忍的平衡点。
游戏软件的测试员带有对策划需求的怀疑，力求通过自
己的努力在玩家和开发者之间将可能产生的矛盾减小。
b) 通用软件开发过程中需求变更少，游戏软件开发过程中需求便更快
i. 通用软件的使用人群和软件的功能针对性，决定软件从开始制作就很少再有新
的需求变更。
而游戏软件，为了满足玩家对游戏的认可度，策划需要不断的揣摩玩家的喜好，进行游戏功能的改进。
加之网游制作本身就是一个庞大复杂的
工程，开发者不可能做到在开发的前期，就对游戏架构及扩展性做出最好的评估。
所以导致为了满足用户的需求而不断的进行一些基础架构的修改，基础架构的修改必然导致某些功能的颠覆。
所以就出现了，游戏开发过程中的一个恶性循环，当基础架构修改到满意了，玩家的需求又有了新的变化，随之而来的又要进行新的调整，再进行新的修改。
最终导致了游戏软件的开发周期不断加长。
任何一个有经验的团队，对于每一个影响基础的改动都应该做出正确的评估。
二、网游有哪些测试内容
a) 性能
i. 客户端性能
ii. 服务器端性能
1. 服务器
2. 数据库
iii. 网络
b) 功能
i. 从运行完game.exe打开游戏界面后可进行的各种操作、玩法
ii. 界面
iii. 音乐
c) 自动化
i. 测试工作组织实施中需要的工具、软件、平台的开发
ii. 自动化的回归测试作用:游戏中基础的、变动不大的、出错率高的、可进行
checklist重复测试的功能、性能等自动化是一个好方法
iii. 任何时候自动化都取代不了人脑，它只是将一些重复性的劳动从我们测试人员
身上去掉，让我们有更多的时间做更有意义的事情，如果你觉得你做一件事情是重复的，且有规律可行的，不防考虑自动化
三、游戏中针对功能性测试测试用例编写浅谈
先了解下游戏中有哪些功能:
a) 游戏发开中的功能有哪些
i. 不同的游戏对于功能的划分不同，但是目前主流一些功能划分中有以下内容:
1. 基础操作
2. Npc
3. 地图
4. 装备
5. 剧情
6. 技能
7. 人际
8. PVP
9. ……
这样我们很简单的将整个游戏的功能进行了划分，划分完毕，下来的工作就是针对某个
功能的测试了。
很多人都问过一个问题，游戏测试中测试用例到底有什么用。
下面继续~
b) 游戏测试的测试用例有什么作用
i. 测试执行过程中，按照用例指示的操作检查操作结果是否正确，记录测试过程
中发现的bug
ii. 按照用例的执行结果确认功能的通过与否，也有的按照用例的覆盖率来确定单
服测试的通过与否
iii. 便于回归测试的执行
这样讲应该比较明白了吧。
c) 测试用例应该包括什么——测试执行过程中所需的所有信息，举例说明下。
例如:
i. 表头:功能名称、案例编写人员、编写时间、测试人员、测试时间
ii. 正文:功能点、测试点、测试输入、预期结果、实际结果
iii. 用例执行结果统计
d) 功能点模块化理念
都知道一个复杂庞大的系统，程序在实现时会将其分成若干模块按照模块功能优先级进行实现。
我们测试过程中也采用这种方法，将复杂的功能点按照实现功能
进行分类，分类后的测试点，再进行分类，直至细分成为一条条用例。
就像庖丁解
牛那样。
按照等价类划分法，将同一判断条件的测试点组成一个集，在这个条件基础上再次判断的条件，我们假设它已经成立。
这样在用例设计过程中就需要测试人员清
楚的知道，哪些条件是一类需优先确认的，哪些是以这类条件为基础的。
我们最终
形成的测试用例一定确保的是一条用例只检查一个测试点。
这样设计也有另外一个好处，如果一条用例不能走通，其它的还可以继续检测，
经常会遇到测试过程中由于一个bug，导致测试工作停滞。
现在这样子我们就可以
采取脚本调试，或者其它方法跳过有bug的测试内容，继续进行其它测试点的测试
了。
e) 场景测试法协助功能点细分
游戏测试中，场景测试方法是经常用到的一种方法，什么是场景测试法，及按照功能设计要求，在脑中模拟出来的一个功能使用时的操作流程。
按照每步操作的
针对点，将针对点划分为所用例设计时的小功能点。
划分时需每步针对点的各种检查点分到该功能点内设计为该功能点的检查点。
再根据检查点进行测试输入(及操作过程)的编写。
用例编写过程中的思考方式就如上了。
讲起来比较抽象，希望对大家有所帮助。
f) 用例的设计原则——一直有人问到底要详细到什么程度 i. 我们不期待用例编写到任何人都可以执行，也没有这个必要 ii. 我们针对的是网游的测试人员，至少是玩过网游的人，这些人对于游戏中的基
础设定都有认识，我们不可能对着一个不知道任务界面是什么的人大讲怎么测试任务。
所以我们用例编写的原则就是针对我们测试组内的测试人员。
iii. 但是，请不要简略到别的测试人员看不懂，特别是当你是专职的用例编写人员
时，编写时请多考虑下语言描述的方式。
请让你的同伴可以看懂，你所要表达的意思。
iv. 用例是没有固定格式的，它的主要原则就是，测试中所需所有信息，我通过你
的文档都能够获取到。
所以不要再执着的像别人要模板。
模板你自己都可以设计，发挥你的创意。
四、编写过程注意事项
与设计人员的沟通
拿到一份文档时请不要急于编写，在这之前很多事情需要做，请先将文档阅读至少三遍，然后思考下，你自己大脑中是否有你所看文档功能点的一个流程图，当确认已经准备好了。
开始设计用例，用例设计的过程就是与设计人员不断沟通，深入了解功能的过程。
你会发现，或许跟你之前流程图中想像的并不完全一样。
这个时候不必惊讶，去找他们核对就好。
不怕发现问题，就怕没有发现问题，最终做了很多无用功。
编写过程中发现的没有预期结果的内容，请及时与策划人员、程序人员核对，必须三方核对。
核对完毕提醒策划人员及时更新设计案，提醒程序人员设计案新修改内容。
这样你会发现，设计测试用例过程的本身就是发现策划案不完善的过程。
请运用你的思维，采用边界法、等价类划分法、错误推断法、以及以往的经验，将每一个测试点的所有需检查点进行充分的设计。
发挥你的主动性，和测试组内其它人探讨你认为可能存在风险的测试点，以便得到更多有价值的信息。
Over。