😏作者简介：博主是一位测试管理者，同时也是一名对外企业兼职讲师。
📡主页地址：【Austin_zhai】
🙆目的与景愿：旨在于能帮助更多的测试行业人员提升软硬技能，分享行业相关最新信息。
💎声明：博主日常工作较为繁忙，文章会不定期更新，各类行业或职场问题欢迎大家私信，有空必回。

 
 

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设计，相信专业的测试同学心中都已经有了一个答案。

  我们在设计用例时必定会加入正例和反例，正例的作用是覆盖所有被测对象的预期功能是否正确，反例则不同，它必须照顾到用例的全面性，和覆盖率不同，它是基于一些错误的场景来对软件进行额外的功能尝试。举个例子，我们平时说的比较多的等价类设计方法，其中就分为有效等价类与无效等价类，而无效等价类就是反例设计的最好体现，也是我们日常最容易想到的反例。那么是否所有的用例都需要设计反例呢？这个命题从字面上来看是不是就已经错了。下面我们就来举几个场景，通过这些我们就可以提取出设计反例的时机：

1 被测对象中使用频率高或者较高的功能
2 被测对象中业务逻辑复杂的功能
3 被测对象中相对独立的功能
4 被测对象中开发耗时较长的功能
5 被测对象中主打、特色的功能
6 被测对象中如果出错将导致严重损失的功能
7 被测对象中开发比较担心的功能

  测试用例的描述一定要言简意赅，千万不能拖沓，最好也不要用大白话。所以对于软件测试的同学来说，文字功底优秀那当然最好，但如果不是，那至少要扎实，用不来可以不用，可以查，但千万别乱用。在一个团队中，迭代版本或老功能进行交叉测试的几率还是挺高的，此时你的用例是否可以被高效的执行，描述的完整与准确程度就成了一个决定性的因素。虽然说起来是老生常谈，但往往却被很多测试同学忽视，除了对产品本身的业务熟悉与否，另外一个就是对于行业内的专业术语是否有准确的认识，如果本身对被测对象中的一些描述有异议可以尽早在团队中做讨论，以统一大家的认知。举个例子，在一个创建信息的界面中，在信息输入框内填入对应信息，点击保存按钮，这时会弹出一个确认窗口。那么这个窗口的名称就会出现各种各样的叫法，有的叫“弹窗”，有的叫“确认窗口”，有的叫“二次确认窗口”，如果在没有统一的情况下，用例中的描述就很容易出现偏差，导致其他测试同学执行时候的效率低下。

  测试用例之间不能有依赖，一条用例应该是验证被测对象某个业务中的单个功能点是否符合需求设计的，切不可将多个功能点加入一个测试用例中以用来验证一连串的业务操作是否正确。因为后期如果测试用例中有某些条件依赖或高耦合，会导致用例的复用率降低，在UI自动化、回归和冒烟测试中，我们就无法将优先度高的用例抽出进行组合来执行对应的测试任务。

  同一产品的测试用例适当做“减法”，随着版本的不断迭代，我们的黑盒测试用例数会随之增多，当达到一定的规模之后日常管理的成本与消耗就会变得越来越大，除了定期对已有的测试用例集做瘦身、转化（删除无效用例，已稳定的功能相关用例可转化为自动化测试用例）之外，我们在设计用例之初就应该本着高效的理念，遵循上面几点所说的来进行处理，非必要时绝不进行全量设计，哪怕是靠近全量的大范围覆盖测试用例设计。有不少的软件测试同学总会觉得设计用例时生怕会漏下任何一点或使用场景，尽可能多的组合与排列各类条件，创造出了大量可能存在类似、重复或低效的测试用例。大家都知道穷尽测试是不可能的，也完全没有必要去纠结会发生一些意想不到的问题，作为软件测试的执行者来说，我们首要保证的是被测对象的功能是否完全满足原生需求，是否可以解决用户提出的痛点。

  基于上面的“减法”观点，另一点需要我们注意的是，如果你是初入测试行业的同学，建议在测试用例设计完成一小部分的时候让团队内的业务专家或测试老鸟看下你的用例，这样做的好处在于他们一般都会告诉你用例可能存在的问题和团队内部的设计风格大致是什么样的，也方便及时纠正错误的设计方向，避免大量的重复返工动作。

  测试用例中还有一个因素也是比较容易被忽略的，那就是前置条件，有部分软件测试的同学觉得没有前置条件貌似也不会影响测试任务的进行。但这里有一个很大的误区，测试用例一般都不是一次性的，经常会有交叉执行、冒烟测试、后期提炼、复用重构的场景存在，甚至在很长的一段时间之后，那些执行过的测试用例将会再一次被提取出进行测试活动。那么在这样的场景下，一个明确的前置条件就变得极为重要了，如果没有了前置条件或前置条件比较潦草，就会导致再次执行用例的时候出现失败的情况，甚至需要花费大量的时间去回忆与调查问题出现的原因，往往大呼得不偿失。

  最后，一切从用户角度出发，这不是一句空话，无论是设计用例还是测试执行过程中皆是如此。我们需要了解当前测试活动的背景，我们的客户是什么样的人群，高频的使用场景是怎样的，我们的新功能是否可以更好的解决客户的当前痛点（需求）。我们除了在设计用例时适当的用上八大设计方法之外，更多的还是需要换位思考，如果我是客户的话会如何考量当前的UI、功能体验？如果测试同学仅仅只是坐在自己的工位上YY自己是客户的话，那最多也只是自欺欺人而已，在日常的工作过程中，我们是否可以向销售、产品、售前售后人员进行必要的客户特征信息收集，甚至与相关人员访问客户、做对应的调查问卷，这些必要的动作都是需要测试人员去完成的，不然凭什么说测试可以站在客户的角度对产品进行测试，提出中肯而又专业的修改建议？当软件测试同学真正的掌握了客户的画像与特征信息后才能够在用例的设计工作中创造出针对性极强的高效用例，而不是一纸空谈。

 
 

4. 后续预告

  由于篇幅关系，关于影响黑盒测试用例的设计因素大致就写这些，博主一直不提倡把一些观点洋洋洒洒写个几万字，技术文章一般都比较短小，方便大家阅读。文章内的这些观点也是博主日常对团队内成员的真实要求，毕竟测试用例设计的是否优秀高效也是大家作为测试从业者的核心竞争力之一。还有一点比较重要的就是坚持，如果你也想提升自己的用例设计能力，不妨在日常工作中多多的刻意练习，这个与环境无关、与旁人无关、与任何借口都没有关系，重点就在于你的动机与目标是否值得你驱使自己真正的动起来并坚持下去。

  年后还会更新一篇关于自动化测试用例设计的文章，同样的，如果大家有任何想看的内容也可以留言或私信，有空都会逐一更新。