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

 

Sophos的裸體安全博客解剖蘋果iMessages，陰謀理論家們瘋狂了。如果你發(fā)送郵件，閱讀“我會(huì)成為下一個(gè)奧巴馬”的一個(gè)額外的空間在句末將發(fā)送消息的“奧巴馬”失蹤。事實(shí)證明，錯(cuò)誤可能會(huì)在代碼的一個(gè)很小的錯(cuò)誤的結(jié)果。

 

我見過的較可信的解釋是，代碼提供的消息認(rèn)為，這將只是放在一行，并準(zhǔn)備為目的的一一線泡沫。

 

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

 

總之，這個(gè)詞奧巴馬有；你只是看不見。

 

你可以想象這可能發(fā)生：一個(gè)錯(cuò)誤，是一個(gè)相對(duì)的所謂的由一個(gè)或fencepost錯(cuò)誤，因?yàn)橐粋€(gè)柵欄，是X段長確實(shí)需要x + 1籬笆景結(jié)束。

 

這里是這樣一個(gè)形象的例子，編程錯(cuò)誤：

 

有一個(gè)討厭的差異比較。

 

首先考慮這一行信息，如果它不超過一行的像素?cái)?shù)量。

 

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

 

但相反的“小于或等于”“大于”，不是“大于或等于”。

 

在我們的綜合實(shí)例，只有一個(gè)消息，完全正確相同的像素長度為線將被視為不同的兩個(gè)代碼片段和觸發(fā)的bug；所有其他的消息會(huì)被正確處理。

 

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

 

在這種情況下，例如，沒有足夠的測試長度隨機(jī)變化的不同的信息很多；你也需要一個(gè)結(jié)構(gòu)化的測試讓你產(chǎn)生并在所有可能的像素長度測試消息。

 

閱讀完整的文章Sophos > > >

 

這是一個(gè)小錯(cuò)誤，測試不可能發(fā)現(xiàn)。我們說的不是一個(gè)特定的字符數(shù)量的觸發(fā)的bug，這是像素長度所以找到的bug會(huì)被非常細(xì)致的測試或完全隨機(jī)的巧合的結(jié)果。

 

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