![[��ǩ:����]](https://www.xuefen.net//file/upload/img/7/228.jpg "[��ǩ:����]")
本文适用对象
初级软件测试人员，或想开拓思路拓展测试范围、提高测试覆盖率的所有测试人员等等。
本文目的
讲述如何快速、简单、有效、有条理地编写一条测试用例，并帮助测试人员从测试用例角度拓展测试思路。
如何简单、快速地
描述（编写）一个测试用例
测试用例的目的在于指导、帮助测试人员按照既定的计划步骤执行测试，并比对测试结果与预期结果是否一致。
对于中大型软件公司而言，测试用例的管理都有既定的规范和工具，如表格管理用例、测试管理软件管理用例（如下图1所示为MeterSphere测试管理软件用例编写页面）等。
但总而言之，测试用例的内容主要不外乎3个部分：前置条件、步骤、预期结果。
那么，对于没有明确地测试管理软件的小型软件公司，或者对于测试人员而言，需要暂时快速地编写一个测试用例或记录测试过程的时候，可以怎么做呢？
推荐一个临时性的用例编写模板：GIVEN...WHEN…THEN。
让我们套用GIVEN…WHEN…THEN的模式来描述下编写用例的大致步骤：
有没有觉得很简单？
让我们再用实际案例，描述下如何用GIVEN…WHEN…THEN模板编写真实用例。以测试访问 http://www.baidu.com 链接这个用例为例1：
使用GIVEN…WHEN…THEN能够简单呈现用例前置条件、执行步骤和预期结果间的逻辑关系，并能清晰地表述一个用例。
那么，什么地方可以用GIVEN…WHEN..THEN这个模板呢？这个模板较之文档用例更为简洁，如下图2所示，对于测试用例提交故障，阐述引发故障的操作方法或故障复现方法，以及故障修复后的验证时都可以使用。
如何使用探索式场景联想法
衍生测试用例
探索式测试更多的是一种测试风格和测试思想，要求测试人员在测试过程中不断思考、发散思维，记录、修改和更新测试方法和测试用例。
场景法则是要求测试人员认真分析测试需求，了解用户使用场景，根据不同的场景进行测试。
而本文讨论的 探索式场景联想法，则是将探索式测试方法、场景法和联想法相结合，在已有测试用例的基础上衍生更多的测试用例。
那么，如何使用探索式场景联想法衍生测试用例呢？
由上一节可知，测试用例是指导测试人员在xx预知条件（场景）下，执行xx步骤，预期得到xx结论。
显而可见，通过改变测试用例的预知条件和操作步骤，则可以衍生出不同的测试用例。而这些测试用例包含不同的测试场景和不同的测试步骤。
如下图3所示，为探索式场景联想法衍生测试用例的结构脑图。
改变前置条件
测试用例的前置条件基本包括：硬件资源和软件系统两个部分。
改变前置条件可以从这几方面入手。
以上节的访问 http://www.baidu.com 链接用例1为例，改变前置条件衍生新的测试用例。由于该用例的前置条件较简单，改变前置条件只需改变浏览器类型和版本即可。
由此，衍生的部分测试用例可如下所示：
改变操作步骤
改变用例操作步骤可以从以下几方面入手：插入步骤、删除步骤、改变步骤和重复步骤。
插入步骤
如图3所示，插入步骤又可以分为插入相关联步骤和不相关联步骤。并在插入步骤中增加用户输入。
同样以用例1为例，插入步骤衍生的测试用例可如下：
删除步骤
删除步骤可以分为删除部分步骤或者删除部分步骤中的部分操作。删除部分步骤，又可以分为删除关键步骤和非关键步骤。
例如，以例1为例，删除关键步骤“点击键盘回车键“衍生新的测试用例如下所示：
改变步骤
改变步骤主要涉及步骤顺序的改变和步骤内容的改变。当测试用例具有多个步骤，且步骤间具有关联性和顺序性的时候，改变步骤顺序则会变得很有意义。改变步骤内容主要是改变步骤中用户的输入（包括数据输入、用户操作等）。
以用例1为例，改变步骤内容衍生的用例如下所示：
重复步骤
对于大多测试人员来说，衍生测试用例时更多关注点在于操作步骤的变化。
但是，对于不同的测试场景，重复相同的测试步骤，仍然具有很大的测试意义。重复步骤进行测试能够挖掘不同前置条件（场景）下的故障，亦能挖掘软件在多个重复步骤操作下潜藏的故障。
以用例1为例，重复步骤衍生的用例如下所示：
测试结论衍生测试用例
除了通过改变前置条件和操作步骤衍生测试用例外，还可以根据测试结论中的异常信息，逆推测试场景，衍生新的测试用例。
这个部分更多的需要测试人员掌握探索式测试方法，对测试过程中的软件资源监控信息、错误日志等保持警惕性，挖掘错误信息中的内容，逆推产生错误信息的原因，构建新的测试用例。
小结
本文阐述了一种可以在提交测试故障信息和验证测试故障时使用的快速测试用例编写模板，快速记录测试场景、测试步骤等关键信息。
并在此基础上，简单讲解了基于探索式场景联想法的测试用例衍生方法，可以帮助测试人员借助已有的测试用例拓展新的测试用例，扩大测试范围，提高覆盖率，挖掘更多场景下的软件故障。
转自公众号投稿： https://mp.weixin.qq.com/s/tPB9qhbaKoJX9LhcJDP3eg
好的测试用例标准：
质量属性：
l正确性：确保测试标题描述部分的内容正确性。
l经济性：只为确定需要的目的设计相应的测试步骤。
l可重复性：自我一致性，即不管谁执行此用例，结果一样。
l适应性：既能适应短期需要，又能考虑长远需要。
l可追踪性：用例能追踪到一个具体的需求。
l自我清理性：单个用例不会影响整个测试环境，即用例执行完了可以恢复原有的测试环境。
l结构化和可测试性
l含有规范的测试标题和编号。
l含有一个确定的测试某一个特定需求的目的。
l含有关于测试方法的描述。
l指定条件信息-环境、数据、预置的条件测试、安全入口等。
l含有操作步骤和预期结果。
l陈述任何辅助证据，例如截图报告并确保这些东西妥善保存。
l确保测试环境的干净（即用例不会影响整个环境）。
描述时使用主动语气结构。
l操作步骤不要超过15步。
l确保单个用例测试执行时用时不超过20分钟。
l自动化脚本用例添加必要的注释，比如目的、输入和期望结果。
l如果可能，建议提供可选择性的预置条件测试。
l用例之间的先后顺序是否跟业务流程一致，即用例在业务流程中的彼此顺序关系是否合理。配置管理：
l采用命名和编号规范归档。
l保存为特定的格式，文件类型。
l用例版本是否与当前被测试软件版本一致（对应）。
l包含用例需要的相应测试对象，如特定数据库。
l存档阅读。
l存档时按角色控制访问方式
l当网络备份时存档。
l离线归档。
这是我在优就业学习时总结的，希望对你有用
本文涉及到测试用例的编写规范，以及用例管理的分享，因此，无论是对于初级测试工程师，还是质量团队的管理者，都有一定的参考意义。文中涉及到的方法和工具并不是唯一解决方案，希望大家收获到的不仅仅是文字表面，而是文中分享的一些思路。
有人说：测试用例还不知道？不就是描述测试步骤吗？
这么回答确实没什么错，只是如果内心上也仅仅这么认为的话，只能说并未理解测试用例。
测试用例除了作为测试行为的描述，更多的是作为被测目标是否达到需求的验证，主要还是考验了一个测试工程师的组织归纳能力，其输入来源往往是承诺书、用例(Use Case) 以及自身对业务领域知识的经验，一个软件测试工程师的专业度往往体现在他设计的测试用例上。
专业的工程师设计出的测试用例集，不仅能够描述自己的行为，还能指导别人实施，不仅强调深度，还具有优秀的用户思维。
虽然从格式上来说，基本就定型了：
关于这部分，网络上的教程只多不少，就不赘述了。
只不过要强调的重点是， 格式只能保证测试用例明晰，并不能提升测试用例的设计能力。因此，测试用例该怎么写？还是要从结构化设计开始。这里需要提到一个概念 HLTD [ High Level Test Design ]，可以简单粗暴的理解为测试大纲的设计。
就如同我们写文章一般，提笔正文之前，会先拟个草稿，列出中心思想及段落提纲，然后再攥写润色。
写测试用例也是类似的套路，先列出测试点作为大纲，并且具有结构化布局。通常以大的功能或模块进行分类，再细化二级甚至三级类别，最终列出具体的测试点。该阶段的设计，笔者倾向于利用思维导图（脑图），相较于传统的文档软件工具，思维导图的展现更直观。
由于最终会是一张大图，所以硬伤也随之体现，只适合用于思路梳理，不适合用于文档化管理。
把这些结构化好的测试点文档化，就是我们所说的测试用例了。
所以从这里我们可以看出，每一条测试用例的目的很明确，是验证一个或一类测试点，颗粒度需要根据公司实际情况权衡，太粗不利于对于测试点覆盖的总结，拆太细会消耗更多的精力。
测试用例其实是一个非常详尽的文档，必然会消耗测试工程师相当一部分的精力。在传统软件开发时代，甚至作为 KPI 的一项指标。
但随着敏捷时代的兴起，有一种声音开始冲击这种认知。
早期的敏捷实践者，对敏捷宣言的解读仅仅停留在了文字表面，认为“只需要软件，不需要文档”。这直接导致了这一时期，大量的团队缺失了详尽的文档，甚至连一些基本的文档都没有。
如今，越来越多的敏捷实践者认识到，敏捷宣言所宣扬的并不是“不用详尽的文档”，恰恰相反， 敏捷宣言认同了“详尽的文档很重要”这件事，并且提出了更高的要求 —— “工作的软件更重要”
对于测试用例文档化工具的选择，很多团队仍然停留在传统的办公软件，如 Word、Excel
但如今凡事比快的市场环境下，团队成员高效协作、团队信息实时共享的需求越来越高，测试用例平台化管理必然还是最终归属，除了文档化，还利用平台制定计划，展示进度和结果。
事实上，在传统时代，大一些的软件公司就已经使用平台来管理测试用例了，这再一次证明了敏捷时代并不意味着推翻过去的经验和成果，而是提出了更高的要求。
如今，相对知名的管理平台有基于 Jira 做插件的，如：Zephyr、Xray、synapseRT、TM4J，也有独立的开源平台: 如：Testlink，或收费的独立平台: 如：TestRail
我们主要从其生态、推行成本、可扩展、费用角度去综合考虑。
Zephyr 的名气一直都很大，但实际上并不太符合国人使用的习惯，使用起来诸多不便。用例直接使用 Jira issue，功能比较简单，用例管理主要在计划和循环的关联上。由于其是 Jira 插件，因此能很好的跟 Jira 上其他 issue (需求、任务、缺陷) 进行关联。但其用例管理的可视化不是很好，没有用例集的概念。迁移方面，数据导入支持类型有限。扩展方面，若要使用其 API，还需要另外装一个插件。其费用中等。
Xray 算中规中矩，也是使用 Jira 的 issue 来创建测试用例。但其新增的 issue 类型多达 5 类，显得极其复杂。关联能力与 Zephyr 相同，数据导入支持类型有限，本身有 API 可供使用。其费用中等。
synapseRT 是国人开发，汉化效果最好，功能强大。有用例集的概念，用例也是用的 Jira issue 来扩展。数据导入支持了 Testlink、Zephyr 这样的其他平台。关联能力同 Zephyr，数据导入支持类型依旧有限，其本身也有 API 可使用。而费用相对较低。
TM4J 使用独立页面管理测试用例，脱离复杂的 Jira issue 页面，上手难度低。数据导入功能强大，覆盖很多类型及一些知名平台。关联能力与上述插件一致，本身也有 API 可使用。但费用相对较高。
Testlink 作为独立的测试管理平台，功能全面，开源免费。可以关联 Jira 这样的知名平台，但由于不是 Atlassian 体系，所以生态体验不高。硬伤是界面丑陋，容易影响工程师的心情。笔者曾经使用其本身的 API 进行 UI 美化。
TestRail 是一个强大的商业平台，笔者接触不多，不乱作评论。
综合考虑，虽然 Testlink 作为免费开源用例管理平台中的 TOP，在用例管理上做得非常科学，一直值得学习，但笔者所在公司已经在使用 Jira，并在落地 DevOps，外加笔者常受 Atlassian 中国社区研究院副院长的支持，TM4J 成为最终选择：
出品方还是挺强的，除了 TM4J，Zephyr 其实也是其下产品，Swagger 也已经是目前认知度很高的产品了。
从官网介绍上可以看出，TM4J 还是比较现代化的：
首先我们看看利用 TM4J 如何来编写测试用例。
层级结构上，我们根据 HLTD 来创建目录以及子目录，以方便所有人理解和阅读，最后的测试点则实例化为一个测试用例，它拥有全局唯一的 Key。
点击 New 按钮创建新测试用例，默认在 Details 标签页，在这里定义用例名称、目的、前提条件，详情中可以设置状态、优先级、所属组件，并可以添加一些便于管理的标签。
切换到 Test scripts 标签页，默认是 Step-by-Step 类型，按照 STEP - TEST DATA - EXPECTED RESULT 添加每一个测试步骤。
另外值得一提的是，在 Traceability 标签页，可以关联 Jira issue、Confluence page
通常我们针对每次产品发布交付，需要制定范围，因此计划管理是必不可少的。
计划管理推荐按照发布版本来制定顶层目录，然后针对测试类型创建二级目录，如回归、新功能、端到端、接口、性能等等。
测试计划的创建本身操作倒并不复杂，除了定义计划名称、目的、状态、责任人，外加一些标签。
还需要关联一下需求或者 Confluence 页面。测试周期在刚创建测试计划的时候可能并不存在，可以在之后创建测试周期的时候，会双向关联。
测试周期是一个承上启下的关键，往上关联测试计划，往下关联具体的测试用例。
通常一次发布交付会经历 3-5 次冲刺，每轮冲刺的范围不一定完全相同。
在新建完测试周期名称、描述以及详情之后。
进入 Test Cases 标签页，点击 + Add test cases 添加已经编写好的测试用例。
这一步操作使得测试用例具备了项目属性。
最后在测试周期的 Traceability 标签页点击 Test Plans 后面的放大镜。
通过查找来关联已经做好的测试计划。
创建完测试周期，就可以进入该周期浏览到分配到自己名下的测试用例了，这是所有测试执行者都需要用到的界面，还可以通过 Group by 根据不同规则进行归类，比如根据测试周期中制定的不同目录。
对于用例步骤的执行，TM4J 提供了一些快捷按钮，可以直接标记通过、失败、阻塞，并且可以点击齿轮按钮，快速创建、查找 Jira issue 进行关联，当然，除了对于步骤关联 issue，也可以针对该用例标记 issue，点击 Issues 后面的 + ▼ 可进行操作。统一平台的好处便是在此了。
虽然我们在查看测试周期列表的时候可以看到测试的进度，但更多数据展示可以通过测试报告来体现。
TM4J 的 Reports 功能给我们提供了丰富的模板，方便一些经验不足的测试质量管理者。
最后，笔者想说， 测试工作不能作为一个独立的业务，应该更多的与其他角色协作 ，特别是在现在的敏捷时代，测试用例的执行可以要求开发工程师关注，测试的状况可以要求产品经理随时介入，因此，强烈建议我们软件测试工作者尽量选择一些跨职能协作平台。
测试分析报告：
1、编写目的：说明这份测试分析报告的具体编写目的，指出预期的阅读范围。
2、测试概要：用表格的形式列出每一项测试的标识符及其测试内容，并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别，说明作出这种改变的原因。
3、测试结果及发现：把本项测试中实际得到的动态输出（包括内部生成数据输出）结果同对于动态输出的要求进行比较，陈述其中的各项发现。
4、对软件功能的结论：简述该项功能，说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。说明测试数据值的范围（包括动态数据和静态数据），列出就这项功能而言，测试期间在该软件中查出的缺陷、局限性。
测试原则
对计算机软件进行测试前，首先需遵循软件测试原则，即不完全原则的遵守。不完全原则即为若测试不完全、测试过程中涉及免疫性原则的部分较多，可对软件测试起到一定帮助。
因软件测试因此类因素具有一定程度的免疫性，测试人员能够完成的测试内容与其免疫性成正比，若想使软件测试更为流畅、测试效果更为有效，首先需遵循此类原则，将此类原则贯穿整个开发流程，不断进行测试，而并非一次性全程测试。
以上内容参考：百度百科-软件测试
以上就是各种测试用例简要模板的全部内容了，但愿对大家有所帮助。
温馨提示：
微信扫码关注公众号
获取更多考试热门资料
