如何寫產(chǎn)品可用性測試報告？

最近完成了一個我司初始期產(chǎn)品的可用性測試項目，基本可以理解為對新用戶進行一下產(chǎn)品全流程各關(guān)鍵節(jié)點的體驗走查，但也涉及了首頁改版設(shè)計的需求挖掘。本篇主要是記錄一下其中可用性測試部分的報告是如何向業(yè)務方呈現(xiàn)的，且怎么呈現(xiàn)更具有說服力與專業(yè)性。

首先，對于可用性任務的設(shè)置與計算方法網(wǎng)上已經(jīng)介紹的十分詳細，對于基本測試方法有需求的朋友可以隨手某百，我就不再贅述。在這里，個人推薦一本書Jeff Sauro等人所著的《用戶體驗度量》，書中對于可用性測試樣本的統(tǒng)計指標與方法，常用的可用性測量問卷與分數(shù)轉(zhuǎn)化、對照參數(shù)已經(jīng)有了很好的解讀與傳授教學。

一般，可用性測試的周期從接到需求到出具完整報告，我這邊的項目周期是2-3周。這個時間的跨度取決于目標用戶的招募難度與業(yè)務數(shù)據(jù)的完備性。我們在進行完整測試及對樣本數(shù)據(jù)整理和匯總后，就進入了報告的撰寫階段。這個環(huán)節(jié)，才是傳達用研價值的最關(guān)鍵環(huán)節(jié)。

話不多說，直接進入報告架構(gòu)環(huán)節(jié)交代：

（PS：以下是我個人的報告架構(gòu)，歡迎更專業(yè)的用研高手指點拔高）

Part 1 研究背景：

1.交代研究目的（一針見血指出你這個報告能干嘛，結(jié)合業(yè)務發(fā)展背景更能提高觀眾的閱讀興趣）

2.樣本招募標準與配比，且需要把每個用戶的基本產(chǎn)品使用經(jīng)驗進行下簡單介紹，幫助業(yè)務方基本了解一下目前用戶本產(chǎn)品與同類產(chǎn)品的使用經(jīng)驗（指標：頻率、時長、深度、接觸渠道等）

3.如果業(yè)務方對研究方法不是很了解可以對方法也進行下介紹（目的作用、樣本量代表性說明、可用性測試監(jiān)測指標、計算方法等等）。個人覺得這個環(huán)節(jié)挺必要，因為業(yè)務方往往能夠系統(tǒng)掌握方法論的較少，向上匯報的時候這些信息能夠很前置且直觀的打消觀眾的后續(xù)閱讀疑惑

Part 2：產(chǎn)品可用性測試評估：

1.當前產(chǎn)品整體可用性水平、曲線分級范圍（整體可用性量表分數(shù)轉(zhuǎn)化計算得出）

2.關(guān)鍵任務（功能）的可用性水平：在這里我們可以結(jié)合功能價值與任務可用性水平一并輸出一個XY軸的四象限圖，一目了然劃分流程體驗優(yōu)先級水平。隨后，基于不同任務的可用性指標對比找出目前各環(huán)節(jié)的關(guān)鍵問題。推薦一篇文章，大家可以參照這位大大的詳細說明來進行呈現(xiàn)與繪制。

文章——可用性測試：任務評估模型與計量方式

補充：如何測功能價值（在用戶節(jié)點任務完成后使用自評題）

題目如下：

PART 3 ：流程可用性問題梳理

在Part 2 已經(jīng)對產(chǎn)品整體、分流程的可用性水平以及存在的主要節(jié)點問題已經(jīng)進行了說明。很好的培養(yǎng)了觀眾對于報告第三部分的閱讀理解性與重點關(guān)注。

本部分的書寫是個體力活——呈現(xiàn)問題

建議：按照測試流程/產(chǎn)品使用流程分塊梳理匯總。

格式：產(chǎn)品界面、問題、影響等

tips：對于每個任務流程的問題進行總結(jié)與給予優(yōu)化建議（體現(xiàn)用研價值，體現(xiàn)個人業(yè)務水平）

Part 4 : 問題優(yōu)先級水平劃分

找出來問題以后，我們需要對問題進行優(yōu)先級水平的計算反饋與問題屬性劃分，屬性劃分這里我們可以對應尼爾森十條可用性原則進行界定

