① 軟體測試計劃怎麼寫要包含哪些內容
軟體壓力測試計劃實例
發布:
2010-12-21
10:08
|
作者:
不詳
|
來源:
領測測試網采編
|
查看:
257次
|
進入軟體測試論壇討論
領測軟體測試網
軟體壓力測試計劃實例
軟體測試利用現代的設計技術和正式的技術復審可以減少代碼中存在的初始錯誤，但是錯誤總是存在的，如果開發者找不到錯誤，那麼，客戶就會找到它們。越來越多的軟體組織認識到軟體測試是軟體質量保證的重要元素之一，很多軟體開發組織將30%—40%甚至更多的項目資源用在測試上，軟體測試技術和軟體測試策略受到了高度的重視和廣泛的應用。本文不想就軟體測試技術和軟體測試策略作深入的理論分析，而是列舉一個在軟體系統測試階段進行的壓力測試實例，希望能通過這個實例與從事軟體測試相關工作的朋友進行交流。首先介紹一下實例中軟體的項目背景，該軟體是一個典型的三層c/s架構的mis系統(客戶端/應用伺服器/資料庫管)，中間層是業務邏輯層，應用伺服器處理所有的業務邏輯，但應用伺服器本身不提供負載均衡的能力，而是利用開發工具提供的orb(對象請求代理)軟體保證多個應用伺服器間的負載均衡。本次測試的目的是：進行單個應用伺服器的壓力測試，找出單個應用伺服器能夠支持的最大客戶端數。測試壓力估算的依據是：假定在實際環中，用戶只啟用一個應用伺服器進行所有的業務處理。方法是：按照正常業務壓力估算值的1~10倍進行測試，考察應用伺服器的運行情況。壓力測試的詳細計劃如下：壓力測試計劃1、測試計劃名稱河北省公安交通管理信息系統壓力測試計劃。2、測試內容2.1背景本次測試中的壓力測試是指模擬實際應用的軟硬體環境及用戶使用過程的系統負荷，長時間運行測試軟體來測試被測系統的可靠性，同時還要測試被測系統的響應時間。用戶的實際使用環境：◇由兩台ibm
xseries250
pc
server組成的microsoft
cluster;◇資料庫管理系統採用oracle8.1.6;◇應用伺服器程序和資料庫管理系統同時運行在microsoft
cluster上。◇有200個用戶使用客戶端軟體進行業務處理，每年通過軟體進行處理的總業務量為：150萬筆業務/年。2.2測試項應用伺服器的壓力測試;2.3不被測試的特性◇系統的客戶端應用程序的內部功能;◇資料庫中的數據量對程序性能的影響。3、測試計劃3.1測試強度估算測試壓力估算時採用如下原則：◇全年的業務量集中在8個月完成，每個月20個工作日，每個工作日8個小時;◇採用80—20原理，每個工作日中80%的業務在20%的時間內完成，即每天80%的業務在1.6小時內完成;測試壓力的估算結果：
② 如何書寫軟體測試計劃書
1引言
1.1編寫目的
本測試計劃的具體編寫目的，指出預期的讀者范圍。
1.2背景
說明：
a． 測試計劃所從屬的軟體系統的名稱；
b． 該開發項目的歷史，列出用戶和執行此項目測試的計算中心，說明在開始執行本測試計劃之前必須完成的各項工作。
1.3定義
列出本文件中用到的專門術語的定義和外文首字母組詞的原片語。
1.4參考資料
列出要用到的參考資料，如：
a． 本項目的經核準的計劃任務書或合同、上級機關的批文；
b． 屬於本項目的其他已發表的文件；
c． 本文件中各處引用的文件、資料，包括所要用到的軟體開發標准。列出這些文件的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。
2計劃
2.1軟體說明
提供一份圖表，並逐項說明被測軟體的功能、輸入和輸出等質量指標，作為敘述測試計劃的提綱。
2.2測試內容
列出組裝測試和確認測試中的每一項測試內容的名稱標識符、這些測試的進度安排以及這些測試的內容和目的，例如模塊功能測試、介面正確性測試、數據文卷存取的測試、運行時間的測試、設計約束和極限的測試等。
2.3測試1（標識符）
給出這項測試內容的參與單位及被測試的部位。
2.3.1進度安排
給出對這項測試的進度安排，包括進行測試的日期和工作內容（如熟悉環境。培訓、准備輸入數據等）。
2.3.2條件
陳述本項測試工作對資源的要求，包括：
a． 設備所用到的設備類型、數量和預定使用時間；
b． 軟體列出將被用來支持本項測試過程而本身又並不是被測軟體的組成部分的軟體，如測試驅動程序、測試監控程序、模擬程序、樁模塊等等；
c． 人員列出在測試工作期間預期可由用戶和開發任務組提供的工作人員的人數。技術水平及有關的預備知識，包括一些特殊要求，如倒班操作和數據鍵入人員。
2.3.3測試資料
列出本項測試所需的資料，如：
a． 有關本項任務的文件；
b． 被測試程序及其所在的媒體；
c． 測試的輸入和輸出舉例；
d． 有關控制此項測試的方法、過程的圖表。
2.3.4測試培訓
說明或引用資料說明為被測軟體的使用提供培訓的計劃。規定培訓的內容、受訓的人員及從事培訓的工作人員。
2.4測試2（標識符）
用與本測試計劃2.3條相類似的方式說明用於另一項及其後各項測試內容的測試工作計劃。
3測試設計說明
3.1測試1（標識符）
說明對第一項測試內容的測試設計考慮。
3.1.1控制
說明本測試的控制方式，如輸入是人工、半自動或自動引入、控制操作的順序以及結果的記錄方法。
3.1.2輸入
說明本項測試中所使用的輸入數據及選擇這些輸入數據的策略。
3.1.3輸出
說明預期的輸出數據，如測試結果及可能產生的中間結果或運行信息。
3.1.4過程
說明完成此項測試的一個個步驟和控制命令，包括測試的准備、初始化、中間步聚和運行結束方式。
3.2測試2（標識符）
用與本測試計劃3.l條相類似的方式說明第2項及其後各項測試工作的設計考慮。
4評價准則
4.1范圍
說明所選擇的測試用例能夠接查的范圍及其局限性。
4.2數據整理
陳述為了把測試數據加工成便於評價的適當形式，使得測試結果可以同，已知結果進行比較而要用到的轉換處理技術，如手工方式或自動方式；如果是用自動方式整理數據，還要說明為進行處理而要用到的硬體、軟體資源。
4.3尺度
說明用來判斷測試工作是否能通過的評價尺度，如合理的輸出結果的類型、測試輸出結果與預期輸出之間的容許偏離范圍、允許中斷或停機的最大次數。
③ 軟體測試計劃怎麼寫求助...
軟體測試計劃是軟體測試員與產品開發小組交流意圖的主要方式。
包括的內容有
對高級期望、何為軟體缺陷，進行定義。
確定測試人員，在哪裡測試，確定資源要求以及如何獲得他們。確定團隊間的責任。
確定哪些需要測試，哪些不需要測試。
定義測試階段，確定本次測試有多少階段，定義每個階段的開始、退出規則。
定義測試策略，確定使用黑盒還是白盒測試，用手工還是使用工具，如果使用工具，是自行開發還是購買已有商用解決方案。
測試員的任務分配。
定義測試進度。
風險評估。
④ 軟體測試計劃怎麼寫
1．引言
1．1項目背景
1．2參考資料（計劃編寫依據：可行性分析報告／軟體需求定義／軟體概要設計／軟體詳細設計／用戶使用說明書／……）
1．3測試術語
1．4有關項目人員組成以及聯系方式（開發人員／版本控制人員／測試人員／軟、硬、結構、營銷人員等）
2．任務概述
2．1測試范圍
2．2測試目標
2．3廣義上還包含測試需求分析／測試用例編寫／測試環境搭建／測試培訓／測試執行等
⑤ 如何寫一份靠譜的軟體測試計劃
所謂計劃就是用來指導執行的，那麼想要執行到尾就要考慮執行計劃的人。如果計劃忽略了人的因素就是「拍腦袋」了。
大致總結軟體測試計劃要符合的內容如下：
1、需求方的高層質量目標
這個是最重要的，多數情況下就是客戶和直接發起領導的高層意圖，比如速度快、界面美觀、高質量等定性的指標，能夠指示質量關注重點。
2、公司運營管理的總體要求
比如配合項目/產品需要多長時間完成、成本多少等等，這個通常是限制，要在這個大的限制下做好質控，不能說為了達到90%的測試覆蓋率，而讓項目成本超標，那就不是測試的本來目的了。
3、設計、開發的要求
要了解開發人員的工作習慣、使用的工具/平台/構架，有些事情是開發工具解決不了的問題，不要硬生生通過「文字」反饋給開發人員，應該先有個溝通，在形成一定共識的基礎上設計測試計劃，對於設計或構架等難於解決的問題，也要有渠道反饋給管理層，以做風險應對，而不要針鋒相對非逼著研發人員修改，最後可能會出現拖延、誤修復等更嚴重的問題。
4、測試的要求
了解公司的質量管理要求、策略、制度、流程，更重要的是了解執行測試的人員的實際能力和經驗。如果這份測試計劃包括了定義的測試操作（也即是測試用例），那這部分是不能因人而異的，如果說測試計劃是為了指導測試人員開發測試用例並指明測試工作安排的，則可以考慮根據執行人員的經驗水平進行繁簡處理調整，如果都是初級人員，則測試計劃就要寫得細一些；如果都是高級人員，則可以把測試計劃的執行主體部分寫的寬泛一些。
5、實施的要求
這里包括項目/產品的實施人員、運維人員、銷售人員的意見，比如項目後期的運維方式、系統的版本控制、自動更新、授權許可機制等。這些雖然不是軟體的主體目標，但是卻與公司運營息息相關，所以也必須在測試策略中予以考慮。
總之，要做出「一份靠譜的軟體測試計劃」在最開始的幾次，需要付出大量的精力，一但這些內容了解了，並記住「重視人的因素」之後，以後都能夠做出「靠譜的測試計劃」了。