如何編寫測試用例-好東西與你們分享

一、剛剛從事軟件測試職業，如何快速掌握編寫測試用例的方法？該怎樣編寫測試用例呢？
專家分析：

一、根據需求文檔，徹底按照需求文檔框架/功能描述，根據本身的理解整理爲用例。簡單來講，就是將需求文檔描述的內容，從新按照用例的格式編輯一次，把能想到的各類可能性添加進去。
二、搜索其餘測試人員編寫的同類型功能用例，先理解，再根據項目實際需求的較小差別，從新新增/刪/改，組成知足需求的用例組。
快速掌握用例其實沒有什麼竅門，只有多看，多想，多寫，多評審。

二、怎樣的測試用例是好用例?若是用一條用例覆蓋一個功能點在實際操做中有很大的缺陷。首先不能確保測試人員進行集成測試時對功能用例執行到位，可能會出現遺漏。所以咱們在測試用例輸出過程當中，建議測試人員就測試因子使用工程方法進行流程功能覆蓋。可是這樣引入另一個問題，客戶的需求是不斷變化的，需求在執行設計和測試用例輸出時，很大概率產生變化，這種變化勢必對原輸出的測試用例形成衝擊。調整的工做量有時會很大，有可能對整個功能推倒從新輸出用例。面對這樣的狀況該如何解決？
專家分析：每一個用例覆蓋一個功能點，是最佳的理想狀態。但條件覆蓋有個缺點就是每次執行會存在一個較長的週期，若是部分不可套用自動化，會致使測試和開發並行產生沒法按時驗證完每一個版本的分支。
有兩種方式可供參考：
1.在本來測試用例的基礎上，再次放大用例描述的模糊度，以利於用例可用於類似但細節不一樣的功能。以登錄界面的字符長度爲12雙字節的用戶名提示框爲例：
原始用例步驟：在登錄界面用戶名輸入框輸入11箇中文字符。
修改後的用例步驟：在登錄界面輸入不超過字符長度限制的用戶名。
點評：原始用例步驟僅適合登錄界面用戶名字符長度限制爲11以上的編輯框。修改後的用例可用於任何字符長度的用戶名編輯框。此方法還可用於對流程描述，如」進入編輯用戶名界面」可替換爲」編輯用戶名」。
2.創建較爲完善的基礎用例庫，項目用例做爲基礎用例庫的子集存在。這樣的用例庫在針對單個功能時，存在多種不一樣的描述和設計。如1點的模糊程度不一樣可做爲相同用例的不一樣兩支用例存在。而在之後的實際項目中，根據項目實際需求，從基礎用例庫篩選合適的用例組做爲項目用例組。

三、有些公司的黑盒測試用例會演進爲自動化用例。若是單一覆蓋點測試用例，會致使自動化腳本代碼複用率不高。像這樣的問題，應該如何解決？
專家分析：首先通常都是按照測試用例去作的，單一運行，假如但願腳本複用高，須要整理業務函數腳本，把經常使用的業務函數化調用。這個是大家負責設計框架的人去想的。若是以爲業務利用率不高，就寫成公共方法調用。

四、是否是性能測試適合男生？有專家說性能測試和功能測試沒多大關聯，不必先學功能測試再學性能測試。這個觀點對嗎？
專家分析：其實性能測試並無趨向於男生，就像開發人員也沒有男生優先的招聘條件同樣。之因此有這個說法，無非是大多數男生比女生更喜歡邏輯推理而已。
性能測試與功能測試仍是有關聯的。有些性能測試還必須在必定功能測試基礎上測試。

