對于軟件測試工程師來講，需要識別的內容非常之多、之具體。除了上篇帖子說的需求之外，測試工作賴以執(zhí)行的測試環(huán)境也是需要重點識別的對象之一。

測試環(huán)境何其重要，在此先梳理一下。測試需求分析的過程，了解并辨別被測軟件，此時其重要性還未體現，因為此時的目標是提取測試點；之后針對每個測試點，測試方法就是下一步要解決的問題，此時需要了解：

1. 已有測試環(huán)境是什么配置？

2.相對于測試方法而言，還需要什么硬件、軟件或設備？

3.已有測試環(huán)境有什么限制？可能通過什么方式破除這種限制？或逼近真實環(huán)境？

到測試用例設計階段，將測試點&確定的測試方法轉換成測試用例，直至測試執(zhí)行階段，測試環(huán)境都直接與該工作本身高度相關，其重要性不言而喻。

那么問題來了，測試工程師應如何識別測試環(huán)境？什么樣的測試環(huán)境是滿足要求的，什么樣的環(huán)境不能滿足呢？此次，我們使用5W2H模型先明確問題：

分析的目標WHY：明確什么樣的測試環(huán)境滿足測試要求，什么樣的環(huán)境不滿足。

分析的對象是WHAT？分析什么才能確定上述問題呢？測試環(huán)境畢竟只是測試環(huán)境，對于測試工作而言，理想狀態(tài)當然是使用真實環(huán)境?，F實情況是，不可能所有的測試都在真實環(huán)境下測試：如車載軟件的測試，如果使用實車測試，有些場景根本無法測試，無法滿足測試要求；另外從資源角度來說也會消耗較多的實車資源，不可能一個測試工程師一臺實車，成本太高；另外對于一些破壞性測試，如果使用實車也會造成實車無法使用，代價太大。在不可能使用真實環(huán)境測試時，我們需要使用模擬環(huán)境測試，如車載軟件測試可以使用HIL臺駕模擬車載控制器，測試軟件的功能和性能?；氐秸}，我們分析的對象就應該是測試環(huán)境與真實環(huán)境之間的差異，以及這種差異對測試造成的影響。

分析時間WHEN：這種分析應該在哪個階段進行，當然是越早越好。如果迭代項目運行中發(fā)現測試環(huán)境的限制，那么可以考慮在下一個迭代開始前就進行這種分析，確認是否需要購置新設備或搭建新環(huán)境；如果不需要大動干戈，那么起碼在測試策劃階段或者測試設計階段執(zhí)行該分析，以明確每項測試內容應該在哪種測試環(huán)境下執(zhí)行。到了執(zhí)行階段，先需要先分析確認，是否所有設備齊全，滿足測試準入條件。

分析地點WHERE：這個具體執(zhí)行人員確定，再環(huán)境現場？或者對環(huán)境很熟悉的情況下，anywhere。

分析人員WHO：這個根據具體情況而定，如果明確識別到環(huán)境的限制，且項目組決定執(zhí)行優(yōu)化，項目管理人員應繼續(xù)跟蹤該事項；否則，該事項應由測試工程師執(zhí)行。

如何分析HOW：一般的考慮是，從硬件、軟件、數據三方面全面分析測試環(huán)境與真實的差異，進而確定測試環(huán)境有效性。

分析到什么程度HOW MUCH：這個需要結合項目具體情況，如果沒有差異當然最好，如果有差異，應該增加何種測試環(huán)境滿足測試需求。