我们在变化中成长。假设你拒绝了变化，那么，你就拒尽了新的美丽和新的机遇。
初始软件测试
“这是一个杯子，主要用来喝水的，它的质量应该如何考量？”
这是在进入上家公司面试时，测试主管问我的题目，相关的回答已经有点模糊，但从这个问题可以大概了解到，测试主管在考察我的测试思维。
其次，如何去准确获取、表现这些需求，即相关指标数据是多少。如要知道大小、高度、容积，得用到相关测量工具，如尺子、圆规。要知道温度承受范围，可能要用到温度计等。
在完成测试工作期间，测试设计、执行之前必须清晰了解原始需求（包括隐性需求），再之后需要有对应的测试方案，需要执行哪些类型测试，要用到什么测试工具等。
很感谢当初测试主管对我测试工作的指导，不仅仅是在具体的技能培训上，还在其他的工作当中对我测试思维的引导。
(海量免费学习资料，软件测试交流群：175317069，还会有同行一起技术交流)
功能测试实践
面试过后进入公司，最开始接触的项目是国税门户网站，所进行的测试工作是主要是功能测试，如测试用例编写、执行，测试报告反馈。当时对所谓的软件生命周期都很模糊，感觉我只要做好自己的测试任务就好了，其他的东西由上级安排就好。现在想想真的好白，白痴的白。在接下来的一年时间，让我真正接触到了项目开发、交付的实际生产过程，简而言之就是，工作任务是无止境的，永远有数不尽的需求要开发、测试，有茫茫多的Bug要跟踪。如何在这中间保持自己清晰的定位显得至关重要。由于在项目组中只有我一个测试人员，那么结果就是，“测试的事情就都是我的”，好像很厉害的样子。但我还只是小白啊。
“某某某，过来一下，这是这个版本修改的内容，大概是要在某月某日完成，你过（看）一下。”
“哦”。
到了测试执行，发现问题后提交给开发同事，开发回复：“设计如此。”
“哦”。
快要上线了，项目经理问：“某某某，现在系统的测试情况怎么样，能不能上线？”
“应该差不多吧”
......
测试主管了解之后，跟我强调了几点：
1、测试的依据，需求基线要清楚，要尽早参与；
2、测试要有计划方案，要有用例设计，不能随意的开展；
3、Bug的跟踪，要有自己的主见、原则；
4、测试结果的把握，要有结果分析。项目的上线，要综合你的以上测试过程，结合目前的情况总结报告，甚至是项目经理也要听取你的意见。你的角色不仅是测试，也是质量保证。
当然，以上的情况只是测试中遇到问题的一点点，如沙漠中的一粒沙（这孩子究竟怎么过来的），但也让我认识到测试是独立的、重要的。
在后来的项目测试工作中，践行测试主管传递的思想原则的同时，我并行了解相关测试书籍、工具、技能，结合工作进行相关实践，逐渐地我的测试能力越来越强。
在省国税外派了一年，之后测试过程中更加有条理、原则、规范。但也仅是个人自觉的约束，很多过程并没有按照软件开发周期的标准来执行，如测试用例、测试报告有时候会在发布版本后才编写（虽然公司也通过了CMMI3），即测试的质量保证更多的依赖个人的素质。并且，当时个人认为测试的业务熟练更多决定于对系统功能本身的熟悉和测试设计执行的熟悉，认识到错误并且有意识改变是在地税的定点联系企业管理系统和电子办税服务厅的测试过程。
之后，进入到地税的定点联系企业管理系统项目组进行测试。当时项目已快要进入验收阶段，甲方要求的功能基本都有实现，但在交付时甲方却不满意，在一些功能的易用性和系统界面展示上提了很多要求，导致整个系统最后框架、原型都换了一遍，而且限定修改的时间很短（又是一个加班加点的开始），最后甚至项目负责人都换了。
总结了下，有几个方面问题：
1、既定清晰的需求都有按要求实现，只不过实现方式不合甲方胃口，如图表不够丰富，只有概要，没有详细。
2、系统界面没有统一的样式，甲方不客气的说像草稿。
3、流程没有体现甲方日常工作内容、步骤。
4、风控系统很肤浅，指标不实用。
在这个测试过程中，我比较正式地参加甲方组织的各种需求讨论会议，期间也认识到原始需求到需求基线其实还是有设计落实过程的，其把握的度就要看负责人或产品经理的灵性了。作为测试人员，在需求评审过程中就要对比原始需求（要详细了解具体日常工作内容，行业特殊性等）和需求基线的不同，给予自己的意见，在测试过程中不时提醒自己。而对需求的理解是否深刻，有时候不是参加正式需求评审就能达到的，还需要深入到用户实际的工作场景，了解实际业务和流程。而对于自己无法准确把握（风控系统），用户又无法准确提供的需求就要定好界限，实现到什么程度。最后，好用的软件不仅是功能的实现，一个界面样式都能让你从头再来。原计划短期内交付的项目，由于后续各种修改需求一直到了次年3月，才基本结束相关测试活动。
完成定点联系企业管理系统的测试之后，我进入了电子办税服务厅项目组，在这里个人的业务掌握程度得到认可。首先，对核心系统（电子办税服务厅接口调用提供方）的相关业务（文书、申报等）熟悉，并与对应系统的中软项目组人员都可以打成一片（也是吸取在陕西时沟通不顺的教训，详细后面性能测试提到）。其次，对电子办税厅的需求理解充分，得益于当时的需求人员耐心引导（为了税务事业，头发都花白了的同事），最后是自己对相关系统的后台数据表结构都比较熟悉。出现问题之后，能快速的理清思路，定位原因。问题出现之后，当你有理有据的跟相关负责人沟通时，他们也会心悦诚服。在经过一年多的团队配合之后项目组启动跟金三对接工作（要2个月完成，又是看星星赏月亮的好时光），项目经理将接口联调的任务交由我负责，也是看在我对原有两方系统及人员的了解。
(海量免费学习资料，软件测试交流群：175317069，还会有同行一起技术交流)
性能测试实践
测试当然不仅有功能测试。第一次接触性能测试也是在国税门户项目组，只不过测试对象不是国税门户网站。其实那个软件系统的具体业务我都不太清楚（惭愧），只知道是叫一户式查询系统。当时虽然了解过性能测试的原理，但是具体如何开展还是有点懵逼。在测试主管的协助指导下（说是一步一扶都不过分），艰难完成。
在此，额外截取下当时某个业务场景测试的结果数据（没有找到曲线图了，发一下当时用表格记录的数据，你没看错，是5并发时间95s！！！）
执行这次测试之后，了解到同性能测试如下相关信息：
1、系统的部署组成，相关的服务器有哪些（此时还不知道具体的网络拓扑结构）。
2、相关场景的选择依据。
3、工具的使用，脚本的录制。
4、主要性能指标。
5、基于工具结果的简单分析。
原谅我当时的简单朴素，能把握的就这些了。
后续的项目测试过程中，也有从事性能测试相关经历，如税企通项目（C/S架构）、省国税门户网站等，但真正让我记忆深刻并且获益良多的是地税的网上申报项目。
网报项目的相关合作方有多个，网络、防火墙、CA认证服务、核心申报等分别是不同的公司负责交付，如果测试过程中有出现问题，往往不好定位是谁的责任。
在这种情况下，了解系统的网络部署拓扑结构尤为重要，之后才是具体的测试场景开展。
具体的测试场景开展：
1、熟悉了解网络拓扑图，相关机器、服务器的物理及网络部署，为之后进行分层次测试做好准备。
2、并发数的计算，按照计算公式C=nL/T（C代表并发数，n代表平均在线人数，L代表场景操作时间，T代表场景考察时间）是比较理想化的，由于项目并没有相关措施监控，因此难以获取到平均在线人数、操作时间等具体参数。这时就要结合实际系统使用情况考虑。如系统纳税人总数及申报总数，每月申报时间（1日到15日，一般最后一周或者3天为大多数），每天申报时间（上午9：00-12：00以及下午14：00-17：00）等信息去计算出每秒事务吞吐量即可得到并发数（事务吞吐量*业务场景时间）。
3、根据实际业务选择需要测试的业务功能场景。
4、性能测试场景，如系统最大并发数，单个节点最大并发数，不同网络接入点最大并发数，稳定性测试等。
5、其他指标如响应时间、资源使用。
......
确定以上方案和指标之后再进行具体的准备和执行。
执行过程中，当然不会那么顺利，开始从系统最外围即外网进行测试，结果不理想，那么就要定位原因，过滤出指标差的业务场景，然后单独测试，此时相关场景加上时间戳信息，再在各个服务器上采集日志，之后为了确认真实，再更换不同服务器地址进行测试对比不同接入点的结果。最后再拿具体的结果给对应的合作方讨论分析。
整体的设计方案执行下来，花了不少的时间。
具体执行测试时，公司内部的功能还算顺利，到分层测试时就比较麻烦。第一是需要在不同的办公地点进行（不能直接访问IP），项目组办公室、税局机房、联通机房等，还记得在机房呆过一个晚上之后，汗渍都是绿的。遇到问题找合作方沟通时，响应速度跟指标差的场景一样--慢。当然，自己的沟通方式也是有缺点的，比如跟合作方说你的系统有问题，不能仅是口头形式，要包含具体证据（报错日志、测试结果报告等），并且定下解决时间，必要时还需要甲方在场。
但不管如何，最终是完成了原定的测试目标。过程是艰辛的，但让我在今后的做事方式更加有条理、按步骤、踏实、耐心。
变化中成长
走过堤岸，有依依杨柳，迈入田野，是无边麦浪。人总会经历不同的旅途风景，在变化之间获得不同的成长见识。
第一份工作经历形成了我对测试的基本认识及工作方式，接到测试任务之后就会条件反射的设想需要开展的测试类型，相关方案。但对于这些工作是否可以更标准化、工程化的开展还只是一个朦胧的概念。
之后重新更换测试工作，工作开始并没有什么不同，只是测试执行之前要求必须编写测试用例。但随着时间的推移，让我体验到了不一样的氛围。
测试要尽早开始，并且排除随意性，有计划的进行，这是软件测试基础理论的原则之一。在公瑾，软件开发过程有比较完善的流程，期间测试人员要经过需求评审、测试用例评审、预测试评审（提交测试前的评审，由开发演示实现的功能）、测试报告评审等。在需求评审之后，要有详细的测试分析、用例，并且列入任务计划进行监控，用例的执行结果也可随时查看，了解测试进度。
落地手工功能测试的同时，我们在持续进行自动化功能测试和性能测试工作。
在很多公司看来，自动化测试是一个比较矛盾的事情，总要考量人力消耗和迭代发布版本维护原有脚本的成本。在没有建立自动化测试体系前，只能沦为个人兴趣或者形式。
我们的自动化测试工作到目前已经走过2年时间，自动化功能测试覆盖率达到95%以上，期间进行自动化测试的同学经历了从无到有，再到完整，并且常态化执行。现在使用Selenium分布式运行多台设备上的脚本，可以快速执行完原有功能的测试用例。在业务功能越来越复杂，测试用例越来越多的情况下，功能自动化测试的地位就越明显。
而对于性能测试，也变得相对易于开展。相关系统的用户使用场景数据可以轻松获取（比如并发数计算），测试执行也已经形成了一个常态化机制，不是经过某次测试之后就不再进行，或者优化后再次测试还需要人工再做一次。目前的接口性能测试和系统性能测试在确定业务场景和脚本后，具体的运行设计方案为自动每天执行，执行结果通过报表（不是测试工具本身的报表，而是测试结果保存到数据库后按照要求重新整理输出报表）展现，相关负责人可以通过结果进行选择性优化，然后再继续测试。
不管是功能自动化测试，还是接口、系统性能测试，我们都已实现工程化、自动化的工作方式，也践行了软件测试中经常提及的测试应该要持续进行的原则。
很容易发现，以前是一个人在摸索中战斗，不断的爬坑的测试过程，现在是工程化、自动化的在持续推进优化改进的过程。个人对体系趋势，优劣不言而喻。
绵薄之力
做为一名自动化软件测试，接下来我想分享一下这些年来，我对于技术一些归纳和总结，和自己对作为一名高级测试者需要掌握那些技能的笔记分享，希望能帮助到有心在技术这条道路上一路走到黑的朋友！
下面分享我整理的这份2021年可能是最全的软件测试工程师发展方向知识架构体系图。
一、Linux必备知识
Linux作为现在最流行的软件环境系统，一定需要掌握，目前的招聘要求都需要有Linux能力。
二、Shell脚本
掌握shell脚本，包括shell基础与应用、shell逻辑控制、shell逻辑函数等。
三、互联网程序原理
自动化必由之路：前端开发基础知识以及互联网网络必备知识。
四、Mysql数据库
软件测试工程师必备Mysql数据库知识，不仅仅停留在基本的“增删改查”。
五、抓包工具
Fiddler、Wireshark、Sniffer、Tcpdump各种抓包工具适用于各种项目，总有一款适合你。
六、接口测试工具
接口测试神器，你绕不开的强大工具：Jmeter。小巧灵活：Postman。
七、Web自动化测试Java&Pyhton
了解自动化的目的，熟练掌握testng&unittest自动化框架，以及断言与日志处理。
八、接口与手机自动化
专业接口调用、测试解决方案。组建完整的web和接口自动化框架，Appium整体使用。
九、敏捷测试&TestOps构建
揭开TestOps的神秘面纱，持续集成Jenkins框架烂熟于心。
十、性能测试&安全测试
软件测试的彼岸：性能测试和安全测试，选对方向，努力爬坑吧！
上面就是我为大家整理出来的一份软件测试工程师发展方向知识架构体系图。希望大家能照着这个体系在3-4个月完成这样一个体系的构建。可以说，这个过程会让你痛不欲生，但只要你熬过去了。以后的生活就轻松很多。正所谓万事开头难，只要迈出了第一步，你就已经成功了一半，等到完成之后再回顾这一段路程的时候，你肯定会感慨良多。
看完这篇内容后，相信以下两件事，也会对你的个人提升有所帮助：
1、 点赞，让更多人能看到这篇文章，同时你的认可也会鼓励我创作更多优质内容。
2、 让自己变得更强：想一想，如果你想在测试这个行业一直做下去，你的经验和测试技术是远远不够的，你需要进阶，你需要丰富你的技术栈！还等什么！
最后:【可能给予你助力的教程】
这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。
关注我的微信公众号：【程序员小濠】就可以免费获取了~
加入我的学习交流群：175317069一起交流分享~群里也有不定期的学习视频和学习资料发放!
如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！