第五篇 12、13、14、15章

使用者體驗：

    要素：使用者的第一印象，誰是目标使用者，什麼樣的人，使用方式，從哪裡進入軟體，知道是做什麼的嗎，使用者用軟體的目的，怎樣使使用者找到自己想要的功能以及掌握基本功能。（5W1H方法（who,when,where,what,why,how））

    從使用者的角度考慮問題：同理心

    使用者需要幫助，但是并沒有那麼笨

    團隊成員都盡可能在實際工作和生活中使用自己開發的産品（從内部測試部開始）

    通過“基于場景的設計”來強化團隊成員對使用者體驗連貫性的了解

    UI設計：頭一次使用産品的使用者和第N次使用産品的使用者

    短期刺激和長期影響都需要被考慮到

    高明的設計：不需要花費額外注意力，也不需要經驗與專業知識即可憑直覺完成正确的操作

    情感的設計:本能層次——外形；行為層次——使用的樂趣和效率；反思層次——自我形象、個人滿足感、回憶。

使用者體驗的一個重要目的就是要降低使用者的認知阻力。

軟體測試：

    單元測試（Unit Test）——在基本的功能/參數上驗證程式的正确性

    功能測試——驗證子產品的功能

    內建測試——驗證幾個互相有依賴關系的子產品的功能

    場景測試——驗證幾個子產品能否完成一個使用者場景

    系統測試——對于整個系統功能的測試

    内部/外部測試    Alpha/Beta測試——測試員在實際使用者環境中對軟體進行全面的測試

    代碼覆寫率測試（Code Coverage Analysis）

    建構驗證測試（Build Verification Test ,BVT）

    驗收測試（Acceptance Test）“探索式”測試（Ad hoc Test）

    回歸測試（Regression Test）場景/內建/系統測試（Scenario/Integration/System Test）

    夥伴測試（Buddy Test）:寫好單元測試，或者運用重構技術 以保持穩定性

    效能測試（Performance Test）壓力測試（Stress Test）

品質保障：

    實作CCMI 能力成熟度模型內建 Capacity Maturity Model Integrated

    安全幻想：“人肉認證”和安全的幻想“given enough eyeballs , all bugs are shallow”

穩定和釋出階段：

    ZBB（zero bug build)、RC（release candidate）、RTM（release to manufacturer）

    會診小組（Triage Team）：

        修複、設計本來如此、不修複、推遲

    DCR（Design Change Request ）：

        問題在哪，問題的影響；如果不修改，會有什麼後果；幾種修改方案，各種方案的優缺點和成本

    最後回歸測試、砍掉功能、修複Bug 的門檻逐漸提高、逐漸當機（讓目前版本和将來的版本的工作分開進行）

    版本釋出：不同目标人群+不同釋出頻率的方式

    釋出之後——事後諸葛亮會議：

        如果重新來過，什麼方面可以做的更好？

        多問幾次為什麼，層層推進

    銀彈：每個角色的代表在項目過程中可以使用有限次的“停止争論，按我說的辦”

問題：

1，在12章中，從使用者的角度考慮問題，講到需要有同理心，但是真的有同理心就夠了嗎？我是覺得在初始版本可以隻是滿足先滿足同理心的要求，但之後我覺得應該盡量做到有預測到使用者可能會出現的問題，即盡可能在使用者遇到問題前就已經解決問題或者有解決問題的方案

2.在短期刺激和長期影響中，我們生活中也有很多不那麼合理的設定，例如電腦太低，使用電腦會不得不彎腰駝背，那有問題了，我們應該怎麼更好地去面對和解決問題？

3.在使用者體驗設計的步驟和目标中，假若我們不斷把認知阻力降低了，會不會有這樣一個問題：我們使用軟體結果和使用紙和筆的結果差不多，那麼使用者為什麼使用我們的軟體而不是直接用紙和筆呢？

4.在書上12章課後練習與讨論，第4題中，我覺得直接設定靜音鍵這就是一種沒有對于使用者的同理心，靜音隻是一種結果，為什麼不設定是什麼情況下的靜音呢

5.之前上課，老師講到了CMMI，我覺得這是和我們生活中很密切的事情，我們為什麼不都站起來，切實用這個模型做一些事情來更好地了解和體驗CMMI呢

6.在夥伴測試中， 我們除了寫好單元測試和運用重構技術以外，能不能模拟使用場景來假設資料來更好地測驗我們的子產品和功能