测试用例该怎么设计？—— 日常加更篇（上）_功能测试用例在意正例反例吗(2)

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

1. 写在前面的话

近两周先后经历了新冠感染、项目变动、公司内部问题等等一连串的变故，自己也不禁感叹人生世事无常，大肠包小肠😅。身边的同事和圈内朋友也经常会吐槽去年的整体形势不佳，被优化、被调岗、被转职数不胜数，哀嚎一片。好在大部分坚持下来的同行们仍旧在自己的岗位上发光发热，有时人生就像你买的股票一样，有顶峰就有低谷，你的人生课题不是如何维持你的顶峰，恰恰却是在令人绝望的低谷中如何苦苦坚持，直至你走出其中。道理谁都懂，但只有真正的经历过各自的低谷并坚持过来，才能看淡生活中的种种困难，演绎好自己的人生之路。

这里要说的还有另外一件事，之前有被同行告知到我写的文章被转载与爬取，我也饶有兴趣的看了几篇转载或爬取的文章，这不看没什么，一看就看出了不少的问题。转载这个我十分欢迎；至于爬取，我本身并不排斥，毕竟当初写这个博客的初衷就是可以帮助到更多的测试同行，但还是希望相关的爬取网站可以本着对贵站的读者负责的态度，无论是限制于爬取技术的门槛还是人为的失误，导致技术文章的内容出现瑕疵与缺失。具体网站就不点名了，这里只将对应有问题的内容进行放出，排序也没有先后。

最后这些文章毕竟不是博主凭空变出来的，该转载就请写清转载类型与出处，哪里来的底气写原创？

图中的描述后半段没了，原本还需要在maven project中查看selenium的配置情况

注释后的代码也没有，原本为Select(ele).select_by_index('0')

Appium中的控制按键与基本按键的相关参数值的两张图片也直接没有了

这原创的好有底气

这里也就不再列举其他的错误了，真的为这些爬取或手动转载的文章感到担忧，原本技术文章的属性就与普通文章不同，他们天生就具有参考价值，文章内容的缺失会令原有的文章内容的指导参考价值发生变化，从而误导读者并发生任何意想不到的反向效果。

2. 目的

我们再把话题拉回来，这次也是应粉丝的要求，加更几篇测试用例设计相关的文章。测试用例这个名词，相信各位从业者已经是熟悉的不能再熟悉了，无论你是从事何种行业，只要是软件测试从业者，测试用例始终贯穿于我们的日常工作中，今天我们就针对设计测试用例的方方面面进行一个详细的介绍。

3. 写好黑盒测试用例的因素

这里要说的设计因素不仅仅是大家熟知的测试用例的各种设计方法，很多同学都应该有类似的经历，各类设计方法虽然是很经典的测试用例设计方法，但在真实的工作中经常会因为各类的主观、客观因素导致大部分的设计方法无法投入实战。这次我们就从另外一个角度来介绍一下写好测试用例的各大因素，这些全部都是博主团队中沿用至今的指导方法，应用于实战，旨在可以让大家在其中找到一些灵感并加以改良，结合自身技能与公司现状，用于自己的团队与日常工作中。

3.1 深入理解产品业务

一定会有人反问，作为一名测试人员理解产品业务不是天经地义的事情吗？大家注意，这一观点的重点在于“深入”，何为深入？有些测试同学在编写测试用例的时候会将产品设计文档或PRD内描述的产品功能业务照样抄一遍，以陈述句的口吻作为测试用例的测试点。这样的行为无法叫深入理解，试问全公司对于产品的功能与业务最熟悉的人是谁？产品经理？项目经理？开发人员？售前售后人员？是测试！在这个点上最有底气也最能抬头挺胸说出这句话的人就是测试。除了长时间接触测试产品的各个功能点之外，整体使用与产品问题解答、缺陷的解决也造就了测试人员的这一优势。测试用例的设计也是测试人员对于产品业务理解的直接体现，如果对被测对象的业务理解片面就很容易造成测试用例的测试点错误或偏离。

