App的測試，和傳統(tǒng)軟件測試有哪些區(qū)別？

App的測試，和傳統(tǒng)軟件測試有哪些區(qū)別？應(yīng)該增加哪些方面的測試用例？

隨手機(jī)對(duì)人們生活中的影響越來越大，App測試工作逐漸被眾人所知。從一開始的眾包到現(xiàn)在的自動(dòng)化探索，手機(jī)測試上的技術(shù)發(fā)展也是日新月異。

App測試相比以往傳統(tǒng)的軟甲測試相關(guān)要復(fù)雜的多且困難的多。

基于工作經(jīng)驗(yàn)，我將如何做好app的測試歸結(jié)為如下內(nèi)容。

(1) ? 非功能測試

app測試的一個(gè)重要方面是app的非功能需求。移動(dòng)app在推出市場或進(jìn)行進(jìn)一步開發(fā)前，測試人員有一定的職責(zé)做該類需求的跟蹤工作。

早期開發(fā)階段要進(jìn)行的第一個(gè)測試應(yīng)該是實(shí)用性測試。通常是由alpha用戶或同事進(jìn)行的。走進(jìn)一家咖啡館或餐廳，問問里面的人他們的app使用情況。讓他們看看現(xiàn)階段開發(fā)的第一個(gè)版本并收集反饋，看看用戶是否能很好地使用新功能，以便得出第一印象。

(2) ? 功能測試

每項(xiàng)開發(fā)的新功能都需要進(jìn)行測試。app測試中功能測試是一個(gè)重要方面。測試人員應(yīng)該要進(jìn)行手動(dòng)測試和后期的自動(dòng)化測試維護(hù)。剛開始測試時(shí)，測試員必須把a(bǔ)pp當(dāng)做"黑盒"一樣進(jìn)行手動(dòng)測試，看看提供的功能是否正確并如設(shè)計(jì)的一樣正常運(yùn)作。除了經(jīng)典軟件測試，像點(diǎn)擊按鈕、提交訂單看看會(huì)發(fā)生什么，測試員還必須執(zhí)行更多功能的app測試。

除了整個(gè)手動(dòng)測試過程，測試自動(dòng)化對(duì)移動(dòng)app也很重要。每個(gè)代碼變化或新功能都可能影響現(xiàn)存功能及它們的狀態(tài)。通常手動(dòng)回歸測試時(shí)間不夠，所以測試員不得不找一個(gè)工具去進(jìn)行自動(dòng)化回歸測試。現(xiàn)在市面上有很多自動(dòng)化測試工具，有商業(yè)的也有開源的，面向各個(gè)不同平臺(tái)，如Android，iPhone，WindowsPhone7，BlackBerry以及移動(dòng)Webapp。根據(jù)開發(fā)策略和結(jié)構(gòu)，品質(zhì)管理測試專家需找出最適合他們環(huán)境的自動(dòng)化工具。

(3) ? 客戶端性能測試

一個(gè)App做的好不好，不僅僅只反應(yīng)在功能上。被測的app在中低端機(jī)上的性能表現(xiàn)也很重要。比如：一個(gè)很好玩的游戲或應(yīng)用，只能在高端機(jī)上流暢運(yùn)行，在中低端機(jī)上卡的不行，也不會(huì)取得好的口碑。

關(guān)于App的性能測試，我們比較關(guān)注的參數(shù)有：CPU，內(nèi)存，耗電量，流量，F(xiàn)PS。同時(shí)也需關(guān)注一下App的安裝耗時(shí)和啟動(dòng)耗時(shí)。

目前大家可能比較困惑的一個(gè)問題，多高的CPU，內(nèi)存，耗電量，流量，F(xiàn)PS才算是符合發(fā)布的值呢？這里可以告訴大家，可以參考精品游戲的一些數(shù)值，將自己研發(fā)的app與業(yè)內(nèi)精品的app數(shù)據(jù)做對(duì)比。

(4) ? 適配兼容測試

App在經(jīng)過功能測試后，也需對(duì)其進(jìn)行適配兼容測試需要檢查的項(xiàng)主要有以下幾點(diǎn)：

(a) 在不同平牌的機(jī)型上的安裝、拉起、點(diǎn)擊和卸載是否正常；

(b) 在不同的操作系統(tǒng)上的安裝、拉起、點(diǎn)擊和卸載是否正常；

我們?cè)趯?shí)際測試中，常常會(huì)遇到下列問題：

(a) 在某個(gè)平牌某個(gè)系統(tǒng)上，app安裝不上；

(b) 在某個(gè)平牌某個(gè)系統(tǒng)上，app無法拉起；

(c) 在某個(gè)平牌某個(gè)系統(tǒng)上，app拉起后無響應(yīng)或拉起后黑屏、花屏；

(d) 在某個(gè)平牌某個(gè)系統(tǒng)上，app無法順利卸載；

（WeTest騰訊質(zhì)量開放平臺(tái)）這個(gè)產(chǎn)品可以實(shí)現(xiàn)多款熱門機(jī)型的適配兼容測試。

(5) ? 弱網(wǎng)絡(luò)測試

App在使用的過程中，難免會(huì)遇到弱網(wǎng)絡(luò)環(huán)境，例如在公車上、在地鐵里。在這種情況下，常常會(huì)出現(xiàn)網(wǎng)絡(luò)抖動(dòng)、上行或下行超時(shí)，導(dǎo)致應(yīng)用中出現(xiàn)丟包。

作為一個(gè)測試人員，我們要對(duì)app在上線前做一定場景的弱網(wǎng)絡(luò)環(huán)境模型，并查看app在弱網(wǎng)絡(luò)環(huán)境下是否存在某些未知的問題。下面是我們常用的弱網(wǎng)絡(luò)環(huán)境場景：

(a) 3G弱網(wǎng)絡(luò)信號(hào)場景模擬；

(b) 市區(qū)低速移動(dòng)場景模擬；

(c) 郊區(qū)高速移動(dòng)場景模擬；

(d) 請(qǐng)求回應(yīng)超時(shí)_上行超時(shí)場景模擬；

(e) 請(qǐng)求回應(yīng)超時(shí)_下行超時(shí)場景模擬；

(f) 網(wǎng)絡(luò)抖動(dòng)場景模擬；

(6) ? 耗電量測試

App在手機(jī)上的表現(xiàn)，除了功能外，app是否耗電，也是測試過程中重點(diǎn)要關(guān)注的一項(xiàng)。手機(jī)設(shè)備在滿電的時(shí)候，這個(gè)App能玩多久；App每小時(shí)的耗電是多少；App在某個(gè)場景掛機(jī)10分鐘耗電量是多少；這些都是我們平時(shí)在耗電量測試中比較關(guān)注的點(diǎn)。

(7) ? 協(xié)議測試

模擬客戶端直接發(fā)送協(xié)議包給服務(wù)器，看看服務(wù)器是否有一定的校驗(yàn)，認(rèn)不認(rèn)客戶端發(fā)過來的數(shù)據(jù)。協(xié)議測試，主要是為了處理用戶發(fā)送惡意協(xié)議到服務(wù)器，騙過服務(wù)器的校驗(yàn)。

(8) 安全測試

App在上線前，都需要做詳細(xì)的安全測試。安全測試主要為了檢測應(yīng)用是否容易被外界破解；是否存在被惡意代碼注入的風(fēng)險(xiǎn)；上線后外掛的風(fēng)險(xiǎn)高不高等。

(9) 服務(wù)器性能測試

服務(wù)器性能測試，主要包含單機(jī)容量測試和24小時(shí)穩(wěn)定性測試。單機(jī)容量測試，可以檢測到單機(jī)服務(wù)器在90%的響應(yīng)時(shí)間和成功率都達(dá)標(biāo)的前提下，能夠承載多少用戶量。使用特定游戲模型壓測24小時(shí)，服務(wù)無重啟，內(nèi)存無泄漏，并且各事務(wù)成功率達(dá)標(biāo)。

這個(gè)可以在WeTest入口預(yù)約。

(10) 服務(wù)器容災(zāi)測試

服務(wù)器容災(zāi)測試，主要指某個(gè)服務(wù)進(jìn)程奔潰掉后，是否具有自行恢復(fù)能力。比如游戲邏輯進(jìn)程消失后，是否會(huì)自動(dòng)拉起；memcached崩潰時(shí)，是否會(huì)重新啟動(dòng)，是否會(huì)對(duì)所有玩家有影響。這些都是app測試過程中需要考慮的因素。

(11) 中斷測試

針對(duì)智能終端應(yīng)用的服務(wù)等級(jí)劃分方式及實(shí)時(shí)特性所提出的測試方法，如：App在前臺(tái)和后臺(tái)運(yùn)行狀態(tài)時(shí)與來電、文件下載、音樂收聽等關(guān)鍵運(yùn)用的交互情況測試等。測試電話，短信，彩信，微博或其他通知進(jìn)來時(shí)app的反應(yīng)。

(12) 上線后期的輿情跟蹤

新的app上線后，用戶對(duì)此應(yīng)用的評(píng)價(jià)，存在哪些測試期間未察覺的Bug，論壇上對(duì)于該應(yīng)用熱門的帖子有哪些，應(yīng)用商店中該應(yīng)用的口碑如何等，都是app在上線后，測試人員需要關(guān)注的點(diǎn)。若需要測試期間未發(fā)現(xiàn)的Bug，需要新測試服進(jìn)行確認(rèn)并根據(jù)該問題的修復(fù)。

