本發(fā)明涉及服務器技術領域，特別涉及一種測試管理控制器的方法、裝置和系統(tǒng)。

背景技術：

基板管理控制器(Baseboard Management Controller，BMC)是內置在服務器中的一個重要部件，用戶通過登入到BMC，使其在服務器的運行過程中發(fā)揮作用。目前，為保證能夠順利登入登出，在服務器發(fā)布之前，都會對BMC進行登入登出測試，進而檢測BMC的穩(wěn)定性，以此來避免給用戶和公司造成嚴重的損失等問題。

目前，在進行BMC登入登出測試時，主要是通過測試人員手動完成登入登出。

但是，一般情況下，為檢測BMC的穩(wěn)定性，需要進行不少于500次的測試，那如果每次的登入登出均是由測試人員手動完成，將會耗費大量的時間，從而整個登入登出測試過程的效率就會非常低。

技術實現(xiàn)要素：

本發(fā)明實施例提供了一種測試管理控制器的方法、裝置和系統(tǒng)，提高了登入登出測試過程的效率。

第一方面，本發(fā)明實施例提供了一種測試管理控制器的方法，該方法包括：

確定待測試管理控制器的測試參數(shù)；標準地址、標準登入標識、標準確認標識及測試次數(shù)；

當接收到外部的執(zhí)行觸發(fā)時，按照所述測試參數(shù)中的測試次數(shù)，對所述待測試管理控制器進行測試。

優(yōu)選地，所述按照所述測試參數(shù)中的測試次數(shù)，對所述管理控制器進行測試，包括：

N1：根據所述測試參數(shù)中的標準地址，獲取所述待測試管理控制器的登入界面；

N2：將所述測試參數(shù)中的標準登入標識和標準確認標識添加到所述登入界面中，當?shù)侨氤晒r，進行登出，并確定已完成的目標測試次數(shù)；

N3：判斷所述已完成的目標測試次數(shù)是否小于所述測試參數(shù)中的測試次數(shù)，如果是，則執(zhí)行N1。

優(yōu)選地，在所述將所述測試參數(shù)中的標準登入標識和標準確認標識添加到所述登入界面之后，進一步包括：

確定所述登入界面跳轉到測試界面，判斷所述測試界面是否存在至少一個特征標識，如果是，則確定登入成功。

優(yōu)選地，在所述將所述測試參數(shù)中的標準登入標識和標準確認標識添加到所述登入界面中之后，進一步包括：

當?shù)侨胧r，生成測試失敗信號，并通過所述測試失敗信號中斷測試。

優(yōu)選地，進一步包括：

利用下述計算公式(1)，計算所述待測試管理控制器的可用度；

其中，λ表征所述待測試次數(shù)對應的所述待測試BMC的可用度；n表征所述待測試次數(shù)；n′表征在所述測試次數(shù)n中登入成功的次數(shù)；t_ci表征第i次測試為登入成功時第i次測試所用的時間；t_sj表征第j次測試為登入失敗時第j次測試所用的時間；

判斷所述可用度是否不小于預設的可用閾值，如果是，則確定所述測試的結果為合格。

優(yōu)選地，進一步包括：

將所述測試次數(shù)中的每一次測試作為當前測試，執(zhí)行：

判斷是否存在目標文件夾；如果是，則在所述目標文件夾中為所述當前測試創(chuàng)建對應的測試文件，所述測試文件存儲所述當前測試對應的執(zhí)行日志及測試結果；否則，創(chuàng)建所述目標文件夾。

第二方面，本發(fā)明實施例提供了一種測試管理控制器裝置，該裝置包括：

確定單元，用于確定待測試管理控制器的測試參數(shù)；標準地址、標準登入標識、標準確認標識及測試次數(shù)；

測試單元，用于當接收到外部的執(zhí)行觸發(fā)時，按照所述確定單元確定的所述測試參數(shù)中的測試次數(shù)，對所述待測試管理控制器進行測試。

優(yōu)選地，所述測試單元，用于循環(huán)執(zhí)行下述N1至N3：