这里的深入指的是千万不要被PRD文档所约束，部分测试同学无论是看PRD或者参加产品评审会时都不太会发表自己的论点与疑问，常常只是被动的接收被测对象相关的需求与业务，无法真正的站在测试人员的角度提出自己的观点。博主在制定测试团队工作流程的时候，会要求业务测试同学在项目前期加入文档测试，测试的对象就是PRD或产品设计，针对最初的原型与业务提出自己的观点。对待产品的设计文档抱着怀疑的态度去审视，告诉自己“产品的设计文档一定有问题”，以这样的潜意识去进行文档测试，你会发现这样做远远比你去熟悉产品设计文档所获得的信息要多的多，自己也从一个旁观者变成了参与者，甚至是审视者。如何做到深入呢，除了不被现有的信息与认知束缚外，另一个有效的做法就是多问自己几个为什么，无论是碰到正确的业务说明还是你认为错误的、有争议余地的业务，都值得我们去问为什么。那么这样做是不是会花费大量的时间？答案是肯定的，但我们必须去做，首先这是一个刻意练习的过程，你老是一味的接受，会发现随着工作年限的增加，多数时候自己无法顺畅地提出自己的观点；反过来说一旦善问原因的习惯养成，你会自己形成一套高效的询问机制，先问自己为什么，带着答案再去与人进行讨论，最后得到大家都能信服的答案。你会发现自己做这件事的耗时越来越短，效率越来越高，这也是我们所说的熟练工。随着时间的累积，你除了测试岗位的经验之外，你也获得了另外一种核心竞争力，那就是你的思维已经和其他人变得不同，你是积极的，独立的，不善于妥协的。

另外这样做的好处也在于我们使用了同样的时间，已经进行了一遍最初的产品测试，这个也与我们测试左移的理念高度重合。而且这样的高度参与形式也利于我们加深对产品业务的理解与印象，在设计测试用例的时候也会更加优质高效。

3.2 测试需求分析（转化）

测试需求分析指的是将产品或项目相关的需求进行转化的一种动作，大家要知道我们所获得的产品需求是无法直接进行测试活动的，产品与项目需求一般是经过专职人员（产品经理等）将原生需求进行转化的阶段性产物，我们测试人员在获取这些需求后一般会再进行一次转化，将此类需求分析转变为更具象化更符合测试活动所需的相关信息。根据公司业务与客观因素的影响，甚至会出现原生需求直接流入测试团队的现象发生，所以在各类需求状态参差不齐的现状影响下，从产品质量保障的角度下，测试需求的分析、转化就显得尤为的重要。

一般来说需求分析转化这个动作是由测试经理或测试主管来完成的，他们会将大的新功能需求或复杂业务需求进行转化、拆分，将其通过测试计划来进行工作分配，那么对应的功能模块也自然会分到各自测试同学的名下，那么接下来就是将各自的功能模块根据产品设计文档中的业务说明进行测试需求的分析与转化。这里可能会有同学听的云里雾里的，其实说的直白一点，这个动作的实际目的就是将大的需求拆成小的需求，再将小的需求转化为测试功能点。转化的效率与质量由个人对于业务与需求的理解深度、完成度来决定，这里也是和3.1中说的深入理解产品业务相呼应。

3.3 用例的呈现形式

经过了以上两步的工作之后，我们就对被测对象基本有了一个比较完整的认知与了解了。那么做过项目与完整产品的同学都知道，每一次的迭代周期都是不同的，时间、资源、要求都不会一成不变。针对这样的情况，我们的测试用例也应该有着与之相对应的呈现形式，根据以上的各个维度与对应可能出现的变化，灵活的呈现形式可以让测试活动更加的可控。

举个例子，如果一个项目是基于敏捷开发的，功能层面也不是里程碑版本，那么他的迭代周期差不多也就是1-2周的时间。这样的迭代周期在当今的互联网行业中也是普遍现状，而且高速迭代的话基本到第2周的时候测试团队就已经介入多时并开展测试活动了，开发则已经开始了下一个迭代版本（新功能）的开发，也就是说测试的第2周测试活动开始后之后也要介入下一个版本的前期项目互动中去。如果是面对这样的高速节奏，很难有充裕的时间让测试慢慢的写完完整的测试用例。

