軟件測試環境怎麼寫

定義測試策略 目前止您肯定參加議客戶倚靠寬議桌問您：系統能處理千用戶傳統負載測試要求您編寫腳本並執行測試試圖給問題精確答案於種測試您需要定義處理含義及 1000 名典型用戶站點情形您需要定義測試用例代表各種用戶：例購買股票或註冊新帳戶接您必須估計用戶些測試用例布數據進行假設即模擬真實用戶與應用程序交互需要思考間（或等待間）負載測試期間某面致反映同數量真實用戶站點情形 種幾足處首先其結比您做假設更顯確假設使結現偏差 其估計真實用戶需要量客戶端硬件每名虛擬用戶給定需要處理能力內存量則典型客戶端計算機處理約 200 名虛擬用戶 2000 名用戶併發處理級別測試需要 10 臺客戶端計算機 - 筆重投資測試使用 HTTPS 站點需要客戶端硬件 終難向您發團隊提供操作導向資訊某處現故障難再現該問題 作備選案我建議您圍繞些關鍵問題設計測試用例： ？？ 系統瓶頸哪系統能同步處理少併發請求 ？？ 響應間變接受前臺機器能處理少名同步超級用戶 ？？ 添加額外硬件結線形增 ？？ 任何穩定性問題妨礙站點執行於產環境 使用發團隊（發團隊參與能現問題領域）提供附加資訊請關注些領域於示例其瓶頸能定單提交領域您派更具體問題例提交流程同處理少請求攻擊些特定領域快且本用向發團隊提供操作導向資訊便能改進系統使用種同我推薦您記住遵循建議 關注負載測試我已提首先要做構建導致潛瓶頸穩定性問題腳本種數據第假設第二使您能夠應用程序收集原始數據根據假設確定更進階別結用擔識別低風險站點腳本編寫問題例站點幫助領域或讀文檔領域編寫腳本能現系統瓶頸 同步請求使用同步請求攻擊瓶頸處主意模擬壞情況：即站點用戶精確同間攻擊瓶頸通使用戶同步您重複進行測試同步結則難再現故障情況使用同步點做點同步點數較健壯（本較高）測試工具提供項功能同步點迫使每名虛擬用戶直等剩餘用戶達腳本定義點才能始請求允許您精確並重復確定站點潛瓶頸區域能處理併發用戶數例限 7 名併發同步用戶 創建循環測試用例腳本使測試用例循環另種每測試用例迭代前站點應處於相同狀態允許您間重複執行測試用例 使用超級用戶使用我所稱超級用戶前面所提超級用戶執行思考間設定零請記住思考間假設用於規測試使虛擬用戶模擬真實用戶虛擬用戶思考間減半則服務器實際負載加倍另種服務器真關與負載關變量每秒請求數虛擬用戶數量及其思考間結合起該負載 讓我進行些數運算使概念更清晰面公式計算訪問站點真實用戶負載（請求數/秒）： 例某站點 100 名併發用戶假設載間 10 秒思考間 30 秒則每秒 2.5 頁我假設每頁 3 請求則 Web 服務器轉化每秒 7.5 請求 超級用戶執行測試觀察每秒請求數並與剛剛計算值比較根據我經驗真實用戶數與超級用戶數比例通約 15:1於同示例意味着 （100/15） 名超級用戶與 100 名普通用戶相同負載再舉例假設 10 名超級用戶響應間變接受請注意轉換真實用戶數該點每秒請求數現您進行任何希望思考間假設甚至更改需重新執行測試幾測試您能根據直覺超級用戶數轉換真實用戶數允許您保持用戶數控減少所需客戶端硬件數量幷包含負載測試軟件本 些超級用戶測試用例於機測試用要測試站點伸縮性添加第二臺 Web 服務器負載平衡器並重復超級用戶測試理想情況看見相同相應數前您能加倍超級用戶數量 要答穩定性問題執行測試延間段內維持合理數量併發且未同步超級用戶我項目熬通宵甚至 24 晝夜停持續間與應用程序關我稱內置測試旦您已採取步驟識別並潛解決找瓶頸則重複同步點測試看限否所增用所支援新併發用戶數重新執行內置測試努力提高數字目標重複該循環直達質量條 少用戶呢 儘管向發團隊提供價值資訊使您更難於答議室問題您近似估計答案例假設站點壞情況瓶頸顯示每臺計算機於 20 名超級用戶情況響應間超 10 秒根據您我建議公式計算結近似估計 300 名真實用戶（20 名超級用戶 * 15 名真實用戶）您做與規用例相同假設通情況百少用戶使用站點領域假設預期 50% 用戶使用領域其領域例文檔或數據庫讀取用戶比例則沒意味着具臺 Web 服務器系統處理約 600 名用戶 目前止我已討論能明確指向站點瓶頸領域情況該何做影響性能領域止您應何做呢答案創建單獨檢視各領域測試腳本首先孤立執行些腳本起執行再比較結看站點領域另領域影響。

軟件環境：從操作系統開始寫，操作系統（Windows、linux）版本，瀏覽器（IE、firefox……）版本，把與被測網站系統有直接使用關係的軟件都寫入軟件環境【所用的軟件測試工具（缺陷管理工具、qtp、loadrunner……截圖軟件等）不能寫入軟件環境，獨立出來單獨寫“測試工具”】，另外，如果電腦裏還有與被測網站無關的軟件也要全部加上，並且註明版本號（比如IE6、IE8、firefox3.0等）。

