确定了项目目标，下面就是要把项目的实施策略、人力资源、进度和成本有个大致的估计，当然这是一个很粗略的估计，不是太精确，但是这不是什么大的问题。但是你一定要做这一步，否则项目到了中后期你就会惴惴不安起来。
 
       项目的估算主要是软件的规模、工作量、工期、成本、人力资源数量及资源日历（资源占用的起止时间）需要好好进行分析和估计。
 
     CMMI里面会有很多需要你去度量的产品数据、项目过程数据，但是这些数据对你来说是否真的有用，其实那是另外一个事情了。但是对于一个成熟的组织，能够收集这些数据以供分析项目和软件的健康状况也是有益的，或者用来将来项目的参考也是有指导意义的。但是让你在项目早期逼着开发人员估计他要开发多少行代码好像意义并不充分，而且还会受到嫌弃。你完全可以在软件发布前对实际撰写的代码行使用工具统计出来，这些数据是比较容易收集的。
 
    对于软件规模的度量很多公司更加倾向于去使用功能点估算，或者在敏捷方法里面对故事点的估计。如果对软件的需求确实能够写到需求规格说明书的要求，把输入和输出都讲清楚，那么确实可以估计出功能点，然后再去推算工作量，但是往往估算工作会占用很多工作量，这不是一个投入和产出成正比的工作。那么实际上，很多人怎么做的呢？
 
       工作量=任务人数*工期
 
     好像工作量的问题确实是解决了，把所有能够列举的任务（来自于WBS）的工作量全部累加起来就能够将项目完成软件或者系统集成的工作量推算出来，这种自下而上的估算方法不仅仅精度提高了，而且项目管理的精细程度增加了。但实际情况又是怎么样的呢？
 
   第一，你没有办法通过历史项目的数据穷尽你现在项目的所有数据，哪怕这两个项目非常类似。
 
   第二，不同的人工作效率是不一样的，新人不一定都是你可以认为的战力，也许你会自嘲认为那算半个人吧。
 
   第三，可能有未知的项目风险会占用更多的工作量和人力资源。
 
   第四，最让人头疼的情况，客户或者你的供应商他们的拖延症犯了，这个时候，哪怕你不停的催促，但你依旧没有办法控制你的工作量。或者你以为是客户应该做的事情，他会告诉你他不是很懂，希望你去完成。
 
   试着回答下面几个问题：
 
  1. 写一份项目计划，为啥你用1天就写好了，但是如果我来写就要3天时间，难道是我的工作效率比你低吗?
 
  2.做一份需求规格说明书，甲调研了10个部们花了10天，撰写文档花了5天，乙调研了5个部门，撰写文档花了5天。甲写的文档比乙写的文档，调研的详细程度更高吗？撰写的文字更加详细吗？
 
 3.1个高级工程师撰写概要设计说明书和2个中级工程师撰写同样的文档，同样都用了3天，你认为两组人谁写的更好呢？
 
 4.小A1个小时500个字可以把事情写清楚，小B1个小时1000个字还没有把事情说明白，你认为你应该怎么估算这样的工作量？
 
      如果你把这些问题想清楚了，那么你会发现你所有的工作量估算都是基于你自己各种的假设，这种假设是主观的，但是你又不会把这些假设写到计划中，让所有人都看到。
 
      当你限定了人数和工期的时候，你把这样的计划发出去，实际上更多的是你把你自己个人的进度期望强加给了执行这个任务的人，希望他们在规定的时间内完成，不管他们是否要加班应对。好的情况是，当你把这个计划给你的团队成员看的时候，他会告诉你完成不了，好吧，你又要修改工期，不好的情况是有人选择沉默，也许是他不知道你的计划会发生什么，更糟糕的情况是他心里清楚完成不了，但是看到别人没有发声，所以就不讲话了。当完成不了的时候，你会生气的跟他说，为什么你觉得完成不了，当时评审的时候不说出来，为什么你已经发现完成不了没有反馈给我？
 
      实际的情况要比你想的更糟，如果这是一个在关键路径上的任务，你不得不要考虑修改你的进度计划，或者发现项目延期时，你的项目成本可能就要超支了，你唯一能够做的，就是让大家不停的加班。一个蝴蝶效应即将在你的项目发生。推倒这个多米诺骨牌的人不是你的成员，而是你自己。从一开始你就把编制进度计划推导出的工作量，等同于了完成产品的工作量。
 
       项目的需求是客观的，因为你必须完成那么多的事情，但是假设却是主观的，工作量的推导如果是基于需求的规模，那么有可能比你用假设的人数*工期来的更加有说服力和指导性。如果 你的需求还没有梳理的如此清楚，OK，你需要的是一份能够把需求调研清楚的短期行动计划。
 
       如果你不要求你写的总体计划准确性那么高的情况下，你可以基于一些假设来完成它，但是你要清楚这个如果作为你项目绩效的基准和你的钱挂钩了，那就真的要仔细考虑一下。
 
      
 
       
 
   

