關(guān)于軟件測試的一點(diǎn)體會(huì ) 軟件測試
有一些心得，零零散散，記錄下來(lái)，與大家交流。
一，軟件測試員的目標是盡可能早地找出軟件缺陷，并確保其得以關(guān)閉。仔細思考后，我覺(jué)得此目標包含三個(gè)含義。
1.軟件測試員的基本目標是發(fā)現軟件缺陷。
這似乎是個(gè)不言而喻的事實(shí)，但有必要再次強調。因為有時(shí)開(kāi)發(fā)小組要測試員只是為了證實(shí)軟件可以運行，而不是找缺陷。在這種情況下，測試人員也就缺乏不懈努力發(fā)現缺陷的探索精神和熱情。所以做好測試的首要條件是明確軟件測試員的基本目標是發(fā)現軟件缺陷。
2.軟件測試員追求的是盡可能早地找出軟件缺陷。
因為軟件的修復費用，隨著(zhù)時(shí)間的推移，將數十倍的增長(cháng)，所以軟件測試員應盡可能早地找出軟件缺陷。對于大型的軟件，在軟件開(kāi)發(fā)的同時(shí)，就應該有緊隨其后的測試，如果等到產(chǎn)品已經(jīng)開(kāi)發(fā)完畢才開(kāi)始測試，非常有可能引起大量耗時(shí)費力的返工。而如何盡可能早的找出缺陷?理論上有一些測試方法：靜態(tài)黑盒測試、動(dòng)態(tài)黑盒測試、靜態(tài)白盒測試、動(dòng)態(tài)白盒測試;配置測試、兼容性測試、易用性測試……，怎樣才能有效的用這些方法盡早的發(fā)現軟件缺陷，需要在工作實(shí)踐中不斷的摸索、總結，不斷的提高測試能力。針對公司的情況，如果軟件的規模不是很大，開(kāi)發(fā)中的測試工作可能由開(kāi)發(fā)人員完成比較合適。
3.軟件測試人員必需確保找出的軟件缺陷得以關(guān)閉。
并不是每個(gè)軟件缺陷都有必要修復的�？赡苁怯捎跊](méi)有足夠的時(shí)間、不算作真正的軟件缺陷、修復的風(fēng)險太大等原因，產(chǎn)品開(kāi)發(fā)小組決定對一些軟件缺陷不作修復。但是，測試人員必需確保找出的軟件缺陷得以關(guān)閉，也就是說(shuō)一旦登記了軟件缺陷，就要跟蹤其生命周期，監視其狀態(tài)，提供必要的信息確保其得到修復和關(guān)閉。
二，關(guān)于Testware。
有個(gè)很簡(jiǎn)潔明了的定義，software development engineers produce software, software test engineers produce testware. 那么testware包含哪些內容呢?test strategy, test plan, test specifications, test procedures, test cases, test reports, test data, test
scripts,defects data等等。同軟件一樣，testware也需要很好地維護。例如，由于修復缺陷改變了軟件的接口，那么case和自動(dòng)測試腳本script都要做相應的修改。
三，對產(chǎn)品說(shuō)明書(shū)的測試。
軟件的產(chǎn)品功能說(shuō)明書(shū)對產(chǎn)品最終需要實(shí)現的功能作了描述。這些功能是最終確定的需要滿(mǎn)足的客戶(hù)需求，也包括軟件必須具備的能力。在規范的軟件開(kāi)發(fā)流程中，產(chǎn)品功能說(shuō)明書(shū)應在確定用戶(hù)需求后，進(jìn)行系統概要設計前確定。
至于為什么要進(jìn)行產(chǎn)品說(shuō)明書(shū)的測試，統計資料表明，很多軟件的缺陷都是因為產(chǎn)品功能說(shuō)明書(shū)不夠全面，經(jīng)常更改造成的;另外，只有詳細的閱讀了產(chǎn)品功能說(shuō)明書(shū)，確認產(chǎn)品需要實(shí)現的功能，才能擬定切實(shí)可行的測試方案。
其方法，具體地說(shuō)有以下幾種。
1.參照需求說(shuō)明，檢查產(chǎn)品功能說(shuō)明書(shū)描述的產(chǎn)品將要實(shí)現的功能是否已經(jīng)完整、準確、一致、合理的描述了產(chǎn)品的功能，并確保這些功能是可測試的。
2.研究產(chǎn)品說(shuō)明書(shū)是否符合現有的軟件設計開(kāi)發(fā)的標準或規范。
3.研究同類(lèi)軟件，預測產(chǎn)品的最終結果。
可是如果應用到實(shí)際的開(kāi)發(fā)流程中，又有著(zhù)一定的困難。因為很難做到讓軟件測試人員在項目的初期就參與項目，一般要等到軟件的雛形出來(lái)后才會(huì )讓軟件測試人員著(zhù)手進(jìn)行測試。即便是在初期測試人員參與項目，也只是根據產(chǎn)品說(shuō)明書(shū)和設計計劃制定測試計劃。測試人員沒(méi)有被賦予責任去檢查產(chǎn)品說(shuō)明書(shū)。
四，經(jīng)濟的測試。
測試是一項復雜的工作。因此要考慮其效率。經(jīng)濟的測試有幾個(gè)原則。
1. 如果一個(gè)case(X)依賴(lài)另一個(gè)(Y)，如果Y失敗，那么X可以不要測試。
2. 針對一個(gè)子集，如果一個(gè)輸入導致了失敗，那么剩下的輸入可以不要測試。
3. 針對一個(gè)case，如果一個(gè)測試子集產(chǎn)生了失敗，那么其他的子集可以不要測試。
由此，聯(lián)想到一個(gè)實(shí)際問(wèn)題。開(kāi)發(fā)人員一次送測，按流程，應進(jìn)行一輪全面的測試。但如果在測試初期發(fā)現了缺陷，此輪測試是否要繼續?不繼續，則此輪測試不完整，無(wú)法產(chǎn)出測試報告。繼續到完全測試，如果發(fā)現的缺陷是嚴重的必須解決的缺陷，則后面的測試是不經(jīng)濟的，因為此缺陷修復后仍要進(jìn)行全面的測試。
按照測試的原則，發(fā)現缺陷要及時(shí)地反饋給開(kāi)發(fā)人員，以便及時(shí)了解軟件狀態(tài)。但在實(shí)際操作中，開(kāi)發(fā)人員得到反饋后常常隨即給出一個(gè)修復版，然后再一輪測試。造成的情況是，到項目結束，發(fā)現多少個(gè)缺陷，往往就經(jīng)過(guò)多少輪測試，每一輪測試僅僅是驗證對一個(gè)缺陷的修復。
所以我覺(jué)得，對于什么時(shí)候暫停測試，是否需要暫停，開(kāi)發(fā)人員什么時(shí)候送測新的修復版本，應該有一個(gè)良好的控制。
五，自動(dòng)測試
我們是用Rational Robot編寫(xiě)自動(dòng)測試腳本進(jìn)行自動(dòng)測試。主要用與一些AP的UI測試。由于編寫(xiě)SQA Basic代價(jià)較高，所以應用于稍具復雜度的程序或需多輪回歸測試的項目是比較經(jīng)濟的，如果是簡(jiǎn)單的UI，或不需進(jìn)行多輪回歸測試的項目，就要比較編寫(xiě)腳本的投入和實(shí)施自動(dòng)測試的經(jīng)濟了。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
