测试是用来做什么的？保证产品质量！

关于测试是用来做什么的，之前一直没有时间认真思考，后面慢慢感悟到了。测试不仅仅测试这么简单，如果你要帮助你的工作质量，那么你肯定会遇到很多困难而无法开展更好的工作，慢慢的你会从流程到细节上去分析。哪个流程没做好、哪个细节的缺失，会导致软件质量存在风险。而往往这些你可能比较难以改变，导致你很难保证软件的质量。测试不仅仅是测试，最终是为了保证质量，测试仅仅是保证质量的一部分。

image.png

第一，测试的主要职责是不是专职用来发现bug的？我觉得如果说是，我想笑。因为真的不是。测试人员的主要职责是保证产品质量的。发现bug，只是工作的一小部分，避免发生bug才是主要职责。如果发现bug是主要职责，那测试和开发就不要坐在一起了。开发一堆，测试一堆，大家相互之间互掐就好了，开发为了开发进度等一系列因素说，这不是一个bug；测试为了减少所谓的担责等一系列因素说，这是一个bug。那不打起来了！？

第二，总有漏掉的bug。这个是存在。但是，这里需要强调的是bug也是分等级的。如果等级严重度从P1~P4是从高到低，你漏了一个P4等级的，我觉得不必要提高嗓子吼得所有人都知道，只需要凑时间修复就好了。P1的话，开发和测试需要坐下来好好检讨分析了。

第三，对于问责。 第一反应是问责测试，其实这里我想说的是那他们如果用Agile的话，不会单独只问责测试，因为测试和开发共同属于同一个小组，我所知道是问责，是小组问责制。即：出了问题，是测试团队和开发团队组成的小组承担责任。而非测试单方面。起因是, 测试和开发是同一时间拿到需求，并在同一周期内完成和产品部门，业务分析部门的交互，并在最终达成一致之后进行的开发和测试行为。也就是说，开发和测试具有行动一致性和目的一致性，这样产品的最终模样才是想要的。而且，功能上线之前是需要在团队内部，包含对产品部和业务部进行演示的。另外提一点，开发需要做单元测试，测试需要提供测试用例以进行开发多角度避免问题。所以，问责，单一只问责测试，是没有道理的。而小组问责，我觉得是比较合理。

第四，对于大家都说开发做出了东西，已经产品了价值。这个，我真的无法认同。这里说这句话，让我感觉似乎，你拉了一泡屎，然后说，看我已经产生了价值。这个理论有点牵强。生产出来的产品是否具有价值，决定的因素在于它本身的可用性，功能性和市场接受度，用户满意度等，而非是它存在与否。对于引入bug的问题，为什么有的开发能够几乎不引入bug，而有的开发能够集成一个小功能，让你原有的很多功能失效？开发的价值，在于你是否是一个优秀的开发，作为大部分都在遵循OOP开发原则的开发人员来说，若是你也能遵循，那引入的bug我相信也会降低。

第五，有人说：“测试总是依附于开发而存在，而且总是被质疑存在的价值。” 是不是真的没有开发，就不需要测试？我的答案是，没有产品就没有开发和测试。开发和测试都是产品的依附。测试不是开发的依附。测试和开发的目的一致性体现在做出高质量，高可靠性的产品上。若是测试不存在了，开发必然会被套上测试的马竿。是软件的发展造成了职务的细分，而非这些需要承担的任务原来不存在。莫要让你代码至上的思想，蒙蔽了你智慧的双眼。

image.png

感悟：现在发现：1.如果没有流程会造成质量风险，比如说测试要测试的内容从哪里来，不是测试自己拍脑袋想出来，这种就是没有相关说明书的情况，这个很容易造成测试漏测、测试用例存在误差。2.软件的功能点与测试用例的评审是必须的，这样至少开发、测试、产品对于软件本身的功能能够达成一致，保证功能点不会漏测。3.如果条件2达成共识，那么剩下细节的部分，比如一个特殊的功能点，这个点大家都考虑到了，然而里面细微的没考虑到，导致功能点到了，细微处测试用例没有包含到。所以条件1相关的设计文档，比如详细设计，这个特殊点会在详细设计里面体现（当然设计人员是有考虑到的），这样就能避免这个问题。否则还是可能出现用例覆盖不全。
总结：产品给出设计文档、开发根据设计文档开发、测试根据设计文档设计用例。设计文档可能存在忽略点、开发可能产生bug、测试可能漏测。关键的是设计文档缺失的内容，开发与测试必定缺失这块内容的相关产出。
若相关设计说明文档的缺失，会提高质量的风险（你要造三轮车，开发、测试以为要造四轮车，轮子几颗没说清楚）
一般而言缺失的不会是核心功能部分，所以开发、测试、产品对功能点达成一致能够保证软件的大部分功能质量。所以从产品-开发、测试，这个环节需要传递的内容要明确，最后测试给出保证质量的用例，大家都无补充，那么就可以认为，可能出现的风险是允许的范围之内的。

image.png

个人认为：产品的设计文档是给开发、测试用的；开发做出来的东西，呈现给产品与测试，测试写出的用例同样需要产品与测试过一遍；这是整体为了保证质量，降低风险而应该共同努力的一个方向。每个环节都很重要，但是逆推的话，开发可以从用例中查找自己是否忽略设计逻辑，产品同样可以从用例中思考设计上的不足。所以测试的产出是用例，就如同开发做出功能是一样的。用例的执行测试来做，不意味着用例其他人就不需要看了。正如软件开发出来的bug一样、类似产品设计出不合理的地方，用例同样有类似bug的不足，所以为了保证质量，用例是必须评审的。
评审后的用例就是测试执行的标准，测试根据测试执行即可，然后分轻重。这样才能保证出现风险的概率与风险出现后造成的影响。
居然要用测试，那么就应该去接受，测试人员对于风险思考后的一些建议，如果仅仅是找一个出问题来背锅的话，其实完全不用多一个测试岗位，还增加了成本。