五、作了幾年測試，自我感受沒有什麼提高，始終是在作一些手工測試，項目來了先不寫測試用例而是先測試，等之後項目不緊張了再補充測試用例。我我的認爲這樣是很不規範的。我一直都認爲寫測試用例是最關鍵的，可是這幾年好像沒怎麼寫過測試用例。還有面試的時候考官也會給你出一道題，讓你大概說下你設計測試用例的思路。這些總讓我感到腦子裏好像空空的，沒什麼思路。專家可否給些指點。
專家分析：1.「項目來了先不寫測試用例而是先測試，等之後項目不緊張了再補充測試用例」 其實這種方式並不規範。若是大家已經有基礎測試用例組，那麼在項目需求確認後，第一時間開始用例的篩選和更新適用的用例組，並在項目前期交付於項目組各個部門評審。這樣的操做不管對於項目質量控制仍是項目出現問題後，對於測試人員的責任分攤，都是有極大利益的。
2.測試用例的設計自己是測試技能中最重要的技術之一。可是因爲它自己涉及整個測試系統的其餘各個技能，因此對用例的理解，實際上就是測試人員對測試的理解。若發現沒法再寫出更好的用例，可多看看業務相關的資料，同時學習測試流程，將自身的測試思想涉及相關業務的邊邊角角，並融入到實際使用的測試流程中。這時你將發現以前的測試用例設計思想存在較大的提高空間，也逐漸能開始經過分析測試環境（不只僅包括執行測試環境），熟練駕馭測試框架，制定測試策略。而以前設計用例欠缺的立足點，也會相應獲得補足。有理有據，天然用例設計邏輯就清晰起來了。

六、手機軟件的性能應考察哪些方面？
專家分析：從手機產品來看，手機性能測試可分爲兩部分：硬件測試和軟件測試。
1.硬件測試操做簡單，但目前國內不少手機硬件測試人員都處於初級階段，便可執行測試，但沒法提出優化解決方案，故廣泛待遇較低。而要發展爲高級硬件測試人員，必須掌握手機硬件測試設計原理，而掌握這部分的測試人員，大多都轉爲硬件開發。
2.手機軟件性能測試目前在國內也比較麻煩，主要因爲如下幾點：
1）嵌入式平臺受於開源程度，自動化工具大多仍是不足。勉強湊合的開源自動化工具沒法應對多元化的客戶和測試人員需求，每每須要二次開發。
2）因爲市場競爭過於激烈，低成本的硬件器件沒法達到最好的性能指標，致使在測試後期，測試人員還在糾結於如何平衡客戶需求指標與實際測試性能指標。軟件性能指標的不斷變動一樣也致使某些測試團隊沒法正確評估性能測試結果究竟是經過仍是失敗。
3）軟件性能測試周期長，投入資源較多，收益較功能測試少，故不少手機設計公司對這一塊持觀望態度。

七、測試用例有不少模版，該如何選擇？測試用例是根據之前測試的積累步驟寫仍是要根據寫測試用例的方法寫？
專家分析：測試用例模板，可本身根據實際測試的環境來選擇。建議選擇表格式的模板，好比excel，比較好統計。
不一樣的測試人員，寫測試用例的方法各不同。並無哪一種方法就絕對好，都須要根據實際狀況來看。如項目自己就很緊，若大張旗鼓的從新按照測試方法設計用例，必然致使中後期測試執行時間短缺，沒法達到預約的迭代次數，而對項目產生更大的風險。因此，先分析環境，纔可能設計出好的測試用例。

八、功能測試作多久才適合作性能測試？
專家分析：功能入門簡單，性能偏難。有一些功能測試基礎，學學性能也無妨，這個沒有時間的約束，看你本身的能力、是否感興趣或者工做的須要。

九、測試用例的細度如何把握？什麼樣的功能點能夠考慮放在同一條用例驗證？什麼樣的功能點必須是由一條用例驗證？
專家分析：用例粒度不管選擇什麼方法，都存在利弊，因此在實際測試用例設計中，如何選取，須要結合整個測試團隊和產品將來發展來看，而非簡單的只分析測試用例原理就能獲得結果。提供一個用例粒度供參考。單個quick check test 單個測試人員在2小時完成，組成的用例組要求覆蓋產品全部功能，而每一個用例均可從System cases中直接提取。以此爲標準，可評估出每一個用例的覆蓋粒度。

