标签：http io 问题 代码 ar 工作 linux 时间
之初 ， 2013-11- 11
总结项目过程中的工作得失，为以后工作中更好发扬优点，改进缺点。
Netframe是基于Intel DPDK开发的高性能转发平台。它的目的是保证高性能转发的基础上，屏蔽底层细节，给上层应用抽象出通用的设备管理，提供网络特性，协议栈，友好的API接口和配置方式。
在项目中途进入测试，主要负责测试 management、device、route、ecmp、arp、cam、login等模块，一共提交197 个bug。 本总结涉及时间范围为20130902 - 20131108。
9月份主要进行CLI测试和功能测试，提交73个bug。
10月份主要进行性能、事件和文档测试，提交98个bug。
11月份主要进行回归测试和随机测试，提交26个bug。
虽然以前没有测试过LINUX网关产品，但由于基本的网络知识与交换机路由器相同，上手快，刚开始就发现了不少Bug，预感此项目会有大量Bug, 项目时间紧张，没有时间编写编写详细的测试方案，因此编写了简单的xmind格式的测试点。虽然是第一次在项目中采用xmind格式编写测试点，但结合发散思维，发现了更多的bug， 取得了良好的效果。这种方法值得继续研究和改进。
由于测试点写得非常简单，在测试时还有会遗漏；在测试后也没有记录对应的结果，导致测试多了有些未写测试点在某个版本是不是有问题；太过简单也不利于交流和评审。下一步需要将测试点进一步细化，对xmind进一步熟悉，逐步建立测试点的表现形式和详细程度规范，最后再看看如何结合kelude提高下测试记录的效果。
本项目大部分时间在测试和提交bug，只有少部分时间用于学习和思考。对NetFrame的实现原理的掌握既不全面也不深入，希望在新的项目中通过学习设计文档及与开发工程师的沟通，能全面深入的掌握实现原理，发现更深层次的bug。
当前我还没进行本项目的自动化脚本编写工作 ，这是接下来的重点，希望进一步提高编写自动化测试脚本的效率。
虽然本项目提交了大量Bug, 但开发工程师大多能迅速解决，不至于影响测试其它用例的进度。
没有设计文档，不利于测试工程师学习原理，定位问题，发现隐藏更深的bug。
解决Bug时没有详细说明Bug产生的原因以及修改方法，不利于回归测试及做进一步的扩展测试，也不利于peer review。在这方面 @白鹏 做的比较好，要赞一下。
从NetFrame的测试结果来看，基本功能问题很少，但易用性，性能，事件方面存在大量bug，性能测试时更是出现了许多core dump的严重bug。 产品的质量是由多方面决定的，希望开发人员在设计和编写代码时，不仅仅考虑实现功能，同时要考虑易用性、性能、安全、可维护性、事件等方面。在自测时解决可以轻易发现的Bug，减少沟通和提交bug的时间成本，给测试工程师更多时间发现更深层次的Bug，共同提高产品质量。
NetFrame 项目中期总结报告,布布扣,bubuko.com
标签：http io 问题 代码 ar 工作 linux 时间
原文地址：http://www.cnblogs.com/root-wang/p/3878400.html
