很抱歉,之前居然忘记了这个系列的更新,幸亏有小伙伴及时追更。这就给补上哈~    

言归正传,我们上期整理了对于这个问题回答的多个角度,如下:

**流程(提测/需求用例评审/测试流程/上线流程/上线后流程)、工具技术/成本/维护、用例规范、bug报告规范、人员任用、风险把控、文档留存、bug补救措施、线上事故复盘、测试环境灵活、责任划分制度、集中随机测试、bug用例需求追踪、代码diff、上线同步 等****方面。**

并且一直说完了:流程,工具技术,用例规范,bug报告规范四个角度。



本节课继续讲:



**- 人员任用**  


人员任用和软件质量的关系,可以从最早的质量铁三角上入手解释。  

也就是 流程、技术、组织。  

图片

其中,组织指的就是人员的任用和管理。有了这个依据,就可以放心的说人员任用了。  



人员的任用上,要知人善用,做好风险防控,ab策略,奖惩分明,开诚布公等手段。一般来说,这个回答应该是领导来回答,起码也是管理层。可惜的是,博主本身并不善于人员管理,虽然曾数次被推荐到管理岗,但都因心软而主动退让。但其中的道理,还是看的懂的。


比如,任何一个核心技术,都要有backup人员,即后备军,防止一言堂的出现。也在人员跳槽的时候最大限度减轻损失。  

还有要时刻保持下属们的竞争状态,也就是说,你作为大领导,不要让手下们互相的关系特别亲近。更不能疏远你,否则会形成联合克上的局面。比如明明这个自动化脚本写的稀碎,但领导每每调研起,所有人都异口同声的说这个脚本没问题,很优秀。你作为管理领导肯定疏于一线技术,就会像古代的皇帝一般被贪官们联手蒙蔽。  

更要防止小团队的出现,比如某大厂内的xx派,xx帮的。这样只会增加内耗和宫斗,对整个团队而言百害无一利。  

  

再有,就是在分配任务给具体人员的时候,不能凭感觉分配,要充分的考虑到项目的难度和人员的基础及心理负担。  

还有在人员管理上,要熟悉几大类的区分,对不同的人以不同的管理手段,比如对于那种特别上进,技术又强的人要安排核心工作。对那种技术强但不上进的人要以利诱等。也就是速成的小白兔,大灰狼这些。  

  

还有在招聘环境就基本敲定的 选、用、育、留策略。组内的最好的学习机会,实践机会给到谁,并不一定是技术最高的那个人,而应该是忠于公司,长期稳定的种子。  



最后声明一下,本人并不想说出上面的这些管理手段,而且也不赞成领导用各种花招对付属下。而且本人也并不懂更深层次的驭人之术,上述技巧只是亲身亲眼所见而已,轻喷。正巧也让广大同学了解一下职场的各种计谋,防止自己被领导下套。  

- 风险把控

风险是一个比较大的名词,涉及到测试的很多流程。每种风险一旦出现要如何急救,之后要如何预防这种风险,责任划分等。



比如在排期的时候:

要预留出多少时间,想到多少种风险比如需求变更风险,提测质量过差风险,出现严重意料之外bug风险,测试环境不通风险,人员风险(比如突然请假),测试的功能是否是新功能,开发是否是新开发,功能是否很底层,是否影响过多模块,功能是否涉及到用户财产,生命安全等。这些因素都是会导致排期不足的因素,不能简单的按照开发周期来指定测试周期。  



还有上线风险:  

上线失败的话如何回滚,每一步都要有风险的把控表格。上线导致了严重bug要怎么修复,什么时候修复。如果bug导致了脏数据,要如何修复,修复的sql是什么,脚本经过测试了么等等。

上线后的回归怎么做,因为涉及到正式环境数据,所以很多写功能无法完全测试,毕竟会影响到实际用户。当然我们考虑的是风险把控,所以就要考虑,一旦真的影响到了线上真实用户,我们要怎么处理,法务部门有相应的声明么?比如你线上上架了一个测试用商品,1块钱的手机。一下就被真实用户看到并疯狂下单付款,你要怎么办?

上线后部分回归功能无法实时测试,比如之后某天的活动,自动在零点上线这种,你要怎么回归,线上又不可能给你真的去调整时间脚本。如果当天夜里自动上线活动失败,要怎么处理?

作者就曾经历过一次类似的,眼看到了上线时间功能却仍然一堆bug,开发同事还在外旅游中。最终只能被迫关闭活动入口... 造成百万以上损失。  



风险还有其他很多方面可以说,比如测试工具,自动化测试脚本,测试平台,数据不可靠,环境不可靠等等风险。我们要讨论的就是这些风险要如何预防,如何急救。  



  



欢迎关注本公众号:测试开发干货,一个不止讲测开的公众号。