如何才能做好手工测试
首先，我想的是，什么是“技术含量”。我觉得，一般指的有“技术含量”的，是你能做别人不能做，或者你完成目标比别人快的多的事情，如果随便一个人很快能上手完成你所做的工作，不算有技术含量。好像只把伪代码转换为语言的程序员，有多少“技术含量”?从这个角度上看，很多人觉得“手工测试没有技术含量”不足为奇了，因为如果按照用例去执行，给出明确的预期结果，谁都应该知道用例执行是通过还是没有通过。那如果不是用例的执行而是去设计，而是编写用例呢?给出一个功能点，每个人是否都能快速的设计出有效的测试用例呢。答案一般是否定的，少同一个公司，有的人写的快，有的人写的慢;有的人考虑的周全，思路很清楚，有的人写用例和不写用例一样，想到哪写哪。测试用例的设计总该算是有“技术含量”了吧，不懂业务的，熟悉业务要很长时间，不晓得逻辑方法的，肯定先要把逻辑弄清楚。
再次，不管什么工作，什么事情，只要能持续的做的深入，总会有能力上的提升。(个人认为，能力包含技术，还有技术以外的东西)对于测试来说，如何定位一个问题，可以做的很深。上次参加那个交流会，会上某公司的主管说了一个例子：“假设我们测邮箱发送4M的附件发送失败，一种做法是直接把附件给开发，说这个附件不能发送;还有一种做法是将问题进行细化，是文件格式的原因，文件大小的原因，还是后只是文件里包含了不合法的字符。”如果是后一种，问题解决起来也快，开发也愿意配合，自己也能提升技能。的确，一开始细化问题的时候，会很费力，但是“火车刚发明的时候比马还慢”，当你能力提升了以后，会发现处理问题会越来越顺手。(如果碰到无法理解的问题，肯定要给开发，不能自己转牛角尖，但是开发修正后，可以去问是什么问题，怎样修复的。)说句比较考张的话，把平凡的测试变为不平凡的分析去做~
后，说其他方面的成长。我们肯定很明白一点，测试不是凭想象，想怎么测，怎么测的，总是在开始测试之前，先把思路理清楚，测试的策略想清楚，于是锻炼了思维。我们总是在描述bug的时候，担心开发看不懂，每次以他人的眼光来审视写的bug，是否有歧义，复现的步骤是否更直白，语句是否更简练而清楚，顺带着，是否有截图和图上重点的标示，于是锻炼了文字描述。我们总是会和需求人员确认需求，和客服人员确认客户问题，和开发确认缺陷问题，于是我们锻炼了沟通。也许有人会不认同这也是一种收获，那可以问问自己，我们有没有测试到一半，发现漏了功能点，重新回头进行测试的情况;我们有没有写bug后，开发看不明白，打回的情况;我们有没有根本没有了解到客户的真正问题，马上去解决的情况。。。。
任何工作，当想有没有前途前，想想自己为此付出了多少。如果做自动化或性能，只会简单的入门，而不去深入，我想也不会有“前途”吧。注:本文出自ermine的51Testing软件测试博客：http://www.51testing.com/?272597