十、如何挑選迴歸用例？什麼樣的用例能夠做爲迴歸用例？若是在備選的用例庫裏邊沒有可做爲迴歸用例的測試用例時咱們應該怎麼處理？
專家分析：迴歸用例Quick Check Test用例差很少，知足2個要求：一是功能覆蓋率，二是可在規定的執行時間內完成。
若是備選的用例庫裏沒有相應的迴歸用例，則須要更新備選用例庫。

十一、新手該如何作好測試？
專家分析：測試對新手的要求很簡單：
1.只相信實際測試的結果。
2.不懂就問，問完就想，想不通再問。切記重複的問題莫屢次提問。
3.沒事就多看資料，無論是否以爲和本身的業務相關，先看先了解，說不定之後哪天就用上了。

十二、剛剛從開發轉作測試，怎樣才能將測試用例設計的全面？
專家分析：有個很簡單的方法，你先按照本身的思路把用例寫一次。而後用1倍的時間給本身的用例找茬，而後將漏掉的點分類，再思考當初設計用例的時候，怎麼能夠將這些用例漏掉的點預先設計進去。
若是其餘測試人員有時間，強烈建組織用例評審。

1三、對於米聊，飛信這種軟件如何設計好的測試用例才能保證沒有功能遺漏，這種軟件如何作性能方面的測試？
專家分析：若是將兼容性測試劃到性能測試中的話，那麼米聊，飛信這類第三方的軟件功能測試還算是比較簡單的，須要注意兩點：
1）交互。因爲不少系統在設計時，並不可能考慮到適應全部的第三方軟件。因此當第三方軟件與系統自己軟件在同時申請資源時，存在較大的風險。
2）容錯。異常處理機制是軟件設計的天生缺陷，咱們沒法在一開始就設計出完美的軟件，特別是在容錯方面。因此錯誤推斷的用例設計方法一般都是軟件設計的命門。
關於性能測試方面，除了上面提到的兼容性測試外，在手機端，還需考慮如下9種性能測試。
長週期測試
響應時間測試
電源管理測試
內存測試
多媒體質量測試
應用程序接口吞吐量測試
耐力測試
負載測試
可靠性測試
而在服務器端，則主要考慮一下6種性能測試
壓力測試
負載測試
大數據量測試
配置測試
可靠性測試
併發測試

1四、對於相似於手機版淘寶這種軟件，它擁有客戶端，服務器端還有一個後臺管理系統相似於進銷存管理系統，我如何設計測試用例才能保證功能的徹底覆蓋？他們之間的交互如何設計測試用例？
專家分析：對於複合型的第三方軟件，首先須要進行功能拆分，如你所說的，拆分爲手持客戶端，服務器，後臺管理系統三大塊。而後再根據每一塊的單獨設計完整測試類型的用例組。
而針對主體三大功能交互用例組，因爲基礎交互用例組已經在UI用例組（客戶端和後臺管理）中設計完成，故目前主要考慮二級以上交互的用例設計。具體設計方法可考慮根據系統資源分配原理，篩選出可同時申請相同類型系統資源的進程或線程，經過組合的方式，設計出交互用例組。如，針對用戶元寶餘額的數據庫，若手機端和後臺管理均對此存儲塊有讀寫權限，當二者同時申請此塊存儲地址的權限時，系統是否響應正常。從這一點即構造出新的用戶元寶餘額的二級交互用例。

1五、面對相對簡單、不太規範的業務需求，並且沒有詳細的開發設計文檔，測試人員應該如何作測試。業務需求提出人員在系統開發測試接近尾聲後，頻繁提出需求變動，測試人員應如何應對？
專家分析：沒有詳細文檔，測試人員除了增強部門溝通外，其實沒有太好的方法來規避風險。若此時測試主管對相關業務設計難度不熟悉的話，那整個測試任務可能沒法順利過渡到中期。
對於項目後期的需求問題，可考慮引入一些流程來規範，如軟件入場標準。也可經過與PM/RD溝通，延長項目週期或將風險轉嫁給決策人（PM）都是一些常見的處理方式。