這么做的好處有兩點：第一點，算是對報告的第三部分進行一個問題清單整理（畢竟在上一部分一頁PPT寫不了幾個問題），第二點是問題優(yōu)先級能夠直接醒目劃分優(yōu)化的重點與順序。整體對于后續(xù)業(yè)務基于此統(tǒng)一向用研返回問題優(yōu)化排期幫助意義較大。

附：問題指標計算量綱

以上，整理完。

畢業(yè)后從事用研工作已有一年，之前對于項目的總結(jié)復盤做的不夠到位。之后會逐漸更新自己的項目心得體會。熱烈歡迎五湖四海同行人士對我進行拍磚指點。

軟件寫好后測試好的,但過一段時間會出問題

測試人員在工作中經(jīng)常打交道的肯定是開發(fā)和產(chǎn)品經(jīng)理，開發(fā)將程序?qū)懗鰜?，測試員進行測試。軟件測試完成后，產(chǎn)品才能生產(chǎn)，在這過程中，難免會遇到軟件會出現(xiàn)問題的情況。那么你肯定聽過這些話：
“這么明顯的bug你都測不出來嗎？”
“為啥這個功能還沒測完就上線了？”
“研發(fā)時間不夠，你壓縮一下測試時間”
“這個bug和開發(fā)沒關(guān)系，注意看需求”
聽到這些話，相信你分分鐘高血壓，這個鍋不知不覺就“甩”到你身了。
問題的關(guān)鍵來了，很多測試員就會出現(xiàn)這種疑問：軟件測試完后，還有Bug，責任全都在測試嗎？
? PS：這里分享一套軟件測試的自學教程合集。教程很全，總量達到300G，有從0基礎(chǔ)開始學的全套完整視頻教程和配套的視頻課件，以及大量的測試項目練習案例（市面上絕無僅有），配合視頻一起學，大概堅持個30天，就能學到不少知識點，學完后找個初級的功能測試工作是沒問題的！
----資料包內(nèi)容詳情---- ? 215集-零基礎(chǔ)到精通全套視頻課程 ? [PPT+代碼]-完整配套的教學課件 ? 18套-測試實戰(zhàn)項目源碼 ? 37套-測試工具軟件包 ? 268道-測試猿畢業(yè)學員真實面試題 ? 500個-面試簡歷模板（信息完整）
『學習資料領(lǐng)取 』300G軟件測試視頻+PPT課件+項目源碼+面試指導48 贊同 · 1 評論文章
我個人覺得應該理性看待，具體問題，具體分析。
當上線后，出現(xiàn)bug后，肯定第一時間應該找測試，測試同學查看是否能復現(xiàn)這個問題，定位漏測問題原因。
如果為頁面有錯別字、頁面樣式重疊嚴重的、功能不可用，用例覆蓋不全面，業(yè)務理解不到位導致的這種非常淺顯可以復現(xiàn)的問題，出了問題，找到測試，無可厚非。
如果是“不可預測、未知”的問題，比如說性能測試中，給出指標并已經(jīng)測試10000人并發(fā)，并已告知開發(fā)人、產(chǎn)品測試并發(fā)量的情況，而開發(fā)、產(chǎn)品人員均沒有提出異議。
但結(jié)果那天由于銷量超好，并發(fā)量達到100000，系統(tǒng)崩潰了，這并不是我們能預測到的，所以是漏測，也不是一個人責任。
所以要對問題定位分析之后才能定位出來，是什么原因，是需求不明確，理解歧義，開發(fā)引入，或是其他原因，然后及時補救，最后再去定責。
舉個例子測試工程師們就會明白，不是所有的鍋都得測試背
1、假設(shè)是軟件版本更新，開發(fā)人員在進行影響分析時漏掉了可能會影響的一個功能，而測試也沒有測到這個功能，恰恰這個功能上線出了問題，那沒說的，開發(fā)的責任；
2、軟件開發(fā)延期導致原本兩輪的測試變?yōu)橐惠啘y試，測試不充分導致出現(xiàn)BUG，這應該是整個項目組的責任；
3、軟件按時提交測試，BUG出現(xiàn)在測試覆蓋范圍內(nèi)，那么就是測試的責任；
4、測試BUG較多，測試部門要求延期上線，結(jié)果客戶或者領(lǐng)導壓下來，說必須按時上線，你說這是誰的問題？
所以，軟件測試完后，還有Bug，不一定都是測試的鍋，首先要清楚的知道是什么原因?qū)е鲁霈F(xiàn)的bug，所以這個時候就需要有人來組織這個Bug的責任認定和后續(xù)改進。
線上Bug的討論一般有如下這些內(nèi)容：
1、Bug的產(chǎn)生原因，仔細地分析Bug為什么會產(chǎn)生，這個環(huán)節(jié)很重要，因為這個環(huán)節(jié)弄清楚以后，責任認定就清楚了。
2、Bug的責任認定，一般來說，除了那些責任真的很清晰的Bug之外，很多Bug都是開發(fā)、測試、策劃、項目經(jīng)理共責的，為了團隊的團結(jié)，也沒有必要去討論哪個團隊負主要責任。
3、Bug影響范圍，分析這個Bug對于用戶造成的影響。
4、改進措施，在改進措施這一項中，可以把以后如何避免類似Bug的措施寫進去，并在任務系統(tǒng)建立任務，指定專門的人跟進。
其實，說到底，還是因為職責劃分不清晰導致的“背鍋”。
那再來說下項目組實際Bug的責任認定吧：
1、如果測試時間還是比較充足，測試用例有寫，但是還是漏測的，那就是測試的責任。
測試用例沒有覆蓋，測試用例覆蓋了卻沒有執(zhí)行，各有不同的偏重點，前者參與評審的相關(guān)人員都有責任，后者測試組的完全責任，PM也有對應責任。
2、如果測試時間不充足，測試用例有寫，但是因為時間不足而降低回歸測試范圍，導致漏測的，那一般是項目組各個角色共責的。
3、如果有開發(fā)修改了功能沒有通知測試人員，導致線上漏測的，那就是開發(fā)的責任。
4、如果策劃人員在回歸測試階段還提了需求變更，在測試人員明確告知風險的情況下還堅持要上需求變更的，那就是策劃的責任。
5、需求覆蓋不到的地方，描述不清楚的地方，需求，設(shè)計和測試都要承擔一定的責任，需求的責任最重。說需求人員的責任大家都容易理解，為什么說設(shè)計和測試還有PM都有責任，是因為需求的評審是需要設(shè)計和測試參與的，角度不同，具體這里就不展開了。
除非判斷就是需求采集中的重大缺陷，否則設(shè)計和測試都有關(guān)聯(lián)的次要責任。
6、設(shè)計過程，開發(fā)過程沒有實現(xiàn)，需求檢查到了，設(shè)計和開發(fā)卻沒有彌補。設(shè)計和開發(fā)的責任，PM責任最大，監(jiān)管不到位。
7、交付部署中出現(xiàn)的問題，版本拿錯的責任，一般在于PM，配置管理員和測試經(jīng)理，也有可能是因為沒有足夠明確的制度造成了混亂，這樣需要部門經(jīng)理或者更高層的人員來牽頭負責。版本拿對了，安裝過程出錯，交付部署人員的責任最大，項目經(jīng)理次之。
對于測試人員來說，測試階段如果因為時間缺少、需求變更頻繁等原因?qū)е禄貧w測試范圍不足的，一定要盡早跟項目組正式地發(fā)郵件溝通情況，讓大家盡早知曉風險，這樣出現(xiàn)線上Bug的時候，項目組其他人員就不會認為測試工作沒做到位。
測試人員如何有效避免“背鍋”呢?

