Arduino和Processing

通过Processing来读取Arduino数据,而这些数据可以来自于多种传感器,然后把这些数据图形化展现在屏幕上。

发表在 物理网 & Arduino | 评论关闭

人与人之间的差距

很多时候,不是因为“硬件”不行,而在于“软实力”。机会是留给有准备的人的

下面,使用网络上的3张图揭示人与人之间的差距!

图1


图2


图3


看出老员工和新员工之间的差别吗?

你是老板,你聘用哪个?

做着同样的工作,有的人拿2000元,有的人拿20000元,同在一个公司,同干一份工作,人跟人之间的差距咋就这么大呢?

一、关于刚入职时

普通员工

优秀员工

看重工资的高低,在一无所长的前提下,没有想过学习丰富的工作经验和职业技能。

更看重宝贵的工作经验,踏踏实实地去学习业务技能,他相信只要有丰富的经验,以后无论到哪都能赢得高薪。


二、关于对待问题

普通员工

优秀员工

在工作中会发现各种各样的问题,对于问题他们往往以抱怨的态度去对待,而没有想方法去解决。

在工作过程中,碰到问题会冷静地分析原因,并通过各种手段去解决,慢慢培养了一种解决问题的能力。


三、关于执行力

普通员工

优秀员工

对于上司交代的问题本着能做就做,不能做就慢慢磨,执行效果较差。

上司交代的事情积极去解决,遇到问题会积极与上司沟通请示,执行效果好。


四、关于个性

普通员工

优秀员工

个性张扬,以自我为中心,不善于处理自己与同事领导的关系,往往给人一种很浮躁的感觉。

为人谦虚低调,能协调好与领导同事的关系,人际关系非常好


五、关于下班后

普通员工

优秀员工

下班后往往通过看电视、打打游戏等方式,度过一段休闲时光。

下班后会抽出时间回顾今天一天的工作内容,反思不足之处,并规划好第二天的工作内容。


六、关于工作重点

普通员工

优秀员工

工作杂乱无章,搞不清楚工作的核心内容,工作往往忙起来手足无措。

能很好地做好工作规划,找准核心工作内容,即使忙起来也能井然有序。


七、关于客户沟通

普通员工

优秀员工

和客户沟通仅局限于单纯的送货收款,没有考虑到客户的实际需求,往往工作很辛苦,但是成效却很低。

能很好地处理与客户的客情关系,准确地找到客户实际需求,并结合客户需求达成销售。往往事半功倍。


八、关于视界

普通员工

优秀员工

缺乏宏观思考,经常纠结于某个终端问题,有时为了应对单个终端问题不惜提高政策从而影响了整个市场价格体系。

从市场整体角度出发,能很好地协调好各个渠道之间的市场问题,对于违反市场规律的个别终端坚决予以治理。


九、关于批评

普通员工

优秀员工

对忠言逆耳理解得不透彻,总认为自己想的是对的,把上司或资深前辈的意见或建议不当一回事,我行我素。

能谦虚地接受批评,认识到自己所犯错误在哪,并积极改正!


十、关于职业规划

普通员工

优秀员工

没有职业规划,对自己想要什么没概念,能做多久算多久,风风光光是一辈子,窝窝囊囊也是一辈子,得过且过。

有自己的职业规划,知道自己想要什么,也知道如何去努力。


                                            不论做什么,用心最重要!

发表在 生活&工作感悟 | 一条评论

浅析软件测试的目的和bug提炼


                            ——  摄于上海临江公园(2015.12)

前言

细细想一想,我们投入大量的时间精力、人力和物力,进行软件测试的目的是什么。仅仅是为了向用户交付高质量的软件产品吗?这自然是对的。但放眼于整个软件项目的研发测试活动,我们不难发现测试的目的其实有两个,或者说,产生的作用应当有风险缓解和质量保证这两个。

