一．概要
1 目的
本文檔編寫目的在於規範基於網站的系統測試，區別於傳統的軟件測試，本文對網站測試的流程與規範進行全面概述，以利於網站開發工作的質量和開發時間，幫助測試人員快速瞭解測試流程，進行測試活動。
2 適用範圍
適用於所有基於WEB的網站測試的項目。
3 網站測試的簡要說明
網站的開發與部署是爲更多更廣泛的用戶提供信息服務，其針對性廣、適用性強，故其性能要求與傳統的軟件不同，其系統的測試也與傳統的軟件測試不同。它不僅需要驗證系統各個模塊的功能是否與用戶需求符合，還要測試系統在不同軟硬件平臺和不同的瀏覽器端的兼容性問題。還有用戶的安全性和可用性測試。
Web網站的特點：網絡集約型、內容驅動性、持續演化性、即時性、安全性、美觀性。
二．基本流程
1．項目立項
項目立項階段是用戶與項目經理針對項目進行敲定，確定項目雙方的職能及相關責任。在此過程中測試人員很多時候都不怎麼會參與進來，其實測試經理或組長是可以以參與者的身份參與進來，瞭解項目的相關事宜。
2.需求分析階段
需求分析階段測試人員對業務關係進行了解，分析需求點。很多測試人員的測試工作都是從這一階段開始。需求分析評審對項目需求分析的結果進行評審，評審團根據公司人員分配來定，一般包含用戶、項目經理、開發人員、測試人員等，不要低於5人。
3.測試計劃階段
測試計劃階段：測試組長就要根據《用戶需求手冊》或《測試需求分析書》開始編寫《測試計劃》，其中包括人員，軟件硬件資源，測試點，集成順序，進度安排和風險識別等內容。評審團根據公司人員分配來定，一般應包含項目經理、測試人員等，不要低於5人。
4.測試設計階段
此階段要對測試工作提出測試方案，測試方案一般由對需求很熟的高資深的測試工程師設計，測試方案要求根據《需求分析》和《測試計劃》上的每個需求點設計出包括需求點簡介，測試思路和詳細測試方法三部分的方案。《測試方案》編寫完成後也需要進行評審。評審人員不要低於5人。
5.測試方案階段
此階段對測試進行詳細設計，主要針對測試用例和規程的設計。測試用例是根據《測試方案》來編寫的，通過測試方案階段，測試人員對整個系統需求有了詳細的理解。這時開始編寫用例才能保證用例的可執行和對需求的覆蓋。測試用例需要包括測試項，用例級別，預置條件，操作步驟和預期結果。其中操作步驟和預期結果需要編寫詳細和明確。測試用例應該覆蓋測試方案，而測試方案又覆蓋了測試需求點，這樣才能保證客戶需求不遺漏。同樣，測試用例也需要評審。評審人員最好不要低於5人。
6.測試執行階段
執行測試用例，對執行結果進行合理管理，及時提交有質量的Bug。
7.結果分析與測試報告
針對測試結果測試人員應該分析相應的結果產生原因，並提交相應的測試報告。
三．測試範圍
1. 功能測試
1.1基本功能模塊測試
根據《用戶需求說明手冊》和《需求分析說明書》，分析各個功能模塊。針對各個功能模塊進行相關功能的測試。
1.2 WEB功能測試
1.2.1鏈接測試
什麼是鏈接？
鏈接是Web 網站的一個主要特徵，它是在頁面之間切換和引導用戶去一些未知地址頁面的主要手段。
鏈接測試的內容：
測試所有鏈接是否按指示的那樣確實鏈接到了應該鏈接的頁面；
1 目的
本文檔編寫目的在於規範基於網站的系統測試，區別於傳統的軟件測試，本文對網站測試的流程與規範進行全面概述，以利於網站開發工作的質量和開發時間，幫助測試人員快速瞭解測試流程，進行測試活動。
2 適用範圍
適用於所有基於WEB的網站測試的項目。
3 網站測試的簡要說明
網站的開發與部署是爲更多更廣泛的用戶提供信息服務，其針對性廣、適用性強，故其性能要求與傳統的軟件不同，其系統的測試也與傳統的軟件測試不同。它不僅需要驗證系統各個模塊的功能是否與用戶需求符合，還要測試系統在不同軟硬件平臺和不同的瀏覽器端的兼容性問題。還有用戶的安全性和可用性測試。
Web網站的特點：網絡集約型、內容驅動性、持續演化性、即時性、安全性、美觀性。
二．基本流程
1．項目立項
項目立項階段是用戶與項目經理針對項目進行敲定，確定項目雙方的職能及相關責任。在此過程中測試人員很多時候都不怎麼會參與進來，其實測試經理或組長是可以以參與者的身份參與進來，瞭解項目的相關事宜。
2.需求分析階段
需求分析階段測試人員對業務關係進行了解，分析需求點。很多測試人員的測試工作都是從這一階段開始。需求分析評審對項目需求分析的結果進行評審，評審團根據公司人員分配來定，一般包含用戶、項目經理、開發人員、測試人員等，不要低於5人。
3.測試計劃階段
測試計劃階段：測試組長就要根據《用戶需求手冊》或《測試需求分析書》開始編寫《測試計劃》，其中包括人員，軟件硬件資源，測試點，集成順序，進度安排和風險識別等內容。評審團根據公司人員分配來定，一般應包含項目經理、測試人員等，不要低於5人。
4.測試設計階段
此階段要對測試工作提出測試方案，測試方案一般由對需求很熟的高資深的測試工程師設計，測試方案要求根據《需求分析》和《測試計劃》上的每個需求點設計出包括需求點簡介，測試思路和詳細測試方法三部分的方案。《測試方案》編寫完成後也需要進行評審。評審人員不要低於5人。
5.測試方案階段
此階段對測試進行詳細設計，主要針對測試用例和規程的設計。測試用例是根據《測試方案》來編寫的，通過測試方案階段，測試人員對整個系統需求有了詳細的理解。這時開始編寫用例才能保證用例的可執行和對需求的覆蓋。測試用例需要包括測試項，用例級別，預置條件，操作步驟和預期結果。其中操作步驟和預期結果需要編寫詳細和明確。測試用例應該覆蓋測試方案，而測試方案又覆蓋了測試需求點，這樣才能保證客戶需求不遺漏。同樣，測試用例也需要評審。評審人員最好不要低於5人。
6.測試執行階段
執行測試用例，對執行結果進行合理管理，及時提交有質量的Bug。
7.結果分析與測試報告
針對測試結果測試人員應該分析相應的結果產生原因，並提交相應的測試報告。
三．測試範圍
1. 功能測試
1.1基本功能模塊測試
根據《用戶需求說明手冊》和《需求分析說明書》，分析各個功能模塊。針對各個功能模塊進行相關功能的測試。
1.2 WEB功能測試
1.2.1鏈接測試
什麼是鏈接？
鏈接是Web 網站的一個主要特徵，它是在頁面之間切換和引導用戶去一些未知地址頁面的主要手段。
鏈接測試的內容：
測試所有鏈接是否按指示的那樣確實鏈接到了應該鏈接的頁面；
測試所鏈接的頁面是否存在；
保證Web 網站上沒有孤立的頁面。所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的URL 地址才能訪問。
保證Web 網站上沒有孤立的頁面。所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的URL 地址才能訪問。
鏈接測試可以手動進行，也可以自動進行。
鏈接測試必須在集成測試階段完成，也就是說，在整個Web 網站的所有頁面開發完成之後進行鏈接測試。
主要測試網站的鏈接是否正常，其中包括測試鏈接頁面的正確性、頁面是否存在、是否存在孤立頁面。
常用測試工具有Xenu（測試鏈接的正確性的工具）。
1.2.2表單測試
什麼是表單？
表單就是一些需要在線顯示和填寫的表格。
表單有一些標準操作，如確認、保存、提交等。
主要測試表單的正確性和規範性，是否適合常用表單的使用習慣。
主要測試方法爲：邊界值測試、等價類測試，以及異常類測試。
1.2.3Cookies測試
什麼是cookies？
Cookie是一個由網頁服務器放在您硬盤上的非常小的文本文件. 它本質上就像您的身份證明一樣，並且不能像代碼那樣被執行或被用來散佈病毒。它只能被您使用並且只能由提供的服務器讀取。
使用cookies的目的：
幫您節約時間。如果您自定義頁面，或註冊產品或服務。cookie記住您的身份.當下一次您再次訪問的時候，將顯示您需要的信息，將幫您填入任何您已經回答過的問題。
Cookies測試
Cookies 通常用來存儲用戶信息和用戶在某些應用系統上的操作序列，當一個用戶使用Cookies訪問了某一個應用系統時，Web 服務器將發送關於用戶的信息，並把該信息以Cookies 的形式存儲在客戶端計算機上，這可用來創建動態和自定義頁面或者存儲登錄等信息。
測試內容
Cookies是否能正常工作；
Cookies是否按預定的時間進行保存；
刷新對Cookies 有什麼影響等。
1.2.4設計語言測試
測試WEB設計語言使用的版本是否規範、是否統一，使用的腳本語言是否規範、統一。
一般採用的時代碼查看法。
鏈接測試必須在集成測試階段完成，也就是說，在整個Web 網站的所有頁面開發完成之後進行鏈接測試。
主要測試網站的鏈接是否正常，其中包括測試鏈接頁面的正確性、頁面是否存在、是否存在孤立頁面。
常用測試工具有Xenu（測試鏈接的正確性的工具）。
1.2.2表單測試
什麼是表單？
表單就是一些需要在線顯示和填寫的表格。
表單有一些標準操作，如確認、保存、提交等。
主要測試表單的正確性和規範性，是否適合常用表單的使用習慣。
主要測試方法爲：邊界值測試、等價類測試，以及異常類測試。
1.2.3Cookies測試
什麼是cookies？
Cookie是一個由網頁服務器放在您硬盤上的非常小的文本文件. 它本質上就像您的身份證明一樣，並且不能像代碼那樣被執行或被用來散佈病毒。它只能被您使用並且只能由提供的服務器讀取。
使用cookies的目的：
幫您節約時間。如果您自定義頁面，或註冊產品或服務。cookie記住您的身份.當下一次您再次訪問的時候，將顯示您需要的信息，將幫您填入任何您已經回答過的問題。
Cookies測試
Cookies 通常用來存儲用戶信息和用戶在某些應用系統上的操作序列，當一個用戶使用Cookies訪問了某一個應用系統時，Web 服務器將發送關於用戶的信息，並把該信息以Cookies 的形式存儲在客戶端計算機上，這可用來創建動態和自定義頁面或者存儲登錄等信息。
測試內容
Cookies是否能正常工作；
Cookies是否按預定的時間進行保存；
刷新對Cookies 有什麼影響等。
1.2.4設計語言測試
測試WEB設計語言使用的版本是否規範、是否統一，使用的腳本語言是否規範、統一。
一般採用的時代碼查看法。
不同的Web 設計語言版本的差異可以引起客戶端或服務器端嚴重的問題；
尤其在分佈式環境中開發時，開發人員都不在一起，這個問題就顯得尤爲重要。
測試的語言，除了HTML 的版本問題外，不同的腳本語言，例如使用Java、JavaScript、ActiveX、VBScript或Perl 等開發的應用程序也要在不同的版本上進行驗證。
1.2.5數據庫測試
數據校驗
根據業務規則，需要對用戶輸入進行校驗，則要保證這些校驗功能正常工作。
一般測試數據的一致性錯誤和輸出錯誤。數據一致性錯誤主要是由於用戶提交的表單信息不正確而造成的，而輸出錯誤主要是由於網絡速度或程序設計問題等引起的，針對這兩種情況，可分別進行測試。再就是數據的安全性測試，一般採用SQL注入的方法。
2．性能測試
網站的性能測試對於網站的運行而言異常重要，網站的性能測試主要從三個方面進行：連接速度測試、負載測試和壓力測試。
2.1連接速度測試
不管用戶使用那種方式的不同，系統都不能讓用戶可以等較長的時間。連接速度測試的目的，就是要保證在許可的時間內響應用戶的請求。
測試網站的鏈接速度，響應用戶的反應時間。
2.2負載測試
負載測試的目的：
負載測試是爲了測量Web 系統在某一負載級別上的性能，以保證Web 系統在需求範圍內能正常工作。負載測試指的是進行一些邊界數據的測試，測量網站系統在某一負載級別上的性能，以保證網站系統在需求範圍內能正常工作。負載級別是某個時刻同時訪問Web系統的用戶數量。
常用自動化測試工具：LoadRunner。
2.3壓力測試
壓力測試傾向應該是致使整個系統崩潰測試出系統能承受的最大壓力而不會發生系統崩潰的現象。同時也是測試系統的限制和故障恢復能力，也就是測試網站系統會不會崩潰，在什麼情況下會崩潰。
壓力測試的內容：
壓力測試必須對 Web 服務應用以下四個基本條件進行有效的壓力測試：
重複（Repetition）；
尤其在分佈式環境中開發時，開發人員都不在一起，這個問題就顯得尤爲重要。
測試的語言，除了HTML 的版本問題外，不同的腳本語言，例如使用Java、JavaScript、ActiveX、VBScript或Perl 等開發的應用程序也要在不同的版本上進行驗證。
1.2.5數據庫測試
數據校驗
根據業務規則，需要對用戶輸入進行校驗，則要保證這些校驗功能正常工作。
一般測試數據的一致性錯誤和輸出錯誤。數據一致性錯誤主要是由於用戶提交的表單信息不正確而造成的，而輸出錯誤主要是由於網絡速度或程序設計問題等引起的，針對這兩種情況，可分別進行測試。再就是數據的安全性測試，一般採用SQL注入的方法。
2．性能測試
網站的性能測試對於網站的運行而言異常重要，網站的性能測試主要從三個方面進行：連接速度測試、負載測試和壓力測試。
2.1連接速度測試
不管用戶使用那種方式的不同，系統都不能讓用戶可以等較長的時間。連接速度測試的目的，就是要保證在許可的時間內響應用戶的請求。
測試網站的鏈接速度，響應用戶的反應時間。
2.2負載測試
負載測試的目的：
負載測試是爲了測量Web 系統在某一負載級別上的性能，以保證Web 系統在需求範圍內能正常工作。負載測試指的是進行一些邊界數據的測試，測量網站系統在某一負載級別上的性能，以保證網站系統在需求範圍內能正常工作。負載級別是某個時刻同時訪問Web系統的用戶數量。
常用自動化測試工具：LoadRunner。
2.3壓力測試
壓力測試傾向應該是致使整個系統崩潰測試出系統能承受的最大壓力而不會發生系統崩潰的現象。同時也是測試系統的限制和故障恢復能力，也就是測試網站系統會不會崩潰，在什麼情況下會崩潰。
壓力測試的內容：
壓力測試必須對 Web 服務應用以下四個基本條件進行有效的壓力測試：
重複（Repetition）；
併發（Concurrency）；
量級（Magnitude）；
隨機變化。
常用自動化測試工具：LoadRunner。
3. 可用性測試
可用性/易用性方面的測試一般採用手工測試的方法進行評判。
3.1導航測試
什麼是導航測試？
隨機變化。
常用自動化測試工具：LoadRunner。
3. 可用性測試
可用性/易用性方面的測試一般採用手工測試的方法進行評判。
3.1導航測試
什麼是導航測試？
在不同的用戶接口控制之間，例如按鈕、對話框、列表和窗口等；
或在不同的連接頁面之間，
導航描述了用戶在一個頁面內操作的方式。
或在不同的連接頁面之間，
導航描述了用戶在一個頁面內操作的方式。
導航測試的內容：
測試網站的導航能力是否良好，比如頁面結構、導航、菜單、連接等是否良好。
常採用手工對網頁進行瀏覽、根據一般用戶的瀏覽習慣來進行評判。
一般此過程讓最終用戶參與這種測試，效果將更加明顯。
導航是否直觀？
Web 系統的主要部分是否可以通過主頁訪問？
Web系統是否需要站點地圖、搜索引擎或其他的導航器幫助？
測試Web 系統的頁面結構；
導航條、菜單、連接的風格是否一致？
測試網站的導航能力是否良好，比如頁面結構、導航、菜單、連接等是否良好。
常採用手工對網頁進行瀏覽、根據一般用戶的瀏覽習慣來進行評判。
一般此過程讓最終用戶參與這種測試，效果將更加明顯。
導航是否直觀？
Web 系統的主要部分是否可以通過主頁訪問？
Web系統是否需要站點地圖、搜索引擎或其他的導航器幫助？
測試Web 系統的頁面結構；
導航條、菜單、連接的風格是否一致？
各種提示是否準確，確保用戶憑直覺就知道是否還有內容，內容在什麼地方。
最好讓最終用戶參與導航測試，效果將更加明顯。
最好讓最終用戶參與導航測試，效果將更加明顯。
3.2圖形測試
什麼是圖形測試？
在Web 網站中，適當的圖片和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。一個Web 網站的圖形可以包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試是網頁美觀測試的一部分，一般測試圖形是否有明確的用途、是否與頁面風格一致，還用圖片的大小與格式的測試。
圖形測試的內容：
(1) 要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。圖片尺寸要儘量地小，並且要能清楚地說明某件事情。
(2) 驗證所有頁面字體的風格是否一致。
(3) 背景顏色應該與字體顏色和前景顏色相搭配。
(4) 圖片的大小和質量也是一個很重要的因素，一般採用JPG 或GIF 壓縮。
常採用手工測試。
3.3內容測試
內容測試用來檢驗web網站系統提供信息的正確性、準確性和相關性。如文字標題是否與文字內容符合，是否存在不需要的文字。
常採用界面瀏覽的方式。
3.4整體界面測試
測試整個網站系統的頁面結構設計是否符合用戶需求規範，是否給用戶的一個整體感。
一般常採用界面瀏覽的方式，最好是有最終用戶的參與。
例如，當用戶瀏覽Web 網站時，應考慮
是否感到舒適？
是否憑直覺就知道要找的信息在什麼地方？
整個Web 應用系統的設計風格是否一致？
4. 安全性測試
4.1登錄驗證
現在的網站系統基本採用先註冊，後登陸的方式。因此，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。
4.2緩衝區溢出
溢出***是通過溢出來控制計算機的指令序列，讓計算機執行自己的惡意代碼，是利用緩衝區溢出漏洞所進行的***行動。緩衝區溢出是一種非常普遍、非常危險的漏洞。
4.3日誌文件
爲了保證網站系統的安全性，日誌文件是至關重要的。需要測試相關信息是否寫進了日誌文件、是否可追蹤。
4.4安全漏洞
服務器端的腳本常常構成安全漏洞，這些漏洞又常常被***利用。所以，還要測試沒有經過授權，就不能在服務器端放置和編輯腳本的問題。
4.5跨站式腳本***（XSS）
跨站腳本***是指***者編寫惡意腳本利用網站漏洞從用戶那裏惡意盜取信息。
4.6 目錄測試
4.7 SSL套接字測試
5. 配置和兼容性測試
5.1平臺測試
採用不同的操作系統平臺對網站進行測試。
市場上有很多不同的操作系統類型，最常見的有Windows、Unix、Macintosh、Linux 等。Web 網站的最終用戶究竟使用哪一種操作系統，取決於用戶系統的配置。
平臺測試就是要測試兼容性問題：
同一個應用可能在某些操作系統下能正常運行，但在另外的操作系統下可能會運行失敗。
因此，在Web 系統發佈之前，需要在各種操作系統下對Web 系統進行兼容性測試。
5.2瀏覽器測試
使用不同的瀏覽器對網站進行瀏覽測試，查看網站在不同瀏覽器中的兼容性問題。
瀏覽器是Web系統客戶端最核心的軟件，來自不同廠商的瀏覽器對Java，、JavaScript、ActiveX、plug-ins 或不同的HTML 有不同的支持。
另外，框架和層次結構風格在不同的瀏覽器中也有不同的顯示，甚至根本不能顯示。不同的瀏覽器對安全性和Java 的設置也不一樣。
什麼是圖形測試？
在Web 網站中，適當的圖片和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。一個Web 網站的圖形可以包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試是網頁美觀測試的一部分，一般測試圖形是否有明確的用途、是否與頁面風格一致，還用圖片的大小與格式的測試。
圖形測試的內容：
(1) 要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。圖片尺寸要儘量地小，並且要能清楚地說明某件事情。
(2) 驗證所有頁面字體的風格是否一致。
(3) 背景顏色應該與字體顏色和前景顏色相搭配。
(4) 圖片的大小和質量也是一個很重要的因素，一般採用JPG 或GIF 壓縮。
常採用手工測試。
3.3內容測試
內容測試用來檢驗web網站系統提供信息的正確性、準確性和相關性。如文字標題是否與文字內容符合，是否存在不需要的文字。
常採用界面瀏覽的方式。
3.4整體界面測試
測試整個網站系統的頁面結構設計是否符合用戶需求規範，是否給用戶的一個整體感。
一般常採用界面瀏覽的方式，最好是有最終用戶的參與。
例如，當用戶瀏覽Web 網站時，應考慮
是否感到舒適？
是否憑直覺就知道要找的信息在什麼地方？
整個Web 應用系統的設計風格是否一致？
4. 安全性測試
4.1登錄驗證
現在的網站系統基本採用先註冊，後登陸的方式。因此，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。
4.2緩衝區溢出
溢出***是通過溢出來控制計算機的指令序列，讓計算機執行自己的惡意代碼，是利用緩衝區溢出漏洞所進行的***行動。緩衝區溢出是一種非常普遍、非常危險的漏洞。
4.3日誌文件
爲了保證網站系統的安全性，日誌文件是至關重要的。需要測試相關信息是否寫進了日誌文件、是否可追蹤。
4.4安全漏洞
服務器端的腳本常常構成安全漏洞，這些漏洞又常常被***利用。所以，還要測試沒有經過授權，就不能在服務器端放置和編輯腳本的問題。
4.5跨站式腳本***（XSS）
跨站腳本***是指***者編寫惡意腳本利用網站漏洞從用戶那裏惡意盜取信息。
4.6 目錄測試
4.7 SSL套接字測試
5. 配置和兼容性測試
5.1平臺測試
採用不同的操作系統平臺對網站進行測試。
市場上有很多不同的操作系統類型，最常見的有Windows、Unix、Macintosh、Linux 等。Web 網站的最終用戶究竟使用哪一種操作系統，取決於用戶系統的配置。
平臺測試就是要測試兼容性問題：
同一個應用可能在某些操作系統下能正常運行，但在另外的操作系統下可能會運行失敗。
因此，在Web 系統發佈之前，需要在各種操作系統下對Web 系統進行兼容性測試。
5.2瀏覽器測試
使用不同的瀏覽器對網站進行瀏覽測試，查看網站在不同瀏覽器中的兼容性問題。
瀏覽器是Web系統客戶端最核心的軟件，來自不同廠商的瀏覽器對Java，、JavaScript、ActiveX、plug-ins 或不同的HTML 有不同的支持。
另外，框架和層次結構風格在不同的瀏覽器中也有不同的顯示，甚至根本不能顯示。不同的瀏覽器對安全性和Java 的設置也不一樣。
5.3分辨率測試
對屏幕的分辨率進行調節來查看網站在不同分辨率下的顯示效果，比如；分辨率低時界面文字顯示太大，而
對屏幕的分辨率進行調節來查看網站在不同分辨率下的顯示效果，比如；分辨率低時界面文字顯示太大，而
分辨率高時又有些文字顯示時太小。
頁面版式在640x400、600x800 或1024x768 的
分辨率模式下是否顯示正常?
頁面版式在640x400、600x800 或1024x768 的
分辨率模式下是否顯示正常?
5.4 連接速率測試
是否有這種情況，用戶使用28.8k modem 下載一個頁面需要10 分鐘，但測試人員在測試的時候使用的是T1 專線?
用戶在下載文章或演示的時候，可能會等待比較長的時間，但卻不會耐心等待首頁的出現。
5.5 組合測試
600x800 的分辨率在MAC 機上可能不錯，但是在IBM 兼容機上卻很難看。
在IBM 機器上使用Netscape 能正常顯示，但卻無法使用Lynx 來瀏覽。
如果所有的人都使用T1 專線，可能不需要測試下載、上載。
有些內部應用程序，開發部門可能在系統需求中聲明不支持某些系統而只支持一些那些已設置的系統。
理想的情況，系統能在所有機器上運行。
四．相關規範
1. 文檔管理規範
2.相關管理工具
是否有這種情況，用戶使用28.8k modem 下載一個頁面需要10 分鐘，但測試人員在測試的時候使用的是T1 專線?
用戶在下載文章或演示的時候，可能會等待比較長的時間，但卻不會耐心等待首頁的出現。
5.5 組合測試
600x800 的分辨率在MAC 機上可能不錯，但是在IBM 兼容機上卻很難看。
在IBM 機器上使用Netscape 能正常顯示，但卻無法使用Lynx 來瀏覽。
如果所有的人都使用T1 專線，可能不需要測試下載、上載。
有些內部應用程序，開發部門可能在系統需求中聲明不支持某些系統而只支持一些那些已設置的系統。
理想的情況，系統能在所有機器上運行。
四．相關規範
1. 文檔管理規範
2.相關管理工具
（注：該文章是網上一篇測試流程的文章上補充完成，對某些部分給予了詳細的說明，在此謝謝該篇文章的初建者）