需求定義中的不支持——可能的測試盲區
一款產品必然有其系統需求或規格，在設計說明中定義清楚的不支持，不實現的功能或特性，有的時候也可能是測試設計中的盲區。
（舉例：需求定義產品產品的一些屬性爲——XX系統不支持Win7之前的系統，XX系統只支持IE內核瀏覽器，XX系統和YY系統的早期版本不兼容。）
實例：
某款平臺產品，從Version1開始，幾年下來已經迭代到Version4，期間接入了N多種終端產品，外設產品，數據庫，Web服務器。因爲兼容性太過龐大，產品分支拉的也密密麻麻，導致維護和測試都非常耗時。藉着技術重大更新的機會，平臺產品開發了Version5版本，對早期的兼容性經過詳細的討論和設計，約定好只支持幾個重大分支的終端，外設產品。
這個版本規劃喜大普奔，團隊內外都說以後就省時省力了。但很不幸在版本進行beta測試時，忽然出現了平臺崩潰的致命問題。
排查下來是一個明確不支持的早期版本設備，接入了平臺，導致了平臺的異常。從測試設計的角度，這就是疏漏之處。產品明確定義了不支持，並不意味着就可以在測試中不用考慮此類場景。按照邊界值的測試設計，這種明確不支持的項目，也可以理解爲N+1的邊界值。
接入“明確不支持”的設備，然後可以驗證很多項目：
1、兼容容錯性，雙方系統是否有異常/崩潰/重啓。
2、設計友好性：是否有人性化的提示——比如版本太老，請升級新版本。
3、設計嚴謹性：直接提示禁止接入。
從產品設計的角度，兼容性的保護沒有設計好，肯定是設計疏漏，但是測試沒有能夠及時設計場景驗證此問題，主要責任還是在測試設計方面。
這也是測試設計需要注意的環節。
規格書中明確明確的，XXX功能不支持，或者XXX版本不兼容，只支持XX系統，XX瀏覽器等等。這些並不代表測試可以不測試。這就是很明顯的健壯性和邊界值保護測試。
但是事物具有一體兩面性，不考慮是不對的，但是也不要陷入到過度設計的牛角尖裏面去。
還是上文的舉例——XX系統不支持Win7之前的系統，那麼在測試設計的時候，有沒有必要把XP、98、vista、2000都裝起來，進行兼容性測試？同理，比如Android系統下的App，明確不支持4之前的版本，那麼是不是也要把之前的系統都裝起來，進行兼容性測試？
從測試設計和投入產出的實際情況來說，前者（win7之前）幾乎是肯定不用測試，後者（Android4之前）可能不用測試，也可能用測試。
這就是此類測試設計的一個常規分類，產品的性質、客戶、覆蓋面等等，需要綜合考慮。按照測試設計從少到多來排序，如下：
一、操作系統兼容性。
可以就按照需求定義所支持的系統進行測試，不需要過多的考慮不支持的產品。
首先，既然產品敢這麼定義，就意味着產品本身就不是QQ、WPS這種，需要全版本兼容的覆蓋面非常廣的產品，而是有可能是特定用戶，特定環境，或者使用目標客戶精準的產品。所以就沒有太多的必要，過度測試。比如守望先鋒，你興致勃勃安裝完，發現卡的一塌糊塗，你也不會罵暴雪產品爛，只會怪自己沒看清楚軟件運行的系統要求，然後自己去買顯卡。
二、Web客戶端對瀏覽器的兼容性。
同理，產品既然設計如此，必然有其道理，如果用戶是全覆蓋類型，你設計產品說不支持chorme瀏覽器，可能會被同類產品直接淘汰。但是如果是給公司內部用的OA系統，ERP系統等，完全可以通過行政要求的方式搞定，只需要在某內核的瀏覽器下完美實現即可。
所以測試設計，也是輕量級的測試設計，找幾款其他內核的瀏覽器，大概的安裝使用一下，看是否會有提示“本產品支持XX瀏覽器”，是否會出現系統異常，導致瀏覽器崩潰，或者操作系統無響應，就可認爲達到設計目的。
三、App對手機操作系統的兼容性。
在手機操作系統上，可以明確不兼容，但是因爲載體的不可控性，這部分還是需要測試的。同樣，現在網上的模擬雲挺多，也不需要實體機刷Rom，投入和產出還是正向的。
四、自己產品之間的兼容性。
比如說某種行業產品，比如超市的掃碼計費系統，小區樓宇的報警系統等，從平臺、到終端，從軟件到設備，都是自己做的，那麼這種升級的兼容性，反而是產品設計和測試設計的重點。
新產品的迭代，可以明確不支持某種老產品/老版本，但是要給出友好的提示，或者明確的解決方案。
所以這種測試，往往就是XY的一張表，或者XYZ的對通表，一個個測試過去，打勾打叉，枯燥繁瑣，但是事關重要。
本文主要描述了測試設計可能的一個盲區——規格明確不支持的功能/特性。但同時也明確了不要過度設計，否則就是浪費成本和項目時間。
測試設計實際上是一個複雜的加權係數的模型，和產品、客戶、使用方式、頻率、缺陷修復成本、行業、公司很多的因素相關，切不可一概而論。