N1：根據所述測試參數(shù)中的標準地址，獲取所述待測試管理控制器的登入界面；N2：將所述測試參數(shù)中的標準登入標識和標準確認標識添加到所述登入界面中，當?shù)侨氤晒r，進行登出，并確定已完成的目標測試次數(shù)；N3：判斷所述已完成的目標測試次數(shù)是否小于所述測試參數(shù)中的測試次數(shù)，如果是，則執(zhí)行N1。

優(yōu)選地，進一步包括：計算單元和判斷單元，其中，

所述計算單元，用于利用下述計算公式，計算所述待測試管理控制器的可用度；

其中，λ表征所述待測試次數(shù)對應的所述待測試管理控制器的可用度；n表征所述確定單元確定出的所述待測試次數(shù)；n′表征在所述測試次數(shù)n中登入成功的次數(shù)；t_ci表征第i次測試為登入成功時第i次測試所用的時間；t_sj表征第j次測試為登入失敗時第j次測試所用的時間；

所述判斷單元，用于判斷所述計算單元計算出的所述可用度是否不小于預設的可用閾值，如果是，則確定所述測試單元的所述測試的結果為合格。

第三方面，本發(fā)明實施例提供了一種測試管理控制器系統(tǒng)，該系統(tǒng)可以包括：上述任一所述的測試管理控制器裝置和至少一個待測試管理控制器，其中，

所述至少一個待測試管理控制器中，每個待測試管理控制器，用于針對每次測試，當接收到所述標準登入標識和所述標準確認標識時，通過所述測試管理控制器裝置展示相應的所述登入界面和所述測試界面或者是不響應。

本發(fā)明實施例提供了一種測試管理控制器的方法、裝置和系統(tǒng)，通過確定一次待測試管理控制器的標準地址、標準登入標識、標準確認標識及測試次數(shù)，那在接收到外部的執(zhí)行觸發(fā)后，就可以按照確定的測試次數(shù)，對待測試管理控制器進行測試，這樣，就能夠有效避免在進行每次測試時，都由測試人員手動輸入，從而提高了針對管理控制器進行登入登出測試過程的效率。

附圖說明

為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術中的技術方案，下面將對實施例或現(xiàn)有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖是本發(fā)明的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據這些附圖獲得其他的附圖。

圖1是本發(fā)明一個實施例提供的一種測試管理控制器方法的流程圖；

圖2是本發(fā)明實施例提供的測試管理控制器裝置所在設備的硬件架構圖；

圖3是本發(fā)明一個實施例提供的一種測試管理控制器裝置的結構示意圖；

圖4是本發(fā)明另一個實施例提供的一種測試管理控制器裝置的結構示意圖；

圖5是本發(fā)明一個實施例提供的一種測試管理控制器系統(tǒng)的結構示意圖；

圖6是本發(fā)明另一個實施例提供的一種測試管理控制器方法的流程圖；

圖7是本發(fā)明又一個實施例提供的一種測試管理控制器方法的流程圖。

具體實施方式

為使本發(fā)明實施例的目的、技術方案和優(yōu)點更加清楚，下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例是本發(fā)明一部分實施例，而不是全部的實施例，基于本發(fā)明中的實施例，本領域普通技術人員在沒有做出創(chuàng)造性勞動的前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

如圖1所示，本發(fā)明實施例提供了一種測試管理控制器的方法，該方法可以包括以下步驟：

步驟101：確定待測試管理控制器的測試參數(shù)；標準地址、標準登入標識、標準確認標識及測試次數(shù)。

步驟102：當接收到外部的執(zhí)行觸發(fā)時，按照所述測試參數(shù)中的測試次數(shù)，對所述待測試管理控制器進行測試。

在本發(fā)明實施例中，通過確定一次待測試管理控制器的標準地址、標準登入標識、標準確認標識及測試次數(shù)，那在接收到外部的執(zhí)行觸發(fā)后，就可以按照確定的測試次數(shù)，對待測試管理控制器進行測試，這樣，就能夠有效避免在進行每次測試時，都由測試人員手動輸入，從而提高了針對管理控制器進行登入登出測試過程的效率。

