『壹』 我需要寫一個網站前後台的軟體測試計劃，要怎麼寫急！
軟體壓力測試計劃實例 發布: 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。測試計劃標識符
2。目錄表
3。參考文獻
4。詞彙表
5。介紹
6。測試項
7。待測特徵
8。不予測試的特徵
9。方法
10。測試項通過/失敗准則
11。掛起准則和恢復需求
12。測試交付物
13。測試任務
14。環境需求
15。職責
16。人員安排與培訓需求
17。進度表
18。計劃風險與應急措施
19。審批
『叄』 求電子商務系統的測試計劃.....急
我也需要啊。
『肆』 iwebshop測試計劃怎麼寫
商城名稱：您的iWebShop商城的名字
商城logo：設置商城首頁頭部的logo圖片
商城標題：站點的名稱，也叫網站的標題，設置後將顯示在位於瀏覽器左上角的標題欄位置。
商城關鍵字：iWebShop站點的關鍵字，便於引擎查找，當輸入多個時，需要用逗，地或者逗|地分隔。例如：shop|iweb。
商城描述：iWebShop站點的重點描述信息，便於引擎查找，讓網站用戶清楚地了解網站概要。
公司名稱：iWebShop商城所屬的公司名字。
版權信息：iWebShop站點版權信息。
ICP備案號：信息產業部所頒發的備案信息。
流量統計代碼：iWebShop網站管理員可以將流量統計代碼添加到此處的文本輸入框中。
是否關閉注冊：（下拉列表框）選擇開啟或關閉，關閉注冊後，此時任何人都無法進行注冊。
是否關閉注冊：（文本輸入框）填寫當選擇關閉會員注冊時，訪客所看到的提示性信息。
注冊同意條款：用戶注冊時所需要同意的服務條款。
支持html代碼格式:換行；加粗。
『伍』 加入一個測試經理對一個網站進行測試，都需要做什麼做測試計劃、用例、總結等等都有什麼需要注意的
（一） 先說測試計劃吧
一個好的測試計劃是用來計劃測試的，指導整個測試過程。所以一個好的測試計劃一定是可以指導測試的，就是對整個測試過程中的人力，時間，資源，策略，范圍的一個說明。
作為一個測試計劃來講，核心的三個要素是時間，資源，范圍。（這句話摘自微軟的軟體測試培訓材料），時間就是什麼時候做以及要花多久做，資源就是你要調用的人力、機器等資源，范圍是你要測試的東西以及測試重點。
除以上提到的3項之外，還有比較重要的項目有策略（具體就是怎麼測）、風險控制（一旦有問題採取什麼應急措施）等項目。
要把一個計劃做得很有實用性，按照筆者的經驗，要注意以下幾個方面：
a. 上面提到的三要素不能少
b. 測試策略一定要交待清楚，就是大概怎麼測試
c. 需要其他人員（部門）協調的，要交待清楚
d. 在估計測試所需的時間、人力及其它資源時，盡量做到客觀、准確、留有餘地，特別是估計開發時間和debug時間，以及要對自己的執行用例速度，回歸速度心裡有數
e. 測試計劃中每個階段要明確表明，並且測試階段的輸入、輸出文檔要清楚
f. 測試計劃中的時間段不宜太長（最好以day為單位），太長就比較模糊，不好度量，不好check
g. 一定要有風險控制，要不然計劃缺乏可執行性
h. 計劃寫完之後不是裝在兜里，要組織PM和Dev進行評審
i. 要不斷更新計劃，記住：每個計劃都是動態的，不是一成不變的
（二） 再說測試用例
和測試計劃一樣，測試用例很多時候也淪為形式，這是軟體測試的可悲之處，軟體測試的依據就是測試用例，如果用例棄之不用，你憑什麼做好測試？這個很可笑。但是實際測試過程中很多時候測試用例並沒用到實處，筆者認為還是用例實用性問題，有的時候用例洋洋灑灑數萬字，到回歸測試的時候根本用不上，至於如何選擇回歸測試用例，我曾經寫過另一篇文章，歡迎查閱。
下面我就個人體會談談做好測試用例的關鍵。
首先，在做用例之前，要做兩件事情。
第一， 透徹了解程序（需求和架構）。
第二， 做一個正式的測試設計（最好文檔化）。然後再開始寫用例。一般寫用例的步驟和建房子一樣，先搭框架，然後填材料，填材料的時候，主要根據需求做相關的設計，具體的設計方法就是那幾種（鄭老的書上寫的很清楚）
一般來說，設計一個比較實用的測試用例，注意如下幾個方面：
a. 選用好的用例管理工具（這個很重要，千萬不要用word，excel）
b. 用例一定要及時更新（補充新的想法，刪除過時的需求）
c. 做好用例分級
d. 做好用例評審，寫用例之前可以征詢相關人員的意見
e. 可以考慮結對編寫，這個是不錯的主意
f. 要全面，包括功能、性能、兼容性、安全性、易用性、容錯性等等
g. 注意把握適當的顆粒度
OK，以上是我個人總結的一些心得，希望對您有些幫助.
-----------------------------------------------------------------------------------------
我不知道lz說的做好測試計劃中的「做好」兩字具體指的是什麼
對於目前大部分公司存在的狀況，很多測試計劃文檔只是一種形式而已
所以我的理解是：怎樣讓測試計劃對整個測試工作真正具有指導作用
這里把測試計劃和測試方案分開來講（計劃對應於管理層面的問題，方案對應於技術方面的問題）
測試計劃中最重要的內容包括：進度安排；人力、物力資源分配（包括組織結構等）、風險假設和規避措施。（其他像軟體版本號之類的，只要是個人都會寫，這里不列了）
寫好測試計劃的關鍵在於：
1 充分了解你的團隊的整體實力和團隊中每個成員的特點
2 充分理解為當前軟體制訂的整個研發活動過程
帶過項目的人都知道：在實際項目中，往往進度才是第一位的，但是對進度的把握和估算卻是極其困難的。只有做到這兩點才有可能對進度有比較准確的把握，對人員有一個合理的分配。否則所謂的進度，所謂的資源分配，都是拍腦袋得出的結果，風險假設更是無從談起，這樣的測試計劃文檔只能流於形式也就不足為奇了。
寫好測試方案的關鍵在於：
1 有一個合理的測試計劃
2 熟悉相關業務
3 深入體會用戶的實際需求
這個不想多解釋了，不難理解。
至於測試用例
看到上面不少朋友認為關鍵在於理解用戶需求
其實理解用戶實際需求是一切的根本
並且對於有些測試（比如像單元測試）對應的測試用例通常和用戶需求之間的關系可能並不直接或是十分密切
當然，如果有一份好的需求和設計文檔的話，什麼事情都解決了。 可是現實往往是不存在這樣的文檔的。
所以我的看法是：
1 對業務理解的深入程度
2 經驗
3 有自己的文檔
前兩條不解釋了。自己的文檔包括兩方面：一個是常用的特殊測試數據，比如一些特殊字元，極限長度的輸入等等。這個在項目時間緊迫的時候是非常有幫助的（有的時候甚至可以當成check list）。另一個就是自己測試模塊對應的相關需求和設計文檔。伺服器上的標准文檔拖到本地來並且記得及時更新。然後在測試過程中，需要什麼內容文檔上沒有，最直接的方法是和開發人員溝通。（其實我很反對這么做。你想，按開發人員自己說的標准去測他們自己開發的模塊能測出因為需求或者設計錯誤導致的問題么……應該是和客戶和designer去溝通，可惜一般沒有這條件-_-）任何標准文檔上缺少的內容，只要是和你有關的，一定要記得做記錄。當然你有時間有精力把整個系統的需求和設計文檔都搗鼓出來最好，不過通常是沒這可能性的。
『陸』 求軟體測試計劃的詳細案例
測試計劃
測試概述:
測試背景:
測試手段:
手工測試
測試范圍:
功能測試 界面測試 介面測試 容錯測試 安全測試 性能測試 穩定性測試 恢復測試 配置測試 安裝測試 文檔測試 可用性測試
測試環境:
軟體環境
操作系統
被測軟體 其他軟體
硬體配置
PC 配置：CPU
內存 ：1G
外部設備
測試策略:
一．功能測試
1．菜單點擊相應標題菜單，驗證其功能是否能實現
2．工具欄 點擊相應工具欄，驗證其功能是否實現
3．按鈕
4．快捷鍵
5.下拉框
6．單選按鈕
7. 復選按鈕
8.切換按鈕
9.編輯按鈕
10.觸發鍵：
11．鏈接：
二 .界面測試 點擊相應按鈕是否滿足UI設計
1登陸界面
2總界面
3 輸入界面
4處理界面
5輸出界面
6提示界面
三. 容測測試 是否滿足資料庫設計要求
主鍵容錯
非空容錯
四、介面測試 點擊相應的菜單 按鈕 工具欄按鈕 彈出相應的介面界面，驗證其功能是否能正確實現 模塊之間的調用 是否滿足概要設計的要求
1.內部介面
2.業務流程測試
3.外部介面
五、安全測試
1.應用級安全測試
2.系統級安全測試 點擊相應菜單，驗證其功能是否實現
六．性能側試
七．負載測試
八.穩定性測試
九 .恢復測試
十.配置測試
十一. 安裝測試
十二.文檔測試
軟體需求 概要設計 測試計劃 測試用例 技術文檔的 質量通過評審 來保障
在線幫助
安裝手冊
使用手冊
七.測試進度安排
工作內容 開始時間 結束時間 責任人 提交的結果 備注
編寫測試計劃
設計發簡訊測試用例
設計資費測試用例
搭建測試環境
集成測試 執行發簡訊測試用例
執行資費測試用例
集成測試分析報告
系統測試 性能測試
恢復測試
配置測試
系統測試分析報告