1、留出足夠的測試時間
要保證測試時間，從流程上就要做起，說明測試的重要性，我看很多測試對自己的重要程度一直沒認識到。在項目排期時，就要定夠足夠的測試時間(一般都是給一點冗余時間，以處理突發(fā)事件)。如果說因為特殊情況導致測試時間不夠，比如開發(fā)沒有按預期提測，產(chǎn)品需求變更，也要勇于提出或者延期發(fā)版，或者減少功能，以保證自己測試時間。如果說這兩點都不能保證，則在測試報告中寫明，由于xxx情況，導致測試時間不足，所引起無法完全覆蓋。
2、做好數(shù)據(jù)備份。凡事不要口頭溝通。
我看有些人背鍋，明明測過了，提過bug，但是線上又出現(xiàn)了人家說你提的bug 呢？你說我只是和開發(fā)說了一句…呵呵，空口無憑。提bug 的時候，不要途一時之快，不寫bug口頭溝通，這樣沒事的時候你好我好大家好，出了事，你想甩鍋都沒辦法甩。包括前面測試的版本包，都備份下來。如果確實是開發(fā)后面改動引起的問題。你可以把前面的版本包拿出來驗證，如果沒問題，則可甩部分鍋給開發(fā)(這里部分看能力，如果是我以前老大，鍋就全甩過去了)
3、寫好測試報告。
對于有風險的內(nèi)容，測試報告里一定要寫清楚，比方說前面說的時間不夠。又或者是一些情況，測試環(huán)境不好驗證。注明后，發(fā)給團隊，團隊人周知，并且是項目負責人拍版可以后再進行發(fā)版。測試報告不要隨便寫寫就算了，非常重要。
4、甩鍋給開發(fā)，產(chǎn)品沒關(guān)系，不要甩鍋給同是測試組員，或者手下，否則后患無窮。
我就碰見過一個甩鍋給手下的老大，最后鬧的兩個人都不說話，有事就發(fā)郵件溝通。畢竟測試同學都是小伙伴，誰是我們的朋友，誰是我們的敵人，還是要分清楚的。滴水不漏的甩鍋給手下，同事，最后難免搞的自己孤家寡人。事實上，我碰見我的組員出一些問題，都會主動幫他分擔部分責任的，讓他感覺我在挺他。這樣才能保證測試團隊的凝聚力。
總結(jié)
保證軟件高質(zhì)量，并非只是測試人員的責任，軟件質(zhì)量體現(xiàn)在功能質(zhì)量、結(jié)構(gòu)質(zhì)量和過程質(zhì)量三個方面，對產(chǎn)品質(zhì)量負責，意味著要對這三方面共同負責。當出現(xiàn)Bug時，對于企業(yè)來說，問題不解決，只是糾纏問題是誰的責任，公司會被這些人直接拖垮，這時候?qū)τ谄髽I(yè)來說最重要的就是解決問題！所以對于產(chǎn)品質(zhì)量，最理想的狀態(tài)還是做到人人都為產(chǎn)品質(zhì)量負責，為了達到這個目標，我們需要建立一種重視質(zhì)量的文化，每個人才會確確實實地對質(zhì)量負責。
另外給大家總結(jié)一下如何避免漏測：

