说说想法！
工作两年半了。期间因为部门的解散换过一次工作。就是现在做政府项目软件公司在这家公司工作一18个月了。学习的技术并不太多。现在更多的还是手功的测试，发包并就有一个安全测试。
但是在整个工作过程，包含得太多了，有时也会觉得现在这样的工作是不是真的要一个测试人员去完成。
政府的项目的能延迟就延迟.....
要是很赶时间的话，就会先让一问部分功能上线，就是这样上线后问题就一大堆了。
因为项目多数据是改造型的，不断的优化功能，添加功能....要开发时就有很多功能的改变是否会导致其他的功能或是
其他的平台会受到影响.根本就没有分析过.....上线后就有很多的BUG.
需求也是这样。
需求文档也只是很粗略的那种,开发走了一批，新来的同事很多业务都不懂。就跟了7年的测试经理对所有业务的熟悉程度还是70%的样子。
项目来了。开发经理给出一个时间表。精确天！
开发和测试就按着去完成，然后得出各种的报告....
测试人员着手测试了，拿到DEMO 对着需求一看，傻了...太多的与需求不相符了。
根本无法测试，一问开发人员
“这功能没有实现吗？”
“这个我不知道哦，我们经理就是说加这个功能就了，没说要加那个，你去问题经理吧”
“你没需求文档吗？”
“我是猜着做的”
一脸黑线呀！
开发出来的功能，开发人员总是没有自测，就提交的。而且一个功能改了好几次，文件提交了好几次，问题还是没有解决......
1、这样开发就会暴露自己的能力------没自测，对工作很散漫
2、文件不断提交，测试人员拿文件太浪费时间，当时配置管理用的是VSS，就一个字烦呀！
运维周五就会发一个BUG的跟踪表的。一下周下来开发至少提交20次，测试人员在更新文件时就要更新20次，如何到了发包时中间还有问题没解决的话，那就又只能从中间断开了，先上后面的修复.....这样真好累呀！
说几个现象
1、开发人员的流动
2、开发人员的积极性
3、开发人员的能力
4、开发人员的业务逻辑
5、开发人员的代码规范
6、开发人员的理解能力
7、提交文件的描述
1、项目经理的负责任
2、项目经理的工作到位
3、项目经理的能力
再说测试人员
1、业务知识，只能业务知识丰富才能得出更多的测试用例，更有说服力的用例。有时要的并不是有效率的用例。而是有能会出现的情况
2、自动化的能力 这个太需要了。改造型的项目，多数是不停回归回归再回归
3、性能、安全 这两个的话，我觉得还是有50%的公司并不太会去重视.... 懂一些就可以。LOADRUNNER 能跑数据正常就行。
APPSCAN 这个也能满足多数企业了！
4、一定要懂数据库，懂得多就更好。当发现BUG时，直接给数据开发看，让开发哑口无言---更有说服力。
5、懂看日志，懂看代码
6、让开发经理和你一起去做代码走查 ------这个是我一周中最开心的事，看开发的代码，听开发说逻辑.一有问题立马说出来...这个超有成就感...
嗯嗯。写的不错。 总结的不错 从现象看本质，从说的几个现象说明，要记着，开发没什么，开发也有能力不行的，做测试也有牛叉的，千万不要妄自菲薄，最反感有的人一上来就 “我做开发的，还让我如何如何……”这种口风，昨天翻自己之前的帖子发现了一个，明明自己开发能力弱，还牛逼哄哄的。
再说测试人员，多动脑子，多动手，从深层次提出尖锐的问题，不管是手工测试还是性能测试，一样有价值。当然，多学一些东西肯定是好的。
总结的不错。。。。。 好乱。。。。。。。。。。。。。 善于总结的人进步快，看好楼主。
页:
[1]
