商務

單元測試的主要任務是驗證詳細規格說明書規定的軟體單元是否被開發人員以代碼的形式正確實現了。這裡的軟體單元在面向過程的程式設計中指的是某個函數，在物件導向的程式設計中指的是類或類的成員方法。該測試要把每個函數的每個分支都100%覆蓋到，並且每個函數的功能都100%覆蓋。單元測試一般是白盒測試，一般分為手工單元測試和自動化單元測試兩種。手工單元測試的基本原理是構建樁模組和測試馳動模組驅動被測單元的執行，然後側試人員輸入設計好的測試案例，測試被測單元能否按照要求處理測試案例。對於出現異常情況的測試案例

這一節以UBT為例，來說明商用測試的主要內容，中國電信運營BREW業務時，會有些不同點。接受檢查測試時，測試人員還將對線上提交的應用程式套件準確性及開發商資質作相應檢查。進入測試時，主要檢查MIF設定，應用程式圖示和應用在手機上的基本健全狀態。MIF設定包括MIF檔案可以正常被開啟，檔案中的優先順序設定是否正確。如果支援iLicense，須選擇File優先順序，ClassID不同時出現Applets和 Dependencies欄內，且不同時出現Applets 欄和Extensions

手機使用者可以被劃分為很多類型，從持有廉價手機的價格敏感型個人使用者到配備高端手機的企業使用者，從使用預付費手機的年輕新潮娛樂使用者再到月度費用支出較高的國際漫遊使用者，不一而足。通過BREW手機，能夠滿足所有這些使用者的各種需求。BREW的核心功能是“無線資料下載”，即手機可以從移動網路下載複雜的程式和應用。因此，和使用者最貼近的就是各種各樣的基於BREW的移動增值業務了。通過BREW應用管理器（BREW Appmanger & Mobileshop,

在BREW引入中國聯通之前，基於BREW的移動增值業務都是與手機上唯一識別碼（ESN）聯絡在一起，以實現計費和使用授權管理。當在BREW手機上引入RUIM卡後，應用所有權、購買資訊以及使用授權就與RUIM卡提供的唯一識別碼(IMSI)連繫了起來。跟據不同的使用者情況，一個帶有IMSI標識符的RUIM卡可以插入不同的手機，這就產生了一些獨特的計費情況。針對機卡分離的情況，BREW在2.X版中增加了一些功能。BDS分發系統也增加了對包月記費的處理以更好的解決用一個IMSI將同一個應用下載到多個手機上

    時間如水，在指尖滑過。    一年半的時間，我將《BREW進階與精通——3G移動增值業務的運營、定製與開發》一書終於連載完了，根據出版社的規定，所轉載的內容和實體書相比是不完整的。首先沒有圖，因為很多圖都是出版社的美編們修改過的，要尊重勞動。其次，其中的部分內容是在正式出版的時候做了修改。連載的內容大部分是我初稿的內容。   感謝電子出版社對我的協助，感謝朋友們的捧場和支援！在這裡給大家拜個晚年！祝大家在新的一年裡，宏“兔”大展！  

BREW 中提供了Perl 介面庫，開發人員可以通過Perl介面編寫指令碼，來實現批處理命令的自動化執行。其中的API 列表包括：•串連和控制目標手機u  ConnecttoDevice(char* portName, char* dllName)u  PutDeviceOffline(int)u  ResetDevice()•複製檔案和目錄u  CopyFileToDevice(char* src, char* dest, bool overwrite)u 

在BREW 3.x 版本以前，後台應用根本不響應suspend和resume事件，也處理有終端使用者相關的互動操作，例如按鍵事件等等。在BREW 3.x 以後，任何應用都可以對按鍵事件進行處理，可以簡單地通過註冊掩碼為NMASK_SHELL_KEY的通知來實現。通過ISHELL_StartBackgroundApplet()直接啟動一個後台應用，後台應用可以直接處理EVT_APP_START_BACKGROUND 事件而不是EVT_APP_START事件。在BREW

擴充類不作為獨立的應用程式使用，手機使用者不能直接特別購買、下載或刪除它們，而是在使用此擴充類的應用程式的內部環境中處理這些功能。擴充類是一種特殊的應用，相當於應用開發商自己開發的庫，在PC機上表現為DLL庫，在終端上同樣是mod執行檔案。擴充類應用從所有者的角度可以分為兩種：公有擴充類和私人擴充類。公有擴充類由開發商開發和擁有，提供給其他開發使用並收費。私人擴充類可以由開發商開發和擁有，供給自己的一個或多個應用使用，與其他應用共用收益；也可以由電訊廠商開發和擁有，由電訊廠商發布，提供給開發商或

在BREW技術平台上提供的是高速資料下載業務，使用者通過下載應用軟體到手機上運行來實現眾多功能，就象可以在PC上WINDOWS中添加、刪除程式一樣，使用者的手機可以下載各種功能的軟體來實現手機的個人化，而且能通過應用軟體的更新功能可以保證相應的移動增值業務不斷升級，始終擁有新鮮的體驗。從移動網路的使用狀況來看，基於BREW的移動增值業務可以分為離線業務和線上業務兩類：（1）離線業務，使用者將內容服務商提供的離線應用（如離線遊戲）下載並儲存到手機後，在手機中可以獨立運行該應用程式而不再需要網路的支

BREW是基於事件驅動的，可以通過ISHELL介面中的相關方法發送或接收指定的事件，事件在系統中的分發處理是通過AEE層來實現的。發送事件的方法有ISHELL_SendEvent，ISHELL_PostEvent等，接收特定事件的方法主要是通過ISHELL_RegisterNotify方法來實現，也可以通過MIF檔案中的設定完成。如果應用註冊了事件，AEE層在事件發生的時候就會發送EVT_NOTIFY 事件給該應用。           