App的測試，和傳統(tǒng)軟件測試有哪些區(qū)別

A：相同點(diǎn)
不管是傳統(tǒng)行業(yè)的web測試，還是新興的手機(jī)app測試，都離不開測試的基礎(chǔ)知識(shí)：
1）同樣的設(shè)計(jì)測試用例方法：邊界值分析法、等價(jià)類劃分、錯(cuò)誤推測法、場景法等（若想看這些基礎(chǔ)課視頻，直接點(diǎn)擊原文看騰訊課堂的視頻，都有，且免費(fèi)?。?br>2）同樣的測試方法：黑盒測試，驗(yàn)證業(yè)務(wù)功能是否正確符合用戶或者設(shè)計(jì)預(yù)期；
3）都要檢查UI：界面的布局、風(fēng)格和按鈕等是否簡潔美觀、是否統(tǒng)一等；
4）頁面性能檢測：測試頁面載入和翻頁的速度、登錄時(shí)長、內(nèi)存是否溢出等；
5）應(yīng)用的穩(wěn)定性：測試應(yīng)用系統(tǒng)的穩(wěn)定性等，不會(huì)閃退卡死等。
B：不同點(diǎn)
相對(duì)于web測試，APP測試，除了要考慮基本的功能測試、性能等，還要考慮手機(jī)本身固有的屬性特征。所以APP測試過程中還需要注意如下幾個(gè)方面特性：
1）手機(jī)作為通信工具，來電、去電、接收短信等操作都會(huì)對(duì)app應(yīng)用程序產(chǎn)生影響，所以app測試第一個(gè)要考慮的屬性特征是：中斷測試。
中斷測試有人為中斷、新任務(wù)中斷以及意外中斷等幾種情況，主要從以下幾個(gè)方面進(jìn)行驗(yàn)證：
a.來電中斷：呼叫掛斷、被呼叫掛斷、通話掛斷、通話被掛斷
b.短信中斷：接收短信、查看短信
c.其他中斷：藍(lán)牙、鬧鐘、插拔數(shù)據(jù)線、手機(jī)鎖定、手機(jī)斷電、手機(jī)問題（系統(tǒng)死機(jī)、重啟）
2）手機(jī)用戶對(duì)app產(chǎn)品的安裝卸載操作：
a.從上一個(gè)版本/上兩個(gè)版本直接升級(jí)到最新版本。
b.全新安裝新版本
c.新版本覆蓋舊版本安裝
d.卸載舊版本，安裝新版本
e.卸載新版本，安裝新版本
3）web自動(dòng)化測試使用的工具較常用的是QTP，而android手機(jī)自動(dòng)化測試工具比較常用的是monkey、monkeyrunner、appium。

軟件測試的方法一共有幾種

1、從是否關(guān)心內(nèi)部結(jié)構(gòu)來看

（1）白盒測試：又稱為結(jié)構(gòu)測試或邏輯驅(qū)動(dòng)測試，是一種按照程序內(nèi)部邏輯結(jié)構(gòu)和編碼結(jié)構(gòu)，設(shè)計(jì)測試數(shù)據(jù)并完成測試的一種測試方法。

（2）黑盒測試：又稱為數(shù)據(jù)驅(qū)動(dòng)測試，把測試對(duì)象當(dāng)做看不見的黑盒，在完全不考慮程序內(nèi)部結(jié)構(gòu)和處理過程的情況下，測試者僅依據(jù)程序功能的需求規(guī)范考慮，確定測試用例和推斷測試結(jié)果的正確性，它是站在使用軟件或程序的角度，從輸入數(shù)據(jù)與輸出數(shù)據(jù)的對(duì)應(yīng)關(guān)系出發(fā)進(jìn)行的測試。

（3）灰盒測試：是一種綜合測試法，它將“黑盒”測試與“白盒”測試結(jié)合在一起，是基于程序運(yùn)行時(shí)的外部表現(xiàn)又結(jié)合內(nèi)部邏輯結(jié)構(gòu)來設(shè)計(jì)用例，執(zhí)行程序并采集路徑執(zhí)行信息和外部用戶接口結(jié)果的測試技術(shù)。

2、從是否執(zhí)行代碼看

（1）靜態(tài)測試：指不運(yùn)行被測程序本身，僅通過分析或檢查源程序的語法、結(jié)構(gòu)、過程、接口等來檢查程序的正確性。

(2)動(dòng)態(tài)測試：是指通過運(yùn)行被測程序，檢查運(yùn)行結(jié)果與預(yù)期結(jié)果的差異，并分析運(yùn)行效率、正確性和健壯性等性能指標(biāo)。

3、從開發(fā)過程級(jí)別看

（1）單元測試：又稱模塊測試，是針對(duì)軟件設(shè)計(jì)的最小單位----程序模塊或功能模塊，進(jìn)行正確性檢驗(yàn)的測試工作。其目的在于檢驗(yàn)程序各模塊是否存在各種差錯(cuò)，是否能正確地實(shí)現(xiàn)了其功能，滿足其性能和接口要求。

(2)集成測試：又叫組裝測試或聯(lián)合，是單元測試的多級(jí)擴(kuò)展，是在單元測試的基礎(chǔ)上進(jìn)行的一種有序測試。旨在檢驗(yàn)軟件單元之間的接口關(guān)系，以期望通過測試發(fā)現(xiàn)各軟件單元接口之間存在的問題，最終把經(jīng)過測試的單元組成符合設(shè)計(jì)要求的軟件。

（3）系統(tǒng)測試：是為判斷系統(tǒng)是否符合要求而對(duì)集成的軟、硬件系統(tǒng)進(jìn)行的測試活動(dòng)、它是將已經(jīng)集成好的軟件系統(tǒng)，作為基于整個(gè)計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、人員、數(shù)據(jù)等其他系統(tǒng)元素結(jié)合在一起，在實(shí)際運(yùn)行環(huán)境下，對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的組裝測試和確認(rèn)測試。

在系統(tǒng)測試中，對(duì)于具體的測試類型有：

（1）功能測試：對(duì)軟件需求規(guī)格說明書中的功能需求逐項(xiàng)進(jìn)行的測試，以驗(yàn)證功能是否滿足要求。

（2）性能測試：對(duì)軟件需求規(guī)格說明書的功能需求逐項(xiàng)進(jìn)行的測試，以驗(yàn)證功能是否滿足要求。

（3）接口測試：對(duì)軟件需求規(guī)格說明中的接口需求逐項(xiàng)進(jìn)行的測試。

（4）人機(jī)交互界面測試：對(duì)所有人機(jī)交互界面提供的操作和顯示界面進(jìn)行的測試，以檢驗(yàn)是否滿足用戶的需求。

（5）強(qiáng)度測試：強(qiáng)制軟件運(yùn)行在異常乃至發(fā)生故障的情況下（設(shè)計(jì)的極限狀態(tài)到超出極限），驗(yàn)證軟件可以運(yùn)行到何種程序的測試。

（6）余量測試：對(duì)軟件是否達(dá)到規(guī)格說明中要求的余量的測試。

（7）安全性測試：檢驗(yàn)軟件中已存在的安全性、安全保密性措施是否有效的測試，

（8）可靠性測試：在真實(shí)的或仿真的環(huán)境中，為做出軟件可靠性估計(jì)而對(duì)軟件進(jìn)行的功能（其輸入覆蓋和環(huán)境覆蓋一般大于普通的功能測試）

（9）恢復(fù)性測試：對(duì)有恢復(fù)或重置功能的軟件的每一類導(dǎo)致恢復(fù)或重置的情況，逐一進(jìn)行的測試。

（10）邊界測試：對(duì)軟件處在邊界或端點(diǎn)情況下運(yùn)行狀態(tài)的測試。

（11）數(shù)據(jù)處理測試：對(duì)完成專門數(shù)據(jù)處理功能所進(jìn)行的測試。

（12）安裝性測試：對(duì)安裝過程是否符合安裝規(guī)程的測試，以發(fā)現(xiàn)安裝過程中的錯(cuò)誤。

（13）容量測試：檢驗(yàn)軟件的能力最高能達(dá)到什么程度的測試。

（14）互操作性測試：為驗(yàn)證不同軟件之間的互操作能力而進(jìn)行的測試。

（15）敏感性測試：為發(fā)現(xiàn)在有效輸入類中可能引起某種不穩(wěn)定性或不正常處理的某些數(shù)據(jù)的組合而進(jìn)行的測試。

（16）標(biāo)準(zhǔn)符合性測試：驗(yàn)證軟件與相關(guān)國家標(biāo)準(zhǔn)或規(guī)范（如軍用標(biāo)準(zhǔn)、國家標(biāo)準(zhǔn)、行業(yè)標(biāo)準(zhǔn)及國際標(biāo)準(zhǔn)）一致性的測試。

（17）兼容性測試：驗(yàn)證軟件在規(guī)定條件下與若干個(gè)實(shí)體共同使用或?qū)崿F(xiàn)數(shù)據(jù)格式轉(zhuǎn)換時(shí)能滿足有關(guān)要求能力的測試。

（18）中文本地化測試：驗(yàn)證軟件在不降低原有能力的條件下，處理中文能力的測試。

4、從執(zhí)行過程是否需要人工干預(yù)來看

