對軟體測試工作的反思

我這個人做完一件事情喜歡反思和總結，這個習慣一直保留着。在測試部做了兩個月，雖然我對測試還是門外漢，隻做了一些具體工作，但忍不住把自己的想法寫了個系統文章，其實提意見我的看法是上司一般不反感，隻要你的意見系統，有建設性，不針對個人攻擊就好。

　　下面就是我當時寫的對測試工作的反思，有些是參考了一些資料，結合自己總結寫的。

對軟體測試工作的反思

　　測試人員的配置：測試人員必須包括三類人，專業測試人員，熟練測試人員和對軟體完全不熟悉的新人。專業測試人員主要負責測試規劃和測試大綱，極限測試環境設計，熟練測試人員主要負責按規定完成大綱測試，屬收斂性測試，新人主要負責易用性和界面合理性測試，屬發散性測試，發現的各類問題由專業測試人員分析并給出解決對策。

　　測試檔案的準備：提前準備好軟體測試需要的圖、工藝檔案，offices，txt，其它cad設計檔案測試标準檔案，而不是臨時去找

　　測試軟體的準備：應該提供不同的作業系統和資料庫平台測試環境，必要的話提供多台測試機器，減少人工浪費在安裝環境上的時間。

　　測試機器的準備：應給測試人員配置相對好的機器，以提高測試速度和效率，同時一定要配置相對差的機器，模拟在使用者現場極端運作環境和速度。

　　業務測試的準備：（針對當時軟體測試主要是功能測試的情況）應該設計大量的業務測試流程，流程可以從開發，市場，實施部門配合，給予解決。

　　測試階段的劃分：應該分開發測試（非常反感開發不懂操作，也不自行測試就送出測試人員驗證的模式），功能測試，極限測試，bug測試（主要是測試曆史環境下有記錄的bug），現場測試（主要是易用性和測試業務流程）

　　對測試大綱的意見：

　　1、測試内容不全面，缺少測試檔案樣例，測試軟體版本号

　　a）很多軟體存在的功能測試大綱沒有涉及，我自己把隻要能夠用的功能都測試了一遍，超出了規定測試大綱的内容，發現了很多新錯誤，當時公司測試水準也确實有限，所謂軟體測試就是兩個臨時員工負責。

　　b）軟體功能之間組合連續測試不完善，很多功能單獨是好的，但如何把管理軟體功能串合起來用的測試流程不清晰，需要測試人員自己發揮

　　2、極端環境測試得不夠

　　對空資料，大資料，大量網絡并發等環境下測試很不夠，往往這個時候能測試出很多問題，例如軟體運作效率

　　3、對誤操作或非法操作給系統帶來的影響測試大綱無展現

　　測試大綱都是要求你如何如何操作，應得到何種結果，但問題是使用者不一定會這樣操作，但我這裡随意操作常常造成當機，這也是我對測試大綱很不滿意的，軟體應該做到即使是使用者誤作業系統有提示或者沒反應，而不是當機，更不是要求實施人員去教育訓練正确的操作。

　　4、測試動作量化不夠

　　例如同一功能測試次數，測試頻率，測試速度都應有規定，例如某一功能測試100次，可能才出現一次bug，如果隻測試10次可能就是ok的，或者連續使用10次就會出現bug，但單獨使用沒問題，這些應該也展現的測試大綱，而不是讓測試人員自己去測。

　　5、測試中對開發人員的開發功能邏輯了解不夠，無法自覺測試潛在的功能缺失和沖突或幹擾（後來我才曉得這叫白箱測試）

　　6、對軟體的宜人性，友好性，windows下程式風格一緻性，簡潔性沒有任何評估

　　7、沒有以使用者層面對設計的功能和動作進行挑剔。

　　8、缺乏軟體測試品質保障體系（後來開目花了大力氣建設了測試體系，通過cmm3級評估）

　　9、沒有機關時間内任意測試過程中當機紀錄，隻測功能的實作性，沒有系統穩定性名額，實時性，同步性等效率量化名額

　　10、沒有參照軟體的對比測試

　　11、沒有前期積累的測試文獻

　　12、測試工作不應該僅僅成為開發的完善工具，還要承擔一部分探索開發方向的作用，甚至一定程度上和開發交融（這個觀點我現在不支援，要求太高了，主要是當時我對自己測試太有信心了）

　　測試目的：

　　1）檢查出軟體中的功能設計不足或bug以保證能滿足使用者正常使用

　　2）在說明書中明确一些常見錯誤操作以防止使用者誤操作或給出解決方法

　　3）對一些一時難以解決的難點，導緻的問題給使用者一個解釋或變通的方法

　　根本目标：

　　保證開目軟體的易學易用穩定的優勢，以優質産品占領市場，赢得口碑。