翻譯未完: Hopper 食譜-按步就班指令教學,增進你的應用程式穩定度

Hopper 食譜-按步就班指令教學,增進你的應用程式穩定度

這份文件意圖對於在Windows Mobile平台上的應用程式開發者去介紹Hopper的應用。藉由Hopper 去偵測,潛伏在你的應用程式中的各種例外狀況、當掉與死結等問題,尤其是被標準測試步驟所忽略的,與被客戶認定或是實機應用測試中的裝置當機情況。這份介紹包含所有必要的內容,告訴你如何透過使用Hopper的進階技術,開始測試應用程式穩定度。

目的

這份文件的目的是教育ISV(獨立軟體廠商)們在Hopper上,如何去增進應用程式的品質與穩定度。發展時如果使用Hopper可以減少客戶的驗證時間,並找到更多應用程式的錯誤,將助於提供一個非常優良品質的應用程式給顧客。 而預期中獨立軟體開發商們的步驟應該是

  1. 在發展週期中持續的使用hopper,區分臭蟲到下面三種
    1. 獨立軟體廠商本身應用程式的臭蟲
    2. 原始裝置製造商的裝置問題(向原始裝置製造商反應去解決臭蟲,假設可能的話)
    3. Windows Mobile本身的問題 (向微軟反應,去進行評估與可能解決)
  2. 分別去協調設備的原始生產商與微軟(假設可能的話),去安全的解決臭蟲,來保證軟體應有的穩定度。
  3. 在裝置的Windows Mobile設備發展週期中,持續的執行Hopper,與個別的裝置製造商們進行協調(假設可能的話)

獨立軟體廠商們,依照以下的方式,將可以很高興的增進應用程式的品質與穩定度。Hopper掌控了原本依靠猜測的品質量度工作,進而縮短了產品上市的時間。

預先準備

