Category Uncategorized

试用这个测试框架，了解它对 JUnit 的超越 在每个现代软件包的构造阶段，测试这一实践都扮演着中心角色。过去那种先编写代码，然后有空的时候再测试（或者根本不测试）的日子已经一去不返，因为大多数开发人员现在认识到需要采用编码和测试彼此交织、同步推进的软件方法论，以便尽早发现 bug，在开发过程开始的时候就识别出主要的风险。 JUnit 超过了其他测试框架，推动开发人员理解了测试尤其是单元测试的用途。利用一个相当简单、实用、严格的架构，JUnit 已经能够“传染”大量开发人员。（有关“被测试传染”的更多信息，请参阅 参考资料。） JUnit 用户已经学会了单元测试的一些基本规则： 每段代码都必须经过测试。 只要有可能，代码的测试必须隔离进行（例如，使用像 模拟对象这样的技术 )。 软件必须容易测试 —— 也就是说， 在编写的时候要想着测试。 但是，随着开发人员对测试的信任增长，JUnit 的简单性和严格性把他们分成两个相反的派别。一方面，有些人坚信 JUnit 的简单性对于不断地提醒程序员软件也必须保持简单来说是必不可少的（这称为 KISS 原则，代表 keep it simple, stupid）；另一方面，有些人认为 JUnit 不是简单而是简化，所以他们想要从测试框架得到新的高级特性、更大的灵活性和更强大的能力。JUnit 的一些特殊特性，就是为了满足这个群体的一些具体批评而推出的： 因为 Java 语言的单继承性，所以必须扩展 TestCase类的限制很大。 无法向 JUnit 的测试方法传递参数，也无法向 setUp()和…

持续集成概述 什么是持续集成 随着软件开发复杂度的不断提高，团队开发成员间如何更好地协同工作以确保软件开发的质量已经慢慢成为开发过程中不可回避的问题。尤其是近些年来，敏捷（Agile） 在软件工程领域越来越红火，如何能再不断变化的需求中快速适应和保证软件的质量也显得尤其的重要。 持续集成正是针对这一类问题的一种软件开发实践。它倡导团队开发成员必须经常集成他们的工作，甚至每天都可能发生多次集成。而每次的集成都是通过自动化的构建来验证，包括自动编译、发布和测试，从而尽快地发现集成错误，让团队能够更快的开发内聚的软件。 持续集成的核心价值在于： 持续集成中的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量； 持续集成保障了每个时间点上团队成员提交的代码是能成功集成的。换言之，任何时间点都能第一时间发现软件的集成问题，使任意时间发布可部署的软件成为了可能； 持续集成还能利于软件本身的发展趋势，这点在需求不明确或是频繁性变更的情景中尤其重要，持续集成的质量能帮助团队进行有效决策，同时建立团队对开发产品的信心。 持续集成的原则 业界普遍认同的持续集成的原则包括： 1）需要版本控制软件保障团队成员提交的代码不会导致集成失败。常用的版本控制软件有 IBM Rational ClearCase、CVS、Subversion 等； 2）开发人员必须及时向版本控制库中提交代码，也必须经常性地从版本控制库中更新代码到本地； 3）需要有专门的集成服务器来执行集成构建。根据项目的具体实际，集成构建可以被软件的修改来直接触发，也可以定时启动，如每半个小时构建一次； 4）必须保证构建的成功。如果构建失败，修复构建过程中的错误是优先级最高的工作。一旦修复，需要手动启动一次构建。 持续集成系统的组成 由此可见，一个完整的构建系统必须包括： 一个自动构建过程，包括自动编译、分发、部署和测试等。 一个代码存储库，即需要版本控制软件来保障代码的可维护性，同时作为构建过程的素材库。 一个持续集成服务器。本文中介绍的 Jenkins 就是一个配置简单和使用方便的持续集成服务器。 Jenkins 简介 Jenkins 是一个开源项目，提供了一种易于使用的持续集成系统，使开发者从繁杂的集成中解脱出来，专注于更为重要的业务逻辑实现上。同时 Jenkins 能实施监控集成中存在的错误，提供详细的日志文件和提醒功能，还能用图表的形式形象地展示项目构建的趋势和稳定性。下面将介绍 Jenkins 的基本功能。 Jenkins 的安装非常简单，只需要从 Jenkins 的主页上下载最新的 jenkins.war 文件然后运行…

