如何让软件测试人员发挥最大价值

引言

对于软件测试员（有的公司叫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布局，视觉感观等）；有人认为自动化耗时费力，写自动化的功夫，手工测试都已经做完好几遍了。这些认识都是片面的。自动化测试不是万能的，但没有自动化测试，是万万不能的！对于长时间的压力测试，重复成百上千遍的测试，自动化测试的优势就明显了；但是对于只是UI界面变化很快或者只是一次性测试的场景，还要进行UI界面录制或编写自动化用例，就得不偿失了。

总之，手工测试和自动化测试，要把握一个度，因地制宜，根据产品的特性等方面，进行综合规划，才能达到良好的效果。手工测试是为了发现bug和验证是否满足用户需求，用户体验是否良好；自动化测试是为了回归验证，或者弥补手工测试无法胜任的工作（成千上万的并发操作，持续7*24小时操作，大容量和吞吐量测试，低时延验证等）。两者各有所长，不能顾此失彼，有个微妙的平衡关系，就看管理者如何把握了。

测试人员与管理者的关系

这里的管理者，指测试组长，测试经理，产品经理，公司总裁等能够支配或影响测试人员的管理者。若管理者制定以发现bug数为重要指标，大家就会拼命发现bug，甚至不会放过任何错别字。别高兴太早，这有可能造成拣了芝麻丢了西瓜的局面。既然以数量为指标，估计没人愿意去发现长时间运行造成的内存泄露问题，大并发量造成的响应延迟或拒绝服务等缺陷，因为这些bug发现费时费力，还不如提提错别字或者UI布局来得实在。

所以，要想最大限度地发挥测试人员的价值，管理者提倡什么，大家就会做什么。作为管理者，应当提倡大家创新，改进流程，提高效率，让大家皆大欢喜，而不是让大家每天苦着脸麻木机械地执行测试用例，活干不完就要求大家没日没夜地加班。如果是那样的话，作为管理者，你是在扼杀人才，浪费公司资源，而且你将会面临大量员工流失的问题，最后导致无人干活，进行恶性循环。

作为测试人员，特别是有思想有抱负的测试人员，无论面对什么局面，你在投入执行测试任务之前，一定要想想能否通过开发工具来减少重复的劳动，磨刀不误砍柴工。哪怕一条case提高一秒，100条case也能够提高100秒，你就可以少加班100秒，减少电费100秒，自己支配的生命多了100秒，日复一日的话，又节省多少呢？想想吧，多划算啊^_^

小结

软件测试，不是凡人眼中的”没啥技术含量“，它是软件工程中的一部分，不可或缺。没有万能的软件测试方法，只有最合适自身的测试策略和手段。无论采用什么方式方法，别忘了我们的最终目标：取得产品的商业成功！软件产品在商业上不成功，神马流行的高大上技术（云计算，机器视觉，人工智能，大数据分析等等）都是浮云，当然喽，纯粹搞科研的不在此讨论范围。