這份文件建立在已經發佈給OEM與ISV們的資料上,強烈的建議在繼續之前先閱讀過下列文章

  1. Hopper for ISV’s – part I (http://blogs.msdn.com/hopperx/archive/2006/06/05/618018.aspx)
  2. The Cat Parade (http://blogs.msdn.com/hopperx/archive/2005/11/30/498113.aspx)  (譯註: The Cat Parade, 作者是引申,讓一隻貓乖乖參加遊行,是非常困難的一件事,這篇文章提到的也是如何讓Hopper去專注在一個應用程式上)
  3. Improving the Cat Parade (http://blogs.msdn.com/hopperx/archive/2006/11/21/improving-the-cat-parade-part-1.aspx)

在Hopper博士部落格上,有許多資料並經常性的更新給ISV們的特定資訊,所以建議ISV們經常的檢查這部落格首頁(http://blogs.msdn.com/hoppeRx/)。這份文件是假設你已經安裝好了VisualStudio 2005 與 Windows Mobile 6 SDK。

檢視-Hopper系統的概觀

在Hopper for ISV’s 文章中,提及Hopper是一個穩定性測試工具,它隨機的模擬送出按鍵與螢幕拖曳給裝置。Hopper是設計對整個裝置進行壓力測試,而不是針對單一應用程式。然而應用程式開發者對與整機的穩定度測試並不感興趣,他們想要的是,可以專注找出他們本身應用程式錯誤的測試,要達成這個目標,需要一個方法去讓Hopper聚焦在他們應用程式上,使Hopper花費最少的時間測試他們的應用程式。

要成功將穩定度測試使用Hopper,三個元素是必須的

Hopper 在你的SDK 工具目錄中,一個簡單的focusApp範例同樣存在hopper 工具目錄中,你需要針對每個要測試的應用程式去客制化它,進行測試需要完成下列步驟。

  1. 使用VisualStudio 去發佈你的程式到裝置或是模擬器中,並且連結上除錯器。這將使你能針對任何意外或是你應用程式當機時去除錯。關於如何去做這些步驟可以參考示範段落。
  2. 客制化focusApp.exe 的原始檔去保持你的應用程式在前景,參考部落格文章“The Cat Parade”可以得到更多的資訊與想法。客制化並發佈到裝置與你的應用程式。
  3. 當你的應用程式執行時,發佈Hopper到裝置並執行,focusApp.exe會強迫Hopper"針對"你的應用程式進行測試,並避免系統待機。

透過合併這三個元素,我們可以移除系統穩定度的問題,讓Hopper只作用在我們的應用程式上,並且找出可能的潛在問題。在範例中,假設你進行這個測試已知有了穩定度問題的裝置上,則Hopper不大可能會遇到那些問題,因為你的應用程式將處理所有按鍵輸入,它是一個非常省事,用來發現你所感興趣應用程式臭蟲的方法,而不會受系統其他問題影響。

示範 – 看Hopper工作並找到真實的臭蟲

(操作步驟 留到下次 July 14 2007)

待續


The Hopper Cookbook (Step-by-step instructions to improve application stability)

The intent of this document is to introduce Hopper to the application developer who is targeting applications for the Windows Mobile platform. The purpose of running Hopper against your application is to find exceptions, hangs and deadlocks that may be lurking in your application that may go unnoticed during testing and may cause device crashes during customer acceptance or field trials. This introduction will include all the necessary materials to begin Stability testing of your application using Hopper as well as pointers for advanced techniques.

Goals

The goal of this document is to educate ISV development community on Hopper so they can improve application quality and stability. Developing with Hopper, ISV’s will reduce customer acceptance time as well as find more application bugs that will contribute to the overall quality of their application. The expected steps from the ISV community are:

  1. Consistently run Hopper during the development cycle and sort the bugs into three categories:
    1. Category #1: ISV application dependent bugs (to be fixed by the ISV)
    2. Category #2: OEM device dependent bugs (to be reported to the respective OEM for fixes, if applicable)
    3. Category #3: WM dependent bugs (to be reported to Microsoft for evaluation and possible fixes)
  2. Coordinate with both the respective OEM and Microsoft (if applicable) to secure bug resolutions and proper application stability
  3. Run Hopper during WM device development by coordinating with their respective OEMs (if applicable)

The ISV development community following the above process will enjoy improved application quality and stability. Hopper takes the guesswork out of quality measurement, thus reducing application time to market.

Prerequisites for this document

This document builds upon existing materials published for the OEM and the ISV development community. It is highly recommended that the reader review the following topics before reading this document:

  1. Hopper for ISV’s – part I (http://blogs.msdn.com/hopperx/archive/2006/06/05/618018.aspx)
  2. The Cat Parade (http://blogs.msdn.com/hopperx/archive/2005/11/30/498113.aspx)
  3. Improving the Cat Parade (http://blogs.msdn.com/hopperx/archive/2006/11/21/improving-the-cat-parade-part-1.aspx)

The Hopper Doctor blog, which contains the above materials is updated frequently and often contains ISV-specific information, so it is recommended that ISVs check the main blog page (http://blogs.msdn.com/hoppeRx/) frequently. This document also assumes the reader has Visual Studio 2005 and the Windows Mobile 6 SDK installed.

Review – and overview of the Hopper system

As mentioned in the Hopper for ISV’s blog, Hopper is a stability test tool that randomly sends keystrokes and screen taps to the device. Hopper is designed to stress the entire device and not remain in a single application. However, application developers are not interested in stability of the entire device– they want to locate and fix bugs only in THEIR application. To achieve this, ISVs need a way to focus Hopper on their application and to minimize the time Hopper spends away from their application.

To successfully perform stability testing with hopper, three elements are needed:

The Hopper component is available under your SDK tools directory. A sample focusApp.exe is provided in the same Hopper tools directory and will need to be customized for each application you are testing. To begin testing, you need to perform the following steps:

  1. Using Visual Studio, deploy your application to a device or the device emulator and attach the debugger. This will enable you to debug any exceptions or hangs that your application encounters. Step-by-step instructions on how to do this are located below in the section labeled Demo.
  1. Customize the focusApp.cpp source to keep your application in the foreground. Refer to “The Cat Parade” blog entry for more information as well as the end of this document for more ideas. Once customized, this tool needs to be deployed to device and your application
  1. Deploy and run Hopper while your application is running. The focusApp will force Hopper to remain “focused” on your application and avoid the rest of the system.

By combining these three elements, we are able to remove platform stability from the equation and allow Hopper’s effort to be focused on your application and away from other potential problems. For example, if you are running this test on a device that has known stability issues, it is unlikely that Hopper will encounter those issue because your application is processing all the key strokes. This is very convenient since it is the application bugs that you are interested in, not the bugs elsewhere in the system.

Demo – Watch Hopper in action and find real bugs!

Below represents a step-by-step procedure for running Hopper on a sample application that is included in the SDK. Ultimately you will want to proceed through the following steps using the application you are developing and not CECamera.

Step 1: Launch Visual Studio. Launch the SDK tools folder from the start menu and navigate into the Hopper Folder and then again into focusApp folder. Double click on this solution to bring up VS.

Step 2: Customize focusApp. We need to customize focusApp to point to the application under test. For this sample, open the file FocusApp.cpp and replace the “\Windows\WMPlayer.exe” with “\Program Files\CECamera\CECamera.exe”. Rebuild the solution. When testing your own application, you will replace the CECamera path and filename with the path and filename of your application

Once this application has been rebuilt – you can close this solution.

Step 3: Launch the CECamera solution provided under the Samples folder – this is the application we will torture under hopper.

Navigate to the CECamera directory under the following directory: SamplesCommonCPPWin32CECamera – double click on this CECamera solution to re-launch Visual Studio with this solution active.

Step 4: Add Hopper dependencies to your deployment.

Change the Project properties to automatically deploy your focsuApp.exe and Hopper.exe. Under the menus Project->Properties, select Configuration Properties -> Deployment and add the following lines to the existing:

focusApp.exe|C:Program FilesWindows Mobile 6 SDKtoolshopperfocusAppFocusApp$(OutDir)|||0

hopper.exe|C:Program FilesWindows Mobile 6 SDKtoolshopper|||0

Please note that your Path locations may be different from the example, and care must be taken to copy & paste the correct paths. When this is complete, your dialog should look similar to:

Test your deployment. Using the menu action Build -> Deploy solution, check the results of your deployment, you should see:

1>—— Deploy started: Project: CECamera, Configuration: Debug Windows Mobile 6 Professional SDK (ARMV4I) ——

1>C:Program FilesMicrosoft Visual Studio 8VCcedllARMV4Imsvcr80.dll

1>C:Program FilesMicrosoft Visual Studio 8VCcedllARMV4Imsvcr80d.dll

1>C:Program FilesWindows Mobile 6 SDKtoolshopperfocusAppFocusAppWindows Mobile 6 Professional SDK (ARMV4I)DebugfocusApp.exe

1>C:Program FilesWindows Mobile 6 SDKtoolshopperhopper.exe

1>c:Program FilesWindows Mobile 6 SDKSamplesCommonCPPWin32CECameraWindows Mobile 6 Professional SDK (ARMV4I)DebugCECamera.exe

========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

========== Deploy: 1 succeeded, 0 failed, 0 skipped ==========

You will note that the Device Emulator will launch in the background and fully boot before copies can begin. If there are any errors during deployment, please check your pathnames above to make sure you are pointing to the correct locations. You must be able to copy & paste the full paths and reference the binaries. Please correct any mistakes before continuing.

Step 5: Close off exit points.

If your application responds to WM_CLOSE to exit, we need to ignore this command so Hopper does not close the application. CECamera sample contains both a menu item and an “X” box that will sent a WM_CLOSE to the app – so we need to comment out this code. Locate the CECamera.cpp file and search for WM_CLOSE like below:

case IDCANCEL:

// Fall through

case IDM_EXIT:

// PostMessage(hwndDlg, WM_CLOSE, 0, 0); ** Comment out this line **

break;

Step 6: Start debugging the CECamera.exe application.

Before we begin debugging we need to verify the debugger will detect and break when an exception is hit. Menu Debug -> Exceptions will bring up the following dialog – make sure all thrown check boxes are checked and your settings saved.

Next, Select the menu Debug -> Start Debugging to deploy and debug CECamera. This will launch the application under test and if you switch back to Device Emulator, you will be presented with the sample application.

Step 7: Launch the Hopper and focusApp.

In this step, we need to access the File Explorer so we can launch focusApp and then Hopper.

Click on the Start Menu, select Programs and then File Explorer.

Navigate UP to the root directory and select focusApp.exe – this will launch focusApp.exe which will quickly bring CECamera back to the foreground.

Bring the File Explorer back by clicking the Start Menu -> File Explorer. Use this opportunity to launch Hopper.exe.

If you wait too long, focusApp will bring the CECamera application back to the foreground and obscure File Explorer. Simply Bring the File Explorer back by clicking the Start Menu -> File Explorer and click on Hopper.exe. This tight-timing is expected and part of the design.

In a moment, Hopper will take over your system and begin pressing keys and tapping on the screen. Once Hopper encounters an exception in your application, Visual Studio will break and you will be notified.

How to debug breaks

Having Hopper focus on your application is only useful if it finds exceptions, hangs or deadlocks. Hopper’s job is to identify these bugs and it is left to the developer to actually find and fix the root cause for any break The Hopper Doctor Blog (http://blogs.msdn.com/hoppeRx/) is a great resource for how to debugging exceptions, hangs and deadlocks found by hopper.

Since Visual Studio is an application debugger you will notice that Hopper will continue stressing the device after your application has broken into the debugger. You will also note that focusApp.exe continues to run and will continue trying to bring your application to the foreground.

This is normal and should not interfere with debugging the break that stopped Visual Studio.

Published Wednesday, June 06, 2007 5:53 PM by shende

Filed under: cat parade, ISV, focusApp

廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s

%d 位部落客按了讚: