五年软件测试生涯

我的正式职业生涯是从做测试开始的，一做就是五年，当时公司的官方名称叫做系统工程师，这个官方叫法估计是打算让该角色有全局观念。因为在大公司，分工比较细，自己就是那一颗颗小小螺丝钉，但这并不意味可以做的事情很枯燥。那个时候，整个公司全面推广敏捷，敏捷项目和传统的瀑布模型差距还是挺大的，这个从公司底层往上推进比较有难度，而我所在的欧美外企则是从上往下推行的，这些前沿的思想和方法，老外还是比较敢于尝试的。一般的做法是先找几个先驱团队试点，成功后再推广。

测试也是需要敏捷的，敏捷软件测试的书也逐步流行，倒三角测试理念在我的实力派组长的带领下推广得风起云涌。我们的敏捷迭代是这样的：每次大版本做两个月，做两个开发迭代和一个发布迭代。测试人员在开发地方负责团队测试策略制定、测试用例设计、测试用例评审组织、手工测试执行、自动化测试编写、联调用例安排、持续集成维护、不同团队联调、缺陷跟进、测试环境维护、测试报告同步等。当然，整个项目团队会统一测试策略，但允许不同团队有不同的做法，毕竟每个团队、每个团队的人、团队的成熟度也是不一样的，而且团队的氛围与小组长的领导力关系也不小。在发布迭代中，注重跨团队的系统测试，包括功能和非功能层面的，安排回归测试，修复严重问题，准备文档等各个层面的评审，对外联调和上线准备等。

我就是在这样的背景下进入开发团队，负责驱动团队测试工作的推进。当初的小组长人非常和蔼，也非常刻苦，是团队的主心骨，技术牛人，团队新人不少，但整体素质都比较高，所以这样一个人人都有责任心的团队难免自管理性特别强，所以对我来说也比较好适应。这样的团队人人可我组织站会，轮流Scrum Master，可以带着自己的想法去组织迭代优化，有演示和回顾，做法真的很标准，每个迭代都可以有分享，正所谓不仅仅是锻炼专业能力，也锻炼项目管理能力等。当初的测试流程是这样的：产品经理和架构师前期调研—产品经理需求分解成用户故事，排列优先级，并初步估计工作量－团队选择用户故事—两次计划会议理解并确认需求，分解成任务并评估开发测试工作量—测试用例设计、测试数据与开发代码单元测试同时进行—开发和测试编写手工和自动化用例－调试完成自动化用例放入持续集成环境—团队测试－修复问题文档准备—回归验证并保持持续集成绿色－演示需求，贯穿其中的是一个检查列表，开发和测试完成标准都比较明确，需要团队产品经理、负责人和测试一起完成该列表并与项目经理确认。很多事情都可以并行做，持续快速高速迭代。

进入系统测试迭代后，一方面兼顾需求学习，更多的是做系统验证，比如跨团队回归测试，比如与外部系统集成测试，比如生产环境部署，比如安装文档验证，编写系统测试自动化用例等，这些都是工作的一部分。有些同时会用系统测试包继续跑性能测试和稳定性测试，这也算回归，毕竟性能测试也是可以在迭代中同步进行，但因为代码在不停地变化，就需要同时回归了。

上面说的是日常主要工作，当然还得注意不停地学习新技术，比如自动化框架、业务知识、系统知识，不断提高自己的软技能，与团队共成长。开发人员需要掌握的技术，诸如数据库、安全、云计算、并发、缓存、散列法、算法的复杂性、分层、惯例与模板、界面、模型化，测试人员也要了解，尤其是测试开发工程师，有很多机会写代码的。

从个人的经验上看，一个好的测试工程师需要具备良好的测试设计能力（有很强测试意识）、具备自动化框架和用例撰写的能力、具备性能测试和典型场景的深入分析问题的能力，我相信无论在瀑布时代还是敏捷时代，都是不会失业的，而且可以做得很好。再加上必要的细心、耐心和责任心，没有理由做不好测试，没有理由不出色。加油吧，奋战在一线的测试工程师，相信你们会越来越棒的。掌握测试设计、测试自动化、非功能测试，走遍天下都不怕！