工作思考之测试

今天参加一个故障的修改。

每天都参加故障修改。

故障的特点是：针对非常特殊的情况的修改，在用户使用过程中几乎不可能发生，而且即使发生了也不会造成太大的问题；

项目的情况：项目的版本马上就要发布给用户使用了；

 

故障发现的过程特点：

针对测试用例a进行测试，非自动化测试的情况，只靠手动敲命令来测试功能：

一个测试人员A君，如果此人相对比较懒，但是也能满足测试部门的要求，对这个测试用例测试就不可能发现问题；

另一个测试人员B君，如果此人相对比较勤快，对相同的测试用例，就有可能发现问题；

 

我的疑问是：对同一个测试用例，如果项目组都是A君程度的，就不能发现问题；如果都是B君程度的，就发现，很多在外场几乎不可能发生的问题；这就无疑增加开发人员的负担，增加代码流程，修改已经测试稳定的流程；而且开发人员也有怨言，天天修改这种故障，几乎就是在出力不讨好，因为针对这个修改要出人力，而且如果这个开发人员没有处理好新的流程，引入故障，还要被领导批评。其实对测试人员要增加了测试负担。

 

我认为深层次的原因是：

1、测试人员为了测试而测试，测试人员没有一个目标，就知道一味蛮力测试。

2、测试用例有问题，大部分的测试用例都是几句话，最重要的是没有对测试结果有一个量化标准，如一秒钟建立多少tcp链接；但测试用例没有一个标准的时候，测试人员就无法衡量什么样测试符合要求的；就只能任由发挥。

3、测试经理、项目经理分析故障的能力，是不是所有的故障都要解决，是不是要分清楚哪个故障是应该解决的，哪个是下个版本解决，或者根本不用解决。这就考验经理们的技术能力了。但是大部分的经理都是有故障都要解决，不分轻重的。

 

 目前的感觉就是：项目越大，人越多，如果没有严格的培训程序，管理，测试和开发只能走向歧途。