测试工程师时间节点

软件测试工程师对软件的质量负责，软件测试是一个系列的过程活动，包括软件测试需求分析、测试用例的设计、执行测试、反馈测试等，贯穿于整个软件项目的生命过程，基本上软件项目的每个阶段都要进行一系列的测试，不同目的不同内容的测试，从多种角度发现软件可能存在的bug，并提交给开发人员及时修改，软件测试工程师可以说是bug的收割机，每天的工作也都是在围绕bug而展开。软件测试程序员每天最主要的工作就是测试，编写测试计划，编写测试用例，测试计划一般指测试人员的测试计划，要在什么时间什么节点做什么事，最后产出什么文档，并在规定的时间内提交，测试用例就是指导测试的文档，通过测试方法和各种策略设计测试用例，这都是测试工程师经常要做的。每天的工作也都是围绕着项目，通过不同的方法和策略达到软件测试的目的。有哪些是必须要做的?执行测试基本上可以说是必须要做的，通过不同工具不同软件不同的方法，比如说黑盒测试、白盒测试或者是其他测试方法，执行测试用例，从而发现缺陷，发现bug之后要提交给开发人员去修改，然后回归测试，再验证开发人员有没有修改好。

软件测试的流程：1、根据软件设计需求制定测试计划，测试数据和测试用例。 2、搭建测试环境、执行测试用例。 3、提交测试报告。 4、跟踪Bug修改情况，不断测试完善产品。 5、产品的其他方面测试。

前段时间才写了一个手机app的测试报告，刚好可以自己理一下思路，回顾一下！

请点击输入图片描述

对于软件测试的流程大概总结了几个基本步骤，测试的文档最好是尽量多，多加一些自己的特色和想法，这样相比于其他文章自己的也更有卖点和优势。

1. 需求：做测试是要跟着测试的文案方向走，这是最重要的，根据需求做测试。

2. 测试的安排计划：测试的时间、地点、资源、人员等竟可能的写全面。

3. 测试用例：测试可以分布的来测试这样更有条理性，主要可以分为单元测试、集成测试、系统测试、验收测试。

4. 测试问题规划：把问题、bug等问题出来，给相关的人员提出问题。

5. 跟进问题：实时更新问题是否解决。

6. 找不同的人测试软件，并把他们的的体验做成报告，充分体现软件的性能、特点、市场、问题等方面的信息。

还没有思路？举一个生动的例子吧！给你一个杯子如何测试？

请点击输入图片描述

1. 界面测试（外形）：它的外形是否和设计一致，是否有不足。

2. 易用性:是否方便手拿，杯子装热水是否烫手等。

3. 安全性：会不会对人造成伤害。

4. 稳定性：是否会漏水，杯子是否太烫会炸裂。

5. 兼容性：是否可以盛酒精、水、果汁等。

总结：对杯子的问题、特点、功能等多方面进行总结。

- 01 -目标规划 & 时间节点时光荏苒，很多测试同伴倒下，我们这些毅力的人踏着血泪继续前行。有的人善于总结，有的人善于思考，有的人善于玩命。当然，各种人生，悉数上演。抱怨的人继续抱怨，怨天由人，止步不前，在公司有一天是一天，进取？不懂，也不想懂。人，得展望未来，拼命的人都在没日没夜的玩命，你还在这里不动。或许你早已没有当年热血与青春，早已不想学习展望，那好，这篇文章不适合你。不要继续看了。如果你还要提升自己，测试前行的路就算很黑暗，那又怎样，还不得杀出一条血路？没有血的惨痛，怎能打动你如此愚钝的腿。你需要做的，好好去规划，从现在起，放下以前的观点或态度，一个字: ”干” 。不想太多，就是”干”，拿出自己的勇气和激情，就是”干”。这才是最重要的 。时间很快，等今年过去，你还要继续悔恨不已么？趁现在，一分一秒，争分多秒，一步一个脚印，哪怕被别人甩下好久，不要害怕，就是”干”，只要一口气在，就全力学习，人就是要对自己狠一点 。怎么干？目标。这玩意谁都知道，为什么你没有坚持？如果你拿出一半的时间从聊微信或看视频中脱离出来，就可以了。说多无益，路是自己走出来的，别在第一步就退了。否则，你的尸体所有人都将无情的踏过。/- 02 -目标确立、执行目标的三部曲：规划、时间、鞭挞。规划，就是要做哪些事，如何拆分，哪些渠道获取学习资料，哪些人可以帮助我，哪些知识需要领悟，哪些弱势，哪些强势，哪些要重点搞定。时间，没有时间来做节点保障，那你的计划规划如同没有终点的比赛，所以，正视自己当前的能力，给自己定个可以阶段性完成的目标，怕就不要玩，还是一样，坚持不下来就不要玩，因为，这个世界，这个行业不会在乎你是谁。鞭挞，时刻清晰和清醒的头脑是自己前进的线。在坚持不下去时，时刻鞭挞自己。我本人特别喜欢恐怖片，为什么？因为再恐怖的事我都体验过了，那现实，还恐怖吗？所以，累了就弄醒自己，就是”干”。对于测试从业者，不管你当前是属于哪个阶段、掌握了哪些技能、技术多牛X ，要明白几点 ：1. 思维扩散点，看长远点 。2. 多培养自己的职场软技能、职业常识 。3. 要相信，测试职业，是整个项目的核心环节，是承上启下的作用 。4. 多去关注行业动态，掌握最新的技术 。5. 一些必备的知识，不管目前工作是否有用到，都得去掌握，迟早用得上（Linux Python Jenkins Shell Sql）6. 多去跟同行交流技术，少点闲扯 。7. 真有闲扯的时间，应该是花在异性 & 家人身上，别老几个基友干聊 。/- 03 -年底大考验考验自己的时候绝不手软，同行沟通，套其他人的话，面试题整理，硬软技能哪些偏重，来哪些 。计划的事情搞得是否可行，自己不足，他人优点有哪些可以借鉴，多沟通和他人扯淡。不管哪个行业，都应该读的书：心理学类图书，人际交往类图书。有志气，有理想的同学可以加我VX:Mr_Chen1112,沟通如何有效学习。

1. 引言 软件测试成为最近 IT 行业的“香饽饽”，引得很多人对软件测试跃跃欲试。可是软件测试的门槛并不低，对于没有软件测试经验的新人而言，如何尽快转入测试工作中去呢？ 了解软件测试都做些什么，具体过程是怎么进行的，可以有助于对软件测试进行初步了解，尽快进入测试工作角色。但是关于软件测试的工作流程，各种现有书籍和文章往往都描述的非常复杂，充斥着不少测试术语，使测试初学者望而生畏。 现在让我们换一种角度看看典型的软件测试是如何进行的，暂且把软件测试过程看作一场大戏，主角就是测试工程师，按照时间顺序记录软件测试工程师一天的工作场景（假设正常工作时间 9:00 到 18:00 ）。 2. 测试大戏开演 时间： 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 工作场景： 下班 画外音： 如果不需要加班，按时回家，爽！ 3. 测试大戏背后的故事 上面的测试场景描述基本上反映了软件测试工程师的工作情形，但是由于测试工作的复杂性、琐碎性、变化性，实际测试过程将是不断变化的。 测试的变化性 对于软件本地化等外包测试，测试过程和测试要求因不同客户而异，即使相同客户的不同项目，也会有些变化。另外，测试所用的测试计划、测试用例、测试 Build 版本经常变化。这是对测试工程师需要面对和正确处理的工作挑战。 多任务同时处理 软件测试工程师在一天的工作时间里，可能需要做多件事情（例如，测试负责人可能中间会安排新的任务），正常测试过程经常被中断，对此需要有相应的心理准备。 及时交流 测试过程很少是一帆风顺的，特别是不熟悉的新软件，或者测试用例没有表达清楚。这时除了自己学习和思考，还需要向测试组的其他同事请教。如果问题仍然没有解决，请及时向测试负责人反映情况，寻求帮助（提示：测试负责人积累了软件测试经验，一般问题都可以搞定，但是测试负责人也不是万能的，他们也有很多不能解决的问题，但是他们有“杀手锏” — 向客户的测试负责人寻求帮助，由于源语言是客户开发的，客户才是万能的！）。 电子邮件是主要的交流方式 测试过程不要一味地在测试计算机上做下去，要经常在日常工作用计算机查看和回复电子邮件，以免耽误了更重要的任务。除了电子邮件之外，也可以打电话和即时网络交流工具（ MSN 等），或者面对面与同事交流（提示：对于复杂的问题，与其来回发送多封电子邮件还说不明白，还不如打个电话或者面对面交谈更有效）。 4. 结束语 有人说，测试很枯燥，而且“一点技术含量都没有”。也有人说，软件测试大有前途！现在中国确的不是软件编程大师，而是软件测试大师。这些观点孰是孰非，您请自己琢磨。不过既然从事了测试行业，还是将它做好为上！]

①测试和发现软件中存在的软件缺陷；②测试工作需要贯穿整个软件的生命周期；③ 测试用例报告形成：测试人员为了更好更有效地进行测试，保证测试工作质量，需要在执行测试工作之前首先需要设计测试用例，形成测试用例报告。④测试计划制定：测试过程中，为了更好地组织与实施测试工作，测试负责人需要制定测试计划，包括有测试资源、测试进度、测试策略、测试方法、测试工具、测试风险等。⑤ 缺陷报告编写及提交：测试人员将发现的缺陷编写成正式的缺陷报告，提交给开发人员进行缺陷的确认和修复。⑥软件质量分析：在测试完成后，测试人员需要根据测试结果来分析软件质量，包括缺陷率、缺陷分布、缺陷修复趋势等。给出软件各种质量特性包括有功能性、可靠性、易用性、安全性、时间与资源特性等的具体度量。最后给出一个软件是否可以发布或提交用户使用的结论。