一个做手工黑盒测试的无奈

木暖

又是一周功能上线前了，精气神又回来了。我还真是顽强呀。
一点也不难过了，今天发现开发的兄弟还是挺信任我的。一个经理不待见我就不待见我吧，还有千千万万个开发兄弟待见呢。加油，加油，加油~~~~（林志玲的小嗲声念）

特别谢谢给我建议的人。上周工作特别多，特别累，一直加班。之前我们的测试是有好几个，现在基本就剩我一个了。
我觉得8楼的说话很到位，呵呵，“我提Bug改不改是你的问题，你不改，但是Bug在那里，出问题是你的问题，跟我有什么关系，我已经找出来。”真有魄力呀。
之前和开发的关系都特别好，基本上他们都觉得我是自己人，对我很好。因为之前我报告的BUG相较其他人来说是比较有质量，并且数量也是摆在那的。很久之前我就负责他们那种比较大的功能的测试了。说不用测的那话的人是他们的新头。是新经理，真的很无奈。而且我发现他说的最多的就是你在前端是看不出来的，问题是我要真看不出来就算了，偏偏我看出来了呀。
现在这个头这么做不仅影响我的的测试，肯定也会影响到其他开发人员对我的信任。这才是让我纠结的重点。以前发现BUG就算再晚也不会埋怨，积极去改就好了，他一说你之前怎么没测出来我就很郁闷了。BUG这个东西防不胜防，我也在努力去防呀。我希望和他和平共处的。唉………………

一个人絮絮叨叨。
不知道还有多少人是和我一样是做手工黑盒测试的，我也曾兴致勃勃的学习QTP，总是不得要领。
可是这些事应该和自动化测试没有什么关系吧。
很喜欢测试，当测试是我的事业。不知道算不算自不量力。因为我发现我守不住我的事业了，不懂技术，测试结果也被人质疑。而我拿不出更有力的证据证明我的测试结果。我说这个不对，有人就说这个就是这样的，我们是怎么怎么做的，肯定没问题。这个你不用测了，肯定是对的。
目前公司的测试就我一个人，近期的测试都要被开发影响。
这次有一个bug上线前才测出来，被问，怎么之前没有测出来。我内疚，可是我也无奈。
测不完的时候我也在加班，我像开发一样，一样重视这些功能，我希望经我手测过的东西，不说完美，至少不会有重大缺陷。这是他们的愿望，也是我的愿望。
不知道为什么会成这样，最近总有一些功能出现问题，我总是想到这没想到那。
特别难受，做一个不被开发信任的测试很难受。之前有人说开发瞧不起测试，我一直觉得只要自己能看得起自己，自己做好自己的事，其他人怎么想有什么关系。可是不是的，一个测试，自己的测试结果就像自己的小孩一样，就像开发的代码一样，不被信任的时候，难过应该是一样的吧。
不知道怎么走下去，不知道为什么会变成这样。如果以后的测试都被开发影响，那我的存在还有什么意义。

msnshow

不要想着手工测试就没啥好做的，自动化才是有前途的

其实手工测试也能做得很好，自动化不一定是最适用的

dde333

只能劝你坚持住，不要轻易放弃！

愚人

高手是要能根据情况判断用什么方法更合适

愚人

做不好手工黑盒，能做好自动化的概率为0.00

月上百合

功能测试，重不在手动动，而是脑动动，因为多动脑测试全面点。我觉的要想没有遗漏还是挺难的。黑盒做好也不是哪么容易的。啥也别想积累经验吧。

yyfpblzhsxlfs

这个也许跟经验积累有关系吧，也许遇到的问题多了，想到的问题，也就多了

qq13816974762

想获得开发的信任，一部分要源于你领导对你工作的支持，另一方面是你工作结果的累计，你能提示比较多而且典型的bug出来，那么之后他们对你的工作肯定有所支持，在一方面就是保持一个良好的关系，至少平时也聊聊，一起活动，打打球或者找一些共同爱好，不能拉所有的开发，但最少要保持有一个关系特别好，还有就是他们对你质疑的时候，你可以去找一找有什么相同的类的软件，而且是比较大的公司做的（他们一般都做的比较细）拿过来对比，这是强有力的证据，对于那些比较离谱的开发，你不用测，肯定是对的，那就一句话，出了问题你负责，但你自己还是要测的，统计下来问题反馈给他，不改就算，项目的质量不是一个人事，不要把什么责任往一个人头上扛，说难听点，我提Bug改不改是你的问题，你不改，但是Bug在那里，出问题是你的问题，跟我有什么关系，我已经找出来，

shijinjin

同意楼上的观点，要对自己有信心，需报着一颗怀疑的心态，努力做好自己份内的事，用事实说话，至于那些不给予你合作的开发人员你可以换位思考一下，寻找和他们最佳的沟通方式，这样会对你的工作起到很大的帮助的。
加油，其实我也是个新手，目前和你的处境很类似。。。

一周琴弦

楼主想开点啊，凡事都会遇到困难，自信一点

一周琴弦

八楼九楼正解

lsekfe

做黑盒测试主要是在功能测试为主，如果东西一多。很容易遗漏，那么测试用例对于黑盒测试人员来说非常关键，我觉得一个好的测试用例才是黑盒测试的最重要组成部分。但是我到现在对于测试用例的编写还是觉得自己没有开窍。只是一味着跟着功能走，很多人说写测试用例之前需要看下研发的文档，说实在的那些文档长的要死，看的都想吐。只能自己看看这方面得书，再开窍下了。

syn106

一个人絮絮叨叨。
不知道还有多少人是和我一样是做手工黑盒测试的，我也曾兴致勃勃的学习QTP，总是不得要领 ...
木暖 发表于 2011-11-20 12:00

    adsds

syn106

回复 14# syn106


    22323

archonwang

呵呵。有时候觉得，反思是重要的。做事哪有没错的。或多或少而已。

不过不反思，下次依然，至少吧。下次不会犯之前犯过的错误就可以了。


至于说手工测试没前途？不赞同，只不过每个人对软件过程和过程中相关的内容的开悟状态不一样罢了。所以，不必纠结于此了。

jingw19

写用例的时候还得要看看开发的需求文档，要尽量保证功能点不要被遗漏了，这样不管是手动黑盒测试，还是自动化测试，都能很好的发现bug

ailxin

说是测试了那么久， 系统都上线了， 我一直都还没见过系统的需求文档，更别说写测试用例了···

木暖

回复 18# ailxin


    哈哈，我们也是呀，基本上你是看不到需求文档的。就是技术说啥，你测啥，觉得过不去的要不就去问技术是不是这么设计的，要不就去问需求方，您这个需求是这个样子的吗？

   越想越不容易呀。

cleangreen

明白明白很明白一个手工黑盒测试的苦。。因为我也是其中一个，很多时候有着很多无奈，版本发布又提心吊胆的，出现问题就会被说测试不到位。。每修改一个大的问题，都会引起很多关联的缺陷，而且很多都隐藏得很深，测试的时间也时候有限的，人手也是有限的。。。有时对着软件都感觉点到想吐的了。。。所以想学点技术，但是却都从无下手。。。

hangxin06066

明白明白很明白一个手工黑盒测试的苦。。因为我也是其中一个，很多时候有着很多无奈，版本发布又提心吊胆的 ...
cleangreen 发表于 2011-11-21 21:03

    同感。。。。。