1六、剛剛接觸黑盒測試，測試計劃和測試用例應該怎麼部署？測試用例是否是就是本身在測試過程當中用到的實例或步驟呢？
專家分析：作好測試計劃的編寫工做應該從如下幾個方面考慮問題：
一、要充分考慮測試計劃的實用性，即，測試計劃與實際之間的接近程度和可操做性。編寫測試計劃的目的在於充分考慮執行測試時的各類資源，包括測試內容、測試標準、時間資源、人力資源等等，準確地說是要分析執行時所可以調用的一切資源以及受各類條件限制，可能受到的各類影響。說的再明確一點就是要「計劃」「如何」去作「測試工做」，而不是「如何編寫測試計劃」。
二、要堅持「5W1H」的原則，明確測試內容與過程。
明確測試的範圍和內容（WHAT）；
明確測試的目的（WHY）；
明確測試的開始和結束日期（WHEN）；
明確給出測試文檔和軟件冊存放位置（WHERE）；
明確測試人員的任務分配（WHO）；
明確指出測試的方法和測試工具（HOW）。
三、採用評審和更新機制，確保測試計劃知足實際需求。
由於軟件項目是一個漸進的過程，中間不可避免地會發生需求變化，爲知足需求變化，測試計劃也須要及時地進行變動。
之因此採起相應的評審制度，就是要對測試計劃的完整性、正確性、可行性進行評估，以保證測試的質量。
四、測試策略要做爲測試的重點進行描述。
測試策略是測試計劃中的重要組成部分，測試計劃是從宏觀上說明一個項目的測試需求、測試方法、測試人員安排等因素，而測試策略則是說明實際的測試過程當中，應該怎樣具體實施。所以，測試策略必定要描述詳盡而且重點突出。
至於測試用例工做，我認爲咱們首先要明確測試用例在整個測試工做中的地位及其做用。我的認爲，測試用例在整個測試工做中的地位和做用主要體如今如下幾個方面：
一、測試用例是測試執行的實體，是測試方法、測試質量、測試覆蓋率的重要依據和表現形式；
二、測試用例是團隊內部交流以及交叉測試的依據；
三、在迴歸測試中，測試用例的存在能夠大大的下降測試的工做量，從而提升測試的工做效率；
四、測試用例便於測試工做的跟蹤管理，包括測試執行的進度跟蹤，測試質量的跟蹤，以及測試人員的工做量的跟蹤和考覈；
五、在測試工做開展前完成測試用例的編寫，能夠避免測試工做開展的盲目性；
六、測試用例是說服用戶相信產品質量的最佳依據，同時也能夠提供給客戶做爲項目驗收的依據。
當咱們認識到測試用例在政工測試工做中的地位及其做用以後，相信你們都已經認識到了測試用例對測試工做的重要性和必要性，那麼，咱們就來討論一下如何有效的保證測試用例的質量。
一、作好測試人員的項目培訓（主要指對需求分析、軟件設計、測試計劃的認知程度）工做。要想發揮團隊中每個成員的全部能力，最好的辦法就是讓他們每個人都清楚這個項目中的全部細節，以及本身要在這個項目中所承擔的責任。
二、儘量的利用以往其餘項目的測試用例；並將該項目中相似模塊進行歸類，按類編寫測試用例，再根據每一個模塊的特色進行修改，要充分利用測試用例的可重用性。
三、在時間資源緊張的狀況下，能夠按照測試的關鍵路徑編寫測試用例，針對關鍵路徑的測試用例必定要詳盡，其餘邊緣模塊的測試用例能夠考慮僅經過性測試（既僅證真測試）。
四、採用針對測試用例的模塊化編寫。我的建議將測試用例和測試數據分開，測試用例中的操做步驟應主要體現於業務流程的檢驗，而測試數據主要體現於針對系統的數據處理結果的檢驗。考慮到軟件項目的需求變動問題，建議將這兩項分開，經過測試用例編號進行關聯，以應對需求變化形成的測試用例的修改，從而減小測試用例的修改量，縮短項目週期，提升工做效率。

1七、WEB頁面測試有哪些方面？重點在哪裏？須要注意的有哪些？
專家分析：基於Web的系統測試與傳統的軟件測試既有相同之處，也有不一樣的地方，對軟件測試提出了新的挑戰。基於Web的系統測試不但須要檢查和驗證是否按照設計的要求運行，並且還要評價系統在不一樣用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。下面從功能、性能、可用性、客戶端兼容性、安全性等方面討論基於Web的系統測試方法。   
隨着Internet和Intranet/Extranet的快速增加，Web已經對商業、工業、銀行、財政、教育、政府和娛樂及咱們的工做和生活產生了深遠的影響。許多傳統的信息和數據庫系統正在被移植到互聯網上，電子商務迅速增加，早已超過了國界。範圍普遍的、複雜的分佈式應用正在Web環境中出現。Web的流行和無所不在，是由於它能提供支持全部類型內容鏈接的信息發佈，容易爲最終用戶存取。在基於Web的系統開發中，若是缺少嚴格的過程，咱們在開發、發佈、實施和維護Web的過程當中，可能就會碰到一些嚴重的問題，失敗的可能性很大。並且，隨着基於Web的系統變得愈來愈複雜，一個項目的失敗將可能致使不少問題。當這種狀況發生時，咱們對Web和Internet的信心可能會沒法挽救地動搖，從而引發Web危機。而且，Web危機可能會比軟件開發人員所面對的軟件危機更加嚴重、更加普遍。   
在Web工程過程當中，基於Web系統的測試、確認和驗收是一項重要而富有挑戰性的工做。基於Web的系統測試與傳統的軟件測試不一樣，它不但須要檢查和驗證是否按照設計的要求運行，並且還要測試系統在不一樣用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。然而，Internet和Web媒體的不可預見性使測試基於Web的系統變得困難。所以，咱們必須爲測試和評估複雜的基於Web的系統研究新的方法和技術。
1、功能測試
一、連接測試
連接是Web應用系統的一個主要特徵，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。連接測試可分爲三個方面。首先，測試全部連接是否按指示的那樣確實連接到了該連接的頁面；其次，測試所連接的頁面是否存在；最後，保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有連接指向該頁面，只有知道正確的URL地址才能訪問。 連接測試能夠自動進行，如今已經有許多工具能夠採用。連接測試必須在集成測試階段完成，也就是說，在整個Web應用系統的全部頁面開發完成以後進行連接測試。
二、表單測試
當用戶給Web應用系統管理員提交信息時，就須要使用表單操做，例如用戶註冊、登錄、信息提交等。在這種狀況下，咱們必須測試提交操做的完整性，以校驗提交給服務器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。若是使用了默認值，還要檢驗默認值的正確性。若是表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字符，測試時能夠跳過這些字符，看系統是否會報錯。
三、Cookies測試
Cookies一般用來存儲用戶信息和用戶在某應用系統的操做，當一個用戶使用Cookies訪問了某一個應用系統時，Web服務器將發送關於用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來建立動態和自定義頁面或者存儲登錄等信息。
若是Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工做。測試的內容可包括Cookies是否起做用，是否按預約的時間進行保存，刷新對Cookies有什麼影響等。
四、設計語言測試
Web設計語言版本的差別能夠引發客戶端或服務器端嚴重的問題，例如使用哪一種版本的HTML等。當在分佈式環境中開發時，開發人員都不在一塊兒，這個問題就顯得尤其重要。除了HTML的版本問題外，不一樣的腳本語言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要進行驗證。
五、數據庫測試
在Web應用技術中，數據庫起着重要的做用，數據庫爲Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在Web應用中，最經常使用的數據庫類型是關係型數據庫，能夠使用SQL對信息進行處理。
在使用了數據庫的Web應用系統中，通常狀況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是因爲用戶提交的表單信息不正確而形成的，而輸出錯誤主要是因爲網絡速度或程序設計問題等引發的，針對這兩種狀況，可分別進行測試。
2、性能測試
一、鏈接速度測試
用戶鏈接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶能夠等較長的時間，但若是僅僅訪問一個頁面就不會這樣。若是Web系統響應時間太長（例如超過5秒鐘），用戶就會因沒有耐心等待而離開。
另外，有些頁面有超時的限制，若是響應速度太慢，用戶可能還沒來得及瀏覽內容，就須要從新登錄了。並且，鏈接速度太慢，還可能引發數據丟失，使用戶得不到真實的頁面。
二、負載測試
負載測試是爲了測量Web系統在某一負載級別上的性能，以保證Web系統在需求範圍內能正常工做。負載級別能夠是某個時刻同時訪問Web系統的用戶數量，也能夠是在線數據處理的數量。例如：Web應用系統能容許多少個用戶同時在線？若是超過了這個數量，會出現什麼現象？Web應用系統可否處理大量用戶對同一個頁面的請求？
三、壓力測試
負載測試應該安排在Web系統發佈之後，在實際的網絡環境中進行測試。由於一個企業內部員工，特別是項目組人員老是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，因此，只有放在Internet上，接受負載測試，其結果纔是正確可信的。
進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼狀況下會崩潰。黑客經常提供錯誤的數據負載，直到Web應用系統崩潰，接着當系統從新啓動時得到存取權。
壓力測試的區域包括表單、登錄和其餘信息傳輸頁面等。
3、可用性測試
一、導航測試
導航描述了用戶在一個頁面內操做的方式，在不一樣的用戶接口控制之間，例如按鈕、對話框、列表和窗口等；或在不一樣的鏈接頁面之間。經過考慮下列問題，能夠決定一個Web應用系統是否易於導航：導航是否直觀？Web系統的主要部分是否可經過主頁存取？Web系統是否須要站點地圖、搜索引擎或其餘的導航幫助？
在一個頁面上放太多的信息每每起到與預期相反的效果。Web應用系統的用戶趨向於目的驅動，很快地掃描一個Web應用系統，看是否有知足本身須要的信息，若是沒有，就會很快地離開。不多有用戶願意花時間去熟悉Web應用系統的結構，所以，Web應用系統導航幫助要儘量地準確。
導航的另外一個重要方面是Web應用系統的頁面結構、導航、菜單、鏈接的風格是否一致。確保用戶憑直覺就知道Web應用系統裏面是否還有內容，內容在什麼地方。
Web應用系統的層次一旦決定，就要着手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯。
二、圖形測試
在Web應用系統中，適當的圖片和動畫既能起到廣告宣傳的做用，又能起到美化頁面的功能。一個Web應用系統的圖形能夠包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試的內容有：
（1）要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一塊兒，以避免浪費傳輸時間。Web應用系統的圖片尺寸要儘可能地小，而且要能清楚地說明某件事情，通常都連接到某個具體的頁面。
（2）驗證全部頁面字體的風格是否一致。
（3）背景顏色應該與字體顏色和前景顏色相搭配。
（4）圖片的大小和質量也是一個很重要的因素，通常採用JPG或GIF壓縮。
三、內容測試
內容測試用來檢驗Web應用系統提供信息的正確性、準確性和相關性。
信息的正確性是指信息是可靠的仍是誤傳的。例如，在商品價格列表中，錯誤的價格可能引發財政問題甚至致使法律糾紛；信息的準確性是指是否有語法或拼寫錯誤。這種測試一般使用一些文字處理軟件來進行，例如使用Microsoft Word的"拼音與語法檢查"功能；信息的相關性是指是否在當前頁面能夠找到與當前瀏覽信息相關的信息列表或入口，也就是通常Web站點中的所謂"相關文章列表"。
四、總體界面測試
總體界面是指整個Web應用系統的頁面結構設計，是給用戶的一個總體感。例如：當用戶瀏覽Web應用系統時是否感到溫馨，是否憑直覺就知道要找的信息在什麼地方？整個Web應用系統的設計風格是否一致？
對總體界面的測試過程，實際上是一個對最終用戶進行調查的過程。通常Web應用系統採起在主頁上作一個調查問卷的形式，來獲得最終用戶的反饋信息。
對全部的可用性測試來講，都須要有外部人員（與Web應用系統開發沒有聯繫或聯繫不多的人員）的參與，最好是最終用戶的參與。
4、客戶端兼容性測試
一、平臺測試
市場上有不少不一樣的操做系統類型，最多見的有Windows、Unix、Macintosh、Linux等。Web應用系統的最終用戶究竟使用哪種操做系統，取決於用戶系統的配置。這樣，就可能會發生兼容性問題，同一個應用可能在某些操做系統下能正常運行，但在另外的操做系統下可能會運行失敗。
所以，在Web系統發佈以前，須要在各類操做系統下對Web系統進行兼容性測試。
二、瀏覽器測試
瀏覽器是Web客戶端最核心的構件，來自不一樣廠商的瀏覽器對Java，、JavaScript、 ActiveX、 plug-ins或不一樣的HTML規格有不一樣的支持。例如，ActiveX是Microsoft的產品，是爲Internet Explorer而設計的，JavaScript是Netscape的產品，Java是Sun的產品等等。另外，框架和層次結構風格在不一樣的瀏覽器中也有不一樣的顯示，甚至根本不顯示。不一樣的瀏覽器對安全性和Java的設置也不同。
測試瀏覽器兼容性的一個方法是建立一個兼容性矩陣。在這個矩陣中，測試不一樣廠商、不一樣版本的瀏覽器對某些構件和設置的適應性。
5、安全性測試
Web應用系統的安全性測試區域主要有：
（1）如今的Web應用系統基本採用先註冊，後登錄的方式。所以，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，能夠試多少次的限制，是否能夠不登錄而直接瀏覽某個頁面等。
（2）Web應用系統是否有超時的限制，也就是說，用戶登錄後在必定時間內（例如15分鐘）沒有點擊任何頁面，是否須要從新登錄才能正常使用。
（3）爲了保證Web應用系統的安全性，日誌文件是相當重要的。須要測試相關信息是否寫進了日誌文件、是否可追蹤。
（4）當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。
（5）服務器端的腳本經常構成安全漏洞，這些漏洞又經常被黑客利用。因此，還要測試沒有通過受權，就不能在服務器端放置和編輯腳本的問題。
6、總結
以上從功能、性能、可用性、客戶端兼容性、安全性等方面討論了基於Web的系統測試方法。
基於Web的系統測試與傳統的軟件測試既有相同之處，也有不一樣的地方，對軟件測試提出了新的挑戰。基於Web的系統測試不但須要檢查和驗證是否按照設計的要求運行，並且還要評價系統在不一樣用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。
web頁面測試注意事項：
Web測試每每不被測試人員重視，認爲是沒有技術含量的體力活，本人結合本身的工做經驗談談Web測試中的一些注意事項，或許會對你們有所幫助。測試過程當中主要考慮HTML頁面、TCP/IP通信、Internet連接、防火牆和運行在web頁面上的一些程序（例如，applet、javascript、應用程序插件），以及運行在服務器端的應用程序（例如，CGI腳本、數據庫接口、日誌程序、動態頁面產生器）。另外，由於服務器和瀏覽器類型不少，不一樣版本差異很小，可是表現出現的結果卻不一樣，鏈接速度以及日益迅速的技術和多種標準、協議。固然還能夠藉助Web測試工具對其進行自動化測試。其它要考慮的以下：
一、服務器上指望的負載是多少（例如，每單位時間內的點擊量），在這些負載下應該具備什麼樣的性能（例如，服務器反應時間，數據庫查詢時間）。性能測試須要什麼樣的測試工具呢（例如，web負載測試工具，其它已經被採用的測試工具，web 自動下載工具，等等）？
二、系統用戶是誰？他們使用什麼樣的瀏覽器？使用什麼類型的鏈接速度？他們是在公司內部仍是外部？
三、在客戶端但願有什麼樣的性能（例如，頁面顯示速度？動畫、applets的速度等？如何引導和運行）？
四、容許網站維護或升級嗎？
五、須要考慮安全方面（防火牆，加密、密碼等）是否須要，如何作？怎麼能被測試？須要鏈接的Internet網站可靠性有多高？對備份系統或冗餘連接請求如何處理和測試？web網站管理、升級時須要考慮哪些步驟？需求、跟蹤、控制頁面內容、圖形、連接等有什麼需求？
六、須要考慮哪一種HTML規範？多麼嚴格？容許終端用戶瀏覽器有哪些變化？
七、頁面顯示和/或圖片佔據整個頁面或頁面一部分有標準或需求嗎？
八、內部和外部的連接可以被驗證和升級嗎？多久一次？
九、產品系統上能被測試嗎？或者須要一個單獨的測試系統？瀏覽器的緩存、瀏覽器操做設置改變、撥號上網鏈接以及Internet中產生的「交通堵塞」問題在測試中是否解決，這些考慮了嗎？
十、服務器日誌和報告內容能定製嗎？它們是否被認爲是系統測試的主要部分並須要測試嗎？
十一、CGI程序、applets、javascripts、ActiveX 組件等能被維護、跟蹤、控制和測試嗎？

