测试安全感

    当我还是新人的时候，每当我测完一个版本，都会内心很惶恐的想，测试是否不够充分，是不是有没有测到的地方，所以经常很不淡定的周末过来又把流程过了一遍，虽然基本没发现有什么问题，但是还是觉得这样复查一遍才能安心测试通过。虽然过了一段时间，逐渐成为老手，但是这种缺乏安全感的感觉偶尔还是会浮上心头:老大让我测一个我没玩过业务，我测完了还是坑觉残留；开发信誓旦旦的说改动很小，但我知道他的代码坑过我几次，我再也不相信他了。渐渐地，我明白了原来测试都是一群缺乏安全感的人，这也从另一个侧面证明了为什么测试团队有这么多妹子

 

    如果以安全感来体现测试情况：版本质量越高，测试越充分，则测试的安全感就越高，测试的安全感越高，对版本测试耗时以及风险的把控能力也就越强。一般而言，用例执行完了就会测试通过，以上面所提例子来看，在很多情况下，测试用例执行完成后并非会测试通过，而是需要达到一定的安全感

 

    影响安全感的因素：

    1.测试对业务的熟悉程度

非常熟悉，代码和逻辑都清楚 ——高安全感

一般熟悉，只是调用过或者小版本摸过——中安全感

不熟悉，没有测试过或调用过——低安全感

    2.测试对开发代码质量的评价——中安全感

代码注释充分，逻辑清楚，文档齐全，业务经验丰富——高安全感

逻辑复杂/业务经验一般/文档或注释缺失——中安全感

新人/提测模块基本流程不通/若干低级BUG——低安全感

    3.测试方法以及用例覆盖的粒度

从函数到接口到系统分层进行测试，覆盖各种场景和逻辑分支——高安全感

完成正常功能的测试，覆盖主流程和部分场景/覆盖了各种场景但存在打桩或模拟的情况——中安全感

仅完成接口测试/测试过程中未能模拟相关场景——低安全感