[开发测试]技服代表与测试对产品的视角

一.双方的职责

? ? ? ? 我说了解的技服代表,主要持续关注客户的业务,并给客户做升级,扩容,软件产品上线入网.另外我的职业是个软件测试,我说理解的软件测试的职责是产品质量保障和版本交付,即在保障质量的同时还能够协助一线或者公司目标讲产品交付给客户.

二.一次经验

? ? ? ? 我有幸出差协助客户做扩容测试,技服代表负责扩缩容产品的操作,以及环境的配置,并持续观察产品,协助客户做交付的测试.而我则是在这个过程中,根据我在产品中的经验,去分析操作的合理性和风险,并在有问题的时候,找到相关的同事进行问题定位.

? ? ? ? 我发现的很有趣的事情是,我们测试在家测试的性能可靠性,比如承诺交付的工作能力时对应的CPU内存信息这些在技服代表这边几乎不会被关注.而他们关注的跟过的是,业务成功的指标,比如在管理平台上面各项业务随时间变化的成功率,以及告警.

? ? ? ? 突然间,我就想,那岂不是我们在家所做的严苛的性能测试和可靠性测试就浪费了,或者说用处不大?实则不然,我们在做测试的时候,测出一个明确的性能,然后售前工程师,或者交付部门就会根据指标向客户承诺一个更低的性能指标,给自己保留一个可以操作的空间.

三.为什么技服代表这么关心告警,而测试不是

? ? ? ? 告警是一个非常重要的手段,有他才能有交付的保障,因为告警可以提前预知系统风险,然后让技术人员去提前做出相应,所以最近才理解到的一点就是,一项商用的特性或者功能一定需要在管家的节点上做相关的告警.

? ? ? ? 所以技服代表在做升级或者扩容前就一定要清理玩告警,或者说在平常的时候,就一定都有在处理告警.

? ? ? ? 而测试在测试产品的时候,常常是根据需求用例,并且完成测试执行,BUG回归.执行过程中,关注点在于用例所描述的关注点,而不太会把注意力放在告警上,而这大概需要特意的训练或者培训强调才会做得到的.

? ? ? ? 另外测试说碰到的告警尝尝是和她们目前的测试内容无关,所以就更加容易忽略了.以及在一些大型的软件系统,工作一年的测试并不会了解所有告警的出发原因以及相对的影响.

四.遇到的一个问题

? ? ? ? 问题是这样子的,扩容过程中,出现license超限的情况.BUG根因是这样子的,扩容的时候,要讲数据拷贝的新扩容出来的设备上,但是为了软件的可靠性或者冗余性,在本地也保存了一份数据,等到技术人员确定扩容过程无问题后才确认把本地的数据删除.但是因为编码原因,在计算所使用的数据量的时候,把拷贝其他地方的数据都本地的数据都计算上了,导致数据的使用量由原先的100增加到150个单位,而license的限制150.这个时候就出发了一个告警.即license超限的告警.

? ? ? ? 所幸license相关的逻辑还算比较人性化和完善,即系统允许客户系统由一定次数能够超过license的使用,而如果是自己根据license来限制,则很有可能导致业务大量失败.

? ? ? ? 为什么会出现这个问题呢?开发方面:最开始在修改迁移数据的代码的时候,是为了性能优化提升而考虑的,然后还是作为一个小的特性或者补丁去做测试,所以一定程度导致测试的测试力度和分析的程度不够.测试角度:测试在拿到这个小特性的时候.抓住了重点即性能提升,所以就在性能测试上花费了大功夫,比如基准测试和多倍压力测试.而不太会去考虑和license相关的逻辑.以及作为一个小的特性,测试在测试执行的时候,就是按照自己说理解的,搭建一个比较干净的并且该系统上没有较多业务和数据量,并没有能够去考虑到客户场景是如何使用该场景的.这样子就测试不出来问题.

? ? ? ? 所以倒是测试的时候,尽可能讲测试环境,设置在业务容量已经达到承诺值的70%的点,这样子可能就能够发现一些问题.

五.对测试的启发

? ? ? ? 经过这件事情之后,我发现,测试并没有去了解客户或者技服代表的关注点,而只是按照需求的约束点去关注,所以对于测试的参考价值是,测试应该主动向技服代表学习,了解他们对产品的了解和期望,并同步传递他们的关注点.