一般功能測試時對的要求是在乾淨的操作系統上進行，也就是說除了與被測系統有關的軟件以外，不能帶有其他軟件，但如果有的話需要需要記錄下來，以備bug再現時有依可尋。在做網站相容性測試時應在被測電腦上安裝上常用軟件，看是否能與其他軟件相容。

聽您這提問，估計您是沒做過測試吧。

什麼是測試環境呢？大白話講就是可以基本準確的將測試用例執行出來，並且結果是有參考意義的那麼個環境~

這前題是你的測試用例是有效的。那撇掉這個不管的情況下，測試環境就不可能是固定的。

有時候，測試環境可能就是一個系統。P如你這個軟件，什麼都不用管，你只要測能不能裝在XP系統上，那此時，一個完整的XP系統就是測試環境。

有時候，你要測一個網站支援不支援多種瀏覽器。那此時，你的測試環境就是一個安裝了多種瀏覽器的操作系統。

我說的你明白了麼？所謂的搭建測試環境（招聘的老有這要求，會搭建環境），就是你能搭出可供測試用的環境。簡單了說~是操作系統~複雜了說，是裝了特定軟件做了特定設定的操作系統~

要知道基本的測試理論，和一些常用的測試工具：如roadrunner,QTP,winrunner.1.白箱測試和黑箱測試是什麼？什麼是迴歸測試？迴歸測試是指修改了舊代碼後，重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤。

自動迴歸測試將大幅降低系統測試、維護升級等階段的成本。迴歸測試包括兩部分：函數本身的測試、其他代碼的測試。

2.單元測試、集成測試、系統測試的側重點是什麼？單元測試是在軟件開發過程中要進行的最低級別的測試活動，在單元測試活動中，軟件的獨立單元將在與程序的其他部分相隔離的情況下進行測試。集成測試，也叫組裝測試或聯合測試。

在單元測試的基礎上，將所有模組按照設計要求，組裝成爲子系統或系統，進行集成測試。實踐表明，一些模組雖然能夠單獨地工作，但並不能保證連接起來也能正常的工作。

程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實現。系統測試是將經過測試的子系統裝配成一個完整系統來測試。

它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法。3.設計用例的方法、依據有那些？白盒測試：邏輯覆蓋法，主要包括語句覆蓋，判斷覆蓋，條件覆蓋，判斷-條件覆蓋，路徑覆蓋黑盒測試：等價劃分類，邊界值分析，錯誤推測法。

5.集成測試通常都有那些策略？1、在把各個模組連接起來的時候，穿越模組接口的數據是否會丟失；2、各個子功能組合起來，能否達到預期要求的父功能；3、一個模組的功能是否會對另一個模組的功能產生不利的影響；4、全局數據結構是否有問題；5、單個模組的誤差積累起來，是否會放大，從而達到不可接受的程度。7.一個缺陷測試報告的組成缺陷的標題，缺陷的基本資訊，復現缺陷的操作步驟，缺陷的實際結果描述，期望的正確結果描述，註釋文字和截取的缺陷圖象。

8.基於WEB資訊管理系統測試時應考慮的因素有哪些？9.軟件本地化測試比功能測試都有哪些方面需要注意？軟件本地化測試的目的：軟件本地化測試的測試策略：1.本地化軟件要在各種本地化操作系統上安裝並測試。2.源語言軟件安裝在另一臺相同源語言操作系統上，作爲對比測試。

3.重點測試因本地化引起的軟件的功能和軟件介面的錯誤。4.測試本地化軟件的翻譯質量。

5.手工測試和自動測試相結合。11.需求測試注意事項有哪些？一個良好的需求應當具有一下特點：完整性：每一項需求都必須將所要實現的功能描述清楚，以使開發人員獲得設計和實現這些功能所需的所有必要資訊。

正確性：每一項需求都必須準確地陳述其要開發的功能。一致性：一致性是指與其它軟件需求或高層（系統，業務）需求不相矛盾。

可行性：每一項需求都必須是在已知系統和環境的權能和限制範圍內可以實施的。無二義性：對所有需求說明的讀者都只能有一個明確統一的解釋，由於自然語言極易導致二義性，所以儘量把每項需求用簡潔明瞭的用戶性的語言表達出來。

健壯性：需求的說明中是否對可能出現的異常進行了分析，並且對這些異常進行了容錯處理。必要性：“必要性”可以理解爲每項需求都是用來授權你編寫文檔的“根源”。

要使每項需求都能回溯至某項客戶的輸入，如UseCase或別的來源。可測試性：每項需求都能透過設計測試用例或其它的驗證方法來進行測試。

可修改性：每項需求只應在SRS中出現一次。這樣更改時易於保持一致性。

另外，使用目錄表、索引和相互參照列表方法將使軟件需求規格說明書更容易修改。可跟蹤性：應能在每項軟件需求與它的根源和設計元素、原始碼、測試用例之間建立起連結鏈，這種可跟蹤性要求每項需求以一種結構化的，粒度好（fine-grained）的方式編寫並單獨標明，而不是大段大段的敘述。