TWI594262B

TWI594262B - 記憶體模組的測試方法

Info

Publication number: TWI594262B
Application number: TW104141994A
Authority: TW
Inventors: 林大華; 陳騰湖
Original assignee: 英業達股份有限公司
Priority date: 2015-12-14
Filing date: 2015-12-14
Publication date: 2017-08-01
Also published as: TW201721643A

Description

記憶體模組的測試方法

本發明描述了一種記憶體模組的測試方法，尤指一種使用單位元錯誤型樣(Single-Bit Error Pattern，SBE Pattern)以及多位元錯誤型樣(Multi-Bit Error Pattern，MBE Pattern)測試記憶體模組的方法。

隨著科技日新月異，各種記憶體也以不同形式應用於日常生活中，以使各種電子設備具備更多功能和操作性。例如個人電腦(PC)內常用的隨機存取記憶體(Random Access Memory，RAM)，具備隨時讀寫及高速度的特性，故常被做為作業系統或其他正在執行中的程式的臨時資料之儲存媒介。又可細分為，動態隨機存取記憶體(Dynamic Random Access Memory，DRAM)以及靜態隨機存取記憶體(Static Random Access Memory，SRAM)。動態隨機存取記憶體其優勢在於結構簡單，每一個位元的資料都只需一個電容跟一個電晶體來處理，故DRAM擁有非常高的密度及容量，且成本較低的優點。靜態隨機存取記憶體其特性為只要保持通電，裡面儲存的資料就可以恆常保持，且不需要如DRAM一樣要做週期性的更新。然而，因記憶體為利用電容充放電的機制儲存資料，因此視為消耗品。當記憶體內部元件發生異常時，記憶體將無法再存儲資料，甚至會導致輸出資料的異常。因此，定期測試記憶體的效能以及判斷其是否能正常運作已成為維護電子系統之可靠度的重要手段。

現有的記憶體測試方法需要利用非常昂貴的外接設備，在主機板上連接一個測試連接端子，並需要利用手動的方式一個一個去測試記憶體，例如手動測試每個雙線記憶體模組(Dual In-line Memory Module，DIMM)的接腳。此種手動測試的方式將非常耗時耗力，且常常因人為疏失而無法完整的分析檢測結果，甚至導致檢測結果不精準。

本發明一實施例提出一種記憶體模組的測試方法。記憶體模組的測試方法包含用戶端機台與測試機台建立連結，驗證用戶端機台與測試機台間之連結的合法性，產生錯誤型樣至測試機台之記憶體模組中，檢查記憶體模組的錯誤狀態，及依據記憶體模組的錯誤狀態，用戶端機台產生測試分析資料。

為讓本發明更顯而易懂，下文依本發明之記憶體模組的測試方法及其系統，特舉實施例配合所附圖式詳細說明，但所提供之實施例並非用以限制本發明所涵蓋的範圍。

第1圖係為本發明記憶體模組的測試系統100之實施例的架構圖。如第1圖所示，測試系統100包含用戶端機台(Client Terminal Device)10以及測試機台(System Under Test Device)11。用戶端機台10可為任何具備程式編譯能力的裝置，例如工作平台、伺服器、個人電腦、平板電腦等裝置。測試機台11可為乘載測試裝置的任何硬體。在本實施例中，測試機台11乘載著複數個記憶體模組12，例如複數個雙線記憶體模組(Dual In-line Memory Module，DIMM)。用戶端機台10與測試機台11係以無線或有線的方式連結。用戶端機台10具有執行記憶體模組12測試所用之測試軟體13的能力。而測試軟體13中具有測試軟體工具14。舉例來說，測試軟體13可使用Intel ^□開發的Rastool測試工具為核心。在測試系統100中，用戶端機台10會根據測試機台11中記憶體模組12的狀態(例如錯誤狀態)，而產生測試分析資料或是回報資料(Summary Report)。而本發明之測試系統100對記憶體模組12進行測試的流程將描述於後文。