在本發(fā)明一個實施例中，為了實現(xiàn)按照確定的測試次數(shù)，實現(xiàn)對待測試管理控制器的自動化測試，所述步驟102的具體實施方式包括：N1：根據所述測試參數(shù)中的標準地址，獲取所述待測試管理控制器的登入界面；N2：將所述測試參數(shù)中的標準登入標識和標準確認標識添加到所述登入界面中，當?shù)侨氤晒r，進行登出，并確定已完成的目標測試次數(shù)；N3：判斷所述已完成的目標測試次數(shù)是否小于所述測試參數(shù)中的測試次數(shù)，如果是，則執(zhí)行N1。

例如，確定的測試參數(shù)中的測試次數(shù)為500次，且當前是對待測試管理控制器進行第30次測試，且第30次測試對應的結果為登入成功，然后，自動判斷出30次〈500次，因此，接下來就會自動從N1開始，執(zhí)行第31次測試。

除此之外，針對每次測試，也無需再由測試人員手動輸入，例如，標準登入標識為admin和標準確認標識為admni，那以上面提到的執(zhí)行第31次測試為例，在執(zhí)行步驟N1時，又會自動將接收外部的執(zhí)行觸發(fā)之前確定的admin和admni自動添加到登入界面中。

通過根據確定的標準地址自動打開相應的登入界面，以及在登入界面中自動添加確定的標準登入標識和標準確認標識，以及通過自動判斷目標測試是否達到已確定的測試次數(shù)，在未達到時，繼續(xù)自動進行下一次的登入登出測試，整個測試過程均是自動完成，從而無需再由測試人員進行手動輸入并完成所有次的測試，因此，提高了針對管理控制器進行登入登出測試過程的效率。

在本發(fā)明一個實施例中，為了確定當前測試是否成功，在所述步驟102中的將所述測試參數(shù)中的標準登入標識和標準確認標識添加到所述登入界面之后，進一步包括：確定所述登入界面跳轉到測試界面，判斷所述測試界面是否存在至少一個特征標識，如果是，則確定登入成功。

其中，特征標識不唯一，可根據用戶需求進行設置，但特征標識的數(shù)量至少為一個，以測試界面中存在的多個按鈕為例，那每個按鈕相應的Button+數(shù)字就可以作為特征標識，如Button1或者Button9。

通過在登入界面跳轉后的測試頁面中找到一個特征標識，這樣，就可知，當前測試已經登入成功，從而為測試成功的測試結果提供了有力的基礎，為完成對待測試管理控制器的測試奠定了基礎。

在本發(fā)明一個實施例中，為了保障對待測試管理控制器的穩(wěn)定性的準確性，在所述步驟102中的將所述測試參數(shù)中的標準登入標識和標準確認標識添加到所述登入界面中之后，進一步包括：當?shù)侨胧r，生成測試失敗信號，并通過所述測試失敗信號中斷測試。

如果不考慮外界的影響，那在出現(xiàn)登入失敗時，就可以中斷測試，無論是否達到測試次數(shù)，均不在繼續(xù)執(zhí)行，例如，同樣以確定的測試參數(shù)中的測試次數(shù)為500次，且當前是對待測試管理控制器進行第30次測試為例，如果第30次的測試結果為登入失敗，則無需在進行第31次操作，從而整個測試過程共執(zhí)行了30次，因此，按照本發(fā)明實施例所述，待測試管理控制器的測試結果為失敗。

通過在登入失敗時，中斷所有測試，這樣，實現(xiàn)了對待測試管理控制器的測試，以此可以判斷待測試管理控制器的穩(wěn)定性不佳，因此，還需對待測試管理控制器進行相應的調整，避免在將其發(fā)布之后，給公司及用戶造成嚴重的損失。

在本發(fā)明一個實施例中，為了排除外界因素有可能對待測試管理控制器造成的影響，可進一步包括：利用下述計算公式(1)，計算所述待測試管理控制器的可用度；

其中，λ表征所述待測試次數(shù)對應的所述待測試管理控制器的可用度；n表征所述待測試次數(shù)；n′表征在所述測試次數(shù)n中登入成功的次數(shù)；t_ci表征第i次測試為登入成功時第i次測試所用的時間；t_sj表征第j次測試為登入失敗時第j次測試所用的時間；

