最近在各博客中看到不少同仁在聊现在越来越热的测试技术和测试工程方法，而本人也在一个通讯公司专职测试摸爬滚打了多年，其中有些心得，希望使用容易理解的语言组织成系列和广大同仁分享。其中可能涉及测试技术、测试设计方法、测试建模、测试流程/开发流程、测试管理、测试度量等方面，如有不确之处，还请多多讨论。

　　搞技术的都知道，技术钻研的越深，越容易有技术情节，但不论如何，测试本身就是一个发展中的行业，特别需要不同方面的声音，希望大家着重关心不同情况下适用的技术本质，而不是无谓的争吵。

　　总体来介绍一下一般的测试活动，目前一般比较上规模的创新技术公司或企业，会设立专门的测试岗位，而测试岗位根据具体职位不同有很大的区别，例如厂验（出厂测试，抽样检验产品的合格率），SIT系统集成测试（在开发后期，根据用户使用场景进行测试），SDV系统设计验证（在系统开发阶段，转测试的第一个环节）等等，总体来说，测试工作越向前介入开发阶段，测试含金量越高。而目前各大技术公司逐渐从瀑布、螺旋开发模式逐渐向迭代开发、增量开发、敏捷开发靠拢，越来越关注测试在设计阶段的重要作用，这些都会在后面系列逐一介绍。

　　我们一般用户接触到的也有测试，例如最近Firefox的Beta测试，微软的体验测试等，这些测试都有一个共性--看不到系统的实现方式，纯黑盒体验测试。方才也提到，测试活动越靠前，越了解系统，越懂得各个开发阶段所使用的测试方法。

　　在瀑布模型中，开发一般必做的是单元测试，自己写代码，自己打桩写测试代码，主要验证语法、逻辑等基本问题，这里有个问题，测试有个主要的思想是“避免让程序员测试自己的程序”，这是一般是指系统测试，开发人员进行单元测试的效率是很高的，首先自己保证没有导致编译不通过的低级错误、内存泄露等隐藏很深的错误，此类错误在系统测试也可以测试，但成本太高；同事之间的代码Review也是很好的错误检测方法；在各个模块接口完成后，可以进行基本功能联调，这时出现的接口问题是主要的拦路虎。一般有积累的系统，会使用模拟器仿真系统，在实际仿真环境调试，这样效率很高。

　　对于转测试后的系统，一般有BBIT、SDV、SIT、发布测试等环节，BBIT是在开发系统转测试前，由测试人员对开发人员交付的系统进行转测试验收的测试活动，保证转测试的系统满足可测试性要求，如果是分几段合入得子特性，也可以做BBIT测试，依避免新合入的特性对主线版本较大的质量冲击，BBIT 测试是一个很好的测试把关环节，如果BBIT不通过，可根据情况打回版本或特性，并针对DI（遗留缺陷）进行质量回溯，避免重复错误。SDV测试时针对系统中不同的功能特性进行单独验证，一般是搭建一个完整的系统环境，由不同的测试人员进行单个功能特性测试，例如通信系统中OSPF、BGP、MPLS LDP等是组成路由器的核心功能，可以由三个测试人员分别验证这三个特性，可根据特性规格、产品规格、标准、使用场景等进行单个特性的功能点测试，保证单个特性的可交付性，这里，在SDV阶段一般不进行性能测试和压力测试，因为此时在基本功能还存在Bug的是否进行性能、压力测试只能让开发忙于解决致命问题，可能有火上浇油的意思，而没有时间思考和反复验证合入的修改代码是否会引起新问题。在SDV各个功能点验证基本充分后时，可以进行性能摸底测试，输出性能摸底报告，给出性能结论。此时，如果性能远不满足要求，而提升的手段也不足以产生质的变化时，这时，就有必要反思一下系统设计阶段的结论了。例如在非常复杂的路由器系统中，可以使用性能建模来分析将来系统的指标。SIT测试中，主要是针对实际应用场景进行特性叠加测试，例如一般在接入侧用户会同时使用 OSPF和MPLS完成域内隧道搭建，这两个特性同时使能是否会有干扰，例如目前很火的VPN技术就是BGP+MPLS的交叉技术，此时在系统中同时使能 L3VPN+MPLS+BGP+OSPF是否可以顺利完成各自的功能，性能是否有影响等。

　　总之，测试层次分的越深，各个环节的输入件和交付件的质量关系到整个测试环节的整体质量。后面的系列中会介绍在测试流程中的各个环节是如何紧密结合的，各个环节的输入和交付件等。

版权声明：本文欢迎转载，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。