1八、測試用的評審須要注意一些什麼？主要是針對哪些人羣？
專家分析：在國內這個評審這個概念很淡薄，可是倒是無處不在的。好比常常作的代碼走查、立項會議、需求討論等等其實都是一種簡化的評審，有的公司把這叫作「頭腦風暴」（每每是遇到難題的時候集中你們的智慧來衝關 ）
一、能夠評審的東東不少，需求、策略、計劃、用例、代碼.....基本上項目中你能想到的東西，均可以拿出來評審。
二、組織評審須要有清晰的目的（這個是整個環節中重要的部分），很簡單，你首先要知道，你須要從這個評審中獲得什麼？也許是但願被評審東東更加完善，也許是但願增長你們交流的機會，甚至多是爲了應付上面的檢查等等。
三、不一樣目的評審，參與人員天然也隨之變化：好比，但願需求更加完善的評審，理論一切與產品有關的人員，大到項目經理，小到一線銷售人員都須要來參加。可是，每每評審的人員越多，時間上就越難安排，因此須要結合實際狀況來刪減。固然，也不是說必需要XX人蔘加的評審才叫評審，好比一個BA與一個客戶或開發人員私下的一次交流，只要作了詳細的記錄，也能夠算做是一個評審。
因此，有內容的評審實際上是不拘形式的，假如非得搞個內審或外審來規範，我只能說那是走過場而已。
四、在組織評審的細節上，有一點很重要：不要在評審過程當中「照本宣書」。
不少公司在評審前不作準備，評審時拉個主持人上去就對着文檔、PPT一陣讀，半天下來，問你們有沒問題，結果只能是隻言片語。
因此，在評審前最好先作預審，也就是在評審前，給予評審人員必定的時間，也許是3、兩天，也許是一星期，讓評審人員熟悉評審目標，並提出本身的意見，由一個統一的程序收集起來，在評審中逐一解決。這樣的效果會好不少。
五、最後說說比較規範的評審流程
肯定評審目標——肯定參與人員（包括主持人、記錄員、評審員等）——安排評審時間——預審——整理預審報告——評審——整理評審報告——做者修改評審目標——複審（複審能夠走簡單流程，由各個提建議的評審人員查看本身的建議是否獲得合理的修改）——存檔
19、測試用例的粒度如何界定？碰到功能複雜的測試，應該如何書寫測試用例？
專家分析：根據需求來定。較複雜的，能夠先畫出流程圖，再進行編寫測試用例。