James A. Whittaker提出的全局探索性测试方法对于探索性测试具有十分重要的指导意义，想必研究和使用探索性测试的人员都对此十分了解。本篇文章重点是结合全局探索性测试方法的测试建议和具体实践案例。
一、 商业区测试
- 指南针测试法
“指南针”作用在于为航行者辨别方向。对于测试人员来说，使用指南针测试法可以快速地找到新待测项目的测试切入点。这些“指南针”可以包括：使用手册、接口文档、帮助文档、用户文档、开发文档等等。参考文档进行测试，一则可以检测文档描述的准确性和易于理解性；二则可以检测产品功能是否与文档描述一致。
那么，在实践工作中，如何具体使用指南针测试法呢？在此，以接口文档和使用手册为例。
接口文档参照测试（以web应用为例）
测试接口本身定义的正确性与合理性：URL设计是否符合语义学标准（如是否有条理）；响应码的设计是否符合标准（如RESTful接口规范）；
测试接口功能的正确性：测试不同请求方式结果的可变性（如GET请求幂等，POST请求不幂等）；测试请求返回的content是否符合上层调用者需求（如上层调用接口要求返回a、b、c，而实际接口设计只返回a、b）；
测试接口的容错性：测试异常请求是否正确处理或拦截（如输入异常字符或数据，接口正确拦截并返回可读的错误信息）；
测试接口的安全性：尤其是对于数据库等接口，安全性尤为重要，测试高危数据灌入是否影响内部数据的安全；
测试接口的性能：尤其对于有高并发或大数据请求的接口，性能要求会更加重要和苛刻（如对某个上传文档接口，测试上传10GB大小文档）；
测试接口的兼容性：版本升级后原接口请求是否兼容（如v1版本接口必填参数为a、b，v2版本接口必填参数为a、b、c，只传入a、b时，对参数c是否有默认处理，接口请求和返回是否正常）；
使用手册参照测试
测试使用手册完整性：产品模块和功能是否描述完整（如手册中是否缺少对某个功能模块的使用说明）；
测试使用手册描述与产品功能的一致性：手册描述使用方法是否与现有产品一致，尤其对于升级产品，考察手册是否也相应更新（如手册中某个功能模块的使用方法是否与现在的产品一致）；
测试手册描述的易于理解性：使用手册描述应该简单、易懂、图文并举，重要的操作最好附图说明，文字描述应无歧义； - 卖点测试法
卖点测试法的主要测试对象是产品的核心功能、吸引客户的功能。使用卖点测试法可以从：参考需求文档测试；参考开发方案测试；参考销售人员/用户操作测试等等。
参考需求文档测试
需求文档是研发/测试人员接触用户需求的第一手资料。需求文档的正确评估直接影响后期开发和测试的正确性。在此可能有人会提出疑问，但从测试人员角度出发，测试人员的技术性可能限制了对需求文档的技术是线性审核，因此我们不限于仅是测试人员参加该项测试。
测试人员参考需求文档测试，首先应该评估需求文档本身的正确性和逻辑性等，其次才应该是参考正确的需求文档进行验收测试。
a） 需求文档本身评估包括以下几个方面：
评估需求文档可实现性： 主要是技术上的可实现性（如评估是否可以实现五彩斑斓的黑）；
评估需求文档的可测试性：需求文档中的先验条件可以达到；需求文档中有明确的结果要求（如要求实现能够支持10GB大小文件的上传接口）；
评估需求文档逻辑正确性：需求文档中描述的逻辑不能自相矛盾（如不能要求时间范围为当日的14点到13点）；
评估需求文档的正交性：各个需求间相互独立，不能交叉或包含（如不能需求A中包含实现某个接口I1的要求，而需求B也在此提出包含实现某个接口I1的要求）；
评估需求文档的一致性：前后需求涉及的共同点应该保持一致（如不能需求A要求实现某个接口I1，而同时间段的需求B要求不能实现某个接口I1）；
b） 参考需求文档的验收测试：
主要是针对需求文档中的明确测试条件、操作步骤和可实现结果进行比对测试（如需求文档要求支持100百万TPS的某个接口转发量，参考需求文档要求测试结果是否达到）；
参考开发方案测试
开发方案是需求文档进入技术实现的第一阶段，是产品实现的重要环节。开发方案的优良与最终产品的质量高低息息相关。同样的，测试人员参考开发方案测试也包含两部分：开发方案本身评估和参考开发方案进行验收测试。
a） 开发方案本身评估
主要是：可实现性评估（如可以选择何种开发语言实现，java？c？go?等等）；技术方案性能评估（如是否存在过度消耗资源等）；需求一致性评估（如是否与需求文档要求一致）；逻辑正确性评估（如是否存在明显的逻辑错误）等；
b） 参考开发方案的验收测试
了解开发方案细节更有助于测试人员进行验收测试。可以包括：开发涉及组件测试（如针对使用的中间件kafka进行测试）；开发脚本测试（如针对安装/部署脚本测试）；开发程序逻辑性测试（如测试程序是否有进入死循环的逻辑）；开发程序局部容错性测试（如针对局部代码块模拟异常数据输入或异常流程测试）等等；
参考销售人员/用户操作测试
销售人员能够直接接触用户，向用户展示产品卖点功能吸引用户。观察销售人员操作更能帮助测试人员识别卖点功能，便于重点测试。此外，由于大多测试属于α测试，测试人员较少能够直接了解测试的使用习惯。因此，若是有机会获得销售人员或用户的操作数据，可以存储该数据用于回归测试。例如：采集用户常用的sql查询语句，用于版本更新的回归测试。 - 地标测试法
“地标”可以理解会测试人员测试时关注的功能节点。地标测试法包括地标间跳跃测试、地标增删测试、地标顺序变换测试。
地标间跳跃测试
例如：测试人员测试某个购物软件的购物付款功能，可以将“购物车”和“商品页面”当作两个不同的途径地标，而“付款”作为最终地标，可以选择从“购物车”—>“付款”、“商品页面”—>“付款“和”商品页面“—>”购物车“不同的地标间跳跃测试。
地标增删测试
例如：删除“购物车“地标，只关注“商品页面”—>“付款“的测试；
地标顺序变换测试
例如：测试”商品页面“—>”购物车“后，变换测试”购物车“—>“商品页面”地标跳跃测试。 - 极限测试法
极限测试法是经常用到的一种测试方法，如功能测试中常用的边界测试法。任何测试项都可以拓展极限测试，只要有明确的测试条件限制。此外，从运行环境来看，可以有：极限资源测试，平台越界测试，组件版本越界测试；从运行状态来看，可以有：极限时间运行测试；从产品本身配置来看，可以有：极限配置测试，极限运算测试。选取极限资源运行测试、极限时间运行测试、极限配置测试和极限运算测试为例。
极限资源测试
极限资源测试可以包括：极限内存资源测试、极限磁盘资源测试、极限cpu资源测试等。观察在极限资源条件下软件的安装和运行情况（如软件在内存严重不足时是否会释放自身程序不需要的缓存，软件是否能够低资源正常运行）；
极限时间运行测试
极限时间运行测试主要测试软件在很长一段时间内的运行稳定性（如：观察软件持续三个月，期间是否有报错、功能是否正常等）。在这段时间内我们可以通过观察日志错误、资源消耗曲线、功能持续可用性等方面判定软件的稳定性。
极限配置测试
软件自身有许多配置，诸如运行参数配置、启动项配置等等。因此，可以针对配置要求的范围进行极限测试，如：某项配置要求时间范围为01:00—05:00，可以测试00:30—00:59是否生效。
极限运算测试
所有软件皆是运行在硬件之上。极限运算测试包括软件极限运算测试和硬件极限运算测试。如：某软件要求某运算结果限制在10000内，可以构造运算结果>10000的运算输入；或某软件无运算结果限制，但硬件是32位处理器，构造运算结果大于2^32的运算输入。 - 快递测试法
快递测试法可以从：跟踪数据流转、跟踪状态变化、修改“地址“等方向出发。以跟踪数据流转和状态变化为例：
跟踪数据流转：跟踪数据从输入到输出过程中每次数据变化，观察和验证其类型转换、数量增减等是否正确（如某个int数据转换string类型，转换结果是否成功）；
跟踪状态变化：跟踪功能对象的状态切换是否正确（如某个数据进入功能模块后是否成功引起了该功能的状态切换，通俗比喻如打开开关电灯发亮）； - 深夜测试法
由于测试人员工作时间性质，大部分测试都在白天进行，而鲜于关注软件在深夜的工作情况。而往往在深夜，会有许多定时任务开启。因此，深夜测试法可以从这些方向出发进行测试：测试软件在其他任务运行时的运行状况，测试软件的定时任务是否成功执行等。
测试软件在其他软件或应用运行时的运行状况：测试其他软件或应用运行时，被测软件是否受影响（如杀毒软件工作时，某破解版被测软件是否能正常工作）；
测试软件的定时任务是否成功执行：例如：测试软件的各项维护任务（将数据归档，备份文件等等）是否定时开启； - 遍历测试法
遍历测试法可以分为：选定目标，遍历所有路径和遍历所有中间目标等方法。
遍历所有路径：俗话说“条条大路通罗马“，选定目标，遍历所有可以到达目标的路径（如，遍历所有从商品出发到达付款的路径）；
遍历所有中间目标：选择最短的一条路径，遍历所有该路径上的中间目标，比如：遍历所有界面菜单上的空间。
由于篇幅有限，本文暂时讲述了全局测试法中的商业区测试类型的具体测试方法与实践指导。至于其他测试类型方法，静待后期分解。
网友评论