有时一个地方的bug太多，并且反复修改也没有改好，那么就停止测试，让开发仔细思考问题所在并且重新设计代码。
要根据实际的开发来调整自己的测试过程，有些项目就是不能提供完整的规格说明书或者需求老是变更。只能根据实际的情况来调整，而不能一味的拒绝。
项目文档是有用的，但是肯定是不足的，对于测试来说很多东西他肯定是没有写的例如边际问题等等。
测试除了产品文档外，还可以借鉴以下产品进行测试
- 用户手册
- 市场产品开发文献
- 市场开发人员向管理层推销产品概念的演讲
- 类似的产品
- 已经使用的用户界面标准和风格指南
什么样的测试计划适用于后期变更
- 不要编写维护成本很高的大量测试文档
- 不要在测试之前开发大的测试包
- 不要把手动或制度化测试捆绑特定的用户界面，除非是想要专门测试该用户界面
- 通过最大化可维护性和跨平台来设计自动化测试
- 构建一组通用用例，可以反复的使用。自动化脚本和测试用例都行
- 构建一组很强的冒烟测试，以快速检测出被测软件中的基本失效
判断测试是否足够的好有多种因素
- 测试知道发现的重要问题的种类，如果存在这种问题的话
- 测试知道产品的不同部件如何表现出来严重问题
- 测试对产品做了与这些风险相应的检查
- 测试策略具有合理的多样化，以避免视野过窄
- 测试使用了所有可能的资源进行测试
- 测试满足客户期望的所有测试过程标准
- 测试尽自己可能，清晰的表示测试策略，测试结果和质量评估
熟练的做到上面这些可是交付之后仍然存在问题可能是
- 了解的风险动态不够深入
- 在测试中出现错误
- 测试的风险评估是正确的，但是管理层决定冒险，并造成损失
测试工程师需要做多轮测试的原因：
- 程序员修改问题后会引入新的问题
- 随着对产品的逐步深入了解，测试工程师会考虑到新的更好的测试，并找出新的问题
- 第一轮测试有些流程甚至都走不通，只有等她修复了才能继续往下测试
如何预估测试时间：
1.列出任务清单预估每个任务需要的时间并且累加起来，再加上25%和产品，程序员扯皮时间，以及其他杂七杂八的工作。
要准备预估测试时间需要考虑到以下的几个问题
- 程序员是否了解这个项目，是否一直做这个项目
- 项目是新开发的，还是老项目维护修修补补的
- 产品逻辑是否复杂，是否与多个系统关联。
- 产品的设计能力，产品文档是否闭环，是否漏掉很多的逻辑
不同的测试工程师拥有不同的擅长领域，有些人擅长测试数据的质量，有些人擅长逻辑复杂的业务流程，有些人更加的细心。如果测试工程师完成某项任务特别慢，并且不能很好的完成任务，说明他不适合这个工作，不要让测试员承担不适合的工作。
不要让测试工程师自始至终对某个项目的同一组功能进行测试，
- 这会使测试员感到厌烦而且每个人都有测试盲点。
- 测试员太专的话不如一个多面手测试
- 如果这个人离开的话，会给测试小组留下很大的知识漏洞
- 两个不同的测试关注点不一样，可以从多方面的进行测试
一个测试过程快到结尾的项目，如何快速找出新的问题
- 对有怀疑的部分进行初步探索式测试，形成更细致地跟踪想法
- 探索被认为是风险很低的部分
- 定位看起来很容易引起不可重视问题的关键部分
- 如果项目要延期，那么需要找出关键错误用来说服项目经理。
测试工程师可以把每天的任务分成阶段性测试，例如60分钟到90分钟为一个阶段。确定这一段时间的需要测试的任务，这样可以保证测试工程师的注意力更加的集中，
作为一个测试沟通能力非常的重要，测试和程序员以及产品的地位是相等的，他们不是你的下级，说服他们给测试提供资源，等等
测试报告应该注意以下几点
- 使用中立，客观的语气
- 不针对具体某个人
- 所有的项目都采用一致的格式
- 按照进度计划提交报告
通过bug数量来预估项目的进度
- 项目刚开始的时候，bug数量会非常的多，到收尾阶段基本上没有什么bug了，说明产品的质量已经取决于稳定了
- 如果到了项目的最后阶段仍然有这大量的bug，并且这些bug不易修改而且还会产生大量新的bug，则建议推迟产品的交付时间
项目日报可以用于项目进展和测试进展度量
- 产品已经完成了多少测试
- 计划进行的测试已经完成了多少
- 发现了多少问题，有多少问题没有解决
- 那些问题阻碍到了继续测试，因为未解决的缺陷，缺乏设备或某些问题还没有做出决策导致测试进度受阻
- 我们对测试质量有多大的把握
测试的周报如何编写
- 第一页列出关键问题
所需要做出的决策（是否需要增加测试人员，是否需要设备，那些问题急需解决）
所需的程序错误修改（影响测试的进度的bug）
预期交付的工作制品（需要交付的文档设备功能和工具等）
意外问题（某个员工跳槽引起的部分测试效率降低，员工需要培训）
- 第二页描述测试小组完成计划任务进展的情况
- 提供错误报告统计数字
- 最后一页列出本周被延迟的项目已经程序错误
测试小组的管理
- 测试经理要让员工可以成为互换的齿轮
- 每个员工都会以不同的方式去完成自己的工作
- 不能扼杀员工的创造性
- 测试经理要对员工的创造性，可说服性，判断力或人际敏感性有大概的了解
- 测试经理要让员工对其工作结果负责
员工具有不同的强项和兴趣，需要进行针对性的进行管理
从哪些方面评估员工的测试报告
- 报告直率的提出了问题吗？
- 报告留下迫切要求后续测试的漏洞吗？
- 发现程序错误的测试看起来例行公事还是很有见地
- Bug很难发现吗?bug 出现在程序一般比较稳定的部分吗？如果是那么是因为测试工程师的坚韧还是好运气
- 程序员能理解提的bug吗？程序员对测试报告有什么反馈意见？这反映出来程序员和测试员的良好协作，还是相互指责
评价测试工程师的可以可以根据以下的条件：
- 阅读提交的bug
- 阅读编写的代码
- 阅读编写的测试文档
- 收集与其一起工作的程序员和其他有关人员的意见
- 他卷入了什么争端，为什么？
- 在按期完成任务方面做的怎么样
- 遗漏了什么类型的bug
- 他对其他测试工程师和程序员提供了什么类型的帮助，以提高他们工作 的有效性和生产率?
- 他在学习新技能吗？新技能应用到工作中吗？传授给其他人了吗？
- 他站在公司的立场上处理过什么问题？
我们不建议进行微观管理：了解员工做什么并据此进行指导，
只需要告诉他们什么时候以及怎样完成自己的工作。
测试经理必须要分配小组的大部分工作，并且自己可能没有充当如何角色。如果测试经理完全丧失测试的技术能力，那么就会丧失可信性。
不要指望所有人都可以有效处理多个项目，如果承当多个项目，测试工程师会把时间分的很碎，要在管理上面花很多时间，要参加很多会议，要花大量时间了解各个项目
测试工程师需要积累专业领域知识，相关技术方面的专门知识，积极提高技能
如何帮助新测试员获得成功
- 安排新测试工程师与项目相关人员见面，熟悉一下公司的环境
- 为测试员指派一位指导者，来回答各种问题，检测新测试工程师所完成的工作
- 让新员工对照沉淀文档来熟悉系统，通过正面测试是员工快速的熟悉产品
- 对于一个几乎要完成的项目，最好不要安排新员工，因为新员工不了解项目而且在测试的时候发现的问题，大多数都是不熟悉系统造成的。这样会浪费老测试工程师的时间，
员工的士气很重要
- 礼貌地对待员工，尊重员工
- 注意他们的工作
- 称赞好的工作，热心和诚实努力
- 如果员工加班，测试经理也要加班
- 如果可能，安排员工做他们感兴趣的任务和项目
- 如果员工任务完成得不够顺利，可指导别人给予帮助，指导
- 提供培训的机会
- 了解员工时要全方面的了解，不要偏听偏信
- 公开的指责员工，会使员工心怀不满，有问题可以私下指出其错误
长期的加班会使员工体力透支，跳槽率提高，低效，工作草率
有些项目需要短期突击加班很正常，但是长期加班不提倡
在指定项目进度计划时，不要指望员工能够明天都8小时集中在工作上，测试工程师需要参加会议，接受培训和编写状态报告和备忘录等
不要同意自己知道的不现实的进度计划，要尽可能准确地估计完成不同任务需要多长时间
身为测试经理在员工遇到困难时，要及时处理提供帮助。提供精神的支持并解决各种不公正待遇，要为员工提供培训的机会
录用员工时：
- 谨慎把其他小组拒绝的人吸收到测试小组中
- 要根据测试小组需要承当的任务，，以及完成这些任务所需的技能做出规划
- 测试团队要有不同背景的人，不同技能的人
- 录用热爱测试工作的人
- 在面谈时要应聘者展示期望有的技能，
测试工程师在找工作的时候要清楚一件事，很多公司都有这样或者那样的问题，不比本公司的问题少
找工作之前可以做的准备
- 多注意休息，使自己的精神状态良好
- 更新好简历
- 搜集自己想要加入的公司，查看公司对技能的要求
- 如果可以最好找一个内部推荐人
- 了解准备应聘的公司，可以从互联网或其他从业者
- 学习脚本语言
- 提高自己的写作技巧
- 提高自己的公众讲话技巧
- 如果能考证的话，可以考证，这样可以加分
如何写好简历
- 如果想要应聘不同的岗位，必须要写出不同的简历
- 简历里面要以时间顺序描述自己的工作经历，要突出介绍在每个工作中取得的成就
- 简历里面要包含功能性或关键词简历，要突出自己的技能，
- 可以适当的夸大自己的背景，技能或经验，但是不要太离谱
- 某些很容易查出来的东西不要造假，如学历等
测试策略要问的三个基本问题是为什么担心？谁关心？测试多少？
为什么担心：测试是昂贵的
谁关心：测试重要的一点就是在于重要任务的感觉和价值观，只在测试策略中包含于他们利益相关的活动
测试多少：到底打算实际测试多少呢？
测试策略是有多种的，每种策略都有不同的重点，都说明如何进行测试。好的测试策略会给出要完成测试的令人信服的描述和论证
- 经过简单的内部评审，找出所有特别明显的问题之后，将产品发放给友好的用户，这些用户会告知项目团队还需要做哪些修改
- 我们定义以用户与产品交互动作系列表示的测试用例，这些测试用例合在一起，代表预期一般用户使用的各种方法。还可以在这些基础上补充压力测试和异常使用测试。首先要做的是对比特定行为的基本偏差，但是也关注程序与用户期望冲突的方式，还要考虑可靠性
- 执行探索式测试，开发和执行自动化回归测试
实际的测试计划就是指导测试过程的一套想法
测试计划是指导将要做什么的所有想法
测试计划并不一定是书面计划，有可能是口头计划，列在白板上的计划，篇幅只有一页纸的计划，一系列电子邮件，一组大纲或问题清单
测试计划需要包含五种资源和约束
- 开发：产生将要测试的产品系统。如何接受该产品？该产品的可测试性如何？
- 需求：成功产品的评判标准。该产品的风险是什么？有关质量谁的意见最重要？
- 测试团队：能够投入该产品测试的人员。有合适的人员吗？能够及时完成任务吗？
- 测试实验室：使测试团队能够完成测试任务的系统，工具和材料。有合适的设备吗？
- 任务：测试团队必须按照客户认可的成功标准解决的问题。快速找出重要问题？对质量做出准备评估？
测试计划必须描述三类选择
策略：如何测试产品以快速的找出重要问题？需要对哪些部分进行特殊测试？要应用什么手段创建测试？测试策略要规定测试项目与测试任务之间的关系
保障条件：如何利用资源实现测试策略？谁来测试？什么时候测试？要想成功需要什么条件？
工作产品：怎样向客户提供工作产品？如何跟踪bug？需要编写什么文档，报告？
不要让保障条件和工作产品影响测试策略
测试策略要比测试用例重要，测试策略要说明测试用例是否能够完成测试任务，总结产生测试用例的手段和目标概述
测试策略可以向任何关心测试的人快速，令人信服的解释自己的测试过程。
好的测试策略是：
- 与具体产品有关：与当前具体产品和技术有关的测试策略总会更好
- 关注风险：显示测试过程可以怎样描述重要问题
- 多样化：在多数情况下，多样化的测试策略优于单调的测试策略
- 实用：测试策略必须是能够被执行
执行达到相当水平的多种不同测试，要优于完美地执行一两种测试
随着对被测试产品的不断深入，测试策略也应该进化
根据产品的成熟度确定测试策略
- 项目初期：简单的测试
- 项目中期：积极的测试
- 项目后期：多样化的进行测试
- 项目最后：谨慎的测试
测试策略制定原则：
1.不要在测试员之间的缝隙中遗漏错误
- 经常测试客户要求测试的内容
- 偶尔测试客户不要求的测试内容
- 测试不够清晰和矛盾的内容
- 不要痛打落水狗，某个功能有很多错误，就不要继续测试了
- 更多的变更意味着更多的测试
测试周期：
- 接受产品
- 对测试系统进行配置
- 检测可测试性
- 确定哪些部分是新增加或经过修改的
- 确定修改了哪些错误
- 测试程序错误修改
- 测试新的或经过变更的部分
- 测试其他部分
- 报告测试结果