如果成為了註冊開發商，就可以獲得BREW Toolsuite 工具。它是一個工具箱，裡面有apploader, BREWlogger, grinder,BREW signer 四個工具。其中BREW Signer 主要由標準認證的開發商直接使用，而由電訊廠商管理的CP/SP一般不需要直接使用BREW

BREW應用的商用測試一般是指TBT，即True Brew Test。TBT的目的是確保電訊廠商網路提供的是無病毒，無惡意的，穩定的移動增值服務。TBT是一個測試需求集合和測試流程，用來測試和評估一個移動增值服務。例如，使用測試手機或者商業網路來測試應用在真實手機上的效能等等。TBT 減少了應用測試的複雜性，例如不同的手機平台，不同的手機軟體版本等，能夠協助開發人員完善應用的品質，尤其是對新的開發人員而言。           

不論是典型的註冊開發商，還是電訊廠商管理的CP/SP，都可以通過開發商互連網或者電訊廠商互連網使用另外的兩個線上工具：ClassID產生器和測試簽名產生器。通過ClassID產生器可以為應用產生一個全球唯一的ClassID，線上工具的主要功能部分12-28所示。 圖 12-28： ClassID的線上產生工具輸入應用程式名稱，線上系統會為開發人員產生一個相應的bid檔案，開發人員下載該bid檔案，就可以安心的使用了。下面是RUIM地址簿介面的bid檔案內容。ifndef

使用者自訂事件的傳遞是應用間通訊的一種有效方法。使用者自訂的事件應當大於等於EVT_USER （0X7000），ISHELL_RegisterEvent()可根據輸入字串註冊自訂的 AEEEvent。 該函數允許應用程式動態保留事件備用，而無須擔心與其它 EVT_USER 範圍事件代碼發生衝突。需要注意的是，事件僅在一次開關機迴圈內有效，在下一次開關機註冊的同一事件，很可能返回不同的 AEEEvent。如果提供了指向 pnCount 的指標，則更新事件被註冊的次數。事件通過

AEE層 支援通知的概念，通知是一種當其它應用中發生某些差錯時可以為該事件註冊不同應用來處理的機制。例如，可以將應用註冊為在有進入的 SMS 訊息時接收通知。這表示只要有進入的 SMS 訊息，登入接收通知的應用就會收到一個事件，這個事件就是 EVT_NOTIFY。通知程式就是產生通知的應用，例如： ITAPI 可充當通知程式，在有進入的 SMS 訊息時就會發會通知。每當通知程式需要發送通知時，都要使用 ISHELL_Notify() 方法。 應用可以通過註冊來接收通知，要這樣做，一般要使用函數

在認證過程中，需要完成以下幾步：開發商完成線上申請，網址是http://www.verisign.com/products/BREWVeriSign校正簽名中心寄送電子郵件給應用開發商，郵件內容包括定單號和對應用方案的一個真實檔案數字ID的確認請求。同時，VeriSign校正簽名中心開始對開發商進行認證工作（這部分工作通常需要5個工作日）。認證通過之後，一封電子郵件會被發送到線上申請表上指定的開發商的公司聯絡處地址。這封電子郵件提供了安裝真實檔案數字ID的說明。開發商在安裝了真實檔案數字ID後，

電訊廠商可以配置是否需要原始卡來刪除某個應用(即永久刪除而不是暫停使用)。如果電訊廠商讓OEM廠商將配置成允需任何卡都可以刪除某個應用，則丟失卡後重換新卡的使用者就能夠刪除、重新下載並有效地將應用所有權變更給新卡。當然，這些下載會對新RUIM卡使用者產生新的應用費用和資料流量費用。使用者會喪失原卡上剩餘的應用使用權，而且不能再使用原有的應用，因為這些應用以為新RUIM卡使用者所有。當然，如果電訊廠商的分發系統支援信用召回（Credit

在基於BREW的移動增值業務開發中，遵循一定的開發原則有助於避免發生常見的錯誤，並可將測試、調試和重寫原始碼所需的時間量降至最低，提高系統的開發效率。通過研究和執行這些指導原則，可以將從Windows轉換至ARM架構的時間總量降至最低，並使應用程式儘可能在行動裝置上正常運行。這些開發原則如下所示:(1)執行NULL指標檢查。建立BREW介面執行個體時必須檢查NULL指標，如果指標有誤，則該介面將無法使用。檢查已指派記憶體所傳遞和返回的所有指標，以確保其有效性。無效指標應使用異常處理機制進行處理。

實際上，事件傳遞本質上就是一種共用記憶體的通訊方式。ICLIPBOARD可以用於實現 AEE 層中的剪下和粘貼功能，是共用記憶體通訊的另一種重要形式。由於剪貼簿資料在應用程式結束後仍可能存在，因而此函數會分配新記憶體並將內容複寫到新的緩衝區，也就是說ICLIPBOARD_Set() 分配的記憶體在系統記憶體裡，所以可以被其他的應用所使用。如果傳遞指標為 NULL 或大小為 0

上面講到，IFIFO實際上就是一個檔案，而且共用檔案，即共用駐留資料也是BREW應用間通訊最簡單的一種方式。BREW中有三種駐留資料的方式：系統儲存，檔案和資料庫。系統儲存是指通過ISHELL_SetPrefs()和ISHELL_GetPrefs()來實現駐留資料的方法。ISHELL_SetPrefs()和ISHELL_GetPrefs()提供了一種方法來儲存包含或讀取應用或類層級首地址的資料結構，相當於VC裡面的序列化，使用起來非常簡便，資料由整個AEE層共用。通常在手機上還存在shared這