相信大多数的软件测试工程师都听说过或者简单了解过测试计划，但是你真的知道什么是测试计划么？你真的知道如何编写测试计划么？
大多数人应该是一脸茫然。
百度的结果五花八门，有没有相对规范的标准呢？答案是没有，至少我没有找到。
那么今天我就结合经验和对一些国内技术前沿的公司跟大家聊一聊什么是测试计划以及如何编写测试计划。
计划的必要性
在我们日常的工作和生活中，经常需要做计划。古人云：凡事预则立，不预则废（《礼记.中庸》），也就是强调预先计划的重要性和必要性。
我们做项目，项目需要定项目计划；测试作为项目中的一部分，当然也需要制定测试计划。
测试计划就像是我们写论文一样，首先做好提纲，才能一步一步的完善填充，有了测试计划就掌握了整个项目的进度和方向，在工作中可以有个指导的作用，不至于偏离工作方向
测试计划规定预期的目标，以什么样的程度完成和在预期多久内完成，这样的规定能够使工作人员做好心理准备，合理的期限和目标能够使工作人员不松懈，有效率的完成一个项目
计划作为对未来工作的规划，肯定会受到突发的或者不稳定的因素影响而导致整个项目出现延期甚至无法进行的结果。因此计划中对于风险评估的必要性就在于罗列出影响整个项目进行的因素，并制定相应紧急方案，将损失降至最小化。
人员的安排呈现合理化。任何一个项目内的工作都有难易繁简的划分，因而才需要有专长的工程师进行对应的测试。难度较大的由资深测试人员安排，难度小的由新进实习生来进行，整个项目的进行就会显得合理化层次化条理化。同时将职责清晰地具体划分到个人身上，也有利于日后的纠错，及时发现哪个环节出现问题。
测试计划的制作是在需求分析完成之后所进行，所以测试计划的执行在一定程度上也是对需求分析的进一步的检验，若在制定过程中，发现有不合理的因素存在，还能及时反馈，进行调整，不至于使众多的人力做了无用功。
测试计划的安排也是一个项目中多个部门间合作的工作指导，一环扣一环，工作的交接在时间上做好详细的备注，才能让部门的合作显得默契。
一个测试计划制定者的素养
有多年从事测试工作的经验，能够条例清晰的罗列出测试中的流程和应当留心的步骤，以及不可缺少的风险规避的意识
对于部门的员工能力要有一定程度的了解，才能合理的安排工作内容
高压下的冷静处理能力，一旦项目出现突发的严重问题，能够冷静找出出错环节。
人际沟通的能力，一个测试计划也是有与其他部门之间的合作关系，需要与其保持及时有效的沟通，了解到他们的需求
那么我们什么时候来做测试计划呢？
一般来说，在产品需求确认，做过测试需求分析之后我们就要开始编写测试计划。当然测试计划编写的工作要根据工作实际来决定，也就是具体情况具体分析（政治课学的哈~）
其实，要想做好测试计划必须有一定的测试经验。那么下面我就结合工作实际，跟大家聊一聊测试计划的内容。
测试计划的内容
测试范围 明确测什么？比如：产品的具体业务需求有哪些？产品是web端的还是移动端的，还是两者都有？
测试策略 明确怎么测。对不同业务需求，具体要有哪些测试类型、测试场景、测试方法。
资源安排 包括测试人员的安排，测试环境是怎样的，测试工具的选择等。
进度安排 在明确测试范围、方法和人员之后，我们要考虑什么时候开始测试，预计要测试多久？以便和开发计划、上线计划衔接。
发布标准 发布标准是测试完成和产品上线需要满足的条件，以便项目内所有角色都有一致认可的目标。怎样才算是测完了？达到怎样的标准才可以上线？
风险预防 最后，我们需要对整个测试过程中可能存在的风险，以及当这些风险发生时的应对措施提前进行一些考虑和准备，并在测试计划中体现出来。
我们把这些内容模板化，形成测试计划的模板。无论是在实际的工作中还是大家学习编写测试计划，都可以用这样的模板来使用。