第2圖係為第1圖實施例之記憶體模組12的測試方法之流程圖。如第2圖所示，本發明之記憶體模組12的測試方法之流程包含但不限定於步驟S201至步驟S205，如下所示： <TABLE border="1" borderColor="#000000" width="_0002"><TBODY><tr><td> 步驟S201： </td><td> 用戶端機台10與測試機台11建立連結； </td></tr><tr><td> 步驟S202： </td><td> 驗證用戶端機台10與測試機台11連結的合法性； </td></tr><tr><td> 步驟S203： </td><td> 產生錯誤型樣(Error Pattern)於測試機台11之記憶體模組12中； </td></tr><tr><td> 步驟S204： </td><td> 檢查記憶體模組12的錯誤狀態； </td></tr><tr><td> 步驟S205： </td><td> 依據記憶體模組12的錯誤狀態，用戶端機台10產生測試分析資料。 </td></tr></TBODY></TABLE>

為了讓第2圖之測試流程與後文所述之詳細的測試方法更容易了解，本文將上述的步驟S201至步驟S205歸類為三個階段。如第2圖所示，第一階段I包含了步驟S201以及步驟S202。而第一階段I的目的在於將用戶端機台10與測試機台11確實建立合法且專用的連結。第二階段II包含了步驟S203以及步驟S204。而第二階段II的目的在於將不同的錯誤型樣(Error Pattern)注入記憶體模組12中，並觀察記憶體模組12接受到這些錯誤型樣後會有那些反應及錯誤狀態。第三階段III包含了步驟S205，而第三階段III的目的在於依據觀察記憶體模組12的錯誤狀態後(可能為記憶體模組12對應的作業系統當機或是記憶體模組12執行自我回復功能，將於後文詳述)，於用戶端機台10產生測試分析資料(或是測試結論報告，Summary Report)。如此，測試人員將可輕易由用戶端機台10獲得記憶體模組12的檢測結果。為了描述更為精準，下文將針對第一階段I內部的詳細流程，以及在第二階段II考慮兩種錯誤型樣(例如多位元錯誤形樣以及單位元錯誤型樣)的使用做詳細說明。並且，在第二階段II使用的兩種錯誤型態之下，其所對應的第三階段III之詳細流程亦會描述於後文。

第3圖係為第2圖之記憶體模組12的測試方法之第一階段I的流程圖。如上述，第一階段I的目的在於將用戶端機台10與測試機台11確實建立合法且專用的連結。第3圖的流程包含但不限定於步驟S301至步驟S305，如下： <TABLE border="1" borderColor="#000000" width="_0003"><TBODY><tr><td> 步驟S301： </td><td> 開始； </td></tr><tr><td> 步驟S302： </td><td> 用戶端機台10與測試機台11建立連結； </td></tr><tr><td> 步驟S303： </td><td> 檢查連結建立是否成功? 若成功，進入步驟S304，若不成功，返回步驟S302； </td></tr><tr><td> 步驟S304： </td><td> 傳送連結資料(SCP)至用戶端機台10； </td></tr><tr><td> 步驟S305： </td><td> 檢查匯入的連結資料(SCP)是否合法? 若是，則進入步驟S401(於第4圖將描述)，若否，則返回步驟S304。 </td></tr></TBODY></TABLE>

