【笔记】关于电信产品测试
http://www.51testing.com/html/41/382641-238654.html
一般的电信产品架构为以下模式：
硬件产品—软件嵌入式平台—具体功能软件实现（包括MIB与命令行）—网管软件（包括C/S与B/S架构，有些电信设备商没有网管）。
电信产品的测试与单纯的软件测试有所不同：
1、涉及硬件、软件两个方面；
2、系统测试的比重非常大（功能测试、性能测试）；
3、业务流程相对复杂，常常涉及到方案的提供，所以对业务的熟悉与理解非常重要，测试工程师同时负责需求的制定与评审、业务流程的制定；
4、系统测试的功能测试部分主要体现在网管（有些还提供CLI）功能测试；
5、设备的性能测试：一般难以借鉴业界现有的工具，自开发的工具调用设备通信接口测试，常用脚本语言python、Ruby等,要求可维护性复用性要高；
6、网管的性能测试：根据架构选择方案；模拟网管操作进行测试，IDN网管为C/S架构,JavaGUI测试使用Abbot测试框架（基于Junit实现）进行，B/S架构的网管可以借鉴的测试框架会多一些。
综上，电信产品测试要求开发技能、业务技能，其中相对软件测试，电信产品测试对业务技能要求比重较大。
业务能力提升：学习项目，分解需求，指定测试计划，编写测试用例，测试，各阶段版本状态分析，Bug跟踪，问题整理跟踪；成为业务“专家”；
测试过程体会较多：对于测试过程方法、软件工程相关、Bug管理、问题跟踪等方面较多体会。
测试不够深入：项目深度不够，对测试只要求业务程度，没机会深入，导致测试技能锻炼不足；
关于自动化的测试：
自动化需求分析设计—自动化测试用例设计—自动化测试脚本开发—自动化测试执行阶段；
自动化没有流程控制，难以上规模应用；
设计方案不佳，脚本的维护带来大量的成本，最终无法维护；
手工测试的辅助：依靠测试用例，支持手动测试中较固定简单的流程，例如用例登录等，控件的检查等，大大减少人力；
例行测试：依据固定的环境平台，进行的回归测试等，这部分的用例也是来自于手动测试环节；
设备通信的测试：只能依靠自动化进行；
脚本级别测试，脚本维护随意，脚本之间配合度不高，底层稳定性差，难以支持自动化大规模进行。
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
