【小白讲白盒】初篇：测试范围评估

【小白讲白盒】初篇：测试范围评估

简介：小白讲白盒 — 代码变更了，我该测什么？

孙子兵法云：谋定而后动，知止而有得。拿到提测任务后，不要着急动手，首要做好测试范围评估。准确的范围可以帮助我们摆脱忙而无获的小白困境，进而事半功倍。

正文：
一次完整的白盒测试流程一般分为如下几步：开发提测代码变更->测试check代码变更->评估测试范围->设计测试方法和测试点->准备测试数据和环境->执行测试->提交bug->bug验证->功能回归上线。
如何根据代码变更来评估测试范围，是小白测试员遇到的第一道坎。what should we do?
第一步，查看代码变更的情况，判断代码变更的目的，做初步代码走查。
查看代码变更需要借助版本控制工具，具体因公司而异。本文以svn举例。通过showlog，可以清楚看到每一次开发提交代码的日志信息，包括变更概述，变更文件，提交人，日期等。

点击变更文件，可以在diff视图中看到新老版本的不同之处，对比以行为单位。
根据每行diff，通过代码走读方式，初步判断变更目的，并检查变更的合理性，不要引入新的代码问题。
第二步，与开发确认变更的目的，沟通是否有建议的测试范围。
对代码变更初步了解之后，需要跟开发沟通确认。一方面了解变更的原因，初步判断是否实现了具体需求。另一方面要获取开发建议的测试范围。前者需要用到代码走查，方法已经讲过，不再累述。后者需要掌握一定的沟通技巧，充分交流可能的影响范围，但不能完全依赖于开发建议。
第三步，根据变更的类型，分析变更影响，确认测试范围。
概括起来，变更的类型可以做如下划分：新增函数，删除函数，修改原有函数，修改数据来源。
《1》新增函数
a. 函数本身逻辑是否符合需求
b.调用该函数的模块有哪些，调用逻辑是否符合需求（参数，分支，时机）
c.调用该函数的模块涉及到哪些功能，确认回归功能list
《2》删除函数
a.删除是否符合需求
b.调用该函数的其他模块是否做出相应改动，有无遗留影响
c.相应功能是否有替代函数，对比实现方式，判断改动的合理性
《3》修改原有函数
a.如果是内部逻辑变更，审查是否符合需求，如果已有单元测试覆盖，最好回归一遍测试用例
b.如果是函数参数变更（个数，类型），检查调用该函数的代码是否同步修改，如果涉及到引用，需要关注调用的逻辑里，有无对引用的数据操作。
c.如果是返回类型修改，检查调用该函数的代码，是否有处理返回值，处理代码是否同步修改
d.如果是修改对外部函数的调用，检查传参合理性，以及对应外部函数是否变动。
《4》修改数据来源
a.如果是公用数据，需要检查其他操作该数据的函数是否受到影响
b.需要确认数据修改生效