第3圖的步驟S301至步驟S305說明如下。首先，測試系統100於步驟S301啟動檢測，接下來，用戶端機台10與測試機台(System Under Test Device)11於步驟S302建立連結。用戶端機台10將會於步驟S303檢查連結是否成功，當連結建立失敗時，會返回步驟S302重新建立連結。反之，若連結建立成功，則進入步驟S304。在步驟S304中，測試機台11會複製一份連結資料(SCP)，並傳至用戶端機台10。用戶端機台10會於步驟S305檢查此連結資料(SCP)的合法性或完整性，並判斷測試機台11是否真的透過連結將完整的連結資料(SCP)傳送。要是連結資料(SCP)的傳送不完整或不合法，測試機台11將會被要求重新傳送連結資料(SCP)，直到認證通過為止。這裡所指的合法性可為任何的完整度指標，例如利用循環冗餘校驗 (Cyclic redundancy check，CRC)檢測連結資料(SCP)是否是正確的，或直接觀察傳送封包內容判斷連結資料(SCP)是否存在等等。當連結資料(SCP)已被接收且認證通過，則進入步驟S401(將於第4圖說明)。換言之，步驟S302及步驟S303係為第2圖中步驟S201的子步驟，而步驟S304及步驟S305係為第2圖中步驟S202的子步驟。藉由透過步驟S301至步驟S305(第一階段I)，用戶端機台10與測試機台11可建立合法且專用的連結。接下來，測試系統100將會進行第二階段II，也就是記憶體模組12測試的程序，詳述於下。

在本發明中，記憶體模組12測試的程序(第二階段II)將考慮兩種方式來進行，一種為利用多位元錯誤型樣(MBE Pattern)進行測試，一種為利用單位元錯誤型樣(SBE Pattern)進行測試，下文將針對這兩種測是手段做詳細說明。

第4圖係為記憶體模組12的測試方法，使用多位元錯誤型樣之第二階段II的流程圖。當用戶端機台10與測試機台11利用第3圖的流程建立合法且專用的連結後，測試系統100即開始執行記憶體模組12的測試程序。而記憶體模組12的測試程序包含但不限定於以下步驟： <TABLE border="1" borderColor="#000000" width="_0004"><TBODY><tr><td> 步驟S401： </td><td> 檢測迴圈啟動； </td></tr><tr><td> 步驟S402： </td><td> 偵測未被檢測的記憶體模組12； </td></tr><tr><td> 步驟S403： </td><td> 注入多位元錯誤型樣(MBE Pattern)至未被檢測的記憶體模組12； </td></tr><tr><td> 步驟S404： </td><td> 檢查記憶體模組12對應的作業系統是否失敗(System Hang Up)? 若失敗，則返回步驟S403，若成功，進入步驟S405； </td></tr><tr><td> 步驟S405： </td><td> 重新啟動測試機台11； </td></tr></TBODY></TABLE>

第4圖的步驟S401至步驟S405說明如下。當用戶端機台10與測試機台11利用第3圖中的步驟S301至步驟S305(第一階段I)可建立合法且專用的連結後，用戶端機台10上的測試軟體13，會利用Intel ^□開發的Rastool測試工具，並透過測試機台11，於步驟S401啟動檢測迴圈。這邊所指的檢測迴圈為一種循序式的處理流程，可對任何單位的記憶體模組12循序啟動測試程序。例如將記憶體模組12量化為以DIMM為單位或是以Bank為單位，再循序進行測試。在步驟S402中，未被檢測的記憶體模組12將會被測試軟體13偵測出來。之後，於步驟S403中，這些未被檢測的記憶體模組12將透過測試機台11逐一注入多位元錯誤型樣。應當理解的是，正常的記憶體模組12在被注入多位元(至少2位元)的錯誤型樣時，其支持的作業系統最後必然失敗(俗稱，當機，System Hang Up)。然而，在注入多位元的錯誤型樣至記憶體模組12的當下，其支持的作業系統不一定會於第一時間失敗，可能會因為系統忙碌(System Busy)而延遲了系統失敗的時間。因此，在步驟S404中，測試軟體13會檢查記憶體模組12對應的作業系統是否失敗，若系統失敗，則進入步驟S405，若系統當下並未失敗(可能為前述的延遲原因)，則返回步驟S403。當作業系統失敗後，依據步驟S405，測試機台11將會被重新啟動，並進入步驟S501(將於第5圖中描述)。換言之，步驟S401及步驟S402為步驟S403的前置步驟，步驟S403係為第2圖中對應步驟S203，而步驟S404及步驟S405係為第2圖中步驟S204的子步驟。藉由透過步驟S401至步驟S405(第二階段II)，錯誤型樣(Error Pattern)將會被注入至記憶體模組12(未被檢測的記憶體模組)中，並進一步觀察記憶體模組12接受到這些錯誤型樣後會有那些反應及錯誤狀態(例如作業系統失敗)。而在執行步驟S401至步驟S405之後，測試系統100將會進入第三階段III，也就是產生錯誤及分析資料的階段，詳述於下。