（1）手工測試：就是測試人員按照事先為覆蓋被測軟件需求而編寫的測試用例，根據(jù)測試大綱中所描述的測試步驟和方法，手工地一個(gè)一個(gè)地輸 入執(zhí)行，包括與被測軟件進(jìn)行交互（如輸入測試數(shù)據(jù)、記錄測試結(jié)果等），然后觀察測試結(jié)果，看被測程序是否存在問題，或在執(zhí)行過程中是否會(huì)有一場發(fā)生，屬于比較原始但是必須執(zhí)行的一個(gè)步驟。

（2）自動(dòng)化測試：實(shí)際上是將大量的重復(fù)性的測試工作交給計(jì)算機(jī)去完成，通常是使用自動(dòng)化測試工具來模擬手動(dòng)測試步驟，執(zhí)行用某種程序設(shè)計(jì)語言編寫的過程（全自動(dòng)測試就是指在自動(dòng)測試過程中，不需要人工干預(yù)，由程序自動(dòng)完成測試的全過程；半自動(dòng)測試就是指在自動(dòng)測試過程中，需要手動(dòng)輸入測試用例或選擇測試路徑，再由自動(dòng)測試程序按照人工指定的要求完成自動(dòng)測試）

5、從測試實(shí)施組織看

（1）開發(fā)測試：開發(fā)人員進(jìn)行的測試

（2）用戶測試：用戶方進(jìn)行的測試

（3）第三方測試：有別于開發(fā)人員或用戶進(jìn)行的測試，由專業(yè)的第三方承擔(dān)的測試，目的是為了保證測試工作的客觀性

6、從測試所處的環(huán)境看

（1）阿爾法測試：是由一個(gè)用戶在開發(fā)環(huán)境下進(jìn)行的測試，也可以是公司內(nèi)部的用戶在模擬實(shí)際操作環(huán)境下進(jìn)行的測試

（2）貝塔測試：是用戶公司組織各方面的典型終端用戶在日常工作中實(shí)際使用貝塔版本，并要求用戶報(bào)告

擴(kuò)展資料

軟件測試的內(nèi)容：

1 得到需求、功能設(shè)計(jì)、內(nèi)部設(shè)計(jì)說書和其他必要的文檔

2 得到預(yù)算和進(jìn)度要求

3 確定與項(xiàng)目有關(guān)的人員和他們的責(zé)任、對(duì)報(bào)告的要求、所需的標(biāo)準(zhǔn)和過程 ( 例如發(fā)行過程、變更過程、等等 )

4 確定應(yīng)用軟件的高風(fēng)險(xiǎn)范圍，建立優(yōu)先級(jí)、確定測試所涉及的范圍和限制

5 確定測試的步驟和方法 ── 部件、集成、功能、系統(tǒng)、負(fù)載、可用性等各種測試

6 確定對(duì)測試環(huán)境的要求 ( 硬件、軟件、通信等 )

7 確定所需的測試用具 (testware)，包括記錄 / 回放工具、覆蓋分析、測試跟蹤、問題 / 錯(cuò)誤跟蹤、等等

8 確定對(duì)測試的輸入數(shù)據(jù)的要求

9 分配任務(wù)和任務(wù)負(fù)責(zé)人，以及所需的勞動(dòng)力

10 設(shè)立大致的時(shí)間表、期限、和里程碑

11 確定輸入環(huán)境的類別、邊界值分析、錯(cuò)誤類別

12 準(zhǔn)備測試計(jì)劃文件和對(duì)計(jì)劃進(jìn)行必要的回顧

13 準(zhǔn)備白盒測試案例

14 對(duì)測試案例進(jìn)行必要的回顧 / 調(diào)查 / 計(jì)劃

15 準(zhǔn)備測試環(huán)境和測試用具，得到必需的用戶手冊(cè) / 參考文件 / 結(jié)構(gòu)指南 / 安裝指南，建立測試跟蹤過程，建立日志和檔案、建立或得到測試輸入數(shù)據(jù)

16 得到并安裝軟件版本

17 進(jìn)行測試

18 評(píng)估和報(bào)告結(jié)果

19 跟蹤問題 / 錯(cuò)誤，并解決它

20 如果有必要，重新進(jìn)行測試

21 在整個(gè)生命周期里維護(hù)和修改測試計(jì)劃、測試案例、測試環(huán)境、和測試用具

參考資料：百度百科-軟件測試

軟件性能測試包括哪些

根據(jù)百度百科：性能測試是通過自動(dòng)化的測試工具模擬多種正常、峰值以及異常負(fù)載條件來對(duì)系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測試。負(fù)載測試和壓力測試都屬于性能測試，兩者可以結(jié)合進(jìn)行。通過負(fù)載測試，確定在各種工作負(fù)載下系統(tǒng)的性能，目標(biāo)是測試當(dāng)負(fù)載逐漸增加時(shí)，系統(tǒng)各項(xiàng)性能指標(biāo)的變化情況。壓力測試是通過確定一個(gè)系統(tǒng)的瓶頸或者不能接受的性能點(diǎn)，來獲得系統(tǒng)能提供的最大服務(wù)級(jí)別的測試。
您可試用一些測試平臺(tái)進(jìn)行性能測試。
例如優(yōu)測。優(yōu)測為企業(yè)提供API全生命周期質(zhì)量解決方案、壓力測試、兼容性測試、移動(dòng)應(yīng)用自動(dòng)化測試、WebUI自動(dòng)化測試等多樣化測試產(chǎn)品。

我們動(dòng)用了十二臺(tái)手機(jī)，為你展現(xiàn)安兔兔V8的全貌

幾天前在ROG與騰訊聯(lián)手發(fā)布了那臺(tái)超旗艦 游戲 手機(jī)后，我們?nèi)咨钤欢赛c(diǎn)出，這種軟硬件廠商聯(lián)合，針對(duì)頂級(jí)手機(jī)制作頂級(jí)內(nèi)容的模式，將會(huì)讓智能手機(jī)的 游戲 生態(tài)從此向如今的PC領(lǐng)域靠攏。說得更直白一點(diǎn)，就是“所有的手機(jī)都能玩 游戲 ”、“所有的手機(jī)玩 游戲 的體驗(yàn)（畫面、流暢度）都差不多”的時(shí)代即將結(jié)束，智能手機(jī)在軟件體驗(yàn)上的“階級(jí)差異”將會(huì)進(jìn)一步放大。
因?yàn)檫@一次，全新的安兔兔V8正是為那些越級(jí)的超旗艦而生。更重要的是，它也進(jìn)一步昭示了5G時(shí)代的智能手機(jī)所應(yīng)該具備的那些，過去我們可能沒有重視到的性能細(xì)節(jié)。
那么首先讓我們來看看安兔兔V8版本的軟件界面——正如各位所見，這一次安兔兔V8的主界面風(fēng)格變化幅度遠(yuǎn)沒有當(dāng)初V6迭代到V7時(shí)那樣“翻天覆地”，但仔細(xì)對(duì)比還是不難看出一些改動(dòng)的。
在V7中，安兔兔的界面設(shè)計(jì)主打的是“減少滑動(dòng)操作”，這固然使得軟件的首頁變得更為簡潔，但也造成屏幕壞點(diǎn)測試、多點(diǎn)觸控測試等實(shí)用的小功能被折疊到了二級(jí)菜單中，反而可能造成一些用戶的迷惑。而V8則改為所有的測試項(xiàng)目都直觀地平鋪在了軟件開啟之后的第一頁上，如此一來那些其實(shí)很管用的小測試，就能更快地被用戶發(fā)現(xiàn)，更好地體現(xiàn)它們的價(jià)值。
比如說，HTML5測試可以在一臺(tái)手機(jī)上對(duì)比不同的瀏覽器APP的性能，可控區(qū)域檢測可以查看屏幕邊緣是否存在觸控失靈，灰階測試則能夠讓那些低灰階位數(shù)的屏幕（比如某些6bit屏）原形畢露，也可以用于查看手機(jī)屏幕白平衡是否過暗/過亮等。
除此之外，本次安兔兔V8也首次在首頁加入了AI測試的鏈接——之所以說是鏈接，主要是因?yàn)楫?dāng)前的安兔兔AI測試還處于Beta階段。目前尚未適配所有的手機(jī)SoC（比如麒麟980的雙核NPU支持就很差，以至于不能運(yùn)行），也不具備大家喜聞樂見的跑分排行榜，因此其尚未直接集成到安兔兔主程序中，因此有需求的用戶可以自行下載安裝。

不管是電腦還是手機(jī)上的測試軟件，其根本的職責(zé)都在于能夠反映出當(dāng)下整個(gè)行業(yè)中，不同定位的產(chǎn)品之間的性能差距，并告知用戶自身的設(shè)備是否能夠支撐起相應(yīng)的軟件體驗(yàn)。
這意味著什么？這意味著測試軟件必須要緊跟最新技術(shù)趨勢(shì)，能夠針對(duì)最先端的處理器架構(gòu)、設(shè)備性能和功能做出優(yōu)化，并將其以正確的比例反映在最終的評(píng)價(jià)體系中。

