EX8：DLL被覆盖的问题。系统先装了产品的的编解码插件，然后又装了其他的播放器（暴风影音、千千静听都出现过此问题），同名编解码插件被覆盖，解码失败。
　　此类的问题，排查过程可能比较纠结，但是排查清楚后，是否要写条测试用例，以后每次都纳入执行呢：“首先安装我司产品，然后安装暴风影音，进行编解码，看是否正常。预期结果：视音频正常。”这种用例是否可执行？
　　看解决问题的方案是什么：
　　8.1、如果解决方案是销售规避——服务器是独立安装的，所装软件都是有标准版本，不允许安装其他软件，那么这个问题根本不需要解决。只需要卸载非允许软件，重新安装一次即可。
　　8.2如果解决方案是统一把dll的路径由system目录，修改到指定的目录，规避dll被覆盖的问题。那么这条case需要执行一段时间，并且要明确检查，setup之后，查看XX路径下的XX文件，是否更新成功这条检查项。
　　8.3如果解决方案没有统一指定，每个软件团队都是自己指定目录，且dll的特性不一样，有多个版本在同时使用，那么必然会存在自己公司多款软件调用dll冲突的现象，或者毫不客气的说，部分人员连dll搜索路径“当前目录->system目录->windows目录->环境变量Path指定的目录”都没有考虑。那么这事儿如果要暴露，要找几个人成立专项测试，甚至要周期性进行检查了——但是一旦恶劣到这种情况，是各软件产品没有统一的规则，大家关起门来自己按照自己的想法设定，并单纯的认为客户只会安装一款 产品。如果是我，肯定罢工——系统部门坐下来定个规则，大家一起修改一下，可以一劳永逸，分分钟的事儿。结果把问题甩给后端团队，找几个人费工费时，长期的去折腾。这是不拿别人当人看，也没有考虑项目整体成本，或者干脆是没有尽到责任，凭什么让测试人员来背锅？
　　一个看起来相同的现象，因为产生原因的不同，可能采用的行动是截然不同的。如果你不在项目组里面，不对里面的原因了如指掌。只是单纯的督促某一个人员，这事儿是不是你的问题？这反而容易激发逆反情绪，对整体推进产品，会产生非常大的负能量。
　　六、测试用例的可执行性。
　　上文已经举了一个例子。凡是随意的写出穷率测试的测试用例，都是不负责任的。
　　A：我写了遍历所有的接口，所有的格式，清清楚楚，你怎么没有测到？
　　B：你算过你这一行实际要测试多少时间么？你写一句话，我要折腾一个礼拜。
　　出了问题，你说你想到了，是执行人员偷懒，但是这么紧张的测试时间，不可能给一个礼拜的时间去测试这么一个基本功能。测试优先级、测试等价类划分，甚至根据客户使用概率做带风险的暂不测试决定，不是测试设计该做的事儿么？
　　形成一张图表来阐述观点。

　　这张表的目的并不是死记硬背，而是当你思考“这个问题的产生，我们要不要写条case，然后一直去执行它？”的时候，能够根据自己产品的实际特点，做出正确的分析判断可以。
　　所以回归一开始的问题，如果是按照冷冰冰的规范约定，所有的问题都必须纳入到缺陷进行管理。在面对复杂多变的种种现实情况时，落地的样式可能会多种多样（不需要、选择执行、长期例行覆盖、短期覆盖、专项重点解决）。
　　第三方部门的种种检查方法，可能并不能套用到一条条的用现有用例中，而趋利避害的本能，向不了解业务的人，讲解清楚的缘由和解决方案是非常麻烦的事情。所以往往实际的产品验证方，与其试图无谓的解释清楚一二三四，还不如干脆做表面文章，写几条看上去通俗易懂的测试用例，大家反而会过的舒服一些。
　　按照驱动力3.0的概念，胡萝卜大棒会扼杀别人的积极性和创造力，所以通过智力定位并且写出足够牛B的测试用例这种高大上的行为，通过标准化、检查化的方式，往往会被变成写水文的应付行为——这不是本文的重点，稍微点到为止。
　　回归测试用例更新、优化本身。
　　除了由缺陷提炼出测试用例进行反向增补外，测试用例的基准库，也要定时评审修改更新的。
　　这是测试用例中的杀虫剂悖论（pesticide paradox）——对软件进行越多的测试，那么该软件对软件测试人员的测试越具有免疫力。或者字面理解，如果地里长期只打一种农药，那么虫子（bug）会产生抗药性，导致效果越来越差，后杀不死虫子。或者换个维度来描述：测试用例是一种数据量化指标，你想考核什么，长此以往必然会得到这种量化结果，但是对事情实际的提升，可能帮助不大。
　　可能一些测试用例在设计时是针对当时产品的一些薄弱环节。但是几个项目测试完成，甚至几年之后，这些测试用例的有效性趋于为0。
　　1、可能是代码逻辑修复，此类问题再也不会出现；
　　2、可能是软硬件变更，原来的测试方案需要调整；
　　3、可能是功能点优先级变化导致的测试用例优先级调整等等。
　　举个例子，曾经在测试用例中，要求把版本放在发布服务器之后，需要重新下载后，进行一次安装测试，确认各模块的版本号信息。这在当时的条件下，是必然的一个测试步骤。原因一、曾经出现过用不同的解压软件和断点续传下载工具，导致文件字节数大小不一致的问题；二、原来版本是一个文件夹，其中有各种ini、exe、bin、setup文件，很容易出现测试版本和发布版本不一致的现象；所以重新进行安装后检查版本，是非常必要的行为。
　　但是过了几年之后，解压缩软件越来越多，兼容性越来越好。覆盖解压软件越来越不可能，还不如指定解压软件及版本号更现实；发布文件本身也不是一个文件夹，而是一个或几个Zip包，也避免了人工复制粘贴多个文件，人为混乱的风险；三、数据校验也做的比之前好多了，没必要采用土鳖的方法手动核实。
　　所以，这条用例，毫无疑问可以删除掉，毕竟下载、替换、看版本号，怎么说也要两、三个小时才能搞的定。
　　经年不变的测试用例，从工作性价比的角度来说，这是无效的工作内容。好像站在楼梯口的服务员，仅仅是因为传统而站在那里，而不知道一开始仅仅是为了提醒大家楼梯的油漆未干。
　　从测试职责和风险来讲，这是推卸管理者的职责。无论怎么说，常年不变的测试用例，意味着多年没有进步的测试团队，这是毋庸置疑的。