【導讀】隨著移動平臺的崛起，越來越多的傳統(tǒng)PC軟件被移植到移動平臺，比如ipad，額，所以為Android用戶開發(fā)滿足日常使用的軟件成為了現(xiàn)在的一大熱門。也可以做定時提醒。

　　

【正文】 s 日程信 息表 序號 列名 數(shù)據(jù)類型 主鍵 說明 1 _id int 是 2 hour int 小時 3 minutes int 分鐘 4 Noticedate varchar 提醒日期 5 Alarmtime 提醒時間 6 Enabled int 是否啟用 7 Vibrate int 是否震動提示 8 message varchar 事項文本 24 6 個人 日程管理 系統(tǒng)實現(xiàn) 本章介紹本系統(tǒng)的各個模塊的設計和實現(xiàn)。首先在 Eclipse 中配置好 ADT 和Android SDK 等開發(fā)環(huán) 境，然后新建一個 Android 項目，項目名為 LifeMemoPro，然后在 Android 項目中的 文件中配置本軟件需要使用的權限。 日程安排界面實現(xiàn) 在該界面中，用戶可以看到所有的事務事項信息。系統(tǒng)通過 ListView 組件來顯示所有的事務事項性信息，每一個 Item 都包括是否啟用按鈕、提醒時間、循環(huán)周期和提醒事項。 該界面的頂端是通過 RelativeLayout、 Button 和 TextView 這三個常用的組件來實現(xiàn)的， RelativeLayout 用來做布局， Button定義了添加事務錄的入口按鈕，而TextView 則指定了本系統(tǒng)的標題。 用戶可以通過左邊的啟動按鈕來啟動或者停止一個提醒事項，如果事項被設置成關閉提醒后，即使時間到了系統(tǒng)也是不會提醒的，直到用戶啟動該項事務提醒為止。 左邊的啟動選項是通過一個 ImageView 和 Checkbox 組件來實現(xiàn)的。通過指定 ImageView 的 Src 屬性來為圖片設置資源，而 Checkbox 則是通過設置其background 屬性來控制其顯示的圖片，從而標識當前是否為勾選狀態(tài)。 Item 的右邊顯示了提醒的時刻和提醒事項。提醒事項名稱為 用戶在添加鬧鐘的時候輸入的。 用戶可以單擊一個日程事項來打開上下文菜單，菜單中包括停止提醒、修改和取消提醒三個選項。 同時，用戶可以通過該界面左上角的“添加”按鈕來打開日程提醒添加界面。具體的實現(xiàn)效果如圖 所示。 25 圖 日程 消息界面 日歷功能實現(xiàn) 日歷界面顯示了當前月的日歷信息，包括月份、日期和對應的周信息。用戶可以同“上一月”和“下一月”按鈕來控制日歷的顯示信息。例如點擊“上一月”按鈕日歷可以返回到上一月的日期。 該界面采用一張背景圖片來標識各個日期單元格和周信息，并通過繼承至ImageView 來實現(xiàn)日歷的繪制。 日歷的每個單元格都是采用 Rect 來繪制的。在 Java 中 Rect 表示了一個矩形，我們可以將其結合 Paint 來繪制一個單元格并且在單元格中繪制文本。繪制文本的工作是交給 Paint 來完成的。繪制文本時，我們通過 Paint 對象的 setTextSize 方法來設置文本的大小，并通過其 setColor 和 setFakeBoldText 方法分別來指定字體的顏色和是否為粗體。 另外，當用戶在屏幕上點擊一個日期后，我們通過 CalendarView 對象的相關方法來或者用戶點擊的是哪個日期，并在屏幕 的下方顯示對應的日期。 具體的實現(xiàn)效果如圖 所示。 26 圖 日期查找功能實現(xiàn) 添加事務模塊實現(xiàn) 在該界面里涉及到了 Android 中的一種重要 Activity，即 PreferenceActivity，該類型主要用來做設置界面使用。本界面通過繼承至 PreferenceActivity 來實現(xiàn)各個選項的填寫和輸入操作，同時，涉及到的 Android 組件包括 CheckBox 和 Button等等。 在該界面中，用戶可以添加新的事務提醒信息。添加時，用戶需要選擇時間、提醒循環(huán)類型；同時用戶可以選擇提醒的 鈴聲和選擇是否震動手機提醒；最后用戶可以輸入提醒事項的名稱。當然這個名稱也可以不輸入。當用戶輸入后該事項名稱將會被顯示在我的事務記錄里。 用戶可以通過最上方的“啟用日程管理”復選框來開啟或者關閉這個提醒事項。當各項輸入完畢后 ,用戶可以通過左下角的“完成”按鈕來提交數(shù)據(jù)。 具體的實現(xiàn)效果如圖 所示。 27 圖 添加 日程 界面 鬧鐘提醒功能實現(xiàn) 當手機時間到了鬧鐘設置的時間時 ,系統(tǒng)自動會啟動鬧鐘來提醒 ,提醒是系統(tǒng)會根據(jù)設置來判斷是否需要震動手機，也會根據(jù)用戶設置的不同提醒聲 音播放不同的提醒聲 ,如果用戶添加事項事務的時候沒有選擇對應的提醒鈴聲 ,則系統(tǒng)會播放默認的提醒聲。 鈴聲提醒是通過在系統(tǒng)注冊一個 Receiver 來實現(xiàn)的 ,該 Receiver 繼承至BroadcastReceiver 并重寫了其 onReceive 方法 ,在該方法中我們可以處理業(yè)務邏輯 ,例如鈴聲提醒。鬧鐘提示截圖如下 所示。 28 圖 提醒界面 同時該 Receiver 需要在 全局文件中注冊： receiver android:name=AlarmInitReceiver intentfilter action android:name= / action android:name= / action android:name= / action android:name= / /intentfilter /receiver 29 7 系統(tǒng)測試與分析 軟件測試的重要性 軟件的測試在軟件生命周期中占據(jù)重要的地位，在傳統(tǒng)的瀑布模型中，軟件測試學僅處于運行維護階段之前，是軟件產品交付用戶使用之前保證軟件質量的重要手段。近來，軟件工程界趨向于一種新的觀點，即認為軟件生命周期每一階段中都應包含測試，從而檢驗本階段的成果是否接近預期的目標，盡可能早的發(fā)現(xiàn)錯誤并加以修正，如果不在早期階段進行測試，錯誤的延時擴散常常會導致最后成品測試的巨大困難。 事實上，對于軟件來講，不論采用什么技術和什么方法，軟件中仍然會有錯。采用新的語言、先進的開發(fā)方式、 完善的開發(fā)過程，可以減少錯誤的引入，但是不可能完全杜絕軟件中的錯誤，這些引入的錯誤需要測試來找出，軟件中的錯誤密度也需要測試來進行估計。測試是所有工程學科的基本組成單元，是軟件開發(fā)的重要部分。自有程序設計的那天起測試就一直伴隨著。統(tǒng)計表明，在典型的軟件開發(fā)項目中，軟件測試工作量往往占軟件開發(fā)總工作量的 40％以上。而在軟件開發(fā)的總成本中，用在測試上的開銷要占 30％到 50％。如果把維護階段也考慮在內，討論整個軟件生存期時，測試的成本比例也許會有所降低，但實際上維護工作相當于二次開發(fā)，乃至多次開發(fā)，其中必定還包含 有許多測試工作。 在實踐中，軟件測試的困難常常使人望而卻步或敷衍了事，這是由于對測試仍然存在一些不正確的看法和錯誤的態(tài)度，這包括 : (1)認為測試工作不如設計和編碼那樣容易取得進展難以給測試人員某種成就感； (2)以發(fā)現(xiàn)軟件錯誤為目標的測試是非建設性的，甚至是破壞性的，測試中發(fā)現(xiàn)錯位是對責任者工作的一種否定； (3)測試工作枯燥無味，不能引起人們的興趣； (4)測試工作是艱苦而細致的工作； (5)對自己編寫的程序盲目自信，在發(fā)現(xiàn)錯誤后，顧慮別人對自己的開發(fā)能力的看法。 30 這些觀點對軟件測試工作是極為不利的 ，必須澄清認識、端正態(tài)度，才可能提高軟件產品的質量。 軟件測試的目的 如果測試的目的是為了盡可能多地找出錯誤，那么測試就應該直接針對軟件比較復雜的部分或是以前出錯比較多的位置。如果測試目的是為了給最終用戶提供具有一定可信度的質量評價，那么測試就應該直接針對在實際應用中會經常用到的商業(yè)假設。 在談到軟件測試時，許多人都引用 Grenford J. Myers 在《 The Art of Software Testing》一書中的觀點 : (1)軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程； (2)測試是為了證 明程序有錯，而不是證明程序無錯誤； (3)一個好的測試用例是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤； (4)一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。 這種觀點可以提醒人們測試要以查找錯誤為中心，而不是為了演示軟件的正確功能。但是僅憑字面意思理解這一觀點可能會產生誤導，認為發(fā)現(xiàn)錯誤是軟件測試的唯一目，查找不出錯誤的測試就是沒有價值的，事實并非如此。 首先，測試并不僅僅是為了要找出錯誤。通過分析錯誤產生的原因和錯誤的分布特征，可以幫助項目管理者發(fā)現(xiàn)當前所采用的軟件過程的缺陷，以便改進。同時，這種分析也能幫助我 們設計出有針對性地檢測方法，改善測試的有效性。其次，沒有發(fā)現(xiàn)錯誤的測試也是有價值的，完整的測試是評定測試質量的一種方法。 軟件測試的方法 隨著 軟件測試技術 的不斷發(fā)展，測試方法也越來越多樣化，針對性更強；選擇合適的軟件測試方法可以讓我們事半功倍。 31 白盒測試 白盒測試，英文是 White Box Testing。又稱結構測試或者邏輯 驅動 測試。 白盒測試 是把測試對象看作一個打開的盒子。利用白盒測試法進行 動態(tài)測試 時，需要測試 軟件 產品的內部結構和處理過程，不需測試軟件產品的功能。 白盒測試 法的覆蓋標準有 邏輯覆蓋 、循環(huán)覆蓋和基本 路徑測試 。其中 邏輯覆蓋 包括 語句覆蓋 、 判定覆蓋 、 條件覆蓋 、判定 /條件覆蓋、 條件組合覆蓋 和 路徑覆蓋 。 白盒測試 是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規(guī)格說明書的規(guī)定正常進行，按照程序內部的結構 測試程序 ，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要 用于 軟件 驗證。 黑盒測試 黑盒測試 ，英文是 Black Box Testing。又稱 功能測試 或者 數(shù)據(jù)驅動測試 。 黑盒測試是根據(jù) 軟件 的規(guī)格對軟件進行的測試，這類測試不考慮軟件內部的運作原理，因此軟件對用戶來說就像一個黑盒子。 軟件測試人員 以用戶的角度，通過各種輸入和觀察軟件的各種輸出結果來發(fā)現(xiàn)軟件存在的缺陷，而不關心程序具體如何實現(xiàn)的一種軟件測試方法。 本系統(tǒng)測試用例 測試用例 1： 本 測試的目的是驗證系統(tǒng)最核心的事務提醒功能是否實現(xiàn)，首先給系統(tǒng)設置一個提醒事項，提醒時間為“ 11： 57”，提醒事項為“朋友生日”，并將其保存。 等待到系統(tǒng)的時間到了 11： 57 分鐘后觀察手機，可以得到以下截圖： 32 圖 提醒測試界面 由此可見，系統(tǒng)在預定的時刻提醒了，并且提醒的標題也跟設置的一致 ,所以系統(tǒng)的提醒功能是沒問題的。 測試用例 2： 首先給系統(tǒng)設置一個提醒事項，提醒時間為“ 11： 57”，提醒事項為“朋友生日”， :此時點擊鈴聲，出現(xiàn)手機數(shù)據(jù)庫中的各種鈴聲，截圖如下： 33 圖 鈴聲選取界面 由此可見，該軟件能夠連接到手機自帶的數(shù)據(jù)庫，調出系統(tǒng)自帶的鈴聲。與手機數(shù)據(jù)庫很好的連接起來。 測試用例 3： 測試備忘事件輸入框，輸入中文。截圖如下： 34 圖 備忘事件輸入 如圖所示，輸入框能夠輸入中文。用戶界面良好。 軟件測試的重要性 第一是確認軟件的質量，其一方面是確認軟件做了你所期望的事情（ Do the right thing），另一方面是確認軟件以正確的方式來做了這個事件（ Do it right）。 第二是提供信息，比如提供給 開發(fā)人員或程序經理的反饋信息，為風險評估所準備的信息。 第三軟件測試不僅是在測試軟件產品的本身，而且還包括軟件開發(fā)的過程。如果一個軟件產品開發(fā)完成之后發(fā)現(xiàn)了很多問題，這說明此軟件開發(fā)過程很可能是有缺陷的。因此軟件測試的第三個目的是保證整個軟件開發(fā)過程是高質量的。 35 8 總結與展望 總結 本次設計研究的是一個基于 Android 的個人事務錄管理系統(tǒng)系統(tǒng)，綜合應用了 Android SDK 、 SQLite、 Activity、 Service 和 receiver 等等知識 ,實現(xiàn)了 Android平臺的日歷功能、事項事務錄 添加、修改、停用和刪除功能，實現(xiàn)了事項提醒、自定義提醒鈴聲、是否震動提醒等等一系列功能，為用戶帶來較好的操作體驗，最大程度地避免忘記一些重要的事項。 從本系統(tǒng)的開發(fā)過程中，我受益匪淺。首先，我認識到了代碼規(guī)范的重要性，特別是在一些大型項目中，用到的函數(shù)可能有數(shù)百個，如果編寫的代碼不規(guī)范會給后期的檢查帶來極大的麻煩。而且完整的代碼測試也非常重要，有些錯誤可能在很久以后才能發(fā)現(xiàn)。其次，我意識到了軟件設計的重要性，原來接觸的項目往往是快速開發(fā)類型的，幾乎不需要在軟件的邏輯設計上花費太多時間，往往可以邊開發(fā)邊進行下 一步的設計。但是這一次我意識到做軟件設計很重要，當初一個設計沒注意，可能造成后來的編碼大