2009-10工作周记

本周工作分为三部分：紧急广播、测试黑龙江新版本、技术支持与客户培训

***********************************************************************

紧急广播系统测试

    周三时接到新任务，测试紧急广播系统，之前该系统一直由研发人员自测，所以我对需求一点也不了解。有个小插曲，大猫说：一周内争取测完！

   我立刻盘算了一下时间，0.5工作日研究需求和设计文档；1个工作日写方案；一个工作日写用例和搭建测试环境（系统还是很简单的），剩下2.5个工作日测试，如果系统没有问题的话，1周应该是够用的。但是到周五我正埋头写用例的时候，大猫问测试完了没有？我瞬时被石化了。大猫还很无辜的说：我不是让你本周内完成么？

    汗，即使是部门内测，也不能这样吧，况且那个系统还是有很多漏洞的，我没正式开始测试已经发现若干问题了，最要命的是该系统发送的消息终端无法顺利接收。以上情况又跟大猫汇报了一下，他终于偃旗息鼓，安静的等待去了，嘿嘿。

    测试方案基本完成，因为没有任何确切地性能指标（我再汗，就算是个不常用的紧急系统，也不止于没有性能指标阿），性能测试部分暂时没写。

    开发同事按照我以前的一个测试用例照葫芦画瓢的写了一份，很有趣，思路果然和我们是不同的，借鉴一下后我就自己重新开始写了，因为进度肯定要延后，索性写得仔细些，没有在周五完成。

*************************************************************
HLJ ：   增加基本包优惠不同代理的限制
测试思路：

        1、在配置文件中设置某代理A享受优惠
         找到符合优惠条件的A代理用户，进行续订，预期结果该用户可以享受到优惠；
         找不符合优惠条件的A代理用户，进行续订，预期结果该用户不能享受到优惠；
         找到其他代理B符合优惠条件的用户，进行续订，预期结果该用户不能享受到优惠；
         找到其他代理B不符合优惠条件的用户，进行续订，预期结果该用户不能享受到优惠；
         2、在配置文件中设置代理B也享受优惠
         找到符合优惠条件的A代理用户，进行续订，预期结果该用户可以享受到优惠；
         找到代理B符合优惠条件的用户，进行续订，预期结果该用户可以享受到优惠；
         找到代理B不符合优惠条件的用户，进行续订，预期结果该用户不能享受到优惠；
         找到其他代理C符合优惠条件的用户，进行续订，预期结果该用户不能享受到优惠；
         3、在配置文件中添加所有代理，享受优惠
         找到其他代理（A、B、C以外）符合优惠条件的用户，进行续订，预期结果该用户可以享受到优惠；
     测试过程：下载新程序，放在D:\工作\1黑龙江\20090302，并在20上替换旧程序，重启IIS，登陆SMS后测试。
1、修改OldSubFav.txt，agentids=10001（意味着只有肇东营业厅的用户可以享受优惠），修改后重启IIS。
查找肇东分公司订购14元优惠的用户，在规定优惠时间内续订，预期结果：不能享受到14元/月优惠。
找用户李茹峰 8451002333927385，进行续订，如预期结果，继续享受到优惠策略。
注意：不能使用超级管理员登陆系统，无法辨别所属代理商。
还需要修改产品编码，确认优惠SMS产品对应的CA产品编码正确。
查找不受优惠的用户张利 拜泉分公司 8451002333335472 不能享受优惠，测试通过

2、修改Oldsubfav.txt 中的代理商设置，增加拜泉id 100006，重启IIS
8451002333335472订购  之前修改oldsubfav.txt中的发卡时间段为070125至今，但是没有订购到优惠产品。
  找一个开户比较晚，肯定在发卡时间段内  8451002333976663， 为其订购，不能享受优惠。测试有问题。
原因是使用了admin用户（总是心存侥幸，结果白费功夫，嘿）。
使用bq4\123456d登陆系统，给用户8451002333976663订购，可以享受优惠。
任选一个用户订购，也享受优惠。

3、修改配置文件，增加其他代理的id，重启IIS
用bq4为8451002333976663订购
用xinxin为8451002333927385订购
均享受到优惠，测试通过。向用户发新版本

*************************************************************************************

  TA问题终于尘埃落定：

  某用户反授权总是报错的问题已经找到原因：

    该用户的机顶盒号不知什么原因当时没有录入数据库中，导致回收授权总是失败，所以调度程序每天都会发送同样反授权指令，在casmgr日志中每日出现报错信息

    解决办法——清在泰安的数据库中执行以下脚本：

update sms_cas_entitleinfo_tab set cardno='707901096A6879BA,110293471',ended=1 where cardno='707901096A6879BA,' and endtime='20081001235959'

  已向技服人员发送邮件。

    技服人员说TA当地最近业务很多，出现登陆及处理数据很慢的问题，希望能解决。

  解决方案，无他，重启服务器而已。

**************************************************************************************

  剩下的事情比较杂

  1、SH客户提出要用运营商购买设备，以供下面的代理商们使用。

  向开发咨询，回曰：可以改，不过容易引发问题，而且改起来比较困难。如果实在需要，可以汇总在新需求里。 后续情况不甚了解，大概是写入新需求了。

  2、协助售前给客户做培训

  主要演示计费模块的使用，同时客户对银行接口非常感兴趣，可惜我以前没有测试过这块，回答不够到位。需要了解的东西还很多，偶要更加努力：）

  3、CBBN准备工作

  争取到比较满意的展板数量：）还有其他一些确认工作，其实我就是传话筒，市场部问什么，就找大猫请示一下，然后把请示结果转给市场部。感觉自己处理事情的能力还需要提高。

  4、名片信息汇总

  因为公司名称变故，所以需要新印名片，收集同事信息的任务就光荣的落在我的头上。很快收集完毕，大猫表扬了我，并且鼓励和鞭策我说：出了问题你要自己付钱重印哦。

  我当然诚惶诚恐，哪能容它出错。但是，没想到，交到秘书那里后，重新更换了模板，在一个最不可能出错的地方出错了，公司邮箱里多了个字母。糟糕的是秘书在让我最后审核时，我仔细对比了每一个地方，除了公司邮箱的名称。阴沟里翻船阿，这个明显的bug我都没找到，呜呜。

   这事错在测试范围不够完整