入行测试也有小十几年了,传统的测试工程师流程拿着需求文档写用例并去执行,大部分用例是基于每一个小需求验证点的扩展,比如一些常规正向用例、反向用例、边界用例、异常用例等等,都是基于用户需求本身去做的验证。在云平台的前几年,这样似乎没什么问题,因为各业务部门都有自己要完成的迭代目标,大家都在测试各自的系统或者模块。直到需求发布的时候突然间发现,即便是你的各种测试方法都用到了,发现仍然有遗漏的bug。而且这个问题屡见不鲜,一直没有太好的改善,那在追求高效、准确的今天,测试人员该如何提升自己的测试水准和效率满足当下快速迭代的需求呢?怎样才能站在更高的层次去思考为什么有些业务bug会逃逸到线上呢?
究其原因主要有以下几点:
1、确实是漏测了
2、异常场景未覆盖
3、需求文档中没有覆盖
4、开发做了需求夹带
5、用户实际使用场景未闭环。
近几年,整个平台的测试开始慢慢关注用户场景化用例测试,原来的那一套测试方法已无法满足当前快速迭代的需求。我们一直在强调测试人员的用例设计需要场景化,如何才是场景化呢。简而言之就是通过这个软件/系统/需求,用户可以完成达到一个实际目标。有角色,有使用场景,且用户故事把产品定义清晰化,用户可以通过产品来做什么,达到什么目标。就像现在的运营商产品,在产品定义之初,产品经理就站在实际的运营商角度去分析这个产品可以为真正的运营商做到什么。
1、可以为运营商做充电站的运营
2、可以为运营商们管理电站、终端
3、除了满足个人客户充电外、还可以发展企业大客户,
4、可以提供为了吸引客户创建的一系列的活动,做活动分析,营收分析等等,让运营商看到利用当前这个产品带来的一些直观的运营收益。
5、还可以替运营商们拓展加盟商业务,与加盟商签定协议进行清分结算,加盟商同样也能通过平台,查看自己的盈利点,与运营商一起实现共同盈利。当然,一些小的投资人也可以与运营商和加盟商共同投资,达到多方盈利的目标。
整体的中心思想就是,我们的产品可以给运营商带来实质的收益,替他们“赚钱”,那不管从哪个出发,这就是一款好产品。了解到这些实际的用户需求后,再回头看产品的整体设计,突然间就豁然开朗,哦,原来需要这样设计。
近期云平台组织了全员共读一本书的活动,在考虑读什么书的时候,我就在思考,作为测试读哪一本书更为契合当下的需求。是专注测试技术拓展,还是专注测试方法的提升。基于以上原因,我选择了《用户故事与敏捷方法》这本书,这本书更多讲解的从用户故事角度出发去做需求交付有什么样的优势。在我看来这些优势对于测试来讲同样重要,特别是对于运营商产品的测试团队在现在面临快速迭代交付的同时,又要保证整个产品的全流程在每次安装盘里都能正常运行,除了接口自动化的覆盖度,角色、场景、用户故事的理念贯穿于我们平时的测试工作中。以下是我们测试团队在验证全流程场景的一些实例,以供大家参考。

