至于為什么要進行產品說明書的測試，統計資料表明，很多軟件的缺陷都是因為產品功能說明書不夠全面，經常更改造成的;另外，只有詳細的閱讀了產品功能說明書，確認產品需要實現的功能，才能擬定切實可行的測試方案。
其方法，具體地說有以下幾種。
1.參照需求說明，檢查產品功能說明書描述的產品將要實現的功能是否已經完整、準確、一致、合理的描述了產品的功能，并確保這些功能是可測試的。
2.研究產品說明書是否符合現有的軟件設計開發的標準或規范。
3.研究同類軟件，預測產品的最終結果。
可是如果應用到實際的開發流程中，又有著一定的困難。因為很難做到讓軟件測試人員在項目的初期就參與項目，一般要等到軟件的雛形出來后才會讓軟件測試人員著手進行測試。即便是在初期測試人員參與項目，也只是根據產品說明書和設計計劃制定測試計劃。測試人員沒有被賦予責任去檢查產品說明書。
四，經濟的測試。
測試是一項復雜的工作。因此要考慮其效率。經濟的測試有幾個原則。
1. 如果一個case(X)依賴另一個(Y)，如果Y失敗，那么X可以不要測試。
2. 針對一個子集，如果一個輸入導致了失敗，那么剩下的輸入可以不要測試。
3. 針對一個case，如果一個測試子集產生了失敗，那么其他的子集可以不要測試。
由此，聯想到一個實際問題。開發人員一次送測，按流程，應進行一輪全面的測試。但如果在測試初期發現了缺陷，此輪測試是否要繼續?不繼續，則此輪測試不完整，無法產出測試報告。繼續到完全測試，如果發現的缺陷是嚴重的必須解決的缺陷，則后面的測試是不經濟的，因為此缺陷修復后仍要進行全面的測試。
按照測試的原則，發現缺陷要及時地反饋給開發人員，以便及時了解軟件狀態。但在實際操作中，開發人員得到反饋后常常隨即給出一個修復版，然后再一輪測試。造成的情況是，到項目結束，發現多少個缺陷，往往就經過多少輪測試，每一輪測試僅僅是驗證對一個缺陷的修復。
所以我覺得，對于什么時候暫停測試，是否需要暫停，開發人員什么時候送測新的修復版本，應該有一個良好的控制。
五，自動測試
我們是用Rational Robot編寫自動測試腳本進行自動測試。主要用與一些AP的UI測試。由于編寫SQA Basic代價較高，所以應用于稍具復雜度的程序或需多輪回歸測試的項目是比較經濟的，如果是簡單的UI，或不需進行多輪回歸測試的項目，就要比較編寫腳本的投入和實施自動測試的經濟了。
如果多輪回歸測試間程序變化比較多，改寫腳本也是負擔很重的工作。
以上是一點點心得，零散寫下。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