在此给大家分享一个测试交流群：672899761。
我就是为了来分享一个模板么？当然不是，那不是我的风格。
在此模板的基础上，我们一点点来剖析如何编写测试计划。
首先我们的依据是项目的交互稿和需求分析结果。
交互稿：

功能分析结果：

第一步我们来明确测试范围

测试范围的确定来自于需求文档，比如本次需求的目标：要求用户可以成功参加课程。我们功能测试需求分析的结果为用户成功参加课程，涉及到浏览课程、参加课程、学习课程三个模块。

然后考虑兼容性测试、性能测试这些测试类型。我们把我们分析的结果填充到模板中的测试范围这一节中，明确需要测试的也无需求和需要测试的测试类型。

接下来我们来写测试策略的内容

我们要根据不同的测试类型考虑不同的测试方法，对于功能测试，我们根据需求分析的思维导图和功能测试的测试用例覆盖浏览课程、参加课程、学习课程三个模块就可以了；兼容性测试，我们要根据产品的应用场景来考虑，比如IE、Chorme、ios、android、不同机型等等；性能测试，根据产品架构、预估数据、线上数据来判断需要执行性能测试的功能接口（比如登录接口）；接口测试，安全性测试等等要根据实际的项目需求来确定。

然后我们将需要用到的测试类型按照测试场景、测试方法等以引用文件的形式填写到测试计划中去，以便让所有项目人员清楚的知道要做哪些测试工作以及怎么做。

接下来我们要考虑测试人员的分工和测试资源的分配

比如说，测试人员数量不够或能力不够的时候，就要额外申请测试人员。
测试资源我们一般包括两方面：测试人力资源和测试环境资源。测试人力资源包含两个维度：测试人员数量和测试人员经验、能力。环境资源一般包括：

在我们的测试计划中，测试人员分配、测试环境资源、网络资源、工具使用都要明确写出来。

接下来，需要做测试进度安排。

测试工作的进度安排依赖于开发工作的节点和提交测试进度的时间，并且直接影响预期的上线时间。所以我们需要根据产品业务的复杂度、所需要进行的不同的测试类型的复杂度、产品上线的质量要求的高低、测试人员的数量、能力和经验这些因素，来评估不同阶段、不同类型的测试工作的工作量。比如冒烟测试的工作量、大概有几轮回归测试以及工作量、性能测试的工作量等等。然后对测试人员的分工进行安排，明确职责；那些人进行功能测试、谁来负责性能测试。最终来预估测试工作开始和结束的时间节点，比如预计什么时候可以开始性能测试；预计什么时候完成第二轮回归测试之类。在整个测试过程中，测试团队需要输出的文档也都需要列明，比如测试计划、功能测试用例、性能测试方案、bug数据、性能测试数据、测试报告等等。

在我们携程XXX项目的例子里，大家可以清晰地看到进度安排的详细情况。

好的厨师需要有能够判断好的菜品可以出锅的标准，同样的道理，在测试工作中也需要有标准或一致的目标，来判断测试阶段是否可以结束、产品是否可以上线。这个标准或者目标一般来说包含两个方面：一是测试工作完成的标准，二是产品可以上线发布的标准。这两个目标既相互有关系，但又不完全相同，两者都需要在项目团队内达成一致和共识。

测试完成是产品发布的前提，但产品上线前还有其他一些需要完成的工作。我们分别来说明。
首先是测试完成的标准，也就是说做到什么样算是测试工作做完了。主要包括：1、测试计划里所有测试类型都已经完成了 2、功能上、兼容性上没有影响用户使用的Bug 3、允许遗留小部分影响不是很大的Bug，但这个数量应该小于一个值 4、性能上符合设计目标和上线要求 这些标准都是针对测试工作本身的要求。