第5圖係為記憶體模組12的測試方法，使用多位元錯誤型樣之第三階段III的流程圖。第5圖的流程包含但不限定於步驟S501至步驟S509，如下： <TABLE border="1" borderColor="#000000" width="_0005"><TBODY><tr><td> 步驟S501： </td><td> 檢查測試機台11的作業系統(OS)狀態，若作業系統被成功啟動且已待命，則進入步驟S503，若作業系統失敗，則進入步驟S502； </td></tr><tr><td> 步驟S502： </td><td> 記錄錯誤資料(Error Log)； </td></tr><tr><td> 步驟S503： </td><td> 檢查遠端伺服器回報資料(BMC)的狀態，若回報資料正常，則進入步驟S505，若回報資料異常，則進入步驟S504； </td></tr><tr><td> 步驟S504： </td><td> 記錄錯誤資料； </td></tr><tr><td> 步驟S505： </td><td> 檢查測試機台11系統回報(System Logs)的狀態，若回報資料正常，則進入步驟S507，若回報資料異常，則進入步驟S506； </td></tr><tr><td> 步驟S506： </td><td> 記錄錯誤資料； </td></tr><tr><td> 步驟S507： </td><td> 偵測所有記憶體模組12的檢測狀態，若所有記憶體模組12都被測試完成，進入步驟S508，若有記憶體模組尚未被測試，則返回第4圖中的步驟S402； </td></tr><tr><td> 步驟S508： </td><td> 產生測試分析資料(Analysis Summary Report)； </td></tr><tr><td> 步驟S509： </td><td> 結束。 </td></tr></TBODY></TABLE>

第5圖的步驟S501至步驟S509說明如下。首先，測試系統100將測試機台11重新啟動後，透過步驟S501檢查其內部作業系統的狀態。此時，重新啟動的作業系統會發生兩種情況，一種為正常啟動且正常匯入驅動程序而進入待命狀態，另一種情況為異常情況，重啟的作業系統仍然執行失敗。因此，若是重啟的作業系統仍然失敗時，表示作業系統可能有其他原因導致執行失敗，例如記憶體模組12發生物理性損壞等等。這時候，用戶端機台10就會透過步驟S502記錄錯誤資料。若是重啟的作業系統能正常運作，則測試系統100將依據步驟S503，進一步檢查遠端伺服器連線回報資料(BMC)的狀態。若是回報資料異常，用戶端機台10就會透過步驟S504記錄錯誤資料。若是回報資料正常，則測試系統100將依據步驟S505，進一步檢查測試機台11系統回報資料(System Logs)的狀態。若是回報資料正常，則測試系統100將執行步驟S507。若是回報資料異常，用戶端機台10就會透過步驟S506記錄錯誤資料。而測試系統100於執行步驟S502、步驟S504及/或步驟S506之後，也會進入步驟S507。在步驟S507中，用戶端機台10上的測試軟體13會透過測試機台11偵測所有記憶體模組12的檢測狀態，以避免漏掉測試某些記憶體模組12。因此，當所有記憶體模組12都被檢測完成時，用戶端機台10將會依據前述步驟S501至S506的資料狀態或是記錄的錯誤資料，於步驟S508產生測試分析資料(報告)(Analysis Summary Report)，並於步驟S509結束測試流程。反之，當某些記憶體模組12尚未被檢測完成時，測試系統100將會返回第4圖中的步驟S402。因此，在使用多位元錯誤型樣之第三階段III的流程中，透過步驟S501至步驟S509，記憶體模組12的測試分析報告及資料將會被自動產生出來，測試人員不需要手動去對記憶體模組12逐一測試。