判斷所述可用度是否不小于預設的可用閾值，如果是，則確定所述測試的結果為合格。

例如，確定測試次數(shù)n為500次、在測試次數(shù)n為500次中登入成功的次數(shù)n′為499、在測試次數(shù)n為500次中登入失敗的次數(shù)為500-n′＝500-499＝1次、第i次測試為登入成功時第i次測試所用的時間t_ci及第j次測試為登入失敗時第j次測試所用的時間t_sj之后，就可以利用上述計算公式(1)計算出待測試管理控制器的可用度，例如而預先設置的可用閾值為98％，因此可以確定待測試管理控制器的測試結果為合格。

由于在測試的過程中，無法排除會有其他因素影響到整個測試過程，從而通過執(zhí)行完所有次測試，并根據測試的結果及相應的測試時間，計算出待測試管理控制器的可用度，這樣，在一定程度上，也避免了由于外界因素影響而導致的對待測試管理控制器的測試失誤的判斷。

在本發(fā)明一個實施例中，為了將整個測試過程中的詳細測試信息以及每次測試的測試結果展示給測試人員，可進一步包括：將所述測試次數(shù)中的每一次測試作為當前測試，執(zhí)行：判斷是否存在目標文件夾；如果是，則在所述目標文件夾中為所述當前測試創(chuàng)建對應的測試文件，所述測試文件存儲所述當前測試對應的執(zhí)行日志及測試結果；否則，創(chuàng)建所述目標文件夾。

一般情況下，為方便測試人員能夠找到整個測試過程的詳細測試信息，目標文件夾為命名為Login_out的文件夾，且創(chuàng)建的文件為Login_out文件，這樣，在執(zhí)行完成一次測試之后，無論是是登入成功還是登入失敗，均會在相應的文件中存儲Log執(zhí)行日志以及測試結果。

通過查找或創(chuàng)建目標文件夾，以及針對每次測試創(chuàng)建對應的測試文件，這樣，在完成對待測試管理控制器的測試之后，測試人員就可以通過找到該目標文件夾，并在該目標文件夾中找到所有的測試對應的執(zhí)行日志以及測試結果，而避免了之前測試人員無法查看具體測試信息的弊端。

如圖2、圖3所示，本發(fā)明實施例提供了一種測試管理控制器裝置。裝置實施例可以通過軟件實現(xiàn)，也可以通過硬件或者軟硬件結合的方式實現(xiàn)。從硬件層面而言，如圖2所示，為本發(fā)明實施例提供的測試管理控制器裝置所在設備的一種硬件結構圖，除了圖2所示的處理器、內存、網絡接口、以及非易失性存儲器之外，實施例中裝置所在的設備通常還可以包括其他硬件，如負責處理報文的轉發(fā)芯片等等。以軟件實現(xiàn)為例，如圖3所示，作為一個邏輯意義上的裝置，是通過其所在設備的CPU將非易失性存儲器中對應的計算機程序指令讀取到內存中運行形成的。本實施例提供的測試管理控制器裝置，包括：

確定單元301，用于確定待測試管理控制器的測試參數(shù)；標準地址、標準登入標識、標準確認標識及測試次數(shù)；

測試單元302，用于當接收到外部的執(zhí)行觸發(fā)時，按照所述確定單元301確定的所述測試參數(shù)中的測試次數(shù)，對所述待測試管理控制器進行測試。

如圖4所示，在本發(fā)明一個實施例中，為了判斷待測試管理控制器是否合格，進一步包括：計算單元401和判斷單元402，其中，

所述計算單元401，用于利用下述計算公式(1)，計算所述待測試管理控制器的可用度；

其中，λ表征所述待測試次數(shù)對應的所述待測試管理控制器的可用度；n表征所述確定單元301確定出的待測試次數(shù)；n′表征在所述測試次數(shù)n中登入成功的次數(shù)；t_ci表征第i次測試為登入成功時第i次測試所用的時間；t_sj表征第j次測試為登入失敗時第j次測試所用的時間；

所述判斷單元402，用于判斷所述計算單元401計算出的所述可用度是否不小于預設的可用閾值，如果是，則確定所述測試單元302測試的結果為合格。

