一款产品必然有其系统需求或规格，在设计说明中定义清楚的不支持，不实现的功能或特性，有的时候也可能是测试设计中的盲区。
　　（举例：需求定义产品产品的一些属性为——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的对通表，一个个测试过去，打勾打叉，枯燥繁琐，但是事关重要。
　　本文主要描述了测试设计可能的一个盲区——规格明确不支持的功能/特性。但同时也明确了不要过度设计，否则是浪费成本和项目时间。
　　测试设计实际上是一个复杂的加权系数的模型，和产品、客户、使用方式、频率、缺陷修复成本、行业、公司很多的因素相关，切不可一概而论。