而這也正是此次安兔兔V8最大的改變所在：首先，V8版本幾乎完全重寫了針對(duì)內(nèi)存的測試部分，增加了針對(duì)智能手機(jī)剩余內(nèi)存、剩余存儲(chǔ)空間的考察，增加了超大內(nèi)存和超大存儲(chǔ)的得分比重（比如說某12GB+1TB的超旗艦，理論上就會(huì)有更大的優(yōu)勢(shì)）；同時(shí)在存儲(chǔ)IO性能的測試中，既會(huì)考察閃存的原生性能，也會(huì)考察廠商的優(yōu)化手段（比如磁盤緩存算法之類），以更多地體現(xiàn)系統(tǒng)優(yōu)化對(duì)于日常流暢度的影響。
其次在3D 游戲 性能的測試中，安兔兔V8對(duì)測試場景進(jìn)行了大幅更新，保留了此前的《精煉廠》場景，作為OpenGL 3.2（或3.1+AEP）API下的測試項(xiàng)目。而將早前的《海岸線》場景則升級(jí)為Vulkan API，并新增了完全重新開發(fā)的超重壓力Vulkan測試場景《兵馬俑》。

值得一提的是，根據(jù)我們從安兔兔方面獲得的消息顯示，本次V8版本還強(qiáng)化了對(duì)90Hz及120Hz在內(nèi)的高刷新率屏幕的支持，但由于一加7 Pro對(duì)于高刷屏采取白名單制度，因此目前在尚未適配的情況下，其安兔兔V8上的成績并不能發(fā)揮出高刷屏的優(yōu)勢(shì)。而不采用白名單方式的華碩ROG與努比亞紅魔3，則可以在3D測試中得到更高的幀率成績，得以充分反映出高刷新屏+旗艦SoC的流暢度優(yōu)勢(shì)。

為了測試本次的安兔兔V8，我們?nèi)咨钜部梢哉f是“下了血本”，足足動(dòng)用了十二臺(tái)設(shè)備參與測試。其主控型號(hào)涵蓋高通、三星、華為、聯(lián)發(fā)科四大品牌，基本上包含了當(dāng)前從千元級(jí)到頂級(jí)旗艦的幾乎所有可能性，內(nèi)存大小也從6GB一直到12GB，閃存容量則從128GB到512GB都有。當(dāng)然，就連目前依然少見的高刷新率旗艦我們也基本找齊：華碩ROG 游戲 手機(jī)2、內(nèi)置風(fēng)扇的努比亞紅魔3、還有號(hào)稱屏幕比肩三星Galaxy S10的一加7 Pro，可以說是應(yīng)有盡有。
需要說明的是，為了能讓各位“選手”發(fā)揮出最佳水平，我們盡可能地通過設(shè)置提高了它們的性能：其中OPPO、華為、三星手機(jī)均開啟了性能模式，紅魔3和紅魔Mars打開了競技鍵（黑鯊 游戲 手機(jī)2 Pro的SHARK SPACE功能暫時(shí)還不支持安兔兔V8），ROG 游戲 手機(jī)2則是啟用了X Mode并套上了外置風(fēng)扇。所有的測試手機(jī)均置于室溫強(qiáng)對(duì)流環(huán)境下以避免積熱。

廢話不多說：先上安兔兔V8跑分詳表（數(shù)據(jù)太多，分了兩張圖）：
看得不清楚？這里還有總分排行榜：
首先，眼尖的朋友可能已經(jīng)注意到我們給某臺(tái)機(jī)型打了馬賽克，這是因?yàn)樗€沒正式發(fā)布之故。不過大家可以將它看作是高通驍龍712平臺(tái)的參考設(shè)備，主要考量其與驍龍710之間的性能對(duì)比。而至于V8版本的安兔兔跑分結(jié)果普遍比V7高了一截，這自然是測試項(xiàng)目和分?jǐn)?shù)比重變更的結(jié)果，當(dāng)然它同時(shí)也就意味著，安兔兔V8的得分是不能與V7版本進(jìn)行對(duì)比的。

其次，有心的朋友或許能看出來，V8版本的安兔兔對(duì)于手機(jī)的存儲(chǔ)性能測試做了更為明確的劃分，新的測試項(xiàng)目已經(jīng)非常接近傳統(tǒng)PC測試軟件的存儲(chǔ)性能測試模式了，且包括順序讀寫與隨機(jī)讀寫的得分，也基本上和對(duì)應(yīng)的閃存類型完全符合。但唯獨(dú)有一個(gè)項(xiàng)目“應(yīng)用存儲(chǔ)速度”是其他評(píng)測軟件上極為少見的，而且它似乎并不受閃存速度/閃存類型的影響。那么安兔兔V8上新增的這個(gè)存儲(chǔ)測試，到底反映的是手機(jī)的哪一項(xiàng)性能指標(biāo)呢？
我們將這一項(xiàng)成績單獨(dú)提取出來看，答案就呼之欲出了：它是同時(shí)考量的手機(jī)的閃存讀寫性能以及可用空間大小。說得更直白一點(diǎn)，它反映的是手機(jī)“裝了多少應(yīng)用之后還能不卡”的能力。雖然這樣的測試項(xiàng)目在以往的評(píng)測軟件中從未有過，但很顯然，它對(duì)于智能手機(jī)的使用感受卻具有相當(dāng)大的參考價(jià)值。
針對(duì)本次安兔兔新增的，面向最高配手機(jī)的Vulkan圖形測試項(xiàng)目《兵馬俑》，我們選取了幾款手機(jī)，將其得分與知名圖形測試軟件3DMARK的Sling Shot Extreme場景圖形分進(jìn)行對(duì)比。可以看到相比于3DAMRK，安兔兔V8的圖型場景測試分?jǐn)?shù)高下之間的差異比例相對(duì)來說還是“溫和”了一點(diǎn)。
最后值得一提的是，本次的安兔兔V8還在成績的最后附上了評(píng)測前后溫度變化的情況。很顯然，這也是專門針對(duì)某些手機(jī)“冰箱大法”或“冷柜大法”跑分的反制措施。通過觀察跑分后的溫度以及溫升情況，就能很方便地判斷手機(jī)是否處在一個(gè)正常的室溫環(huán)境下，是否采用了特別的冷卻措施等等，從而進(jìn)一步降低了跑分“作弊”的可能性。

其實(shí)說到手機(jī)“跑分”這個(gè)事，它如今的熱度自然是不比曾經(jīng)那個(gè)“核戰(zhàn)”的年代。特別是隨著智能手機(jī)從增量市場逐漸轉(zhuǎn)向存量市場，對(duì)于許多至今依然使用著幾年前的老機(jī)型，或者只愿意使用百元機(jī)的用戶來說，跑分幾乎可以說是他們最不會(huì)考慮的應(yīng)用場景，沒有之一。
但是有入門級(jí)用戶，就自然也有頂級(jí)的發(fā)燒友——無論是因?yàn)榻橐庑聶C(jī)的 游戲 性能，還是僅僅只是出于好奇想知道剛?cè)胧值男缕炫灥降住俺缮睅缀?，緊跟技術(shù)潮流的最新跑分軟件，都能給這些消費(fèi)電子的中堅(jiān)用戶們以最為客觀的回答。

如何加強(qiáng)軟件需求管理，提高軟件質(zhì)量

