關於軟體品質的思考 - 什麼是品質？

標籤：

關於軟體品質的思考 - 什麼是品質？

當選擇一個商品的時候，我們常掛在嘴邊的一個詞就是“品質”，這是影響我們選擇的一個很重要的指標。這一篇我們就來探討一下什麼是軟體的品質。當然，都是個人的一些觀點，不同意可以拍磚或者來探討。

　　品質這個詞用得太普遍以至於混亂，有時候它表示品質這個指標，有時候它隱含品質好的意思。而且不可避免的，好的品質常常和它的反面聯絡在一起，就好像以前的“品質萬裡行”，或者現在的3.15，列出的都是品質方面的問題，好像很少宣揚品質好的產品。所以很多時候，我們看品質是從反面(缺陷，或者品質不好的地方)來看的。在下面討論的時候我們也會用或正或反的例子來看。雖然是在探討軟體的品質，但是為了便於理解，可能也會舉別的產品的例子。

　　前一篇裡面也提到，在傳統的關於軟體缺陷的定義中，是看實際做出來的產品是否和規格說明書(spec)一致，如果不一致那就是defect或者俗稱bug。如果只是從這個範圍來看，這個定義本身沒有問題，因為如果做出來的東西不是我們想要的，那當然不對。所以下面我們得出品質的第一個方面。

　　Quality scope #1： 實現了說明書上的功能

　　比如你下載了一個電影播放器，它宣稱可以支援MP4, MOV, RMVB, AVI格式，那麼它必須可以正確播放這些格式的檔案。這是一個很基本的要求，就像洗衣機要能洗衣服。如果實現這樣的準系統出現的問題，那麼使用者會非常生氣，覺得品質太差，根本不能用，直接卸載掉，或者要求退貨(商業產品)。

　　正因為這樣的後果很嚴重，所以在測試中，對於這樣的準系統我們都會反覆驗證。

　　OK， 如果說明書上說的功能都實現了，那麼就是一款品質很好的產品了嗎? 實際上可能並非如此。那麼差別在哪裡呢?

　　Quality scope #2： 一些不言自明的要求

　　為什麼說是不言自明呢。舉個例子， 還是洗衣機，客戶可能會說“我想買一台洗衣機”。然後他買回去一台，價格也還不錯。回去後發現確實能洗衣服(上面提到的準系統實現了)，但是有個問題，這個洗衣機洗一次衣服需要3個小時，而且洗的時候噪音很大。

　　洗衣機是很普遍的一個商品，使用者在一開始買的時候可能也不會問洗一次要多長時間或者噪音多少分貝。這並不代表他沒有這方面的標準，而是“不言自明”。 如果事先沒有說明，這可能會帶來一些糾紛，但是最終生產這樣的洗衣機的廠家一定是這些問題的受害者。因為大家都會知道這個牌子的洗衣服超慢，而且噪音大。而如果只按照第一個scope的要求，它可能是一個很合格的產品，而且或許衣服還洗得挺乾淨的，通過了QA的測試。

　　我相信這一類的例子還可以舉出很多

　　筆記本： 發熱量比較小，不會太燙

　　殺毒軟體：佔用系統資源不要太多，機器啟動也不會變得很慢

　　網上購物系統：回應時間不能太長

　　這方面的要求有很多，比如包括safety， performance，stability，impact to other software...

　　也正因為這一類的要求是“不言自明”的，所以開發的時候反倒容易被忽視。當然也可能是故意被忽視，因為技術和成本的原因，很多山寨產品就是如此吧。

　　比較好的做法是我們把這些方面的需求明確的列出來，並儘可能的進行量化。比如前面例子中涉及的時間和噪音問題，如果在內部的設計文檔中就有明確的要求，最終出來的產品就不會有這麼大的問題。

　　關於這一類的需求，還有幾個特點。

　　1. 這方面的要求不容易確定，也不容易評估或者驗證。

　　比如performance，比單純的某個功能點，要複雜很多，有時候甚至什麼是performance夠好或者很好都難以界定。所以這也要求產品的設計和開發人員對產品和使用者的需求有更輸入的理解，而不只是照著做。

