“凡事预则立，不预则废。”告诫我们准备的重要性。想要做好测试，一样需要充分的准备。尽早介入项目，有利于测试人员清楚项目的方方面面，比如项目的支持状况、需求文档、概要设计、详细设计、数据库表结构、存储数据特点、表关联和索引的建立等等细节。要了解这些细节，所有的启动会议，产品需求会，架构讨论会等等，都要去参加。虽然可能在流程上，公司没有规定测试要参加这些会议，但你可以向测试经理申请参加，因为你有足够的理由告诉他，这是为了保证项目质量，为了多了解项目信息。在系统被开发的这段时间，均可以利用来参加各种会议，做好充分的测试准备。在参会了解项目的同时，它也解决了很多互联网企业，不注重文档，只强调沟通的问题。不断地沟通，能让你获得足够的项目信息，进而合理地编写测试计划和测试用例。
对于编写测试计划，考虑到测试中经常会出现不可控因素，导致无法精确估计测试时间。所以在编写计划时，只要大概估计不同模块需要的测试时间，简单地把计划内容控制在一页纸即可。等所有的准备工作都进行完毕，就可以进行具体的测试工作了。
完成一个项目的测试工作，通常要经过三轮测试。第一轮测试最为艰苦，时常状况百出，因此要预留整个测试周期50%~70%的时间，保证把所有测试用例执行一遍。如果出现个别用例的场景制造困难，要不断请求外力协助解决，在项目上线前，争取至少测过一遍。等第一轮测试提出的所有问题都修改完，所有严重及以上级别的问题都已验证关闭，就可以开始第二轮测试了。第二轮测试，一样要执行所有用例。由于上一轮测试已经解决大部分问题，第二轮测试的时间可缩短至测试周期的20%~30%。如果有条件，大家可以交换测试用例，进行交叉测试，这能在一定程度上降低项目的漏测率，提高测试质量。除经项目负责人确认遗留暂不修复的问题，其余所有问题都验证关闭后才能进入第三轮测试。第三轮测试，吴老的方案是把之前遇到的所有问题都再回归一遍，保证这些问题不再出现即可。我测第三轮都是在代码封板后回归主流程，其实和吴老回归所有问题差不多，都能测到主流程。
然而计划赶不上变化，并不是每个项目，都能做到理想中的三轮测试。如果遇到代码质量差或者项目时间紧的情况，就要调整测试策略，根据项目周期和测试资源，对不重要的模块，做适当的战略放弃，集中精力测试核心模块，保证主流程畅通无阻，这样也能基本满足项目需要。如果临近上线，仍然一直出现新问题，且无法呈现收敛的趋势，就要把所有没有修复的问题整理成测试报告，让所有干系人知晓，并最终确定是否带问题上线。
因为线上环境和测试环境还是有不小的差异，一般测完这三轮后，为保险起见，都要先发布一个灰度版本，把程序布置到预发布服务器上。虽然预发布服务器不对外服务，但它使用的所有数据以及架构，都属于线上环境的一个节点。吴老在测试工作中，会对灰度版本做一到两天的跟踪验证。我所在的公司，出于两点考虑，一般都交给产品或者运营人员进行线上验证。首先是安全起见，只有少部分人员拥有线上验证的权限。其次是多个项目频繁迭代，没有时间留给测试进行线上跟踪。等产品发送线上验证通过的邮件后，测试算是打了一场胜仗，就可以放心投入到下一个项目了。
不同的单位，基本都能采用经典的三轮测试法，但要是遇到比较流行的敏捷开发，就行不通了。敏捷开发采用小步快跑、快速迭代的方式，搭配自动化测试进行验证。它比传统的开发模式压力大，规定到每天要开发哪些需求，如果持续集成和自动化做的足够好，可以每天或者每小时发布，这对测试人员的沟通能力和基础能力都会有较高的要求，是一个很好的挑战。吴老建议大家如果有机会，一定要感受一下敏捷开发的流程，体验一下自己在敏捷开发中的价值，这些价值将来都是你作为高级测试人员的核心竞争力！
---记光荣之路吴老3月24日清晨分享
作者：Flyleaves
出处：http://www.cnblogs.com/Flyleaves/
参考声源：http://m.ximalaya.com/zhubo/44966139
本文版权归作者、微信公众号光荣之路和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