一、什么是質(zhì)量？ 作為軟件產(chǎn)品的銷售人員，市場人員或維護(hù)人員經(jīng)常會(huì)受到客戶這樣那樣的指責(zé)或抱怨，客戶說：你們產(chǎn)品的質(zhì)量太差，不穩(wěn)定等等。那么什么是質(zhì)量呢？我們?cè)撊绾蝸砗饬抠|(zhì)量呢？ 質(zhì)量具有三個(gè)維度： ?? 符合目標(biāo)。目標(biāo)是客戶所定義的，符合目標(biāo)即判斷我們是不是在做需要做的事情。?? 符合需求。即產(chǎn)品是不是在做讓它做的事情。?? 符合實(shí)際需求。實(shí)際的需求包括用戶明確說明的和隱含的需求。ISO 關(guān)于質(zhì)量的定義表示如下： “ 一個(gè)實(shí)體（產(chǎn)品或服務(wù)）的所有特性，基于這些特性可以滿足明顯的或隱含的需要?！?注意，在這個(gè)定義中包含明顯的需求和隱含的需求。而往往我們會(huì)忽略隱含的需求。因此在控制一個(gè)產(chǎn)品的質(zhì)量的過程中必須關(guān)注這些隱含的需求，并給予應(yīng)有的驗(yàn)證。另一方面因?yàn)槲覀兊漠a(chǎn)品是為客戶提供服務(wù)的，因此凡是不滿足客戶需求的，我們都認(rèn)為是一個(gè)失效（ failure ）。所以我們的產(chǎn)品必須始終圍繞著客戶的需求進(jìn)行開發(fā)和驗(yàn)證。這里我們談到客戶，其實(shí)在一個(gè)軟件的需求收集過程中需要關(guān)注客戶和用戶。而我們經(jīng)常會(huì)忽略客戶與用戶之間的區(qū)別。那么誰是客戶？誰是用戶呢？簡單的來說，客戶是真正能夠決定是否購買你軟件的人，而用戶是實(shí)際使用軟件的人。了解了這個(gè)區(qū)別，對(duì)于你在分析需求的重要性的時(shí)候就可以進(jìn)行參考。同時(shí)在產(chǎn)品質(zhì)量驗(yàn)證的時(shí)候也可以做出不同的權(quán)衡。另一方面我們?cè)诳紤]我們用戶需求的時(shí)候，往往只考慮了實(shí)際使用軟件的人員，而忽略了其它一些人員對(duì)軟件的要求或?qū)浖斐傻臐撛诟偁?，這包括維護(hù)人員的要求、系統(tǒng)管理人員的要求、軟件上下游人員的要求、先前版本的情況、市場上競爭對(duì)手的軟件情況等。每個(gè)人提到質(zhì)量的時(shí)候，經(jīng)常會(huì)遇到下列矛盾，在這些矛盾中隱含著對(duì)質(zhì)量的承諾【 5 】： ?? 質(zhì)量需要一個(gè)承諾，尤其是高層管理者的承諾。但為了得到質(zhì)量，高層管理者必須和其雇用的員工進(jìn)行緊密合作； ?? 許多人相信沒有缺陷的產(chǎn)品和服務(wù)是不可能的。但是控制在一定級(jí)別的缺陷數(shù)是正常并可接受的； ?? 質(zhì)量經(jīng)常是和成本緊密聯(lián)系在一起，一個(gè)高質(zhì)量的產(chǎn)品同時(shí)也意味著高投入。這是設(shè)計(jì)的質(zhì)量和一致性質(zhì)量的一個(gè)矛盾； ?? 一個(gè)高的質(zhì)量要求需求規(guī)格說明書足夠詳細(xì)，以便產(chǎn)品可以根據(jù)這些規(guī)格說明書進(jìn)行定量的分析。然而許多組織沒有能力或者不愿意產(chǎn)生如此詳細(xì)程度的規(guī)格說明書； ?? 技術(shù)人員經(jīng)常相信規(guī)范和標(biāo)準(zhǔn)會(huì)束縛他們的創(chuàng)造力，因此就不遵照標(biāo)準(zhǔn)做事。然而如果要得到高質(zhì)量的產(chǎn)品，就必須遵循良好定義的標(biāo)準(zhǔn)和過程。二、流程對(duì)質(zhì)量的貢獻(xiàn) 好了，既然已經(jīng)了解了什么是質(zhì)量，那么怎么才能改進(jìn)軟件產(chǎn)品的質(zhì)量呢？從一個(gè)企業(yè)的長遠(yuǎn)發(fā)展來看，首先應(yīng)當(dāng)從流程抓起，規(guī)范軟件產(chǎn)品的開發(fā)過程。這是一個(gè)軟件企業(yè)從小作坊的生產(chǎn)方式向集成化、規(guī)范化的大公司邁進(jìn)的必經(jīng)之路，也是從根本上解決質(zhì)量問題，提高工作效率的一個(gè)關(guān)鍵手段。軟件產(chǎn)品的開發(fā)同其它產(chǎn)品（如汽車）的生產(chǎn)有著共同特性，即需要按一定的過程來進(jìn)行生產(chǎn)。在工業(yè)界，流水線生產(chǎn)方式被證明是一種高效且能夠比較穩(wěn)定地保證產(chǎn)品質(zhì)量的一種方式。通過這種方式，不同的人員被安排在流程的不同位置，最終為著一個(gè)目標(biāo)共同努力，這樣可以防止人員工作間的內(nèi)耗，極大的提高工作效率。并且由于其過程來源于成功的實(shí)例，因此其最終的產(chǎn)品質(zhì)量能夠滿足過程所設(shè)定的范圍要求。軟件工程在軟件的發(fā)展過程中吸取了這個(gè)經(jīng)驗(yàn)并把它應(yīng)用到了軟件開發(fā)中，這就形成了軟件工程過程，簡單的說就是開發(fā)流程。無論做什么事情，都有一個(gè)循序漸進(jìn)的過程，從計(jì)劃到策略再到實(shí)現(xiàn)。軟件流程就是按照這種思維來定義開發(fā)過程，它根據(jù)不同的產(chǎn)品特點(diǎn)和以往的成功經(jīng)驗(yàn)，定義了從需求到最終產(chǎn)品交付的一整套流程。流程告訴我們?cè)撛趺匆徊揭徊饺?shí)現(xiàn)產(chǎn)品，可能會(huì)有那些風(fēng)險(xiǎn)，如何去避免風(fēng)險(xiǎn)等等。由于流程來源于成功的經(jīng)驗(yàn)，因此，按照流程進(jìn)行開發(fā)可以使得我們少走彎路，并有效的提高產(chǎn)品質(zhì)量，提高用戶的滿意度。目前流行的流程方法有很多種，不同的過程模型適合于不同類型的項(xiàng)目。瀑布模型是應(yīng)用的最為廣泛的一種模型，也是最容易理解和掌握的模型，然而它的缺陷也是顯而易見的。遺漏的需求或者不斷變更的需求會(huì)使得該模型無所適從。然而，對(duì)于那些容易理解但很復(fù)雜的項(xiàng)目，采用瀑布模型會(huì)是比較適合的，因?yàn)槟憧梢园床烤桶嗟娜ヌ幚韽?fù)雜的問題。在質(zhì)量要求高于成本和進(jìn)度要求的時(shí)候，該模型表現(xiàn)的尤其突出。螺旋模型是也是一個(gè)經(jīng)典模型，它關(guān)注于發(fā)現(xiàn)和降低項(xiàng)目的風(fēng)險(xiǎn)【 8 】。螺旋型項(xiàng)目從小的規(guī)模開始，然后探測風(fēng)險(xiǎn)，制定風(fēng)險(xiǎn)控制計(jì)劃，接著確定下一步項(xiàng)目是否還要繼續(xù)，然后進(jìn)行下一個(gè)螺旋的反復(fù)。該模型的最大優(yōu)點(diǎn)就是隨著成本的增加，風(fēng)險(xiǎn)程度隨之降低。然而螺旋模型的缺點(diǎn)是比較復(fù)雜，且需要管理人員有責(zé)任心，專注以及有管理方面經(jīng)驗(yàn)。RUP （ Rational Unified Process ）是 Rational 公司提出的一套開發(fā)過程模型，它是一個(gè)面向?qū)ο筌浖こ痰耐ㄓ脴I(yè)務(wù)流程【 9 】。它描述了一系列相關(guān)的軟件工程流程，它們具有相同的結(jié)構(gòu)，即相同的流程構(gòu)架。RUP 為在開發(fā)組織中分配任務(wù)和職責(zé)提供了一種規(guī)范方法，其目標(biāo)是確保在可預(yù)計(jì)的時(shí)間安排和預(yù)算內(nèi)開發(fā)出滿足最終用戶需求的高品質(zhì)的軟件。RUP 具有兩個(gè)軸，一個(gè)是時(shí)間軸，這是動(dòng)態(tài)的。另一個(gè)是工作流軸，這是靜態(tài)的。在時(shí)間軸上，RUP 劃分了四個(gè)階段：初始階段、細(xì)化階段、構(gòu)造階段和發(fā)布階段。每個(gè)階段都使用了迭代的概念。在工作流軸上，RUP 設(shè)計(jì)了六個(gè)核心工作流程和三個(gè)核心支撐工作流程，核心工作流軸包括：業(yè)務(wù)建模工作流、需求工作流、分析設(shè)計(jì)工作流、實(shí)現(xiàn)工作流、測試工作流和發(fā)布工作流。核心支撐工作流包括：環(huán)境工作流、項(xiàng)目管理工作流和配置與變更管理工作流。具體可以參考圖 1。RUP 匯集現(xiàn)代軟件開發(fā)中多方面的最佳經(jīng)驗(yàn)，并為適應(yīng)各種項(xiàng)目及組織的需要提供了靈活的形式。作為一個(gè)商業(yè)模型，它具有非常詳細(xì)的過程指導(dǎo)和模板。但是同樣由于該模型比較復(fù)雜，因此在模型的掌握上需要花費(fèi)比較大的成本。尤其對(duì)項(xiàng)目管理者提出了比較高的要求。圖1 RUP 工作流程示意圖 IPD （ Integrated Product Development ）流程是由 IBM 提出來的一套集成產(chǎn)品開發(fā)流程，非常適合于復(fù)雜的大型開發(fā)項(xiàng)目，尤其涉及到軟硬件結(jié)合的項(xiàng)目。IPD 從整個(gè)產(chǎn)品角度出發(fā)，流程綜合考慮了從系統(tǒng)工程、研發(fā)（硬件、軟件、結(jié)構(gòu)工業(yè)設(shè)計(jì)、測試、資料開發(fā)等）、制造、財(cái)務(wù)到市場、采購、技術(shù)支援等所有流程。是一個(gè)端到端的流程。在 IPD 流程中總共劃分了六個(gè)階段（概念階段、計(jì)劃階段、開發(fā)階段、驗(yàn)證階段、發(fā)布階段和生命周期階段），四個(gè)個(gè)決策評(píng)審點(diǎn)（概念階段決策評(píng)審點(diǎn)、計(jì)劃階段決策評(píng)審點(diǎn)、可獲得性決策評(píng)審點(diǎn)和生命周期終止決策評(píng)審點(diǎn)）以及六個(gè)技術(shù)評(píng)審點(diǎn)，具體可以參考圖 2。IPD 流程是一個(gè)階段性模型，具有瀑布模型的影子。該模型通過使用全面而又復(fù)雜的流程來把一個(gè)龐大而又復(fù)雜的系統(tǒng)進(jìn)行分解并降低風(fēng)險(xiǎn)。一定程度上，該模型是通過流程成本來提高整個(gè)產(chǎn)品的質(zhì)量并獲得市場的占有。由于該流程沒有定義如何進(jìn)行流程回退的機(jī)制，因此對(duì)于需求經(jīng)常變動(dòng)的項(xiàng)目該流程就顯得不大適合了。并且對(duì)于一些小的項(xiàng)目，也不是非常適合使用該流程。圖2 IPD 流程示意圖 三、流程與技術(shù) 流程和成功不是等價(jià)的。沒有流程就成功是不可能得到保證，但有了流程并不意味著肯定能夠成功。這恐怕是很多迷信于流程的人所不能接受的。但這的確是個(gè)事實(shí)。記得有個(gè)做了將近 30 多年的需求分析專家說過：即使是一個(gè)已經(jīng)達(dá)到 CMM4 級(jí)的公司，也完全有可能做不好需求分析。為什么？技術(shù)，技術(shù)是成功的另外一個(gè)必要條件。就好比現(xiàn)在你要從上海到北京去，流程給你指出了最短的路徑，技術(shù)提供給你最快的交通工具。兩者結(jié)合就是完美。對(duì)于軟件開發(fā)來說，要保證軟件的質(zhì)量，需要掌握多方面的技術(shù)，包括分析技術(shù)、設(shè)計(jì)技術(shù)、編碼技術(shù)和測試技術(shù)等等。在國內(nèi)有一個(gè)普遍的非正?，F(xiàn)象，就是大家覺得只有編程能力才是玩電腦的真正技能。就好像造一套房子，其它都不重要，只要磚瓦匠有高超的技能就行了。盡管這個(gè)比喻會(huì)打擊很多程序員的自尊心，但這的確是一個(gè)事實(shí)。我們?nèi)鄙傧到y(tǒng)級(jí)的工程師，在分析和設(shè)計(jì)方面的工作做得很不扎實(shí)。需求是一個(gè)項(xiàng)目的靈魂。模棱兩可的需求帶來不可避免的后果便是返工 —— 重做一些你認(rèn)為已做好的事情。返工會(huì)耗費(fèi)開發(fā)總費(fèi)用的 4 0 %，而 7 0 % ～ 8 5 % 的重做是由于需求方面的錯(cuò)誤所導(dǎo)致的（ l e ff i n g w e l l1 9 9 7 ）【 10 】。想像一下如果你能減少一半的返工會(huì)是怎樣的情況？你能更快地開發(fā)出產(chǎn)品，在同樣的時(shí)間內(nèi)開發(fā)更多、更好的產(chǎn)品，甚至能偶爾回家休息休息。在《軟件需求》一書中關(guān)于如何進(jìn)行需求分析給出了比較詳細(xì)的介紹【 7 】，RUP 中關(guān)于需求的指導(dǎo)也是很實(shí)用的。設(shè)計(jì)是最能體現(xiàn)一個(gè)工程師能力和水平的環(huán)節(jié)。一個(gè)好的設(shè)計(jì)基本上決定了產(chǎn)品的最終質(zhì)量。設(shè)計(jì)是把需求轉(zhuǎn)換成系統(tǒng)的一個(gè)關(guān)鍵步驟，它需要從自然語言描述的需求中尋找出設(shè)計(jì)的基礎(chǔ)單元，構(gòu)建出整個(gè)系統(tǒng)的構(gòu)架。在 RUP 中關(guān)于系統(tǒng)構(gòu)架師和設(shè)計(jì)師的定位是相當(dāng)高的。關(guān)于設(shè)計(jì)方面的技能涉及面是很廣的，包括傳統(tǒng)的結(jié)構(gòu)化設(shè)計(jì)到面向?qū)ο笤O(shè)計(jì)。設(shè)計(jì)人員需要掌握一定的建模技術(shù)。UML 是國際上比較流行的一種建模語言【 11 】。在嵌入式方面，SDL 也是一種非常好的選擇?！对O(shè)計(jì)模式》是在設(shè)計(jì)思想方面總結(jié)的非常出色的一本書【 6 】，作為一名設(shè)計(jì)人員（尤其是面向?qū)ο笤O(shè)計(jì)人員）必須要好好研究一下。但是對(duì)這些模式的應(yīng)用應(yīng)當(dāng)講究一種自然的應(yīng)用，千萬不要因?yàn)槟Ｊ蕉ピO(shè)計(jì)模式，否則會(huì)適得其反?，F(xiàn)在的程序員熱中于掌握多種編程語言，或者講究語言的過分技巧化，而往往忽略了編程語言的規(guī)范化。不規(guī)范的語言應(yīng)用給程序的可理解性、可維護(hù)性以及可測試性帶來了大的傷害，進(jìn)而損害了產(chǎn)品的質(zhì)量。某公司曾對(duì)中國程序員和印度程序員做過一個(gè)測驗(yàn)，這個(gè)測驗(yàn)要求參加者對(duì)一組數(shù)進(jìn)行排序。測試結(jié)果發(fā)現(xiàn)，印度程序員設(shè)計(jì)的程序使用的算法并不是最優(yōu)，但卻是最不容易出錯(cuò)的，并且?guī)讉€(gè)程序員寫出來的代碼如出一轍。而幾個(gè)中國程序員寫出的代碼，有的非常漂亮，很精練，效率很高；有的卻很冗雜，還有錯(cuò)誤。如果大家是在做研究性的項(xiàng)目或純粹興趣性的項(xiàng)目，那么充分發(fā)揮自己的編程天才也無可厚非。然而，對(duì)于一個(gè)軟件公司，產(chǎn)品最終是要交給用戶的，需要遵循的是一個(gè)軟件產(chǎn)品的開發(fā)工程。因此這類軟件的開發(fā)需要遵循一定的編程規(guī)范，畢竟開發(fā)的軟件不是自己用，還需要和別人的集成，還需要給以后版本重用和維護(hù)。測試的技術(shù)將在第五節(jié)進(jìn)行闡述?？傊鞒毯荜P(guān)鍵，技術(shù)也很重要，我的觀點(diǎn)是：魚和熊掌，兩者都不能放。四、全面質(zhì)量管理 自從 Deming 的全面質(zhì)量管理（ TQM ）原則在日本工業(yè)界獲得了巨大成功之后，這個(gè)原則迅速被傳播到了世界各個(gè)地方，同樣，全面質(zhì)量管理原則也被應(yīng)用到了軟件開發(fā)當(dāng)中。如前面提到的，軟件開發(fā)也是一個(gè)工程性的工作，因此必須提高整個(gè)工程的質(zhì)量。產(chǎn)業(yè)界的大量研究（ TRW 、 Nippon Electric 和 Mitre Corp. 以及其它一些公司）表明設(shè)計(jì)活動(dòng)引入的錯(cuò)誤占軟件過程中出現(xiàn)所有錯(cuò)誤（和最終的缺陷）數(shù)量的 50 ％到 65 ％。根據(jù) IBM 的研究表明，假定在分析階段發(fā)現(xiàn)的錯(cuò)誤其改正成本為 1 個(gè)單位的話，那么在測試之前（設(shè)計(jì)編碼階段）發(fā)現(xiàn)一個(gè)錯(cuò)誤的修改成本約為 6.5 個(gè)貨幣單位，在測試時(shí)（集成測試，系統(tǒng)測試和驗(yàn)收測試）發(fā)現(xiàn)一個(gè)錯(cuò)誤的修改成本約為 15 個(gè)貨幣單位，而在發(fā)布之后（已經(jīng)交到用戶手上）發(fā)現(xiàn)一個(gè)錯(cuò)誤的修改成本約為 60 到 100 個(gè)貨幣單位。同樣該比例也適用用于發(fā)現(xiàn)一個(gè)錯(cuò)誤需要的時(shí)間。我們可以看下面兩條曲線圖： 圖3 缺陷代價(jià)曲線 為了提高產(chǎn)品質(zhì)量，縮短產(chǎn)品開發(fā)進(jìn)度，節(jié)約產(chǎn)品開發(fā)成本，必須盡早的進(jìn)行產(chǎn)品質(zhì)量控制。全面質(zhì)量控制要求在過程的每個(gè)階段每個(gè)步驟上都要進(jìn)行嚴(yán)格的驗(yàn)證和確認(rèn)活動(dòng)。什么是驗(yàn)證？ 驗(yàn)證 就是要用數(shù)據(jù)證明我們是不是在正確的制造產(chǎn)品。注意這里強(qiáng)調(diào)的是過程的正確行【 12 】。什么是確認(rèn)？ 確認(rèn) 就是要用數(shù)據(jù)證明我們是不是制造了正確的產(chǎn)品。注意這里強(qiáng)調(diào)的是結(jié)果的正確性。IEEE 給出的驗(yàn)證和確認(rèn)過程可以用下圖來表示。驗(yàn)證和確認(rèn)是一個(gè)廣泛的概念，感興趣的讀者可以參考 IEEE Std 1012-1998。
圖4 驗(yàn)證和確認(rèn)模型 五、關(guān)注測試 軟件測試是軟件質(zhì)量控制中的關(guān)鍵活動(dòng)。業(yè)界的統(tǒng)計(jì)數(shù)據(jù)表明，測試的成本大約占軟件開發(fā)總成本的 50 ％左右。軟件測試的目的是要發(fā)現(xiàn)軟件中的錯(cuò)誤。一個(gè)好的測試是發(fā)現(xiàn)至今沒有被發(fā)現(xiàn)的錯(cuò)誤。傳統(tǒng)的軟件測試專注于動(dòng)態(tài)測試范疇，如：單元測試，集成測試和系統(tǒng)測試。而測試工程的發(fā)展已經(jīng)進(jìn)入到了全流程的測試，包括開發(fā)過程前期的靜態(tài)測試。一般我們可以把測試分為白盒測試和黑盒測試。白盒測試 ：顧名思義，白盒測試應(yīng)當(dāng)是透明的。的確，該類測試是根據(jù)程序代碼的內(nèi)部邏輯結(jié)構(gòu)來設(shè)計(jì)測試用例進(jìn)行測試。那么什么是測試用例？ 一個(gè) 測試用例 就是一個(gè)文檔，描述輸入、動(dòng)作、或者時(shí)間和一個(gè)期望的結(jié)果，其目的是確定應(yīng)用程序的某個(gè)特性是否正常的工作。黑盒測試 ：看了白盒測試的解釋，我想你很快就能猜出黑盒測試是不考慮程序內(nèi)部結(jié)構(gòu)情況的。事實(shí)上也是這樣。黑盒測試是根據(jù)規(guī)格說明書進(jìn)行的測試。規(guī)格說明書 記錄了用戶的需求。比如用戶希望在編輯器中增加查找功能，那么我們把該需求寫入規(guī)格說明書，根據(jù)該項(xiàng)要求，直接調(diào)用應(yīng)用程序的該項(xiàng)功能進(jìn)行測試，而不管其內(nèi)部是用什么算法實(shí)現(xiàn)的。白盒和黑盒這兩類測試是從完全不同的出發(fā)點(diǎn)，并且是兩個(gè)完全對(duì)立點(diǎn)，反映了事物的兩個(gè)極端，兩種方法各有側(cè)重，不能替代。但是在現(xiàn)代測試?yán)砟钪校@兩種測試往往不是決然分開的，一般在白盒測試中交叉使用黑盒測試的方法，在黑盒測試中交叉使用白盒測試的方法。常見的白盒測試是單元測試。單元測試 是測試中最小單位的測試。簡而言之，就是拿一個(gè)函數(shù)出來，加上驅(qū)動(dòng)模塊，樁模塊，讓它能夠運(yùn)行起來，然后設(shè)計(jì)一些用例測試其內(nèi)部的控制點(diǎn)（如：條件判斷點(diǎn)，循環(huán)點(diǎn)，選擇分支點(diǎn)等）。驅(qū)動(dòng)模塊 是模擬調(diào)用被測函數(shù)的函數(shù)。樁函數(shù) 是模擬當(dāng)前測試函數(shù)所調(diào)用的函數(shù)。常見的黑盒測試包括：集成測試，系統(tǒng)測試。集成測試 是在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求（如根據(jù)結(jié)構(gòu)圖）組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測試。實(shí)踐表明，一些模塊雖然能夠單獨(dú)地工作，但并不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實(shí)現(xiàn)。系統(tǒng)測試 的目的在于通過與系統(tǒng)的需求定義作比較，發(fā)現(xiàn)軟件與系統(tǒng)定義不符合或與之矛盾的地方。系統(tǒng)測試的測試用例應(yīng)根據(jù)需求分析說明書來設(shè)計(jì)，并在實(shí)際使用環(huán)境下來運(yùn)行。系統(tǒng)測試的內(nèi)容極其廣泛，包括功能測試、協(xié)議測試、性能測試、壓力測試、容量測試等等。有關(guān)測試方面的概念可以參考本人已出版的《軟件測試技術(shù)概論》。軟件測試是產(chǎn)品最終交付到用戶之前的最后一道防線，有著舉足輕重的地位。然而，做好軟件測試卻是不容易的，一方面你需要同時(shí)掌握軟件開發(fā)的技能和軟件測試方面的技能；另一方面產(chǎn)品必須給予測試充分的獨(dú)立性和資源保證。六、成功的鐵三角 在一個(gè)軟件企業(yè)中，如果能夠良性的發(fā)展，必須關(guān)注組織，流程和人三者之間的關(guān)系。組織是流程成功實(shí)施的保障，好的組織結(jié)構(gòu)能夠有效的促進(jìn)流程的實(shí)施；流程對(duì)于產(chǎn)品的成功有著關(guān)鍵的作用，一個(gè)適合于組織特點(diǎn)和產(chǎn)品特點(diǎn)的流程能夠極大的提高產(chǎn)品開發(fā)的效率和產(chǎn)品質(zhì)量，反之則會(huì)拖延產(chǎn)品開發(fā)進(jìn)度，并且質(zhì)量也無法得到保證；對(duì)企業(yè)來說，人是最寶貴的財(cái)富，它們是技術(shù)的載體。對(duì)于一個(gè)軟件公司來說，無論是開發(fā)人員還是測試人員，都非常關(guān)心其今后的發(fā)展通道，如果有一條清晰的技術(shù)發(fā)展線為其指明今后的職業(yè)發(fā)展方向的話，這可以大大激勵(lì)員工的士氣和工作積極性。另外技術(shù)發(fā)展的方向應(yīng)該與現(xiàn)在的開發(fā)流程和規(guī)范相結(jié)合，這樣有利于專業(yè)技能的提高?？傊M織，流程和人這三者是一個(gè)企業(yè)成功的鐵三角，理想的情況下它們彼此促進(jìn)，糟糕的情況下它們彼此制約。七、國際上流行的質(zhì)量標(biāo)準(zhǔn) 最早進(jìn)入國內(nèi)的質(zhì)量標(biāo)準(zhǔn)是 ISO 系列。在軟件方面主要使用 ISO9000 系列標(biāo)準(zhǔn)。ISO9000 是一個(gè)非常完整的標(biāo)準(zhǔn)，并且定義了供應(yīng)商設(shè)計(jì)和交付一個(gè)有質(zhì)量產(chǎn)品的能力所需要的所有元素。ISO9002 涵蓋了對(duì)供應(yīng)商控制設(shè)計(jì)和開發(fā)活動(dòng)所認(rèn)為重要的質(zhì)量標(biāo)準(zhǔn)。ISO9003 用于證明供應(yīng)商在檢視和測試期間檢測和控制產(chǎn)品不一致性的能力。ISO9004 描述和 ISO9001 、 ISO9002 和 ISO9003 相關(guān)的質(zhì)量標(biāo)準(zhǔn)，并提供了一個(gè)完整的質(zhì)量查檢表。軟件能力成熟度模型是目前國內(nèi)軟件企業(yè)中非常受歡迎的一個(gè)質(zhì)量標(biāo)準(zhǔn)。并且該標(biāo)準(zhǔn)已經(jīng)成為業(yè)界一個(gè)事實(shí)上的標(biāo)準(zhǔn)。CMM 為軟件組織提供了一個(gè)指導(dǎo)性的管理框架。在這個(gè)框架的指導(dǎo)下： ?? 軟件組織可以對(duì)其軟件開發(fā)、維護(hù)過程獲得控制。?? 軟件組織可以推進(jìn)其軟件工程更為科學(xué)、推進(jìn)軟件過程管理更為卓越。?? CMM 通過確定當(dāng)前軟件過程管理的成熟度，通過標(biāo)識(shí)軟件的質(zhì)量和過程改進(jìn)中關(guān)鍵的、要害的問題，可以指導(dǎo)軟件組織選擇正確的軟件過程改進(jìn)策略。?? CMM 將其焦點(diǎn)，聚焦在一系列具體的軟件過程活動(dòng)上，并以侵略方式（ Aggressively ）達(dá)到這些活動(dòng)。一個(gè)軟件組織就可以穩(wěn)定地、持續(xù)地改進(jìn)其整個(gè)軟件組織過程，使得其軟件過程管理能力取得持續(xù)地、持久地不斷爭長提高。在 CMM 中，把軟件工廠分為五個(gè)等級(jí)：初始級(jí)、可重復(fù)級(jí)、已定義級(jí)、管理級(jí)和優(yōu)化級(jí)。其中： 初始級(jí) ：軟件過程是未加定義的隨意過程，項(xiàng)目的執(zhí)行是隨意甚至是混亂的。也許，有些企業(yè)制定了一些軟件工程規(guī)范，但若這些規(guī)范未能覆蓋基本的關(guān)鍵過程要求，且執(zhí)行沒有政策、資源等方面的保證時(shí)，那么它仍然被視為初始級(jí)?？芍貜?fù)級(jí) ：人們根據(jù)多年的經(jīng)驗(yàn)和教訓(xùn)，總結(jié)出軟件開發(fā)的首要問題不是技術(shù)問題而是管理問題。因此，第二級(jí)的焦點(diǎn)集中在軟件管理過程上。一個(gè)可管理的過程則是一個(gè)可重復(fù)的過程，可重復(fù)的過程才能逐漸改進(jìn)和成熟。可重復(fù)級(jí)的管理過程包括了需求管理、項(xiàng)目管理、質(zhì)量管理、配置管理和子合同管理五個(gè)方面；其中項(xiàng)目管理過程又分為計(jì)劃過程和跟蹤與監(jiān)控過程。通過實(shí)施這些過程，從管理角度可以看到一個(gè)按計(jì)劃執(zhí)行的且階段可控的軟件開發(fā)過程。已定義級(jí)： 要求制定企業(yè)范圍的工程化標(biāo)準(zhǔn)，并將這些標(biāo)準(zhǔn)集成到企業(yè)軟件開發(fā)標(biāo)準(zhǔn)過程中去。所有開發(fā)的項(xiàng)目需根據(jù)這個(gè)標(biāo)準(zhǔn)過程裁剪出與項(xiàng)目適宜的過程，并且按照過程執(zhí)行。過程的裁剪不是隨意的，在使用前必須經(jīng)過企業(yè)有關(guān)人員的批準(zhǔn)。管理級(jí) ：所有過程需建立相應(yīng)的度量方式，所有產(chǎn)品的質(zhì)量（包括工作產(chǎn)品和提交給用戶的最終產(chǎn)品）需要有明確的度量指標(biāo)。這些度量應(yīng)是詳盡的，且可用于理解和控制軟件過程和產(chǎn)品。量化控制將使軟件開發(fā)真正成為一種工業(yè)生產(chǎn)活動(dòng)。優(yōu)化級(jí)： 的目標(biāo)是達(dá)到一個(gè)持續(xù)改善的境界。所謂持續(xù)改善是指可以根據(jù)過程執(zhí)行的反饋信息來改善下一步的執(zhí)行過程，即優(yōu)化執(zhí)行步驟。如果企業(yè)達(dá)到了第五級(jí)，就表明該企業(yè)能夠根據(jù)實(shí)際的項(xiàng)目性質(zhì)、技術(shù)等因素，不斷調(diào)整軟件生產(chǎn)過程以求達(dá)到最佳。美國國防部規(guī)定，重要性級(jí)別高的軟件應(yīng)該由質(zhì)量級(jí)別高的企業(yè)承擔(dān)。不同等級(jí)的軟件公司提交的軟件，其軟件質(zhì)量也相差很大，國外的一份統(tǒng)計(jì)資料如下： 表 1 、 CMM 級(jí)別與軟件質(zhì)量關(guān)系表格 每千行軟件的缺陷數(shù)目
軟件過程成熟度等級(jí)
軟件準(zhǔn)時(shí)提交的百分比
每人每月生產(chǎn)的程序行數(shù)
軟件需要返工的百分比
平均軟件失效時(shí)間（近似）

