【读书活动感悟】—等价边界读书组—《软件测试的艺术》第六章 更高级别的测试
这章的内容是更高级别的测试，也可以理解为专门给软件产品做的 “深度体检”。为啥这步必不可少？举个例子：开发团队把充电桩 APP 的 “找桩”“扫码”“支付” 等功能拆成小块做单元测试，每个单独操作都没问题，但车主实际使用时，却出现扫码启动充电后 APP 显示 “充电中”，充电桩却没反应的情况 —— 这就是单元测试没覆盖到的跨模块漏洞，所以这时候就需要更高级别的测试来发现问题。
一、软件开发与测试的 “默契配合”
软件开发就像接力赛：产品经理说 “充电桩 APP 要支持预约充电后自动提醒提醒用户”，设计师出了带倒计时提醒的原型图，再交给开发写代码，每一步都是信息传递和转换的过程。可偏偏问题就出在 “传递” 环节：比如产品要求 “预约后 30 分钟内未插枪自动取消预约”，开发写成了 “预约后30分钟未降锁自动取消预约”，这就属于信息转换错误。针对这类问题，书中介绍了三个实用方法：
1、把流程抠细：比如给需求加备注明确 “30 分钟取消时限”，并标注 “需同步更新充电桩状态为插枪”，从源头减少错误；
2、阶段验收不偷懒：原型图完成后让产品核对倒计时逻辑，代码写完后先测试预约功能是否符合时限要求，没问题再进入下一环；
3、测试方法 “对症下药”：比如需求转设计阶段，重点查原型图是否有取消预约的弹窗提示；设计转代码阶段，专门测试预约超时后 APP 与充电桩的状态是否同步。
这样精准匹配每个转换步骤，既不做无用功，也不会漏掉关键错误。
这里要特别说明下：测试顺序不是死规定，很多测试环节是可以同步进行的，不用非得等前一个做完。比如测试预约功能的同时，可同步测试充电状态更新的及时性。
二、功能测试：给软件 “对答案”
功能测试核心就是查软件 “有没有按说明书干活”，主要从三个方面入手：
1、定义上：就像老师批改作业，拿着 “标准答案”（软件规格说明）对照软件实际表现，找不一致的地方。比如规格说明要求 “应 1 分钟内更新充电桩状态”，实际测试时发现3分钟才更新，这就是明显的不一致；
2、方法上：大多用 “黑盒测试”—— 比如测试充电桩 APP 的扫码充电功能，我们不用管后台代码的实现逻辑，需要保证打开 APP 扫码、确认充电模式，看充电桩是否正常启动充电的全流程业务正常；不过这也得靠之前的单元测试打好基础，比如先确保下发指令到设备的全流程以及金额计算等逻辑没问题，在每个阶段结束时，可以引入一个独立的验证过程，在进入下一个阶段之前尽可能多地发现问题
3、过程上：得先分析规格说明，比如把 “充电流程” 拆成找桩筛选、扫码连接、充电监控、结束支付四个步骤，再针对每个步骤设计测试用例，比如测试筛选 “直流快充桩” 时，APP 是否会混入交流慢充桩的结果。测试过程顺序并不一定意味着严格的时间顺序，多种测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。
--等价边界读书组：唐宏蕾