SHARE8：黑盒测试三剑客

今日分享黑盒测试三剑客。

因为从事的工作中一直存在黑盒测试，但是针对黑盒测试，很多人没有一个清晰的测试思路，今天结合自己学到的一些内容，做一个简单的分享。

黑盒测试三剑客，分别是BUG预防、测试框架、探索性测试。以下来分析这个测试三剑客。

什么是BUG预防？从哪些方面可进行BUG预防测试？

• 测试用例
• 测试环境
• 流程管理
• BUG原因分析

测试用例：是测试的基础，上期文章中针对测试用例的设计有写过，可参考：SHARE7:如何设计测试用例

测试环境：主要是研发的环境要和测试的环境一致，这样在测试和复现问题时，保证不会因为环境差异导致问题复现不到。另一方面是测试环境要和终端客户的保持一致，模拟终端客户的使用场景，最大的可能的还原真实，甚至比设计理论还要严格。

流程管理：主要从转测试的入口条件审核，需要研发提供的转测试资料，例如自测报告，BUG解决问题表单，测试用例测试情况。必要的话开会，与相关人员碰头，当面交流清楚，这样操作会给研发一定的压力，让他们认真的对待自己的版本，不会瞎忽悠，可以在大家面前过一些测试报告，如果没人评审，不认真的研发大概率会不自测。另一点就是测试内部定期对BUG问题进行回溯，让测试出来的问题设计成测试用例。

BUG原因分析：当研发解决完问题走单给你，可以对研发提一些要求，比如在每个解决的问题单后面附上，问题出现原因XXXX，解决措施XXXXX，测试需要关注点XXXX，这样一定程度上较少沟通的成本，也能让测试清楚的知道问题出现的背景。如果有不懂的，可以请求研发解释一下，这样操作对BUG的认识就会比较深刻，同时用测试的思维，举一反三，可能发现一些设计上的缺陷；在了解了问题的原因后，如果没有测试用例，可进行一个用例的补充，设计逻辑测试思路，下次就能更快的发现问题。最后，测试要学习必要的软硬件知识，不能总是问一些小白的问题，有防止研发的忽悠，知其然并知其所以然。

测试框架

测试框架，就是测试对研发提的一些功能测试要求，包含功能测试点，测试方法及测试用例。测试设计测试框架，测试规范，以此丰富研发的设计规范，有时候研发的思路不会像测试那么发散，他们只是按照需求进行设计，在某个功能点的细节上，不会设计太复杂，但是测试思路就很发散，拿到手很容易将软件搞死，这就是两者的差异，所以对开发提供一些测试框架，帮助他们查漏补缺，弥补需求上的一些不足，对整个项目的进展其实是很有帮助的。

探索性测试

两个前提

1. 测试之前一定会有一个全局的方针战略，即整体的测试计划，它可以避免走错大方向，该测的部分没有覆盖到，计划之外的部分却投入了大量时间。

2. 测试一旦开始，没有固定的思路，测试人员不受任何先入为主的条条框框约束，根据测试途中获取的信息，指导各自走不同的路径，最终目的就是发现潜藏的缺陷。

以下论点取自James A. Whittaker的探索式软件测试一书，非常有趣的一本书，然后针对实际的工作需要，截取一些适用的方法：

指南测试法：城市的题图通常都会标注一些热门的旅游景点，测试这些热门的区域是非常重要的。不管在任何一次发布的过程中，核心功能是肯定要覆盖到的。指南测试要求测试人员严格按照用户手册的建议执行操作，有可能是手册描述不到位或者核心功能并不像宣传的那样好。

卖点测试法：此方法是鼓励测试人员观看销售给客户演示的Demo，理解销售的角度哪些功能对客户来说是最大的卖点，他们未必就是核心功能，但值得测试人员把它们当核心功能来对待。同时，也许刁钻的客户会提出各种质疑，这些质疑和稀奇古怪的问题也可以纳入测试人员的设计中。

地标测试法：在旅游的时候，如果我们设计了要到访的地方，通常会在地图上插上旗子，这就是地标。但是没有人规定我们应该按照何种顺序去到访这些地标。不同的测试人员可能会选择不同的顺序，有经验的测试人员会基于对软件产品架构和技术层面的理解，采取一些古怪的路径但更可能发现缺陷。

极限测试法：向软件提出难以回答的问题，比如最大可以发挥到什么程度，承受多少用户，承载多少数据。那个特性或功能会把软件逼到极限运作，哪些输入和数据会消耗软件最多的计算能力？哪些输入可能绕过它的错误检测？

快递测试法：快递运送的货物，就好比软件里的数据，结果不同的地点转接，拆包装包最终到底目的地。所以快递测试专注的是数据，跟随它们走遍整个软件。

深夜测试法：城市灯火阑珊会在午夜过后逐渐安静下来，商场店铺纷纷打烊。但是软件不应该停止工作，软件测试人员有时应该刻意的关注在冷门时间段软件所做的附属工作，比如数据备份归档、维护监控任务的运行等等。

博物馆测试法：这是针对软件的遗留代码，保留了些许年代的一些功能，找出它们来验证是否有出现失效。当初开发它们的时候，甚至可能缺乏文档，但这并不意味着它们应该被忽略。

深巷测试法：在每个城市，都有些地方并不吸引游客意味着不吸引人群，但作为测试人员来说，反而是这种最不可能被用到或者最不吸引用户的特性，容易潜藏着难以发现的Bug。

通宵测试法：当它面临持续不断的调用、输入、重读重写之类的操作，如果运行时间足够长，就很可能会出问题，内存会需要回收、数据需要清空，永远不要关闭它，保持不间断的运行。（更多的时候会采用自动化或者机器人思想）

长路径测试法：把那个在应用程序埋藏最深的界面当做测试目标（离起始点最远的那个界面），观察经过的每一个界面

超模测试法：针对UI的表面测试，衡量软件的展现能力，像T型台的超模那样，不去关注她们幕后的辛酸痛苦劳累，跳出产品专家或测试的头衔，以普通观众的角度，去关注那些能看到的界面展现，元素是否被正确绘制、是否难看、颜色风格是否一致、界面的切换变化是否表意清晰？

取消测试法：此方法的思想是启动了立即停止，特别是一些运行流程比较耗时的功能如备份还原或者搜索，在启动之后，立即取消。发散一点还可以变成，启动一个耗时操作，不停止立即启动另外一个耗时操作，以此来检测应用程序的自我清除能力。

懒汉测试法：选择尽可能少的输入，能不输入尽量不输入，能不修改尽量不修改，观察应用程序是否能响应得出正确结果。

反叛测试法：反叛思想要求输入最不可能的数据，或者已知的而已输入，测试人员可以采用逆向思维、明知一些数据违反规则，却偏偏要采用这样的数据，或者不按照正确的顺序来输入。

强迫症测试法：测试人员强迫软件一边又一边接受同样的数据，反复执行同样的操作，最重要的特点就是重复。此种思维方式，常常打破了开发人员设计代码的思路，他们预想着你会按步骤操作，却不曾考虑过你反复的执行第一步应该如何处理。

以上就是今天的全部分享内容！