小白的白盒测试之路——用例设计篇

提到白盒测试的用例，首先想到的是接口测试用例和逻辑覆盖用例，但小白最近遇到了这样的一个问题：

问题：黑盒白盒同时进入测试，黑盒测平台，白盒测核心，项目上线时间为平台测试结束时间，开始迫于压力将核心的测试完成时间压缩到上线前，但后期时间紧张，测试混乱、不全面，上线问题较多，压力山大。

面对这样的问题大家怎么考虑的呢，我认为这个问题的直接原因有两个：

1. 白盒测试效率较低，前期需要铺垫的东西较为复杂（代码了解、用例编写、用例调试等），等白盒测试这边铺垫完成，黑盒这边功能都测完了；

2. 白盒测试人员考虑问题简单，认为所有待测的核心功能都需要白盒测试，没有针对不同的功能选择测试的方法，导致将大量的时间耗费在一些没有必要做白盒测试的功能上；

怎样解决这样的问题呢，首先要先清楚各种测试手段的优势和劣势：

1. 随机测试的时间消耗最少但覆盖面也最小，适合做回归测试；

2. 黑盒测试的时间消耗中等覆盖面较全面，适合做直观功能的测试；

3. 白盒测试的时间消耗较高但覆盖面十分全面，适合做核心逻辑的验证；

4. 自动化测试的时间消耗极高可覆盖规模性的数据，适合做策略性的验证；

根据上面所述测试手段的优势和劣势，我们尝试用下面的办法解决上述的问题：

1. 白盒测试排期前，需要针对测试的功能和测试的时间判断测试的手段，根据测试手段的不同和时间消耗给出准确的排期；

2. 对于项目进行中插入进来的任务要考虑当前测试时间是否宽裕、插入任务是否复杂，考虑后再判断是否要接插入任务；

3. 测试过程中遇到白盒用例设计较为复杂的情况时，应考虑是否可以采用其他方式（如黑盒测试）的方式来解决，不应钻牛角尖，将大量时间花费在写用例代码上；

原文链接

如需转载该篇文章，请注明来自“搜狗测试”