软件测试中，是否存在一种故障(fault)，通过任何测试都无法检测
常在河边走，哪有不湿鞋的，不管是哪款产品，都是存在问题的。测试不可能覆盖所有的问题，所以测试并不是一锤子买卖，而是一个持续的活动。当然也针对项目的复杂程度而言，特别简单的就不在这个范围内了。测试的责任是保障产品的质量，什么是质量，这个不同的人有不同的理解。说说我的理解，简单讲就是让用户用的舒心，让客户看着放心。能达到这个程度，及时存在一些小瑕疵，也是无伤大雅的。那么这就要求，测试需要能够识别出优先级以及风险，对于客户/用户特别关注的地方，比如说客户/用户经常使用的场景下的功能，这个是要重点保证的，客户新增的需求，这个不用说了，肯定是要保证的，以及一些常见的异常场景，毕竟用户各式各样，啥操作都可能有。在这些重要的部分都保证的前提下，即使漏测了，那么问题严重程度应该也不是很大。其实上述主要的，还是重点分析软件的使用场景，用户的使用习惯，虽然有些场景归属于异常操作，但是这些也有可能属于用户的使用习惯，所以针对这类场景的测试，还是需要多关照的。以上都需要测试活动尽可能的前移，而不是等到开发把东西做出来，测试一测就完事了。漏测不可怕，可怕的是同一个问题反复出现而不改进，所以及时总结，进行闭环，防止问题重犯是特别中的特别重要。有点跑题，测试发现不了的问题，肯定是存在的，只要我们把风险降到最低，那么问题就不大。一点拙见，欢迎讨论
■网友
我觉得这个问题要分几方面说。 首先，测试的目的是什么？测试是为了检查，产品的设计开发，是否满足了产品原有的需求。 如果产品的测试条例是按照需求一条条设计出来的，那么，至少可以说，产品提出的需求都是可以测试的。 所以说产品中的故障定义，应该是产品不符合设计需求的项。只要符合产品提出的需求，并得到用户的认可，即使坏了，也只能说，产品的需求可以要求的更严一些。 题主估计想说的是，是不是有些我们想测试的项，当前办不到。 这个办不到，大致有这几种情况：1、 这种故障提的不合理，由应用需求导致。比如，一个判定，判定结果是大于3为故障。实际上当结果大于2.5就故障了，软件当然判不出来故障；所以，这种故障，需要应用需求仔细衡量，这个阈值怎么设计最符合实际；2、 测试手段达不到。例如有一段硬件自检功能代码。这段代码需要硬件有数据读取输入，但是，这种操作是计算机指令完成的，软件不能对其打断测试。但是，这个时候我们可以对其起始态进行不同逻辑测试，通过在不同情况下的分析，得到测试结果；3、 当前技术存在瓶颈。例如，当前的软件设计，满足不了实际应用的需求，但是，这很有可能是硬件速度不够，或者数据输入不够，或者计算机计算不过来。这种软件，从逻辑上看，是没有问题的，但是就是会运行不正确，这个时候，实际上只要改变系统的硬件性能，或者改变算法，就可以重新提需求进行测试；4、 资源耗不起。原则上，我们想干一件事情，是肯定能做到的。但是，是否值得投入这个资源，就是问题了。例如，一段代码，需要穷举法，得1万年才能枚举遍历完实例。其实他是可以测试的，只是，需要的时间我们是接受不了的。有个著名的沥青是否为液体实验，题主可以看一下，说的就是这个意思。说了这么多，回到楼主的问题，故障应该有其定义，以是否满足需求为标准，从而制定测试方法，这样，我们认为故障都是可测的。
■网友
理论上，是不存在的。 问题都可发现，只是发现的成本，以及场景 。
推荐阅读
- 广东警方曝光38款存在超范围收集用户信息违规行为App
- 大学再有三个月就结束了，没学到知识，参加一个软件测试培训机构好吗
- 傻子当国有银行行长都能赚钱这句话是否是对的
- 网通社|喜欢蔚来的越来越多了 连续四个月交付创新高 你是否愿意放弃特斯拉选择它？
- 豆瓣为啥受到同志社群的欢迎
- |PHEV车款没比较环保，新能源是否存在谎言呢？
- 运营商收取的流量费用价格是否合理
- 游戏公司一般咋识别游戏脚本
- 知乎上关于人生经验的介绍是否可能对青少年造成潜在危害
- 是否该停止密码掩饰了