发布新日志

  • 准备考研了

    2009-06-19 15:23:50

    工作了快4年 感觉好累 想回到学校去休息 充电

    在这4年当中似乎一切都是很顺利的 虽然毕业以后没有进入名企工作 而是进了一个小台资公司 工资不是很高但是工作还是蛮开心的 同事们都觉得我很小 很照顾

    换了2份工作都是很顺利 但是还是觉得累 一种心里上的无法说出的累

    昨天老公也说让我继续再考研 想想再读书也是不错了 老公马上博士毕业了 可以养我了 继续读书对我来说可能是比较好的选择

    考研最大的选择是专业 不想再从事现在的行业 毕业女人老了 不能吃这碗青春饭了

    选择别的行业 又没接触过 不知道结果会是怎样

    既然是再读 可能就选择一个自己喜欢的吧

    这两天一定要做出决定

     

  • 如何处理上下级的关系

    2009-06-16 14:54:10

    在职场中打拼 如何处理上下级之间的关系是职场成功的关键

    处理好了关系领导才会重用你 提拔你

    处理好了关系手下才会为你卖命 为你做事 才能有业绩

    职场中的上下级关系 有的好似朋友 有的亲如兄弟姐妹 有的成了对立的陌生人 有的之间勾心斗角。。。。。

    我现在处的位置 我与我的领导和下属基本上保持好朋友的关系

    很想了解其他人对这层关系的处理 所以每当有时间的时候喜欢翻翻如何处理人际关系的书 喜欢在搜索社区中看人际关系的文章 

     

  • 版本管理

    2009-06-12 17:13:59

    目前公司的一个产品版本太多 管理起来很不方便

    目前的大概情况是这样的:

    1、有一个公共的版本

    2、与不同的地方合作又分出很多不同的地方版本,地方版本的功能基本上和公共版本是一样的,针对每个地方会有一些像logo图标不一样,端口不一样等,有些功能不向地方版本开放,服务器由我们统一管理

    3、为了与竞争对手的竞争,有一个属于公司自己的特殊版本(反屏蔽版本),这个版本和公共版本用的是相同的端口,只是logo和一些窗口名字都没有了

    4、完全独立的地方版本,相当于帮别人开发软件,别人共享部分信息给我们

    5、一个属于自己的地方版本,端口与公共版本不一样、窗口标题都没有了

    目前是每个版本每次发布的时候都打包,一个版本的改动经常引起一些和本次修改不相关的问题,一直没想到好的办法来管理

  • 由测试转向测试管理的过程(一年的心得)

    2009-06-10 10:13:29

    我是从测试开始的没有做过开发 工作大概3年左右转向了测试管理

    做测试时的工作开始是执行测试提交测试bug 慢慢的开始学习设计测试用例 维护测试用例

    现在做测试管理一年过去了 开始的时候很多事情还是自己亲自去做像设计用例 维护用例 有时还要执行测试

    渐渐的把这些测试的日常工作交给了别人去做 自己主要做的就是每个项目开始的时候和开发人员、市场人员一起讨论 理解业务需求(用户需求)进而提取软件需求 到测试需求  制定测试方案(测试计划)监督测试工作 分析测试结果 督促助手工作 检查助手的工作成果 对她们的工作成果进行评估 为她们争取该有的权利和利益 想办法给她们安排培训工作 以提高测试能力

    总之就是要想方设法的合理安排好测试工作 既利于公司也要利用手下做事的人 不加班的尽量不加 该有的福利尽量的争取

    每天繁杂的事情变得好多 不像之前做测试 一心只要想办法找到问题就可以了

    个人心得:做管理主要的就是:1、要选好人 这样才可以保证你选的人可以为你做事 做好事 2、要做好事 怎样去合理分配工作 让每个人都能发挥其长处 3、要分好钱 根据个人能力给与适合的报酬

  • 感悟

    2009-06-09 13:48:09

    5.12地震 新闻名播罗京逝世 生命太脆弱 要珍惜生命 真心 开心的过好每一天

    H1N1流感外来输入病例在中国激增 人普遍缺少责任心 太过于自私 呼吁人人都要对自己对他人负责人

    5.12地震 成都公交车着火 重庆没要瓦斯爆炸 塌荒 多灾多难的四川人 希望灾难离你们远去

    高考结束了 全国的家长们可以解放了  可怜天下父母心 长大的孩子们一定要孝顺 尊敬自己的父母 不管他们能给与了你什么 不能他们是做什么工作 他们都是为了你才坚强的生活的 千万不要做抛弃自己父母的事

    今年北京的天气很反常 异常的炎热 全国各地也是自然灾害不断 希望我们每个人都能为社会做点事 保护我们赖以生存的大自然 让他少受一点伤害

    2008年的金融危机在2009年还在延续 希望经济学家们能继续努力 然经济向着良性的方向发展 避免走向滑坡的一面

    2009年我也将更加积极的去面对生活 孝顺我们的父母 关心我的兄弟姐妹 多多与朋友们联系

  • 职场倦怠症

    2009-05-08 14:18:59

    职场倦怠症 对工作缺乏激情 没有动力 整天混日子 有事做事 没事休息 对自身的技能没有提高

    最近似乎很符合这些症状 大概快有1个月了 除了工作以外 提不起兴趣学习  每天都是混混沌沌的不知道自己在做什么

    以前在的公司每天要写工作总结 一天下来还知道自己在干什么 现在完全没有了概念

    不知道这样的症状是不是就是我所任务的职场倦怠症

    昨天和一个朋友聊的时候 他也有这样的感觉

    不只我一个人这样 还有不少人和我一样 不知道该为这样情况庆幸 庆幸这么多人和我一样

    还是该为中国这样的企业的制度感到悲哀 没法提高员工的工作热情和积极性 无疑是企业的一大败笔

    还是因为经济危机造就了这种现象 好像似乎又不是 在经济危机前很多同学也说过这样的问题

    哎 除了感叹 还是感叹

     

  • 继续写-----软件测试与行业知识

    2009-04-17 15:34:27

    从一个做PDF软件的公司 到一个做物流信息的公司 虽然还是做测试 但是行业不同了 做测试也要很了解行业知识才能测试的更好。

    pdf阅读器和编辑器 需要了解文本编辑工具 及打印机方面的知识,pdf转换器就是虚拟打印机。测试打印机需要测试不同的纸张 彩色打印还需要测试打印的色彩 使用不同型号的打印机打印效果对比 网络打印 本地打印 等

    对物流信息平台的测试需要很多的物流知识 如配货站是怎么帮司机配货的 怎么帮货主发货的 专线公司是怎么运作的 零担运输是怎么回事 整车运输等 骗货是怎么回事 在运输的过程中货主关注的是什么 司机关注的是什么 等

    开始时候开发的物流信息平台 是一个供配货站 车主 货主 发布货源信息 车源信息的网络平台,货主和配货站将货运信息发布到网上,司机在网上查找货源信息 也将自己的车源信息发布到平台上,这样就达成了司机、货主、配货站之间的互动交易。这个平台主要的两个功能就是发布信息和搜索信息,然后就是一些附件的功能辅助用户发布信息和搜索信息

    后台在这个平台的基础上扩展了车辆管理 为车主及配货站提供了一个管理车辆的平台,提供了一些增值服务发短信、定位、身份核查等等

    现在公司主要的业务开始慢慢转向运输管理 为一些大的企业提供运输管理服务。开发了一套运输管理系统,外包大货主企业的运输业务,主要是货主向我们提供运输订单如:要发多少吨电缆到什么地方 我们接到委托单以后帮货主找车 发运 直到货物运输到达目的地,这样整套的物流服务,系统还会想客服提供报表服务,帮助企业降低物流成本。

  • 续4年做了什么,得到什么

    2009-04-14 13:10:57

    在家不上网 所以写起来比较慢

    上次写到测试用例 以及在测试的过程中对测试用例的使用情况。关于测试用例基本上就这么多,中间有些环节可能记得不太清楚了 以后想起来再补充。

    还有就是重新用户发现的问题,像转换问题会附有相应的文件还比较好重现,这种问题算是我们在制作测试数据时没有考虑到的问题,遇到这样的问题,我们通常要把用户发来的附件作为特殊的测试数据写入测试用例中。

    还有些用户问题如:葡萄牙用户发来的问题,先要找到葡萄牙语的操作系统,装葡萄牙语的软件,如果装换的是word文档还要转葡萄牙语的office或英文office,基本上符合用户的环境以后,按照用户邮件中的步骤一步一步的操作,有时会重现不了问题,遇到重现不了的情况只能把可能影响的模块告诉开发人员,让他们自己去找问题。

    在用例基本完善了以后我们开始学习使用qtp自动化测试工具,因为买了qtp mercury送了一套winrunner的sn,我们把这两个测试工具,结合起来使用。最初的自动化测试是针对PDF driver的也就是pdf转换器,因为每次测试需要测试的测试数据太多了,所以希望能使用工具,减少工作量。先用qtp录制脚本,录制两份不同的脚本,一份是公司的driver录制的脚本,一份是adobe driver录制的脚本,然后用winrunner比较两个driver转换的文档,与adobe不同的就是有问题,由于开始自动比较结果存在一些问题,还是会手动比较来进行确认,有些文档adobe的转换结果也不对,这个时候我们只能查阅pdf referrence 来证实结果的正确与错误。

    基本上在第一家公司做的事情大概就是这么多,一年以后我就离开了这家公司来到现在公司,在现在的公司一直工作到现在,有3年多时间了。

    我到现在的公司时,公司之前没有专门做测试的,也没有测试文档,测试流程,一切都是空白。开始的时候我只是按照以前的测试方法,先熟悉公司的产品(物流信息平台),对每个版本进行测试。然后将问题写到excel中发给开发人员,当时我自己制作了一个excel文档用于记录测试中发现的bug(因为没有bug系统),文档的格式大概就是(编号、操作步骤、问题、时间、测试人、开发人、备注)。这是一家刚起步的做物流信息的公司,随着我对公司产品的了解一步一步加深,对公司的了解也更多,开始我们的产品仅限于一个物流信息平台和一个门户网站、以及后台管理等等。慢慢的公司的产品也在增多手机物流平台、手机定位系统、车辆管理系统、运输管理系统等等。

    在对公司的产品熟悉以后我开始按照以前学习到的知识,先开始写测试需求(没有开发需求)、测试用例、建立测试流程、引入bug管理系统(jira)、配置管理(svn)等等。开始就我一个人做测试,因为产品少还能忙的过来,后台产品越来越多,一个人很难忙过来,我的头让我招2个人帮我一起测试,我招了2个小姑娘帮。

  • 续4年做了什么,得到什么----测试用例篇

    2009-04-09 14:23:12

    前面说了开始我们是怎么写测试需求 因为是已成型的软件 所以基本上需求就是根据成型软件+adobe软件+加个人对软件的熟悉程度+PDF参考资料提取出来的

    对于我们各自提取分析出来的测试需求 先是测试组人员之间进行评审 因为文档是通过vss管理的大家先通过vss评审文档,评审以后对于不对的地方及不清楚的地方会加上批注  最后大家一起开会讨论评审 定出评审结果 各自在按照评审结果进行修改。本来计划要与开发人员一起评审文档的 可是无奈天下的开发似乎都不喜欢看文档 最好只能是我们自己内部评审通过了以后由开发的头头 稍稍过了一下我们的文档 也没说什么 默认就算是通过了外部评审。

    有了需求以后我们就按照需求文档设计测试用例,设计测试用例的方法基本上就是一些什么边界值、等价类、因果图、错误推测之类的方法。需要说的一点是我把自己平时在测试过程中测试出来的问题感觉比较重要的都写进了测试用例中。用例模板的格式就是我在上篇中附上的途中的格式,在设计测试用例的过程中主要的是测试步骤和预期结果部分,关于如何设计测试用例这是一个很难的事情 不是一两句话可以说的完,我主要想说的是我们在设计测试用例的过程中主要完成的事情就是使用例能覆盖所有的需求,至于我们设计的用例能否测试出很多bug 后来我们在实施的过程中 按照用例执行发现的问题并不是很多 相反习惯了自由测试的前辈们 不按照用例发现的问题反而比较多。所以说我们设计的用例在开始只满足了覆盖需求,在接下来我们也逐渐的设计了一些特殊的用例 包括一些不常出现的问题、用户反馈回来的问题等。由于在设计出来的用例要覆盖所有的需求 所以我们在测试的时候 第一个版本会按照用例全部走一遍 而且是每个人变化这测试不同的模块,用例走完以后我们基本上就是按照自己的经验来进行自由测试 这个阶段发现的问题也比较多,到了版本比较稳定了以后准备上线的时候 我们先做回归测试 然后做上架测试也就是版本发布测试,此时时间比较紧没办法走所有的用例,我们选择按照一条的条件筛选出本次测试的“上架测试用例”,基本上每个版本发布我们都会选择不同的“上架测试用例”来满足大部分的需求,觉得比较主要的模块就会拿出来重点测。

     

  • 续4年做了什么,得到什么----测试需求及测试用例

    2009-04-08 15:23:06

    下面说说我当初是怎么分析测试需求的、如何设计测试用例的

    我们的测试需求文档模板分成以下几个部分:

    第一部分是简介,顾名思义就是简单的介绍一下软件的功能、性能等方面的内容,因为我们当时是按照模块写的,也就是模块需求文档,此部分主要是介绍这个模块的功能及此文档的都会有那些人看,参考了那些文档或软件等知识。

    第二部分就是功能需求部分,每个模块又会一级一级的再细分下去(XXX功能 功能描述 具体需求)如:新建页面功能(PDF阅读和编辑器中的),在“功能描述”中先大概的描述一下新建页面这个功能是干什么的,也就是新建页面功能的概述,在“具体需求”部分会详细的描述新建页面这个需求如:有几种方式可以新建页面(也就是新建页面有多少个入口),对于不同的用户新建页面有什么不同如没有购买sn激活的用户新建页面会有水印等,对于新建的页面有那些操作如旋转等等,能越详细的描述一个功能越好。

    第三部分是关于性能需求的,当时我们做性能测试基本上都是手动的,和Adobe的软件进行对于,如把相同的文档用公司的转换器转换成pdf文档需要多长时间,用Adobe的转换器进行转换需要多长时间,两者之间不能相差太多,对于很大的文档在1分之内是可介绍的,对于小的文档相差10几秒是可介绍的等等,这些都是通过用户反馈回来的意见制定的一个大概的标准。性能需求和功能需求一样也是分模块的,然后再一级一级的细分(XXX功能 性能描述 具体的性能需求),对于性能测试主要是集中在PDF转换器部分,对于pdf阅读和编辑器性能测试没有具体的要求,只要在平时测试的工程中使用起来不是很慢就行了。对于pdf转换器的性能测试先分析出需要测试那些类型的文件,每个类型的文件又有那些特俗的需求,针对不同的需求制作相应的测试数据如:对于图片文档分.jpg .gif .bmp等各种格式,每种格式又分为不同的像素36bp 72bp等等。测试数据制作好了,将这些测试数据分别用公司的pdf转换器转换记录转换时间,再用adobe的转换器转换记录时间,两个时间进行对比

    第四部分是关于安全性测试的,这部分主要是测试不同的sn激活以后的使用时间,以及不用sn激活等情况

    以上是关于测试需求的分析。

    接下来说一下测试用例的设计

    测试用例模板是自己设计的主要包括这几个部分:

    说明 测试版本  
    测试时间  
      测试环境  
    测试人  
    功能模块 编号 测试项 测试子项 前提条件 测试步骤 测试数据 验证标准 备注 测试结果

     

    关于如何设计测试用例,等会再写

  • 4年做了什么 得到了什么

    2009-03-30 17:46:31

      2005年毕业以后从云南来到了北京,在学校学的是软件工程 对于测试和软件质量在学校的时候从老师那有一些了解,在校期间也实际做过测试的工作,那是在软件工程课中我们分小组做项目,最后的测试从设计到实施就是我负责的。有一个学期上的一门关于CMM的课程我很喜欢,也很认真的去学习了,从这门课中让我对软件质量有了进一步的了解,也让我坚定了以后做测试的信念。毕业以后我的目标很明确,从事测试行业,也有几个同学在我的影响下步入测试行业。

    在找工作的过程中我对工作的要求不高,因为我知道自己什么都不会,什么都需要学习,我没有像其他人一样一定要求自己进有名的大公司,我选择了进入小公司。

    我的第一份工作是一家台资企业,是个纯技术性的公司,人不多加上行政人员大概在40人左右,做PDF阅读器和转换器的,用的主要语言是C。公司的测试分为白盒测试和黑盒测试,我被分在了黑盒测试组(组里人都很好,可能觉得我小都很照顾我,我也很喜欢和他们一起工作)。

    1、开始仅仅是做黑盒测试,每天使用软件,功能与Adobe的软件进行对比,遇到问题就提交bug。对于bug的描述有一定的要求,首先标题要能明确的反映问题,其次是bug的级别和测试环境,再次就是在描述问题的时候要遵守一定的格式(当时的格式是:步骤+问题+备注信息)将问题清楚的反馈给开发人员,对于只出现一次的bug,每次都会截图或者把错误信息放在bug里供开发人员参考。对于问题要找到出现的规律,清楚的描述给开发人员(有时还需要现场给开发人员演示bug)。

    以后继续。。。今天有事不能继续了

  • 开始充实空间

    2009-03-30 17:40:20

    空间创建这么久了一直没时间来写点什么 说没时间应该是个借口

    在测试这块做了将近4年了 对于测试有一点自己的理解和想法 散乱的分布在脑海中 一直没能总结一下

    最近感觉需要对之前的工作和学习总结总结 希望能从中总结出一些东西同测试的朋友们分享一下

    也希望从同行哪学习更多的东西

    互相交流 分享知识

Open Toolbar