如圖5所示，本發(fā)明實施例提供了一種測試管理控制器系統(tǒng)，該系統(tǒng)可以包括：上述任一所述的測試管理控制器裝置501和至少一個待測試管理控制器502，其中，

所述至少一個待測試管理控制器502中，每個待測試管理控制器502，用于針對每次測試，當接收到所述標準登入標識和所述標準確認標識時，通過所述測試管理控制器裝置501展示相應的所述登入界面和所述測試界面或者是不響應。

下面將以兩種判斷測試結果(第一種：出現(xiàn)登入失敗時，中斷測試；第二種：完成所有次測試)來測試管理控制器為例，通過確定待測試管理控制器及其測試參數(shù)(標準地址、標準登入標識、標準確認標識及測試次數(shù))，然后針對測試參數(shù)中的測試次數(shù)，完成對待測試管理控制器的測試。

下面將以“第一種：出現(xiàn)登入失敗時，中斷測試”、待測試管理控制器A的測試參數(shù)中的標準地址1、標準登入標識為admin、標準確認標識為admni及測試次數(shù)為1000次為例，對本發(fā)明實施例提供的一種測試管理控制器方法進行詳細說明，如圖6所示，該方法可以包括如下步驟：

步驟601：依次確定待測試管理控制器A的標準地址1、標準登入標識admin、標準確認標識admni及測試次數(shù)1000次。

每個待測試管理控制器均有相應的唯一地址與之對應，在本發(fā)明實施例中，測試人員在測試待測試管理控制器A時，可通過上網查看其中文資料，從而確定A的標準地址1，該地址也可稱為A的IP地址。

除此之外，標準登入標識和標準確認標識卻均不唯一，其中，A中可以存儲標準登入標識和標準確認標識之間的十幾個對應關系，但一般情況下，只存儲兩個對應關系，在本發(fā)明實施例中，admin和admni就是A中的其中一個對應關系。

而且，為保證測試結果的有效性，對于待測試管理控制器的測試一般都不少于500次，那在本發(fā)明實施例中，針對A的測試次數(shù)設定為1000次。

步驟602：接收外部的測試觸發(fā)。

在本發(fā)明實施例中，在已經確定待測試管理控制器A的標準地址1、標準登入標識admin、標準確認標識admni及測試次數(shù)1000次之后，需要在接收到外部的執(zhí)行觸發(fā)之后，根據測試次數(shù)1000次，對待測試管理控制器A開始進行測試。在本發(fā)明實施例中，外部的執(zhí)行觸發(fā)可以為計算機鍵盤上的“Eenter”鍵。

在接收到執(zhí)行觸發(fā)之后，就可以針對1000次測試中的每一次進行測試，在本步驟中首先進行第1次測試。

步驟603：判斷是否存在Login_out文件夾，如果是，則執(zhí)行步驟604，否則，執(zhí)行步驟605。

為了能夠向測試人員展示全面的測試結果信息，可通過生成每次測試的執(zhí)行日志以及測試結果，而且，為便于在完成對待測試管理控制器A的測試之后，測試人員能夠方便的找到這些信息，因此，在本發(fā)明實施例中，可將其放在一個文件夾名稱為Login_out的文件夾，那如果之前進行過類似測試，應該會有該文件夾，否則，就沒有該文件夾，所以，需判斷是否存在Login_out文件夾。

步驟604：在Login_out文件夾中為當前測試創(chuàng)建對應的Login_out文件，執(zhí)行步驟606。

針對本發(fā)明實施例1000次測試中的每次測試，因為測試的執(zhí)行時間、測試結果等信息的不同，每次均會生成不同的執(zhí)行日志，所以可針對每次測試分別構建對應的Login_out文件，例如，在進行第k次測試時，就會在Login_out文件夾中創(chuàng)建一個相應的Login_out k文件，那這樣，在完成第k次測試時，該文件就會對當前第k次測試的執(zhí)行日志及測試結果進行存儲。

步驟605：創(chuàng)建Login_out文件夾，并執(zhí)行步驟604。

如上述步驟603所述。

步驟606：根據標準地址1，獲取待測試管理控制器A的登入界面。

