年末的一些感想

下午整理了一下今年的一些工作情况，准备写工作总结。看了看，发现一年下来都疲于奔命中。

    我做软件测试工作，今年算加班大概有200个有效工作日，测试了28个任务，平均算下来，每个任务实际只有7个工作日多一点。最长的一个连贯的工作任务，测试了32个工作日，最短的只有1.5天。

    实际28个任务中很多都是重复的，比如我们有一个软件分A、B、C三版（不是随口说的，就叫A版、B版、C版），其中每个版本还分中文版、英文版，中间还升了一次级，里面的功能也经常的添加、删除、修改，每次改动一些，都要拿过来测试一下，甚至帮助都是我们帮忙检查修改的。今年为了这个程序，我们就测试了不下10次。

    我们公司的程序绝对不是小程序，大部分是*工程，实际中每天都要用的，所以有问题很容易就会被发现。一些软件还要做外文版向国外买。其中很多程序里面的工作流在我测试的范围外我都会搞不清楚。

    软件工程中说的都很好听，实际上很多都无法执行。测试工作应该有各种文档支持，比如需求、帮助等；测试前应该写测试用例；测试介入软件过程中越早越好等等等等，但是在我们这里几乎无法执行。

    连续超过10个工作日的测试任务今年只有6个，包括我这两天正在测试的。其它大部分在3－6天之间，而且几乎都没有任何的文档，拿过来就要测。等到软件熟悉的差不多了，实际也就离测试完毕不远了。测试用例，我记得很久没有写过了，顶多写个测试注意事项，标明测试中需要特别注意的地方。真写测试用例，写完黄花菜都凉了。

    时间紧、任务多，像什么自动化之类更是水中之月。像我们的程序，自动化工具倒能使用（每个页面都几十edit，很好抓），但用了又能如何，一个程序的测试时间顶多能让我们测试3次，在写脚本的时间内，我敢保证我手工测试发现的问题比自动化工具多的多。

    工作的松紧也并不在测试部掌握之中，很多都是临时的任务。年初的工作计划根本没用，开发那里几乎每个项目都要拖，如果一个项目延期，就会和其它的项目冲突。我最忙的2月份，一个月加班11.5工作日；10月份的时候，整个月什么事情都没有。任务紧的时候，曾经从其它部门借调了4个人来帮忙；任务松的时候，11、12两个月只有我自己测试了几个任务。

    我不清楚我们公司是特例还是普遍。测试的工作都想像的简单，特别是黑盒手工。但想做好，实际和每个人想像的会有很大的差别。很多时候并不是技术能力上的问题，而是实际情况不得不逼你那么做。国内的环境我想应该不会相差很多吧。

10 个解决方案

#1

呵呵
鹿鸣兄过得蛮充实哟：）

#2

zhuma(竹马)
挣的钱也不少把？？

#3

这才是一个真正的参与到实际工作中的人所说的话，严重同感，呵呵，不过环境如此，不是哪一个公司、哪一个人能够改变的，公司想生存，就得在这样的环境中竞争，个人想生存，就得在这样的公司中做事，我们能做的仅仅是尽自己的全力将该做的事做好。

#4

htw_qq()兄：

是不是搞错了对象哟：）
俺可是彻头彻尾的穷人兄弟：（

#5

有个测试部就不错啦，呵呵。。。3-5年前公司里头连测试这个岗位都还没有呢。。

#6

不错呀
老兄够可以的!

#7

呵呵,去大公司吧,大公司對軟件質量保證很看重的,真正做好測試軟件保證還是很有前途的,不過還要等幾年,國內目前對軟件測試重視程度還不夠的

#8

呵呵
现实与理想的差距

#9

因为开发的原因，会给测试带来许多困难。
可是开发就容易吗？我们经常因为设计的因素而疲于应付。
同样，设计人员也会因为上游的工作造成很多失误，
而测试的失误又直接影响到软件的维护。
现代的软件生产就像一条流水线，每一个工序的错误都会对下游产生影响。
这就是为什么现在软件开发重视团队协作的原因。

#10

个人觉得重视团队是一方面,还有一方面就是对于每一个开发人员,也就是我们自己,一定要扎扎实实的把自己范围内的工作做好,努力提高自己的工作能力,解决问题的能力,只有从咱们自己身上找到不足,想到问题解决的办法,才是真正的进步,才真正有意义,也就是说,表面上看事协作的问题,实际就是个人的问题,团队问题最终会归到个人的工作技能水平上来的.这个就是公司正常运转的基础面吧(没开过公司,自己吓说的,见笑.)
每年年关的时候总结一下感觉收获都不一样
记得去年的时候还看到我们组里面交上来的整齐的年终总结
今年写总结的时候,和去年感触又是不一样.呵呵

#1