引言
对于软件测试员（有的公司叫QA或质量控制员）而言，在不同的公司文化或体制下，往往对自己的职责或定位都会存在很大的差异，导致软件测试员，甚至是公司管理员都存在疑惑： 软件测试员是否真的有存在的必要？如何才能发挥他们的最大价值？
软件测试的目的是什么
什么是软件测试的目的？问题不是很简单吗？但是，我相信仍然有不少人都不一定能够答对。做事没有目标，就会像无头的苍蝇，到处乱撞。船在海中行驶，不能没有灯塔（现在或许有导航仪了，^_^），软件测试，也不能没有目标。对于软件测试员，你执行测试的任务，要达到什么目标？对于管理者，你招收软件测试员，用他们来干什么？要他们发挥什么价值？
下面就是软件测试的目标层次，看你达到了哪层？
第一层：软件测试的目标就是发现软件产品是否存在bug（缺陷或错误）。
第二层：软件测试的目标就是检验软件产品是否满足最终用户需求。
第三层：软件测试的目标是保证软件产品如期按需按质交付，保证产品的商业成功，获取最大利润。
下面我简单分析下各层次的状况。
如果你在第一层，你应该是初入测试行业的菜鸟，不错，就是菜鸟，不管你是否乐意接受。软件测试不仅是发现错误，还有用户需求（包括行业或操作惯例等隐性需求，例如默认 ctrl + c 是复制，若你的文本编辑器非要用它实现关闭程序，那只能留着自己用了）
如果你在第二层，应该在测试行业工作了几年，知道站在用户的角度去验证产品了。保证产品能够满足用户需求，离成功已经不远了，作为测试员，你也已经尽力了。
如果在第三层，你已经跳出了测试员的束缚，能够用管理者的眼光来审视软件测试，至少有几年工作经验或者管理者思维了。这个层次，测试已非测试，测试和开发不分彼此，都是为了产品的商业成功而努力。
软件测试的方法策略是什么
这个就没有统一的答案了，具体问题具体分析，没有放之四海而皆准的银弹。不同的公司（资源，人力，物力，财力等），不同的文化（保守，进取，激进，诚信，严谨，虚伪，欺诈等），不同的产品（移动嵌入式，服务器端，Web前端，桌面应用，单用户，多用户等），不同的产品阶段（预研调研阶段，需求阶段，开发阶段，后期收尾阶段，维护阶段等），所使用的测试方法策略都是不一样的。这么多因素组合在一起，你就知道为何同样是做测试，换个公司或者部门，感觉完全颠覆了你积累的“测试观”，这个是正常现象，如果都是千篇一律，那才怪呢！
但是话又说回来，难道那么多因素，我们就没有方法可循，没有准则可依了吗？凡事都有方法，都有规律可循，以下是我总结的几条经验，仅供大家参考，不当之处，敬请批评指正，欢迎砖头和大棒。
1. 引入自动化测试：对于服务器端要求稳定性高，软件生命周期长，软件需求变化不大，测试用例巨大，操作繁琐易错等场景，引入自动化测试是明智之举，绝对是“磨刀不误砍柴工”。有些公司领导抠门，认为自动化测试开发周期长，自动化测试人员薪资要求高，不舍得投入人力，财力和时间， 只顾眼前利益看眼前成果，匆忙让手工测试占主导。当后续随着测试用例的增加，执行周期越来越长，想搞自动化测试，已经来不及了！
2. 引入持续集成体系：对于采用敏捷开发的团队，持续集成必不可少！甚至可以说，持续集成做到什么程度，敏捷开发的成功就是它的程度。试想一下，若无持续集成，每天提交编译的代码，谁能保证能够运行正常？
有些团队也有持续集成，引入一些工具（Jenkins, CruiseControl, Appache Continuum, TeamCity等），每天能checkin，每天出个DailyBuild，就以为是持续集成了。他们往往忽略了最后一步，也是最重要的一步，那就是持续集成里的自动化测试步骤。可以毫不夸张的说，持续集成的自动化测试是否成功，决定了敏捷团队的敏捷开发是否成功，决定了产品是否能够如期按质按需交付，决定了产品是否能够如决策者预期那样，占领市场先机，取得商业成功。
3. 产品信息要公开明确：此处的产品信息包括产品需求（User Story，性能要求，环境要求，兼容性等），发布计划（包含周期，里程碑，RC，GA等时间点），测试资源（人力，时间，设备等）。有些公司为了所谓的保密，产品需求不给测试人员看（甚至普通开发人员都没权看），导致最终的产品不能满足用户需要，这种情况你还真不能怨测试人员。信息公开明确，便于制定计划，知道哪些测试点，需要多少时间和人力，统一协作（这也是团队精神的体现啊），上下齐心，才能最大限度地保证产品成功。
4. 开发与测试本不分彼此：开发与测试人员，根本不是矛盾和敌对的团队，而是相互依存分工不同的一个团队整体。如果开发与测试团队矛盾重重，一般都是体制奖罚的问题（例如以缺陷数来考核测试和开发的绩效，发现bug多，测试的功劳，开发的污点，反之亦然。），需要管理者深思变革考核机制。纯粹以代码行数，制造和发现的bug数或严重度来考核，真的是很失公允的考核方式，而且会造成开发和测试的矛盾，影响团队的团结。最佳的考核，应该是以项目是否成功来同时考核开发和测试，与公司其他产品比较考核，让大家荣辱与共，大家就团结了（局部团结，有可能会造成所谓的”部门墙“，但总比内讧强很多了）。
5.手工测试和自动化测试相辅相成： 手工测试和自动化测试，就像开发和测试，鱼和水一样，不可分离，相辅相成，才能达到最优效果。
手工测试和自动化测试的关系
对手工测试的误解
一提到手工测试，推崇自动化测试的人员，肯定会露出鄙视的眼神，对手工测试不屑一顾。这种认识是错误的，真正发现缺陷，保证产品质量的过程，手工测试功不可没。就算你是在写自动化测试的case，难道你不需要手动调试一下自动化用例？在调试的过程中，要么发现了自动化测试用例存在问题（或者脚本存在问题），要么发现产品不符合要求（软件缺陷），这个过程，就是手工测试的过程。另外，对于UI布局，视觉感观，音视频同步等QoS，自动化测试是很难发现问题或不易实现的。
对自动化测试的误解
对于自动化测试，有人爱有人狠。有人认为自动化测试是万能的，什么都要实现自动化测试（UI布局，视觉感观等）；有人认为自动化耗时费力，写自动化的功夫，手工测试都已经做完好几遍了。这些认识都是片面的。自动化测试不是万能的，但没有自动化测试，是万万不能的！对于长时间的压力测试，重复几百上千遍的测试，自动化测试的优势就明显了。
困难与折磨对于人来说，是一把打向坯料的锤，
