微服务中的测试

新的挑战 微服务和传统的单块应用相比,在测试策略上,会有一些不太一样的地方。简单来说,在微服务架构中,测试的层次变得更多,而且对环境的搭建要求更高。比如对单块应用,在一个机器上就可以setup出所有的依赖,但是在微服务场景下,由于依赖的服务往往很多,要搭建一个完整的环境非常困难,这对团队的DevOps的能力也有比较高的要求。 相对于单块来说,微服务架构具有以下特点: 每个微服务在物理上分属不同进程 服务间往往通过RESTful来集成 多语言,多数据库,多运行时 网络的不可靠特性 不同的团队和交付周期 上述的这些微服务环境的特点,决定了在微服务场景中进行测试自然会面临的一些挑战: 服务间依赖关系复杂 需要为每个不同语言,不同数据库的服务搭建各自的环境 端到端测试时,环境准备复杂 网络的不可靠会导致测试套件的不稳定 团队之间的沟通成本 测试的分层 相比于常见的三层测试金字塔,在微服务场景下,这个层次可以被扩展为5层(如果将UI测试单独抽取出来,可以分为六层)。 单元测试 集成测试 组件测试 契约测试 端到端测试 和测试金字塔的基本原则相同: 越往上,越接近业务/最终用户;越往下,越接近开发 越往上,测试用例越少 越往上,测试成本越高(越耗时,失败时的信息越模糊,越难跟踪) 单元测试 单元测试,即每个微服务内部,对于领域对象,领域逻辑的测试。它的隔离性比较高,无需其他依赖,执行速度较快。 对于业务规则: 商用软件需要License才可以使用,License有时间限制 需要License的软件在到期之前,系统需要发出告警 @Test public void license_should_expire_after_the_evaluation_period() { LocalDate fixed = getDateFrom("2015-09-03"); License license = new License(fixed.toDate(), 1); boolean isExpiredOn = license.isExpiredOn(fixed.plusYears(1).plusDays(1).toDate()); assertTrue(isExpiredOn); } @Test public void license_should_not_expire_before_the_evaluation_period() { LocalDate fixed = getDateFrom("2015-09-05"); License license = new License(fixed....

October 1, 2016 · 2 min · 邱俊涛 | Juntao Qiu

敏捷团队里的QA

QA的职责 我们先讨论一下传统的瀑布模型下QA是如何工作的,其中最主要的问题是什么;然后作为对比,我们来看看在敏捷团队里QA又是如何工作的,工作重点又是什么;最后,我们详细看一看在新的职责下,QA应该如何做。 瀑布开发模型 即使在今天,在很多企业中,瀑布模型仍然是主流。每一个需求都需要经过分析,设计,开发,测试,上线部署,运维等阶段。虽然一些企业已经在实施敏捷开发,比如项目/产品以迭代的方式运作,也有诸如每日站会,代码检视等敏捷实践,但是如果仔细审视,你会发现其实开发模式骨子里还是瀑布:按照软件组件划分的部门结构(详见康威定律),按照职能划分的团队(开发和测试分属不同部门),过长的反馈周期,永远无法摆脱的集成难题等等。 随着软件变得越来越复杂,团队里没有任何一个人可以说出系统是如何运作的,也不知道最终用户是谁,以及最终用户会以何种方式来使用最终的软件。 更糟糕的是,按照职能划分的团队在物理上都是隔离的,比如独立的测试部门,独立的运维部门,整日忙碌而难以预约到档期的业务人员,当然还有经常疲于交付,无处吐槽的苦逼开发。由于这些隔离,信息的反馈周期会非常长,一个本来很容易修复的缺陷可能在4周之后才可能被另一个部门的测试发现,然后通过复杂的工作流(比如某种形式的缺陷追踪系统)流到开发那里,而开发可能还在拼命的完成早就应该交付的功能,从而形成恶性循环。 瀑布模式中的QA 在这样的环境中,QA们能做的事情非常有限。在需求开始时会他们参加需求澄清的会议,制定一些测试计划,然后进行测试用例的设计。有的企业会用诸如Excel之类的工具来记录这些用例。这些写在Excel里的,死的用例用处非常有限。而最大的问题在于:它们无法自动化执行。另外,在实际软件开发中,需求总是会经常发生变化,需求的优先级也会有调整,然后这些记录在Excel中的死的用例会很快过期,变得无人问津。 除此之外,QA中的有些成员会使用工具来录制一些UI测试的场景,然后在每个新版本出来之后进行回放即可。然而,当UI发生一点变化之后,这些自动化的用例就会失效:比如HTML片段中元素位置的调整,JavaScript的异步调用超时等等。 显然,这种单纯以黑盒的形式来检查功能点的测试方式是不工作的,要真正有效的提升软件质量,仅仅通过事后检查是远远不够的,软件的质量也应该内建于软件之中。QA的工作也应该是一个贯穿软件生命周期的活动,从商业想法,到真实上线,这其中的所有环节,都应该有QA的参与。 系统思考 如果不从一个系统的角度来思考软件质量,就无法真正构建出健壮的、让业务和团队都有信心的软件系统。质量从来都不只是QA的职责,而是整个团队的职责。 关于软件质量,一个根深蒂固的误解是:缺陷在开发过程中被引入,然后在测试阶段被发现,最后在QA和开发的来来回回的撕扯中被解决(或者数量被大规模降低),最后在生产环境中,就只会有很少的,优先级很低的缺陷。 然而事实上,很多需求就没有仔细分析,业务价值不很确定,验收条件模糊,流入开发后又会引入一些代码级别的错误,以及业务规则上的缺陷,测试阶段会漏掉一些功能点,上线之后更是问题百出(网络故障,缓存失效,黑客攻击,操作系统补丁,甚至内存溢出,log文件将磁盘写满等等)。 在一个敏捷团队中,每个个人都应该对质量负责,而QA则以自己的丰富经验和独特视角来发掘系统中可能的质量隐患,并帮助团队将这些隐患消除。 我在ThoughtWorks的同事Anand Bagmar在他的演讲What is Agile testing- How does automation help?中详细讨论过这部分内容。 QA到底应该干什么? 本质上来说,任何软件项目的目标都应该是:更快地将高质量的软件从想法变成产品。 将这个大目标细分一下,会得到这样几个子项,即企业需要: 更多的商业回报(发掘业务价值) 更快的上线时间(做最简单,直接的版本) 更好的软件质量(质量内嵌) 更少的资源投入(减少浪费) 其实就是传说中的多、快、好、省。如果说这是每一个软件项目的目标的话,那么团队里的每一个个人都应该向着这个目标而努力,任何其他形式的工作都可以归类为浪费。用Excel记录那些经常会失效,而且无法自动执行的测试用例是浪费,会因为页面布局变化而大面积失效的UI测试也是浪费,一个容易修复的缺陷要等到数周之后才被发现也是浪费。 在这个大前提下,我们再来思考QA在团队里应该做什么以及怎么做。 QA的职责 Lisa Crispin在《敏捷软件测试》中提到过一个很著名的模型:敏捷测试四象限。这个模型是QA制定测试策略时的一个重要参考: 如果按照纵向划分的话,图中的活动,越向上越面向业务;越向下越面向技术。横向划分的话,往左是支撑团队;往右是评价产品。 其实简化一下,QA在团队里的工作,可以分为两大类: 确保我们在正确的交付产品 确保我们交付了正确的产品 根据这个四象限的划分,大部分团队可能都会从Q2起步:QA会和BA,甚至UX一起,从需求分析入手,进行需求分析,业务场景梳理,这时候没有具体的可以被测试的软件代码。不过这并不妨碍测试活动,比如一些纸上原型的设计(感谢刘海生供图): 通过这一阶段之后,我们已经有了用户故事,这时候QA需要和开发一起编写用户故事的自动化验收测试。当开发交付一部分功能之后,QA就可以做常规的用户故事测试,几个迭代之后,QA开始进行跨功能需求测试和探索性测试等。根据探索性测试的结果,QA可能会调整测试策略,调整测试优先级,完善测试用例等等。 根据项目的不同,团队可以从不同的象限开始测试策略的制定。事实上,Q1-Q4仅仅是一个编号,与时间、阶段并无关系,Lisa Crispin还专门撰文解释过。 关于QA如何在软件分析的上游就介入,然后通过BDD的方式与业务分析师一起产出软件的各种规格描述,并通过实例的方式来帮助整个团队对需求的理解,ThoughtWorks的林冰玉有一篇文章很好的介绍了BDD的正确做法。如果将QA的外延扩展到在线的生产环境,制定合理的测量指标,调整测试策略,强烈推荐林冰玉写的另一篇文章产品环境中的QA。 其他职责 事实上,软件生命周期中有很多的活动,有很多处于灰色地段。既可以说是应该开发做,又可以说应该QA做,甚至可以推给其他角色(比如OPs)。不过我们知道,一旦涉及角色,人们就再也不会按照全局优化的思路来应对问题了。这种灰色的活动包括: 持续集成的搭建 测试环境的创建于维护 UAT上的数据准备 代码中的测试代码的维护 测试代码的重构 在团队实践中,这些活动我们通常会让QA和开发或者OPs同事一起结对来完成。一方面避免知识孤岛的形成,另一方面在跨角色的工作中,也可以激发出更多不同的思路。 万能的QA? 虽然在这些活动中,QA都会参与,但是并不是说团队里只要有一个QA就可以了。QA在参与这些活动时,侧重点还是有很大不同的。 比如需求分析阶段,如果有QA的加入,一些从QA角度可以发现的有明显缺陷的场景,则可以在分析阶段就得到很好的处理。另一方面,尽早介入可以设计出更合理的测试计划(比如哪些功能的优先级比较高,用户更会频繁使用,那么对应的测试比重也会更高)。在Story分析与书写阶段,QA可以帮助写出更加合理的验收条件,既满足业务需求,又可以很好的指导开发。 在和开发一起编写澄清需求时,主要是编写自动化验收测试,而不是实际编写业务逻辑的实现(虽然QA应该参与Code Reivew环节,学习并分享自己的观点);甚至在上线运维阶段,QA还需要和OPs一起来设计用户数据的采集指标(比如用户访问的关键路径,浏览器版本,地区的区分等),从而制定出新的测试策略。 扩展阅读 What is Agile testing - How does automation help?...

September 24, 2016 · 1 min · 邱俊涛 | Juntao Qiu

如何设计一个培训

培训元模式 最近在帮客户设计一个微服务进阶版培训的材料,整理的过程中我意识到这类事情我已经做过好多次了。比如在ThoughtWorks的P2能力建设项目,3周3页面工作坊等等,我觉得应该将设计课程/设计培训中的模式、原则和实践都提取一下,形成一个元模式(即关于培训的培训)。 一个培训中的活动,按照时间顺序可以分为三个步骤: 设计培训内容 培训前期准备 培训中的一些实践 设计培训内容 根据经验,只有那些正好处于瓶颈阶段,需要别人给予一些具体指导的人,培训是最有效的。比如我最近在学习iOS开发,那么用Swift开发一个Todo List应用就特别合适,而另一个基于Objective-C的自动化测试则对我来说一点用也没有(即使这个可能更高级,讲师更牛)。 在任何一个培训可能的设计之前,首先需要回答几个问题: 培训目的是什么? 参与者对主题的了解程度如何? 参与者的组成比例(比如junior占比,senior占比等) 结果如何检验? 一个例子 例子是人类的好朋友,这里我们来看一个例子: 客户要为负责开发的同事做一次培训,培训的目的是要帮助他们建立微服务架构下的常见实践的知识框架。从结果的长期效果来看,这次培训要能指导实际的开发工作。参与者对微服务的一些概念有初步了解,也做过小的练习,但是诸如如何划分服务边界,如何拆分微服务等,都不了解,也比较迫切的想要了解。 根据这个上下文,客户希望在培训中可以传递这样一些内容: 如何拆分微服务 常见的微服务设计原则 拆分微服务的时机 如何做微服务的测试 为了确保信息传递的准确性,我问了一遍上边都提到的列表,并且得到了答案: 听众是开发经验相对丰富的开发(3-5年) 学习拆分为了将大的应用拆分,以方便维护 自动化测试能力和意识都较为薄弱 听众自己的期望是可以有一些切实可以指导实际开发的收获 在有了这些输入的情况下,我做出了这样一些调整: 不专门讲拆分微服务 主要精力讲DDD(Domain Driven Design) 设计迭代式的,逐步变得复杂的场景来练习DDD 讲解和练习自动化测试(Consumer Driven Contract) Session+Workshop+讨论的形式 看了这个计划之后,客户开始觉得挺困惑,说这个怎么跟我们梳理的课程诉求不一致?对于这个疑惑,我的建议是这样的: 之前的例子不能落地(找不到足够复杂的,又适合在培训中拆分的场景) 微服务的核心不是基础设施,而是设计原则,或者说如何在开发中找出边界 有了DDD的指导,划分本身并非难事儿 自动化测试(集成测试和契约测试)的能力和认识必须建立 然后我把整理好的课件,实例分解,课程安排给客户讲了一遍之后,他觉得很满意。客户自己也是懂技术的,在分析了现状之后,后来又专门要求给部门内做一些DDD培训(而不是微服务本身)。 培训方式 同样,方式上也需要一些问题的解答才能有效进行: 培训总时长 更偏重练习还是偏重讲解(工作坊还是Session,以及各自的占比) 参与者如何投入(比如是工作时间,还是晚上等) 根据经验来看,不论是TWU还是对客户的培训,工作坊和Session结合的方式效果最好。 Workshop至少需要包含这样几部分: 明确要做的练习(多长时间,达到什么目的等) Showcase(参与感,如果有多轮的话,要保证每个人都有Show的机会,而不是每次同一个人) 讨论环节(点评,这个时机可以做一些小结,将要传递的信息润物细无声的传递出去) 应该避免的做法是:...

September 10, 2016 · 1 min · 邱俊涛 | Juntao Qiu

你需要的编程练习

高效幻象 通过对自己的行为观察,我发现在很多时候,我以为我掌握了的知识和技能其实并不牢靠。我引以为豪的高效其实犹如一个彩色的肥皂泡,轻轻一碰就会破碎,散落一地。 你可能只是精通搜索 我们现在所处的时代,信息爆炸,每个人每天都会接触,阅读很多的信息,快速消费,快速遗忘。那种每天早上起来如同皇帝批阅奏折的、虚假的误以为掌握知识的错觉,驱动我们进入一个恶性循环。 即使在我们真的打算解决问题,进行主动学习时,更多的也只是在熟练使用搜索引擎而已(在一个领域待久了,你所使用的关键字准确度自然要比新人高一些,仅此而已)。精通了高效率搜索之后,你会产生一种你精通搜索到的知识本身的错觉。 如何写一个Shell脚本 在写博客的时候,我通常会在文章中配图。图片一般会放在一个有固定格式的目录中,比如现在是2016年5月,我本地就会有一个名为$BLOG_HOME/images/2016/05的目录。由于使用的是markdown,在插入图片时我就不得不输入完整的图片路径,如:/images/2016/05/stack-overflow.png。但是我又不太记得路径中的images是单数(image)还是复数(images),而且图片格式又可能是jpg,jpeg,gif或者png,我也经常会搞错,这会导致图片无法正确显示。另外,放入该目录的原始文件尺寸有可能比较大,我通常需要将其缩放成800像素宽(长度无所谓,因为文章总是要从上往下阅读)。 为了自动化这个步骤,我写了一个小的Shell脚本。当你输入一个文件名如:stack-overflow.png后,它会缩放这个文件到800像素宽,结果是一个新的图片文件,命名为stack-overflow-resized.png,另外它将符合markdown语法的文件路径拷贝到剪贴板里:/images/2016/05/stack-overflow-resized.png,这样我在文章正文中只需要用Command+V粘贴就可以了。 有了思路,写起来就很容易了。缩放图片的命令我是知道的: $ convert -resize 800 stack-overflow.png stack-overflow-resized.png 但是要在文件明上加入-resized,需要分割文件名和文件扩展名,在Bash里如何做到这一点呢?Google一下: FULLFILE=$1 FILENAME=$(basename "$FULLFILE") EXTENSION="${FILENAME##*.}" FILENAME="${FILENAME%.*}" convert -resize 800 $FULLFILE $FILENAME-resized.EXTENSION 难看是有点难看,不过还是可以工作的。接下来是按照当前日期生成完整路径,date命令我是知道的,而且我知道它的format格式很复杂,而且跟JavaScript里Date对象的format又不太一样(事实上,世界上有多少种日期工具,基本上就有多少种格式)。再Google一下: $ date +"/images/%Y/%m/" 最后一步将路径拷贝到剪贴板也容易,Mac下的pbcopy我也会用:echo一下字符串变量,再管道到pbcopy即可: PREFIX=`date +"/images/%Y/%m/"` echo "$PREFIX$FILENAME-resized.EXTENSION" | pbcopy 但是将内容粘贴到markdown里之后,我发现这个脚本多了一个换行。我想这个应该是echo自己的行为吧,会给字符串自动加上一个换行符。Google一下,发现加上-n参数就可以解决这个问题。 好了,完整的脚本写好了: #!/bin/bash FULLFILE=$1 FILENAME=$(basename "$FULLFILE") EXTENSION="${FILENAME##*.}" FILENAME="${FILENAME%.*}" convert -resize 800 $FULLFILE $FILENAME-resized.EXTENSION PREFIX=`date +"/images/%Y/%m/"` echo -n "$PREFIX$FILENAME-resized.EXTENSION" | pbcopy 嗯,还不错,整个过程中就用了我十几分钟时间而已,以后我在写博客时插入图片就方便多了! 不过等等,好像有点不对劲儿,我回过头来看了看这段脚本:7行代码只有1行是我独立写的!没有Google的话,查看man date和man echo也可以解决其中一部分问题,不过文件扩展名部分估计又得花较长时间。 仔细分析一下,之前的成就感荡然无存。 更多的例子 我相信,过几周我再来写这样一个简单的脚本时,上面那一幕还是会出现。开发者的IDE的外延已经将Google和Stack Overflow集成了。很难想象没有这两个IDE的插件我要怎样工作。 其实除此之外,日常工作中这样的事情每时每刻都在发生: Ansible里如何创建一个给用户robot读写权限的目录? Python 3中启动简单HTTPServer的命令是? Spring Boot的Gradle String是? Mongodb中如何为用户robot授权? Gulp里一个Task依赖另一个Task怎么写? 等等等等,这个列表可以根据你的技术栈,偏向前端/后端的不同而不同,但是相同的是在Google和Stack Overflow上搜索,阅读会浪费很多时间,而这些本来都是可以避免的。...

May 26, 2016 · 1 min · 邱俊涛 | Juntao Qiu

为失败而设计

为故障和失败做设计 先来看一个笑话: QA工程师走进酒吧,要了一杯啤酒,要了0杯啤酒,要了999999999杯啤酒,要了一只蜥蜴,要了-1杯啤酒,要了一个sfdeljknesv,酒保从容应对,QA工程师 很满意。接下来,一名顾客来到了同一个酒吧,问厕所在哪,酒吧顿时起了大火,然后整个建筑坍塌了。 事实上,无论我们事先做多么详尽的计划,我们还是会失败。而且大多数时候,失败、故障都会从一个我们无法预期的角度发生,令人猝不及防。 如果没有办法避免失败(事先要考虑到这么多的异常情况不太现实,而且会投入过多的精力),那么就需要设计某种机制,使得当发生这种失败时系统可以将损失降低到最小。 另一方面,系统需要具备从灾难中回复的能力。如果由于某种原因,服务进程意外终止了,那么一个watchdog机制就会非常有用,比如supervisord就可以用来保证进程意外终止之后的自动启动。 [program:jigsaw] command=java -jar /app/jigsaw.jar startsecs=0 stopwaitsecs=0 autostart=true autorestart=true stdout_logfile=/var/log/jigsaw/app.log stderr_logfile=/var/log/jigsaw/app.err 在现实世界中,设计一个无缺陷的系统显然是不可能的,但是通过努力,我们还是有可能设计出具有弹性,能够快速失败,从失败中恢复的系统来。 错误无可避免 令人担心的错误处理 我们先来看两个代码片段,两段代码都是在实现一个典型的Linux下的Socket服务器: int main (int argc, char *argv[]) { int serversock; struct sockaddr_in server; serversock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) setup_sockaddr(&server); bind(serversock, (struct sockaddr *) &server, sizeof(server)); listen(serversock, MAXPENDING) //... } 如果加上现实中可能出现的各种的处理,代码会变长一些: int main (int argc, char *argv[]) { int serversock; struct sockaddr_in server; if (argc != 2) { fprintf(stderr, "USAGE: server <port>\n"); exit(-1); } if ((serversock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) { fprintf(stderr, "Failed to create socket\n"); exit(-1); } setup_sockaddr(&server); if (bind(serversock, (struct sockaddr *) &server, sizeof(server)) < 0) { fprintf(stderr, "Failed to bind the server socket\n"); exit(-1); } if (listen(serversock, MAXPENDING) < 0) { fprintf(stderr, "Failed to listen on server socket\n"); exit(-1); } //....

May 17, 2016 · 2 min · 邱俊涛 | Juntao Qiu