这里,先来说说“风险缓解”。我们都知道,风险是无法避免的,它贯穿于我们生活的全部,开车有风险、工作有风险、旅游有风险等等,既然风险总是客观存在的,那怎样才能有效避免或者缓解风险呢,就如同开车样,可以通过买保险、安全气囊、保持合理车距和速度等来缓解。观之于,软件活动中,又有什么缓解之道呢。在探讨确定风险以及风险缓解方法之前,我们有必要先认识下如何分析软件活动中的风险。

1.风险分析

  • 哪些功能模块是高风险和高频率?
  • 这些风险发生的可能性有多大?
  • 一旦发生,对公司和客户会产生多大影响?
  • 这些影响有哪些缓解措施?
  • 这些缓解措施有多少可能会失败?
  • 处理这些失败的成本有哪些?
  • 发生风险是偶尔还是经常、总是?

产生风险的原因有很多,如果要精确地、定量地计算风险甚至比缓解风险还要麻烦。通常,我们的做法是使用两个要素:失败频率和影响,来给产品的每项功能打分,我们发现,风险实际上是一个定性的相对值,而非一个定量的绝对值。风险分析的目标不是要给出一个精准的数值,而是要识别一个功能相对于另一个功能其风险是大还是小,继而,产生的结果便是决定以哪种方法测试哪些功能。

评估软件产品功能因素之一的失败频率,我们一般使用代表有具体意义的四个形容词来打分。如下:
  • 罕见:是指发生故障的可能性很渺小,发生问题后的恢复也很容易。
  • 少见:在少数情况下会发生故障,但是在使用场景复杂度不高的情况下或使用率较低的情况下,发生的可能性非常小。
  • 偶尔:发生故障的情形可以预料到,可以重现,而发生该频率的功能是比较常用的。
  • 经常:此功能所属的特性使用量大、复杂度高、问题频发。

很多时候,我们其实只想要或只需要知道一个风险比另一个风险更大就足够了,费尽心思去做一些数字的计算或者评分,是没有意义的。上述基于分类定义(罕见、少见、偶尔、经常)风险的分析已经足够我们使用了。评估风险影响程度的方法大致相同,也是从几种预定义的相对值中进行选取。
  • 最小:是指这种影响程度的功能,一般都注明了是属于“边界功能”或写进了FAQ手册,同时这种风险或者问题产生的影响对用户而言很微小,几乎察觉不到。
  • 一些:是指软件风险的发生会轻微影响到用户,一旦发生,用户重试或恢复机制即可解决问题。
  • 较大:是指软件发生的问题会阻碍用户使用。
  • 最大:是指软件发生的问题会永久性的损害产品的声誉,并导致用户不再使用,同时给公司带来损失。

2.风险缓解
风险分析帮助我们识别风险;测试帮助我们缓解风险。在我们探讨了风险分析和缓解之后,是时候,探索质量保证了。风险不太可能被彻底消除,通常情况下,风险并没有真的造成伤害,为什么呢?原因即在于我们会以实际行动来缓解风险。

就软件而言,一种极端的缓解方法就是去掉风险最大的那块组件。交付的功能组件越少,风险就越小。但是,这种方式是长久之计吗,除了彻底的消除风险外,其实还有很多措施可以缓解风险。
  • 可以围绕风险大的功能点编写用户故事,并从中确定高风险的使用场景,然后QA测试反馈给开发团队,让他们有针对性的增加约束。
  • 编写和执行回归测试,以便重现问题或者验证Bug是否真正得到修复。
  • 将无意间或者不是通过执行现有测试用例发现的Bug方式,补充进现有的测试用例。
  • 插入监听代码,以便更早地检测到问题。
  • 采用其他一些可取的软件交付、发布方法,比如黑暗部署等。
  • 重点针对风险大的模块、功能以及产品的特色功能展开测试。
  • 多重测试方法,即包括面向用户服务的回归测试 + 故障测试 + 平台可用性测试等在内的测试方法。
  • 遵循一定的测试法则。

