【正文】 模塊是應(yīng)用了四個本本框，中間一塊專輯及歌曲顯示的模塊是屬于一個自定義模塊 播放音軌SeekBar播放器最重要的一部分就是音軌與歌曲進度同步的實現(xiàn)。()，參數(shù)傳入歌曲的長度。Android的線程的開始是通過Handler類來進行的，Handler類是線程與線程之間通信的橋梁，實現(xiàn)Runnable接口會實現(xiàn)里面的run方法，當(dāng)線程開始的時候，Runnable中的run方法會向Handler發(fā)一個Message消息，這樣，Handler類就可以接收到run方法發(fā)送過來的不同的消息進行不同的代碼處理。要啟動一個線程調(diào)用Handler的方法postDelayed(Runnable，1000)表示線程睡眠時間是1000ms 。對音軌進行刷新。這也是進度條上的游標(biāo)會不停的移動和歌詞時間會不停的變動的原因。用的是布局中的線性布局LinearLayout。LinearLayout中依次放置播放/暫停，上一首、下一首按鈕屬性。該接口在執(zhí)行行需要一個數(shù)據(jù)源，通過如下步驟：第一步：()。第二步： 傳入歌曲數(shù)據(jù)源，(String path)。第三步：準(zhǔn)備播放數(shù)據(jù)源，()。播放數(shù)據(jù)源，該數(shù)據(jù)源播放后，不再與程序有關(guān)，()()。 歌詞顯示界面當(dāng)播放音樂文件時，如果同時存在該歌曲的LRC格式的歌詞文件時，系統(tǒng)會自動匹配歌詞并且達(dá)到同步顯示的效果。如果是則提示，進度條+歌詞滾動，進度條更新部分在updatesb方法。歌詞滾動部分runnabel。 列表顯示界面歌曲列表整體采用了相對布局(RelativeLayout)，中間歌曲列表部分采用的是ListView視圖，以確保有大量歌曲時能滾動式容納所有歌曲。 專輯列表 在Android里面，有一個視圖叫ListView，其特點是一個有BaseAdapter的屬性，從下到下，或從左到右的顯示方式。我們定義一個類MusicAdapter 繼承了BaseAdapter，然后通過算法對這個適配器進行擴展，擴展成為第一行能顯示一張圖片和一個歌曲名字。該方法返回一個View，即視圖。ListView同樣有一個監(jiān)聽器new onItemClickListener(){Override public void onItemClick(AdapterView? arg0, View arg1, int arg2,long arg3) {}}，我們只要實現(xiàn)這個方法，就可以監(jiān)聽鼠標(biāo)的點擊事件，當(dāng)鼠標(biāo)點擊到每一行時，(int position)得到該行上的信息。 菜單設(shè)置界面菜單主要分3個模塊：常用、工具、其他默認(rèn)彈出時在常用目錄下，在常用里有一個退出程序按鈕，用戶點擊可以退出系統(tǒng)，點擊確定按鈕則程序在該設(shè)定時間后停止播放，點擊日/夜模式設(shè)置可以調(diào)節(jié)屏幕的明暗度。 播放器的這個日/夜模式設(shè)計實際上就是改變屏幕的明暗度，通過獲取系統(tǒng)當(dāng)前屏幕的設(shè)置明暗度來進行改變，當(dāng)系統(tǒng)為亮?xí)r程序會自動更改系統(tǒng)設(shè)置視屏幕變暗，當(dāng)程序為為暗時則會使屏幕變亮。335 音樂播放器的測試一個軟件產(chǎn)品或系統(tǒng)的開發(fā)成功，不僅僅是編寫完為使用者提供服務(wù)功能的程序而已。與程序的開發(fā)相配合的、具有同樣重要性的另一半工作，是對開發(fā)完畢的軟件所進行必要的測試。你可以花費巨大的資源和努力進行程序的開發(fā)，可是你要是沒有與此配套的完善的測試，所開發(fā)出來的軟件往往會因為質(zhì)量問題無法滿足客戶的要求和幫助你贏得市場的競爭。但是忽視或輕視測試工作的不良習(xí)慣和企業(yè)文化仍舊普遍存在。 前面講述了測試對軟件開發(fā)的重要性。測試的目的有兩個：第一是要確證這些為用戶解決某些問題的功能設(shè)計被正確無誤地開發(fā)出來了，也就是說，如果用戶按照所設(shè)計的使用方法和過程（我們稱為User Scenario，即使用方案），的確能夠利用這些功能所提供的服務(wù)和解決問題；第二是保證軟件在被使用的情況下，如果使用者并不按照所設(shè)計的使用方案在使用軟件，它不應(yīng)該由于任意的使用、或其它外部影響造成任何問題，包括出現(xiàn)差錯，比如數(shù)據(jù)遺失、數(shù)據(jù)錯誤、甚至造成系統(tǒng)崩潰等等。為達(dá)到第一個目的、也是最主要的目的，最佳的方法是根據(jù)所設(shè)計的每個功能和使用方案，設(shè)計一個相對應(yīng)的測試執(zhí)行過程，去驗證這個功能或使用方案是能夠從頭到尾完成的。要能夠確證所有功能的確是準(zhǔn)確地被丌發(fā)出來了，唯的辦法就是為每一個使用方案都設(shè)計出大量的、一套完整的測試案例，然后通過對這些測試案例的按部就班的執(zhí)行來證明軟件的確可以完成所設(shè)計的功能。 測試模型 V模型V模型最早是由Paul Rook在20世紀(jì)80年代后期提出的，旨在改進軟件開發(fā)的效率和效果。從左到右描述了基本的開發(fā)過程和測試行為，非常明確的標(biāo)注了測試過程中存在的不同類型的測試，并且清楚的描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系。但V模型存在一定的局限性，它僅僅把測試作為在編碼之后的一個階段，是針對程序進行的尋找錯誤的活動，而忽視了測試活動對需求分析、系統(tǒng)設(shè)計等活動的驗證和確認(rèn)的功能。W模型由兩個V字型模型組成，分別代表測試與開發(fā)過程，圖中明確表示出了測試與開發(fā)的并行關(guān)系。W模型有利于盡早地全面的發(fā)現(xiàn)問題。同時，對需求的測試也有利于及時了解項目難度和測試風(fēng)險，及早制定應(yīng)對措施，這將顯著減少總體測試時間，加快項目進度。在w模型中，需求、設(shè)計、編碼等活動被視為串行的，同時，測試和開發(fā)活動也保持著一種線性的前后關(guān)系，上一階段完全結(jié)束，才可正式開始下一個階段工作。對于當(dāng)前軟件開發(fā)復(fù)雜多變的情況，W模型并不能解除測試管理面臨著困惑。而W模型在這一點上進行了補充，明確指出應(yīng)該對需求、設(shè)計進行測試。在實際測試工作中我們應(yīng)該盡可能地區(qū)應(yīng)用各模型中對項目有實用價值的方面，不能強行的為實用模型而實用模型。因此這著就導(dǎo)致了，我們在開發(fā)的初期階段就對需求定義進行了多次的更新。綜合以上考慮，我們采用的測試方法是：以W模型作為框架，及早的、全面的開展測試。 白盒測試已知產(chǎn)品的內(nèi)部工作過程，可以通過測試證明每種內(nèi)部操作是否符合設(shè)計規(guī)格的要求，所有內(nèi)部成分是否已經(jīng)檢查，該測試方式稱之為白盒測試。白盒測試的前提是可以把程序看成裝在一個透明的白盒子里面，也就是完全理解程序結(jié)構(gòu)和處理過程，這種方法按照程序內(nèi)部邏輯測試程序，檢驗程序中每條通路是否按預(yù)定要求正確工作。 (2) 對多有的邏輯判定，取“真”與取“假”的兩種情況都能至少測試一次。 黑盒測試 已知產(chǎn)品的功能設(shè)計規(guī)格，可以進行測試證明每個實現(xiàn)了的功能是否符合要求，這種測試方式稱之為黑盒測試。黑盒測試法把程序看成一個黑盒子，完全不考慮程序內(nèi)部結(jié)構(gòu)和處理過程。使用黑盒測試法，主要是發(fā)現(xiàn)以下幾類錯誤：(1) 是否有不正確或遺漏的功能。(3) 是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息訪問錯誤。(5) 是否有初始化或終止性錯誤。白盒測試的工作主要由軟件開發(fā)人員在編碼之后自行對所編代碼完成測試。 功能的測試與實現(xiàn) 播放器整體功能的實現(xiàn)， 播放器運行界面圖 播放器整體功能，主要是針對播放器的播放功能，上一首，下一首選擇及媒體格式的支持等， 測試內(nèi)容 測試結(jié)果播放控制能正確的完成播放、暫停、進度條的拖動功能格式支持支持MP3格式上、下首歌曲的選擇能正確的選擇“上一曲”，“下一曲” 播放器整體功能測試結(jié)果 播放器主要模塊功能測試播放器的主要模塊功能測試，主要是對用戶圖形界面模塊，歌詞同步顯示模塊等功能進行了測試。 測試過程與總結(jié) 依據(jù)傳統(tǒng)的方法，將系統(tǒng)測試作為軟件丌發(fā)的一個階段，系統(tǒng)測試執(zhí)行工作將在系統(tǒng)開發(fā)完成后開展，很明顯，這樣做不利于BUG的及時暴露。 我們依據(jù)“全過程測試”的測試?yán)砟睿诒鞠到y(tǒng)中我們將軟件的開發(fā)和軟的測試緊密的結(jié)合在一起，要求要充分關(guān)注開發(fā)過程，對開發(fā)過程的各種變化及時做出響應(yīng)。實踐證明，這種做法起到了預(yù)期的效果，與設(shè)計過程緊密結(jié)合的測試過程，有效的于早期發(fā)現(xiàn)了許多系統(tǒng)缺陷，降低了開發(fā)成本，同時也使基于復(fù)雜開發(fā)模型的測試管理工作更加清晰明了。對需求的把握很大程度上決定了軟件測試是否能夠成功。不但一起討論需求的完善性與準(zhǔn)確性，同時從可測試性角度為需求文檔提出建議。同時，結(jié)合前期對項目的把握，很容易制定出了完善的測試計劃和方案，將各階段產(chǎn)品的測試方法及進度有條不紊進行下去。 本章小結(jié)軟件測試的目的，第一是確認(rèn)軟件的質(zhì)量，其一方面是確認(rèn)軟件做了你所期望的事情，另一方面是確認(rèn)軟件以正確的方式來做了這個事件。再次軟件測試不僅是在測試軟件產(chǎn)品的本身，而且還包括軟件開發(fā)的過程。因此軟件測試的第三個目的是保證整個軟件開發(fā)過程是