视项目与产品的时间周期而定，我们的测试用例一般会有三种类型，word、excel、xmind。这三种类型分别用来对应不同的周期长度，项目如果是高度定制化的且周期较长，我们使用word来进行充分的测试用例设计工作，每一个用例的执行步骤、预期结果、实际执行情况都会详细的描述其中，测试颗粒度也是最小的。高度定制化的项目特点就是不可复制，且项目成本与收益率比都是比较高的，这样的情况下团队可以有足够的预算来进行充足的项目开发、保障、交付工作；如果是项目周期适中，3周至1个月的小型项目，就可以使用excel来进行测试用例的设计。这种测试用例的特点是小巧、独立，因为是列表形式的，我们就不会要求在用例中存在执行的具体步骤，可以将每一条看做是一个测试功能点，因为相对之间独立、无依赖，所以也可以在多处拿来进行复用。之前也有测试同学提出过excel形式的不好管理，其实这个见仁见智，如果你真的想将此类型的用例进行管理与复用，完全可以搭配测试管理工具来进行实现，比如我们常见的禅道、testlink、Jira等等都是可以的，但这里不推荐直接使用这些工具来进行编写，一个是用例结构无法互通，复用率不高，另一个是描述与编写的复杂程度不弱于word的呈现形式，成本较高。至于像之前说的高速迭代的项目，周期一般在1-2周的那种，那就比较推荐使用xmind来进行测试用例的设计，其实与其说是测试用例，倒不如说是测试点，因为他的描述形式实在是足够简单，但简单不代表草率，能用一句话描述清楚需要测试的功能点也是测试同学都应该掌握的软技能之一。用xmind或类似的思维导图工具来进行用例设计，不仅仅可以大幅缩减编写中的时间成本，另一个优势就是他特有的展现形式，图文类的展现形式就可以有效的将你编写的测试功能点平铺在你的面前，将测试点进行图形化管理，方便查缺补漏，这个也是文档类测试用例所不能媲美的。如果团队对xmind有一定时长的使用经验，可以尝试下Xmind2testcase，这个是基于python实现的一个工具，他可以在xmind中进行测试用例的模板定制，提升我们日常工作中测试用例设计的效率与规范程度。另外它也可以将xmind中的用例转化成csv，从而导入至测试管理工具进行二次管理、复用，真正的在用例管理层面中实现闭环。

3.4 测试用例设计

这里就不再介绍黑盒测试用例的设计方法了，相信大家应该早已烂熟于心。接下去要说的是我们在日常工作中设计用例时需要注意的一些关键事项与技巧。在这一阶段，很多测试同学通常会根据自己之前做的一些准备工作来进行用例设计，都经过之前的几步准备动作了，现在还不得马上开始编写测试用例吗？博主想说的是，既然都已经做了这么多准备了，我们就更不能草率的直接进行用例的设计，其实在我们的身边也有很多的资源可以进行利用，来辅助我们的用例设计工作。

大家可别忘了测试人员并不是一个团队在战斗，我们还有被称为开发的战友。在我们开始设计用例的阶段，一般开发团队的各类设计文档都已经完善或初具雏形，这些资源也是帮助我们设计优质用例的好帮手。说几个最简单的，功能模块的详细设计或者数据库的设计文档应该都有吧，上面这两个文档就可以帮助我们更好的描述自己的测试用例，详细设计里面一般会描述功能模块的实现逻辑、数据库设计图则是支撑业务实现的所需数据结构的新增、变更等。而这些文档你需要主动的去找开发索要，因为在他们的认知中这些东西是支撑他们开发的必需品，但对测试来说则不是这样。当然以上说的这些只是最基本的一些开发设计文档，大家还是根据各自公司团队的真实情况去进行确认。

当我们开始了测试用例的设计与编写时，另一个非常重要的就是基于产品测试与质量保障的一些认知与经验了，经验这个方面比较感性，博主在此不作介绍，这里重点说一下认知。认知这个东西虽然比较抽象，但却是我们在做某些专业性工作时必不可少的重要因素之一，那作为软件测试来说，部分的产品质量保障（毕竟保障不光是测试在做，整个项目团队都是质量的保障者），测试活动本身的质量保障都是整个项目全生命周期中必须时刻谨记的目标。

这里就围绕着产品测试的一些认知问题来进行讲解，首先我们在设计黑盒测试用例时一般都会以画面为单位进行设计，那这里推荐将UI部分放在第一确认位，比起被测功能的正确实现，我们应该先确认UI的整体布局是否合理、风格是否统一，是否有错乱显示等。测试同学在执行用例时应该站在客户的角度出发，为了更好的体现这一点，设计用例的时候就更应该将这一理念加入其中，客户在接触被测产品的第一时间，他关注的是功能还是整体的UI设计，相信专业的测试同学心中都已经有了一个答案。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

sdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！