具体的风险缓解方法和效果很大程度上取决于应用本身以及用户对于产品使用的需求。对于QA测试和开发人员而言,其工作的核心内容就是,前者主要负责暴露风险,后者主要负责解决风险。那些风险影响程度被标记为较大和最大的风险点就要比最小和较小的要优先处理,按照优先级或风险顺序进行测试。原则是,如果不能全部测试,就先测试最重要的,也就是风险或者功能最主要的。

除此外,QA测试人员的职责之一是根据最终的测试结果和分析总结报告、风险热力图等来给出产品是否可以发布的意见建议。

3.质量保证
在我们经历了软件风险分析和缓解之后,需要做质量保证了,须知,测试也是质量保证的一个范畴。质量保证的两大技术手段是:技术评审 + 软件测试。技术评审更具有预防性,也就是说,它的目的是尽早地排除缺陷,而软件测试则是验证已经开发完成的实际代码。同时,质量保证也是敏捷迭代开发方法中的关键组成部分,质量保证能够确保用户的需求得到满足。

质量保证的3大组成部分包括软件测试、质量控制和软件配置管理。软件测试的目的是通过验证和确认活动来保证软件设计、代码和文档能够满足相应的需求。软件测试的主要环节包括测试计划、测试设计、测试开发和测试执行等。质量控制是用来监控工作和观察需求是否实现的过程和方法,它侧重于通过结构化的审查来排除软件开发生命周期中产生的缺陷。

  • 将需求设计转换成可测试的测试用例;
  • 让测试作为质量持续改进的过程;
  • 以用户为中心:应当站在用户的角度来考虑问题,确保用户的需求得到满足;
  • 提高服务精神:为项目组服务,帮助项目组投入质量保证中;
  • 了解开发:对开发工作的基本情况了解,能够理解项目的活动;
  • 提高沟通技巧:善于沟通,营造良好的气氛,避免审计活动成为一种找茬活动;
  • 尽早了解项目;尽早测试、尽早失败、尽早交付(缺陷越早发现越早修改越经济);
4.如何提炼Bug
测试后,我们应当针对测试过程中取得的教训进行整改,对经验进行总结,如下。
1)测试过程的管理经验、具体某个bug的分析总结经验、以及和开发人员的交流沟通经验、bug描述经验和缺陷发现经验等。
2)分析测试的整个过程,是否合理安排了投入资源、测试进度是否按照计划进行,如果没有是因为什么原因,如何避免下次类似问题、测试和缺陷风险是如何控制的、有哪些需要改进的地方。
3)还应该包括某些专门类型的测试经验总结。例如哪种测试的效率最高和最低、碰到的问题是如何解决的;自动化测试执行效率,下次有哪些改进等。
4)提炼出Bug模式。报告应该包括对测试用例的分析和设计经验总结;哪种方式发现bug的效率高等。通常,需要从典型的或者具有一定规律性的缺陷中,总结提炼出具有普遍代表性的Bug模式。测试人员需要能够从这些重复出现的Bug中学习,总结出Bug模式,用于指导测试。要成为典型缺陷,需要满足以下条件:
  • 重复出现、多次出现;
  • 能代表某种类型的缺陷;
  • 能通过相对固定的测试方法/步骤发现这些缺陷;
总结这些典型缺陷出现的现象、出现的原因以及测试的方法,就可以提炼出一种Bug模式。提炼的一般步骤如下:
  • 分析缺陷报告,找出经常出现的bug类型;
  • 分析bug的根源,找出bug产生的深层次原因;
  • 分析找到bug的方法,总结如何才能每次都发现这种类型的bug;
发表在 OpenStack 测试 | 评论关闭

使用Kolla部署openstack

1、加入 Docker 的源

# tee /etc/yum.repos.d/docker.repo << 'EOF'
[dockerrepo]
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/centos/$releasever/
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg
EOF

