存儲我們要講兩點內容：
實存管理：
存儲我們只需要了解三種分配方法即 可：單一連續分配、固定分區分配、可變分區分配；其實我們經常講對于一些不好區分的概念，我們畫個表，把他們放在一起來進行對比，那么通過對比來理解，那 真的是太爽了；所以呢，我們也畫個表，把這幾個概念放在一起來進行區分和理解，看圖：
這樣一對比，我們就能看的出來，只有可變分區分配的空間是可變的；然后另外兩個分配是靜態的。其實顧名思義也就差不多能理解的差不多，沒有難度的，我們再深入一點來了解：看幾個圖：
單一連續分配：
我們可以看得出來，把整個內存區畫為一個區。它同一時間在內存當中只能裝入一個程序，只能用于單用戶、單任務的執行操作。
固定分區分配：
這個跟單一連續有相似之處，就是內存分配的還是比較固定了；但是這個分配還有自己的特點，就是把內存分為幾個塊，比如是：10K、22K、32K；那么 就會有可能能運行三個程序，當三個程序占用內存在這三個區域內的時候，我們就能運行。把這個分區給定死了，所以一旦有比這些區域要大的程序要運行，那么就 完蛋了，雖然總內存夠用，但是也不能運行，因為分區分的太死了。
可變分區：
打個比方：有三個過程，一開始和單一連續分配是一樣的，然后當有程序要運行的時候，就給該程序分配匹配的空間，當用完之后，釋放出來之后，又能拼湊成一個空白的區域，回到最初的狀態，特別靈活。
我們繼續對可變分區分配方式進行探討：
最佳適應法：選 擇等于或最接近需求的內存自由區進行分配。這種方法可以減少碎片，但同時也可能帶來更多小得無法再用的碎片。但是這個還算有弊端的，這個我們應該怎么理解 呢？比如我們有一個6K的空間，然后分配一個5K的空間給一個程序運行，那么剩余的1K一般來說就沒法利用了，因為一般很少有1K的程序要運行，所以這個 1K就成了碎片了，那么循環下來的話，就有很多碎片產生了。但是相對來說，這個分配方法還算是挺好的。
首次適應法：首次就是尋找第一個可用的，可用就是尋找大于等于作業需求的內存的自由區分配給作業。這個的好處就是縮短查找時間。
最差適應法：選擇整個主存中最大的內存自由區。比如我有一個5K的程序要運行，然后內存中最大的自由區是64K，那么一樣把64K分配給5K的程序運行，然后剩下的59K自由區還能繼續利用起來。
循環首次適應算法：不在每次都是從頭開始分配，而是連續向下匹配。我們畫個圖來理解：
比如我們的內存是這么個分配，那么我們現在有個作業需要12K內存占用，我們就從5K、10K、15K連續查找合適 的，當找到15K的時候，我們就分配給12K，那么當我們剩余的3K的時候，剛好有一個程序是3K的需要分配內容來運行，要是我們按照首次適應法來進行分 配，因為首次適應法是每次都是從頭開始的，所以我們就找到5K的區域，就把5K分配了；但是要是我們按照循環首次適應的話，我們是連續分配的，這樣我們就 能剛好把剩余的3K分配給這個程序了；這就是首次和循環首次的區別；我這么講應該沒有問題了吧。
虛存管理：
頁式存儲存儲管理：
通過用戶程序和內存的分塊，用戶程序分為n個頁面，頁表起記錄的作用。接下來我們看地址轉換圖：
這個就是我們的地址轉換器，我們想看這個是怎么個工作的，那么我們來看個例子，我們分析例子來進行理解：
我們設定頁面大小為4K，圖中的邏輯地址用十進制表示：我們來求a：
我們的過程應該是這樣的，我們的邏輯地址是8644（十進制的），那么轉換成二進制的為：10 0001 1100 0100；我們得知頁面為4K=2的12次方，所以頁內地址就為12位，所以a的后半部分為10 0001 1100 0100的后12位，為0001 1100 0100,那么剩下的最高兩位為頁號：10，轉換成十進制為2，然后找出物理塊號為8,8轉換成二進制位1000，所以物理快號頁內偏移拼合得1000 0001 1100 0100，化為十進制得33220。
其實只要我們懂得了這個過程，那么剩下的就是進制的轉換了，不難。
段式存儲組織
從用戶出發，將一個程序分成幾個塊：
我們有頁式存儲的基礎，這個就不在胯下，只是段的大小有點大。
我們再看看地址轉換：
這個算法跟咱們的頁式存儲是一樣的。大家動手試試。
存儲講起來挺有意思，我理解也許會有偏差，希望大家多多指正，不勝感激~
進程
1、進程的狀態：
這里邊我們主要是要講的內容就是這兩個圖：我們通過這兩個圖來介紹一些相關的知識點：
三態圖：
我們還是來看圖進行分析：
我們就這個圖進行分析各個關鍵部分：這些關鍵在于理解，很Easy的，或者你把這個圖畫出來也就馬上明白了。
就緒：就是“萬事俱備只欠東風”，就差CPU的調度了，只要CPU一調度便可運行。
運行：就是在就緒狀態的基礎上得到了CPU的調度。
等待（阻塞）：還沒具備運行條件，等待時機的狀態，我們從這個圖也能看的出來，等待狀態不能直接運行，必須要經過就緒這個狀態的，所以等待狀態除了等待CPU調度之外，還缺少某些運行所需的條件。
五態圖：
我們把幾個關鍵的概括一下：其實這個圖跟咱們上面那個三態圖是吻合的，只是把三態圖分的更細了點我覺得；所以分析五態圖咱們只需要把三態圖掌握好就行， 就這么easy；我們再看看幾個關鍵的：主要是三態圖的一個動態的一個表示過程，所以這些概念的東西，結合前面的三態圖理解就非常容易了：
就緒——>運行：就是三態圖中的，條件被CPU選中了。
運行——>就緒：運行超時或者是條件被更高優先級進程剝奪。
運行——>等待：條件還沒具備運行條件，等待某一事件的發生。
等待——>就緒：條件是等待的事件已發生，具備了運行條件。
在這里邊，還非常要主要這些箭頭的指向。
2、進程死鎖：
死鎖是進程管理設計不當造成的；進程死鎖是一個進程在等待一個不可能發生的事；系統死鎖是一個或多個進程產生死鎖。
其實對于這方面的知識，跟咱們生活是很有聯系的。比如我們使用過打印機都知道。所以把生活的場景投進去理解，就很簡單了。
死鎖產生的必要條件：
互斥條件：即一個資源每次只能被一個進程使用。
保持和等待條件：有一個進程已獲得了一些資源，但因請求其他資源被阻塞時，對已獲得的資源保持不放。
不剝奪條件：有些系統資源是不可剝奪的，當某個進程已獲得這種資源后，系統不能強行收回，只能由進程使用完時自己釋放。
環路等待條件：若干個進程形成環形鏈，每個都占用對方要申請的下一個資源。
解決死鎖的策略
死鎖預防：我們要求用戶申請資源時一起申請所需的全部資源，這就破壞了保持和等待條件：將資源分層，得到上一層資源后，才能申請下一層資源，它破壞了環路等待條件。預防通常會降低系統的效率。
死鎖避免：避免是指進程在每次申請資源時判斷這些操作是否安全，典型算法是”銀行家算法“。但這種算法會增加系統的開銷。
死鎖檢測：前兩者是事前措施，而死鎖的檢測則是判斷系統是否處于死鎖狀態，如果是，則執行死鎖解除策略。
死鎖解除：這是與死鎖檢測結合使用的，它使用的方式就是剝奪。即將資源強行分配給別的進程。
接下來，我們來實戰一下：
銀行家算法：
找了這么一個例子跟大家分析分析我的理解過程：
首先求剩下的資源數：
R1=9-（1+2+2++1）=2
R2=8-（2+1+1+2+1）=1
R3=5-（1+1+3）=0
我們從這個表中很容易的分析出：還需資源數=最大需求量-已分配資源數
那么需要一個系統是安全的，那么這個進程就不能產生死鎖?，F在就一目了然了都：
從我們剩下的資源數和還需要的資源數，我們剩下的R1=2、R2=1、R3=0這個只能符合P2進程的0、1、0；
那么我們給P1運行完成之后，我們的資源要釋放，所以我們資源=現有資源+已經分配的：
那么我們現在就有了R1、R2、R3的資源分別為：4、2、1；我們再觀察一下看哪個進程需要資源符合我們的釋放的資源的：
那只能是P4了，因為需要的資源為：0、0、1；而我們現在有的資源為：4、2、1，完全能滿足這個進程P4的要求；我們看圖：
那么這兩個進程就完成了，接下來我們還繼續對比著來看：
我們剩下的資源5、4、1。這時候我們發現了P5和P1都能滿足他們所需的資源：所以P5和P1就可以隨心所欲了，那我們不如就從需要資源小的開始分配試試；
這時候我們發現我們剩余的資源又能滿足到P3和P1進程了。所以我們的答案就不止一種了：
我們要是先分配P1，再分配P5，再到P3.結果就是：
雖然進程的這個順序有很多種，在都滿足不造成死鎖的情況下，是否有最優的排序呢？我覺得應該是有的，就是在不發生死鎖的情況下，我們應該是優先給予需要資源少的進程。
我們需要建一個自己的bug管理系統，我就自己動手自己安裝bugzilla了，在安裝之前我在網上google了一下，看了一個網友的安裝心得，不過基本上沒有在ubuntu/debian上安裝的。我就自己試著開始了。
不多說了：
sudo apt-get install mysql-server注意：需要設置mysql的root 用戶的密碼，注意要和以后的bugzilla的管理員密碼一致
sudo apt-get install bugzilla按照需要輸入管理員帳號，密碼
ubuntu把需要的apache，sendmail，還有那些依賴的perl模塊都一起安裝了.
開始配置bugzilla
配置apache2
vi /etc/apache2/httpd.conf 添加
ServerName localhost:80
//網上人坑爹把單詞拼錯了
sudo /etc/init.d/apache2 restart
配置bugzilla
vi /etc/bugzilla/localconfig
修改相應的配置：
$webservergroup = "www-data";
#
# How to access the SQL database:
#
$db_host = "localhost"; # where is the database?
$db_port = 3306; # which port to use
$db_name = "bugs"; # name of the MySQL database
$db_user = "bugs"; # user to attach to the MySQL database
//不用改數據庫 你安裝bugzallia的時候會讓你配置的 很簡單
#
# Some people actually use passwords with their MySQL database ...
#
$db_pass = "1234";
#
# Should checksetup.pl try to check if your MySQL setup is correct?
# (with some combinations of MySQL/Msql-mysql/Perl/moonphase this doesn"t work)
#
$db_check = 1;
$index_html = 1;
配置數據庫：
mysql -u root -p1234
Create database bugs;
GRANT SELECT, INSERT, UPDATE, DELETE, INDEX, ALTER, CREATE, LOCK TABLES,CREATE TEMPORARY TABLES, DROP, REFERENCES ON bugs.* TO bugs@localhost IDENTIFIED BY "1234";
Flush privileges；
quit;
退出數據庫；
重新生成bugzilla數據庫；
cd /usr/share/bugzilla/lib/
sudo perl checksetup.pl
根據提示輸入
注意：在ubuntu上安裝的bugzilla的主登錄窗口有點bug,需要從頁面地下的login按鈕進入就可以了。
據調查顯示，代碼審查工作有助于提高軟件開發質量，然而許多開發者卻不愿意在他們的團隊中實施代碼審查工作，本文主要分析了開發者為什么會抵制代碼審查工作的原因以及為什么他們會有此想法，目的是為了引導開發者加入代碼審查工作。
代碼審查究竟是什么樣的工作呢？通常情況下它是指否決質量的一種過程。大量統計數據表明代碼審查極大的提高了軟件質量以及降低了技術風險，不僅如此，它還降低了開發成本。
一起來看下代碼審查工作所帶來的好處：
如圖所示，代碼審查工作帶來這么多的益處，那為什么還有一些開發團隊拒絕這一做法呢？我們一起來分析下原因：
first ，better code starts with review
fight bad code ，and find more bugs with code review!
good code reviews
tackle your code and design requirements/docunments
文化問題或許已成為一種巨大的障礙，大部分開發者會厭惡代碼審查是因為他們無法忘記那些痛苦的審查會議，更槽糕的是，他們害怕因劣質代碼而遭到管理 者的批評與指責（這個通常是管理者自身的原因，而不是壞代碼）。代碼審查工作有助于提升團隊自身能力，我們應該持積極態度，而不是為了找機會來貶低同伴。
另一種可能性，當大家相互協作、積極互動時，管理者會誤認為大家在“聊天”。敏捷性團隊已經意識到快速創建軟件工作需要積極的互動與協作。他們認為堅持代碼審查工作，是通向成功的秘訣。
第三種可能性誤解，開發者利用靜態分析工具來查找bug，以致代碼審查工作成為不必要性。然而事實并非如此，Capers Jones，一位軟件質量度量領域的巨人，曾發表過一篇文章“結合視察、靜態分析和測試能消除影響效率缺陷的95%”，這種三叉戟式的方法最能確保軟件質 量。
靜態分析只是其中的一個分叉。
靜態分析工具有著很大的局限性，包括無法辨認出一些疑似代碼，比如，靜態分析工具不具備標記功能，因為它無法確定一個函數名為getRandomNumber是否應該總返回相同的值（with a hat tip toXKCD）。
Int getRandomNumber()
{<
return 4; //chosen by fair dice roll.
//guaranteed to be random
}
| |
也許代碼審查最大障礙是恐懼。開發者擔心錯過最后期限，害怕分心，害怕投入過多時間。要知道，這些都是愚蠢的想法，代碼審查的目的是在前端開發過程中最大限度的提高代碼質量以及幫助你縮短開發周期。
最后，我認為，調用一個進程（代碼審查工作）能夠促進團隊合作，提供指導且有助于技能的發展，鼓勵開發者熟悉代碼的基礎部分，最終可達到提高整 個軟 件質量。當然，如果您想快速輸入代碼，可以考慮一些代碼審查工具，前提是，你要確保該工具是輕量級并且有趣。一旦你習慣了使用該工具便有了依賴性（許多使 用代碼審工具用戶都這么認為）“我們無法想象沒有編碼工具的日子”，我想你會發現它們的價值所在。
無論如何，請記住，拒絕代碼審查是不可取的。
http://mirrors.163.com/centos/6.2/isos/i386/CentOS-6.2-i386-bin-DVD1.iso
6．3.6 POST Data
顯示通過Post方式數據信息
以下是mail.163.com登錄過程中POST Data，如下圖所示：
https://reg.163.com/logins.jsp?type=1&url=http://fm163.163.com/coremail/fcg/ntesdoor2?lightweight%3D1%26verifycookie%3D1%26language%3D-1%26style%3D-1
上面的紅框：application/x-www-form-urlencoded表示，post方式默認提交數據編碼
備注：以下為Post方式提交數據編碼幾種方式：
| text/plain | 以純文本的形式傳送 |
| application/x-www-form-urlencoded | 默認的編碼形式，即URL編碼形式 |
| multipart/form-data | MIME編碼，上傳文件的表單必須選擇該 |
Mime Type指的是如text/html,text/xml等類型
MIME>（Multipurpose Internet Email Extension），意為多用途Internet郵件擴展，它是一種多用途網際郵件擴充協議，在1992年最早應用于電子郵件系統，但后來也應用到瀏覽 器。服務器會將它們發送的多媒體數據的類型告訴瀏覽器，而通知手段就是說明該多媒體數據的MIME類型，從而讓瀏覽器知道接收到的信息哪些是MP3文件， 哪些是JPEG文件等等。當服務器把把輸出結果傳送到瀏覽器上的時候，瀏覽器必須啟動適當的應用程序來處理這個輸出文檔。在HTTP中，MIME類型被定 義在<head>、</head>部分的Content-Type中。
| 數據類型 | MIME類型 |
| 超文本標記語言文本 .htm,.html文件 | text/html（數據類別是text，種類是html，下同） |
| 純文本，.txt文件 | text/plain |
| RTF文本，.rtf文件 | application/rtf |
| GIF圖形，.gif文件 | image/gif |
| JPEG圖形，.jpeg, .jpg文件 | image/jpeg |
| au聲音，.au文件 | audio/basic |
| MIDI音樂，mid,.midi文件 | audio/midi,audio/x-midi |
| RealAudio音樂，.ra, .ram文件 | audio/x-pn-realaudio |
| MPEG，.mpg,.mpeg文件 | video/mpeg |
| AVI，.avi文件 | video/x-msvideo |
| GZIP，.gz文件 | application/x-gzip |
| TAR，.tar文件 | application/x-tar |
如上圖紅圈所表示，可以看到POST Data 中的password和username數據；
備注：get方法和Post方法區別
GET方法
GET方法是默認的HTTP請求方法，我們日常用GET方法來提交表單數據，然而用GET方法提交的表單數據只經過了簡單的編碼，同時它將作為URL的一部分向Web服務器發送，因此，如果使用GET方法來提交表單數據就存在著安全隱患上。例如
Http://127.0.0.1/login.jsp?Name=zhangshi&Age=30&Submit=%cc%E+%BD%BB
從上面的URL請求中，很容易就可以辯認出表單提交的內容。（？之后的內容）另外由于GET方法提交的數據是作為URL請求的一部分所以提交的數據量不能太大
POST方法
POST方法是GET方法的一個替代方法，它主要是向Web服務器提交表單數據，尤其是大批量的數據。POST方法克服了GET方法的一些缺點。通 過POST方法提交表單數據時，數據不是作為URL請求的一部分而是作為標準數據傳送給Web服務器，這就克服了GET方法中的信息無法保密和數據量太小 的缺點。因此，出于安全的考慮以及對用戶隱私的尊重，通常表單提交時采用POST方法。
7． >3.7 Content
統計顯示收到的Http響應信息
如下圖所示：可以查看
https://reg.163.com/logins.jsp?type=1&url=http://fm163.163.com/coremail/fcg/ntesdoor2?lightweight%3D1%26verifycookie%3D1%26language%3D-1%26style%3D-1
頁響應具體內容：
8． >3.8 Stream
顯示客戶端發送的數據，然后服務器端返回的數據
客戶端發送總數據：901 bytes sent to 218.107.55.86:80
客戶端接受到服務器端返回總數據：247 bytes received by 192.168.52.188.10720
以下用請求一個mail.163.com中的Logo圖標為例說明：
http://mimg.163.com/logo/163logo.gif
左邊：客戶端向服務器端發送數據流
1 GET /logo/163logo.gif HTTP/1.1
以上代碼中“GET”代表請求方法，“closea_d.js”表示URI，“HTTP/1.1代表協議和協議的版本。
2 Accept: */*
指示能夠接受的返回數據的范圍, */*表示所有
3 Referer: http://g1a114.mail.163.com/a/f/js3/0712240954/index_v6.htm
包含一個URL，用戶從該URL代表的頁面出發訪問當前請求的頁面
4 Accept-Language: zh-cn
表示能夠接受的返回數據的語言
5 Accept-Encoding: gzip, deflate
Accept-Encoding>表明了瀏覽器可接受的除了純文本之外的內容編碼的類型，比如gzip壓縮還是deflate壓縮內容。
6 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
客戶端標識瀏覽器類型
7 Host: mimg.163.com
訪問地址主機標識地址
8 Connection: Keep-Alive
保持Tcp連接(前臺已有備注，這里不做說明)
9Cookie: vjuids=-1b9063da8.1173d33f879.0.9aab8b85a459d; vjlast=1199406314; _ntes_nnid=a1e69963f40453af8a9ad171cc4cd8da,0|tech|; NTES_UFC=3000000100000000000000000000000000000000000000000000000000000000; Province=021; City=021; ntes_mail_firstpage=normal; NTES_SESS=68LUOUH9ewcCBFyN5OXZ_0qf._IOMCkFscaGYrooXpjtVF7r8Vx7jAzg7HGdWo00GQEn1ZmrZcX7FMAXnb052r8XOFZZYk.hN; NETEASE_SSN=mayingbao2002; NETEASE_ADV=11&23&1199409658752; Coremail=VDeAMrrrDFaTa%XCVwJiXXsRLSLkbLhZXXZGqPJkEXFKNt; wmsvr_domain=g1a114.mail.163.com
Cookies>沒什么說的，前面已列舉了
右邊：服務器端向客戶端返回數據流
1 HTTP/1.0 304 Not Modified
服務器告訴客戶，原來緩沖的文檔還可以繼續使用。
2 Date: Mon, 31 Dec 2007 21:42:27 GMT
發送HTTP消息的日期
3 Content-Type: image/gif
服務器返回請求類型是image/gif
4 Expires: Wed, 30 Jan 2008 21:42:27 GMT
指定實體的有效期
5 Last-Modified: Wed, 19 Apr 2006 03:46:16 GMT
指定被請求資源上次被修改的日期和時間
6 Age: 5607
表示Http接受到請求操作響應后的緩存時間
7 X-Cache: HIT from mimg68.nets.com
表示你的 http request 是由 proxy server 回的
8 Connection: keep-alive
保持Tcp請求連接狀態
9． >3.9 HttpWatch>請求信息框
菜單區如上圖紅框所示：
Started: >表示開始記錄請求一個URL時間
Time: >表示記錄請求耗費的時間
Sent: >表示客戶端向服務器端發送請求字節大小
Reveived:>表示客戶端收到服務端發送請求字節大小
Method: >表示請求URL方式
Result: >表示服務器返回到客戶端結果
以下是Httpwatch中http狀態碼列表
| 200 | OK/Success status code |
| 302 | Moved temporarily status code |
| 304 | Not modified status code |
| 401 | Access denied status code |
| 404 | Page or file not found |
| Aborted | Internet Explorer aborted the HTTP request before a response was received |
| (Cache) | Content read from cache without sending an HTTP request to the server |
| ERROR_* | An error occurred such as ERROR_INTERNET_NAME_NOT_RESOLVED |
| 2xx | Successful HTTP status code |
| 3xx | Redirection HTTP status code |
| 4xx | Client error HTTP status code |
| 5xx | Server error HTTP status code |
詳細Http狀態參數
| 態代碼 | 狀態信息 | 含義 |
| 100 | Continue | 初始的請求已經接受，客戶應當繼續發送請求的其余部分。（HTTP 1.1新） |
| 101 | Switching Protocols | 服務器將遵從客戶的請求轉換到另外一種協議（HTTP 1.1新） |
| 200 | OK | 一切正常，對GET和POST請求的應答文檔跟在后面。 |
| 201 | Created | 服務器已經創建了文檔，Location頭給出了它的URL。 |
| 202 | Accepted | 已經接受請求，但處理尚未完成。 |
| 203 | Non-Authoritative Information | 文檔已經正常地返回，但一些應答頭可能不正確，因為使用的是文檔的拷貝（HTTP 1.1新）。 |
| 204 | No Content | 沒有新文檔，瀏覽器應該繼續顯示原來的文檔。如果用戶定期地刷新頁面，而Servlet可以確定用戶文檔足夠新，這個狀態代碼是很有用的。 |
| 205 | Reset Content | 沒有新的內容，但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容（HTTP 1.1新）。 |
| 206 | Partial Content | 客戶發送了一個帶有Range頭的GET請求，服務器完成了它（HTTP 1.1新）。 |
| 300 | Multiple Choices | 客戶請求的文檔可以在多個位置找到，這些位置已經在返回的文檔內列出。如果服務器要提出優先選擇，則應該在Location應答頭指明。 |
| 301 | Moved Permanently | 客戶請求的文檔在其他地方，新的URL在Location頭中給出，瀏覽器應該自動地訪問新的URL。 |
| 302 | Found | 類似于301，但新的URL應該被視為臨時性的替代，而不是永久性的。注意，在HTTP1.0中對應的狀態信息是 “Moved Temporatily”。 出現該狀態代碼時，瀏覽器能夠自動訪問新的URL，因此它是一個很有用的狀態代碼。 注意這個狀態代碼有時候可以和301替換使用。例如，如果瀏覽器錯誤地請求http://host/~user（缺少了后面的斜杠），有的服務器返回 301，有的則返回302。 嚴格地說，我們只能假定只有當原來的請求是GET時瀏覽器才會自動重定向。請參見307。 |
| 303 | See Other | 類似于301/302，不同之處在于，如果原來的請求是POST，Location頭指定的重定向目標文檔應該通過GET提?。℉TTP 1.1新）。 |
| 304 | Not Modified | 客戶端有緩沖的文檔并發出了一個條件性的請求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務器告訴客戶，原來緩沖的文檔還可以繼續使用。 |
| 305 | Use Proxy | 客戶請求的文檔應該通過Location頭所指明的代理服務器提?。℉TTP 1.1新）。 |
| 307 | Temporary Redirect | 和302（Found）相同。許多瀏覽器會錯誤地響應302應答進行重定向，即使原來的請求是POST，即使它實際上只 能在POST請求的應答是303時才能重定向。由于這個原因，HTTP 1.1新增了307，以便更加清除地區分幾個狀態代碼：當出現303應答時，瀏覽器可以跟隨重定向的GET和POST請求；如果是307應答，則瀏覽器只 能跟隨對GET請求的重定向。（HTTP 1.1新） |
| 400 | Bad Request | 請求出現語法錯誤。 |
| 401 | Unauthorized | 客戶試圖未經授權訪問受密碼保護的頁面。應答中會包含一個WWW-Authenticate頭，瀏覽器據此顯示用戶名字/密碼對話框，然后在填寫合適的Authorization頭后再次發出請求。 |
| 403 | Forbidden | 資源不可用。服務器理解客戶的請求，但拒絕處理它。通常由于服務器上文件或目錄的權限設置導致。 |
| 404 | Not Found | 無法找到指定位置的資源。這也是一個常用的應答。 |
| 405 | Method Not Allowed | 請求方法（GET、POST、HEAD、DELETE、PUT、TRACE等）對指定的資源不適用。（HTTP 1.1新） |
| 406 | Not Acceptable | 指定的資源已經找到，但它的MIME類型和客戶在Accpet頭中所指定的不兼容（HTTP 1.1新）。 |
| 407 | Proxy Authentication Required | 類似于401，表示客戶必須先經過代理服務器的授權。（HTTP 1.1新） |
| 408 | Request Timeout | 在服務器許可的等待時間內，客戶一直沒有發出任何請求?？蛻艨梢栽谝院笾貜屯徽埱?。（HTTP 1.1新） |
| 409 | Conflict | 通常和PUT請求有關。由于請求和資源的當前狀態相沖突，因此請求不能成功。（HTTP 1.1新） |
| 410 | Gone | 所請求的文檔已經不再可用，而且服務器不知道應該重定向到哪一個地址。它和404的不同在于，返回407表示文檔永久地離開了指定的位置，而404表示由于未知的原因文檔不可用。（HTTP 1.1新） |
| 411 | Length Required | 服務器不能處理請求，除非客戶發送一個Content-Length頭。（HTTP 1.1新） |
| 412 | Precondition Failed | 請求頭中指定的一些前提條件失?。℉TTP 1.1新）。 |
| 413 | Request Entity Too Large | 目標文檔的大小超過服務器當前愿意處理的大小。如果服務器認為自己能夠稍后再處理該請求，則應該提供一個Retry-After頭（HTTP 1.1新）。 |
| 414 | Request URI Too Long | URI太長（HTTP 1.1新）。 |
| 416 | Requested Range Not Satisfiable | 服務器不能滿足客戶在請求中指定的Range頭。（HTTP 1.1新） |
| 500 | Internal Server Error | 服務器遇到了意料不到的情況，不能完成客戶的請求。 |
| 501 | Not Implemented | 服務器不支持實現請求所需要的功能。例如，客戶發出了一個服務器不支持的PUT請求。 |
| 502 | Bad Gateway | 服務器作為網關或者代理時，為了完成請求訪問下一個服務器，但該服務器返回了非法的應答。 |
| 503 | Service Unavailable | 服務器由于維護或者負載過重未能應答。例如，Servlet可能在數據庫連接池已滿的情況下返回503。服務器返回503時可以提供一個Retry-After頭。 |
| 504 | Gateway Timeout | 由作為代理或網關的服務器使用，表示不能及時地從遠程服務器獲得應答。（HTTP 1.1新） |
| 505 | HTTP Version Not Supported | 服務器不支持請求中所指明的HTTP版本。（HTTP 1.1新） |
Type:請求URL的類型
Type: 請求URL的類型
以下是Httpwatch中的URL的類型列表
| text/html | Normal html based content |
| text/css | Cascading style sheets |
| text/xml | XML data, e.g. SOAP requests and responses |
| text/* | Any textual content type including all the above types |
| image/gif | GIF image |
| image/jpg | JPEG image |
| image/* | Any image including gifs, jpgs and png files |
| application/x-javascript | Javascript |
| application/* | Any application content, e.g. flash files (application/x-shockwave-flash) |
URL:列出請求的URL具體地址
以下主要是HttpWatch菜單區的功能介紹:
10．3.10 Record
點擊”Record”按鈕開始錄制Http請求操作
11．3.11 Stop
點擊”Stop”按鈕停止錄制Http請求操作
12．3.12 Clear
點擊”Clear”按鈕,清除所有錄制Log記錄如下圖所示紅框中內容:
13．3.13 Summary
點擊”Summary”按鈕,顯示或隱藏所有請求信息概述
以下用httpwatch工具記錄打開http://www.google.cn/過程，Summary信息如下：
Perfomance信息如上圖所示：
Elapsed time Http URL請求時間總和
Network Round Trips 沒搞明白
Downloaded Data 客戶端接受到服務器端傳來的數據總和
Uploaded Data 客戶端發送到服務器端數據總和
Http compression savings http數據壓縮
DNS Lookups DNS解析
Tcp Connets Tcp連接
Status codes信息如上圖所示
Cache 表示緩存的數據有4處
200 ok 表示Http狀態代碼200 ok 1處
14．3.14 Find
點擊”Find”按鈕,可以打開一個查詢對話框,在日志記錄中去搜索字符串
15．3.15 Filter
點擊”Filter”按鈕, 可以打開一個過濾器對話框,如下圖所示
16．3.16 Save
點擊”Save”按鈕,可以打開保存對話框,如下圖所示:
可以保存的格式為.hwl (Httpwatch Log文件格式), .Xml, CVS格式
17．3.17 Help
點擊”Help”按鈕,沒什么說的,就是英語Help
2 四定位問題技巧
1． 4.1 巧用Filter功能過濾信息
假設懷疑yun.js有問題，當然你要對js程序要有了解，可使用Filter過濾器，直接將需要的yun.js找出，查看其是否存在問題！
YSlow分析網頁,并提出如何提高其性能的基礎上一套規則,高性能的網頁。我搜索一下”Yslow使用說明“，發現都是舊版本Yslow的使用介紹。于是翻譯了一下yahoo官方關于新版Yslow的的使用幫助，希望給初次使用Yslow的朋友一些幫助。
注：英文不是很好，對著翻譯軟件翻譯的，有不對的地方，大家指正。
安裝 YSlow
先安裝 Firebug https://addons.mozilla.org/en-US/firefox/addon/1843
Firebug 幫助文檔 http://www.getfirebug.com/docs.html.
再下載安裝 http://developer.yahoo.com/yslow
使用Yslow
Yslow是運行在Firebug窗口下，所有要運行Yslow，必須安裝Firebug。
有兩種方法啟動Yslow
1、打開Firebug窗口，選擇Yslow選項。
2、直接點擊瀏覽器右下角的Yslow啟動按鈕。
你第一次打開Yslow時，以下圖像作為Firebug的一部分被顯示在的瀏覽器窗口。
點擊 Run Test 運行Yslow，也可以點擊 Grade, Components, 或Statistics選項開始對頁面的分析。
你可以選擇 Autorun YSlow each time a web page is loaded 它將自動對以后打開頁面進行分析，
您也可以右擊YSlow狀態欄，然后選擇或取消自動運行。
Yslow視圖
YSlow顯示測試結果的分析,分為等級、組件、統計信息。你可以瀏覽這些觀點之間選擇標簽以觀的名字在YSlow標簽的Firebug控制臺。
以下是說明的等級、組件、統計信息。
一、等級視圖
查看一個分析,選擇頁面的性能等級標簽或點擊網頁的字母等級在狀態欄這頁紙的底部。
視圖顯示了等級為網頁的成績單。整個字母等級為頁面顯示在頂部隨著全面數值的表現。這個頁面是基于22可分級的高性能網頁的規則(見性能規則)。這些規則是列在按重要性的順序,從最重要不重要。從 A 級到 F 級，A 級為最高。
下面是一個等級的例子：
如果頁面與某一個規則無關，則顯示 N/A ，表示不適用。
點擊每一規則，都給出了改進建議。要查看更全面的改進方法進入前端性能優化指南
二、組件視圖
分組顯示頁面組件，表格列出組件的信息，點擊 Expand All展開顯示給個分組內各的組件信息。
下面簡要列在組件檢視表：
TYPE：該組件的類型。該網頁是由組成部分的下列類型： doc, js, css, flash, cssimage, image, redirect, favicon, xhr, and iframe.
SIZE(KB)：該組件的大小以千字節。
GZIP(KB)：該組件的gzip壓縮的大小以千字節。
COOKIE RECEIVED(bytes)：字節數在HTTP設置的Cookie響應頭。
COOKIE SENT(bytes)：節數的Cookie在HTTP請求報頭
HEADERS：HTTP信息頭，點擊放大鏡查看全面信息。
URL：鏈接地址
EXPIRES(Y/M/D)：日期的Expires頭，屬于緩存設置一種。
RESPONSE TIME (ms)：響應時間
ETAG：ETag響應頭，也是緩存設置的一種
ACTION：額外的性能分析
三、統計信息視圖
左側圖表顯示是頁面元素在空緩存的加載情況，右側為頁面元素使用緩存后的頁面加載情況。我們可以看到，頁面元素緩存后的使頁面的http請求和頁面總大小都減少，從而加快了頁面打開時間。參看（頁面的緩存設置）
YSlow菜單欄
一、規則集
1 、YSlow （ 2版） -這一規則集包含了所有22個測試的規則。
2 、精英（ V1導聯） -這個規則集包含原始13規則中使用了YSlow 1.0 。
3、小網站或博客-這個規則集包含14個規則，適用于小型網站或博客。參照下方的圖片，看看哪一種規則，在這個規則集。
請注意，最后選定的規則集成為默認的規則集。默認規則集可以是一個預定義的三個之一或您自己創建的一個。
要創建您自己的規則集，單擊Rulesets下拉菜單旁邊的 Edit 按鈕。新的規則集屏幕將顯示：
1、點擊左側 New Set 按鈕，出現全部22調規則，勾選你所需的
2、點擊 Save ruleset as... 保存，會彈出個命名窗口，命名就可以了。
3、你還可以對自定義的規則再次編輯或者刪除。
YSlow 工具
YSlow的工具菜單上提供了多種報告工具，您可以使用獲得的信息，以幫助您的網頁分析。以下是截圖工具菜單：
1、JSLint
JSLint收集所有外部和內部的JavaScript從目前的網頁，提交給JSLint ，一個JavaScript驗證，并打開一個單獨的窗口了一份報告，存在問題，該網頁的JavaScript的。該報告包括大致位置的源代碼的問題。很多 時候，這些問題是語法錯誤，但JSLint尋找風格公約的問題和結構性問題。
2、All JS
收集所有外部和內部的JavaScript的網頁，并顯示在一個單獨的腳本窗口。您可能想要使用這個工具來查看某個腳本，以及是否實際使用是正確的。
3、All JS Beautified
將js以人們可讀的方式展示。
4、All JS Minified
收集所有外部和內嵌JavaScript，刪除評論和白色空間以縮小的腳本。以改善網頁的性能。
5、All CSS
收集所有的行內和外部的樣式表在網頁上，并將其顯示在一個單獨的窗口。
6、All Smush.it
如果您按一下所有Smush.it ， Smush.it將運行在網頁上所有的圖片組成。此工具將告訴你該圖像可被優化，并創建一個壓縮文件，來優化圖像。當您選擇此工具你會看到輸出如下所示：
以上就是Yslow的使用指南，結束。
1、了解軟件的原始需求（測試目的） 在編寫一個軟件或者模塊的測試用例時候，一定要明白這個功能的原始需求，也就是軟件的使用者（客戶）的需求。理解原始需求后，編寫的測試用例才更有目的性。
2、熟悉軟件的功能需求（測試點）
這個功能需求是指軟件的細化需求點，這個一般在需求文檔里面都會體現。這里要做的是把 “粗略”的需求，細化成一個個小需求點。熟悉功能需求后，要知道軟件是怎么使用的，這也才能覆蓋到各種操作。
總之，測試用例一定要全部覆蓋所有的需求點，這是最基本的一點。
3、熟悉軟件的實現原理（測試點）
在理解原始需求和軟件的功能需求后，根據需求編寫的測試用例，基本上都能覆蓋得比較全面了。
在此基礎上，熟悉軟件的實現原理，理解軟件的內部處理。
?。?）熟悉原理的過程是進一步深入熟悉軟件的過程。如果單單是從需求點上面覆蓋案例，測試用例只能覆蓋“表面”的一層。一些內部的處理流程也許沒有覆蓋到，而這些沒有覆蓋到的代碼很可能就是一個風險點。
（2）熟悉模塊原理后，還有一點就是易于分析軟件模塊的關聯性。一個大型的軟件，都是一些小模塊的組合而成。軟件越是大型，耦合就越大，“互相影響”就會越多，若設計用例單單從模塊本身考慮的話，很可能就會對其他模塊造成風險。
4、用戶場景和網上問題（測試點）
從用戶的使用場景考慮，這在一些網絡設備比較重要，比如軟件后期在一些真實的使用環境中使用。
還要就是從一些網上問題總結出來的，那些地方容易出錯，在設計案例的時候需要考慮進去 。
5、測試用例的框架
一個測試用例的框架體現了一個測試人員在設計測試用例的整體思路。框架也是從大到小劃分下來，可以是：
UI界面，功能，容錯，兼容，性能等幾大類，每個大類在根據軟件的邏輯等進行劃分成小類，最后細分到測試點。
6、測試步驟（測試技巧方法）
前面4點都是從測試點的角度考慮，測試用例在完成測試點外，接下來就是測試步驟和測試結果啦。
測試用例可以寫的很詳細，也可以寫的比較簡單。這要看公司的要求，有些公司要求測試步驟很細很細，包括測試結果和測試步驟一一對應。
要求測試步驟寫的很詳細的公司，一般是怕執行人員的執行力不到位，導致沒有理解案例的目的，導致漏測。一般出現在新員工對軟件系統的不熟悉。
如果測試步驟寫的很詳細的話，會很耗時間，而且過于詳細的會限制執行人員的思維。個人認為測試用例的重點在于測試點上。
7、測試用例的一些思路
在設計測試用例中，通常較多使用的是邊界值，等價類，通過和不通過測試。下面從單個模塊或者單個功能點考慮：（結合一些網上文章的觀點）
?。?）UI界面：易用性，提示信息，整體布局，按鈕圖標，色彩，中英文標點錯別字。
?。?）數據的多樣性：有效數據，合法的無效數據（邊界值），非法的異常數據，產生錯誤輸出的合法數據組合等各種數據的組合。
?。?）操作多樣性：添加刪除編輯查詢 ，多用戶的操作。
（4）容量測試
?。?）用戶權限：使用權限，各種操作的權限。
?。?）升級安裝卸載：平滑升級
?。?）日志相關（包括調試日志）
（8）軟件功能的邏輯劃分：功能上劃分未能覆蓋的代碼邏輯，可以添加白盒灰盒用例。
?。?）可靠性，容錯性
?。?0）兼容性：瀏覽器，系統，支撐軟件。
?。?1）安全性
?。?2）性能（這里的性能是指，單個模塊或者子系統的性能）
總之測試用例首先要能覆蓋所有功能需求點，然后搞懂軟件處理邏輯，可以找開發一起看測試用例，把沒有覆蓋到的代碼流程相應的用例補充，至此，用例基本不會出現基本功能的問題。
在此基礎上，可以進行一些可靠性，容錯性，兼容性等用例的設計，測試下軟件的穩定性。
概述：什么是測試管理的藝術？在物聯網、云技術、移動互聯網的興起發展，三網合一成為大趨勢的未來，測試管理藝術又將何去何從呢？本文旨在與對測試管理感興趣的同仁進行探討。
名家名言
藝術不是你所看到的東西，而是你讓別人看到的東西。
——埃德加 德加（Edgar Hilaire Germain de Gas）
什么是測試管理的藝術？
一提到藝術我們馬上就會想到繪畫、雕塑、戲劇、建筑、舞蹈、詩歌等等，但在這里我們要討論的，是關于測試管理的藝術。首先我們來看，什么是測試？ISTQB為測試做了如下定義：
測試是一個過程，它包括了軟件生命周期的所有活動，有靜態的也有動態的。它涉及到計劃、準備和對軟件及其相關工作產品的評估，目的是
● 判定軟件或軟件的工作產品是否滿足特定需求；
● 證明它們是否符合目標；
● 發現缺陷。
但是什么時候做測試？是在產品將要完成的時候來做還是從產品需求定義的時候就開始做？實際經驗又告訴我們，如果在產品將要完成的時候再做測試那么就太晚了，預防缺陷遠比發現缺陷耗費的費用和時間少的多。所以，測試的目的應該是：
● 預防缺陷；
● 提供與產品質量相關的信息和信心；
● 發現缺陷。
什么是管理？
管：為了達成某一目的，行使一定的權力，組織分配人員執行任務。
理：在目標實現的過程中，控制過程，使其條理化、有序進行。
測試管理（manage）就是制定計劃、執行計劃、檢查和改進過程從而達到測試目的的一切方法和活動。制定計劃（或規定、規范、標準、法規等）是設計達 到目標的路徑，將整體的大目標分成一個個階段性的小目標，確定實現階段性目標所需要采取的戰略措施，部署相應的人力、物力、規定走向目標時應該遵循的規 范、標準、法規和過程等；執行就是按照計劃去做，即實施；檢查就是將執行的過程或結果與計劃進行對比，總結出經驗，找出差距；改進首先是推廣通過檢查總結 出的經驗，將經驗轉變為長效機制或新的規定；再次是針對檢查發現的問題進行糾正，制定糾正、預防措施，以持續改進。
測試管理的藝術就是創造管理方法和技巧，創造性的運用管理方法和技巧實現測試的目的。它應該是基于實踐的，與時俱進的，同時也是感性的，反映人類內心的情感和訴求，反映對理想的追求。因為只有這樣的藝術才會有生命力。
回顧國際上的管理學藝術之路，我們可以看到管理學經歷了兩大階段：
第一階段：從行為科學到戰略管理
從個體行為到組織行為（1956—1965）
從組織中的人到人的組織（1966—1975）
從過程管理到戰略管理（1976—1985）
第二階段：從組織變革到知識管理 從職能組織到變革組織（1986—1995）
從組織管理到知識管理（1996—2005）
回顧軟件測試的目的演變，我們可以看到如下的脈絡：
以調試為主（從有軟件開始-1956）
證明程序是正確的（1957–1978）
證明程序中有錯誤（1979–1982）
評估產品能力（1983–1987）
預防缺陷（1988–1992）
預防缺陷，發現缺陷，評估質量（1992– ）
管理理念方法和技巧都是以目標為導向的。當我們的目標發生了變化的時候，管理的藝術也隨之得到了發展。我們可以清楚的看到管理藝術隨著測試目的的變化而變化，在有一個時間上一一對應（或者略帶滯后）的關系。
比如在測試目的從“調試”轉換到“證明程序是正確的”時，也是管理藝術從個體行為到組織行為轉變的過程。再比如，當測試的目的從“證明程序中有錯誤”改變為“評估產品能力”時，管理藝術也經歷了從過程管理到戰略管理的轉換。
隨著物聯網、云技術、移動互聯網的興起和發展，測試管理也受到了空前未有的挑戰，因為測試對象的開發規模，組織形式，應用范圍以及對人類生活的影響都產生了前所未有的革命。如何創造管理方法和技巧，創造性地運用管理方法和技巧來適應這場革命成為我們必須面對的課題。
筆者以為，未來的測試組織和測試過程應該體現：效率 Performance，安全 Security，隨時可取 Availability，靈活收放 Scalability的特性。
未來的測試管理應該是
● 多種軟件生命周期的組合 – V模型和敏捷開發敏捷測試的一體化；
● 多種測試組織形式的組合 – 內包、外包、研發測試人員角色互換，獨立測試團隊，第三方測試多種測試組織形式的一體化；
● 多種文化交融，超越地域分布，集目標管理、知識管理、人才管理、信息化管理為一體。
只有這樣，我們才能與時俱進，適應新的形勢發展，創造出新的測試管理藝術。
讓我們聽從內心的直覺，聽從內心對美的呼喚和追求，一起去探索尋求21世紀新的測試管理藝術，并將這些藝術表現出來。因為正如法國古典印象主義畫家埃德加.德加（Edgar Hilaire Germain de Gas）所說的：
“藝術不是你所看到的東西，而是你讓別人看到的東西。”