北京軟件公司的軟件缺陷測試條紋的用例和掩蓋錯誤總是會彈出–即使較激烈的測試不一定能把每一個小問題。有時微小的錯誤在開發過程中可以變成尴尬的，公共的bug。趕在發射前的測試将需要這些bug，測試動作的每個組合非常細緻（東西不實用）或淋上鋒利的每一行代碼，挑剔的眼光。這是較新的真實世界的例子：

 

Sophos的裸體安全博客解剖蘋果iMessages，陰謀理論家們瘋狂瞭(le)。如果你發送郵件，閱讀“我會成爲下一個奧(ào)巴馬”的一個額外的空間在句末将發送消息的“奧(ào)巴馬”失蹤。事實證明，錯誤可能會在代碼的一個很小的錯誤的結果。

 

我見過的較可信的解釋是，代碼提供的消息認爲，這将隻是放在一行，並(bìng)準備(bèi)爲目的的一一線泡沫。

 

但代碼實際上格式的消息指出，不完全放在一行，從(cóng)而使其與第二行的較後一個(gè)字。

 

總之，這個詞(cí)奧(ào)巴馬有；你隻是看不見。

 

你可以想象這可能發生：一個錯誤，是一個相對的所謂的由一個或fencepost錯誤，因爲一個栅欄，是X段長(zhǎng)確(què)實需要x + 1籬笆景結束。

 

這裏是這樣一個形象的例子，編(biān)程錯(cuò)誤：

 

有一個(gè)讨厭的差異比較(jiào)。

 

首先考慮(lǜ)這一行信息，如果它不超過(guò)一行的像素數量。

 

第二測(cè)試看起來很相似，但表達(dá)的其他方式：是檢查該消息不适合在一個線代替它。

 

但相反的“小於(yú)或等於(yú)”“大於(yú)”，不是“大於(yú)或等於(yú)”。

 

在我們的綜合實例，隻有一個消息，完全正確(què)相同的像素長(zhǎng)度爲線将被視爲不同的兩個代碼片段和觸發的bug；所有其他的消息會被正確(què)處理。

 

順便說一句，這就是爲什麽軟件測(cè)試是很難的一個(gè)原因。

 

在這種情況下，例如，沒有足夠的測試長度随機變(biàn)化的不同的信息很多；你也需要一個結構化的測試讓你産生並(bìng)在所有可能的像素長度測試消息。

 

閱(yuè)讀(dú)完整的文章Sophos > > >

 

這是一個小錯誤，測(cè)試不可能發現。我們說的不是一個特定的字符數量的觸發的bug，這是像素長(zhǎng)度所以找到的bug會被非常細緻的測(cè)試或完全随機的巧合的結果。

 

不要開始呼吸急促和恐慌，你的測試是不夠的。我強調這個故事提醒大家，質量並不意味著軟件是完美的，無缺陷的–不是質量保證的點。而QA提供一系列不同的用途，當測試和漏洞，確保你有人與實踐在地方，會幫你找到很多bug之前盡可能的釋放。同樣重要的是，解決許多這些漏洞可能在發射前。更多的錯誤總是會出現一次北京軟件公司的軟件進入用戶–手如果你知道和/或有固定的許多缺陷可以在發射前你有一個更好的位置來解決這些新來的人。