本文介绍了如何使用 Jenkins 和 TestNG 实现满足复杂测试需求的”自助式”自动化测试平台。该方案以 Jenkins 作为平台的基础，结合功能强大的插件及系统配置，部署基于 TestNG 的自动化测试包，并提供了友好的 Web 访问界面。项目成员可以在任何时间和地点，通过浏览器访问该平台，而且可以按照不同需求选择测试环境、测试集、测试用例，并提交自动化测试请求，达到真正的“自助式”自动化测试。该平台它可以极大地提高开发和测试团队自动化脚本的使用效率和便捷性。 背景介绍 在软件业十分成熟的今天，敏捷（Agile）开发在业界日益流行，而面临的挑战也日益增多，不断变化的用户需求、缩短的开发周期、频繁的部署上线、复杂的产品架构和团队组织，如何继续保证软件的质量是一个不能回避的课题。 许多企业级规模的项目常常按照功能模块将庞大的团队分为多个独立的 Scrum 团队。在这种情况下，每个 Scrum 团队各自负责其所属功能模块的开发和测试。在 Scrum 团队中各种角色在不同的时间点有针对性不同的测试需求。其次，Build 部署以及测试频率大幅增加。测试类型和阶段也更加细化。 而现有的自动化测试，常常由独立的自动化测试团队来执行和维护。其他的 Scrum 团队成员除非十分了解自动化测试包的细节，否则无法按照自身多类型的测试需求来执行自动化脚本。并且有些项目自动化测试包涵盖了成百上千的测试用例，仅仅因为需要验证某个模块或某几个功能点是否成功而执行整个测试包不仅费时且没有必要。 本文针对以上涉及的问题，提出以下的解决方案：利用 Jenkins 和 TestNG 搭建“自助式”自动化测试平台，充分利用了 Jenkins 成熟的平台及其插件, 以及 TestNG 对选择测试用例的内在支持。 该平台具有以下优点： 基于成熟的测试工具。Jenkins 是目前业内最流行的快速持续集成工具之一, 其稳定的性能和丰富的扩展性, 使得很多的团队都优先选择它作为项目的主要支持工具。TestNG…

用ldap方式访问AD域的的错误解释 用ldap方式访问AD域的的错误一般会如下格式： LDAP: error code 49 – 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece 其中红字部分的意思如下： 525 – 用户没有找到 52e – 证书不正确 530 – not permitted to logon at this time 532 – 密码期满 533 – 帐户不可用 701 –…

#!/bin/sh myPath=”/var/log/httpd/” myFile=”/var /log/httpd/access.log” #这里的-x 参数判断$myPath是否存在并且是否具有可执行权限 if [ ! -x “$myPath”]; then 　　mkdir “$myPath” fi #这里的-d 参数判断$myPath是否存在 if [ ! -d “$myPath”]; then 　　mkdir “$myPath” fi #这里的-f参数判断$myFile是否存在 if [ ! -f “$myFile” ]; then 　　touch “$myFile” fi #其他参数还有-n,-n是判断一个变量是否是否有值 if […

