工程师新项目上线时间

互联网和传统行业的不一样，变更多，迭代快，测试工程师们能大噶说一下吗？还有，怎么样才能提高自己的价值呢？ 精彩答案： 会员jijiting： 抛砖引玉，了解皮毛而已。 测试要做的是，检测和监控产品的质量，提高测试效率，优化测试流程，改善评测办法，为产品的改进和上线提供保障。 测试工程师大概在做： 1、功能测试：包括和开发、产品确认产品需求，做测试计划，设计测试用例，做测试用例评审，做冒烟测试或者准入测试，执行测试用例，多轮迭代测试，一直跟踪到上线之后的回测，以及看下用户的反馈，确认测试过程中有没有遗漏（算作是KPI的一部分）。在这个过程中，可以反思自己的疏漏，完善测试的流程，完善测试的检查点，增加各种类似的测试，思考可以自动化的部分并实现。 2、自动化测试：对界面、接口或者后台进行自动化的测试，在测试的前期可以保障基本功能的正常，在测试中期可以保障开发的修改没有对产品质量引起严重问题，在测试的后期可以做上线前的回归测试，上线之后可以作为日常的监控。自动化的测试在不同平台、不同操作系统、不同浏览器下使用不同的工具，采用不同的框架，所以在没有这些的时候需要调研目前行业内比较流行的解决方案，寻找到适合自己产品的方法来解决问题。之后开始设计测试用例，并进行实现。产品的改进过程中需要进行维护，保证随时都可以通过。 3、性能测试：测试产品的性能，在多大的压力下可以满足当前预期的用户请求。需要使用各种压力工具，做压力文件，安排与线上一致的测试机器或者精简后的环境进行测试，对测试出来的数据进行分析，确认现有的系统是否存在问题。貌似环境部署可能是个问题，所以公司里面会有大牛做一些自动部署的工具，甚至会开发出一些独立的平台来完成多台机器的部署工作，可以节省很多的时间。测试出来的数据跟产品以及开发人员确认，也可能会找到一些方案来解决。 4、测试开发：相对来说开发的工作比一般测试工作要多一些。开发一些自动化的测试的平台，比如一些评测系统，供人工评测试用；设计一些测试框架，来满足日常自动化以及性能测试的需要。制定持续集成测试的平台和方案并且实现，结合自动化的测试实现人工测试之前的自动化测试实现，对开发的代码进行监控，跟踪并尽量帮开发改进产品质量等等。这块我比较白，还在仰视阶段。接受其他测试人员的需求，开发合适的工具来提升整体测试效率，改进测试方法。 5、测试工具以及测试理念的推进。测试在大多数人看来还是比开发要差一些的，测试工具还可以，能够直接快速的反映出测试人员的价值，但是更多的功能测试、性能测试还需要跟开发去沟通，让他们意识到测试的重要性，但是最重要的还是要提升测试自己的工作能力，尝试影响开发人员并且和开发人员一起，最终提升产品的质量。 6、测试人员还是要多学习吧。要是觉得测试是个人都可以做的就别来趟这个浑水了。 会员 姜雷： 我当时是做实习生，实习生的时间比较自由，也没有具体的产品、KPI捆绑，所以我做的主要是没有具体产品关联的长线项目。比如说自动测试平台的搭建，测试自动化辅助工具的开发，原有测试脚本的集成、改写、自动化等工作（比较杂，有些随性，我甚至写过单元测试——这个应该是dev做的）。还有就是一些具体的模块覆盖率的提高、测试自动化的探索。 具体到身边的入职同事们，工作就比较杂了。忙起来的时候，是黑盒、白盒；自动化、手动的都要做。项目上线之前的功能、性能、压力测试等都是必要做的，由于目前国内互联网发展较快，项目改进迭代的压力很大，所以有的时候感觉身边的同事都被项目纠缠得忙——这就是为什么上下一心都觉得自动化很重要。 当然，还有些人专门做测试工具的开发和测试流程改进的探索，我当时所在的部门也开发了很不错的自动化测试工具——这应该是我接触过的最接近开发的测试开发人员了。 我实习的组测试人员比较主动，去做了一些项目敏捷化的探索，还主导了项目的敏捷化，但是开发人员那边跟进得并不是很积极——我个人认为这个应是开发人员主导的，而且整个团队都参与进来，各个人员的角色需要有交叉——可惜我在实习期间没有体验到这些，这个在形成了一定的规模的国内公司估计很难改变。我实习结束的时候，有些组在流程上已经非常敏捷、自动化了，但是毕竟是上线的产品，自动化的初期肯定有一定的阵痛，估计现在应该好多了。 另外，谈谈我个人的一些感受，如果专门做测试的话，我觉得最大的问题就是成就感的问题。你做的似乎永远只能是内部使用的东东，永远不会成为呈现在用户面前的产品（gtest等测试框架产品除外）。当一个项目上线以后，你得到的relief多一些，但是成就感相对少一些。 我只是从实习生的角度谈的。

