测试工作中的技能储备

今天工作中碰见一件事情，让所有人都觉得有点郁闷。

    我们产品是一个底层的安装框架，对上层要支持平台软件，再上层还要支持产品软件。每个都是独立开发，每个产品都定时在货架服务器上上传新的相对稳定的版本，来支撑其他子域的测试和验证，整大产品的主要客户是电信运行商，规模比较的大。

    我们的产品应为涉及到很多个平台（linux，solaris，windows）且每种系统上还有多种不同特征的版本（单机双机多机....），一个正常的转测试流程下来，涉及到的测试场景有10多种，平均每个测试人员要分配2-3个场景，而且不包含各种专项测试，任务量比较繁重。

  

    一般情况的转测试，都只使用平台软件来配合，不会涉及到产品软件，偶尔零星的也会使用产品包，如果涉及到产品包，我们就称之为“联调”。进这个项目三个月以来，只见过几次联调，每次都是那个几个老员工来做。

    每次转测试的各种包，都是开发的CMO从货架拿版本然后再转到测试，经由测试经理和TSE制定好测试策略以后转发给测试员测试，整个流程测试人员基本不会接触到货架，虽然一开始测试经理一直在强调每个测试员都需要熟悉怎么从货架获取最新的版本，但是一直都没有特别的测试要求从货架取版本，再加上测试任务繁重，新进的测试人员基本都不知道如何从货架取其它域的软件包。

    这次的转测试，是星期六早上，测试员需要花大约一天的时间来准备测试环境，迭代开发的原因，转测试流程非常紧凑。周一晨会，测试经理宣布本次测试的所有场景都需要联调，所有测试员都要从货架上获取版本。几经周折以后才发现，包括测试经理，TSE在内的10个人，只有3个会从货架取平台包，只有一个会取产品包。于是所有的测试进度都停滞，等待产品包。偏偏不巧，产品的货架包又存在不确定因素，需要和产品域的人沟通，而产品域的联系人正巧又在开会，于是整个测试进度从上午到晚上下班，一直停滞。

   导致这个个时间的根本原因就是技能储备不充分，总结一下自己对这个事件的看法以及解决办法

 

oydeqq原创，转载请注明出处。