在满足了测试本身的前提下，产品要发布还需要满足哪些要求呢？比如说：1、产品需求都已完成 2、交互视觉走查都已完成 3、一流的小部分Bug项目组完成了风险评估，都认可且问题不大 4、产品使用说明或用户手册或更新log都已完备等等。

在我们携程的例子里，测试完成标准和上限标准有如下：

在我们的生活中，网网计划是美好的，现实是残酷的。

测试工作亦是如此，很少有计划是完全可以顺顺利利执行完的，计划本身也需要更新维护。所以我们要对测试过程和产品质量可能会发生的一些问题和风险做好应对准备，避免问题真的发生后出现连锁反应，影响整个测试和项目工作。
测试风险一般包含这样几类：一是测试范围的风险，比如说一开始测试需求分析不准确、不到位漏了测试点，甚至某个测试类型遗漏了，这样问题就比较大了，所以测试需求分析是整个测试工作的基础，还有就是产品需求变更的风险，加需求、减需求、改需求都需要重新进行测试需求分析，需要测得一定要测到，不需要测的就不要浪费人力物力和工作量；二是测试进度的风险，比如说做计划时工作量估计的不准，测试做着做着发现时间不够导致项目延期，还有测试依赖开发，可能开发工作没有按时完成或改bug不及时导致进度延后，还有可能测试人员因为别的项目更重要抽调走了或者请假、离职等原因造成人员变动；三是产品质量的风险，比如开发的代码质量比较低或者测试人员是新人对业务不熟悉，能力和经验有所欠缺等等。

在携程某项目的例子中，列举了一些可能遇到的风险：

到这里我们就完成了一份测试计划。有的人可能依旧存在疑问：做计划真的有那么重要么？我们实际工作中有很多项目根本就没有计划依旧可以完成的啊！我们来看一下不做计划可能会有哪些问题~
首先，如果没有计划我们无法预估工作量和需要的测试人员数量。一个项目的工作量和需要的人员数量都没有依据，在公司里怎么来协调和安排呢？
其次，测试人员的分工明确，会导致工作重复和遗漏。出了问题大家可能都觉得不是自己的问题，导致工作混乱效率低下。
再就是测试进度失控。到底什么时候做完没有一个预期，其他的团队怎么安排工作呢？进度有没有失控也没有判断依据，临到预计的上线时间才发现还有很多没有测到、没测完，直接影响整个项目的进行。
还有就是应对需求变更困难，对可能出现的风险没有准备。一旦出现问题，大家一片混乱，很容易导致测试遗漏和项目延期。
最后就是没有统一发布标准，上线意见不一致。测试团队认为Bug太多不能上线，开发团队认为都是小Bug不要紧，先上线再说，导致争执不下的局面。、
当然根据项目不同还可能存在其他一些列问题......
总而言之，测试计划的作用非常重要。
指导测试过程
协调项目安排
提高测试效率
提高测试质量
做测试计划对测试人员的能力和要求是非常高的，从另一个角度来说，测试计划可以体现一个测试人员的自我修养。一个测试人员需要很好的经验沉淀、有很多好的全局意识才能做好一个项目的测试计划。
希望大家都能够很好的胜任编写测试计划这项工作。
文章来源：https://blog.csdn.net/KnowledgePower/article/details/80074161

工作日志简介
 
　　工作日志顾名思义就是针对自己的工作，每天记录工作的内容，所花费的时间以及在工作过程中遇到的问题，解决问题的思路和方法。最好可以详细客观的记录下你所面对的选择，观点，观察，方法，结果和决定，这样每天日事日清，经过长期的积累，才能达到通过工作日志提高自己的工作技能。 
 　　随着移动互联网时代的到来，QQ，微博，微信等新应用层出不穷，人们对于时间资源的需求也越来越大，而另一方面，时间的碎片化往往让很多工作者结束一天工作的时候，却想不起来今天到底做了哪些工作。工作日志在帮助人们抵抗时间碎片化方面能够起到一定的作用。 
 
写过日志，但写过工作日志，可是这次培训实习要求每人每天写一篇工作日志，且发布到博客上，不知道工作日志该怎么写，也偷偷看过其他同学交的日志，有的看起来跟小学生的流水账日志一样，感觉不太靠谱啊，然后上网搜了一下范文，模板之类的，感觉程序员的工作日志至少包括一下几个方面吧！
 
