怎样才能从菜鸟发展到高端软件测试工程师？

sincor

怎样才能从菜鸟发展到高端软件测试工程师？
感觉整天写word 编脚本  用用软件好像没有什么提升？

高端的软件测试包括些什么？


转一篇文章


【微软培训心得】
周末的时候听了微软测试的培训，颇有感触，主要是测试的方面的培训，也包含了微软做项目的流程和方法。从微软做项目的流程上，如何使上千人或更多的人有良好的协调，保证项目的质量，可见一斑。
        从需求开始说起，正如我们所知需求是一个项目的灵魂，如果需求偏离了，后面的开发测试可能要走很多弯路。需求不明确，迫使开发人员按照他自己的想法去设计，可能出来的结果不是客户所需的。导致大量的无效代码写出来，被推翻，然后再继续，又被推翻……有句老话叫：失之毫厘，谬以千里就是这个意思，如果为了抢进度，而在需求这部分挤时间的话，到了项目的后期就必须要花成倍的人力，物力来弥补。测试在需求不明确的情况下测试，有些早期可以规避的设计问题在后期发现，无疑于亡羊补牢而非未雨绸缪。
那么微软是怎么样做的呢？一个大的项目，分成若干子模块。每一个模块对应一个需求人员，一个开发人员和一个测试人员。微软的项目是没有概要需求的，从长期总结下来的经验看，概要需求的设计作用不是很大，因为没有什么内容也很容易导致概要需求的评审大家也都是很happy就通过。直接就是详细需求文档，要详细到每个接口的定义，甚至每个输入框可输的数据类型。这个模块的需求文档出来之后，都有什么人参与评审呢？其中包括，此模块的开发人员和测试人员；开发经理和测试经理（评审需求用来保证和其他模块兼容）；市场人员（从用户角度考虑）；大头（据说是比尔.G直接的下属）这六个人去评审这个模块的需求，这六个人一起去看需求文档是否合理细致，实行一票否决制，任何一个人不Sign Off都不能通过。之后就是这个模块的详细设计文档（开发人员）和详细测试计划（测试人员）。这就保证了开发和测试的并行。同样，详细设计文档和测试计划也都是六人评审制。为什么需要那么多的人评审？是要在做事之前，让其他人帮助你看你想清楚了没有，人无完人，一个人想的再全面也有可能有疏漏的地方，所以聚集其他人的力量帮你想清楚避免走弯路。假设某个项目有30个模块的话，意味着大头要看30个模块的需求文档，30个模块的详细设计文档和30个模块的详细测试计划。他将需要看90份文档，这样，就能够保证了整个项目了然于心。我听到老师讲的很震撼的话就是，在微软是没有QA的，因为在微软每个人都是QA.
        接下来是开发过程。因为不是重点，讲的不是特别细致。主要的核心点是如果来预防缺陷要高于如何解决缺陷。严格按照详细设计文档来编码，就不会产生之前的大量无效代码的情况。开发团队还需要有Code Guide Line编码规范。认真执行编码规范。开发人员在check-in之前要保证自己的编码为有效代码。如何保证开发人员的编码为有效代码呢？这就引入了自动化测试，为了保证编码有效，就要利用自动化测试工具来保证。思路是用程序来检查程序。在编码的过程当中，运行自动化测试工具能帮助开发人员边编码边检查。提交上去的代码自然要比没有经过编码检查的质量要高很多。这样就做到了边开发边测试，也就是所谓的“极限编程”。当然微软的自动化测试工具都是自己开发的，量身为项目本身所打造。
自动化测试，它是软件质量的保障体系，自动化测试最大的优点就是把重复性的劳动交给计算机去做，包括review静态代码，每个版本更新后都需要重复测试的功能，或者是大量的数据的重复操作。这些如果在项目之前都开发完成的话，对于软件的效率会有极大的提高。但是有利有弊，自动化测试也有一定的局限性：
        自动化测试前期投入很大，包括编写自动化测试工具，开发自动化测试脚本。如果项目周期短，没有可持续性不适合自动化测试。
        自动化测试的技术门槛相对较高，测试团队整体水平不高的情况下无法完成工具的发开，心有余而力不足。
        对于没有预期结果的测试，不适应自动化。
        对于用户体验的测试，主观性比较强的不适应自动化。