　　2. 這方面的產品特性是難以被抄襲的。

　　國內的山寨能力想必大家都見識過，很多產品出來後很快就有了功能十分相近的仿製品。小到手機，大到汽車。iphone的山寨版長得很像哦，而且也可以全屏觸摸，multi-touch，而且不到1千塊。還有雙環的SUV，遠一點看就是BMW X5，之前一位美國同事來出差看到一輛還特意掏出手機拍照留戀，因為他是X5車主。現實中，iphone在國內依然火爆，X5也還是很多人的dream car。因為有很多看不見的特性(比如performance)在它們和抄襲者之間劃清了明確的界限，品質高下立現。當然，差別也不只是這麼提到的這些，還有其他，比如branding。

好吧，如果我們的產品連這些不言自明的要求也考慮到了，那麼是不是就會被認為品質很好呢? 不一定。

　　Quality scope #3： 設計符合使用者的需求

　　在scope #1中，我們提到好的品質的最起碼的條件就是實現了宣稱的功能。那麼引伸出另一個問題是，設計本身是合理的嗎?

　　如果我們把developer定位成實現所需要的功能的人，把QA定位成驗證這些功能是否正確實現了的人，那麼這一部門的品質我們就沒有辦法覆蓋到。因為如果是這樣的定位，大家就不會去想，這樣做合理嗎?是使用者想要的嗎?做出來使用者會喜歡嗎? 反正我們只要按著spec做出來就好了。

　　這樣的例子其實也有很多，比如

　　1. by design，我們只支援IE瀏覽器。但是我們發現很多使用者都在使用Firefox和Chrome。

　　2. 我們的郵件曆史尋找只支援按收件者，現實中有很多使用者也需要按寄件者來尋找

　　3. 如果使用者重裝系統的話，需要把曾經在老系統上配置的policy一條條重新設定，包括white list和black list。

　　4. 如果中途網路斷掉了，使用者前面輸進去的東西下次連網後要重新輸入。

　　類似的例子我們還可以舉出很多。這些問題有什麼共同點呢，那就是使用者會抱怨我們的系統品質不夠好，會給售後服務部門提一個case過來，提出他們的合理(從他們的角度確實是)要求。

　　如果我們的軟體測試只停留在驗證功能的角度，這些問題都不是問題，因為直接被我們排除在工作範圍以外。但是最終這些問題都會被使用者遇到，而且形成一種印象，那就是我們的產品品質不夠好，特別是當競爭者能夠做到的時候。這就會形成一個gap，我們自我裝載的時候覺得品質很好很穩定，但是使用者還是不滿意。

　　要解決這樣的問題，可能有兩個方面的要求

　　1. 測試人員(其實也包括開發人員)應該更多的從使用者的角度來考慮問題。也就是常說的customer insight，從這個角度我們不是完全被動的按著spec走，而是可以challenge它，為什麼做成這樣，至少要知道為什麼。

　　2. 測試人員要往開發流程的更前面走，而不只是等到產品做出來了之後去裝起來驗證。那樣太晚了，而且修改的成本比早期要高很多。測試人員一開始就應該參與到產品的設計中，並且從使用者的角度給出自己的意見。當然，這一部分也依賴於domain knowledge和個人的經驗。

　　以上兩個方面，對測試人員來講，是挑戰，因為要求更高了，也是機會，因為工作更有value了。

　　到目前為止，看起來我們的品質範圍已經比較完整了? not yet。

　　Quality scope #4： 處理異常情況的能力

　　說到這個問題，還是舉個例子吧。很多人可能對nokia手機的抗摔能力印象深刻，自己遇到的或者聽朋友說的。常見的情節是這樣的，一不小心從桌子上，或者從樓梯上把手機摔了下來，然後蓋子摔開了，甚至電池也掉出來了，這時候心裡拔涼的，但是抱著僥倖心理把它們重新裝到一起，按下開機鍵，everything is OK，然後很happy。這種故事的後續是很多人因此第二次，第三次稱為諾記的使用者。因為覺得他們的手機品質很好。

