手機軟件測試

1、手機軟件測試簡介1、手機軟件測試背景我國的手機測試技術(shù)從總體上說屬于剛剛起步階段, 近幾年經(jīng)歷了從無到有的過程。 現(xiàn) 在的水平基本上能滿足手機測試的要求,但是同發(fā)達(dá)國家的先進(jìn)生產(chǎn)廠商的差距是全方位 的, 無論是從實現(xiàn)技術(shù)上, 流程的規(guī)范性與合理性, 還是從對測試概念的理解上都有相當(dāng)?shù)?距離。 又加上手機產(chǎn)業(yè)的巨大發(fā)展?jié)摿? 所以, 手機測試技術(shù)在我國手機開發(fā)行業(yè)中必將面 臨著更加激烈的競爭和強大的挑戰(zhàn)。測試伴隨在整個手機軟件開發(fā)的各個階段中。 測試的成功與否, 測試的覆蓋性好壞與測 試質(zhì)量的高低直接關(guān)系到手機軟件的可用性, 友好性, 可靠性。 直接影響到產(chǎn)品能否如期上 市, 關(guān)系到手機廠商的切

2、身利益與長期的市場競爭力。 可以說, 測試環(huán)節(jié)是手機軟件開發(fā)的 重要環(huán)節(jié),是整個開發(fā)過程的“中樞神經(jīng)” 。同時,測試用例的設(shè)計在測試過程中是非常重 要的一個環(huán)節(jié),是重中之重。2、測試用例的常見分類2.1 基本功能測試基本功能是指手機軟件向手機用戶提供的最小的、 可以進(jìn)行的所有簡單操作的集合。 對 基本功能的測試是指測試工程師在被測試的手機上進(jìn)行實際操作, 來驗證操作是否可行, 操 作的結(jié)果是否滿足設(shè)計的要求,如果不滿足,就要報告錯誤,由開發(fā)者來改正錯誤。具體的操作例如:接一個電話,打一個電話,發(fā)送一條普通短信,接收一條普通短信, 發(fā)送一條彩信,接收一條彩信,播放一首靜態(tài)音樂文件(mp3 ,播放

3、一段視頻文件,照一張 像片, 錄制一段錄像, 接收電子郵件, 用瀏覽器上網(wǎng)瀏覽網(wǎng)頁, 設(shè)置一個鬧鐘, 使用計算器, 通過藍(lán)牙接收數(shù)據(jù),等等。2.2 交互測試所謂交互測試是指當(dāng)手機不同的兩個或者多個功能之間有交互的時候, 對手機所應(yīng)該處 的狀態(tài)或者行為進(jìn)行測試, 被測手機的狀態(tài)或者行為應(yīng)該與需求設(shè)計中的要求相一致。 如果 有錯誤,同樣應(yīng)該由開發(fā)人員來進(jìn)行改正。具體的操作例如:打電話時接收短信息, 看短信內(nèi)容時候進(jìn)來一個電話, 聽音樂時候瀏 覽新短信, 聽音樂時候進(jìn)來一個電話,上網(wǎng)瀏覽時進(jìn)來一個電話, 接電話時候鬧鐘報警,等 等。2.3 臨界測試所謂的臨界測試是指當(dāng)手機的某些可用資源達(dá)到或者超過理

4、論允許的極大值時, 在手機 上繼續(xù)進(jìn)行某種操作時候的測試。 此時手機的行為應(yīng)該是友好的, 可被使用者接收的, 應(yīng)該 與需求分析的要求相符合。具體的操作例如:內(nèi)存滿時候撥打電話, 內(nèi)存滿時候啟動瀏覽器, 內(nèi)存滿時候啟動音樂 播放器, 數(shù)據(jù)庫滿時候撥打電話, 數(shù)據(jù)庫滿時候啟動瀏覽器, 數(shù)據(jù)庫滿時候啟動音樂播放器, 地址本滿時候繼續(xù)添加記錄,短信收件箱滿時候繼續(xù)收新短信,等等。2.4 壓力測試壓力測試一般是指在比較短的一段時間內(nèi), 被測手機執(zhí)行比較多的任務(wù)或者操作, 來檢 測被測手機承受壓力的能力。 具體的操作例如:在短時間內(nèi)發(fā)送大量的短信, 同時并接收大 量的短信,發(fā)送和接收的數(shù)量都在 50 條以

5、上。短信的群發(fā)(包括超長短信 ,查看接收和 發(fā)送的成功率,接通一個電話并且保持很長一段時間(大于 10 個小時 ,等等。3、測試用例設(shè)計注意事項對于測試用例的設(shè)計來說, 操作步驟的描述總體上要求盡量籠統(tǒng)化, 含糊化。 為了表述 一個概念或者操作, 不必具體說清楚怎么樣具體地完成這個操作, 只需一帶而過地說要進(jìn)行 什么操作即可。比如說,只需要說明“啟動計算器應(yīng)用” ,而不必說先進(jìn)到主菜單,再到某 某選項下面找到“計算器”之類的話。再比如,只需要說“接通一個電話,然后接收一條短 信” ,而不必說如何如何接通電話,如何從別的手機或者軟件發(fā)送一條短信。同時為了防止 測試工程師在執(zhí)行測試用例的時候不清楚

6、某些操作的具體實現(xiàn)方法, 還需要在相應(yīng)測試用例 的聯(lián)機幫助文檔中對可能引起混淆的操作或者比較籠統(tǒng)的描述做出進(jìn)一步詳細(xì)的說明。這樣的好處是測試用例沒有同十分具體的某一款產(chǎn)品綁定的太緊密。 在實際的商業(yè)模式 中, 經(jīng)常是同一個手機軟件平臺會衍生出一系列的不同產(chǎn)品。 這些產(chǎn)品的功能基本相同, 只 是具體的操作界面有所不同。 新開發(fā)的測試用例應(yīng)該是面向整個平臺, 而不是針對具體的某 一款產(chǎn)品的。 否則無形中會大大增加額外的勞動力。 所以無論從商業(yè)成本的考慮還是從開發(fā) 周期成本角度來說,開發(fā)針對平臺的測試用例無疑是最正確的選擇。其實, 為了能夠使開發(fā)出的測試用例能夠快速地被新來的測試工程師所理解和掌握,

7、 為 了能使這些測試用例有更多的可使用者, 也應(yīng)該盡可能地把對操作步驟的描述詳細(xì)化和具體 化,因為只有這樣,才能使測試用例更加通俗易懂,節(jié)省更多的新手的熟悉和適應(yīng)的周期。所以,這就需要找到一個“籠統(tǒng)”與“詳細(xì)”之間的平衡點,只有適當(dāng)?shù)卣莆樟嗽敿?xì)的 分寸與火候,才能使得測試用例具有更高的認(rèn)可度和質(zhì)量。4、測試過程中的注意事項(1高度的責(zé)任心是作為一個優(yōu)秀的測試工程師所必備的最基本素質(zhì),一個好的測試 工程師要對所測試的軟件負(fù)責(zé),對開發(fā)人員負(fù)責(zé),同時也是對自己負(fù)責(zé)。(2要有充足的耐心,因為有的問題需要多次反復(fù)的,甚至是令人煩躁的重復(fù)操作才 可能重現(xiàn)出來,只有有充足的耐心才能把錯誤揪出來,不讓一個錯誤

8、漏網(wǎng)。(3細(xì)心也是一個非常重要的基本要求,粗心大意肯定會漏掉很多很多的問題。(4保持對錯誤的敏感性,有的錯誤不是很明顯,也就是說同樣的現(xiàn)象,有的測試工 程師就會“視而不見” ,沒有認(rèn)為可能存在錯誤,而有的測試工程師就會意識到可能會有問 題存在。(5興趣是最好的老師,如果對測試工作有足夠的興趣,就能積極主動地發(fā)現(xiàn)很多別 人不容易發(fā)現(xiàn)的問題。 興趣也是可以培養(yǎng)出來的, 不斷總結(jié)自己發(fā)現(xiàn)的問題, 看到自己發(fā)現(xiàn) 的問題被改正過來,一點一滴成就感的積累可以培養(yǎng)對測試工作的興趣。(6自身的努力也是成為一個優(yōu)秀的程序員所必備的要求,盡量多學(xué)習(xí)測試的專業(yè)背 景知識, 多多了解軟件及硬件的結(jié)構(gòu)以及工作原理, 虛

9、心學(xué)習(xí)好的測試方法和技巧, 不斷積 累自己處理問題的能力及經(jīng)驗,肯定會成為一名好的測試工程師。mtk 手機游戲測試MTK 手機主要還是看各個第三方軟件設(shè)計公司的要求,若有需求文檔,那就 easy 了,但是 對于大多數(shù)做 MTK 的公司來說, 研發(fā)速度是第一位的, 所以一般沒有啥子需求文檔和設(shè)計文 檔的東東。測試 MTK 軟件,先要了解你們公司對于整個產(chǎn)品的定位。經(jīng)常老總都會說:“偶們要求做最 好的產(chǎn)品。 ”這是屁話,不可信也。根據(jù)產(chǎn)品的開發(fā)周期和第一個測試版本的穩(wěn)定性,判斷出產(chǎn)品最終投產(chǎn)的大概質(zhì)量水平標(biāo) 準(zhǔn),再根據(jù)定義好的標(biāo)準(zhǔn)選擇測試重心,執(zhí)行相關(guān)的測試。以斗地主為例:假設(shè)這個第三方軟件的研發(fā)

10、生命周期為 1個月, 測試人員 2人, 版本每周更 新一個。一周一個版本, 也就意味著每周的實際測試時間只有 3天 (剩 2天做回歸測試和版本集成等 工作 ,也就是說,測試總時間為 3*4*2*8=192人時偶們需要關(guān)注的測試內(nèi)容有:1、正確邏輯測試:斗地主正常測試,包括:牌的大小順序:3A;連子的大小邏輯以及比大小時的張數(shù)限制; 三帶一和三帶對的邏輯; 四張可以與其他形式的牌比較; 對王大于一切; 輸贏判斷和分?jǐn)?shù)計 算等等(還包括其他元素,比如虛擬人物發(fā)音、標(biāo)題畫面檢查等等2、錯誤邏輯測試斗地主錯誤測試, 包括:單張、 對子和三張互不能比較大小。 三帶非對 (兩個單張或三張等 ; 3、交互測

11、試開啟斗地主模塊時,與手機終端的主要功能進(jìn)行交互測試,主要包括(來電、短信、鬧鐘、 電量低提示、插拔耳機、插拔充電器、插拔數(shù)據(jù)線、藍(lán)牙數(shù)據(jù)接收等等4、性能測試次數(shù)測試:反復(fù)開啟 /關(guān)閉斗地主模塊;反復(fù)多次已用戶的使用角度,運行斗地主模塊(最 好找其他人試用 ;反復(fù)開啟 /關(guān)閉斗地主各個界面,比如主界面、積分排行榜界面等等。 時間測試:開啟斗地主功能后,長時間待機測試(有數(shù)字電源的話可以作為輔助工具 ;長 時間不間斷的測試斗地主功能(測試過程中不關(guān)閉斗地主模塊進(jìn)程小結(jié):由于時間較短,正確邏輯測試在每個版本都需要全部測試完, 2、 3、 4的測試內(nèi)容分 別在第 2、 3、 4版本測試。 至于性能測

12、試的內(nèi)容的可能消耗大量的時間, 可以再測試初期先 聯(lián)系好用戶測試(就在公司內(nèi)部找都可以,比如文秘、前臺等都可以 。還是不怎么清楚 LZ 項目組的測試工作的實際情況:項目測試工作總量 /(測試人員數(shù) *測試周期 、測試人員測試水平。所以只能提出一些籠統(tǒng)的建議, LZ 再根據(jù)實際情況進(jìn)行剪裁。 1、針對于穩(wěn)定性測試,可以將測試重心放到交互測試和性能測試上。2、對于 MTK 手機,目前官方只提供了一個 USB 同步軟件,但是其同步功能也僅限于電話本 和短信兩個模塊。對于自己集成的第三方軟件來說,沒有現(xiàn)成的測試工具。3、針對死機等嚴(yán)重故障的測試,可以從 3方面下手:1 、增強代碼走查,增加單元、集成或

13、灰盒測試(灰盒測試可能不實際,因為灰盒測試需要 開發(fā)測試組件,搭建測試環(huán)境 。針對 MTK 這種快速性開發(fā)模型,最有效可行的就是加強代碼走查和增加白盒測試內(nèi)容。當(dāng)然, 如果你們公司編碼不規(guī)范很混亂, 或測試人員不具備編碼能力, 就只能考慮放棄這部 分的測試,而著重進(jìn)行以下兩個方面的測試。2 、增大性能測試的有效工作時間總量(說白了, 就是增加性能測試的次數(shù),增長性能測試 的時間 。在進(jìn)行交互測試時, 增加交互測試的次數(shù)。嘗試使用更復(fù)雜的交換環(huán)境進(jìn)行測試, 比如,游 戲 +來電 +短信 +GPRS+MP3+鬧鐘 +備忘錄。3 、增加客戶測試內(nèi)容,尋找更多的友情客戶對試驗機進(jìn)行試用。小結(jié):增加測試

14、工作總量是提高產(chǎn)品穩(wěn)定性的最有效手段。復(fù)雜交互情況的測試有兩個好處:1、更快速的完成交互測試。比如需要測試 A 、 B 模塊與 C 模塊的交互測試,兩兩交互就有 4種情況(注意交互的時候需要考慮模塊啟動的先后順序 。實用 3個模塊交互的只需要測試 兩種即可:ABC 和 CAB 。剩余的 BAC 和 CBA 實用等價法可以省略不測。2、極限條件下終端出問題的幾率更高,如果極限條件可以正常工作,那么一般情況就不在 話下了。反之,若一般情況下終端正常,并不能證明極限情況下終端也正常。6255平臺已經(jīng)很穩(wěn)定了,根據(jù)以前偶們做 MTK 的經(jīng)驗,大多數(shù)死機和白屏的問題都是偶們 在研發(fā)過程中錯誤的修改了 M

15、TK 的源碼引入的。所以,最直接的辦法就是去了解你們的第三方軟件在調(diào)用 MTK 的時候主要做了什么改動。比如在終端顯示第三方軟件的界面、 啟動第三方進(jìn)程等, 都需要調(diào)用相關(guān)的 MTK 提供的 API , 如果能調(diào)查出主要使用的部分,可以進(jìn)行針對性的檢查。如果只想檢測死機 /白屏 /重啟 (其實 MTK 在發(fā)生致命錯誤時, 會自動啟動重啟功能 這些問 題,就只有性能測試、交互測試和用戶測試比較有效。如果性能和用戶測試都不能做,那么交互測試你可以選擇極限情況下的交互測試。6225支持的并發(fā):第三方軟件開啟時 +通話(來電 +SMS+MMS +MP3+鬧鐘(N 個,不過是依次 排隊運行的 +備忘錄(

16、N 個,其實和鬧鐘一樣 。交互測試時,最好將第三方軟件的每個界 面和功能(選擇啟動稍微長點的功能(1秒以上才具可測性 ,比如斗地主的每局完時統(tǒng)計 分?jǐn)?shù)的功能 都進(jìn)行交互測試。 如果時間不夠, 就選重要界面和用戶使用較多的功能作為測 試對象。最后,在 6225中值得關(guān)注的還有一點。它的 MMS 是后期集成的,不是 MTK 本身就有的,所 以,加強 MMS 與你所測試的第三方軟件的交互測試可以作為一個重點。建議你將你們做的軟件的界面和功能列一個優(yōu)先級列表, 這樣可以再有限時間內(nèi)選擇測試的 重點。 (沒時間,不重要的東東就不測了,簡單看一下就行。畢竟時間和測試質(zhì)量是成正比 的。 MTK 的快速開發(fā)模

17、型是這樣的,由于開發(fā)和測試周期短,產(chǎn)品出廠后肯定會存在問題的。其實,完全覆蓋 1, 2級缺陷的測試,其實際測試工作量與普通測試沒有區(qū)別,只是開發(fā)在 修改缺陷時,不會修改嚴(yán)重等級較低的缺陷而已。在 MTK 測試中, 有一個測試的偏門:收集用戶使用較多的功能點, 進(jìn)行仔細(xì)的測試,對于用 戶使用的少和無關(guān)緊要的功能點,簡單跑一遍就可以了。比如,1、在斗地主軟件中, “積分排行版”用戶使用次數(shù)較少,就可以簡單測試:隨意運行一次斗 地主程序,查看是否能正常儲存數(shù)據(jù)即可。2、在斗地主軟件中,用戶自定義用戶名功能對用戶來說可有可無,所以也可以進(jìn)行簡單測 試?？傊?想要節(jié)約測試工作量,就需要裁減測試內(nèi)容,還是

18、建議你做一個測試功能點的 list , 然后定義出優(yōu)先級。在有限的時間內(nèi),將測試工作重點放在優(yōu)先級高的功能點上。舉一個以前偶們用過的例子:比如有過 3個功能點,分別是 A 、 B 、 C ,優(yōu)先級也是依次降序 排列。測試版本計劃有 3個。每個版本測試周期只能夠完成 2個模塊的測試。偶們的測試策略為:在 3個版本中, A 都需要測試一次, B 在第二個版本測試。第三個版本 測試時,先回歸測試 B ,再功能測試 A ,最后根據(jù)用戶使用 C 時的習(xí)慣優(yōu)先級來測試 C ,如 果部分 C 功能點沒有測試,也不會再去關(guān)注。 (當(dāng)然,這是極限情況,一般來說 C 功能點還 是可以進(jìn)行至少一次的功能測試的,但是

19、偶們不會在 C 上做任何交互或性能測試產(chǎn)品出廠后出現(xiàn)問題是不可避免的, 這也不能全說是測試人員的問題。 你們公司產(chǎn)品的主要 問題還是集中在領(lǐng)導(dǎo)的策略上。 (不過領(lǐng)導(dǎo)出了問題后,往往都要找人背黑鍋的 “沒時間就沒產(chǎn)品質(zhì)量嘛”兄弟,你遇到的這種事情很常見的,只要是測試人員,遲早都會遇到的。不用太擔(dān)心,仔細(xì)思考問題的原因和改進(jìn)措施才是正道。以前偶在做 MTK 的時候, 曾經(jīng)也因為一個嚴(yán)重的缺陷, 沒有強力督促開發(fā)進(jìn)行修改, 結(jié)果導(dǎo) 致產(chǎn)品投產(chǎn)后出現(xiàn)巨大損失(本來是個賺錢的單子,結(jié)果還賠了幾百 W 。 (其中的原因 比較復(fù)雜,就不細(xì)說了,呵呵 目前我正在完善以前的測試用例并且分出優(yōu)先級。 以前的測試人

20、員的測試用例太不適合公司 的業(yè)務(wù)了。 真是不知道怎么展開測試的。 。 撞大運也不行啊。 。 剛到新公司兩周。 。 。進(jìn)入手機 行業(yè)兩周 問題的主要原因:1:測試沒有覆蓋完全2:信任開發(fā)的話,開發(fā)說這個改掉之后沒有其他的 BUG 。再加上時間緊, 所以就沒有測試其他的關(guān)于 MP3的功能。只針對修改進(jìn)行測試。歸根到底還是 測試沒有覆蓋完全!兩個問題:1:測試沒有覆蓋完全測試永遠(yuǎn)都不能實現(xiàn)完全覆蓋。短周期的測試就更不能完成了。但是在實際過程中,當(dāng)你沒有測試完時,領(lǐng)導(dǎo)就要你下結(jié)論:OK 或 NO這樣的問題,你可以考慮將“測試策略”在項目初期進(jìn)行評審。針對幾個相似的項目,只評 審一個測試策略就 OK 。

21、 (人員以測試為主,開發(fā)和市場人員也應(yīng)該參與比如:測試策略中, 在交互性方面, 產(chǎn)品通過與 A/B/C模塊的 a/b/c交互性測試,并測試通 過后,即可認(rèn)為產(chǎn)品交互性沒有問題。這樣的評審能集思廣益, 找到產(chǎn)品中需要重點測試部分; 同時也能減輕產(chǎn)品投入市場后出現(xiàn) 問題時,給測試部門帶來的影響。不過這樣的評審有個前提,要積極調(diào)動大家去想才有效果2:開發(fā)的信任度開發(fā)與測試的關(guān)系是雙面的。在缺陷上, 測試?yán)碚撋喜粦?yīng)該信任開發(fā); 在產(chǎn)品質(zhì)量上, 開發(fā) 為測試提供了更多的測試手段。關(guān)于 6225測試的測試問題,偶前幾天也與原來做 MTK 的開發(fā)交流一下。他們也是說,其實 要找出“所有的死機故障”和找出“所

22、有故障”根本沒有區(qū)別,因為在編碼時并不能預(yù)見一 段錯誤的代碼帶來的危害有多大 (但是偶還是覺得規(guī)范的編碼能有效的預(yù)防重大故障的 產(chǎn)生所以,回歸測試要嚴(yán)格做,開發(fā)的關(guān)系還是要搞好樓主指的是手機的第三方軟件測試吧如果是,那么我略談一些關(guān)于這方面的東西。首先測試一般是把流程走通, 這是最基本的, 你的軟件需要實現(xiàn)什么功能和實現(xiàn)了什么功 能,嚴(yán)格按照需求,即使是可用的功能,需求沒有的話,那也是 Bug 。軟件的可用性和體驗性交互性:這一塊的 Bug 應(yīng)該是最多, 舉一個簡單的例子, 使用軟件的過程中來短信和來電, 如果你的軟件是基于網(wǎng)絡(luò)的,這一塊肯定會有很多問題。而且,手動的將網(wǎng)絡(luò)斷開再恢復(fù),請求會不

23、會重新發(fā)送,這一點也是需要考慮的。將軟件中的控件和手機的按鍵結(jié)合起來測試。還有你要明確軟件的平臺,兼容性需要考慮, 如果是一個平臺的, 但是分辨率不一樣, 會使 得界面元素丟失等,如果是鍵盤和觸屏,那又要分情況考慮了。找 Bug 就是要把軟件玩死, 就要充分考慮異常的操作, 測試不是找開發(fā)的錯誤, 而是想開 發(fā)沒想到的東西,場景是否面面俱到,錯誤處理是否健全。我在做這方面的測試一等價類劃分方法針對手機狀態(tài)大致可以歸幾個大類:1. 按鍵類(等價法 :有效輸入和無效輸入(有效輸入指 UM 和菜單指示;無效輸入 指測試菜單功能此時沒有定義的按鍵和用戶動作 ;2. 外部中斷類(等價法 :常用、不常用及

24、無效二、 邊界值分析例子 1:短消息發(fā)送功能的等價類劃分方法 :合法等價類: 0160非法等價類:>160三和其他軟件的兼容比如同時打開你測的軟件,然后去瀏覽網(wǎng)站 QQ 打電話 接電話,發(fā)短信收短信(彩信 這些只是一些 還有很多 手機要測的面很廣 不同的手機,不同的網(wǎng)絡(luò),不同的操作系統(tǒng), 都需要考慮。沒有什么好的軟件,主要靠經(jīng)驗。手機軟件測試有哪些方法一、 等價類分析法等價類劃分方法針對手機狀態(tài)大致可以歸幾個大類:1. 按鍵類(等價法 :有效輸入和無效輸入(有效輸入指 UM 和菜單指示;無效輸入 指測試菜單功能此時沒有定義的按鍵和用戶動作 ;2. 外部中斷類(等價法 :常用、不常用及無效

25、2.1. 常用:來電和來消息(短信、彩信、 push 消息 ;掀合蓋;側(cè)鍵;耳機&FM ;情景 模式;電量不足2.2. 不常用:充電; 鬧鐘&記事本&關(guān)機時間&整點報時提示; Icon &動畫顯示; Icon &動畫刷新;編輯界面&pop 顯示框輸入為空或滿;編輯界面&pop 顯示框狀態(tài)輸入法默認(rèn) &字符編碼默認(rèn);失效 SIM 卡;大容量等 SIM 卡兼容;排序;號碼識別;二、 邊界值分析例子 1:短消息發(fā)送功能的等價類劃分方法 :三、 錯誤猜測法例子 1:利用手機鬧鐘重響的例子引入錯誤猜測法基本概念,講解錯誤猜測法的意義

26、未接來電 29通,內(nèi)存中規(guī)劃的分區(qū)一直分配被占用。即使同一號碼也同樣占用資源。假設(shè) 此時第 30通電話正好為來電號碼不顯示,即“來電號碼未知”或境外來電號碼隱藏時(國 外保護個人隱私,自動開啟來電號碼隱藏功能 ,可能會出現(xiàn) BUG ,實際情況證明,此時會 出現(xiàn) Reset 問題。四、 判定表法舉例一,若手機用戶欠費或停機,則不允許主被叫。表示為判定表如下:七、 狀態(tài)遷移法舉例手機 mp3鍵盤播放模式測試用例設(shè)計1. 鍵盤用戶模式基本操作功能2. 支持媒體格式與文件格式要求3. 多媒體播放中對外部事件的響應(yīng)4. 終端處理能力(包括終端異常處理、文件操作5. PC 與終端同步能力手機應(yīng)用終端測試和

27、普通軟件測試在測試策略和任務(wù)分配上有何不同?如果我選擇 Andriod 平臺, 安裝一個社區(qū)交友網(wǎng)站的應(yīng)用終端, 現(xiàn)在要做這個應(yīng)用終端的功 能測試,在進(jìn)行人員的分配和測試策略上與普通軟件測試的區(qū)別?不是年齡,而是我們的經(jīng)驗老到,并且強調(diào)一下,測試經(jīng)驗和開發(fā)經(jīng)驗是不一樣的。我們先拿微軟公司的測試工作內(nèi)容來看看, 基本了解一下軟件測試是干什么, 你就好選擇了。 微軟的軟件測試工作1. 基本情況測試在微軟公司是一項非常重要的工作, 微軟公司在此方面的投入是非常巨大的。 微軟對測 試的重視表現(xiàn)在工程開發(fā)隊伍的人員構(gòu)成上, 微軟的項目經(jīng)理、 軟件開發(fā)人員和測試人員的 比例基本是 1:3:3或 1:4:4

28、,可以看出開發(fā)人員與測試人員的比例是 1:1。對于測試的 重視還表現(xiàn)在最后產(chǎn)品要發(fā)布的時候, 此產(chǎn)品的所有相關(guān)部門都必須簽字, 而測試人員則具 有絕對的否決權(quán)。測試人員中分成兩種職位, Software Development Engineer in Test(測試組的軟件開發(fā) 工程師 實際上還是屬于開發(fā)人員, 他們具備編寫代碼的能力和開發(fā)工具軟件的經(jīng)驗, 側(cè)重 于開發(fā)自動化測試工具和測試腳本,實現(xiàn)測試的自動化。 Software Test Engineer (軟件測 試工程師具體負(fù)責(zé)測試軟件產(chǎn)品,主要完成一些手工測試以及安裝配置測試。2. 測試計劃測試計劃是測試人員管理測試項目, 在軟件中尋

29、找 Bug 的一種有效的工具。 測試計劃主要有 兩個作用, 一是評判團隊的測試覆蓋率以及效率, 讓測試工作很有條理的逐步展開。 二是有 利于與項目經(jīng)理、 開發(fā)人員進(jìn)行溝通。 有了測試計劃之后, 他們就能夠知道你是如何開展測 試工作的, 他們也會從中提出很多有益的意見,確保測試工作順利進(jìn)行?？傊?有了測試計 劃可以更好的完成測試工作,確保用戶的滿意度。測試人員在編寫測試計劃之前,應(yīng)獲得以下文檔:1程序經(jīng)理編寫的產(chǎn)品功能說明書或產(chǎn)品開發(fā)計劃;2程序經(jīng)理或開發(fā)人員提供的開發(fā)進(jìn)度表。根據(jù)產(chǎn)品的特性及開發(fā)進(jìn)度安排, 測試人員制定具體的測試計劃。 測試計劃通常包括以下內(nèi) 容:1測試目標(biāo)和發(fā)布條件:a. 給

30、出清晰的測試目標(biāo)描述;b. 定義產(chǎn)品的發(fā)布條件,即在達(dá)到何種測試目標(biāo)的前提下才可以發(fā)布產(chǎn)品的某個特 定版 本。2待測產(chǎn)品范圍:a. 軟件主要特性 /功能說明,即待測軟件主要特性的列表;b. 特性 /功能測試一覽, 應(yīng)涵蓋所有特性、對話框、菜單和錯誤信息等待測內(nèi)容, 并列舉每 個測試范圍內(nèi)要重點考慮的關(guān)鍵功能。3測試方法描述:a. 定義測試軟件產(chǎn)品時使用的測試方法;b. 描述每一種特定的測試方法可以覆蓋哪些測試范圍。4測試進(jìn)度表:a. 定義測試?yán)锍瘫?b. 定義當(dāng)前里程碑的詳細(xì)測試進(jìn)度。5測試資源和相關(guān)的程序經(jīng)理 /開發(fā)工程師:a. 定義參與測試的人員;b. 描述每位測試人員的職責(zé)范圍;c. 給

31、出與測試有關(guān)的程序經(jīng)理 /開發(fā)工程師的相關(guān)信息。6配置范圍和測試工具:a. 給出測試時使用的所有計算機平臺列表;b. 描述測試覆蓋了哪些硬件設(shè)備;c. 測試時使用的主要測試工具。此外, 還應(yīng)列出測試中可能會面臨的風(fēng)險及測試的依賴性, 即測試是否依賴于某個產(chǎn)品或某 個團隊。 比如此項測試依賴性 WindowsCE 這個操作系統(tǒng), 而這個系統(tǒng)要明年 2月份才能做好, 那么此項測試就可能只有在明年 5月份才能完成, 這樣就存在著依賴關(guān)系。 如果那個團隊的 開發(fā)計劃往后推,則此項測試也會被推遲。3. 測試用例開發(fā)一個好的測試用例就是有一個合理的概率來找到 Bug ,不要冗余,要有針對性,一個測試只 針

32、對一件事情。 特別是功能測試的時候, 如果一個測試是測了兩項功能, 那么如果測試結(jié)果 失敗的話,就不知道到底是哪項功能出了問題。測試用例開發(fā)中主要使用的技術(shù)有等價類劃分,邊界值的分析, Error Guessing Testing。 等價類劃分是根據(jù)輸入輸出條件, 以及自身的一些特性分成兩個或更多個子集, 來減少所需 要測試的用例個數(shù),并且能用很少的測試用例來覆蓋很多的情況,減少測試用例的冗余度。 在等價類劃分中,最基本的劃分是一個為合法的類,一個為不合法的類。邊界值的分析是利用了一個規(guī)律, 即程序最容易發(fā)生錯誤的地方就是在邊界值的附近, 它取 決于變量的類型,以及變量的取值范圍。一般對于有

33、n 個變量時,會有 6n+1個測試用例, 取值分別是 min-1, min, min+1, normal, max-1, max,max+1的組合。邊界值的分析的缺點, 是對邏輯變量和布爾型變量不起作用,還有可能會忽略掉某些輸入的組合。Error Guessing Testing完全靠的是經(jīng)驗,所設(shè)計的測試用例就是常說的猜測。感覺到軟 件在某個地方可能出錯, 就去設(shè)計相應(yīng)的測試用例, 這主要是靠實際工作中所積累的經(jīng)驗和 知識。其優(yōu)點是速度快,只要想得到,就能很快設(shè)計出測試用例。缺點就是沒有系統(tǒng)性,無 法知道覆蓋率會有多少,很可能會遺漏一些測試領(lǐng)域。實際上在微軟是采用一些專門的軟件或工具負(fù)責(zé)測試

34、用例的管理, 有一些測試信息可以被記 錄下來,比如測試用例的簡單描述, 在哪些平臺執(zhí)行,是手工測試還是自動測試, 運行的頻 率是每天運行一次, 還是每周運行一次。 此外還有清晰的測試通過或失敗的標(biāo)準(zhǔn), 以及詳細(xì) 記錄測試的每個步驟。4. Bug跟蹤過程在軟件開發(fā)項目中,測試人員的一項最重要使命就是對所有已知 Bug 進(jìn)行有效的跟蹤和管 理,保證產(chǎn)品中出現(xiàn)的所有問題都可以得到有效的解決。一般地,項目組發(fā)現(xiàn)、定位、處理 和最終解決一個 Bug 的過程包括 Bug 報告、 Bug 評估和分配、 Bug 處理、 Bug 關(guān)閉等四個階段:1測試工程師在測試過程中發(fā)現(xiàn)新的 Bug 后,應(yīng)向項目組報告該 Bug 的位置、表現(xiàn)、當(dāng)前 狀態(tài)等信息。項目組在 Bug 數(shù)據(jù)庫中添加該 Bug 的記錄。2開發(fā)經(jīng)理對已發(fā)現(xiàn)的 Bug 進(jìn)行集中討論,根據(jù) Bug 對軟件產(chǎn)品的影響來評估 Bug 的優(yōu)先 級, 制定 Bug 的修正策略。 按照 Bug 的優(yōu)先級順序和開發(fā)人員的工作安排, 開發(fā)經(jīng)理將所有 需要立即處理的 Bug 分配給相應(yīng)的開發(fā)工程師。3開發(fā)工程師根據(jù)安