QA的幾個經典問題（1）

問題一：什麼是「軟件測試」--「QA」？

1。出自(IEEE, 1986; IEEE, 1990).

Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features ofthe software item

就是一個經過分析軟件和需求以前差別，發現bug,對軟件的功能進行評價的過程。

2。軟件測試就是在受控制的條件下對系統或應用程序進行操做並評價操做的結果。

3。軟件測試是爲了發現錯誤而執行程序的過程。

這一種也是大多數文檔和書籍進行的定義，其實和第一個定義沒有什麼區別。

問題二：什麼是「測試案例」?

測試案例是一份文檔，它描述了一個輸入、反應、或者是與其相應的預期的響應，以便來判斷應用軟件的是否正常。測試案例應當包括測試標識、測試案例的名稱、目標、測試條件/設置、輸入數據要求、步驟、以及預期的結果。

問題三：若是時間不夠，沒法進行充分的測試怎麼辦?

使用風險分析，肯定測試的重點。

因爲不多有機會對一個應用軟件進行全部可能的測試 (包括全部可能的事件組合、全部的相關性、或者一切可能出錯的東西)，對大多數軟件開發項目來講，利用風險分析是適當的。這須要判斷技能、常識、感受和經驗。若是有正當理由，也可採用正式的方法。須要考慮下列因素：

ü 對於該項目的用途而言，哪一種功能最重要?

ü 哪一種功能對用戶最明顯?

ü 哪一種功能對安全影響最大?

ü 哪一種功能對用戶最有用?

ü 對客戶來講，該應用軟件的哪一個部分最重要?

ü 在開發過程當中，該應用軟件的哪一個部分能夠最早測試?

ü 哪一部分代碼最複雜，容易致使出現錯誤?

ü 哪一部分的應用程序是在急迫或在驚恐的狀況下開發出來的?

ü 哪一部分程序與過去項目中引發問題的部分相相似/有關?

ü 哪一部分程序與過去項目中須要大量維護的部分相相似/有關?

ü 需求和設計的那些部分不清楚或不容易讀?

ü 開發人員認爲在應用軟件中哪些部分是高風險的?

ü 哪些問題能形成最差的發行?

ü 哪些問題最能引發用戶抱怨?

ü 哪些測試能夠容易地覆蓋多種功能?

ü 哪些測試在覆蓋高風險部分的測試時使用時間最少?

 

問題四：若是需求一直在變化怎麼辦?

 

這是一個常見的使人頭疼的問題。

ü若是可能，儘早與承擔該項目風險的人接觸，以便了解需求會怎樣改變，從而能夠儘早地改變測試計劃和策略。

ü 若是在對應用程序進行初始設計時多考慮一些適應性，那麼之後在發生需求的改變時，就不須要再爲改變作不少事情了。

ü 好的代碼註釋和好的文檔有助於開發人員做出相應的改變。

ü只要有可能，就應使用快速原型 (rapid prototyping)，以幫助用戶確認他們的需求，從而減小變動。

ü在項目的時間表中應當留出餘量，以應付可能出現的變動。

ü儘可能把新的需求歸入應用軟件的「下一版」，而把原始需求做爲「初版」。

ü經過談判，把易於實現的新的變動列入項目，而把難於實現的新需求列入該應用軟件的之後的版本。

ü要確保讓客戶和管理人員瞭解變動對進度表的影響、所帶來的風險、以及因變動所引發的大量資金消耗。

ü在應付改變時，應在爲創建自動測試而做的努力和從新進行測試所作的努力之間取得平衡。

ü在設計自動測試劇本時，試圖使其有一些靈活性。

ü在對應用軟件進行自動測試時，要把注意力集中在看來不大會改變的部分。

ü對變動進行適當的風險分析，以減小回歸測試的要求。

ü在設計測試案例時要有必定的靈活性。作到這一點並不容易，因此要下降測試案例的詳細程度，或者只創建高級的通用型的測試計劃。

ü 少注意詳細的測試計劃和測試案例，要把重點放在專門的測試 (ad hoc testing) 上。