　　這個故事有趣的地方在於說明書上從來不會寫我們的手機從樓梯上摔下來不會有問題，廠家估計一般也不敢寫。從樓梯上把手機摔下來絕對是一個異常的情況，也不是產品針對的情境，嚴格來說摔了之後壞了也屬正常。但是反過來，如果這種異常的情況下，都沒有問題，就會讓人覺得品質很好。所以是一個品質加分的地方，也是branding build up的地方。比如你可以(以前?)不小心把水倒在Thinkpad的鍵盤上，也可以踢到macbook的電源線。

　　從軟體的角度，異常的情況也有很多，比如

　　1. 突然停電

　　2. 硬體故障

　　3. 作業系統故障

　　4. 網路連接意外中斷

　　5. 系統資源(記憶體，硬碟，網路連接埠等)耗盡

　　6. 使用者的誤操作

　　通常情況下，這些情況都不會發生，但是還是會發生(墨菲法則)的。如果只是一個PC上播放MP3的軟體，遇到上面的情況就出問題了，甚至不能恢複需要重裝，也許還是可以接受的，畢竟不是很重要的任務，而且也不常發生。但是如果是很重要的軟體系統，而且有著重要的資料，不能恢複就問題大了。

　　對於這一部分，我們都應該考慮到，不管是開發還是測試。在測試的過程中，我們也要盡量的去驗證。

其實品質還有很多的方面，比如。

　　Quality scope #5： 易用性

　　這是一個很重要的也常常被忽視的方面。很多時候我們開發產品的人會覺得自己的產品很好用，但是使用者不覺得。我想其中一個很重要的原因是我們自己對這個領域很熟悉，而且對產品的各個功能，甚至他們內在的聯絡很清楚，再者因為工作的原因我們已經用了幾十上百遍。這樣算來易用性當然不是問題。但是我們不能要求我們的使用者如此，因為使用者不會(很多產品也不應該)花很多的時間研究學習我們的產品，他們購買我們產品提供的功能，就是要更有效和高效的完成他的工作。如果使用者為了完成一件常見的工作，比如修改一項小的設定，就需要去修改很多的地方，而且沒有提示要告訴他修改對應的地方，那麼這就是我們產品的問題。

　　很多時候使用者錯用或者誤用我們產品的功能，除了使用者自身知識和經驗不足之外，我們也應該反思一下是不是我們的產品做得不好用，流程和介面設計得太讓人困惑。

　　易用性不只是產品的UI做得比較好看，更多的時候還包括產品的流程和介面的設計。這是一個很大的領域，這裡限於自己的自己的瞭解和篇幅就不詳述了。最基本的，我們可以把自己想象成對產品瞭解有限的初用者，很多問題就容易暴露出來了，或者還有一個辦法，找一個不太瞭解人的，給他一些任務，讓他去操作，然後去觀察，聽聽他的感受。

　　Quality scope #6： 可維護性

　　維護的目的有很多，比如產品升級，功能更新，打補丁等等。 對於一個正式而長期使用的系統而言，特別是伺服器軟體，這是很常見的工作。這些方面處理的好壞往往也非常容易影響到使用者對產品的判斷和印象。常見的問題包括

　　1. 產品升級不能將來的版本的資料導過來，或者資料出錯

　　2. 升級後不相容或者對硬體要求很高

　　3. 打補丁或者升級後遇到問題是否可以復原?

　　4. 使用者報過來問題，如果收集資訊定位問題

　　軟體品質其實是一個很複雜的東西，上面提出的其實也只是工作中常遇到的一些方面(即便如此，很多還是常被忽略)，比如使用者對產品品質的看法還會受到情感因素的影響，比如產品的UI，和客服人員的溝通過程，以及公司和產品的品牌等等。

　　從軟體測試的角度，針對品質的不同的方面，我們也有不同類型的測試活動來保證，比如design review，還有各種測試類型，functional，stability，performance，deployment，migration，usability，stress，compatibility 等等。

閱讀原文閱讀 681投訴

關於軟體品質的思考 - 什麼是品質？