在本發(fā)明實施例中，在執(zhí)行測試時，會首先根據待測試管理控制器A的標準地址1，打開一個與之對應的A的登入界面，該登入界面中有標準登入標識和標準確認標識相對應的輸入框，以此進行登入。

步驟607：將admin和admni添加到登入界面中，確定登入界面跳轉到測試界面。

將admin和admni添加到上述步驟606中提到的登入界面中的相應輸入框內，如果輸入的admin和admni是相互對應且正確的，那登入界面就會實現(xiàn)跳轉，那如果測試人員在確定標準登入標識和標準確認標識時，輸入有誤，那在執(zhí)行到該步驟時，也會有相應的提示，例如，標準登入標識輸入錯誤、標準登入標識不存在或者標準確認標識有誤等提示性信息，然后為實現(xiàn)對A的測試，就需要重新進行確定。

步驟608：判斷測試界面中是否存在至少一個ID，如果是，則執(zhí)行步驟609，否則，執(zhí)行步驟612。

在本發(fā)明實施例中，只要在跳轉后的測試界面中找到一個ID(特征標識的其中一種)，例如，在跳轉后的測試頁面中找到多個ID，分別為Button1、Button2和Button3。

步驟609：確定登入成功，并登出，以及確定已完成的目標測試次數(shù)k。

步驟610：將當前第k次測試對應的執(zhí)行日志及登入成功的測試結果保存到對應的Login_out文件中。

當步驟609中登出之后，則對于A的第k次測試執(zhí)行完成，那針對當前測試，也生成了相應的執(zhí)行日志，例如，以第k次測試過程中的一個執(zhí)行日志為例，如{某年某月某日某時某分某秒：admin和admni添加到登入界面}。

除此之外，登入成功的測試結果也會生成，例如{某年某月某日某時某分某秒：第k次測試登入登出成功}。

步驟611：判斷目標測試次數(shù)k是否小于1000，如果是，則執(zhí)行步驟606，否則，執(zhí)行步驟614。

由于在已確定測試次數(shù)為1000次，因此，在當前測試成功之后，如果未達到1000次，還應繼續(xù)從本發(fā)明實施例中的步驟607繼續(xù)進行測試，那如果已達到該次數(shù)，則已完成測試，從而中斷測試即可。

步驟612：生成測試失敗信號，并通過測試失敗信號中斷測試。

在本發(fā)明實施例中，在1000次測試中，只要出現(xiàn)一次登入失敗，就中斷所有測試，并認為待測試管理控制器A的測試不達標。

步驟613：將當前測試對應的執(zhí)行日志及登入失敗的測試結果保存到對應的Login_out文件中，并結束當前流程。

在本發(fā)明實施例中，對于登入失敗的執(zhí)行日志以及測試結果也應進行相應的存儲，以方便在完成所有測試后，向測試人員展示全面的測試執(zhí)行日志以及對應的測試結果。

步驟614：結束并退出測試。

下面將以“第二種：完成所有次測試”、待測試管理控制器A的測試參數(shù)中的標準地址1、標準登入標識為admin、標準確認標識為admni及測試次數(shù)為1000次為例，對本發(fā)明實施例提供的一種測試管理控制器方法進行詳細說明，如圖7所示，該方法可以包括如下步驟：

步驟701：預先設置待測試管理控制器A的可用閾值λ₁。

在本發(fā)明實施例中，考慮到外界因素有可能會對待測試管理控制器A的測試過程產生一定影響，因此，可通過執(zhí)行完1000次測試，然后根據每次的測試結果，計算出待測試管理控制器A的可用度，然后通過與預先設置的可用閾值判斷λ₁進行比較，從而確定A是否合格。

步驟702：確定待測試管理控制器A的標準地址1、標準登入標識admin、標準確認標識admni及測試次數(shù)1000次。

在本發(fā)明實施例中，該步驟與圖6中相應的方法一致，首先應確定待測試管理控制器A的上述四個測試參數(shù)。

步驟703：接收外部的測試觸發(fā)。