1、学习总结 
 内容：在自学或别人指导的过程中，收获的知识或技术的总结。 
 目的：总结的过程是对知识的回顾和梳理，让你理解更深刻。
 
2、工作总结 
 内容：每日任务的进度，项目的进度。 
 目的：了解每天任务的完成情况，把握整个项目的进度，有利于计划的调整。
 
3、问题总结 
 内容：在学习或工作的过程中遇到的难题及解决办法。 
 目的：相同的错误不能总出现，出现相同的问题，要能快速找到解决办法。
 
4、明日计划 
 内容：计划下明天的任务。 
 目的：有计划，才能更有效率地完成任务。
 

 
工作日志模板
 
日期
每日工作记录
完成情况
今日工作计划
计划完成情况
周一
周二
周三
周四
周五
 
工作日志是记录任务来源及任务输出的工程，因此，对于员工来讲，工作日志的提醒作用就体现的非常明显。员工在实际操作过程中，可能会同时进行多项工作，在从事实际操作过程中，可能会注意小的现象而忽略重要的事情，所以及时的查看工作日志，并进行标注，对企业的每一位员工都有重要的作用。
 
工作日志怎么写
 
工作日志的目的是帮助撰写者反省总结一天的工作，不断改善提高自己。所以一篇好的工作日志，可以从时间、内容和感想三个维度来考量。 
 
时间维度
 
能够如实的记录自己的时间消费记录。将自己在某些事情上的花费的时间记录统计出来，从而判断自己工作效率究竟如何。
 
内容维度
 
每天的工作有一些事情是自己原来安排好的，有的是临时发生的，有的任务是短期独立存在的，有的任务是长期并且和其他任务相关的，有的事情自己一个人可以搞定，有的任务可能需要自己的同事、朋友、客户等多方参与。在处理这些事情的过程中，工作日志需要详实的记录任务的进展，能够根据当前的发展情况，列出下一步行动清单。
 
感想维度
 
人是理性和感性的混合体。工作中肯定会有失败的苦闷和成功的喜悦，这些感性的认知丰富着我们人生的阅历。通过工作日志抒发记录自己工作中的喜怒哀乐，能够缓解自己的工作压力，保持对工作的积极态度。
 
工作日志格式
 
时间
工作项目及工作内容概述
9：00—10：00
10：00–11：00
…
 
不同的员工从事的业务是不同的，其工作内容就会有本质上的不同。因此企业员工的效率及工作的及时性就非常难进行控制，因此企业的最高管理者就应该把工作日志看成是追踪的重要手段。
 
个人工作日报模板
 
工作日报
时间
工作内容
存在的问题
解决方法
 

 工作日报模板
 
 
工作A
时间
结果
背景
过程
总结

导读：
 
程序员开发时间越久，跟文档打交道的时间越长，需要记忆的东西就越多。每到写周总结的时候，已经忘记本周做了哪些工作，为了防止这种情况，强烈建议养成日志习惯！工作日志的内容不限，可参考下面的模板
 
 
 
计划 当天的工作计划 ，具体到可以完成的一个很小的任务
学习 工作中接触的新内容，需要学习的地方，记录下来，及时充电
工作 实际完成的工作内容，周报主要参照内容
其他 包括会议，考勤，搬位置等其他特殊情况的记录
 
计划
 
 
XXX周例会（上午9：30-10：30）
 
 
统筹昨天完成情况和今天的计划工作（10：30-11：00）
 
 
具体工作A（11：00-12：00）
 
 
具体工作B（13：00-15：00）
 
 
具体工作C（15：00-18：00） 
 
 
 
学习
 
 
学习spring cloud框架第一章
 
 
mysql性能优化之——索引优化
 
 
hadoop深入学习第二章
 
工作 
 
 
完成工作A
 
 
完成工作B
 
 
工作C未完成（由于开会）
 
其他
 
周例会，主题：讨论sass供应链系统原型UI会议15：00-17：00
 
 
通过以上几步，相信一天的主要工作了然于心，写周报的效率也提高了很多。希望大家能够坚持下去！