大于 10
初始級(jí)
<=50
Z
>=45
2 到 60 分鐘

小于 10
可重復(fù)級(jí)
90
1.5Z
20
1-160 小時(shí)

小于 1
已定義級(jí)
99
2.5Z
10
不確定

小于 0.1
管理級(jí)
降低開發(fā)時(shí)間到 1/2
5 Z
5
不確定

小于 0.01
優(yōu)化級(jí)
降低開發(fā)時(shí)間到 1/4
10Z
<=2
近似完全可靠
對(duì)于很多已經(jīng)推行或者準(zhǔn)備推行 CMM 的公司來說，CMM 的起步是很難的，因此 Humphrey 又提出了 PSP （ Person Software Process ）和 TSP （ Team Software Process ）【 2 】【 3 】。CMM 是過程改善的第一步，它提供了評(píng)價(jià)組織的能力、識(shí)別優(yōu)先改善需求和追蹤改善進(jìn)展的管理方式【 1 】。企業(yè)只有開始 CMM 改善后，才能接受需要規(guī)劃的事實(shí)，認(rèn)識(shí)到質(zhì)量的重要性，才能注重對(duì)員工經(jīng)常進(jìn)行培訓(xùn)，合理分配項(xiàng)目人員，并且建立起有效的項(xiàng)目小組。然而，它實(shí)現(xiàn)的成功與否與組織內(nèi)部有關(guān)人員的積極參加和創(chuàng)造性活動(dòng)密不可分。PSP 能夠指導(dǎo)軟件工程師如何保證自己的工作質(zhì)量，估計(jì)和規(guī)劃自身的工作，度量和追蹤個(gè)人的表現(xiàn)，管理自身的軟件過程和產(chǎn)品質(zhì)量。經(jīng)過 PSP 學(xué)習(xí)和實(shí)踐的正規(guī)訓(xùn)練，軟件工程師們能夠在他們參與的項(xiàng)目工作之中充分運(yùn)用 PSP，從而有助于 CMM 目標(biāo)的實(shí)現(xiàn)。TSP 結(jié)合了 CMM 的管理方法和 PSP 的工程技能，通過告訴軟件工程師如何將個(gè)體過程結(jié)合進(jìn)小組軟件過程，并將后者與組織進(jìn)而整個(gè)管理系統(tǒng)相聯(lián)系；通過告訴管理層如何支持和授權(quán)項(xiàng)目小組，堅(jiān)持高質(zhì)量的工作，并且依據(jù)數(shù)據(jù)進(jìn)行項(xiàng)目的管理，向組織展示如何應(yīng)用 CMM 的原則和 PSP 的技能去生產(chǎn)高質(zhì)量的產(chǎn)品。軟件的生產(chǎn)過程及其它的許多子過程、軟件的開發(fā)者和用戶、以及系統(tǒng)的使用中存在著巨大的變化和不同，要使一個(gè)軟件過程對(duì)軟件生產(chǎn)的改善真正有所幫助，其框架應(yīng)是由 CMM 、 TSP 和 PSP 組成的一個(gè)完整體系，即從組織、群組和個(gè)人三個(gè)層次進(jìn)行良好的軟件工程和管理實(shí)踐的指導(dǎo)和支持?？偠灾?，單純實(shí)施 CMM，永遠(yuǎn)不能真正做到能力成熟度的升級(jí)，只有將實(shí)施 CMM 與實(shí)施 PSP 和 TSP 有機(jī)地結(jié)合起來，才能發(fā)揮最大的效力。八、如何起步？ 質(zhì)量改進(jìn)需要花費(fèi)成本，因此改進(jìn)的途徑需要視不同公司的規(guī)模、業(yè)務(wù)、財(cái)務(wù)狀況、人員技術(shù)水平等多方面綜合進(jìn)行考慮。一般建議中型以上的較大的軟件公司實(shí)施 CMM 體系。而對(duì)于一些小型的軟件公司可以采取比較實(shí)際的，相對(duì)成本較少，且容易操作的方面進(jìn)行，這些方面大致如下： ?? 實(shí)施簡潔的開發(fā)過程體系，根據(jù)不同業(yè)務(wù)特點(diǎn)可以選擇瀑布模型，迭代模型等，并在這些模型上進(jìn)行適當(dāng)?shù)淖兓赃m應(yīng)于短平快的產(chǎn)品開發(fā)特點(diǎn)。?? 提高需求分析和設(shè)計(jì)方面的技術(shù)，例如：原型法技術(shù)，分析模式，設(shè)計(jì)模式，面向?qū)ο笤O(shè)計(jì)，UML 等； ?? 加強(qiáng)文檔化工作。文檔是經(jīng)驗(yàn)的保留，對(duì)于一個(gè)企業(yè)要想獲得長期的發(fā)展，必須加強(qiáng)文檔化工作； ?? 加強(qiáng)編程規(guī)范工作； ?? 進(jìn)行適當(dāng)?shù)臏y試工作，建議進(jìn)行單元測試和系統(tǒng)測試； ?? 實(shí)施配置管理工作，加強(qiáng)版本控制； ?? 開展走讀、評(píng)審和檢視活動(dòng)，尤其要加強(qiáng)代碼走讀，建議進(jìn)行每日交叉走讀活動(dòng)； ?? 進(jìn)行簡單的度量分析獲得；建議實(shí)施 PSP 活動(dòng)；