吃透業(yè)務需求
需求評審階段，產(chǎn)品經(jīng)理、開發(fā)、測試在開會之前，一般都會收到一份需求文檔和原型圖。在開會前，研讀好需求文檔后，做好理解不明確和產(chǎn)生歧義的地方，待產(chǎn)品經(jīng)理組會來講解需求時，針對不懂的地方進行提問，認真記錄。
提高用例質(zhì)量
提高用例覆蓋率，結(jié)合業(yè)務設(shè)計有效業(yè)務場景，保證測試有效性。
做好用例評審
測試人員結(jié)合用例對需求進行反串講，把對需求的理解講一遍，列出所有的測試點和測試場景，產(chǎn)品和開發(fā)同事評審是否有遺漏場景，如果沒有異議，這樣就可以很大程度的避免漏測了。

增加交叉測試
一個人精力畢竟有限，如果條件和時間允許，可以把測試過的功能交給你的搭檔，讓他幫忙在測試一下，畢竟每個人的測試思路不一樣，也許也有收獲也不一定呢。
有效回歸測試
梳理主流程用例，尤其隨著版本迭代和功能的增加，回顧測試用例極為重要，畢竟每次發(fā)版時，要保證主流程沒問題吧，主流程都有問題，難道還敢上線？
可能有的同學說了，那么多用例，也執(zhí)行不完呀，不是有web自動化嗎，自動化跑唄，可能有的同學說不會呀，咱們學可以嗎？
bug仲裁
在上線前，查看還有哪些問題，是未解決的，與產(chǎn)品、開發(fā)、測試經(jīng)理商量，哪些bug是允許帶到線上的，如果三方達成一致，那么線上再出問題，也是已知的，就沒什么問題了。
做好漏測復盤
對待漏測態(tài)度上必須要重視，分析為何會漏測，是哪個環(huán)節(jié)出了問題，是流程問題還是技術(shù)問題？
同樣的坑別踩第二次，技術(shù)不足的學習補齊，流程不足的規(guī)范流程。
把它當做一次提高的機會，也正因為這次機會，讓你印象越深刻，能夠避免下次不會再犯同樣的錯誤。

ppt 程序報告中 測試，結(jié)果分析該怎么寫

順序是這樣的：實驗題目》》實驗目的》》實驗要求》》實驗器材（當然寫計算機了）》》實驗流程圖（就畫那些什么平行四邊形里寫開始，橢圓形里寫步驟的那種）》》實驗步驟（寫程序代碼）》》結(jié)果分析（寫詳細些
比如寫輸入什么
輸出了什么
如果結(jié)果有問題
你可以分析
比如因為循環(huán)次數(shù)少導致的或怎么樣）