摘要：DevOps是一种方法论，归纳总结了面临独一无二的机遇和强有力需求的网络巨头们，结合自身业务本质构思出全新工作方式的过程中所采用的实践，而他们的业务需求也很直接：以史无前例的节奏对自己的系统进行演进，有时候可能还需要以天为单位对系统或业务进行扩展。虽然DevOps对初创公司来说很明显是不可或缺的，但那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。 最近我阅读了很多有关DevOps的文章，其中一些非常有趣，然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。 这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要，过去15年来，我一直在大型机构，主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论，该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体，很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素：开发者和运维人员之间的混乱之墙。 请不要误会我的这种观点，除了某些XP实践，大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走，同时还有很多其他原因会导致软件开发项目的失败或延误。 但在我看来，混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。 与其独自生闷气，我觉得不如说点更实在的东西，写一篇尽可能精准的文章，向大家介绍DevOps到底是什么，能为我们带来什么。长话短说，DevOps并不是某一套工具。DevOps是一种方法论，其中包含一系列基本原则和实践，仅此而已。而所用的工具（或者说“工具链”吧，毕竟用于为这些实践提供支持的工具集有着极高的扩展性）只是为了对这样的实践提供支持。 最终来说，这些工具本身并不重要。相比两年前，目前的DevOps工具链已经产生了翻天覆地的变化，可想而知，两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。 本文并不准备介绍某些工具链，甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践，它们的主要目的，毕竟这些才是对我而言最重要的。 DevOps是一种方法论，归纳总结了面临独一无二的机遇和强有力需求的网络巨头们，结合自身业务本质构思出全新工作方式的过程中所采用的实践，而他们的业务需求也很直接：以史无前例的节奏对自己的系统进行演进，有时候可能还需要以天为单位对系统或业务进行扩展。 虽然DevOps对初创公司来说很明显是不可或缺的，但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。 本文的部分内容已发布为Slideshare演示幻灯片，可在这里浏览： 目录 DevOps的真谛到底是什么？ 简介1.1 管理信条1.2 一个典型的IT组织1.3 运维人员测挫败感1.4 基础架构自动化1.5 DevOps：仅此一次，一颗神奇的银子弹 基础架构即代码2.1 概述2.2 DevOps工具链2.3 收益 持续交付3.1 从实践中学习3.2 自动化3.3 更频繁的部署3.4 持续交付的前提需求3.5 零停机部署 协作4.1 混乱之墙4.2 软件开发流程4.3 共享工具4.4 协同工作 结论 1. 简介 DevOps所关注的不是工具本身，也不是对chef或Docker的掌握程度。DevOps是一种方法论，是一系列可以帮助开发者和运维人员在实现各自目标（Goal）的前提下，向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。 开发者和运维人员之间最大的问题在于：虽然都是企业中大型IT部门不可或缺的，但他们有着截然不同的目的（Objective）。 开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义，以及为什么我认为这种状况很严峻并且很糟糕。…