在本發(fā)明實施例中，當確定待測試管理控制器A的標準地址1、標準登入標識admin、標準確認標識admni、測試次數(shù)1000次以及接收觸發(fā)之后，就會自動完成針對待測試管理控制器A的每次登入登出測試，而無需測試人員手動進行1000次測試，這樣，能夠有效提高測試過程中的效率。

步驟704：判斷是否存在Login_out文件夾，如果是，則執(zhí)行步驟705，否則，執(zhí)行步驟706。

步驟705：在Login_out文件夾中為當前測試創(chuàng)建對應的Login_out文件，執(zhí)行步驟707。

步驟706：創(chuàng)建Login_out文件夾，并執(zhí)行步驟706。

步驟707：根據標準地址1，獲取待測試管理控制器A的登入界面。

步驟708：將admin和admni添加到登入界面中，確定登入界面跳轉到測試界面。

步驟709：判斷測試界面是否存在至少一個ID，如果是，則執(zhí)行步驟710，否則，執(zhí)行步驟713。

步驟710：確定登入成功，進行登出，確定已完成的目標測試次數(shù)i，及當前第i次測試所用的時間t_ci。

在本發(fā)明實施例中，為計算待測試管理控制器A的可用度，應在每次完成測試時，計算該測試過程所用的時間，那第i次測試所用的時間t_ci是指從執(zhí)行步驟707至當前步驟中完成登出時所需的時間，例如，第501次測試為登入登出測試成功，且所用的時間t_c501為2s；除此之外，還可通過根據生成的執(zhí)行日志進行計算，如，在進行確定第i次測試所需的時間t_ci時，根據當前步驟已經生成的執(zhí)行日志進行獲得，例如，在第20次測試時生成的第一條執(zhí)行日志為{2016年10月28日23時22分55秒：獲取了待測試管理控制器A的登入界面}，生成的最后一條執(zhí)行日志為{2016年10月28日23時22分56秒：登出成功}，所以第20次測試所用的時間t_c20為56-55＝1秒。

需要說明的是，在執(zhí)行到該步驟時，均會確定相應測試下對應的時間，以便與為之后判斷待測試管理控制器A是否合格奠定基礎。

步驟711：將當前第i次測試對應的執(zhí)行日志及登入成功的測試結果保存到對應的Login_out文件中。

步驟712：判斷目標測試次數(shù)i是否小于1000，如果是，則執(zhí)行步驟707，否則，執(zhí)行步驟716。

步驟713：確定登入失敗，確定已完成的目標測試次數(shù)j，及當前第j次測試所用的時間t_sj。

在本發(fā)明實施例中，同樣可根據上述步驟611中的方法確定第j次測試所用的時間t_sj。

步驟714：將當前第j次測試對應的執(zhí)行日志及登入失敗的測試結果保存到對應的Login_out文件中。

步驟715：判斷目標測試次數(shù)j是否小于1000，如果是，則執(zhí)行步驟707，否則，執(zhí)行步驟716。

在本發(fā)明實施例中，無論是登入登出成功，還是登入登出失敗，都需要判斷當前測試次數(shù)j是否小于1000，這樣，如果小于，則繼續(xù)從步驟707進行下一次測試，如果不小于，則執(zhí)行步驟716。

步驟716：確定1000次測試中登入成功的次數(shù)n′為998次。

在完成所有1000次測試之后，確定在這1000次測試中登入成功的次數(shù)n′，在本發(fā)明實施例中，以登入成功的次數(shù)n′為998次為例，則相應的登入失敗的次數(shù)就可以計算得出為1000-n′＝1000-998＝2次。

步驟717：根據測試次數(shù)n為1000次、n′、1000-n′、t_ci及t_sj，計算待測試管理控制器A的可用度λ。

在本發(fā)明實施例中，在確定測試次數(shù)n為1000次、在測試次數(shù)n為1000次中登入成功的次數(shù)n′、在測試次數(shù)n為1000次中登入失敗的次數(shù)1000-n′、第i次測試為登入成功時第i次測試所用的時間t_ci及第j次測試為登入失敗時第j次測試所用的時間t_sj之后，就可以利用計算公式(1)計算出待測試管理控制器A的可用度那在本發(fā)明實施例中，為簡化計算方法，例如，以根據公式(1)計算出的待測試管理控制器A的可用度λ為98.997％。