第6圖係為記憶體模組12的測試方法，使用單位元錯誤型樣之第二階段II的流程圖。不同於上述考慮多位元錯誤型樣(MBE Pattern)，在此考慮了單位元錯誤型樣(SBE Pattern)的測試。當用戶端機台10與測試機台11利用第3圖的流程建立合法且專用的連結後，測試系統100即開始執行記憶體模組12的測試程序。而記憶體模組12的測試程序包含但不限定於以下步驟： <TABLE border="1" borderColor="#000000" width="_0006"><TBODY><tr><td> 步驟S601： </td><td> 檢測迴圈啟動； </td></tr><tr><td> 步驟S602： </td><td> 偵測未被檢測的記憶體模組12； </td></tr><tr><td> 步驟S603： </td><td> 注入單位元錯誤型樣(SBE Pattern)至未被檢測的記憶體模組12； </td></tr><tr><td> 步驟S604： </td><td> 檢查記憶體模組12的單位元錯誤狀態； </td></tr><tr><td> 步驟S605： </td><td> 檢查記憶體模組12是否被執行正確的錯誤位元回復機制? 若錯誤位元回復機制被正確執行而使錯誤位元被更正，則進入步驟S701，若錯誤位元回復機制執行異常，則進入步驟S606； </td></tr><tr><td> 步驟S606： </td><td> 檢查重試(Retry)次數，若重試次數大於R，進入步驟S702，若重試次數小於等於R，則返回步驟S603。 </td></tr></TBODY></TABLE>

第6圖的步驟S601至步驟S606說明如下。當用戶端機台10與測試機台11利用第3圖中的步驟S301至步驟S305(第一階段I)可建立合法且專用的連結後，用戶端機台10上的測試軟體13，會利用Intel ^□開發的Rastool測試工具，並透過測試機台11，於步驟S601啟動檢測迴圈。這邊所指的檢測迴圈為一種循序式的處理流程，可對任何單位的記憶體模組12依序啟動測試程序。例如將記憶體模組12量化為以DIMM為單位或是以Bank為單位，再循序進行測試。在步驟S602中，這些未被檢測的記憶體模組12將透過測試機台11逐一注入單位元錯誤型樣。應當理解的是，正常的記憶體模組12在被注入單位元的錯誤型樣時，將會執行錯誤位元回復的功能，使發生錯誤的位元自動被更正。因此，在步驟S604中，測試軟體13會檢查記憶體模組12被注入單位元錯誤型樣之後的狀態，並於步驟605中，檢查記憶體模組12是否被執行正確的錯誤位元回復機制。若錯誤位元回復機制被正確執行而使錯誤位元被更正，則進入步驟S701(將於第7圖說明)。反之，若錯誤位元回復機制執行異常，則進入步驟S606。在步驟S606中，測試系統100會計算單位元錯誤型樣被重複注入的次數(Retry)，若重複注入的次數(這裡亦稱為重試次數)大於R，進入步驟S702(將於第7圖說明)。反之，若重複注入的次數小於等於R，則返回步驟S603，繼續重複地將單位元錯誤型樣注入至記憶體模組12中，這裡所指的R係為正整數。換言之，步驟S601及步驟S602為步驟S603的前置步驟，步驟S603係對應第2圖中的步驟S203，而步驟S604及步驟S605係為第2圖中步驟S204的子步驟。藉由透過步驟S601至步驟S606(第二階段II)，錯誤型樣(Error Pattern)將會被注入至記憶體模組12(未被檢測的記憶體模組)中，並進一步觀察記憶體模組12接受到這些錯誤型樣後會有那些反應及錯誤狀態(例如記憶體模組12自我更正錯誤位元)。而在執行步驟S601至步驟S606之後，測試系統100將會進入第三階段III，也就是產生錯誤及分析資料的階段，詳述於下。

