一、總述
作為軟件測試者都知道，軟件測試可分為黑盒測試、白盒測試以及介于兩者之間的灰盒測試。(這些對軟件測試者而言并不陌生的概念性的東西在此就不詳細介紹了。)在對佳能傳真機的測試中佳能QA進行的都是不了解程序代碼而直接進行數據輸入求證輸出結果的黑盒測試。而黑盒測試與白盒測試的一個最大的不同在于黑盒測試比較隨機、靈活，很多問題的測試、發現都是靠一些經驗、感覺。
佳能傳真機Model-4是一款面向全球的傳真機型，其軟件相對而言也很復雜，因此在軟件的測試中也先后出現了很多bug，在對這些bug分析總結的基礎上結合對先前的modelA3的測試總結談一下自己對測試的一點心得體會。
二、測試思路
我們知道很多軟件都涉及到內存(memory)和用戶界面(UI)兩大部分，佳能傳真機軟件也都包括這兩部分，而這兩部分的好壞將直接影響的軟件的功能、性能和用戶的使用，因此這兩部分的測試是一款軟件產品測試中相當重要的一部分。下面首先從這兩部分的測試談起。
1.用戶界面測試(UI test)
M4的用戶界面比較簡單，而modelA3用戶界面相對而言就要復雜得多。在這里談到的用戶界面的測試體會很多都是基于A3的測試心得。
產品軟件界面猶如人的面孔，界面的好壞決定用戶對軟件產品的第一印象，好的截面能給人一種賞心悅目的感受，好的界面也能起到導向作用，同時界面的好壞將直接影響到用戶的操作、使用等。
界面測試時要注意到文字、符號(圖像、logo標簽等)顯示是否正確、合理。如果一款軟件連最基本的文字顯示都不正確，可想用戶看到后會有什么樣的感受，同時在符號(圖像、logo標簽等)如果不能正確合理的顯示將會影響到用戶的操作使用等。比如，在A3的文字顯示上必須注意好文字顯示的是否正確，其大小寫是否混淆(日語中的大小寫有著嚴格的區分，大小寫代表著不同的單詞)等;而在一些圖標信息上也是必須嚴格做到該顯示的就要顯示出來，不該顯示的就不要顯示，比如A3中的音量圖標、色帶圖標還有一些multi-key(分別代表著傳真發送、傳真接受、精度設置、拷貝的F1、F2、F3、F4圖標)，如果不能正確合理的顯示將會導致用戶的誤解、操作錯誤等�？傊�，在文字、符號(圖像、logo標簽等一些軟件界面顯示信息)上要做到正確、合理。
事實上，想網頁設計、電腦應用軟件等一下在電腦上運行的軟件界面測試不僅要注意到易用、合理、協調美觀還要注意到一些規范性測試等。在此不便具體介紹，只是為了強調說明用戶界面測試的重要性。
2.內存測試(memory test)
可以說每一款軟件中都要涉及到內存管理，而一款軟件的內存處理的好壞將直接影響到軟件功能能否正常實現、運行中性能狀態是否良好等。應該說在ModelA3和Model4的測試中有很大一部分都問題都有內存方面，而在這方面的測試更是花費了大量時間。下面結合實例來說明一下內存測試的思路、方法。
在A3的測試中，舉兩個關于和電話記錄有關的問題：1、A3電話薄最大存儲容量為100條，如果注冊滿100條后再進行注冊101條電話號碼時，最早注冊的那條號碼將被覆蓋掉;如果用戶刪除第8條以后的任意一條號碼，則會引起內存電話記錄混亂、同時也影響到來電顯示問題;2、A3的來電歷史最大記錄為30條，當記錄滿30條時，如果從中隨意刪除一條記錄，然后再來電，會出現某些來電記錄被最新來電覆蓋的問題，即之前的來電記錄有和最新的來電記錄一致的現象。
在M4的測試中也有很多涉及到內存的問題出現，比如小數據量多頁傳真接收打印時，會出現數據丟失顯現。
內存管理是軟件中很容易出問題的部分，我們想將這部分這好也是比較難，但我們可以從以下幾個方面來把握：一、內存測試時，對內存進行增加、刪除來改變內存記錄看其會不會影響到其他的內存記錄;二、注意內存存儲時，對其進行各種斷電或其他中斷操作，看這些操作會不會影響到內存記錄;三、讓內存記錄到臨界狀態，在存儲極限狀態對其進行一些操作，看在極限狀態下會不會出現一些錯誤或混亂現象。
總之，內存管理是軟件中一項非常重要的部分，內存混亂、出錯將影響到軟件的功能和性能，今后，無論在哪方面的軟件測試中都要注意!
==================================================================
以上兩點主要是從測試對象出現談起的，主要說的是測試層面問題，下面從測試思路上介紹一些常用的且容易發現問題的測試方法.
==================================================================
3.中斷測試
對用戶而言，在產品的使用過程中不可避免的會出現一些無法預料到的中斷，因此一款軟件的設計就要考慮到這些中斷的影響，而我們在測試過程中也就必須對軟件進行各種中斷測試。中斷測試是測試中一種常用到的測試方法，中斷測試是保證軟件功能和性能的一個重要手段，在實際測試中中斷測試都很容易找到軟件中的一些問題。
我們在進行中斷測試時，要注意到對中斷時間點的把握，特別是在一些關鍵點上很容易出問題。在對M4進行拷貝和各種打印測試時，都大量運用了中斷測試，也發現了很多問題，下面舉例來說明一下中斷測試：
Eg1.傳真在邊收邊打時，以下是一些中斷點：1、傳真協議建立的過程中;2、傳真剛開始啟動接收(到內存)時;3、傳真接收過程中;4、傳真接收快要結束時;5傳真接收完畢剛要啟動打印時;6、傳真吸紙(pre-feed)時;7、傳真吸紙中;8、傳真喜紙結束準備啟動打印時;9、傳真打印過程中;10、傳真剛剛打印結束退紙時。通過對以上中斷點的測試我們有發現在傳真剛打印打印時可以中斷掉，而在傳真打印過程中不能手動中斷打印，而在打印快結束的時候又可以手動進行中斷。
上面的例子說的是對任務本身進行的中斷，而在實際測試中，我們還要注意到對一個任務由其他任務導致的中斷測試。比如，我們在進行注冊的時候，突然來個電話等。這些也都很容易導致一些問題的出現。
我們在軟件測試時不但要進行一些合乎邏輯的功能性測試，而且更要進行一些破壞性的中斷測試�？梢哉f，不會對軟件實施一些破壞性活動的中斷測試的測試者絕不是一名好的測試者!
順便再提一下非法測試，一般而言，我們的軟件都是按照程序員設計的流程來運行，但在軟件運行的過程中難免會出現一些誤操，這些非法的不符合邏輯的操作也是我們在測試中必須注意把握的，我們不但要保證軟件在正常情況下能夠正常運行，而且還要保證使得軟件在一些非法的不符合邏輯的操作面前不會出問題，這也就是我們平時所說的要保證軟件的強壯性。
4.多任務測試
多任務測試也是軟件測試過程中必須考慮到的一個方面，比如說我們在報告打印的過程中，突然來電。這時根據規格要求，傳真機不但要能正常接聽來電，打印動作也不被來電影響，類似于這類的測試很多，而這類問題的測試也是一些bug多發情況。
在多任務測試時，很容易出現一些死機、某些功能無法正常實現等情形。我們在進行多任務測試時不但要把握這些功能能否正常實現還要看有沒有其他一些問題出現。比如，在打印報告的時候來電，在CALL ID打開的狀態看來電顯示是否正確，在通話結束的時候掛機，看LCD的顯示是否又恢復到打印狀態時的顯示等。
在進行多任務測試時，我們還要結合一些中斷測試等來進行測試，以防止出現一些異常情況。
5.臨界測試
我們知道，日本是一個地震多發的國家，每年都會有一些或大或小的地震去騷擾一下，為此，日本人曾吃了不少苦。為什么日本會有那么多的地震?原因很簡單，從地理上而言它處于亞歐版塊和太平洋版塊的臨界位置，不穩定!所以也就容易出現一些不必要的問題。
以上只是形象的說明一下臨界位置是一個比較敏感地帶，表現的不穩定性，容易出問題。我們軟件也是如此。因此，對軟件進行臨界測試時是一個非常重要的方面!
我們在對M4進行臨界測試時，表現最為重要的還是內存方面，往往內存在達到其存儲容量的臨界點時會有很多問題發生，如數據丟失等。
臨界測試還有如對電話存儲極限時的測試：當來電歷史里的記錄條數處于最大狀態或者電話薄中登錄的號碼數目最大時，我們對其進行一些合法的、非法的、正常的以及非正常的操作來檢驗軟件是否出現一些以外情況等。
事實上，進行臨界測試時還要更多結合一些中斷測試，比如之前在傳真剛發送完成顯示“TRANSMITTING OK”時，我們按
三、其他問題
1.概率性問題
應該說概率性問題是對任何一個測試者都感到頭疼的問題，尤其是那些概率性偏低的問題，很難重現。為此，我們在佳能軟件測試時就飽受這方面的折磨。
一個最為難忘的例子就是對A3進行“CLEAR ALL”操作時出現“MEMORY ERR”問題，這個問題的概率很低，出現的情況很隨機，毫無規律性而言，為測這個問題幾個人前后做了不下3000次的操作。好在問題最后得以解決——原來是硬件FLASH出現的問題。
概率性問題是一個讓人頭疼的問題，但恰恰是這種問題的存在影響了我們產品的性能，試想，軟件正在工作的過程中突然出現了死機或者重起的現象將會讓用戶有著怎樣的感受!對于一個小的產平還好，如果大到航空航天、金融系統，如果在運行中出現了這樣的問題，將會是怎樣一個后果呢?災難!
在此，主要是想說明我們在測試時，必須把一些概率性的問題重視起來，對于一些比較嚴重的概率性的問題，我們的原則應該是已經出現，就要查出，最終解決!在這方面，佳能做的就十分不錯，非常值得我們學習!
2.測試流程
對于測試流程，大家基本上都是大同小異，在此就不再介紹了。我們所要注意的一點就是在測試流程的執行上一定要嚴格，尤其是最后發行軟件版本前的確認測試，一定要將每一個可能出現問題的地方都要測試到位。
3.測試文檔
如何編寫一個好的測試文檔(precheck list)對于測試而言是很重要的一個環節，測試文檔是一個測試者測試思路、方法的重要反映。一個好的測試文檔所羅列的測試用例首先要全面，要能涉及到軟件的各個功能部分，不能有所遺漏。如果測試出現空白，將是一件十分可怕的事情。
有資料反映，微軟在寫windows操作系統的測試文檔時就寫下了10萬個測試用例。在測試文檔的編寫方面，一定要做到全面、詳盡，而且最好是經驗豐富的測試人員來編寫。
4.測試管理
測試管理應該說是一門很值得研究的學問，它涉及到測試執行、bug的發現提出、分析評估、分配解決、確認解決情況等很多方面，時間關系，在此不能，也很難一下子把它說的那么到位。下面僅提一下bug管理工具。
應該說現在的bug管理工具不是太多，而一個好的bug管理工具對軟件設計而言又非常重要，一個好的軟件管理工具能夠幫幫助人們有效的管理軟件中出現的問題，提高工作效率。在測試管理管理上，canon使用的是lotus管理工具，這個管理工具相對而言比較好一些，值得我們在今后的工作中借鑒使用。
四、小結
一個好的測試者決不限于對一些基本功能的測試驗證上，不僅是為了證明某些功能可以實現，更主要的是為了證明某些功能不能實現而進行的一些“破壞性”測試，這樣的測試也是為了保證相應功能能夠正常穩定的實現�；谶@個指導思想我們在佳能傳真機的測試時進行了大量的中斷測試、掉電測試、臨界測試以及其他一些異常操作測試。當然，不管如何測試，軟件中的bug都無法全部發現解決，我們所做的就是按照軟件測試中的good-enough原則，盡可能多的測試出用戶在使用中可能碰到的bug，確保軟件質量。
從宏觀而言，軟件測試現在還處于嬰幼兒階段，還很不成熟，在國際上也沒有一個統一的測試標準，我們要做的就是不斷地學習、積累、探索。
文章來源于領測軟件測試網 http://www.k11sc111.com/