步驟718：判斷λ是否小于λ₁，如果是，則執(zhí)行步驟719，否則執(zhí)行步驟720。

步驟719：確定待測試管理控制器A的測試結果為合格。

在本發(fā)明實施例中，通過判斷λ＝98.997％和λ₁＝98％，則可明顯看出λ＝98.997％＞λ₁＝98％，因此，針對待測試管理控制器A的測試結果合格。

步驟720：確定待測試管理控制器A的測試結果為不合格。

綜上，本發(fā)明各個實施例至少具有如下有益效果：

1、在本發(fā)明實施例中，通過確定一次待測試管理控制器的標準地址、標準登入標識、標準確認標識及測試次數(shù)，那在接收到外部的執(zhí)行觸發(fā)后，就可以按照確定的測試次數(shù)，對待測試管理控制器進行測試，這樣，就能夠有效避免在進行每次測試時，都由測試人員手動輸入，從而提高了針對管理控制器進行登入登出測試過程的效率。

2、在本發(fā)明實施例中，通過根據確定的標準地址自動打開相應的登入界面，以及在登入界面中自動添加確定的標準登入標識和標準確認標識，以及通過自動判斷目標測試是否達到已確定的測試次數(shù)，在未達到時，繼續(xù)自動進行下一次的登入登出測試，整個測試過程均是自動完成，從而無需再由測試人員進行手動輸入并完成所有次的測試，因此，提高了針對管理控制器進行登入登出測試過程的效率。

3、在本發(fā)明實施例中，通過在登入界面跳轉后的測試頁面中找到一個特征標識，這樣，就可知，當前測試已經登入成功，從而為測試成功的測試結果提供了有力的基礎，為完成對待測試管理控制器的測試奠定了基礎。

4、在本發(fā)明實施例中，通過在登入失敗時，中斷所有測試，這樣，實現(xiàn)了對待測試管理控制器的測試，以此可以判斷待測試管理控制器的穩(wěn)定性不佳，因此，還需對待測試管理控制器進行相應的調整，避免在將其發(fā)布之后，給公司及用戶造成嚴重的損失。

5、在本發(fā)明實施例中，由于在測試的過程中，無法排除會有其他因素影響到整個測試過程，從而通過執(zhí)行完所有次測試，并根據測試的結果及相應的測試時間，計算出待測試管理控制器的可用度，這樣，在一定程度上，也避免了由于外界因素影響而導致的對待測試管理控制器的測試失誤的判斷。

6、在本發(fā)明實施例中，通過查找或創(chuàng)建目標文件夾，以及針對每次測試創(chuàng)建對應的測試文件，這樣，在完成對待測試管理控制器的測試之后，測試人員就可以通過找到該目標文件夾，并在該目標文件夾中找到所有的測試對應的執(zhí)行日志以及測試結果，而避免了之前測試人員無法查看具體測試信息的弊端。

上述裝置內的各單元之間的信息交互、執(zhí)行過程等內容，由于與本發(fā)明方法實施例基于同一構思，具體內容可參見本發(fā)明方法實施例中的敘述，此處不再贅述。

需要說明的是，在本文中，諸如第一和第二之類的關系術語僅僅用來將一個實體或者操作與另一個實體或操作區(qū)分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關系或者順序。而且，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個〃·····”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設備中還存在另外的相同因素。

本領域普通技術人員可以理解：實現(xiàn)上述方法實施例的全部或部分步驟可以通過程序指令相關的硬件來完成，前述的程序可以存儲在計算機可讀取的存儲介質中，該程序在執(zhí)行時，執(zhí)行包括上述方法實施例的步驟；而前述的存儲介質包括：ROM、RAM、磁碟或者光盤等各種可以存儲程序代碼的介質中。

最后需要說明的是：以上所述僅為本發(fā)明的較佳實施例，僅用于說明本發(fā)明的技術方案，并非用于限定本發(fā)明的保護范圍。凡在本發(fā)明的精神和原則之內所做的任何修改、等同替換、改進等，均包含在本發(fā)明的保護范圍內。