软件测试工作的多种可能性

软件测试工作的多种可能性

很多做测试的朋友问过这样一个问题：“现在敏捷开发模式中，自动化测试那么流行，而且连开发人员都开始做测试了，是不是以后就没有测试人员了?”

其实我在这里可以肯定的告诉大家现实并不是这样的。

首先我们需要讨论的是分工的问题。

人类的工业化生产最初也是不分工的，但随着生产技术的复杂度提升，以及对于生产效率的更高要求，产生了分工;同样对于软件开发来说也是一样，最开始并没有测试人员和需求分析人员，而都是开发人员。也是随着软件项目的复杂度以及要求的提高，慢慢产生了工作种类的区别，由此产生了专门做测试的人员，也就是测试人员。

由此看来，并不是有了测试人员这样一个职位，才诞生了相应的工作和职责，而恰恰相反;那如果想取消这个职位，但是相应的工作和职责并没有消除，在我看来无非就是把这个职位换一个名称，或者是和别的职位的工作与职责重新排列组合而已。

其次我们需要明确什么是测试的核心，是自动化测试，还是测试报告，亦或是探索性测试呢?其实都不准确，我认为测试用例设计才是软件测试的灵魂。

没有恰如其分的测试用例设计，软件测试很容易误入歧途：导致没有目标的盲目测试，不考虑投入产出比的自动化测试，不从全局优化的、割裂的单元测试、集成测试和系统测试等。

测试用例设计也是需要熟练运用测试用例设计方法，并且结合测试人员的经验和智慧才能设计出来的，这同样是测试人员不同于软件开发团队中其他角色，需要不断积累的关键一点。如果说在敏捷开发模式中，开发人员可以完成单元测试和自动化测试，业务分析人员也可以进行探索性测试的话，测试人员唯一不能被取代的就是测试用例的设计。如果说描述得更全面一些，即使要让别的角色替代测试人员，至少他们也需要具备测试用例设计的能力，而这种能力需要长时间的锻炼和运用才能具备。

最后，虽然测试工作并不会消失，但是测试人员也需要进化，需要跟随新的软件开发模式，不断学习，不断进步，保持自己的必要性和特殊性。

举例来说，在敏捷开发模式中，测试人员不仅仅是根据需求编写测试计划和用例，并且手动执行，给出测试报告就好了。而是需要测试前移，在需求分析阶段尽可能地发现和预防问题，在开发过程中避免问题的产生，并且通过问题分析指导开发方向和改进措施;同时需要测试范围扩大，不仅需要覆盖软件开发阶段，还需要覆盖产品上线部署以及运维的相关活动，甚至是通过分析用户反馈来提高产品质量。

可以看出敏捷中测试人员的任务和职责更多了，这就需要我们更加发挥自己的聪明才智，更高效地分析和解决问题，更快速地学习各项技能，同时注重各项实践的运用。