|
找專業(yè)的人,做專業(yè)的事 | 為您提供設(shè)計(jì)管家服務(wù) 最近25學(xué)堂在簡書上看到一篇比較完整的手機(jī)app開發(fā)、測試、視覺設(shè)計(jì)、交互設(shè)計(jì)的完整流程。作者：小叮當(dāng)doe。 其實(shí)，之前25學(xué)堂也分享了很多關(guān)于APP設(shè)計(jì)、APP開發(fā)、APP測試的流程。估計(jì)也有很多人還不是很明白。 比如之前分享的： 1、UIMAX設(shè)計(jì)師的工作分享：完整的交互設(shè)計(jì)流程詮釋 2、不懂APP開發(fā)的你，必知的整套APP項(xiàng)目的開發(fā)步驟 3、APP重設(shè)計(jì)的工作流程以及APP產(chǎn)品的re-design思路 4、APP設(shè)計(jì)干貨，手機(jī)UI界面設(shè)計(jì)思路解析與流程 5、產(chǎn)品經(jīng)理思維流程：看產(chǎn)品、想產(chǎn)品、做產(chǎn)品
從整個(gè)APP產(chǎn)品大局來看： 產(chǎn)品的研發(fā)流程分為四個(gè)步驟：產(chǎn)品定義——交互設(shè)計(jì)——開發(fā)——測試。 這四個(gè)步驟也分別對(duì)應(yīng)研發(fā)中的四個(gè)角色：產(chǎn)品經(jīng)理——設(shè)計(jì)師——開發(fā)工程師——測試工程師。
1、產(chǎn)品定義階段的目標(biāo)就是確定用戶場景，定義產(chǎn)品的功能和范圍。 2、而設(shè)計(jì)師需要根據(jù)這些用戶場景和功能范圍進(jìn)行交互設(shè)計(jì)。 3、開發(fā)工程師將會(huì)根據(jù)產(chǎn)品經(jīng)理和設(shè)計(jì)師的方案進(jìn)行寫代碼，把這個(gè)方案實(shí)現(xiàn)成可用的產(chǎn)品。 4、之后的再由測試工程師進(jìn)行產(chǎn)品測試，以保證產(chǎn)品達(dá)到了產(chǎn)品經(jīng)理和設(shè)計(jì)師的這個(gè)要求。
下面我們就來看看產(chǎn)品定義的流程： 一、定義產(chǎn)品需求在這里要談?wù)摰闹饕怯脩粜枨蠛彤a(chǎn)品需求。
1.1、用戶需求和產(chǎn)品需求 首先必須要搞清的是用戶需求不等同于產(chǎn)品需求。 用戶需求，簡單來說是用戶希望同構(gòu)使用某一款產(chǎn)品來實(shí)現(xiàn)和滿足某種需要。如安全、娛樂、溝通、交友等。用戶需求是用戶對(duì)某類產(chǎn)品真實(shí)需要的反應(yīng)。 而產(chǎn)品需求，是某一類產(chǎn)品或服務(wù)能夠滿足用戶需要的集合。也就是說，用戶需求并不完全傳遞到產(chǎn)品需求當(dāng)中去。而產(chǎn)品需求的獲取渠道也不僅僅是用戶需求。 1.2、獲取產(chǎn)品需求的方式 （1）用戶需求：用戶需求是產(chǎn)品需求的核心來源。但并不是所有的用戶需求都能轉(zhuǎn)化為產(chǎn)品需求。用戶需求需要子可行性和必要性驗(yàn)證上，才可以轉(zhuǎn)化為產(chǎn)品需求。 （2）相關(guān)利益合作伙伴：開發(fā)商、咨詢機(jī)構(gòu)、制造商等等。他們通過對(duì)市場的研究分析和對(duì)運(yùn)營所積累的產(chǎn)品需求，是設(shè)計(jì)分析產(chǎn)品需求很好的參考。 （3）競品分析：對(duì)競爭對(duì)手主要產(chǎn)品進(jìn)行對(duì)標(biāo)研究，分析其產(chǎn)品的成敗關(guān)鍵和發(fā)展趨勢，了解市場對(duì)類似產(chǎn)品的反饋。 （4）標(biāo)桿市場：標(biāo)桿市場是國內(nèi)外在同類產(chǎn)品上運(yùn)營比較成功的熱門行業(yè)，通過對(duì)標(biāo)桿市場中知名企業(yè)所運(yùn)營的相近產(chǎn)品的功能進(jìn)行剖析?？梢粤私鈬H與國內(nèi)在該類產(chǎn)品上的先進(jìn)做法。 （5）企業(yè)內(nèi)部產(chǎn)品研討會(huì)、員工體驗(yàn)及內(nèi)部專家評(píng)估。
1.3、用戶需求的提取與挖掘的方式 了解用戶需求的有效方式是用戶研究，這是用戶中心設(shè)計(jì)流程的第一步。其主要研究方式是：用戶訪談、用戶觀察、問卷調(diào)研、焦點(diǎn)小組、眼動(dòng)實(shí)驗(yàn)等等。并對(duì)由此得到的信息與數(shù)據(jù)進(jìn)行處理和分析。從中提取制作出初步的用戶需求文檔。 顯然這些需求是不夠的。這些需求僅僅是用戶在現(xiàn)有需求上的反饋。此外，設(shè)計(jì)師可以利用在用戶研究階段所生成的人物角色（人物畫像）這個(gè)工具，并放置到具體場景中，從而挖掘用戶可能的潛在需求。 （1）通過用戶研究直接獲取 用戶研究階段可能會(huì)出現(xiàn)各式各樣的問卷及數(shù)據(jù)列表。這些數(shù)據(jù)的收集活動(dòng)并不難，所需要付出的只是耐心和時(shí)間。 為了更多更好的獲取初步用戶的需求，用戶研究員需要在問卷調(diào)查的問卷設(shè)計(jì) 、用戶訪談、焦點(diǎn)小組等的腳本設(shè)計(jì)中，明確哪些問題或者選項(xiàng)是為需求而設(shè)置的，以便后續(xù)階段的整理。 （2）在場景中運(yùn)用人物角色進(jìn)行挖掘。 人物角色的來源、概念及功能：人物角色不是真實(shí)的人，但它是基于我們觀察到的那些真實(shí)的人的行為和動(dòng)機(jī)，并且在整個(gè)設(shè)計(jì)過程中代表真實(shí)的人，是在人種學(xué)調(diào)查收集到的世紀(jì)用戶行為數(shù)據(jù)的基礎(chǔ)上形成的綜合模型。在研究階段我們觀察用戶的行為模式，在建模階段將其模式化，最后生成人物角色。 也就是說人物角色源自于用戶研究。研究人員通過用戶研究，通過一定的標(biāo)準(zhǔn)將眾多的用戶進(jìn)行細(xì)分，從而得到不同的細(xì)分用戶群組。 細(xì)分的用戶群組經(jīng)過一定的評(píng)估、調(diào)整，從而確定細(xì)分角色群組。角色群組經(jīng)過一定的潤色。諸如為每個(gè)角色群組賦予具有代表性的照片、名稱、職業(yè)、性格等鮮明的人物屬性，從而形成不同的人物角色。 人物角色通常因其重要程度及特定定義為：首要人物角色、次要人物角色、不重要的人物角色、排斥的人物角色。 通過建立人物角色，從而將用戶研究結(jié)果以一種簡單直觀但又非常有效的方式使設(shè)計(jì)團(tuán)隊(duì)成員（決策人員、產(chǎn)品經(jīng)理、交互設(shè)計(jì)師、視覺設(shè)計(jì)師）等對(duì)大家所面對(duì)的客戶群形成一致的了解。 場景的概念與作用：用戶角色是死的，靜態(tài)的東西，只有將其放到一定的場景中去，才會(huì)鮮活起來，與產(chǎn)品產(chǎn)生交互。 場景是人物角色與產(chǎn)品進(jìn)行交互的“理想化”情景。它講述的是每個(gè)人物角色如何與產(chǎn)品進(jìn)行交互的故事。每個(gè)人物角色都將對(duì)應(yīng)一個(gè)場景，甚至更多，以求覆蓋用戶使用場景的各種情形。 在場景中使用人物角色進(jìn)行需求的挖掘:針對(duì)每個(gè)人物角色，設(shè)計(jì)合理的場景，然后集合相關(guān)的工作人員（不僅僅是交互和視覺設(shè)計(jì)師）一起進(jìn)行頭腦風(fēng)暴。再此階段每個(gè)人要有深度的同理心，并在每個(gè)關(guān)節(jié)點(diǎn)將所能想到的可能性完全說出來，記錄下來，此時(shí)的氣氛也是不加約束和不帶批判的。 在此以時(shí)間為軸“生活中的一天”為例，來針對(duì)手機(jī)瀏覽器產(chǎn)品利用人物角色來進(jìn)行需求挖掘。譬如： 早晨起來，剛起床：會(huì)看天氣預(yù)報(bào)、日歷中可能涉及的功能：天氣查詢、日歷。 吃早餐的時(shí)候：可能會(huì)看新聞、郵件以及自己的博客。這樣就會(huì)設(shè)計(jì)到新聞、微博以及郵箱。 以及交通途中：上午辦公室：中午午餐：下午辦公室：下班前：下班途中：餐廳里：家中：被窩里等等各種狀態(tài)下來挖掘可能用到的功能。 每個(gè)人物角色通過一個(gè)或多個(gè)場景的挖掘，要對(duì)其所涉及到的功能進(jìn)行羅列，并根據(jù)其在每個(gè)人物角色的重要性定義每個(gè)功能的權(quán)重，并建立excel檔。
1.4、用戶需求提升為產(chǎn)品需求，由此得出產(chǎn)品功能需求列表
以上得出的用戶需求，并不能直接轉(zhuǎn)入產(chǎn)品需求，需要經(jīng)過一定的評(píng)估和帥選考察其可行性和必要性。 可行性：目前的技術(shù)和企業(yè)資源是否有能力，是否能在現(xiàn)行的情況下，與進(jìn)度時(shí)間表等現(xiàn)實(shí)條件下開發(fā)出完全滿足用戶需求的產(chǎn)品。 必要性：用戶的這些需求是否有需要滿足，滿足這些需求企業(yè)需要付出的代價(jià)，以及是否有足夠的企業(yè)效益來支撐市場的運(yùn)營。 經(jīng)過上述驗(yàn)證，并結(jié)合前面所敘述的相關(guān)利益合作伙伴、競品分析、標(biāo)桿市場及企業(yè)內(nèi)部研討會(huì)等所得到的用戶需求，從而得到完整的用戶需求列表。 在此所有的產(chǎn)品需求都轉(zhuǎn)化為產(chǎn)品功能。工作人員可以將之前用戶研究階段收集的功能需求合并到后來利用任務(wù)角色在場景下挖掘的需求列表中。他們本質(zhì)上也相應(yīng)對(duì)應(yīng)著不同的人物角色。 在這里，角色的權(quán)重（可以根據(jù)首要人物角色、次要人物角色、不重要人物角色等分成3點(diǎn)量表或者5點(diǎn)量表）與對(duì)應(yīng)的任務(wù)的權(quán)重的乘積，就是功能總的重要程度。
二、交互設(shè)計(jì)流程（一）交互設(shè)計(jì)三段式 草圖——低保真原型——高保真原型  我們看到的這張圖實(shí)際上他畫的相當(dāng)規(guī)整，它已經(jīng)是一個(gè)完整的產(chǎn)品架構(gòu)圖。但是我們工作中的話可能只是信手拈來，草草的畫上幾筆，這些都沒關(guān)系，草圖強(qiáng)調(diào)的就是能快速地將想法具體化，然后和其他同事進(jìn)行討論。 低保真原型圖：就是在草圖的基礎(chǔ)上，通過計(jì)算機(jī)的幫助，由簡單的線框和文字去繪制這個(gè)界面。當(dāng)然，低保真原型不能只是簡單的看，還要進(jìn)行一些簡單的交互操作。用白話來講就是動(dòng)態(tài)，可以簡單地進(jìn)行體驗(yàn)一下這個(gè)設(shè)計(jì)，盡可能的發(fā)現(xiàn)一些問題。去進(jìn)行一定的修改。  高保真原型圖：就是先在這個(gè)線框圖的基礎(chǔ)上進(jìn)行視覺設(shè)計(jì)，在將這個(gè)視覺設(shè)計(jì)稿呢制作成可進(jìn)行交互操作的原型。這個(gè)效果很可能都能和最后的那個(gè)產(chǎn)品相差無幾，甚至你可以在你的手機(jī)上進(jìn)行模擬的操作。 高保真原型呢一般用于交付給開發(fā)與測試那邊。開發(fā)人員將按照高保真原型進(jìn)行開發(fā)。測試人員將以高保真原型為基準(zhǔn)，對(duì)開發(fā)人員交付的產(chǎn)品進(jìn)行測試。
所以大家可以看到，在設(shè)計(jì)流程中，設(shè)計(jì)師首先要通過草圖與產(chǎn)品經(jīng)理以及其他同事進(jìn)行討論，以確定產(chǎn)品的設(shè)計(jì)方向。之后再做一個(gè)低保真原型來進(jìn)行打磨設(shè)計(jì)。在之后會(huì)制作高保真原型來交付給開發(fā)和測試人員。 所以設(shè)計(jì)師的整個(gè)這個(gè)設(shè)計(jì)工作都是一個(gè)和其他角色進(jìn)行溝通的一個(gè)過程。而我們剛才提到的設(shè)計(jì)的三個(gè)步驟也是圍繞溝通而展開的。 （二）為什么要畫原型 原因在于減少修改成本，便于溝通討論。
畫原型最大的目的呢，是為了減少后期修改成本，用一個(gè)低成本的原型去體驗(yàn)去討論，去修改，盡量避免開發(fā)好了再去修改。第二呢，一個(gè)可交互的原型更方便和其他人去進(jìn)行溝通和討論，所謂一圖勝千文。所以圖片比文字的溝通效果要好很多。那么，如果說是原型，或者可以交互的原型，它的溝通效果就要比圖片要好很多。 所以，需要強(qiáng)調(diào)的是，原型只不過是一個(gè)設(shè)計(jì)工具，設(shè)計(jì)的思想才是真正的核心所在。所以，在學(xué)好工具的基礎(chǔ)上，應(yīng)該多花時(shí)間在設(shè)計(jì)思路的學(xué)習(xí)上。
三、開發(fā)接下來就到了程序員編寫程序的三個(gè)步驟了。（關(guān)于開發(fā)，在這里不做詳述） 1、app軟件開發(fā)大功能模塊代碼編寫 2、app軟件開發(fā)大概的界面模塊編寫 3、把大概的界面和功能連接后，app軟件開發(fā)的大致demo就出來了 4、demo自己試用和體驗(yàn)幾遍后，根據(jù)情況修改 5、沒有大錯(cuò)誤后，0.9版本可以嘗試尋找beta用戶 6、根據(jù)測試用戶的反饋，重復(fù) 前三個(gè)步驟
四、測試測試工程師，一般就是從用戶角度出發(fā)，檢測開發(fā)工程師做的東西是不是符合產(chǎn)品的需求，或是用戶體檢好不好？不要求有太專業(yè)的知識(shí)，但是要細(xì)心，對(duì)產(chǎn)品敏感。所以有很多不是計(jì)算機(jī)專業(yè)的人員照樣可以做測試工程師，因?yàn)槲覀兊漠a(chǎn)品需要不同的人來說嘛。 也有比較專業(yè)的白盒或是灰盒測試，這就要求測試人員會(huì)些兒編程技術(shù)了，但是要求不太高，不必會(huì)某種語言的高級(jí)編程，普通應(yīng)用或是代碼段能看懂就行。問題要考慮全面，細(xì)致，有原則，不能跟著開發(fā)和產(chǎn)品走，這是測試人員的要求。
（一）軟件測試的測試流程有： 制定測試計(jì)劃——編輯測試用例——執(zhí)行測試用例——發(fā)現(xiàn)并提交BUG——開發(fā)組修正BUG——對(duì)已修正BUG進(jìn)行返測——修正完成的BUG將狀態(tài)置為已關(guān)閉，未正確修正的BUG重新激活. （二）規(guī)范的測試流程  需求分析：需求分析由產(chǎn)品人員制定，他們要做的不是一份簡單的文檔，而是細(xì)化每一個(gè)功能的細(xì)節(jié)，每一個(gè)按鈕的位置，對(duì)于稍大或復(fù)雜一點(diǎn)的需求都進(jìn)行建模。 需求評(píng)審：這里會(huì)叫上所有參與項(xiàng)目人員進(jìn)行，開發(fā)人員、測試人員、QA人員。測試人員提出需求，開發(fā)人員考慮功能實(shí)現(xiàn)的方案與可行性、當(dāng)然開發(fā)負(fù)責(zé)也是要參與的。測試人員主要是對(duì)需求的理解提出疑問，以便才能根據(jù)需求寫用例。QA人員是最終對(duì)軟件質(zhì)量進(jìn)行驗(yàn)證的人，所以也需求了解需求 開發(fā)人員編寫排期：開發(fā)人員需求根據(jù)需求功能點(diǎn)進(jìn)行排期。然后將開計(jì)劃轉(zhuǎn)交給測試人員。 測試計(jì)劃排期：測試人員根據(jù)開發(fā)計(jì)劃，對(duì)測試具體測試時(shí)間，也就是開發(fā)功能完成后的時(shí)間，進(jìn)行幾輪測試等。然后，把項(xiàng)目的開發(fā)與測試計(jì)劃發(fā)送給各部門負(fù)責(zé)人及參與項(xiàng)目的所有人員。 編寫測試用例：根據(jù)詳細(xì)的需求分檔，開始進(jìn)行用例的編寫。 用例評(píng)審：在用例進(jìn)行評(píng)審之間，先以郵件形式將用例發(fā)送給相關(guān)人員，以便他們事先了解用例對(duì)哪些功能進(jìn)行驗(yàn)證以及驗(yàn)證的細(xì)節(jié)。 然后，測試人員組進(jìn)行用例評(píng)審，開發(fā)人員對(duì)用例與實(shí)際功能不符合有哪些，產(chǎn)品人員對(duì)會(huì)通過用例對(duì)功能的具體實(shí)現(xiàn)進(jìn)行把握等等。 提交基線：開發(fā)人員完成所有功能后，會(huì)對(duì)自己的功能進(jìn)行一個(gè)自測。自測完成后提交測試人員進(jìn)行基線。
（三）具體測試流程： 開發(fā)人員對(duì)于基到測試線的功能進(jìn)行測式，發(fā)現(xiàn)的問題通過缺陷管理工具進(jìn)行反饋，開發(fā)人員對(duì)問題進(jìn)行修復(fù)，然后，準(zhǔn)備第二輪基。  測試人員完成第一輪測試后，需要寫測試結(jié)論，發(fā)到相關(guān)人員。然后對(duì)基線后的第二輪進(jìn)行測試，第二輪會(huì)對(duì)第一輪中發(fā)現(xiàn)的問題進(jìn)行重點(diǎn)回歸。 測試通過：經(jīng)過兩到三輪或四輪的測試后，直到?jīng)]發(fā)現(xiàn)新的問題，或暫時(shí)無法解決，或不緊急的問題。通過上級(jí)確認(rèn)，可以通過。編寫測試報(bào)告與驗(yàn)收方案。 驗(yàn)收方案是交由QA進(jìn)行驗(yàn)證的。在現(xiàn)公司的流程中是將測試與QA分開的，測試人員重點(diǎn)關(guān)注的是功能是否可以正常運(yùn)行。QA關(guān)注的是整個(gè)流程的質(zhì)量以及最終用戶的質(zhì)量。有些公司QA與測試是不區(qū)分的，但這對(duì)測試的要求會(huì)更高，除了關(guān)心功能，還需要關(guān)心整體流程與質(zhì)量。 流程分析：這個(gè)流程是規(guī)范的，測試真正融入了整個(gè)流程，而且還擔(dān)任了很重的角色，從而也有效的保證了軟件產(chǎn)品的整體質(zhì)量。 那么這個(gè)流程是不是完美的呢？不，這個(gè)項(xiàng)目流程太強(qiáng)化各種文檔。我們來看測試的工作內(nèi)容，測試計(jì)劃、測試用例、測試結(jié)論、測試報(bào)告、驗(yàn)收方案、問題的提交跟蹤。其實(shí)，我們真用于測試的時(shí)間是非常少的，在一周的時(shí)間，也許只有一天或不到一天的時(shí)間是在進(jìn)行測試的。測試人員只有在測試的時(shí)候才會(huì)體現(xiàn)出他的價(jià)值。而大部分工作卻不能體現(xiàn)他的價(jià)值。 當(dāng)然，我這里會(huì)省略與測試主流程無關(guān)的東西，真正的測試工作中瑣事很多。
（四）敏捷測試流程 前面講的第一種流程，還是第二種流程都是瀑布式的，嚴(yán)格來說第一種簡陋的都不能稱為瀑布式，對(duì)于一個(gè)三個(gè)月的項(xiàng)目說，產(chǎn)品把需求分析完了給開發(fā)，然后產(chǎn)品就沒事兒了；開發(fā)開發(fā)完成之后給測試，然后開發(fā)人員也不忙了。 測試完成之后上線。那么在產(chǎn)品分析的階段，開發(fā)和測試都是沒事干的（這里只對(duì)單一項(xiàng)目）。 開發(fā)階段，產(chǎn)品和測試也基本沒事兒。同樣在測試階段，產(chǎn)品與開發(fā)也是沒什么事兒的。 敏捷測試的一個(gè)核心是迭代，在每個(gè)時(shí)間點(diǎn)上，所有項(xiàng)目人員都是有事可做的。 1、下面是我理解中的敏捷測試流程圖：  第一階段： 通過上面的流程圖，對(duì)于一個(gè)月的需求分析，在敏捷中，可能三五天就確定下來。這個(gè)需求定得會(huì)很模糊，但整體框架確定。產(chǎn)品對(duì)其中某一模塊功能確認(rèn)，開發(fā)人員開始對(duì)確認(rèn)的功能編碼，開發(fā)人員編碼的過程中，測試進(jìn)行功能分解，因?yàn)楦鶕?jù)模糊的需求很難寫出具體的用例，所以，只能盡量對(duì)功能進(jìn)行分析得細(xì)些，標(biāo)注需要驗(yàn)證的內(nèi)容。 第二階段： 開發(fā)完成后交給測試人員進(jìn)行測試，開發(fā)人員繼續(xù)開發(fā)新的功能。那么測試人員發(fā)現(xiàn)的問題怎么辦呢？會(huì)從開發(fā)團(tuán)隊(duì)中抽出一個(gè)人員來用于解決測試發(fā)現(xiàn)的問題。但開發(fā)進(jìn)度并沒有因?yàn)闇y試而停止。 流程分析： 在這個(gè)流程中弱化了文檔，強(qiáng)調(diào)了各個(gè)人員的溝通，通過這種迭代的方式，三個(gè)月的項(xiàng)目，可以能兩個(gè)月和兩個(gè)半月就會(huì)完成。 但這種流程并非完美，加入一個(gè)功能在需求分析階段就是錯(cuò)誤的，因?yàn)樗且粋€(gè)迭代漸進(jìn)的過程。也只能一路錯(cuò)下去。
2、對(duì)測試問題的處理  上面的圖更能清晰看出對(duì)問題的處理過程。 第一塊面板中是開發(fā)人員未實(shí)現(xiàn)的功能，第二塊面板中是開發(fā)完成功能，測試人員對(duì)其進(jìn)行測試，發(fā)現(xiàn)不通過的就放回未開發(fā)的面板中，測試通過的將放到第三塊面板中。 找專業(yè)的人,做專業(yè)的事 | 為您提供設(shè)計(jì)管家服務(wù) 最近25學(xué)堂在簡書上看到一篇比較完整的手機(jī)app開發(fā)、測試、視覺設(shè)計(jì)、交互設(shè)計(jì)的完整流程。作者：小叮當(dāng)doe。 其實(shí)，之前25學(xué)堂也分享了很多關(guān)于APP設(shè)計(jì)、APP開發(fā)、APP測試的流程。估計(jì)也有很多人還不是很明白。 比如之前分享的： 1、UIMAX設(shè)計(jì)師的工作分享：完整的交互設(shè)計(jì)流程詮釋 2、不懂APP開發(fā)的你，必知的整套APP項(xiàng)目的開發(fā)步驟 3、APP重設(shè)計(jì)的工作流程以及APP產(chǎn)品的re-design思路 4、APP設(shè)計(jì)干貨，手機(jī)UI界面設(shè)計(jì)思路解析與流程 5、產(chǎn)品經(jīng)理思維流程：看產(chǎn)品、想產(chǎn)品、做產(chǎn)品
從整個(gè)APP產(chǎn)品大局來看： 產(chǎn)品的研發(fā)流程分為四個(gè)步驟：產(chǎn)品定義——交互設(shè)計(jì)——開發(fā)——測試。 這四個(gè)步驟也分別對(duì)應(yīng)研發(fā)中的四個(gè)角色：產(chǎn)品經(jīng)理——設(shè)計(jì)師——開發(fā)工程師——測試工程師。
1、產(chǎn)品定義階段的目標(biāo)就是確定用戶場景，定義產(chǎn)品的功能和范圍。 2、而設(shè)計(jì)師需要根據(jù)這些用戶場景和功能范圍進(jìn)行交互設(shè)計(jì)。 3、開發(fā)工程師將會(huì)根據(jù)產(chǎn)品經(jīng)理和設(shè)計(jì)師的方案進(jìn)行寫代碼，把這個(gè)方案實(shí)現(xiàn)成可用的產(chǎn)品。 4、之后的再由測試工程師進(jìn)行產(chǎn)品測試，以保證產(chǎn)品達(dá)到了產(chǎn)品經(jīng)理和設(shè)計(jì)師的這個(gè)要求。
下面我們就來看看產(chǎn)品定義的流程： 一、定義產(chǎn)品需求在這里要談?wù)摰闹饕怯脩粜枨蠛彤a(chǎn)品需求。
1.1、用戶需求和產(chǎn)品需求 首先必須要搞清的是用戶需求不等同于產(chǎn)品需求。 用戶需求，簡單來說是用戶希望同構(gòu)使用某一款產(chǎn)品來實(shí)現(xiàn)和滿足某種需要。如安全、娛樂、溝通、交友等。用戶需求是用戶對(duì)某類產(chǎn)品真實(shí)需要的反應(yīng)。 而產(chǎn)品需求，是某一類產(chǎn)品或服務(wù)能夠滿足用戶需要的集合。也就是說，用戶需求并不完全傳遞到產(chǎn)品需求當(dāng)中去。而產(chǎn)品需求的獲取渠道也不僅僅是用戶需求。 1.2、獲取產(chǎn)品需求的方式 （1）用戶需求：用戶需求是產(chǎn)品需求的核心來源。但并不是所有的用戶需求都能轉(zhuǎn)化為產(chǎn)品需求。用戶需求需要子可行性和必要性驗(yàn)證上，才可以轉(zhuǎn)化為產(chǎn)品需求。 （2）相關(guān)利益合作伙伴：開發(fā)商、咨詢機(jī)構(gòu)、制造商等等。他們通過對(duì)市場的研究分析和對(duì)運(yùn)營所積累的產(chǎn)品需求，是設(shè)計(jì)分析產(chǎn)品需求很好的參考。 （3）競品分析：對(duì)競爭對(duì)手主要產(chǎn)品進(jìn)行對(duì)標(biāo)研究，分析其產(chǎn)品的成敗關(guān)鍵和發(fā)展趨勢，了解市場對(duì)類似產(chǎn)品的反饋。 （4）標(biāo)桿市場：標(biāo)桿市場是國內(nèi)外在同類產(chǎn)品上運(yùn)營比較成功的熱門行業(yè)，通過對(duì)標(biāo)桿市場中知名企業(yè)所運(yùn)營的相近產(chǎn)品的功能進(jìn)行剖析?？梢粤私鈬H與國內(nèi)在該類產(chǎn)品上的先進(jìn)做法。 （5）企業(yè)內(nèi)部產(chǎn)品研討會(huì)、員工體驗(yàn)及內(nèi)部專家評(píng)估。
1.3、用戶需求的提取與挖掘的方式 了解用戶需求的有效方式是用戶研究，這是用戶中心設(shè)計(jì)流程的第一步。其主要研究方式是：用戶訪談、用戶觀察、問卷調(diào)研、焦點(diǎn)小組、眼動(dòng)實(shí)驗(yàn)等等。并對(duì)由此得到的信息與數(shù)據(jù)進(jìn)行處理和分析。從中提取制作出初步的用戶需求文檔。 顯然這些需求是不夠的。這些需求僅僅是用戶在現(xiàn)有需求上的反饋。此外，設(shè)計(jì)師可以利用在用戶研究階段所生成的人物角色（人物畫像）這個(gè)工具，并放置到具體場景中，從而挖掘用戶可能的潛在需求。 （1）通過用戶研究直接獲取 用戶研究階段可能會(huì)出現(xiàn)各式各樣的問卷及數(shù)據(jù)列表。這些數(shù)據(jù)的收集活動(dòng)并不難，所需要付出的只是耐心和時(shí)間。 為了更多更好的獲取初步用戶的需求，用戶研究員需要在問卷調(diào)查的問卷設(shè)計(jì) 、用戶訪談、焦點(diǎn)小組等的腳本設(shè)計(jì)中，明確哪些問題或者選項(xiàng)是為需求而設(shè)置的，以便后續(xù)階段的整理。 （2）在場景中運(yùn)用人物角色進(jìn)行挖掘。 人物角色的來源、概念及功能：人物角色不是真實(shí)的人，但它是基于我們觀察到的那些真實(shí)的人的行為和動(dòng)機(jī)，并且在整個(gè)設(shè)計(jì)過程中代表真實(shí)的人，是在人種學(xué)調(diào)查收集到的世紀(jì)用戶行為數(shù)據(jù)的基礎(chǔ)上形成的綜合模型。在研究階段我們觀察用戶的行為模式，在建模階段將其模式化，最后生成人物角色。 也就是說人物角色源自于用戶研究。研究人員通過用戶研究，通過一定的標(biāo)準(zhǔn)將眾多的用戶進(jìn)行細(xì)分，從而得到不同的細(xì)分用戶群組。 細(xì)分的用戶群組經(jīng)過一定的評(píng)估、調(diào)整，從而確定細(xì)分角色群組。角色群組經(jīng)過一定的潤色。諸如為每個(gè)角色群組賦予具有代表性的照片、名稱、職業(yè)、性格等鮮明的人物屬性，從而形成不同的人物角色。 人物角色通常因其重要程度及特定定義為：首要人物角色、次要人物角色、不重要的人物角色、排斥的人物角色。 通過建立人物角色，從而將用戶研究結(jié)果以一種簡單直觀但又非常有效的方式使設(shè)計(jì)團(tuán)隊(duì)成員（決策人員、產(chǎn)品經(jīng)理、交互設(shè)計(jì)師、視覺設(shè)計(jì)師）等對(duì)大家所面對(duì)的客戶群形成一致的了解。 場景的概念與作用：用戶角色是死的，靜態(tài)的東西，只有將其放到一定的場景中去，才會(huì)鮮活起來，與產(chǎn)品產(chǎn)生交互。 場景是人物角色與產(chǎn)品進(jìn)行交互的“理想化”情景。它講述的是每個(gè)人物角色如何與產(chǎn)品進(jìn)行交互的故事。每個(gè)人物角色都將對(duì)應(yīng)一個(gè)場景，甚至更多，以求覆蓋用戶使用場景的各種情形。 在場景中使用人物角色進(jìn)行需求的挖掘:針對(duì)每個(gè)人物角色，設(shè)計(jì)合理的場景，然后集合相關(guān)的工作人員（不僅僅是交互和視覺設(shè)計(jì)師）一起進(jìn)行頭腦風(fēng)暴。再此階段每個(gè)人要有深度的同理心，并在每個(gè)關(guān)節(jié)點(diǎn)將所能想到的可能性完全說出來，記錄下來，此時(shí)的氣氛也是不加約束和不帶批判的。 在此以時(shí)間為軸“生活中的一天”為例，來針對(duì)手機(jī)瀏覽器產(chǎn)品利用人物角色來進(jìn)行需求挖掘。譬如： 早晨起來，剛起床：會(huì)看天氣預(yù)報(bào)、日歷中可能涉及的功能：天氣查詢、日歷。 吃早餐的時(shí)候：可能會(huì)看新聞、郵件以及自己的博客。這樣就會(huì)設(shè)計(jì)到新聞、微博以及郵箱。 以及交通途中：上午辦公室：中午午餐：下午辦公室：下班前：下班途中：餐廳里：家中：被窩里等等各種狀態(tài)下來挖掘可能用到的功能。 每個(gè)人物角色通過一個(gè)或多個(gè)場景的挖掘，要對(duì)其所涉及到的功能進(jìn)行羅列，并根據(jù)其在每個(gè)人物角色的重要性定義每個(gè)功能的權(quán)重，并建立excel檔。
1.4、用戶需求提升為產(chǎn)品需求，由此得出產(chǎn)品功能需求列表
以上得出的用戶需求，并不能直接轉(zhuǎn)入產(chǎn)品需求，需要經(jīng)過一定的評(píng)估和帥選考察其可行性和必要性。 可行性：目前的技術(shù)和企業(yè)資源是否有能力，是否能在現(xiàn)行的情況下，與進(jìn)度時(shí)間表等現(xiàn)實(shí)條件下開發(fā)出完全滿足用戶需求的產(chǎn)品。 必要性：用戶的這些需求是否有需要滿足，滿足這些需求企業(yè)需要付出的代價(jià)，以及是否有足夠的企業(yè)效益來支撐市場的運(yùn)營。 經(jīng)過上述驗(yàn)證，并結(jié)合前面所敘述的相關(guān)利益合作伙伴、競品分析、標(biāo)桿市場及企業(yè)內(nèi)部研討會(huì)等所得到的用戶需求，從而得到完整的用戶需求列表。 在此所有的產(chǎn)品需求都轉(zhuǎn)化為產(chǎn)品功能。工作人員可以將之前用戶研究階段收集的功能需求合并到后來利用任務(wù)角色在場景下挖掘的需求列表中。他們本質(zhì)上也相應(yīng)對(duì)應(yīng)著不同的人物角色。 在這里，角色的權(quán)重（可以根據(jù)首要人物角色、次要人物角色、不重要人物角色等分成3點(diǎn)量表或者5點(diǎn)量表）與對(duì)應(yīng)的任務(wù)的權(quán)重的乘積，就是功能總的重要程度。
二、交互設(shè)計(jì)流程（一）交互設(shè)計(jì)三段式 草圖——低保真原型——高保真原型  我們看到的這張圖實(shí)際上他畫的相當(dāng)規(guī)整，它已經(jīng)是一個(gè)完整的產(chǎn)品架構(gòu)圖。但是我們工作中的話可能只是信手拈來，草草的畫上幾筆，這些都沒關(guān)系，草圖強(qiáng)調(diào)的就是能快速地將想法具體化，然后和其他同事進(jìn)行討論。 低保真原型圖：就是在草圖的基礎(chǔ)上，通過計(jì)算機(jī)的幫助，由簡單的線框和文字去繪制這個(gè)界面。當(dāng)然，低保真原型不能只是簡單的看，還要進(jìn)行一些簡單的交互操作。用白話來講就是動(dòng)態(tài)，可以簡單地進(jìn)行體驗(yàn)一下這個(gè)設(shè)計(jì)，盡可能的發(fā)現(xiàn)一些問題。去進(jìn)行一定的修改。 高保真原型圖：就是先在這個(gè)線框圖的基礎(chǔ)上進(jìn)行視覺設(shè)計(jì)，在將這個(gè)視覺設(shè)計(jì)稿呢制作成可進(jìn)行交互操作的原型。這個(gè)效果很可能都能和最后的那個(gè)產(chǎn)品相差無幾，甚至你可以在你的手機(jī)上進(jìn)行模擬的操作。 高保真原型呢一般用于交付給開發(fā)與測試那邊。開發(fā)人員將按照高保真原型進(jìn)行開發(fā)。測試人員將以高保真原型為基準(zhǔn)，對(duì)開發(fā)人員交付的產(chǎn)品進(jìn)行測試。
所以大家可以看到，在設(shè)計(jì)流程中，設(shè)計(jì)師首先要通過草圖與產(chǎn)品經(jīng)理以及其他同事進(jìn)行討論，以確定產(chǎn)品的設(shè)計(jì)方向。之后再做一個(gè)低保真原型來進(jìn)行打磨設(shè)計(jì)。在之后會(huì)制作高保真原型來交付給開發(fā)和測試人員。 所以設(shè)計(jì)師的整個(gè)這個(gè)設(shè)計(jì)工作都是一個(gè)和其他角色進(jìn)行溝通的一個(gè)過程。而我們剛才提到的設(shè)計(jì)的三個(gè)步驟也是圍繞溝通而展開的。 （二）為什么要畫原型 原因在于減少修改成本，便于溝通討論。
畫原型最大的目的呢，是為了減少后期修改成本，用一個(gè)低成本的原型去體驗(yàn)去討論，去修改，盡量避免開發(fā)好了再去修改。第二呢，一個(gè)可交互的原型更方便和其他人去進(jìn)行溝通和討論，所謂一圖勝千文。所以圖片比文字的溝通效果要好很多。那么，如果說是原型，或者可以交互的原型，它的溝通效果就要比圖片要好很多。 所以，需要強(qiáng)調(diào)的是，原型只不過是一個(gè)設(shè)計(jì)工具，設(shè)計(jì)的思想才是真正的核心所在。所以，在學(xué)好工具的基礎(chǔ)上，應(yīng)該多花時(shí)間在設(shè)計(jì)思路的學(xué)習(xí)上。
三、開發(fā)接下來就到了程序員編寫程序的三個(gè)步驟了。（關(guān)于開發(fā)，在這里不做詳述） 1、app軟件開發(fā)大功能模塊代碼編寫 2、app軟件開發(fā)大概的界面模塊編寫 3、把大概的界面和功能連接后，app軟件開發(fā)的大致demo就出來了 4、demo自己試用和體驗(yàn)幾遍后，根據(jù)情況修改 5、沒有大錯(cuò)誤后，0.9版本可以嘗試尋找beta用戶 6、根據(jù)測試用戶的反饋，重復(fù) 前三個(gè)步驟
四、測試測試工程師，一般就是從用戶角度出發(fā)，檢測開發(fā)工程師做的東西是不是符合產(chǎn)品的需求，或是用戶體檢好不好？不要求有太專業(yè)的知識(shí)，但是要細(xì)心，對(duì)產(chǎn)品敏感。所以有很多不是計(jì)算機(jī)專業(yè)的人員照樣可以做測試工程師，因?yàn)槲覀兊漠a(chǎn)品需要不同的人來說嘛。 也有比較專業(yè)的白盒或是灰盒測試，這就要求測試人員會(huì)些兒編程技術(shù)了，但是要求不太高，不必會(huì)某種語言的高級(jí)編程，普通應(yīng)用或是代碼段能看懂就行。問題要考慮全面，細(xì)致，有原則，不能跟著開發(fā)和產(chǎn)品走，這是測試人員的要求。
（一）軟件測試的測試流程有： 制定測試計(jì)劃——編輯測試用例——執(zhí)行測試用例——發(fā)現(xiàn)并提交BUG——開發(fā)組修正BUG——對(duì)已修正BUG進(jìn)行返測——修正完成的BUG將狀態(tài)置為已關(guān)閉，未正確修正的BUG重新激活. （二）規(guī)范的測試流程 需求分析：需求分析由產(chǎn)品人員制定，他們要做的不是一份簡單的文檔，而是細(xì)化每一個(gè)功能的細(xì)節(jié)，每一個(gè)按鈕的位置，對(duì)于稍大或復(fù)雜一點(diǎn)的需求都進(jìn)行建模。 需求評(píng)審：這里會(huì)叫上所有參與項(xiàng)目人員進(jìn)行，開發(fā)人員、測試人員、QA人員。測試人員提出需求，開發(fā)人員考慮功能實(shí)現(xiàn)的方案與可行性、當(dāng)然開發(fā)負(fù)責(zé)也是要參與的。測試人員主要是對(duì)需求的理解提出疑問，以便才能根據(jù)需求寫用例。QA人員是最終對(duì)軟件質(zhì)量進(jìn)行驗(yàn)證的人，所以也需求了解需求 開發(fā)人員編寫排期：開發(fā)人員需求根據(jù)需求功能點(diǎn)進(jìn)行排期。然后將開計(jì)劃轉(zhuǎn)交給測試人員。 測試計(jì)劃排期：測試人員根據(jù)開發(fā)計(jì)劃，對(duì)測試具體測試時(shí)間，也就是開發(fā)功能完成后的時(shí)間，進(jìn)行幾輪測試等。然后，把項(xiàng)目的開發(fā)與測試計(jì)劃發(fā)送給各部門負(fù)責(zé)人及參與項(xiàng)目的所有人員。 編寫測試用例：根據(jù)詳細(xì)的需求分檔，開始進(jìn)行用例的編寫。 用例評(píng)審：在用例進(jìn)行評(píng)審之間，先以郵件形式將用例發(fā)送給相關(guān)人員，以便他們事先了解用例對(duì)哪些功能進(jìn)行驗(yàn)證以及驗(yàn)證的細(xì)節(jié)。 然后，測試人員組進(jìn)行用例評(píng)審，開發(fā)人員對(duì)用例與實(shí)際功能不符合有哪些，產(chǎn)品人員對(duì)會(huì)通過用例對(duì)功能的具體實(shí)現(xiàn)進(jìn)行把握等等。 提交基線：開發(fā)人員完成所有功能后，會(huì)對(duì)自己的功能進(jìn)行一個(gè)自測。自測完成后提交測試人員進(jìn)行基線。
（三）具體測試流程： 開發(fā)人員對(duì)于基到測試線的功能進(jìn)行測式，發(fā)現(xiàn)的問題通過缺陷管理工具進(jìn)行反饋，開發(fā)人員對(duì)問題進(jìn)行修復(fù)，然后，準(zhǔn)備第二輪基。 測試人員完成第一輪測試后，需要寫測試結(jié)論，發(fā)到相關(guān)人員。然后對(duì)基線后的第二輪進(jìn)行測試，第二輪會(huì)對(duì)第一輪中發(fā)現(xiàn)的問題進(jìn)行重點(diǎn)回歸。 測試通過：經(jīng)過兩到三輪或四輪的測試后，直到?jīng)]發(fā)現(xiàn)新的問題，或暫時(shí)無法解決，或不緊急的問題。通過上級(jí)確認(rèn)，可以通過。編寫測試報(bào)告與驗(yàn)收方案。 驗(yàn)收方案是交由QA進(jìn)行驗(yàn)證的。在現(xiàn)公司的流程中是將測試與QA分開的，測試人員重點(diǎn)關(guān)注的是功能是否可以正常運(yùn)行。QA關(guān)注的是整個(gè)流程的質(zhì)量以及最終用戶的質(zhì)量。有些公司QA與測試是不區(qū)分的，但這對(duì)測試的要求會(huì)更高，除了關(guān)心功能，還需要關(guān)心整體流程與質(zhì)量。 流程分析：這個(gè)流程是規(guī)范的，測試真正融入了整個(gè)流程，而且還擔(dān)任了很重的角色，從而也有效的保證了軟件產(chǎn)品的整體質(zhì)量。 那么這個(gè)流程是不是完美的呢？不，這個(gè)項(xiàng)目流程太強(qiáng)化各種文檔。我們來看測試的工作內(nèi)容，測試計(jì)劃、測試用例、測試結(jié)論、測試報(bào)告、驗(yàn)收方案、問題的提交跟蹤。其實(shí)，我們真用于測試的時(shí)間是非常少的，在一周的時(shí)間，也許只有一天或不到一天的時(shí)間是在進(jìn)行測試的。測試人員只有在測試的時(shí)候才會(huì)體現(xiàn)出他的價(jià)值。而大部分工作卻不能體現(xiàn)他的價(jià)值。 當(dāng)然，我這里會(huì)省略與測試主流程無關(guān)的東西，真正的測試工作中瑣事很多。
（四）敏捷測試流程 前面講的第一種流程，還是第二種流程都是瀑布式的，嚴(yán)格來說第一種簡陋的都不能稱為瀑布式，對(duì)于一個(gè)三個(gè)月的項(xiàng)目說，產(chǎn)品把需求分析完了給開發(fā)，然后產(chǎn)品就沒事兒了；開發(fā)開發(fā)完成之后給測試，然后開發(fā)人員也不忙了。 測試完成之后上線。那么在產(chǎn)品分析的階段，開發(fā)和測試都是沒事干的（這里只對(duì)單一項(xiàng)目）。 開發(fā)階段，產(chǎn)品和測試也基本沒事兒。同樣在測試階段，產(chǎn)品與開發(fā)也是沒什么事兒的。 敏捷測試的一個(gè)核心是迭代，在每個(gè)時(shí)間點(diǎn)上，所有項(xiàng)目人員都是有事可做的。 1、下面是我理解中的敏捷測試流程圖： 第一階段： 通過上面的流程圖，對(duì)于一個(gè)月的需求分析，在敏捷中，可能三五天就確定下來。這個(gè)需求定得會(huì)很模糊，但整體框架確定。產(chǎn)品對(duì)其中某一模塊功能確認(rèn)，開發(fā)人員開始對(duì)確認(rèn)的功能編碼，開發(fā)人員編碼的過程中，測試進(jìn)行功能分解，因?yàn)楦鶕?jù)模糊的需求很難寫出具體的用例，所以，只能盡量對(duì)功能進(jìn)行分析得細(xì)些，標(biāo)注需要驗(yàn)證的內(nèi)容。 第二階段： 開發(fā)完成后交給測試人員進(jìn)行測試，開發(fā)人員繼續(xù)開發(fā)新的功能。那么測試人員發(fā)現(xiàn)的問題怎么辦呢？會(huì)從開發(fā)團(tuán)隊(duì)中抽出一個(gè)人員來用于解決測試發(fā)現(xiàn)的問題。但開發(fā)進(jìn)度并沒有因?yàn)闇y試而停止。 流程分析： 在這個(gè)流程中弱化了文檔，強(qiáng)調(diào)了各個(gè)人員的溝通，通過這種迭代的方式，三個(gè)月的項(xiàng)目，可以能兩個(gè)月和兩個(gè)半月就會(huì)完成。 但這種流程并非完美，加入一個(gè)功能在需求分析階段就是錯(cuò)誤的，因?yàn)樗且粋€(gè)迭代漸進(jìn)的過程。也只能一路錯(cuò)下去。
2、對(duì)測試問題的處理 上面的圖更能清晰看出對(duì)問題的處理過程。 第一塊面板中是開發(fā)人員未實(shí)現(xiàn)的功能，第二塊面板中是開發(fā)完成功能，測試人員對(duì)其進(jìn)行測試，發(fā)現(xiàn)不通過的就放回未開發(fā)的面板中，測試通過的將放到第三塊面板中。 找專業(yè)的人,做專業(yè)的事 | 為您提供設(shè)計(jì)管家服務(wù) 最近25學(xué)堂在簡書上看到一篇比較完整的手機(jī)app開發(fā)、測試、視覺設(shè)計(jì)、交互設(shè)計(jì)的完整流程。作者：小叮當(dāng)doe。 其實(shí)，之前25學(xué)堂也分享了很多關(guān)于APP設(shè)計(jì)、APP開發(fā)、APP測試的流程。估計(jì)也有很多人還不是很明白。 比如之前分享的： 1、UIMAX設(shè)計(jì)師的工作分享：完整的交互設(shè)計(jì)流程詮釋 2、不懂APP開發(fā)的你，必知的整套APP項(xiàng)目的開發(fā)步驟 3、APP重設(shè)計(jì)的工作流程以及APP產(chǎn)品的re-design思路 4、APP設(shè)計(jì)干貨，手機(jī)UI界面設(shè)計(jì)思路解析與流程 5、產(chǎn)品經(jīng)理思維流程：看產(chǎn)品、想產(chǎn)品、做產(chǎn)品
從整個(gè)APP產(chǎn)品大局來看： 產(chǎn)品的研發(fā)流程分為四個(gè)步驟：產(chǎn)品定義——交互設(shè)計(jì)——開發(fā)——測試。 這四個(gè)步驟也分別對(duì)應(yīng)研發(fā)中的四個(gè)角色：產(chǎn)品經(jīng)理——設(shè)計(jì)師——開發(fā)工程師——測試工程師。
1、產(chǎn)品定義階段的目標(biāo)就是確定用戶場景，定義產(chǎn)品的功能和范圍。 2、而設(shè)計(jì)師需要根據(jù)這些用戶場景和功能范圍進(jìn)行交互設(shè)計(jì)。 3、開發(fā)工程師將會(huì)根據(jù)產(chǎn)品經(jīng)理和設(shè)計(jì)師的方案進(jìn)行寫代碼，把這個(gè)方案實(shí)現(xiàn)成可用的產(chǎn)品。 4、之后的再由測試工程師進(jìn)行產(chǎn)品測試，以保證產(chǎn)品達(dá)到了產(chǎn)品經(jīng)理和設(shè)計(jì)師的這個(gè)要求。
下面我們就來看看產(chǎn)品定義的流程： 一、定義產(chǎn)品需求在這里要談?wù)摰闹饕怯脩粜枨蠛彤a(chǎn)品需求。
1.1、用戶需求和產(chǎn)品需求 首先必須要搞清的是用戶需求不等同于產(chǎn)品需求。 用戶需求，簡單來說是用戶希望同構(gòu)使用某一款產(chǎn)品來實(shí)現(xiàn)和滿足某種需要。如安全、娛樂、溝通、交友等。用戶需求是用戶對(duì)某類產(chǎn)品真實(shí)需要的反應(yīng)。 而產(chǎn)品需求，是某一類產(chǎn)品或服務(wù)能夠滿足用戶需要的集合。也就是說，用戶需求并不完全傳遞到產(chǎn)品需求當(dāng)中去。而產(chǎn)品需求的獲取渠道也不僅僅是用戶需求。 1.2、獲取產(chǎn)品需求的方式 （1）用戶需求：用戶需求是產(chǎn)品需求的核心來源。但并不是所有的用戶需求都能轉(zhuǎn)化為產(chǎn)品需求。用戶需求需要子可行性和必要性驗(yàn)證上，才可以轉(zhuǎn)化為產(chǎn)品需求。 （2）相關(guān)利益合作伙伴：開發(fā)商、咨詢機(jī)構(gòu)、制造商等等。他們通過對(duì)市場的研究分析和對(duì)運(yùn)營所積累的產(chǎn)品需求，是設(shè)計(jì)分析產(chǎn)品需求很好的參考。 （3）競品分析：對(duì)競爭對(duì)手主要產(chǎn)品進(jìn)行對(duì)標(biāo)研究，分析其產(chǎn)品的成敗關(guān)鍵和發(fā)展趨勢，了解市場對(duì)類似產(chǎn)品的反饋。 （4）標(biāo)桿市場：標(biāo)桿市場是國內(nèi)外在同類產(chǎn)品上運(yùn)營比較成功的熱門行業(yè)，通過對(duì)標(biāo)桿市場中知名企業(yè)所運(yùn)營的相近產(chǎn)品的功能進(jìn)行剖析?？梢粤私鈬H與國內(nèi)在該類產(chǎn)品上的先進(jìn)做法。 （5）企業(yè)內(nèi)部產(chǎn)品研討會(huì)、員工體驗(yàn)及內(nèi)部專家評(píng)估。
1.3、用戶需求的提取與挖掘的方式 了解用戶需求的有效方式是用戶研究，這是用戶中心設(shè)計(jì)流程的第一步。其主要研究方式是：用戶訪談、用戶觀察、問卷調(diào)研、焦點(diǎn)小組、眼動(dòng)實(shí)驗(yàn)等等。并對(duì)由此得到的信息與數(shù)據(jù)進(jìn)行處理和分析。從中提取制作出初步的用戶需求文檔。 顯然這些需求是不夠的。這些需求僅僅是用戶在現(xiàn)有需求上的反饋。此外，設(shè)計(jì)師可以利用在用戶研究階段所生成的人物角色（人物畫像）這個(gè)工具，并放置到具體場景中，從而挖掘用戶可能的潛在需求。 （1）通過用戶研究直接獲取 用戶研究階段可能會(huì)出現(xiàn)各式各樣的問卷及數(shù)據(jù)列表。這些數(shù)據(jù)的收集活動(dòng)并不難，所需要付出的只是耐心和時(shí)間。 為了更多更好的獲取初步用戶的需求，用戶研究員需要在問卷調(diào)查的問卷設(shè)計(jì) 、用戶訪談、焦點(diǎn)小組等的腳本設(shè)計(jì)中，明確哪些問題或者選項(xiàng)是為需求而設(shè)置的，以便后續(xù)階段的整理。 （2）在場景中運(yùn)用人物角色進(jìn)行挖掘。 人物角色的來源、概念及功能：人物角色不是真實(shí)的人，但它是基于我們觀察到的那些真實(shí)的人的行為和動(dòng)機(jī)，并且在整個(gè)設(shè)計(jì)過程中代表真實(shí)的人，是在人種學(xué)調(diào)查收集到的世紀(jì)用戶行為數(shù)據(jù)的基礎(chǔ)上形成的綜合模型。在研究階段我們觀察用戶的行為模式，在建模階段將其模式化，最后生成人物角色。 也就是說人物角色源自于用戶研究。研究人員通過用戶研究，通過一定的標(biāo)準(zhǔn)將眾多的用戶進(jìn)行細(xì)分，從而得到不同的細(xì)分用戶群組。 細(xì)分的用戶群組經(jīng)過一定的評(píng)估、調(diào)整，從而確定細(xì)分角色群組。角色群組經(jīng)過一定的潤色。諸如為每個(gè)角色群組賦予具有代表性的照片、名稱、職業(yè)、性格等鮮明的人物屬性，從而形成不同的人物角色。 人物角色通常因其重要程度及特定定義為：首要人物角色、次要人物角色、不重要的人物角色、排斥的人物角色。 通過建立人物角色，從而將用戶研究結(jié)果以一種簡單直觀但又非常有效的方式使設(shè)計(jì)團(tuán)隊(duì)成員（決策人員、產(chǎn)品經(jīng)理、交互設(shè)計(jì)師、視覺設(shè)計(jì)師）等對(duì)大家所面對(duì)的客戶群形成一致的了解。 場景的概念與作用：用戶角色是死的，靜態(tài)的東西，只有將其放到一定的場景中去，才會(huì)鮮活起來，與產(chǎn)品產(chǎn)生交互。 場景是人物角色與產(chǎn)品進(jìn)行交互的“理想化”情景。它講述的是每個(gè)人物角色如何與產(chǎn)品進(jìn)行交互的故事。每個(gè)人物角色都將對(duì)應(yīng)一個(gè)場景，甚至更多，以求覆蓋用戶使用場景的各種情形。 在場景中使用人物角色進(jìn)行需求的挖掘:針對(duì)每個(gè)人物角色，設(shè)計(jì)合理的場景，然后集合相關(guān)的工作人員（不僅僅是交互和視覺設(shè)計(jì)師）一起進(jìn)行頭腦風(fēng)暴。再此階段每個(gè)人要有深度的同理心，并在每個(gè)關(guān)節(jié)點(diǎn)將所能想到的可能性完全說出來，記錄下來，此時(shí)的氣氛也是不加約束和不帶批判的。 在此以時(shí)間為軸“生活中的一天”為例，來針對(duì)手機(jī)瀏覽器產(chǎn)品利用人物角色來進(jìn)行需求挖掘。譬如： 早晨起來，剛起床：會(huì)看天氣預(yù)報(bào)、日歷中可能涉及的功能：天氣查詢、日歷。 吃早餐的時(shí)候：可能會(huì)看新聞、郵件以及自己的博客。這樣就會(huì)設(shè)計(jì)到新聞、微博以及郵箱。 以及交通途中：上午辦公室：中午午餐：下午辦公室：下班前：下班途中：餐廳里：家中：被窩里等等各種狀態(tài)下來挖掘可能用到的功能。 每個(gè)人物角色通過一個(gè)或多個(gè)場景的挖掘，要對(duì)其所涉及到的功能進(jìn)行羅列，并根據(jù)其在每個(gè)人物角色的重要性定義每個(gè)功能的權(quán)重，并建立excel檔。
1.4、用戶需求提升為產(chǎn)品需求，由此得出產(chǎn)品功能需求列表
以上得出的用戶需求，并不能直接轉(zhuǎn)入產(chǎn)品需求，需要經(jīng)過一定的評(píng)估和帥選考察其可行性和必要性。 可行性：目前的技術(shù)和企業(yè)資源是否有能力，是否能在現(xiàn)行的情況下，與進(jìn)度時(shí)間表等現(xiàn)實(shí)條件下開發(fā)出完全滿足用戶需求的產(chǎn)品。 必要性：用戶的這些需求是否有需要滿足，滿足這些需求企業(yè)需要付出的代價(jià)，以及是否有足夠的企業(yè)效益來支撐市場的運(yùn)營。 經(jīng)過上述驗(yàn)證，并結(jié)合前面所敘述的相關(guān)利益合作伙伴、競品分析、標(biāo)桿市場及企業(yè)內(nèi)部研討會(huì)等所得到的用戶需求，從而得到完整的用戶需求列表。 在此所有的產(chǎn)品需求都轉(zhuǎn)化為產(chǎn)品功能。工作人員可以將之前用戶研究階段收集的功能需求合并到后來利用任務(wù)角色在場景下挖掘的需求列表中。他們本質(zhì)上也相應(yīng)對(duì)應(yīng)著不同的人物角色。 在這里，角色的權(quán)重（可以根據(jù)首要人物角色、次要人物角色、不重要人物角色等分成3點(diǎn)量表或者5點(diǎn)量表）與對(duì)應(yīng)的任務(wù)的權(quán)重的乘積，就是功能總的重要程度。
二、交互設(shè)計(jì)流程（一）交互設(shè)計(jì)三段式 草圖——低保真原型——高保真原型 我們看到的這張圖實(shí)際上他畫的相當(dāng)規(guī)整，它已經(jīng)是一個(gè)完整的產(chǎn)品架構(gòu)圖。但是我們工作中的話可能只是信手拈來，草草的畫上幾筆，這些都沒關(guān)系，草圖強(qiáng)調(diào)的就是能快速地將想法具體化，然后和其他同事進(jìn)行討論。 低保真原型圖：就是在草圖的基礎(chǔ)上，通過計(jì)算機(jī)的幫助，由簡單的線框和文字去繪制這個(gè)界面。當(dāng)然，低保真原型不能只是簡單的看，還要進(jìn)行一些簡單的交互操作。用白話來講就是動(dòng)態(tài)，可以簡單地進(jìn)行體驗(yàn)一下這個(gè)設(shè)計(jì)，盡可能的發(fā)現(xiàn)一些問題。去進(jìn)行一定的修改。 高保真原型圖：就是先在這個(gè)線框圖的基礎(chǔ)上進(jìn)行視覺設(shè)計(jì)，在將這個(gè)視覺設(shè)計(jì)稿呢制作成可進(jìn)行交互操作的原型。這個(gè)效果很可能都能和最后的那個(gè)產(chǎn)品相差無幾，甚至你可以在你的手機(jī)上進(jìn)行模擬的操作。 高保真原型呢一般用于交付給開發(fā)與測試那邊。開發(fā)人員將按照高保真原型進(jìn)行開發(fā)。測試人員將以高保真原型為基準(zhǔn)，對(duì)開發(fā)人員交付的產(chǎn)品進(jìn)行測試。
所以大家可以看到，在設(shè)計(jì)流程中，設(shè)計(jì)師首先要通過草圖與產(chǎn)品經(jīng)理以及其他同事進(jìn)行討論，以確定產(chǎn)品的設(shè)計(jì)方向。之后再做一個(gè)低保真原型來進(jìn)行打磨設(shè)計(jì)。在之后會(huì)制作高保真原型來交付給開發(fā)和測試人員。 所以設(shè)計(jì)師的整個(gè)這個(gè)設(shè)計(jì)工作都是一個(gè)和其他角色進(jìn)行溝通的一個(gè)過程。而我們剛才提到的設(shè)計(jì)的三個(gè)步驟也是圍繞溝通而展開的。 （二）為什么要畫原型 原因在于減少修改成本，便于溝通討論。
畫原型最大的目的呢，是為了減少后期修改成本，用一個(gè)低成本的原型去體驗(yàn)去討論，去修改，盡量避免開發(fā)好了再去修改。第二呢，一個(gè)可交互的原型更方便和其他人去進(jìn)行溝通和討論，所謂一圖勝千文。所以圖片比文字的溝通效果要好很多。那么，如果說是原型，或者可以交互的原型，它的溝通效果就要比圖片要好很多。 所以，需要強(qiáng)調(diào)的是，原型只不過是一個(gè)設(shè)計(jì)工具，設(shè)計(jì)的思想才是真正的核心所在。所以，在學(xué)好工具的基礎(chǔ)上，應(yīng)該多花時(shí)間在設(shè)計(jì)思路的學(xué)習(xí)上。
三、開發(fā)接下來就到了程序員編寫程序的三個(gè)步驟了。（關(guān)于開發(fā)，在這里不做詳述） 1、app軟件開發(fā)大功能模塊代碼編寫 2、app軟件開發(fā)大概的界面模塊編寫 3、把大概的界面和功能連接后，app軟件開發(fā)的大致demo就出來了 4、demo自己試用和體驗(yàn)幾遍后，根據(jù)情況修改 5、沒有大錯(cuò)誤后，0.9版本可以嘗試尋找beta用戶 6、根據(jù)測試用戶的反饋，重復(fù) 前三個(gè)步驟
四、測試測試工程師，一般就是從用戶角度出發(fā)，檢測開發(fā)工程師做的東西是不是符合產(chǎn)品的需求，或是用戶體檢好不好？不要求有太專業(yè)的知識(shí)，但是要細(xì)心，對(duì)產(chǎn)品敏感。所以有很多不是計(jì)算機(jī)專業(yè)的人員照樣可以做測試工程師，因?yàn)槲覀兊漠a(chǎn)品需要不同的人來說嘛。 也有比較專業(yè)的白盒或是灰盒測試，這就要求測試人員會(huì)些兒編程技術(shù)了，但是要求不太高，不必會(huì)某種語言的高級(jí)編程，普通應(yīng)用或是代碼段能看懂就行。問題要考慮全面，細(xì)致，有原則，不能跟著開發(fā)和產(chǎn)品走，這是測試人員的要求。
（一）軟件測試的測試流程有： 制定測試計(jì)劃——編輯測試用例——執(zhí)行測試用例——發(fā)現(xiàn)并提交BUG——開發(fā)組修正BUG——對(duì)已修正BUG進(jìn)行返測——修正完成的BUG將狀態(tài)置為已關(guān)閉，未正確修正的BUG重新激活. （二）規(guī)范的測試流程 需求分析：需求分析由產(chǎn)品人員制定，他們要做的不是一份簡單的文檔，而是細(xì)化每一個(gè)功能的細(xì)節(jié)，每一個(gè)按鈕的位置，對(duì)于稍大或復(fù)雜一點(diǎn)的需求都進(jìn)行建模。 需求評(píng)審：這里會(huì)叫上所有參與項(xiàng)目人員進(jìn)行，開發(fā)人員、測試人員、QA人員。測試人員提出需求，開發(fā)人員考慮功能實(shí)現(xiàn)的方案與可行性、當(dāng)然開發(fā)負(fù)責(zé)也是要參與的。測試人員主要是對(duì)需求的理解提出疑問，以便才能根據(jù)需求寫用例。QA人員是最終對(duì)軟件質(zhì)量進(jìn)行驗(yàn)證的人，所以也需求了解需求 開發(fā)人員編寫排期：開發(fā)人員需求根據(jù)需求功能點(diǎn)進(jìn)行排期。然后將開計(jì)劃轉(zhuǎn)交給測試人員。 測試計(jì)劃排期：測試人員根據(jù)開發(fā)計(jì)劃，對(duì)測試具體測試時(shí)間，也就是開發(fā)功能完成后的時(shí)間，進(jìn)行幾輪測試等。然后，把項(xiàng)目的開發(fā)與測試計(jì)劃發(fā)送給各部門負(fù)責(zé)人及參與項(xiàng)目的所有人員。 編寫測試用例：根據(jù)詳細(xì)的需求分檔，開始進(jìn)行用例的編寫。 用例評(píng)審：在用例進(jìn)行評(píng)審之間，先以郵件形式將用例發(fā)送給相關(guān)人員，以便他們事先了解用例對(duì)哪些功能進(jìn)行驗(yàn)證以及驗(yàn)證的細(xì)節(jié)。 然后，測試人員組進(jìn)行用例評(píng)審，開發(fā)人員對(duì)用例與實(shí)際功能不符合有哪些，產(chǎn)品人員對(duì)會(huì)通過用例對(duì)功能的具體實(shí)現(xiàn)進(jìn)行把握等等。 提交基線：開發(fā)人員完成所有功能后，會(huì)對(duì)自己的功能進(jìn)行一個(gè)自測。自測完成后提交測試人員進(jìn)行基線。
（三）具體測試流程： 開發(fā)人員對(duì)于基到測試線的功能進(jìn)行測式，發(fā)現(xiàn)的問題通過缺陷管理工具進(jìn)行反饋，開發(fā)人員對(duì)問題進(jìn)行修復(fù)，然后，準(zhǔn)備第二輪基。 測試人員完成第一輪測試后，需要寫測試結(jié)論，發(fā)到相關(guān)人員。然后對(duì)基線后的第二輪進(jìn)行測試，第二輪會(huì)對(duì)第一輪中發(fā)現(xiàn)的問題進(jìn)行重點(diǎn)回歸。 測試通過：經(jīng)過兩到三輪或四輪的測試后，直到?jīng)]發(fā)現(xiàn)新的問題，或暫時(shí)無法解決，或不緊急的問題。通過上級(jí)確認(rèn)，可以通過。編寫測試報(bào)告與驗(yàn)收方案。 驗(yàn)收方案是交由QA進(jìn)行驗(yàn)證的。在現(xiàn)公司的流程中是將測試與QA分開的，測試人員重點(diǎn)關(guān)注的是功能是否可以正常運(yùn)行。QA關(guān)注的是整個(gè)流程的質(zhì)量以及最終用戶的質(zhì)量。有些公司QA與測試是不區(qū)分的，但這對(duì)測試的要求會(huì)更高，除了關(guān)心功能，還需要關(guān)心整體流程與質(zhì)量。 流程分析：這個(gè)流程是規(guī)范的，測試真正融入了整個(gè)流程，而且還擔(dān)任了很重的角色，從而也有效的保證了軟件產(chǎn)品的整體質(zhì)量。 那么這個(gè)流程是不是完美的呢？不，這個(gè)項(xiàng)目流程太強(qiáng)化各種文檔。我們來看測試的工作內(nèi)容，測試計(jì)劃、測試用例、測試結(jié)論、測試報(bào)告、驗(yàn)收方案、問題的提交跟蹤。其實(shí)，我們真用于測試的時(shí)間是非常少的，在一周的時(shí)間，也許只有一天或不到一天的時(shí)間是在進(jìn)行測試的。測試人員只有在測試的時(shí)候才會(huì)體現(xiàn)出他的價(jià)值。而大部分工作卻不能體現(xiàn)他的價(jià)值。 當(dāng)然，我這里會(huì)省略與測試主流程無關(guān)的東西，真正的測試工作中瑣事很多。
（四）敏捷測試流程 前面講的第一種流程，還是第二種流程都是瀑布式的，嚴(yán)格來說第一種簡陋的都不能稱為瀑布式，對(duì)于一個(gè)三個(gè)月的項(xiàng)目說，產(chǎn)品把需求分析完了給開發(fā)，然后產(chǎn)品就沒事兒了；開發(fā)開發(fā)完成之后給測試，然后開發(fā)人員也不忙了。 測試完成之后上線。那么在產(chǎn)品分析的階段，開發(fā)和測試都是沒事干的（這里只對(duì)單一項(xiàng)目）。 開發(fā)階段，產(chǎn)品和測試也基本沒事兒。同樣在測試階段，產(chǎn)品與開發(fā)也是沒什么事兒的。 敏捷測試的一個(gè)核心是迭代，在每個(gè)時(shí)間點(diǎn)上，所有項(xiàng)目人員都是有事可做的。 1、下面是我理解中的敏捷測試流程圖： 第一階段： 通過上面的流程圖，對(duì)于一個(gè)月的需求分析，在敏捷中，可能三五天就確定下來。這個(gè)需求定得會(huì)很模糊，但整體框架確定。產(chǎn)品對(duì)其中某一模塊功能確認(rèn)，開發(fā)人員開始對(duì)確認(rèn)的功能編碼，開發(fā)人員編碼的過程中，測試進(jìn)行功能分解，因?yàn)楦鶕?jù)模糊的需求很難寫出具體的用例，所以，只能盡量對(duì)功能進(jìn)行分析得細(xì)些，標(biāo)注需要驗(yàn)證的內(nèi)容。 第二階段： 開發(fā)完成后交給測試人員進(jìn)行測試，開發(fā)人員繼續(xù)開發(fā)新的功能。那么測試人員發(fā)現(xiàn)的問題怎么辦呢？會(huì)從開發(fā)團(tuán)隊(duì)中抽出一個(gè)人員來用于解決測試發(fā)現(xiàn)的問題。但開發(fā)進(jìn)度并沒有因?yàn)闇y試而停止。 流程分析： 在這個(gè)流程中弱化了文檔，強(qiáng)調(diào)了各個(gè)人員的溝通，通過這種迭代的方式，三個(gè)月的項(xiàng)目，可以能兩個(gè)月和兩個(gè)半月就會(huì)完成。 但這種流程并非完美，加入一個(gè)功能在需求分析階段就是錯(cuò)誤的，因?yàn)樗且粋€(gè)迭代漸進(jìn)的過程。也只能一路錯(cuò)下去。
2、對(duì)測試問題的處理 上面的圖更能清晰看出對(duì)問題的處理過程。 第一塊面板中是開發(fā)人員未實(shí)現(xiàn)的功能，第二塊面板中是開發(fā)完成功能，測試人員對(duì)其進(jìn)行測試，發(fā)現(xiàn)不通過的就放回未開發(fā)的面板中，測試通過的將放到第三塊面板中。 |
|
|
