软件测试之风险管理

没有不存在风险的项目。作为测试人员，工作中无处可见风险，所以要学会擦亮你的双眼，及时识别风险，及时评估风险影响范围，及时给出降低或者规避风险的措施。

下面是我在工作中真真实实遇到的风险。

一、需求风险

描述：需求变更频繁，需求文档质量差，需求不合理，均可能导致开发和测试返工。
主要责任人：产品

二、测试用例覆盖不全

描述：测试人员在前期需求评审参与度低，对需求理解不透彻，导致用例设计覆盖不全，有遗漏，未发起用例评审也可能导致用例场景遗漏。另外由于1中的需求变更导致测试用例未及时更新，测试B进行执行的时候，漏掉部分功能。或者按照错误的进行测试。
责任人：测试

三、提测延期

描述：在迭代前，测试计划中会包括需求或者某个可提测的模块提测时间，这个时间是开发和测试私下沟通达成一致的，由于开发人员的因素未能按照提测，在提测前未将风险同步出来，导致未按照计划来，提测延期，测试相应的计划就会被打乱。整体对项目带来一系列的风险。
责任人：开发

四、冒烟质量差

描述：开发提测过来的版本，质量差，存在很多主流程跑不通，随便点点就报错的问题，导致测试阻塞无法进行，需要打回版本重新冒烟。
责任人：开发

五、测试环境风险

描述：测试环境不稳定，开发私自替换版本，或者修改配置，开发和测试使用一个环境进行测试，这些均是风险。还有一些场景无法模拟u用户场景，导致未能测试，客户使用过程中发现了
责任人：修改环境的银

六、测试用例设计未及时输出、测试进度慢被阻塞的风险

描述：测试对于用例设计的工作量评估出现误差， 导致测试用例未能及时输出，从而导致冒烟用例不能按时输出，开发不能正常提测。测试进度慢被阻塞，可能有多种，比如测试工具的理解需要时间成本，导致执行慢，或者是测试场景复杂，比预期的要执行慢，或者是存在阻塞性的问题，导致后续测试用例均被卡住。
责任人：测试、开发。

七、bug修复不及时，不收敛

描述：版本的bug比较多，开发修复问题进度慢，且修复问题，引入新的问题，导致返工等，bug不收敛，或者是bug修复不及时，所有bug均在封版前一天才开始修复问题。测试也有，因为测试应该及时跟踪bug修复的进度，避免bug遗留到最后一天，提前进行风险预警。
责任人：开发、测试

八、修改bug影响范围未准确评估

描述：开发人员修改一个bug，对于代码的关联不是很熟悉，导致修改了这块，其余使用这块代码的功能，未进行同步修改，测试人员不知道，仅回归了这个问题，最后将版本部署到客户侧，被客户发现了，就是线上重大事故。
责任人：开发。改进措施：自动化回归。

九、插入需求

描述：导致工作量增加，影响现有的任务进度。一般在迭代前期是测试计划会做好接下来要做的事情，进入迭代后，就开始正常的走研发流程，但是不可避免插入新的需求，应该说实际工作中，这种简直就是家常便饭。。。。所以针对这种插入的需求，作为测试负责人，你该怎么办?首先，规划之外的需求临时插入，必然导致原来的测试任务无法正常开展，除非吐血加班。。。但是加班不是解决问题的办法，如果测试一味的接需求，测试排期总是被打乱，那版本的质量如何保障？加班身体搞垮了，测试如何能够更好的做好测试？哈哈哈。。。
责任人：产品、项目经理
解决方案：说点有用的，如果遇到临时插入的紧急需求时，要及时和当前计划内的需求进行比较，测试先心里有个优先级合理排序，以及插入后的影响，会有哪些工作无法做，不做的话，会导致什么，不做的话，什么时候能够安排上，是否会影响下个迭代的事情？需要给出合理的解释。然后把事实同步到项目组，产品、开发、项目经理，一起讨论，最后达成一个可行的方案。

十、人员请假风险

描述：对于请假导致的哪些工作无法正常开展，影响范围，是否特别重要的需求，是的话，是否协调组内的其他测试来接手，或者是其他项目组的测试人员来协助测试，其他测试中间接手也是风险，可能会对需求理解不充分，导致测试不全等问题。
责任人：测试
解决措施：同描述。

十一、评审风险，未正常发起用例评审

描述：因为时间来不及。省略了评审，导致测试用例覆盖不全。
责任人：测试。

十二、开发需求理解不对，导致开发出来的存在功能不对。

十三、产品变更需求。未通知测试，仅告诉了开发。导致测试开始测试的才发现。

十四、开发私自接需求，修改了一个小点，然后自测后，就跟着版本发出去，未经过测试。问题暴漏在线上。

十五、开发技术架构风险，做一半发现行不通，需要变更技术架构。

解决措施，待更新。。。。