标签：多个 意义 成功 需求 测试 实习生 笑话 背景 开发
新年伊始，又想吐槽一番。
背景；我在一个做自动化的持续集成测试的组。
我们隔壁有一个做测试工具的组。半年前我们隔壁组做了一个工具，具有代码分支管理、静态分析、不同级别的单元测试、集成测试等功能，
这个工具被老板看中，强制让所有部门使用这个工具来提交代码。不用这个工具提交的代码将不能合入产品代码的主分支。使用这个工具提交的代码会自动去编译、打包、进行各层测试。
大家使用之后，发现这个工具烂透了。有无数的严重BUG。（比如提交上去的代码不能打包成功，等等。）
我每次提交代码使用这个工具需要浪费大约8小时时间来解决他的bug导致的问题，才能最终把我们要提交的代码提交上去。
接着，隔壁组对这个工具的开发陷入了泥潭。
工具质量极差，被用户（各个其他需要提交代码的部门）提了很多BUG。
不得不停止开发新功能，去改BUG。改BUG时又引入新BUG，导致用户提交了更多的BUG。
这个时候，工具组的人和上头的老板才意识到这个东西这样做下去不行。
这工具需要测试。
于是找了个自动化测试架构师，带了一群实习生来做自动化测试。
他们把该工具的API拿出来，封装了一套自动化测试关键字。写了一些自动化测试脚本。
希望建立一套持续集成测试系统来对这个系统做自动化回归接口测试。
这时我们组的老板有意向把这个系统的测试工具接过来 （就因为我们组是专门做持续集成测试的？），于是来咨询我们的意见。
我想说，错了，这个方向完全错了。
这个项目注定会在泥潭里越陷越深。
这个项目中有很多错误：
1. 开发之初毫无测试意识。作为一个测试工具开发组，好歹算半个测试人员，居然没有一点测试的意识。不配备任何测试人员地去写一个影响很大的工具。
2. 没有单元测试。值得一提的是我们的所有产品代码都有或多或少的单元测试。所以没有单元测试，在我们这里肯定是一个错误。
3. 没有分析过这个系统的风险和各种外部依赖之间的关系。结果开发出的测试工具依赖多个不稳定的外部系统或服务。导致本来质量就差的工具显得质量更垃圾了。
4. 当发现需要测试时错误地选择了自动化测试。你们需要的是一个熟悉产品，熟悉需求的，合格的手工测试人员。
以手工回归测试执行的慢为理由拒绝手工测试。这正是这个组最大的错误。
合格的测试人员，掌握快速测试的思想，使用合适的工具，完全可以把任何复杂系统的测试时间降下来。在最短时间内发现最严重问题。
5. 他们最终也没有意识到测试人员需要了解需求。找了完全不了解需求的实习生来做自动化测试。当然了，这个工具也压根没有需求文档。
这时如果是一个合格的测试人员，我们会先去学习、了解这个系统，然后自己整理出这个系统的需求。以此为依据来进行测试。
但是，显然，由于我们公司全部都是自动化测试人员，并没有一个合格的手工测试人员。
即使我可以做，我也不愿意去加入这个烂摊子。
6. 自动化测试来不及解决这个系统的质量问题。
讽刺的是，他这个工具本身是一个持续集成测试工具。他们想要我们来搭一个持续集成测试工具的持续集成测试系统。真是一个笑话。到时候我们这个持续集成系统搭好了又一堆BUG谁再搭一个来测我们的系统？
而且这个时间线也拉得太长了，这套自动化API测试即使搭起来也是很久以后了，写脚本的人又不懂用户需求，根本不能写出有实际意义的脚本。也就是说，即使测试全PASS，也不代表系统真的没问题。
7. 测试人员不是救火队员。你的系统质量已经烂成一坨了，请不要妄想此时引入一两个测试人员来背黑锅。所以这种情况下，我是绝对不愿意接这个活的。
而且手工测试人员的地位之低真是令人惊讶。
能改善这种垃圾系统的质量的测试人员都是真正的高手，他们却想把这种高人当作打下手的人放进项目组，做梦呢。
我就只能不屑地笑笑，然后告诉他们，这个系统病入膏肓没救了。
最后这一切又印证了我对测试工具/自动胡测试的看法：测试工具和自动化测试脚本本身的质量是最需要保证的。
请把三流开发人员从这个做自动化和做工具的队伍中踢出去，最起码也找一些二流的开发来做。另外，请找一个一流的架构，从一开始就减少这个系统的BUG产生可能性。
而不是找三流的架构加三流的开发，作出一堆垃圾再去找测试背锅。
记一个质量极差的测试工具——请重视手工测试，自动化测试不是银弹
标签：多个 意义 成功 需求 测试 实习生 笑话 背景 开发
原文地址：http://www.cnblogs.com/sdet/p/6351519.html
