住房城乡建设部官方网站百度广告优化

住房城乡建设部官方网站,百度广告优化,做外贸在什么网站上比较好,黄页88标题生成器现在很多文章都有介绍如何使用测试框架来测试#xff0c;但只介绍工具如何使用#xff0c;却不介绍如何从研发角度设计测试用例#xff0c;写出来的单测往往很难维护#xff0c;看上去就只是为了维持kpi而已。 测试用例设计的MECE原则 测试用例设计有很多经典的方法…现在很多文章都有介绍如何使用测试框架来测试但只介绍工具如何使用却不介绍如何从研发角度设计测试用例写出来的单测往往很难维护看上去就只是为了维持kpi而已。测试用例设计的MECE原则测试用例设计有很多经典的方法比如等价类划分法、边界值分析法、错误推测法等。这些测试方法提供了设计的思路但是却没有说明如何评判测试用例是否已经设计完全。评判测试用例有没有设计完全是确保业务逻辑bug-free的关键。因此我们在设计测试用例时需要确保测试用例设计遵循MECE原则。测试用例设计遵循MECE原则指的是对测试用例进行分类时分类应该是互斥Mutually Exclusive且完备Collectively Exhaustive的。将测试用例根据MECE原则进行分类可以更好地帮助我们设计出符合需求的测试用例从而更好的保证软件质量。下面就以排队需求作为例子说明测试用例设计是如何满足MECE原则的。有消费者、队列组、队列、任务四种角色其关系如下有一批队列在每个队列中都有一批任务不同的队列可以组成队列组消费者可以订阅不同的队列组。在消费者消费队列中的任务时需要按照订阅关系和一定的规则消费队列中的任务。在消费任务时每个任务都可能对应多个消费者当其中一个消费者忙碌时需要自动分配给下一个消费者。另外因为一个消费者可以同时订阅多个队列组所以需要从多个队列组里选取一个任务出来进行消费。其消费规则如下所示消费规则文字详述如下如果专属队列有任务则从专属队列中选择排队时间最长的任务如果专属队列无任务VIP队列中有任务则选择VIP队列中的任务对VIP队列中的任务按队列优先级进行排序选择优先级最高的队列如果优先级最高的队列只有一个则从该队列中选择排队时间最长的任务如果优先级最高的队列有多个则从这多个队列中选择排队时间最长的任务如果专属队列无任务VIP队列中无任务则选择非VIP队列中的任务对非VIP队列中的任务按队列优先级进行排序选择优先级最高的队列如果优先级最高的队列只有一个则从该队列中选择排队时间最长的任务如果优先级最高的队列有多个则从这多个队列中选择排队时间最长的任务在上篇文章中引入了订阅组的概念如图所示一个消费者订阅的所有队列组组成一个订阅组不同消费者的订阅组可能是不一样的用一张图简单表示这种关系要先分析清楚复杂的问题首先要做的就是按一定的标准分解问题将问题的规模变小变成一个个子问题然后逐个解决最终就解决了整个复杂的问题。分类的方法有很多但是无论使用哪种方法需要确保的是按某种标准分解问题之后子问题之间是相互独立的不存在任何依赖的且分解后的n个子问题最终也可以组合成原始的问题不至于会漏掉某些可能的情况。这样分解问题才满足MECE原则。如果分解问题后不满足MECE原则那必定会存在遗漏测试用例的情况或者有重复测试用例的情况如果在后续设计的时候发现有这样的问题那可能就要重新回过头来确定分解的标准了。在这个需求中我会将这个复杂需求按这样的标准进行分解订阅了同一订阅组的消费者消费任务订阅了不同订阅组的一类消费者消费任务为什么这样分解就能满足MECE原则因为对于整个任务消费情况来看只有订阅了同一订阅组和订阅了不同订阅组这两种情况不可能存在订阅的订阅组既相同又不同的情况。这样就是满足MECE原则的问题分解。订阅了同一订阅组的消费者消费任务对于这种情况其实就是从一个订阅组内选择一个任务出来分配给订阅了这个订阅组的消费者。所以问题就转化成根据消费规则选择订阅组内的任务时如何满足MECE原则。其实这里的用例的设计已经在上面的需求描述里给出来了此处再列出来这样分解为什么是满足MECE原则的呢在这个比较规则中比较的顺序是按 队列类型选择、优先级队列选择策略、任务选择策略 这三种策略依次比较下来的。这几种策略是根据既有的需求分类得来的相互之间没有重叠的情况所以在策略的分类上是满足MECE原则的。然后对于每一种选择策略其分支的组成都是互斥且完备的比如队列类型选择策略中VIP队列只存在有任务和无任务两种互斥的情况不可能存在既有任务又无任务的可能性所以这样的用例设计就能覆盖到所有的情况。我们可以用这样的标准去审视每一种策略看看是否都满足MECE原则如果都满足那么这样的分类就能确保你不会遗漏任何一种情况。订阅了不同订阅组的一类消费者消费任务订阅了同一订阅组的消费者消费任务是比较流程化的用思维导图就可以比较方便地梳理出来。但是像订阅了不同的订阅组的消费者用思维导图就不太好分析出来了。这个时候我们可以稍稍运用一些基础的数学知识集合。试想一下我们会如何表示一个消费者订阅了哪些队列组比如消费者 C1 订阅了队列组 QG1, QG2那我们会这样表示: C1: {QG1, QG2}如果是消费者 C2 订阅了队列组 QG2, QG3那就会这样表示C2: {QG2, QG3}。这样消费者C1和C2订阅的队列组之间就形成了交集相交的队列组就是QG2。从这个角度去思考对于订阅了不同订阅组的一类消费者消费任务的情况就变成了考察如何穷举两个集合之间的关系了。从以往学过的简单的数学知识就可以知道两个集合之间的关系无非就是 子集、全集、交集、无交集 这四种情况。因此我们可以用韦恩图来表示集合之间的关系从这个图里我们以消费者C1作为考察对象则其他消费者的订阅组和C1之间的关系是C2 的订阅组是 C1 订阅组的子集C3的订阅组是C1订阅组的全集C4订阅组和C1订阅组的交集是 {QG2}C5订阅组和C1订阅组之间无交集。这样我们在写测试用例代码时从消费者的编号和队列组的编号就知道只需要用5个消费者和4个队列组就可以穷举所有的情况。而且这几种情况都是相互独立又完全穷尽的。再论先写代码还是先写测试在前面一篇文章中讨论了究竟应该先写代码还是先写测试在这里想结合这个需求再强调一下其实先写哪种都没有关系关键是要先设计测试用例。在这个需求例子中经过这一轮分析即使你没有写一行代码通过对测试用例的设计你也对最终要实现成什么效果已经了如指掌。甚至你可以在不写一行实现代码的情况下就可以把对应的测试用例代码写出来。当然不是说要一下子把所有的用例都写完而是用TDD的方式先写一个测试用例的代码然后再写这个测试用例对应的实现代码测试通过后再实现下一个测试用例。其实设计测试用例的过程就像是一种直观的方式来写测试用例代码的过程如果你之前认为先写测试再写实现这样的开发模式有点违反“常识”不妨试试在开发之前先对着需求按MECE原则设计出测试用例然后再去写测试用例代码或者去写实现代码你就会发现TDD方式的开发模式是非常合理且顺畅的。而现实中有很多人都认为TDD并不符合实际开发过程。但其实这篇文章介绍的测试用例设计方法和设计过程就是在做着TDD开发模式中的一个至关重要的环节任务拆分tasking。无法很好地实践TDD本质上不是因为这种方式违反常识而是因为开发者在开发之前无法很好地理清需求并做好任务拆分以致于在模仿TDD的形式时遭遇到了挫败感而忽略了TDD最核心的部分-任务拆分。所以在之前的文章中我也说过先写测试或先写代码其实都不重要重要的是要先按MECE原则设计出测试用例其实也就是要按照MECE原则做好任务拆分这样无论你是先写实现还是先写测试或者是用其他的方式实现只要最终实现的效果是符合事先设计好的测试用例的预期的那对产品最终的质量就会有了保障。总结在这个需求中运用了MECE原则设计测试用例在实际开发中的确做到了这部分业务逻辑0bug。希望这篇文章能给大家一点启示测试用例的设计过程本质上就是在做任务拆分。对复杂需求的测试用例要实现对应的测试用例代码对于前置条件的构造也很麻烦。这部分就留待下一篇文章解决了。最后作为一位过来人也是希望大家少走一些弯路在这里我给大家分享一些软件测试的学习资料和我花了3个月整理的软件测试自学全栈这些资料希望能给你前进的路上带来帮助。​视频文档获取方式这份文档和视频资料对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你以上均可以分享点下方小卡片即可自行领取。