性能測試包括哪些方面

性能測試包括負(fù)載測試和壓力測試。
性能測試是通過自動(dòng)化的測試工具模擬多種正常、峰值以及異常負(fù)載條件來對(duì)系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測試。負(fù)載測試和壓力測試都屬于性能測試，兩者可以結(jié)合進(jìn)行。通過負(fù)載測試，確定在各種工作負(fù)載下系統(tǒng)的性能，目標(biāo)是測試當(dāng)負(fù)載逐漸增加時(shí)，系統(tǒng)各項(xiàng)性能指標(biāo)的變化情況。壓力測試是通過確定一個(gè)系統(tǒng)的瓶頸或者不能接受的性能點(diǎn)，來獲得系統(tǒng)能提供的最大服務(wù)級(jí)別的測試。
性能測試在軟件的質(zhì)量保證中起著重要的作用，它包括的測試內(nèi)容豐富多樣。中國軟件評(píng)測中心將性能測試概括為三個(gè)方面：應(yīng)用在客戶端性能的測試、應(yīng)用在網(wǎng)絡(luò)上性能的測試和應(yīng)用在服務(wù)器端性能的測試。通常情況下，三方面有效、合理的結(jié)合，可以達(dá)到對(duì)系統(tǒng)性能全面的分析和瓶頸的預(yù)測。

關(guān)于App的測試，和傳統(tǒng)軟件測試有哪些區(qū)別？的介紹就到這里，以上就是小編整理的App的測試，和傳統(tǒng)軟件測試有哪些區(qū)別？全部內(nèi)容了，歡迎大家留言討論。訪問培訓(xùn)啦了解更多相關(guān)內(nèi)容（本文共20673字）

985大學(xué) 211大學(xué) 全國院校對(duì)比 專升本