第7圖係為第2圖之記憶體模組12的測試方法，使用單位元錯誤型樣之第三階段III的流程圖。第7圖的流程包含但不限定於步驟S701至步驟S705，如下： <TABLE border="1" borderColor="#000000" width="_0007"><TBODY><tr><td> 步驟S701： </td><td> 記錄檢測通過資料(Pass Log)； </td></tr><tr><td> 步驟S702： </td><td> 記錄錯誤資料(Error Log)； </td></tr><tr><td> 步驟S703： </td><td> 偵測所有記憶體模組12的檢測狀態，若所有記憶體模組12都被檢測完成，進入步驟S704，若有記憶體模組尚未被測試，則返回第6圖中的步驟S602； </td></tr><tr><td> 步驟S704： </td><td> 產生測試分析資料(Analysis Summary Report)； </td></tr><tr><td> 步驟S705： </td><td> 結束。 </td></tr></TBODY></TABLE>

第7圖的步驟S701至步驟S705說明如下。首先，若記憶體模組12被注入單位元的錯誤型樣後，成功地更正單位元錯誤。此時，用戶端機台10將會透過步驟S701，記錄檢測通過資料(Pass Log)，表示這一個記憶體模組12為正常狀態。反之，若記憶體模組12被注入單位元的錯誤型樣後，無法成功地更正單位元錯誤。此時，用戶端機台10將會透過步驟S702，記錄錯誤資料(Error Log)，表示這一個記憶體模組12可能發生某些問題。在步驟S703中，用戶端機台10上的測試軟體13會透過測試機台11偵測所有記憶體模組12的檢測狀態，以避免漏掉測試某些記憶體模組12。因此，當所有記憶體模組12都被檢測完成時，用戶端機台10將會依據前述步驟S701或S702的資料狀態或是記錄的錯誤資料，於步驟S704產生測試分析資料(報告)(Analysis Summary Report)，並於步驟S705結束測試流程。反之，當某些記憶體模組12尚未被檢測完成時，測試系統100將會返回第6圖中的步驟S602。因此，在使用單位元錯誤型樣之第三階段III的流程中，透過步驟S701至步驟S705，記憶體模組12的測試分析報告及資料最後會自動產生出來，測試人員不需要手動去對記憶體模組12逐一測試。

綜上所述，本發明描述了一種記憶體模組的測試方法及系統，其設計概念為利用軟體進行全自動化的測試，並利用多位元錯誤型樣或單位元錯誤型樣對記憶體模組進行測試，來自動偵測記憶體模組是否有異常的情況發生。因此，由於本發明之測試系統為具有自動測試記憶體模組的功能，相較於傳統手動的測試流程，本發明的測試時間亦可大幅縮短，且所花的人力成本以及人為失誤造成的錯誤亦可大幅降低。以上所述僅為本發明之較佳實施例，凡依本發明申請專利範圍所做之均等變化與修飾，皆應屬本發明之涵蓋範圍。

<TABLE border="1" borderColor="#000000" width="_0008"><TBODY><tr><td> 100 </td><td> 測試系統 </td></tr><tr><td> 10 </td><td> 用戶端機台 </td></tr><tr><td> 11 </td><td> 測試機台 </td></tr><tr><td> 12 </td><td> 記憶體模組 </td></tr><tr><td> 13 </td><td> 測試軟體 </td></tr><tr><td> 14 </td><td> 測試軟體工具 </td></tr><tr><td> S201至S205 </td><td> 步驟 </td></tr><tr><td> I至III </td><td> 階段 </td></tr><tr><td> S301至S305 </td><td> 步驟 </td></tr><tr><td> S401至S405 </td><td> 步驟 </td></tr><tr><td> S501至S509 </td><td> 步驟 </td></tr><tr><td> S601至S606 </td><td> 步驟 </td></tr><tr><td> S701至S705 </td><td> 步驟 </td></tr><tr><td> A至F </td><td> 流程圖的端點 </td></tr></TBODY></TABLE>

