安裝 nodejs
安裝 Appium
Appium是Android平臺上一個測試框架。
本文簡單地介紹如何在
Linux機器上安裝并運行該框架。
應用環境：
Ubuntu 12.04 LTS
HTC One X (endeavoru, S720e)
Android SDK
請參考SDK環境，這里就不多說了。
Appium
安裝 nodejs
apt-get install nodejs
# 或者通過nodejs源碼編譯，這樣可以使用最新的代碼
cd ~/downloads
wget http://nodejs.org/dist/v0.10.25/node-v0.10.25.tar.gz
tar -zxf node-v0.10.25.tar.gz
cd ode-v0.10.25
./configure --prefix=/usr/local/node
make && make install
# edit ~/.bashrc and add node to your PATH env
安裝 Appium
npm install -g appium # install appium as a global app
配置手機
手機需要是已經root過的！
su
chmod 777 /data/local
另外，也要確保你手機上安裝了最新的chrome瀏覽器!
Note:
這步是必需的，否則后面會發生無法啟動瀏覽器的異常。
下載&運行測試項目
# 下載項目
git clone git@github.com:ytfei/appium_chrome_demo.git
cd appium_chrome_demo
npm install # 安裝依賴包
# 啟動appium
appium -g appium.log &
# 開始測試
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
感謝我老婆，大周六自己在家帶孩子，讓我參加了一整天的敏捷Scrum Master 培訓。我想如果這個培訓是
工作日在公司內部，大家是否還有如此的積極熱情呢？今天只達到預期人數的一半，參與程度卻非常高，結束之后大家都圍著杜偉忠教練不斷問問題。我切實的感覺到這些人真的是公司內愿意
學習新知識，對
敏捷，對改進有極大熱情的人。我想無論是培訓還是其他交流活動，想甄別出南郭先生還是真正熱情的粉絲，選擇周末舉辦是個不錯的辦法。
拋開現實，在敏捷實踐的活動中，我們可以組成自組織的小團隊，頻繁溝通、持續改進。但是真正討論到敏捷落地，有些人一聲嘆息說“理想與現實還是有差距的”，也有些人覺得“有心問鼎，無力回天”，還有一大部分人抱著樂觀而又被動的心態想著“總有人來幫助我們做出改變的”…
世界的大環境都是一直在改變的，又何況我們所處在的小環境，面對變革，要么被淘汰，要么被改變。被動改變是痛苦的，想主動改變卻又覺得無從下手干著急是更痛苦的。反正都要痛那么一下子，就好比打針，我們預期到針要扎在哪個屁股上，會事先做好心理準備的。所以我想可以先來分析下敏捷轉型會扎到我們個人和組織的哪些痛處？
持續學習之痛
組織中一部分人已經習慣了現有的工作方式，雖然有問題，但是憑著個人的經驗也能夠處理的游刃有余。
作為開發，每天要應付很多的各種來源的任務，有的是產品經理和開發經理定的，有的是總監拍的。已經習慣了領導驅動的工作方式，也已經逐漸摸索出了一套“上有政策，下有對策”的應對措施。我已經習慣于通過google來解決問題，偏偏現在只能用
百度，就忍了。你還要讓我學習“重構”、學習“
測試驅動開發”，學習“實例化需求”，學習“持續集成”？我只想說“我是寫代碼的，干嘛要管你們那么多事情”。
作為測試，隔三差五的上線個小需求啥的，等待部署環境一個小時，等待數據同步三個小時，抓緊在午夜十二點之前完成十來個用例的線上驗證，好回家睡覺。我上班不能學習吧，我要點頁面，我要找開發，找產品，下班我還要加班啊，什么時間來學習呢？
我已經好久不碰代碼了，
自動化測試我怎么學的會呢？測試最牛逼的還是手動測試，專家都這么說了。
作為產品，我都忙得找不著北了，我不主動去找開發人家也不搭理我，我天天要開會、要溝通，要寫PRD，還要天天被測試纏著確認各種需求問題。我一直希望深入的掌握業務，可是我TMD也就是個公司業務方的代言人，就是你們天天說的“二道販子需求”。別給我提什么Product owner是決定一個產品成敗的關鍵所在，我只想著老老實實把領導關注的業務都給實現嘍，敏捷啊，是你們研發自己的事情。
組織架構之痛
組織結構是職能部門橫向劃分的，產品經理屬于產品部門、開發屬于開發部門、測試屬于測試部門、項目經理屬于
項目管理部。每個部門的團隊都要實現各自不同的價值，這樣難免會出現“各掃門前雪”的情況。如果要敏捷，倡導跨職能的團隊，原來獨立職能團隊積累的一些經驗需要打破重來，原來的經理們需要重新找到自己的位置。這都是不容易的。
首先從測試部門說起，目前測試團隊的價值體現在什么地方？常常團隊中認為發現足夠多的
Bug，編寫足夠多的
測試用例，及時得反饋問題，這樣就夠了。可是真是這樣嗎？每每開發完成了提交測試，后期又出現項目周期延誤，大家或多或少的心里嘀咕“測試時間這么拖這么長，能力不行嗎？”有時線上出了問題，開發熬夜改bug到凌晨3點，他也會抱怨一句“這個問題怎么測試沒發現？”。測試肯定覺得很冤，我們Bug和用例的數據都在那呢，最后處理問題的結果可能是開發測試各打五十大板了事。如果要敏捷轉型，追求全能型工程師，測試部門獨立存在的必要性就很小了，敏捷團隊中的每個人無論是開發、產品、還是測試都會參與到測試中去，打破了對測試工程師自身的局限以及這個title的局限。面對組織架構的重構，測試部門及團隊成員必須浴火重生，在提升業務能力和技術能力的同時才能體現出自身的價值。
目前的開發部門，負責前臺頁面的不管后臺Server的問題，負責單獨模塊開發的不負責公共部分問題的修改，開發主管一般作為Product owner來掌控項目。這樣看起來，專業化、精細化的分工是能夠把職責劃分得更清晰，可是確常常會出現接力失誤，導致接力棒掉在地上的情況。有些劃分不清的區域，誰也不愿意也沒有責任去主動承擔。開發主管以小組成員利益的角度出發，在平衡客戶需求和團隊訴求時是非常困難的。可是，如果轉型，必然需要調整組織結構，要重新打破舊有的平衡，已經到嘴邊的“蛋糕”也需要重新分配。
產品上面已經吐槽了，這里就說說項目管理部門。尷尬的項目經理沒有考核項目成員的權利，卻要承擔著項目質量控制、進度控制、風險控制的責任，需要協調產品、研發、測試各個部門。可以不斷的反饋問題，推動起來卻重重阻礙。出現問題匯報領導，項目組成員覺得你愛打小報告，若是不匯報，出現問題，又要承擔沒有及時反饋的責任。因此只能說這個戰場比拼的是情商和個人魅力，這樣才能夠順利周旋于多個角色之間。那么，轉型敏捷后，項目經理要面臨什么樣的角色轉換呢？Scrum master 還是 product owner，還是重新開始寫代碼，成為一名團隊成員呢？
渺小的個人VS強大的影響力
渴望改進的人，絕不是消極的，抱怨是無解的。敏捷的思想是要相信團隊，無論是自己所在的小團隊，還是公司這個大團體。還要相信個體的力量，通過不斷學習提高自己的能力，發揮“日拱一卒”的精神，抱著一顆同理心，幫助他人，與團隊內外的成員共同進步，去建立自己的影響力。做好心理和技能的準備，不斷的實踐嘗試，一步一步實現改進的愿望。
說起來是這個道理，可是有人會說了，我作為一個普通員工，我甚至只是一個測試工程師，處于項目流程的下游，我感覺自己什么也做不了。即使領導支持敏捷了，我們作為測試，不會直接的交付產品，我們也無法單獨敏捷啊。或者作為一名開發工程師，或者產品經理，個人都是沒法一下子去推動敏捷改進的。還有人說，那就等吧，你不用操那么多心，你所想的遲早有一天公司都會幫你實現的。。。
不只是我們自己相信，敏捷思想是經過驗證的能夠提高交付價值，提高團隊效率的有效工具。因此，我們要相信好的東西，大家是沒有理由不喜歡的。就好比美味的螃蟹，大家不去吃，是因為不知道它的美味，不同的人看到的是不用的角度，有的人只看到了張牙舞爪的鉗子，有的人只看到了硬硬的殼子，在沒有品嘗到美味的蟹肉和蟹黃之前，大家都不可能欣然接受，更何談去主動參與，積極推動呢？
杜偉忠教練也給我們分享過一個實例，原來他還沒做敏捷教練，是熱心敏捷的愛好者。他的辦法就是鼓勵身邊的同事或領導和他一起去參加敏捷的社區或者交流分享活動，讓大家逐漸都感受到敏捷的魅力，大家都覺得好了，自然推動起來就沒什么阻力了。這只是一種影響他人的方法。我們也可以從自身做起，不斷學習，去掌握敏捷的精髓，提煉出真正提高生產力對團隊有益的實踐，先小范圍應用到實際工作中，身邊的人自然會看到你做的一切，自然會感受到敏捷的力量。
這是
互聯網的時代，按照互聯網思維，每個人都是一個節點，通過建立連接可以發揮無窮的影響力，方法就是不斷的 學習、實踐、溝通、分享 ，循環往復…
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
Loadrunner12推出Community版本，支持50個免費用戶
LoadRunner仿照6年前就已經出現的SOASTA、Neotys、Blazemeter等競爭對手，推出云
性能測試平臺，有興趣的朋友可以看看《Thoughts about LoadRunner 12 Release》這篇
文章。
新特性
1、Cloud-based load generators
2、Licensing - 50 vUsers free
3、VUGEN improvements
The ability to review replay statistics for tests after each run.
Including details on total connections, disconnections and bytes downloaded.
The ability to edit common file types in the editor.
Support for recording in the Internet Explorer 11, Chrome v30 and Firefox v23 browsers.
The ability to create scripts from Wireshark or Fiddler files.
The ability to record HTML5 or SPDY protocols.
4、TruClient improvements
TruClient script converter. This basically replays your TruClient scripts and records the HTTP/HTML traffic allowing you to create these script typers from TruClient recordings. This is similar to recording GUI scripts and then converting to other script types.
The addition of support for Rendezvous points, IP spoofing, VTS2 and Shunra network virtualisation in TruClient scripts.
5、
Linux Load Generator improvements
Building on the increased support for Linux Load Generators in 11.5x, LDAP, DNS, FTP, IMAP, ODBC, POP3, SMTP and
Windows Sockets scripts can now be replayed through UNIX load generators.
6、CI/CD support
Better integration with Jenkins etc.
7、Platform support
Support for installation on Windows Server 2012.
(LoadRunner 11.x and PC 11.x only supported up to W2K8 which was a barrier to enterprise adoption).
LoadRunner components can now run in a "non-admin" user account with UAC and DEP enabled.
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
一、 網站程序中采用DIV+CSS這種模式，不用Table
目前DIV+CSS是主流的編程語言，這與其體積小加載快的優點是密不可分的。主流的網站和CMS采用的也都是這種模式。因此建議大家也采用這種模式來編程，而不要采用原始的Table結構。Table結構不但管理不方便，網頁體積也會變大，降低網站的加載速度。
二、 采用Gzip技術對網頁進行壓縮
采用Gzip技術對網頁進行壓縮是減少網頁體積的一個很好的方式.一般情況下這是需要你的網站空間支持的，像我用的A5的合租主機，壓縮率可以達到80%。網頁體積小了，自然加載速度就快了。
三、 減少CSS文件數量和體積
在采用DIV+CSS過程中，CSS文件是非常重要的。如果在編寫過程中有多個CSS文件，建議將多個CSS文件進行合并，這樣可以加快網站加載速度。另外，可以采用專業的網頁減肥軟件對CSS文件進行減肥，以減少CSS文件的體積。
四、使用CDN加速。
近一年CDN已經在我們個人站長中聽的較多，也有很多朋友在使用。CDN的全稱是Content Delivery Network，解釋為內容分發網絡。原理思路是盡可能避開
互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定。也就是網站加速器，這個需要付費使用的，免費的不是太穩定。
五、優化代碼，減少臃腫結構。
如果我們使用較為流行的CMS這方便應該不會有臃腫的代碼結構存在，但需要注意的是我們在制作或者選擇網站模 板的時候也會存在不合理的結構。我們需要在寫模板或者程序的時候使用較為簡潔的程序框架，簡潔有利于用戶體驗，也更利于搜索引擎蜘蛛的爬行和抓取。
六、減少圖片大小和數量。
我們盡量在上傳網站圖片的時候減少圖片的大小和尺寸，可以在上傳圖片之前對圖片進行壓縮處理，圖片適當尺碼即可，不要過大。圖片僅僅是網站的點綴，而不需要都是圖文。同時，我們也盡量避免使用大量的視頻或者音頻內容。
七、減少JavaScript腳本文件，盡量存放在一個文件中。
盡量外部調用JS代碼，不要放在網頁中，更不要遠程調用外部的JS代碼。例 如
Google建議您加載在HEAD標簽的分析。您也可以嘗試結合的JavaScript和壓縮他們更快地加載。有些時候我們在頭部的CSS，JS代碼太 多，導致中間內容部分加載太慢。所以盡量減少頭部的代碼。
八、運用靜態的HTML頁面
眾所周知，ASP、PHP、JSP等順序完成了網頁信息的靜態交互，運轉起來確實十分方便，由于它們的數據交互性好，能很方便地存取、更改
數據庫的內容，但是這類順序也有本人的缺陷，那就是它必需由效勞器先生成HTML頁面，然后在“傳送”給用戶，多了一個步驟，必定會影響到網站的拜訪速度，所以筆者建議，在新站開端的時分，在對本人網站的重要調查期內還是采用靜態的HTML頁面比擬保險。
九、 將ASP、ASPX、PHP等文件的訪問改為.js引用
這在ASP、ASPX、PHP等程序設計時應該注意的，如果要在靜態的HTML頁面里嵌入動態的數據，而這些動態的數據是由ASP、PHP等程序來提供的話，會使用以下的語句引用：
<script src=”http://image.ccidnet.com/ad_files/network_index.asp?orders=1″></script>
這樣的話，每次有一個人訪問你的網站，服務器就要執行并處理一次network_index.asp文件，從數據庫抽取相應的數據，再輸出給網頁顯示，如果有幾萬個人同時訪問，就要執行幾萬次，后果就可想而知。建議在這些程序中將數據動態生成到一個network_index.js文件中去，然后在首頁通過
<script src=”http://www.179job.com/ad_files/home_daohang/network_index.js”></script>
這樣的代碼來引用該network_index.js文件。這樣，數據顯示的任務就交給客戶端的瀏覽器去做，不會耗費服務器的資源，顯示速度自然就很快；前者所花的時間幾乎是后者的幾倍！
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
正是因為業務需求推動應用軟件的創建，所以應用程序的設計必須萬無一失且通過質量保證認證。質量保證的一個重要方面是：設計出能確保所有設計場景已在
測試中被抓取的
測試用例。測試用例是一組條件或變量，在其中，測試員將決定被測系統是否滿足設計的要求和功能。開發測試用例的過程也有助于發現應用程序的要求或設計中的問題。一個測試用例與一些元素指示（如測試集ID ，測試用例ID，測試總結和測試描述）有關。
測試用例設計有兩個主要任務：
·測試設計是所有邏輯測試用例的注意要求的草案。如果有效地設計，這就是一個能在測試執行時節省相當大精力及成本的關鍵部分。
·規格包含被轉化為將要進行的物理測試指令的完整描述的草稿。
我們使用一個基于元數據的方法來設計測試用例。這種方法對于將要跨多個應用程序進行統一測試時以可重復的方式設計測試用例來說是很有用的。示例場景是涉及數據遷移或企業數據屏蔽的項目。基于元數據的測試用例設計和通用測試用例設計的主要區別是：前者沒有在從需求去推導測試用例上花時間，因為通過元數據直接使用數據或前期數據的數據或屬性是有可能的。
圖1．使用測試用例生成工具設計測試用例
用基于元數據的方法，我們可以著手處理庫存要求；反過來，著手處理庫存要求也可以獲取元數據存儲庫中的數據屬性。基于庫存，就能準備高層次的場景，然后支持測試用例的開發。為了加快測試用例的準備過程，我們設計了可以用任意基本腳本語言（如VB腳本，UNIX或Perl）實現的方法，以可重復的方式高效地生成測試用例。
測試用例生成工具（ TCGT ）是一個基于在矩陣上的信息的基礎上生成測試用例的高度自動化工具。它生成的測試用例可以滿足驗收，確認，應用核實的目的。基于元數據的測試用例設計可以用于以下兩種場景，在這兩種場景中要求了基于工廠的測試用例設計和生成。
場景1：數據遷移
數據遷移項目需要大量的
數據庫測試，以確保沒有數據泄漏，且遷移后數據的完整性和質量得以保留。遷移過程是由一組作為映射規則和轉換功能的規格決定的。例如，如果我們正在測試一個系統，把數據從
SQL Server 2005遷移到SQL Server 2008中，我們就需要執行以下操作：
·數據遷移的需求分析
·規范化要求
·元數據驗證
·數據驗證
場景2：數據屏蔽
基于元數據的測試用例的設計也可以在企業數據屏蔽中實現。數據屏蔽測試需要比較數據正確性和完整性的源頭數據和目標數據。沒有屏蔽或屏蔽后復制的表格應該測試其數據變化，屏蔽算法和業務規則。在大多數情況下，數據屏蔽場景需要可重復準備和執行的測試用例，這樣測試用例設計中就可以使用元數據方法了。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
一、問題：如何將mock的類自動注入到待測類，特別是在沒有setter方法的情況下。
解答：
前提:待測的service類及其依賴的其他類都是處在被spring管理中的。
做法：在
測試類中，只要將待測的類標注為@InjectMocks，將其依賴的其他類標注為 @Mock，
就可以使用MockitoAnnotations.initMocks(this);這句話自動將依賴的類注入待測類，如果依賴類在spring的管理下有自己的name，那么甚至在待測類中都不需要寫setter方法。
例：
1、待測類
@Component("abcService") public class AbcService { @Resource(name="aaaDao") private AaaDao aaaDao; @Resource(name="bbbDao") private BbbDao bbbDao; ......//注：此處省略的代碼中并不包含aaaDao和bbbDao的setter方法。 } |
2、測試類
public class AbcServiceTest{ @InjectMocks AbcService abcService; @Mock AaaDao aaaDao; @Mock BbbDao bbbDao; @Before public void setup(){ MockitoAnnotations.initMocks(this);//這句話執行以后，aaaDao和bbbDao自動注入到abcService中。 //在這之后，你就可以放心大膽地使用when().then()等進行更詳細的設置。 } } |
二、問題：如何對連續的調用進行不同的返回
對連續的調用進行不同的返回 (iterator-style stubbing)
還記得在實例2中說道當我們連續兩次為同一個方法使用stub的時候，他只會使用最新的一次。但是在某一個方法中我們確實有很多的調用怎么辦呢？mockito當然想到這一點了：
when(mock.someMethod("some arg")) .thenThrow(new RuntimeException()) .thenReturn("foo"); //First call: throws runtime exception: mock.someMethod("some arg"); //Second call: prints "foo" System.out.println(mock.someMethod("some arg")); //Any consecutive call: prints "foo" as well (last stubbing wins). System.out.println(mock.someMethod("some arg")); |
當然我們也可以將第一句寫的更簡單一些：
when(mock.someMethod("some arg"))
.thenReturn("one", "two", "three");
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
CentOS：
開啟遠程連接服務：service sshd start
添加到系統啟動項：chkconfig sshd on
客戶端工具：windows下連接工具putty
=============================================
Ubuntu：
安裝命令：$ sudo apt-get install openssh-server
查看openssh-server是否啟動
$ ps -e | grep ssh
進程ssh-agent是客戶端，sshd為服務器端，如果結果中有sshd的進程說明openssh-server已經啟動，如果沒有則需運行命令啟動。
啟動、停止和重啟openssh-server的命令如下
/etc/init.d/ssh start
/etc/init.d/ssh stop
/etc/init.d/ssh restart
配置openssh-server
openssh-server配置文件位于/etc/ssh/sshd_config，在這里可以配置SSH的服務端口等，例如：默認端口是22，可以自定義為其他端口號，如222，然后需要重啟SSH服務。
Ubuntu中配置openssh-server開機自動啟動
打開/etc/rc.local文件，在exit 0語句前加入：
/etc/init.d/ssh start
關于客戶端連接
客戶端可以用putty、SecureCRT、SSH Secure Shell Client等SSH 客戶端軟件，輸入您服務器的IP地址，并且輸入登錄的用戶和密碼就可以登錄了。我常選擇的客戶端軟件是putty。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
摘要: 前言 本文基于順序循環隊列，給出Linux生產者/消費者問題的多線程示例，并討論編程時需要注意的事項。文中涉及的代碼運行環境如下： 本文假定讀者已具備線程同步的基礎知識。 一 順序表循環隊列 1.1 順序循環隊列定義 隊列是一種運算受限的先進先出線性表，僅允許在隊尾插入(入隊)，在隊首刪除(出隊)。新元素入隊后成為新的隊尾元素，元素出隊后其后繼元素就成為隊首元素。 隊列的順...
閱讀全文
WINDOWS遠程連接LINUX配置（LINUX VNC
Server配置）：
1.查看本機是否有安裝vnc（centOS5默認有安裝vnc）
rpm -q vnc vnc-server
如果顯示結果為：
package vnc is not installed
vnc-server-4.1.2-14.e15_3.1
那恭喜你，機器上已經安裝了vnc，如果沒有，就得自己安裝了，這里不說怎么安裝了，很簡單，在centOS的軟件庫中搜索，點擊安裝
2.把遠程桌面的用戶加入到配置文件中
vim /etc/sysconfig/vncservers
使用vim編輯器打開配置文件，在文件中添加下面兩行命令
VNCSERVERS="1:root" --指定遠程用戶
VNCSERVERARGS[1]="-geometry 1024x768" --指定遠程桌面分辨率
3.給你剛剛設置的遠程桌面用戶 root 設置密碼
vncpasswd
4.開啟VNC端口
vim /etc/sysconfig/iptables
使用vim編輯器打開配置文件，在文件中添加下面一行命令
-A RH-Firewall-l-INPUT -p tcp -m tcp --dport 5900:5903 -j ACCEPT
5.重啟防火墻
service iptables restart
6.修改遠程桌面顯示配置文件（不修改此文件你看到的遠程桌面很簡單，相當于命令行操作，為了遠程操作如同本地操作一樣，務必參考以下方式進行修改）
cd ~/.vnc/
vim xstartup
使用vim編輯器打開配置文件，并進行下列修改
#xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" & --將它注釋，加#代表注釋
#twm & --將它注釋
gnome-session & --添加它
看了這段代碼，大家應該明白是怎么回事了
7.啟動vnc服務
service vncserver start
8.遠程連接
打開vnc客戶端，server框中輸入ip:1 (1代表上面配置的遠程用戶代號，配置文件中可以配置多個遠程用戶)，這時你便可以輕松的通過友好的遠程桌面來控制centOS了。
9.開機自動啟動vnc
vim /etc/rc.d/rc.local
使用vim編輯器打開配置文件，并進行下列修改
/etc/init.d/vncserver start --新增行
WINDOWS遠程連接：
主機ip+port
http://www.cnblogs.com/zxlovenet/p/4042959.html
LINUX下遠程桌面工具（可遠程WINDOWS）：
在Linux上配置訪問遠程桌面的軟件，這里我們需要安裝rdesktop和tsclient，其中rdesktop是基于命令行的工具，tsclient只是一個圖形化的界面，依賴于rdesktop。
登入gnome后打開終端
$yum install rdesktop
$yum install tsclient
如下圖的：Terminal Server Client
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
浮現在腦海的很多 Linux命令，其中一些不為人知，另一些則很常見，如下： xargs or parallel: 并行運行一些程序，命令有很多的選項
m4: 簡單的宏處理命令
screen: 功能強大的終端復用和會話持久工具，詳見http://www.ibm.com/developerworks/cn/linux/l-cn-screen/
yes: 重復輸出字符串 詳見 http://codingstandards.iteye.com/blog/826940
cal: 非常漂亮的日歷
env: 運行一個命令，在腳本中非常有用
look: 查找以字符串開頭英文單詞
cut and paste and join: 數據操作命令
fmt: 格式化一個文本段
pr: 以頁/列為單位格式化一串文本或一個較大文件，詳見 http://hi.baidu.com/mchina_tang/item/1ce11d5d317dfc05aaf6d70d
fold: 使文本換行
column: 格式化文本成列或表格
expand and unexpand: 在制表符和空格之間轉換
nl: 添加行號
seq: 打印行號
bc: 計算器
factor: 輸出整數的因數，factor輸出的為整數的質因數
nc: 網絡調試和數據傳輸
file: 判斷一個文件的類型
stat: 查看文件狀態
tac: 從最后一行輸出文件內容，和cat輸出是相反的
shuf: 對一個文件按行隨機選擇數據
comm: 按行比較一個有序文件
hd and bvi: 輸出或編輯二進制文件
strings: 查看二進制文件中的內容
tr: 字符翻譯或操作字符
iconv or uconv: 轉換編碼的字符串
split and csplit: 劃分文件
7z: 高壓縮率壓縮文件
ldd: 查看動態庫信息
nm: 查看目標文件中的符號表
strace: 調試系統調用
mtr: 網絡調試時能夠更好的進行路由跟蹤工具
wireshark and tshark: 數據包捕獲和網絡調試
host and dig: 查找DNS
lsof: 查看進程文件描述符和socket信息
dstat: 很有用的系統數據統計工具
iostat: CPU和磁盤使用統計
htop: top的改進版本
last: 登錄歷史
w: 當前登錄用戶
id: 查看用戶/組 表示信息
sar: 查看歷史系統統計數據工具
iftop or nethogs: 查看socket或者進程的網絡利用率
ss: 查看統計信息
dmesg: 啟動或者系統錯誤信息
(Linux) hdparm: 顯示或設定磁盤參數
(Linux) lsb_release: 查看linux系統發行版本信息
(Linux) lshw: 查看硬件信息
fortune, ddate, and sl: 這取決于你是否覺得蒸汽機或者比比語錄有用。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters