软件测试工程师要考证-试睡师要考证吗

有时一个地方的bug太多，并且反复修改也没有改好，那么就停止测试，让开发仔细思考问题所在并且重新设计代码。

要根据实际的开发来调整自己的测试过程，有些项目就是不能提供完整的规格说明书或者需求老是变更。只能根据实际的情况来调整，而不能一味的拒绝。

项目文档是有用的，但是肯定是不足的，对于测试来说很多东西他肯定是没有写的例如边际问题等等。

测试除了产品文档外，还可以借鉴以下产品进行测试

用户手册市场产品开发文献市场开发人员向管理层推销产品概念的演讲类似的产品已经使用的用户界面标准和风格指南

什么样的测试计划适用于后期变更

不要编写维护成本很高的大量测试文档不要在测试之前开发大的测试包不要把手动或制度化测试捆绑特定的用户界面，除非是想要专门测试该用户界面通过最大化可维护性和跨平台来设计自动化测试构建一组通用用例，可以反复的使用。自动化脚本和测试用例都行构建一组很强的冒烟测试，以快速检测出被测软件中的基本失效

判断测试是否足够的好有多种因素

测试知道发现的重要问题的种类，如果存在这种问题的话测试知道产品的不同部件如何表现出来严重问题测试对产品做了与这些风险相应的检查测试策略具有合理的多样化，以避免视野过窄测试使用了所有可能的资源进行测试测试满足客户期望的所有测试过程标准测试尽自己可能，清晰的表示测试策略，测试结果和质量评估

熟练的做到上面这些可是交付之后仍然存在问题可能是

了解的风险动态不够深入在测试中出现错误测试的风险评估是正确的，但是管理层决定冒险，并造成损失

测试工程师需要做多轮测试的原因：

程序员修改问题后会引入新的问题随着对产品的逐步深入了解，测试工程师会考虑到新的更好的测试，并找出新的问题第一轮测试有些流程甚至都走不通，只有等她修复了才能继续往下测试

如何预估测试时间：

1.列出任务清单预估每个任务需要的时间并且累加起来，再加上25%和产品，程序员扯皮时间，以及其他杂七杂八的工作。

要准备预估测试时间需要考虑到以下的几个问题

程序员是否了解这个项目，是否一直做这个项目项目是新开发的，还是老项目维护修修补补的产品逻辑是否复杂，是否与多个系统关联。产品的设计能力，产品文档是否闭环，是否漏掉很多的逻辑

不同的测试工程师拥有不同的擅长领域，有些人擅长测试数据的质量，有些人擅长逻辑复杂的业务流程，有些人更加的细心。如果测试工程师完成某项任务特别慢，并且不能很好的完成任务，说明他不适合这个工作，不要让测试员承担不适合的工作。

不要让测试工程师自始至终对某个项目的同一组功能进行测试，

这会使测试员感到厌烦而且每个人都有测试盲点。测试员太专的话不如一个多面手测试如果这个人离开的话，会给测试小组留下很大的知识漏洞两个不同的测试关注点不一样，可以从多方面的进行测试

一个测试过程快到结尾的项目，如何快速找出新的问题

对有怀疑的部分进行初步探索式测试，形成更细致地跟踪想法探索被认为是风险很低的部分定位看起来很容易引起不可重视问题的关键部分如果项目要延期，那么需要找出关键错误用来说服项目经理。

测试工程师可以把每天的任务分成阶段性测试，例如60分钟到90分钟为一个阶段。确定这一段时间的需要测试的任务，这样可以保证测试工程师的注意力更加的集中，

作为一个测试沟通能力非常的重要，测试和程序员以及产品的地位是相等的，他们不是你的下级，说服他们给测试提供资源，等等

测试报告应该注意以下几点

使用中立，客观的语气不针对具体某个人所有的项目都采用一致的格式按照进度计划提交报告

通过bug数量来预估项目的进度

项目刚开始的时候，bug数量会非常的多，到收尾阶段基本上没有什么bug了，说明产品的质量已经取决于稳定了如果到了项目的最后阶段仍然有这大量的bug，并且这些bug不易修改而且还会产生大量新的bug，则建议推迟产品的交付时间

项目日报可以用于项目进展和测试进展度量

产品已经完成了多少测试计划进行的测试已经完成了多少发现了多少问题，有多少问题没有解决那些问题阻碍到了继续测试软件测试工程师要考证，因为未解决的缺陷，缺乏设备或某些问题还没有做出决策导致测试进度受阻我们对测试质量有多大的把握

测试的周报如何编写

第一页列出关键问题

所需要做出的决策（是否需要增加测试人员，是否需要设备，那些问题急需解决）

所需的程序错误修改（影响测试的进度的bug）

预期交付的工作制品（需要交付的文档设备功能和工具等）

意外问题（某个员工跳槽引起的部分测试效率降低，员工需要培训）

第二页描述测试小组完成计划任务进展的情况提供错误报告统计数字最后一页列出本周被延迟的项目已经程序错误

测试小组的管理

测试经理要让员工可以成为互换的齿轮每个员工都会以不同的方式去完成自己的工作不能扼杀员工的创造性测试经理要对员工的创造性，可说服性，判断力或人际敏感性有大概的了解测试经理要让员工对其工作结果负责

员工具有不同的强项和兴趣，需要进行针对性的进行管理

从哪些方面评估员工的测试报告

报告直率的提出了问题吗？报告留下迫切要求后续测试的漏洞吗？发现程序错误的测试看起来例行公事还是很有见地Bug很难发现吗?bug 出现在程序一般比较稳定的部分吗？如果是那么是因为测试工程师的坚韧还是好运气程序员能理解提的bug吗？程序员对测试报告有什么反馈意见？这反映出来程序员和测试员的良好协作，还是相互指责

评价测试工程师的可以可以根据以下的条件：

阅读提交的bug阅读编写的代码阅读编写的测试文档收集与其一起工作的程序员和其他有关人员的意见他卷入了什么争端，为什么？在按期完成任务方面做的怎么样遗漏了什么类型的bug他对其他测试工程师和程序员提供了什么类型的帮助，以提高他们工作 的有效性和生产率?他在学习新技能吗？新技能应用到工作中吗？传授给其他人了吗？他站在公司的立场上处理过什么问题？

我们不建议进行微观管理：了解员工做什么并据此进行指导，

只需要告诉他们什么时候以及怎样完成自己的工作。

测试经理必须要分配小组的大部分工作，并且自己可能没有充当如何角色。如果测试经理完全丧失测试的技术能力，那么就会丧失可信性。

不要指望所有人都可以有效处理多个项目，如果承当多个项目，测试工程师会把时间分的很碎，要在管理上面花很多时间，要参加很多会议，要花大量时间了解各个项目

测试工程师需要积累专业领域知识，相关技术方面的专门知识，积极提高技能

如何帮助新测试员获得成功

安排新测试工程师与项目相关人员见面，熟悉一下公司的环境为测试员指派一位指导者，来回答各种问题，检测新测试工程师所完成的工作让新员工对照沉淀文档来熟悉系统，通过正面测试是员工快速的熟悉产品对于一个几乎要完成的项目，最好不要安排新员工，因为新员工不了解项目而且在测试的时候发现的问题，大多数都是不熟悉系统造成的。这样会浪费老测试工程师的时间，

员工的士气很重要

礼貌地对待员工，尊重员工注意他们的工作称赞好的工作，热心和诚实努力如果员工加班，测试经理也要加班如果可能，安排员工做他们感兴趣的任务和项目如果员工任务完成得不够顺利，可指导别人给予帮助，指导提供培训的机会了解员工时要全方面的了解，不要偏听偏信公开的指责员工，会使员工心怀不满，有问题可以私下指出其错误

长期的加班会使员工体力透支，跳槽率提高，低效，工作草率

有些项目需要短期突击加班很正常，但是长期加班不提倡

在指定项目进度计划时，不要指望员工能够明天都8小时集中在工作上，测试工程师需要参加会议，接受培训和编写状态报告和备忘录等

不要同意自己知道的不现实的进度计划，要尽可能准确地估计完成不同任务需要多长时间

身为测试经理在员工遇到困难时，要及时处理提供帮助。提供精神的支持并解决各种不公正待遇，要为员工提供培训的机会

录用员工时：

谨慎把其他小组拒绝的人吸收到测试小组中要根据测试小组需要承当的任务，，以及完成这些任务所需的技能做出规划测试团队要有不同背景的人，不同技能的人录用热爱测试工作的人在面谈时要应聘者展示期望有的技能，

测试工程师在找工作的时候要清楚一件事，很多公司都有这样或者那样的问题，不比本公司的问题少

找工作之前可以做的准备

多注意休息软件测试工程师要考证，使自己的精神状态良好更新好简历搜集自己想要加入的公司，查看公司对技能的要求如果可以最好找一个内部推荐人了解准备应聘的公司，可以从互联网或其他从业者学习脚本语言提高自己的写作技巧提高自己的公众讲话技巧如果能考证的话，可以考证，这样可以加分

如何写好简历

如果想要应聘不同的岗位，必须要写出不同的简历简历里面要以时间顺序描述自己的工作经历，要突出介绍在每个工作中取得的成就简历里面要包含功能性或关键词简历，要突出自己的技能，可以适当的夸大自己的背景，技能或经验，但是不要太离谱某些很容易查出来的东西不要造假，如学历等

测试策略要问的三个基本问题是为什么担心？谁关心？测试多少？

为什么担心：测试是昂贵的

谁关心：测试重要的一点就是在于重要任务的感觉和价值观，只在测试策略中包含于他们利益相关的活动

测试多少：到底打算实际测试多少呢？

测试策略是有多种的，每种策略都有不同的重点，都说明如何进行测试。好的测试策略会给出要完成测试的令人信服的描述和论证

经过简单的内部评审，找出所有特别明显的问题之后，将产品发放给友好的用户，这些用户会告知项目团队还需要做哪些修改我们定义以用户与产品交互动作系列表示的测试用例，这些测试用例合在一起，代表预期一般用户使用的各种方法。还可以在这些基础上补充压力测试和异常使用测试。首先要做的是对比特定行为的基本偏差，但是也关注程序与用户期望冲突的方式，还要考虑可靠性执行探索式测试，开发和执行自动化回归测试

实际的测试计划就是指导测试过程的一套想法

测试计划是指导将要做什么的所有想法

测试计划并不一定是书面计划，有可能是口头计划，列在白板上的计划，篇幅只有一页纸的计划，一系列电子邮件，一组大纲或问题清单

测试计划需要包含五种资源和约束

开发：产生将要测试的产品系统。如何接受该产品？该产品的可测试性如何？需求：成功产品的评判标准。该产品的风险是什么？有关质量谁的意见最重要？测试团队：能够投入该产品测试的人员。有合适的人员吗？能够及时完成任务吗？测试实验室：使测试团队能够完成测试任务的系统，工具和材料。有合适的设备吗？任务：测试团队必须按照客户认可的成功标准解决的问题。快速找出重要问题？对质量做出准备评估？

测试计划必须描述三类选择

策略：如何测试产品以快速的找出重要问题？需要对哪些部分进行特殊测试？要应用什么手段创建测试？测试策略要规定测试项目与测试任务之间的关系

保障条件：如何利用资源实现测试策略？谁来测试？什么时候测试？要想成功需要什么条件？

工作产品：怎样向客户提供工作产品？如何跟踪bug？需要编写什么文档，报告？

不要让保障条件和工作产品影响测试策略

测试策略要比测试用例重要，测试策略要说明测试用例是否能够完成测试任务，总结产生测试用例的手段和目标概述

测试策略可以向任何关心测试的人快速，令人信服的解释自己的测试过程。

好的测试策略是：

与具体产品有关：与当前具体产品和技术有关的测试策略总会更好关注风险：显示测试过程可以怎样描述重要问题多样化：在多数情况下，多样化的测试策略优于单调的测试策略实用：测试策略必须是能够被执行

执行达到相当水平的多种不同测试，要优于完美地执行一两种测试

随着对被测试产品的不断深入，测试策略也应该进化

根据产品的成熟度确定测试策略

项目初期：简单的测试项目中期：积极的测试项目后期：多样化的进行测试项目最后：谨慎的测试

测试策略制定原则：

1.不要在测试员之间的缝隙中遗漏错误

经常测试客户要求测试的内容偶尔测试客户不要求的测试内容测试不够清晰和矛盾的内容不要痛打落水狗，某个功能有很多错误，就不要继续测试了更多的变更意味着更多的测试

测试周期：

接受产品对测试系统进行配置检测可测试性确定哪些部分是新增加或经过修改的确定修改了哪些错误测试程序错误修改测试新的或经过变更的部分测试其他部分报告测试结果