第1圖係為本發明記憶體模組的測試系統之實施例的架構圖。第2圖係為第1圖實施例之記憶體模組的測試方法之流程圖。第3圖係為第2圖之記憶體模組的測試方法之第一階段的流程圖。第4圖係為第2圖之記憶體模組的測試方法，使用多位元錯誤型樣之第二階段的流程圖。第5圖係為第2圖之記憶體模組的測試方法，使用多位元錯誤型樣之第三階段的流程圖。第6圖係為第2圖之記憶體模組的測試方法，使用單位元錯誤型樣之第二階段的流程圖。第7圖係為第2圖之記憶體模組的測試方法，使用單位元錯誤型樣之第三階段的流程圖。

<TABLE border="1" borderColor="#000000" width="_0010"><TBODY><tr><td> 100 </td><td> 測試系統 </td></tr><tr><td> 10 </td><td> 用戶端機台 </td></tr><tr><td> 11 </td><td> 測試機台 </td></tr><tr><td> 12 </td><td> 記憶體模組 </td></tr><tr><td> 13 </td><td> 測試軟體 </td></tr><tr><td> 14 </td><td> 測試軟體工具 </td></tr></TBODY></TABLE>

Claims

一種記憶體模組的測試方法，包含：一用戶端機台與一測試機台建立一連結；驗證該用戶端機台與該測試機台間之該連結的合法性；產生一錯誤型樣(Error Pattern)至該測試機台之一記憶體模組中；檢查該記憶體模組的一錯誤狀態；及依據該記憶體模組的該錯誤狀態，該用戶端機台產生一測試分析資料；偵測一未被測試的記憶體模組；及產生並注入一多位元錯誤型樣(MBE Pattern)至該未被測試的記憶體模組。
如請求項1所述之測試方法，其中驗證該用戶端機台與該測試機台間之該連結的合法性，包含：該測試機台傳送一連結資料(SCP)至用戶端機台；及該用戶端機台檢查該連結資料是否合法(Valid)。
如請求項1所述之測試方法，其中檢查該記憶體模組的該錯誤狀態，包含：檢查注入該多位元錯誤型樣後之該記憶體模組對應之一作業系統(OS)是否失敗(Hang Up)；及若該作業系統失敗，重新啟動該測試機台。
如請求項3所述之測試方法，其中依據該記憶體模組的該錯誤狀態，該用戶端機台產生該測試分析資料，包含：重新啟動該測試機台後，檢查該測試機台對應於該記憶體模組之該作業系統之一狀態；若該作業系統係為一執行失敗狀態，產生並記錄一錯誤資料；及依據該錯誤資料，產生該測試分析資料。
如請求項3所述之測試方法，其中依據該記憶體模組的該錯誤狀態，該用戶端機台產生該測試分析資料，包含：檢查該對應於該記憶體模組之一遠端伺服器回報資料(BMC)之一狀態；若該遠端伺服器回報資料係為一資料異常狀態，產生並記錄一錯誤資料；及依據該錯誤資料，產生該測試分析資料。
如請求項3所述之測試方法，其中依據該記憶體模組的該錯誤狀態，該用戶端機台產生該測試分析資料，包含：檢查該測試機台對應於該記憶體模組之一系統回報資料(System Logs)之一狀態；若該系統回報資料係為一資料異常狀態，產生並記錄一錯誤資料；及依據該錯誤資料，產生該測試分析資料。
如請求項1所述之測試方法，另包含：產生並注入一單位元錯誤型樣(SBE Pattern)至該未被測試的記憶體模組。
如請求項7所述之測試方法，其中檢查該記憶體模組的該錯誤狀態，包含：檢查該記憶體模組之一單位元的該錯誤狀態；及檢查該記憶體模組是否被執行一錯誤位元回復機制。
如請求項8所述之測試方法，其中檢查該記憶體模組的該錯誤狀態，另包含：若該記憶體模組未被執行該錯誤位元回復機制，重新將該單位元錯誤型樣(SBE Pattern)注入至該記憶體模組中；及該方法另包含：產生並記錄一錯誤資料(Error Log)。