跟他讲讲项目上线的定义以及自己如何保障上线后的更新迭代、维护呗。项目上线是项目的里程碑性标志节点，为保证项目上线在前期需要做好充分的准备工作，同时也需要建立有效的回滚机制，保障项目如果上线失败能够快速还原保证客户使用是有效的、稳定的，不影响用户的日常办公与生产。 环境备份在上线前需要对项目的环境进行备份处理，尤其分步上线或者已有上线工作，做好环境备份，便于快速回滚、即便失败也能快速还原，避免因为上线工作影响客户日常的办公及生产。如：某些行业/企业对于平台的要求较高，不能以客户的停产作为项目上线失败的代价。同时将项目上线过程中的问题记录、汇总，为下次项目上线累积经验教训。 脚本更替以脚本的方式实现平台的更替及功能的更新，便于当上线出现问题后，快速还原。同时结合脚本的方式也便于后续的维护，如：服务器一键重启，集群环境部署待建，集群环境自启动等。编写shell脚本代替人工操作，提高工作的准确率及工作的效率。 迭代上线项目上线，不强调是全部准备好进行平台性整体上线，而是结合工作的推进和进展实现迭代上线。前面上线的工作作为后续上线功能的支撑，后面上线的工作作为前面上线的升级。项目上线后伴随用户的使用的频度、习惯等或多或少会有些调整、建议，这时项目团队需要能够快速迭代上线满足用户的使用需求。

