大佬谈涨薪之路：测试这一岗位究竟每天都干什么？

lsekfe

我们在变化中成长。假设你拒绝了变化，你就拒绝了新的美丽和新的机遇。模拟软件测试工程师工作场景！！

　　初始软件测试
　　“这是一个杯子，主要用来喝水的，它的质量应该如何考量？”
　　这是在进入上家公司面试时，测试主管问我的题目，相关的回答已经有点模糊，但从这个问题可以大概了解到，测试主管在考察我的测试思维。
　　首先，这个杯子的质量包含哪些方面？即通常所说的需求是什么？如显性需求，首先应该是杯子，不是瓶子、罐子等，用途是喝水的；隐性需求呢？那就比较笼统了，如大小、高度、容积、制作材料、温度承受范围，还有一些其他细节如颜色、边角圆滑等。
　　其次，如何去准确获取、表现这些需求，即相关指标数据是多少。如要知道大小、高度、容积，得用到相关测量工具，如尺子、圆规。要知道温度承受范围，可能要用到温度计等。
　　在完成测试工作期间，测试设计、执行之前必须清晰了解原始需求（包括隐性需求），再之后需要有对应的测试方案，需要执行哪些类型测试，要用到什么测试工具等。
　　很感谢当初测试主管对我测试工作的指导，不仅仅是在具体的技能培训上，还在其他的工作当中对我测试思维的引导。

　　功能测试实践
　　面试过后进入公司，最开始接触的项目是国税门户网站，所进行的测试工作是主要是功能测试，如测试用例编写、执行，测试报告反馈。当时对所谓的软件生命周期都很模糊，感觉我只要做好自己的测试任务就好了，其他的东西由上级安排就好。现在想想真的好白，白痴的白。
　　在接下来的一年时间，让我真正接触到了项目开发、交付的实际生产过程，简而言之就是，工作任务是无止境的，永远有数不尽的需求要开发、测试，有茫茫多的Bug要跟踪。如何在这中间保持自己清晰的定位显得至关重要。由于在项目组中只有我一个测试人员，那么结果就是，“测试的事情就都是我的”，好像很厉害的样子。但我还只是小白啊。
　　“某某某，过来一下，这是这个版本修改的内容，大概是要在某月某日完成，你过（看）一下。”
　　“哦”。
　　到了测试执行，发现问题后提交给开发同事，开发回复：“设计如此。”
　　“哦”。
　　快要上线了，项目经理问：“某某某，现在系统的测试情况怎么样，能不能上线？”
　　“应该差不多吧”......

　　项目实践后续
　　测试主管了解之后，跟我强调了几点：
　　1、测试的依据，需求基线要清楚，要尽早参与；
　　2、测试要有计划方案，要有用例设计，不能随意的开展；
　　3、Bug的跟踪，要有自己的主见、原则；
　　4、测试结果的把握，要有结果分析。
　　项目的上线，要综合你的以上测试过程，结合目前的情况总结报告，甚至是项目经理也要听取你的意见。你的角色不仅是测试，也是质量保证。
　　当然，以上的情况只是测试中遇到问题的一点点，如沙漠中的一粒沙（这孩子究竟怎么过来的），但也让我认识到测试是独立的、重要的。
　　在后来的项目测试工作中，践行测试主管传递的思想原则的同时，我并行了解相关测试书籍、工具、技能，结合工作进行相关实践，逐渐地我的测试能力越来越强。
　　在省国税外派了一年，之后测试过程中更加有条理、原则、规范。但也仅是个人自觉的约束，很多过程并没有按照软件开发周期的标准来执行，如测试用例、测试报告有时候会在发布版本后才编写（虽然公司也通过了CMMI3），即测试的质量保证更多的依赖个人的素质。
　　并且，当时个人认为测试的业务熟练更多决定于对系统功能本身的熟悉和测试设计执行的熟悉，认识到错误并且有意识改变是在地税的定点联系企业管理系统和电子办税服务厅的测试过程。
　　之后，进入到地税的定点联系企业管理系统项目组进行测试。当时项目已快要进入验收阶段，甲方要求的功能基本都有实现，但在交付时甲方却不满意，在一些功能的易用性和系统界面展示上提了很多要求，导致整个系统最后框架、原型都换了一遍，而且限定修改的时间很短（又是一个加班加点的开始），最后甚至项目负责人都换了。

　　总结工作中的问题
　　1、既定清晰的需求都有按要求实现，只不过实现方式不合甲方胃口，如图表不够丰富，只有概要，没有详细。
　　2、系统界面没有统一的样式，甲方不客气的说像草稿。
　　3、流程没有体现甲方日常工作内容、步骤。
　　4、风控系统很肤浅，指标不实用。
　　走过堤岸，有依依杨柳，迈入田野，是无边麦浪。人总会经历不同的旅途风景，在变化之间获得不同的成长见识。
　　第一份工作经历形成了我对测试的基本认识及工作方式，接到测试任务之后就会条件反射的设想需要开展的测试类型，相关方案。但对于这些工作是否可以更标准化、工程化的开展还只是一个朦胧的概念。
　　之后重新更换测试工作，工作开始并没有什么不同，只是测试执行之前要求必须编写测试用例。但随着时间的推移，让我体验到了不一样的氛围。
　　测试要尽早开始，并且排除随意性，有计划的进行，这是软件测试基础理论的原则之一。在公司，软件开发过程有比较完善的流程，期间测试人员要经过需求评审、测试用例评审、预测试评审（提交测试前的评审，由开发演示实现的功能）、测试报告评审等。在需求评审之后，要有详细的测试分析、用例，并且列入任务计划进行监控，用例的执行结果也可随时查看，了解测试进度。
　　落地手工功能测试的同时，我们在持续进行自动化功能测试和性能测试工作。

　　测试观点分享
　　很容易发现，以前是一个人在摸索中战斗，不断的爬坑的测试过程，现在是工程化、自动化的在持续推进优化改进的过程。个人对体系趋势，优劣不言而喻。
　　以下是个人测试经验中的一些观点：
　　1、尽量把测试往前推，尽早发现，降低修复成本；
　　2、测试的目的不是发现Bug，而是预防Bug的发生；
　　3、通过各种技术手段和流程改进，逐步的解放公司内部测试人员，让他们把精力放在对产品的把握上。
　　当然，不管有多好的工作起点平台，测试人员的素质才是决定最终测试质量的保证。在从原有重复的工作方式中解放后，测试人员的综合素质如所处行业知识、测试思维、测试设计方案都影响到具体的测试结果，这些都是工具、平台无法取代的。

　　作为过来人的一些忠告
　　最后，作为过来，给所有测试员一些忠告~~一名测试员，你真的不该只会点点点~随着软件开发体系的改变，对于现在的测试人员来说，不是自动化或者代码有多重要，而是懂自动化，懂代码，能够理解系统的实现，已经变成了必备技能。并且很多初学者很纠结，自动化测试工具那么多，比如QTP、selenium、jmeter、postman、LoadRunner等等。