自动化测试和自动化运维

现在云计算和DevOps的发展趋势，我觉得一个成熟的自动化运维平台应该包括以下的特性：

==============================================================
具体需求： 有一个登陆页面， 上面有2个textbox, 一个提交按钮。 请针对这个页面设计30个以上的test case.
此题的考察目的： 面试者是否熟悉各种测试方法，是否有丰富的Web测试经验， 是否了解Web开发，以及设计Test case的能力
这个题目还是相当有难度的， 一般的人很难把这个题目回答好。
功能测试(Function test)
输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。 输入错误的用户名或者密码, 验证登录会失败，并且提示相应的错误信息。 登录成功后能否能否跳转到正确的页面 用户名和密码，如果太短或者太长，应该怎么处理 用户名和密码，中有特殊字符，和其他非英文的情况 记住用户名的功能 登陆失败后，不能记录密码的功能 用户名和密码前后有空格的处理 密码是否以星号显示
界面测试(UI Test)
布局是否合理，2个testbox 和一个按钮是否对齐 testbox和按钮的长度，高度是否复合要求 界面是否好看 图片，颜色，字体，超链接，是否都显示正确
性能测试(performance test)
打开登录页面，需要几秒 输入正确的用户名和密码后，登录成功跳转到新页面，不超过5秒 能支持多少个用户同时登陆
安全性测试(Security test)
登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取) 用户名和密码是否通过加密的方式，发送给Web服务器 用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript验证 用户名和密码的输入框，应该屏蔽SQL 注入攻击 用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击） 错误登陆的次数限制（防止暴力破解）
可用性测试(Usability Test)
是否可以全用键盘操作，是否有快捷键 输入用户名，密码后按回车，是否可以登陆
兼容性测试（Compatibility Test）
主流的浏览器下能否显示正常已经功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等） 不同的平台是否能正常工作，比如Windows, Mac 移动设备上是否正常工作，比如Iphone, Andriod 不同的分辨率 不同的浏览器大小 （浏览器最大化， 和非最大化）
软件辅助性测试 （Accessibility test）
软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能
高对比度下能否显示正常 （视力不好的人使用）
=================================================================

image.png
一、支持混合云的CMDB现在越来越多的服务器都转到了云上，而主流的公有云、私有云平台都拥有比较完备的资源管理的API，这些API也就是构建一个自动化CMDB的基础。新一代的自动化运维平台应该是可以基于这些API来自动维护和管理相关的服务器、存储、网络、负载均衡的资源的。通过API对资源的操作都应该被作为操作日志记录下来，以备作为后续操作审计的基础数据。
CMDB这个东西听上去是老生常谈，但这个确实是所有运维工具的基础设施。而基于开源工具做运维平台最大的麻烦，就是如何在各个工具之间把CMDB统一起来。CMDB不统一起来，就意味着一旦要增加一台服务器，可能要在各个运维工具里面都要同步一下，这个还是非常折腾滴。。。
二、比较完备的监控+应用性能分析（APM）能支持对平台的可用性、服务器的性能、各种服务（web服务、应用服务、数据库服务）的性能进行监控。做的好一些应该能进行更深入、或者关联性的性能分析。
现在市面上一般都会将资源性能监控和应用性能监控（APM）混合着讲，这里面的产品确实也有很多都是重叠的，两方面都会涉及到。
开源的性能监控系统主流有的Zabbix、Nagios，国产的开源监控平台有小米OpenFalcon，但这些基本都只是做基本的资源监控（服务器，磁盘、网络等）和简单的服务软件的性能监控（中间件，数据库等）。
而市面上的APM系统更主打的功能是应用性能分析，比如能精确定位到某个应用的URL的访问速度快慢，某些SQL执行速度的快慢，这些对于开发人员和运维人员快速定位问题还是很有帮助的。APM这方面的商业工具，国外比较主流的有New Reclic、Dynatrace，国内的也就是透视宝、Oneapm、听云等，他们也提供了API进行集成。APM这方面的开源工具有pinpoint（一个韩国团队开源的），zipkin（twitter开源），cat（大众点评开源）。
三、有一个还不错UI的批量运维工具在业务发展比较快的情况下，从几台服务器，到几十台服务器，再到几百台服务器，批量运维的需求很自然就产生了，老板也希望越少的人干越多的活。
现在也有不少开源的批量运维工具，也都比较成熟了，比如puppet、chef、ansible、saltstack。puppet和chef都是ruby做的，实话实说，ruby的熟手市面上很少，比python不是难招一点。
我个人比较推荐使用ansible或者saltstack，这两个系统都是python写的，代码质量和社区活跃度都挺不错的。ansible有官方的web ui——Tower，但实话实说不好用，所以我们也在重新做一套自己用起来更顺手的WEB UI。
四、日志集中分析工具线上系统最常规的问题定位方式，就是日志分析了。随着服务器的增多，日志的分析定位也成为一个难点和痛点（想象一下，系统出故障之后，要去几十甚至数百个节点去上去查日志，是有多折腾）。
国内有一家叫日志易的公司，是专门做日志分析方面的运维工具的。另外还有一家log insight，也是做这个领域，但产品好像还处于beta阶段。
日志分析这个领域现在是一个热点，现在的开源方案也比较多了，比如著名的ELKStack，还有Flume+Kafka+Storm的体系。上面这两个方案相对重一些，部署比较复杂，网上介绍的文章也不少。
比较轻量级的开源日志集中采集方案有python做的Sentry，他是通过改造各种语言的日志采集框架来实现日志的集中采集，各种主流的开发语言的日志框架都支持得很完整了，比如java的log4j和logpack。Sentry的官网在此：Sentry - Track exceptions with modern error logging for JavaScript, Python, Ruby, Java, and Node.js**
五、持续集成和发布工具这方面其实比较难有统一的需求，很多公司集成发布的做法都差异挺大的。持续集成方面，一般用jekins的比较多，这方面网上介绍的文章也很多。
而如何把打好的包发布至各台服务器，则可以通过批量运维工具或者脚本来完成了。版本发布的过程涉及到很多细节，包括了版本文件的上传、分发、版本管理、回滚等各种操作。对于一般不太复杂的项目，我比较推荐的做法是把打包好的文件上传到svn上，然后通过脚本在各台服务器上进行发布操作就行了，这样其实是利用了SVN来完成文件的上传、分发、版本管理、回滚等各种操作。
六、安全漏洞扫描工具现在一个稍微有点知名度的系统，都会遭受各种各样的安全攻击的折磨。一般的公司不太可能请得起专职的安全工程师，所以运维工程师最好能自己借助一些安全扫描工具来发现自己系统的漏洞。安全工具方面我了解不多，不太熟这个领域的开源工具。之前乌云网推出过一个SaaS化的漏扫平台——唐朝巡航，有对外提供漏洞扫描的API，不过最近乌云网一直在升级，所以也就暂时无法调用了。