下面就从测试计划开始：
基于前面详尽的需求文档，测试人员开始制定详细测试计划，和详细设计可在同一时间完成。完美的测试是90%的测试任务和开发并行完成，10%的测试任务在开发之后完成，还是刚才说的，预防缺陷要比解决缺陷效果好的多。让开发人员边开发就边测试自己的代码使之都是有效代码。测试计划中除了包含常见的测试内容，功能测试，性能测试，健壮性测试，安全测试，界面测试等，还应该考虑到UE用户体验测试，因为用户体验的好坏是决定商业上是否成功的标准。不仅把产品做到能用，还要把产品做到好用。所以产品开发完成之后积累用户的反馈也很重要。还有风险的方面，包括自动化测试工具的使用，售后升级是否有保障等。需求不明确所导致的测试时间的延长，这些都要计算到测试风险之中。关于架构的测试是十分重要的，一定要提前到需求层面上。当然系统架构师需要极高的技术壁垒来保证系统的架构。
        制定测试计划中，人员不充分，经验不足怎么办？从工程的角度考虑问题，不仅仅是要求测试人员之间分享经验，还需要有效的标准。一个好的模板，是节约人力成本的好办法。还能弱化对每个人的依赖度。还要检查需求细不细，避免主观语句（性能高，响应速度快等这样的形容词），速度响应快，快到多少秒。一定要量化需求，而不是主观感受。凡事以数据说话，这样才能有说服力。
        如何提高测试用例的编写水平？第一，积累测试素材，比如对于文本框的验证，一般都是验证那几项，有效数值，无效数值。空格，空等等。这些测试用例在每个项目中都可以反复使用。第二，测试方法的复用，对于有继承性的项目来说，用之前编写的测试脚本或自动化测试工具以达到测试方法的复用。
        如何判定测试是否充分？验证到每个对象的每个属性值，结合自动化做深度测试。
        测试对bug的理解不一致怎么办？有争议的地方和开发人员商定，确认后建立checklist或者user guide line，列出检查清单。以后如发现此问题，对照清单解决问题。
        如果衡量缺陷的质量？1）检查环境，测试环境是否正常 2）是否可重现 3）检查是否是重复bug 4）详尽的操作步骤 5）问题的定位 6）要能提出修改意见就更好了
        缺陷的分类比一般的分类多的项有：测试引起的；由其他bug引起的；功能未实现的。
执行测试的过程当中，限定解决缺陷的时间，即check-in ETA估计完成时间。真正把每个问题都落实到微观。这些缺陷分配是由Triage Team来做,由上面说的高层领导组成，试想这样一群人看过90份文档之后，对项目的细节都清清楚楚，自然能够有效的保障产品的质量。通过缺陷管理平台，微软的高层清楚的知道某个开发人员的代码有效率是多少即使他们未曾谋面。目前有很多跨地域管理的问题，管理者不可能时刻都盯着手下的人在做什么。重要的得到信息的方式，做到用数据管理，以事实说话。
测试后期到准备发布阶段，发布评估标准（Release Criteria）：
        95%的测试用例通过率，且持续时间>5天。
        允许有5%的case不通过，但级别不能是重要的case..
        代码覆盖率>85%
        ZBB零bug边界，保持15天
测试项目之中的管理，以数据为依据，分析bug的曲线，做到防微杜渐，知道目前的项目进展状况并估算项目的进度是否在可控范围内，才能保证项目顺利进行。对于项目的流程的制定，过于复杂的流程如果过于难以执行，则会降低纪律的可执行力，所以针对不同的项目制定不同的流程。但是一旦制定，就要落实。分配任务的时候要落实到每个人头上，不能把一个任务交给一群人做，要明确到每个人做什么模块。合理的制定里程碑之间的工作计划，循序渐进逐步完善：
        短期计划：制定计划模板，添加bug的规范，check-in之前做代码检测。
        中期计划：调整缺陷管理库，做到测试用例和bug关联
        长期计划：开发测试工具，做到自动化测试。
        2天微软的测试培训时间并不长，也没有介绍任何的测试工具，但是确确实实的给我们讲了一种做项目的方法和态度。微软之所以能够成为做产品的大哥，关键在于对产品质量的要求，“在质量面前什么都不重要”。我对于项目的朴素的理解就是，每个阶段把握每个细节，认真落实文档，目的是让其他人帮你想遗漏的地方，然后严格遵循文档开发，用实际的数据说话。每个人都担当起QA的职责，监督团队的其他人，互相促进和发展，项目的质量就会大有保证。

archonwang

没有做够体力活，没有足够的知识涉足面，是不够资格成为一个高级测试工程师的。

楼主大家一起加油。

qingrou

难怪微软能做大做强。
它有太多我们所缺少的观念和制度。
看过这篇文章，又让自己更清醒了点，看到了差距也看到了自己需要努力学习的方向。
这篇文章真是太好！
谢谢楼主。