难得的机会 谢谢大家关注我的微信公众号vipdocker，到目前为止已经有过千的订阅数。虽然还很少，但是我会继续努力分享多多写点工作心得以及工作的技术思考来与大家交流。不过惭愧的是，最近的一些变化使得我已经尽3个月没有写文章了，抱歉抱歉！ 个人最大的变化是新近换了新东家，借着给新东家的同事分享Scrum开发模式的机会，把这个系列的文章的终结篇给完成了，或许某些内容与之前的文章有些重复，不过又有了新的思考，欢迎翻阅与对比查看(可通过公众号的历史文章找到)。 本文主要涵盖的内容如下： 敏捷Scrum模式概貌 Scrum Team的组成与角色分工 团队的日常活动 敏捷Scrum模式概貌 开发管理的痛点 开发过程的各个环节的明确边际，造成信息传递链条过长，沟通成本以及问题反馈效率低。现行的多数团队，其沟通方式多数是链式传递的，从产品->架构->开发->测试这样一个过程。然后就是每个人都希望做完自己规定的职责后可以当甩手掌柜，最后结果是下游环节在出现问题的时候把责任习惯性推给上游环节。测试不管大局，拼命找开发的所谓的“漏洞”，而开发则去说架构没有设计好，架构则找产品茬说产品啥YY需求。这样最明显的特征就是测试似乎绩效很好，但是产品质量依然一塌糊涂。这里引出一个公司管理的一个很现实的问题，在小团队规模开发模式下，以个人还是以团队的方式考核KPI和事？ 新技术的引入（微服务、容器化），不再适应大军团作战，而是需要匹配的灵活的端到端团队。在一个分层比较多的组织里面，最难做到的是管理水平化，往往在团队外增加“保姆式”的组织或监控流程。这样团队除了日常的工作，还要疲于应付那些水平管理所带来的沟通、会议等。这样整个团队都在疲于加班，但是事情依然无法按时完成。 客户的需求变化已经不再局限于整体产品购买，而是倾向于业务快速迭代，大军团作战已经难以快速交付、快速变更。如何配合客户的业务变更成为传统大型产品销售型企业最大的挑战。因为一个客户的产品已经难以复制性再交付给下一个客户了。在这样的市场条件下，如何将系统更大程度的拆解与灵活组装考验架构设计能力，也同样考验开发组织形式的变更能力。 敏捷开发不是个新鲜事物，但是随着微服务、容器化等新技术理念的推出，敏捷开发找到了更合适的切合点而已。 什么是Scrum敏捷开发 几个值得思考的问题： 团队对于需求范围是否有自主性？ 开发范围是否是根据时间倒排？ 是流程管控开发人员，还是人主导流程？ 在有市场交付压力的团队中，最容易遇到的问题就是倒排时间。因为交付内容与交付日期已经先确定了，然后当遇到开发瓶颈的时候，第一个想到的就是给团队增加人手。但是别忘了一个经典的说法，一个女人生一个孩子需要9个月，那么9个女人是否可以一个就生出一个孩子呢？答案是显而易见的。另外一个说法就是，如果所有的需求都是高优先级的，那么所有的需求都是低优先级的。 具体什么是Scrum敏捷开发，大家可以参考一下这本书：<<Successding with Agile Software Development with Scrum>> 不过还是跟大家强调一点，流程是死的，人是活动，需要根据团队情况进行变通。 区别 现在已经不流行敏捷开发，而是流程DevOps了。其实可以这样说，不以敏捷开发为基础的DevOps都是耍流氓。 Scrum不是等同DevOps，也不等同与现在更流行的SRE的概念。（具体SRE是什么，大家可以搜索一下）。DevOps和SRE将运维管理引入到开发团队中，将运维情况与开发形成一个闭环，是开发更能有效的考虑实际使用情况。个人理解，其三者的关系如下图： “scrum vs devops vs sre” 困境 虽然很多时候，大家都觉得敏捷开发， DevOps等理念都很好，但是就是很难去实行，最大的借口就是原来需要做的事情太多。但是这个时候，无论是团队还是管理者，需要停下脚步，做下思考，因为你遇到的情况很可能与下面这个图类似(来自互联网)： “hard…

docker images往往不知不觉就占满了硬盘空间，为了清理冗余的image，可采用以下方法： 1.进入root权限 sudo su 2.停止所有的container，这样才能够删除其中的images： docker stop $(docker ps -a -q) 如果想要删除所有container的话再加一个指令： docker rm $(docker ps -a -q) 3.查看当前有些什么images docker images 4.删除images，通过image的id来指定删除谁 docker rmi <image id> 想要删除untagged images，也就是那些id为<None>的image的话可以用 docker rmi $(docker images | grep “^<none>” | awk “{print $3}”)…

cd到上级目录，然后输入一条命令即可查询每个子目录所占用的空间大小 du -h –max-depth=1 Linux学习，http:// linux.it.net.cn 可以更改–max-depth参数的值，该参数表示查询子目录的层级，当前为1层

  As Java developers we’re often really busy with large backlogs, customer issues and countless disruptions. It can be quite daunting finding the time to learn all about things like Kubernetes and its associated tools and technologies (kubectl, OpenShift,…