2016.7.7 一次低级错误导致的产品缺陷

十分忧伤，在程序上的低级错误，导致了产品出现了漏洞，而且已经出了一些货，当然现在懊恼也无他用，还是需要好好的总结不足。
1、对RT-Thread操作系统不熟悉

现在来分析一下出问题的代码：

static void comm_proc_thread_entry(void* parameter){... ...rt_thread_delay(20);//... ...if(NEW_OPB_RS485){while(1){if(rt_mb_recv(&comm_mb,(rt_uint32_t *)&value,RT_WAITING_FOREVER)==RT_EOK){tb3_rs485_modlue.set_rs485_port_fun(38400,USART_WordLength_8b,USART_StopBits_1,USART_Parity_No);if(tb3_elempu_modlue.comm_fun!= RT_NULL){tb3_elempu_modlue.comm_fun();//发送板间通信数据}comm_thread_check = 0 ;}}}//使用旧方案else if(OLD_OPB_RS422){tb3_rs485_modlue.set_rs485_port_fun(38400,USART_WordLength_8b,USART_StopBits_1,USART_Parity_No);while(1){if(tb3_elempu_modlue.comm_fun!= RT_NULL){tb3_elempu_modlue.comm_fun();//发送板间通信数据}comm_thread_check = 0 ;rt_thread_delay(5);}}}

        我居然相信了上述代码的可靠性，而且没有去推敲这几句代码的实际使用情况，因为该县线程这样写的话，两个判断条件在经过了开始的200ms延时后就开始进行工作，万一在200ms内两个条件的标志位都不成立，那么就不会再执行。

而很明显，在电梯上电的时候，电源肯定比电梯信号来的快，而这两个条件的判断需要电梯信号的触发，所以就悲剧了。

所以，应该在两个if判断语句外再加一个while循环，然后每隔50ms执行一次，这样就不管电梯信号什么时候来了。

2、测试不全面

        发现很难，现在的职位既是写程序、做硬件的那个，同时也是做测试的那个，当然，这些都是一些客观原因，主观上还是自己测试不够仔细。

怎么办？以后涉及到电梯的产品，定义一些功能点，总结以往的经验，看那些地方比较隐藏，但又容易出问题的地方，列一个功能的表格，测试的时候，每个表格都有相应的说明，必须这么做，宁可杀错，不可放过

3、测试条件实在比较缺乏

       此次产品针对的是日立的进口梯产品，估计整个日立中国就这么一个试验台，而且路途遥远，厂房又诸多限制，真的很难做好测试。不过关于公司在产品测试上的槽点就不想在这里说，只能说，很多条件，没有条件就只能自己创造条件。