首页 > 代码库 > 测试安全感

测试安全感

    当我还是新人的时候,每当我测完一个版本,都会内心很惶恐的想,测试是否不够充分,是不是有没有测到的地方,所以经常很不淡定的周末过来又把流程过了一遍,虽然基本没发现有什么问题,但是还是觉得这样复查一遍才能安心测试通过。虽然过了一段时间,逐渐成为老手,但是这种缺乏安全感的感觉偶尔还是会浮上心头:老大让我测一个我没玩过业务,我测完了还是坑觉残留;开发信誓旦旦的说改动很小,但我知道他的代码坑过我几次,我再也不相信他了。渐渐地,我明白了原来测试都是一群缺乏安全感的人,这也从另一个侧面证明了为什么测试团队有这么多妹子
 
    如果以安全感来体现测试情况:版本质量越高,测试越充分,则测试的安全感就越高,测试的安全感越高,对版本测试耗时以及风险的把控能力也就越强。一般而言,用例执行完了就会测试通过,以上面所提例子来看,在很多情况下,测试用例执行完成后并非会测试通过,而是需要达到一定的安全感
 
    影响安全感的因素:
    1.测试对业务的熟悉程度
非常熟悉,代码和逻辑都清楚 ——高安全感
一般熟悉,只是调用过或者小版本摸过——中安全感
不熟悉,没有测试过或调用过——低安全感
    2.测试对开发代码质量的评价——中安全感
代码注释充分,逻辑清楚,文档齐全,业务经验丰富——高安全感
逻辑复杂/业务经验一般/文档或注释缺失——中安全感
新人/提测模块基本流程不通/若干低级BUG——低安全感
    3.测试方法以及用例覆盖的粒度
从函数到接口到系统分层进行测试,覆盖各种场景和逻辑分支——高安全感
完成正常功能的测试,覆盖主流程和部分场景/覆盖了各种场景但存在打桩或模拟的情况——中安全感
仅完成接口测试/测试过程中未能模拟相关场景——低安全感

测试安全感