1.系統集成的模式與方法
1.1 軟件集成測試前的準備
◇人員安排
◇測試計劃
◇測試內容
◇集成模式
◇測試方法
1.2 集成測試的模式
漸增式測試模式與非漸增式測試模式
非漸增式測試模式：先分別測試每個模塊，再把所有模塊按設計要求放在一起結合成所要的程序，如大棒模式。
漸增式測試模式：把下一個要測試的模塊同已經測試好的模塊結合起來進行測試，測試完以後再把下一個應該測試的模塊結合進來測試。
1.3 自頂向下和自底向上集成方法
驅動程序/驅動模塊（driver），用以模擬被測模塊的上級模塊。驅動模塊在集成測試中接受測試數據，把相關的數據傳送給被測模塊，啓動被測模塊，並打印出相應的結果。
樁程序/樁模塊（stub），也有人稱爲存根程序，用以模擬被測模塊工作過程中所調用的模塊。樁模塊由被測模塊調用，它們一般只進行很少的數據處理，例如打印入口和返回，以便於檢驗被測模塊與其下級模塊的接口
1.3.1 自頂向下法(Top-down Integration)
1.3.2 自底向上法(Bottom-up Integration)
1.3.3 混合策略(Modified Top-down Integration)
混合法：對軟件結構中較上層，使用的是“自頂向下”法；對軟件結構中較下層，使用的是“自底向上”法，兩者相結合
1.3.4 大棒集成方法(Big-bang Integration)
採用大棒集成方法,先是對每一個子模塊進行測試（單元測試階段），然後將所有模塊一次性的全部集成起來進行集成測試 。
因爲所有的模塊一次集成的，所以很難確定出錯的真正位置、所在的模塊、錯誤的原因。這種方法並不推薦在任何系統中使用，適合在規模較小的應用系統中使用。
1.3.5 三明治集成方法(Sandwich Integration)
採用三明治方法的優點是：它將自頂向下和自底向上的集成方法有機地結合起來，不需要寫樁程序因爲在測試初自底向上集成已經驗證了底層模塊的正確性。採用這種方法的主要缺點是：在真正集成之前每一個獨立的模塊沒有完全測試過。
改善的三明治集成方法
改進的三明治集成方法，不僅自兩頭向中間集成，而且保證每個模塊得到單獨的測試，使測試進行得比較徹底 。
1.4 幾種集成方法性能的比較
2.功能測試
2.1 目的和內容
程序安裝、啓動正常，有相應的提示框、錯誤提示等
每項功能符合實際要求
系統的界面清晰、美觀
菜單、按鈕操作正常、靈活，能處理一些異常操作
能接受正確的數據輸入，對異常數據的輸入有提示、容錯處理等
數據的輸出結果準確，格式清晰，可以保存和讀取
功能邏輯清楚，符合使用者習慣
系統的各種狀態按照業務流程而變化，並保持穩定
支持各種應用的環境
能配合多種硬件周邊設備
軟件升級後，能繼續支持舊版本的數據
與外部應用系統的接口有效
2.2 功能測試的方法
等價類劃分法
邊界值分析法
錯誤推測法
因果圖法
組合分析法
2.2.1 等價類劃分法
劃分好等價類測試：防止遺漏測試案例。
2.2.2 邊界值分析法
例子：排序程序，邊界條件有：
序列爲空；
序列僅有一個數據；
序列爲滿，用猜錯法補充一下測試用例；
序列已經按要求排好序；
序列的順序與要求的順序恰好相反；
序列中的所有數據全部相等。
因爲錯誤最容易發生在邊界值附近，所以邊界值分析法對於多變量函數的測試很有效，尤其是對於像C/C++數據類型要求不是很嚴格的語言有利 。
2.2.3 錯誤推測法
這個錯誤到底在哪呢？
2.2.4 因果圖法
2.2.5 組合分析法
組合分析是一種基於每對參數組合的測試技術，主要考慮參數之間的影響是主要的錯誤來源和大多數的錯誤起源於簡單的參數組合。
3.系統測試
迴歸測試（Regression test）
壓力測試 (Stress test)
容量測試 (Capacity test)
性能測試 (Performance test)
安全測試 (Security test)
容錯測試 (Recovery test)
可靠性測試（Reliability test）
3.1 迴歸測試
迴歸測試的目的
所做的修改達到了預定的目的，如錯誤得到了改正，新功能得到了實現，能夠適應新的運行環境等；
不影響軟件原有功能的正確性。
迴歸測試的方法
再測試全部用例
基於風險選擇測試
基於操作剖面選擇測試
再測試修改的部分
迴歸測試的組織和實施
3.2 壓力測試，容量測試和性能測試
壓力測試、容量測試和性能測試的測試目的雖然有所不同，但其手段和方法在一定程度上比較相似，通常會使用特定的測試工具，來模擬超常的數據量、負載等，監測系統的各項性能指標，如CPU和內存的使用情況、響應時間、數據傳輸量等。
3.3 性能測試
看看在各種情況下CPU使用的效率
性能測試的目的： 爲了驗證系統是否達到用戶提出的性能指標，同時發現系統中存在的性能瓶頸，起到優化系統的目的。
性能測試指標的來源： 用戶對各項指標提出的明確需求；如果用戶沒有提出性能指標則根據用戶需求、測試設計人員的經驗來設計各項測試指標。（需求+經驗）
主要的性能指標： 服務器的各項指標（CPU、內存佔用率等）、後臺數據庫的各項指標、網絡流量、響應時間
性能測試要點：
測試環境應儘量與產品運行環境保持一致，應單獨運行儘量避免與其他軟件同時使用。
性能測試一般使用測試工具和測試人員編制測試腳本來完成。
性能測試的重點在於前期數據的設計與後期數據的分析。
性能測試的用例主要涉及到整個系統架構的問題，所以測試用例一旦生成，改動一般不大，所以做性能測試的重複使用率一般比較高。
性能測試的方法和技巧：
兩種負載類型：
“flat”測試
ramp-up測試
對於企業級的系統，性能測試的方法主要有：
基準測試
性能規劃測試
滲入測試
峯谷測試
兩種負載類型：
3.3.1 “Flat”測試
對於一次給定的測試，應該取響應時間和吞吐量的平均值。精確地獲得這些值的唯一方法是一次加載所有的用戶，然後在預定的時間段內持續運行。
3.3.2 Ramp-up測試:
用戶是交錯上升的（每幾秒增加一些新用戶）。ramp-up測試不能產生精確和可重現的平均值，這是因爲由於用戶的增加是每次一部分，系統的負載在不斷地變化。其優點是，可以看出隨着系統負載的改變，測量值是如何改變的?據此選擇要運行的flat測試的範圍。
3.3.3 基準測試
將系統置於相同的高負載下，將請求之間間隔時間設爲零。這樣服務器會立即超載，並開始構建執行隊列。如果請求（虛擬用戶）數保持一致，基準測試的結果會非常精確? flat運行是獲得基準測試數據的理想模式
3.3.4 性能規劃測試
性能規劃類型的測試其目標是找出在特定的環境下，給定應用程序的性能可以達到何種程度。例如，如果要以5秒或更少的響應時間支持8,000個當前用戶，需要多少個服務器？
要確定系統的容量，需要考慮幾個因素:
用戶中有多少是併發與服務器通信的。
每個用戶的請求間時間間隔是多少。
如何加載用戶以模擬負載狀態？
最好的方法是模擬高峯時間用戶與服務器通信的狀況。
如果用戶負載狀態是在一段時間內逐步達到的,選擇ramp-up測試，每隔幾秒增加x個用戶;
如果所有用戶是在一個非常短的時間內同時與系統通信，就應該使用flat測試，將所有的用戶同時加載到服務器
什麼是確定容量的最好方法？
結合兩種負載類型的優點，並運行一系列的測試
如：首先使用ramp-up測試確定系統支持的用戶範圍?該範圍內不同的併發用戶負載進行一系列的flat測試，更精確地確定系統的容量。
3.3.5 滲入測試
滲入測試是一種比較簡單的性能測試。滲入測試所需時間較長，它使用固定數目的併發用戶測試系統的總體健壯性。這些測試將會通過內存泄漏、增加的垃圾收集(GC)或系統的其他問題，顯示因長時間運行而出現的任何性能降低。
建議運行兩次測試——一次使用較低的用戶負載（要在系統容量之下，以便不會出現執行隊列），一次使用較高的負載（以便出現積極的執行隊列）。
3.3.6 峯谷測試
兼有容量規劃ramp-up測試和滲入測試的特徵,目標是確定從高負載（例如系統高峯時間的負載）恢復、轉爲幾乎空閒、然後再攀升到高負載、再降低的能力。
性能測試的過程:
一、輸入框
1、字符型輸入框：
（1）字符型輸入框：英文全角、英文半角、數字、空或者空格、特殊字符“~！@#￥%……&*？[]{}”特別要注意單引號和&符號。禁止直接輸入特殊字符時，使用“粘貼、拷貝”功能嘗試輸入。
（2）長度檢查：最小長度、最大長度、最小長度-1、最大長度+1、輸入超工字符比如把整個文章拷貝過去。
（3）空格檢查：輸入的字符間有空格、字符前有空格、字符後有空格、字符前後有空格
（4）多行文本框輸入：允許回車換行、保存後再顯示能夠保存輸入的格式、僅輸入回車換行，檢查能否正確保存（若能，檢查保存結果，若不能，查看是否有正常提示）、
（5）安全性檢查：輸入特殊字符串（null,NULL, ,javascript,<script>,</script>,<title>,<html>,<td>）、輸入腳本函數(<script>alert("abc")</script>)、doucment.write("abc")、<b>hello</b>）
2、數值型輸入框：
（1）邊界值：最大值、最小值、最大值+1、最小值-1
（2）位數：最小位數、最大位數、最小位數-1最大位數+1、輸入超長值、輸入整數
（3）異常值、特殊字符：輸入空白（NULL）、空格或"~!@#$%^&*()_+{}|[]\:"<>?;',./?;:'-=等可能導致系統錯誤的字符、禁止直接輸入特殊字符時，嘗試使用粘貼拷貝查看是否能正常提交、word中的特殊功能，通過剪貼板拷貝到輸入框，分頁符，分節符類似公式的上下標等、數值的特殊符號如∑，㏒，㏑，∏，+，-等、
輸入負整數、負小數、分數、輸入字母或漢字、小數（小數前0點捨去的情況，多個小數點的情況）、首位爲0的數字如01、02、科學計數法是否支持1.0E2、全角數字與半角數字、數字與字母混合、16進制，8進制數值、貨幣型輸入（允許小數點後面幾位）、
（4）安全性檢查：不能直接輸入就copy
3、日期型輸入框：
（1）合法性檢查：(輸入0日、1日、32日)、月輸入[1、3、5、7、8、10、12]、日輸入[31]、月輸入[4、6、9、11]、日輸入[30][31]、輸入非閏年，月輸入[2]，日期輸入[28、29]、輸入閏年，月輸入[2]、日期輸入[29、30]、月輸入[0、1、12、13]
(2)異常值、特殊字符：輸入空白或NULL、輸入~！@#￥%……&*（）{}[]等可能導致系統錯誤的字符
（3）安全性檢查：不能直接輸入，就copy，是否數據檢驗出錯？
4、信息重複:在一些需要命名,且名字應該唯一的信息輸入重複的名字或ID,看系統有沒有處理,會否報錯,重名包括是否區分大小寫,以及在輸入內容的前後輸入空格,系統是否作出正確處理.
二、搜索功能
若查詢條件爲輸入框，則參考輸入框對應類型的測試方法
1、功能實現：
（1）如果支持模糊查詢，搜索名稱中任意一個字符是否能搜索到
（2）比較長的名稱是否能查到
（3）輸入系統中不存在的與之匹配的條件
（4）用戶進行查詢操作時，一般情況是不進行查詢條件的清空，除非需求特殊說明。
2、組合測試：
（1）不同查詢條件之間來回選擇，是否出現頁面錯誤（單選框和多選框最容易出錯）
（2）測試多個查詢條件時，要注意查詢條件的組合測試，可能不同組合的測試會報錯。
三、添加、修改功能
1、特殊鍵：（1）是否支持Tab鍵 （2）是否支持回車鍵
2、提示信息：（1）不符合要求的地方是否有錯誤提示
3、唯一性：（1）字段唯一的，是否可以重複添加，添加後是否能修改爲已存在的字段（字段包括區分大小寫以及在輸入的內容前後輸入空格，保存後，數據是否真的插入到數據庫中，注意保存後數據的正確性）
4、數據 正確性：
（1）對編輯頁的每個編輯項進行修改，點擊保存，是否可以保存成功，檢查想關聯的數據是否得到更新。
（2）進行必填項檢查（即是否給出提示以及提示後是否依然把數據存到數據庫中；是否提示後出現頁碼錯亂等）
（3）是否能夠連續添加（針對特殊情況）
（4）在編輯的時候，注意編輯項的長度限制，有時在添加的時候有，在編輯的時候卻沒有（注意要添加和修改規則是否一致）
（5）對於有圖片上傳功能的編輯框，若不上傳圖片，查看編輯頁面時是否顯示有默認的圖片，若上傳圖片，查看是否顯示爲上傳圖片
（6）修改後增加數據後，特別要注意查詢頁面的數據是否及時更新，特別是在首頁時要注意數據的更新。
（7）提交數據時，連續多次點擊，查看系統會不會連續增加幾條相同的數據或報錯。
（8）若結果列表中沒有記錄或者沒選擇某條記錄，點擊修改按鈕，系統會拋異常。
四、刪除功能
1、特殊鍵：（1）是否支持Tab鍵 （2）是否支持回車鍵
2、提示信息：（1）不選擇任何信息，直接點擊刪除按鈕，是否有提示（2）刪除某條信息時，應該有確認提示
3、數據 實現：（1）是否能連續刪除多個產品（2）當只有一條數據時，是否可以刪除成功 （3）刪除一條數據後，是否可以添加相同的數據（4）如系統支持批量刪除，注意刪除的信息是否正確 （5）如有全選，注意是否把所有的數據刪除（6）刪除數據時，要注意相應查詢頁面的數據是否及時更新 （7）如刪除的數據與其他業務數據關聯，要注意其關聯性（如刪除部門信息時，部門下游員工，則應該給出提示）（8）如果結果列表中沒有記錄或沒有選擇任何一條記錄，點擊刪除按鈕系統會報錯。
如：某一功能模塊具有最基本的增刪改查功能，則需要進行以下測試
單項功能測試（增加、修改、查詢、刪除）
增加——>增加——>增加 （連續增加測試）
增加——>刪除
增加——>刪除——>增加 （新增加的內容與刪除內容一致）
增加——>修改——>刪除
修改——>修改——>修改 （連續修改測試）
修改——>增加（新增加的內容與修改前內容一致）
修改——>刪除
修改——>刪除——>增加 （新增加的內容與刪除內容一致）
刪除——>刪除——>刪除 （連續刪除測試）
五、註冊、登陸模塊
1、註冊功能：
（1）註冊時，設置密碼爲特殊版本號，檢查登錄時是否會報錯
（2）註冊成功後，頁面應該以登陸狀態跳轉到首頁或指定頁面
（3）在註冊信息中刪除已輸入的信息，檢查是否可以註冊成功。
2、登陸 功能：
（1）輸入正確的用戶名和正確的密碼
（2）輸入正確的用戶名和錯誤的密碼
（3）輸入錯誤的用戶名和正確的密碼
（4）輸入錯誤的用戶名和錯誤的密碼
（5）不輸入用戶名和密碼（均爲空格）
（6）只輸入用戶名，密碼爲空
（7）用戶名爲空，只輸入密碼
（8）輸入正確的用戶名和密碼，但是不區分大小寫
（9）用戶名和密碼包括特殊字符
（10）用戶名和密碼輸入超長值
（11）已刪除的用戶名和密碼
（12）登錄時，當頁面刷新或重新輸入數據時，驗證碼是否更新
六、上傳圖片測試
1、功能 實現：
（1）文件類型正確、大小合適
（2）文件類型正確，大小不合適
（3）文件類型錯誤，大小合適
（4）文件類型和大小都合適，上傳一個正在使用中的圖片
（5）文件類型大小都合適，手動輸入存在的圖片地址來上傳
（6）文件類型和大小都合適，輸入不存在的圖片地址來上傳
（7）文件類型和大小都合適，輸入圖片名稱來上傳
（8）不選擇文件直接點擊上傳，查看是否給出提示
（9）連續多次選擇不同的文件，查看是否上傳最後一次選擇的文件
七、查詢結果列表
1、功能 實現：
（1）列表、列寬是否合理
（2）列表數據太寬有沒有提供橫向滾動
（3）列表的列名有沒有與內容對應
（4）列表的每列的列名是否描述的清晰
（5）列表是否把不必要的列都顯示出來
（6）點擊某列進行排序，是否會報錯（點擊查看每一頁的排序是否正確）
（7）雙擊或單擊某列信息，是否會報錯
八、返回鍵檢查
1、一條已經成功提交的記錄，返回後再提交，是否做了處理
2、檢查多次使用返回鍵的情況，在有返回鍵的地方，返回到原來的頁面多次，查看是否會出錯
九、回車鍵檢查
1、在輸入結果後，直接按回車鍵，看系統如何處理，是否會報錯
十、刷新鍵檢查
1、在Web系統中，使用刷新鍵，看系統如何處理，是否會報錯
十一、直接URL鏈接檢查
1、在Web系統中，在地址欄直接輸入各個功能頁面的URL地址，看系統如何處理，是否能夠直接鏈接查看（匿名查看），是否有權限控制，是否直接執行，並返回相應結果頁；
十二、界面和易用性測試
1、風格、樣式、顏色是否協調
2、界面佈局是否整齊、協調（保證全部顯示出來的，儘量不要使用滾動條
3、界面操作、標題描述是否恰當（描述有歧義、注意是否有錯別字） |
4、操作是否符合人們的常規習慣（有沒有把相似的功能的控件放在一起，方便操作）
5、提示界面是否符合規範（不應該顯示英文的cancel、ok，應該顯示中文的確定等）
6、界面中各個控件是否對齊
7、日期控件是否可編輯
8、日期控件的長度是否合理，以修改時可以把時間全部顯示出來爲準
9、查詢結果列表列寬是否合理、標籤描述是否合理
10、查詢結果列表太寬沒有橫向滾動提示
11、對於信息比較長的文本，文本框有沒有提供自動豎直滾動條
12、數據錄入控件是否方便
13、有沒有支持Tab鍵，鍵的順序要有條理，不亂跳
14、有沒有提供相關的熱鍵
15、控件的提示語描述是否正確
16、模塊調用是否統一，相同的模塊是否調用同一個界面
17、用滾動條移動頁面時，頁面的控件是否顯示正常
18、日期的正確格式應該是XXXX-XX-XX或XXXX-XX-XX XX:XX:XX
19、頁面是否有多餘按鈕或標籤
20、窗口標題或圖標是否與菜單欄的統一
21、窗口的最大化、最小化是否能正確切換
22、對於正常的功能，用戶可以不必閱讀用戶手冊就能使用
23、執行風險操作時，有確認、刪除等提示嗎
24、操作順序是否合理
25、正確性檢查：檢查頁面上的form, button, table, header, footer,提示信息，還有其他文字拼寫，句子的語法等是否正確。
26、系統應該在用戶執行錯誤的操作之前提出警告，提示信息.
27、頁面分辨率檢查，在各種分辨率瀏覽系統檢查系統界面友好性。
28、合理性檢查：做delete, update, add, cancel, back等操作後，查看信息回到的頁面是否合理。
29、檢查本地化是否通過：英文版不應該有中文信息，英文翻譯準確，專業。
十三、兼容性測試
兼容性測試不只是指界面在不同操作系統或瀏覽器下的兼容，有些功能方面的測試，也要考慮到兼容性，
包括操作系統兼容和應用軟件兼容，可能還包括硬件兼容
比如涉及到ajax、jquery、javascript等技術的，都要考慮到不同瀏覽器下的兼容性問題。
十四、鏈接測試
主要是保證鏈接的可用性和正確性，它也是網站測試中比較重要的一個方面。
可以使用特定的工具如XENU來進行鏈接測試。
1導航測試
導航描述了用戶在一個頁面內操作的方式，在不同的用戶接口控制之間，例如按鈕、對話框、列表和窗口等；或在不同的連接頁面之間。通過考慮下列問題，可以決定一個Web應用系統是否易於導航：導航是否直觀？Web系統的主要部分是否可通過主頁存取？Web系統是否需要站點地圖、搜索引擎或其他的導航幫助？
在一個頁面上放太多的信息往往起到與預期相反的效果。Web應用系統的用戶趨向於目的驅動，很快地掃描一個Web應用系統，看是否有滿足自己需要的信息，如果沒有，就會很快地離開。很少有用戶願意花時間去熟悉Web應用系統的結構，因此，Web應用系統導航幫助要儘可能地準確。
導航的另一個重要方面是Web應用系統的頁面結構、導航、菜單、連接的風格是否一致。確保用戶憑直覺就知道Web應用系統裏面是否還有內容，內容在什麼地方。
Web應用系統的層次一旦決定，就要着手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯。
2圖形測試
在Web應用系統中，適當的圖片和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。一個Web應用系統的圖形可以包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試的內容有：
（1）要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。Web應用系統的圖片尺寸要儘量地小，並且要能清楚地說明某件事情，一般都鏈接到某個具體的頁面。
（2）驗證所有頁面字體的風格是否一致。
（3）背景顏色應該與字體顏色和前景顏色相搭配。
（4）圖片的大小和質量也是一個很重要的因素，一般採用JPG或GIF壓縮，最好能使圖片的大小減小到30k以下
（5）最後，需要驗證的是文字迴繞是否正確。如果說明文字指向右邊的圖片，應該確保該圖片出現在右邊。不要因爲使用圖片而使窗口和段落排列古怪或者出現孤行。
通常來說，使用少許或儘量不使用背景是個不錯的選擇。如果您想用背景，那麼最好使用單色的，和導航條一起放在頁面的左邊。另外，圖案和圖片可能會轉移用戶的注意力。
十五、業務流程測試（主要功能測試）
業務流程，一般會涉及到多個模塊的數據，所以在對業務流程測試時，首先要保證單個模塊功能的正確性，其次就要對各個模塊間傳遞的數據進行測試，這往往是容易出現問題的地方，測試時一定要設計不同的數據進行測試。
十六、安全性測試
（1）SQL注入（比如登陸頁面）
（2）XSS跨網站腳本***：程序或數據庫沒有對一些特殊字符進行過濾或處理，導致用戶所輸入的一些破壞性的腳本語句能夠直接寫進數據庫中，瀏覽器會直接執行這些腳本語句，破壞網站的正常顯示，或網站用戶的信息被盜,構造腳本語句時，要保證腳本的完整性。
document.write("abc")
<script>alter("abc")</script>
（3）URL地址後面隨便輸入一些符號，並儘量是動態參數靠後
（4）驗證碼更新問題
（5）現在的Web應用系統基本採用先註冊，後登陸的方式。因此，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。
（6）Web應用系統是否有超時的限制，也就是說，用戶登陸後在一定時間內（例如15分鐘）沒有點擊任何頁面，是否需要重新登陸才能正常使用。
（7）爲了保證Web應用系統的安全性，日誌文件是至關重要的。需要測試相關信息是否寫進了日誌文件、是否可追蹤。
（8）當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。
（9）服務器端的腳本常常構成安全漏洞，這些漏洞又常常被***利用。所以，還要測試沒有經過授權，就不能在服務器端放置和編輯腳本的問題。
十七、性能測試
1連接速度測試
用戶連接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統響應時間太長（例如超過5秒鐘），用戶就會因沒有耐心等待而離開。
另外，有些頁面有超時的限制，如果響應速度太慢，用戶可能還沒來得及瀏覽內容，就需要重新登陸了。而且，連接速度太慢，還可能引起數據丟失，使用戶得不到真實的頁面。
2負載測試
負載測試是爲了測量Web系統在某一負載級別上的性能，以保證Web系統在需求範圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統的用戶數量，也可以是在線數據處理的數量。例如：Web應用系統能允許多少個用戶同時在線？如果超過了這個數量，會出現什麼現象？Web應用系統能否處理大量用戶對同一個頁面的請求？
3壓力測試
負載測試應該安排在Web系統發佈以後，在實際的網絡環境中進行測試。因爲一個企業內部員工，特別是項目組人員總是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，所以，只有放在Internet上，接受負載測試，其結果纔是正確可信的。
進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼情況下會崩潰。***常常提供錯誤的數據負載，直到Web應用系統崩潰，接着當系統重新啓動時獲得存取權。
壓力測試的區域包括表單、登陸和其他信息傳輸頁面等。
備註：
1、負載/壓力測試應該關注什麼
測試需要驗證系統能否在同一時間響應大量的用戶，在用戶傳送大量數據的時候能否響應，系統能否長時間運行。可訪問性對用戶來說是極其重要的。如果用戶得到“系統忙”的信息，他們可能放棄，並轉向競爭對手。系統檢測不僅要使用戶能夠正常訪問站點，在很多情況下，可能會有***試圖通過發送大量數據包來***服務器。出於安全的原因，測試人員應該知道當系統過載時，需要採取哪些措施，而不是簡單地提升系統性能。
1）瞬間訪問高峯
如果您的站點用於公佈×××的抽獎結果，最好使系統在中獎號碼公佈後的一段時間內能夠響應上百萬的請求。負載測試工具能夠模擬X個用戶同時訪問測試站點。
2）每個用戶傳送大量數據
網上書店的多數用戶可能只訂購1-5書，但是大學書店可能會訂購5000本有關心理學介紹的課本?或者一個祖母爲她的50個兒孫購買聖誕禮物(當然每個孩子都有自己的郵件地址)系統能處理單個用戶的大量數據嗎?
3）長時間的使用
如果站點用於處理鮮花訂單，那麼至少希望它在母親節前的一週內能持續運行。如果站點提供基於web的email服務，那麼點最好能持續運行幾個月，甚至幾年。可能需要使用自動測試工具來完成這種類型的測試，因爲很難通過手工完成這些測試。你可以想象組織100個人同時點擊某個站點。但是同時組織100000個人呢。通常，測試工具在第二次使用的時候，它創造的效益，就足以支付成本。而且，測試工具安裝完成之後，再次使用的時候，只要點擊幾下。
採取措施：採用性能測試工具WAS、ACT，LR等協助進行測試
十八、測試中應該注意的其他情況
1、在測試時，與網絡有關的步驟或者模塊必須考慮到斷網的情況
2、每個頁面都有相應的Title，不能爲空，或者顯示“無標題頁”
3、在測試的時候要考慮到頁面出現滾動條時，滾動條上下滾動時，頁面是否正常
4、URL不區分大小寫，大小寫不敏感
5、、對於電子商務網站，當用戶併發購買數量大於庫存的數量時，系統如何處理
6、測試數據避免單純輸入“123”、“abc“之類的，讓測試數據儘量接近實際
7、進行測試時，儘量不要用超級管理員進行測試，用新建的用戶進行測試。測試人員儘量不要使用同一個用戶進行測試
8、提示信息：提示信息是否完整、正確、詳細
9、幫助信息：是否提供幫助信息，幫助信息的表現形式（頁面文字、提示信息、幫助文件），幫助信息是否正確、詳細
10、可擴展性：是否由升級的餘地，是否保留了接口
11、穩定性：運行所需的軟硬件配置，佔用資源情況，出現問題時的容錯性，對數據的保護
12、運行速度：運行的快慢，帶寬佔用情況
做個快樂的自己。