2、安装 EPEL 源

# yum install -y epel-release

3、kolla安装

# yum -y install python-pip libffi-devel python-devel openssl-devel git ansible gcc python-setuptools
# yum -y install docker-engine-1.11.2-1.el7.centos.x86_64

4、开启Docker的MountFlags

# sed -i 's/MountFlags.*/MountFlags=shared/' /usr/lib/systemd/system/docker.service

5、修改 /usr/lib/systemd/system/docker.service 文件,添加–insecure-registry,如下:

ExecStart=/usr/bin/docker daemon -H fd:// --insecure-registry git.trystack.cn:5000

重启和安装服务

# systemctl daemon-reload && systemctl restart docker
# git clone https://git.openstack.org/openstack/kolla
# pip install kolla/
# cd kolla
# pip --default-timeout=100 install -r requirements.txt tox
# tox -e genconfig
# cp -r etc/kolla /etc/

6、部署openstack
使用下面命令生成各服务的密码

# kolla-genpwd

7、执行命令后,编辑/etc/kolla/passwords.yml文件。可以修改 keystone_admin_password 的值。

8、编辑 /etc/kolla/globals.yml 文件,如下。这里我们使用99cloud的Trystack docker源。

kolla_install_type: “source”
kolla_internal_vip_address: “192.168.1.100”  //访问Dashboard的地址
docker_registry: "git.trystack.cn:5000"
docker_namespace: “99cloud”

9、使用下面命令检查配置是否正确

# ./tools/kolla-ansible -i /usr/share/kolla/ansible/inventory/all-in-one prechecks

10、使用下面命令开始部署openstack

# ./tools/kolla-ansible -i /usr/share/kolla/ansible/inventory/all-in-one deploy

11、部署完后,访问虚拟IP地址 http://192.168.1.100

发表在 OpenStack | 3 条评论

Kolla部署OpenStack 任务失败分析

问题:

使用Kolla来部署Ceilometer的docker镜像失败,使用常规的方法无法直接看到错误信息,所以摸索出的一个方法如下:

1、在被部署节点上(这里为控制节点)

这里,由于部署失败,Ceilometer容器没能成功运行起来(状态为Exit)。现在,手动启动Ceilometer容器。

# docker restart e3dfdf9e7e0a
# docker exec -it e3dfdf9e7e0a bash
# /usr/bin/ceilometer-api --logfile /var/log/ceilometer/api.log   //可以在一个正常的节点上执行ps aux|grep ceilometer来查看相关信息
# tailf /var/log/ceilometer/api.log

从日志中,我们可以看到因为没有配置文件,或者配置文件没有进行配置,全部被#注释了。这里,我们来验证下是否真的是这样的,将一个好的ceilometer.conf和配置文件放在主机的/var/lib/kolla/config_files目录下,稍后我们将其挂载到容器的/etc/ceilometer/目录下。
# exit     退出容器
# docker rm -f  e3dfdf9e7e0a    删除该容器

2、在主机上执行如下操作
1)基于ceilometer-api镜像,重新创建一个容器
# docker run -u root -it --net=host -v /var/lib/kolla/config_files/:/etc/ceilometer/ --name=ceilometer-api 
autodeploy.chinacloud.com:4000/kollaglue/centos-binary-ceilometer-api:2.0.1 bash

2)日志重定向
/usr/bin/ceilometer-api --logfile /var/log/ceilometer/api.log


3)查看日志
# tailf /var/log/ceilometer/api.log
现在,在该日志中,没有看到相关配置文件的错误信息了。

但,问题怎么解决,即Kolla调用Ansible部署OpenStack Ceilometer时,为什么没有对template文件进行配置,还需要研究。有一点即是,社区是不支持在N版之前部署Ceilometer的。这里是我们分析问题的一个简要思路。
发表在 OpenStack | 2 条评论