引言 软件测试成为最近 IT 行业的“香饽饽”，引得很多人对软件测试跃跃欲试。可是软件测试的门槛并不低，对于没有软件测试经验的新人而言，如何尽快转入测试工作中去呢？ 了解软件测试都做些什么，具体过程是怎么进行的，可以有助于对软件测试进行初步了解，尽快进入测试工作角色。但是关于软件测试的工作流程，各种现有书籍和文章往往都描述的非常复杂，充斥着不少测试术语，使测试初学者望而生畏。 现在让我们换一种角度看看典型的软件测试是如何进行的，暂且把软件测试过程看作一场大戏，主角就是测试工程师，按照时间顺序记录软件测试工程师一天的工作场景（假设正常工作时间 9:00 到 18:00 ）。  测试大戏开演 时间：9:00 工作场景： 启动工作计算机，查看收到的电子信件。 画外音： 查看收到的电子邮件（哇塞，这么多电子邮件！），理解当天的测试工作的内容和要求。 测试工程师至少配置两台计算机：其中一台是日常工作用，例如，收发电子邮件等。另外还有一台软件测试用的计算机。 时间：9:10 工作场景： 回复电子邮件。 画外音： 回复电子邮件。如果对于安排的测试任务和要求存在任何疑问，请在回复电子邮件时列举出来。如果任务明确，回信中可以简单的说明理解测试任务了，按照测试任务要求进行测试。（正好今天有一封电子邮件分配了测试任务 A ，而且任务明确，测试文档等完整。） 电子邮件有不同的优先级，任务非常紧迫的电子邮件应该优先处理，尽快回复。（面对多封邮件保持镇定，分清哪些邮件需要马上回复） 并非全部的电子邮件都需要回复（抄送给自己的邮件和一般通告等不需要回复） 时间：9:25 工作场景： 启动用于测试的计算机 根据测试要求配置操作系统、安装要测试的软件 根据测试用例执行测试任务 A 。 画外音： 测试一般需要按照测试指导文档和测试用例进行。（软件测试可不是盲目的乱测一气的呀！） 很多软件的测试要求在一个“干净”的计算机上测试（提示：干静的计算机是仅安装了操作系统，没有安装其他应用程序的计算机）。 在进行正式测试前，需要阅读测试文档，明确测试任务（这些测试文档你找到了吗？是最新的测试文档吗？）。时间： 11:00 工作场景： 执行软件测试，书写软件测试 Bug 报告 画外音： 按照测试要求，尽量多找出软件的 Bug 。（什么破软件，能找出这么多 Bug ！ 反过来想，软件如果没有 Bug ，我们测试工程师不就失业了吗！） 根据发现的软件 Bug ，按照客户要求写出每个 Bug 的报告（要书写明白，否则客户事后会要求你重写，很费时间，也影响公司的测试质量，是否很没有面子？） 时间：11:30 工作场景： 报告测试执行中的遇到了问题 画外音： 如果测试用例的步骤不明确或者测试的软件不能成功安装，无法进行下面的测试，应该及时向测试负责人报告，等待答复后进行测试。（重大问题，切莫瞒报，也别主观想当然地猜测！） 如果某些测试步骤不明确，但是可以暂时跳过，请向测试负责人报告，并且继续进行下面的测试。（灵活处理，合理利用时间，时间就是金钱！） 时间：12:00 工作场景： 查收和回复新邮件，新邮件又来了一个新的测试任务 B ，而且要求紧急处理。 暂停测试任务 A ，进行测试任务 B 。 画外音： 测试过程中，要主要定时查看是否有新邮件，特别是那些要求非常紧急的任务。（重要任务一定要优先处理，否则就是工作失职） 如果新任务比较紧急，应该中断当前的测试，接着执行新任务。（为什么计划总是没有变化快，可是现实就是这样。）时间： 12:30 工作场景： 午餐、休息 画外音： 阳光、午餐、休息，美！（禁止在办公室玩任何电子游戏，办公室不是娱乐场所！）时间：13:30 工作场景： 查收和回复新邮件 画外音： 真幸运，没有其他新任务。 继续上午的任务 B 。时间：14:30 工作场景： 完成新任务 B ，向测试负责人提交任务 B 的测试结果 画外音： 完成任何任务后，需要向测试负责人发送任务完成的电子邮件。（这一点很重要的，否则你做的工作再多，测试负责人也不一定很清楚） 提交任务的电子邮件中，应该写明任务是否全部完成，存在什么问题，测试结果存放在什么计算机的哪个目录中。（想象测试负责人需要你提交哪些内容，最好在一封信中交待明白，完整，清楚，条理分明） 时间：14:40 工作场景： 发送测试任务 A 不能按期完成的电子邮件 画外音： 由于执行了新测试任务 B ，使得测试任务 A 不能按时完成，应该及早向测试负责人发送电子邮件。（如果你不主动说无法按时完成任务 A ，测试负责人就默认为你能够按时完成。而如果到了完成任务的最后期限，而你突然向测试负责人说任务还没有完成，那么我可以很负责任地告诉你：测试负责人将会很生气，后果很严重！） 得到测试负责人的答复后，继续执行测试任务 A 。 如果客户要求必须当天完成测试任务 A ，可能要做好加班准备（苦恼 … ）。或者请测试负责人将一部分任务分解给其他测试人员执行（呵呵，谢谢兄弟们拉我一把 ... ）。时间：14:50 工作场景： 继续执行测试任务 A 。 画外音： 寻找软件 Bug （这是主要任务之一） 书写 Bug 测试报告（这也是主要任务之一） 时间：15:30 工作场景： 查收和回复新邮件 画外音： 没有新电子邮件，呵呵！（最不喜欢在测试工作中，经常有邮件来骚扰！） 继续执行测试任务 A 。 时间：17:00 工作场景： 参加测试小组内部会议 画外音： 经常在测试过程中，测试小组内部会召开短暂的会议。（交流很重要的，倾听和发言一个都不能少） 会议内容一般是测试过程中遇到的问题，以及可能的解决办法，也包括测试进度是否与测试计划保持一致。 时间：17:30 工作场景： 发送当天任务完成情况的电子邮件 画外音： 当天任务完成情况的报告应该在下班前尽早发送给测试负责人，以便得到及时回复。 总结当天测试任务完成的情况（全部完成还是部分完成） 测试遇到的需要测试负责人或者问题客户帮助解决的问题（遇到问题一定要反映，不要什么问题都自己扛！） 给出当天处理 Bug 的数量、类型和存放位置（确保测试负责人能很容易的找到这些测试结果吗？）时间：17:45 工作场景： 整理当天的测试文档， 做好备份 个人总结 画外音： 备份当天的测试结果（有备无患！） 总结测试遇到的问题和学习的新知识（好好学习，天天向上！） 准备第二天的测试任务（未雨绸缪）时间： 18:00 工作场景： 下班 画外音： 如果不需要加班，按时回家，爽！ 测试大戏背后的故事 上面的测试场景描述基本上反映了软件测试工程师的工作情形，但是由于测试工作的复杂性、琐碎性、变化性，实际测试过程将是不断变化的。 测试的变化性 对于软件本地化等外包测试，测试过程和测试要求因不同客户而异，即使相同客户的不同项目，也会有些变化。另外，测试所用的测试计划、测试用例、测试 Build 版本经常变化。这是对测试工程师需要面对和正确处理的工作挑战。 多任务同时处理 软件测试工程师在一天的工作时间里，可能需要做多件事情（例如，测试负责人可能中间会安排新的任务），正常测试过程经常被中断，对此需要有相应的心理准备。 及时交流 测试过程很少是一帆风顺的，特别是不熟悉的新软件，或者测试用例没有表达清楚。这时除了自己学习和思考，还需要向测试组的其他同事请教。如果问题仍然没有解决，请及时向测试负责人反映情况，寻求帮助（提示：测试负责人积累了软件测试经验，一般问题都可以搞定，但是测试负责人也不是万能的，他们也有很多不能解决的问题，但是他们有“杀手锏” — 向客户的测试负责人寻求帮助，由于源语言是客户开发的，客户才是万能的！）。 电子邮件是主要的交流方式 测试过程不要一味地在测试计算机上做下去，要经常在日常工作用计算机查看和回复电子邮件，以免耽误了更重要的任务。除了电子邮件之外，也可以打电话和即时网络交流工具（ MSN 等），或者面对面与同事交流（提示：对于复杂的问题，与其来回发送多封电子邮件还说不明白，还不如打个电话或者面对面交谈更有效）。

软件测试工程师：软件企业中的质量管理

软件测试工程师的一天是怎么度过的呢？ 其实可以按照时间轴进行分为三个阶段： 去上班的阶段 工作中的阶段 下班后的阶段 清楚了一天时间的阶段划分，那么就可以知道一天的时间如何分配，以及自己的工作内容是什么了。 一、去上班的阶段         作为软件测试的工程师，每天的开始往往是伴随着激烈的闹钟开始，潜意识中和烦躁的闹钟做着激烈的斗争，在睡意惺忪中极不情愿的起床。总觉得早上的时间很紧张，此时距离大多数企业规定的9点上班时间可能不足2小时。如果住的距离公司近，那么对于住在车程2小时外的小伙伴来说充满了羡慕嫉妒恨。         早餐往往在路边或者公司附近就近解决，有时候也迫于时间的关系，早餐也就省了。能够按时进入公司打卡是多么幸运的一件事。（当然如果是领导，那就不用体会这一段了） 二、工作中的阶段       一般忙碌的一天往往是从早会开始（9:10左右），大多数互联网企业开启了敏捷开发模式，测试工程师作为软件质量的保障者，需要每天参与早上scrum小组的站会，解答三个问题。1）昨天完成了什么？2）今天即将要做什么？3）有没有需要协调的问题？       大约在15分钟后，站会结束。根据初步计划开始今天的任务，往往计划都是很美好的，但是...，但是事实却是从如下可能场景开始： 场景一：理想型 理想型企业团队的测试工程师，那么更多的是从开始计划的任务开始，按部就班实现自己的当日任务。 - 需求分析评审会议（其他相关会议） - 制定计划方案，做好测试准备，搭建环境等 - 根据已确定需求用例编写、用例评审、用例执行 - 进行缺陷的跟踪处理（提bug、跟进bug） - 问题的沟通交流，有效处理 - ......       如果是上述这种场景，那么恭喜您，所在的企业应该是流程资源等非常好的企业，能够专一有效的完成自己的每日任务（用例、缺陷），而不需要太多的杂念处理其他事物，适合性格内容向型的工程师。 场景二：一般型 一般型企业的测试工程师，工作是从开始计划的任务开始，但是否按部就班的执行下去，得看实际情况。 - 验证bug，并且回归测试相关模块，此时又发现新问题，找来开发、产品开启了补唾沫横飞的沟通场面... - 准备开始设计测试用例，发现需求不完整，没有细节，找产品临时给备注一堆说明，原来的设计推到再来... - 执行用例的环境没有准备好，申请的账号还没有通过，不可预知的风险悄悄的接近... - ......       如果是上述场景，那么同样恭喜您，所在企业迫切需要您梳理流程规范，细化好测试计划过程，需要和小组成员一起攻克难关，需要跨部门的合作和沟通技能，影响团队的进步。 场景三：凌乱型 凌乱型企业的测试工程师，工作没有计划，可以随心所欲的开始每天的任务，也可以不假思索的戛然而止。 - 测试工程师是一个“全能型”的人员，上级领导指哪儿，就往哪儿打，而且要求打的准 - 测试过程中的任务按照用户迫切的要求来，先把功能完成，至于能否满足质量要求，那是后面事 - 穿梭于不同任务及工作中，要么成为英雄，要么成为“枭雄” - ......       如果是上述场景，那么同样恭喜您，所在企业迫切需要您独当一面，从制度到流程到技术到业务，不求精通，但求能解决实际问题，挑战与机遇并存，要么最后是企业的英雄，要么是企业历史潮流中的一段插曲。         转眼间，时钟已经走向了中午12:00，一般企业会有1~2小时的午休时间，该段时间除了吃饭午休外，仅有的时间可以和同事们侃侃大山，聊聊生活，有时会讨论一些技术问题......，下午又开始接着上午的任务继续...... 随着下班的时间到了， 需要将一天的工作任务做个汇总和总结，按照要求发日报、周报。 上班工作期间内容总结 1)开会讨论 会占用10%~20%左右时间，各种形式的会议，为做下一步任务达成一致 2)设计执行 测试过程中设计执行时间会占用70%以上的时间，这也是测试的重点和核心 3）沟通确认 对于有疑问的地方和不同人员进行沟通确认会占用约10%左右时间 三、下班后的阶段 经历了忙碌而充实的一天，按照正常的工作时间结束测试工程师的一天。 如果碰到项目上线或者加班情况，那就只能按照实际要求来。       如果是非正常的下班，那么回家后的时间可能只有休息了，在睡梦中等待第二天的闹钟响起。       但如果是正常的下班，那么回家的时候基本是自己支配，当然为了后续能够更好的发展，别忘了用仅有剩余时间给自己充充电，这个时间是非常重要的，能够自由支配的时间不多，抓住仅有的时间查阅资料自己挖掘新知识，因为大神都是这么过来的。         总之，作为软件测试工程师，主要时间是在公司阶段任务，需要做好日常的管理，追求技能的提升，才能在有效的时间管理中强大自己，为企业带来价值，赢得未来的发展。 这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。 加油吧，测试员！如果你需要提升规划，那就行动吧，在路上总比在起点观望的要好。 未来的你肯定会感谢现在拼命的自己！