爱尘封梦醒难 爱尘封梦醒难
海总是这样,一浪下去,马上又会有一浪上来,日复一日不知疲倦地向前......尽管他会被岸一次一次推回,但他仍然在向着他的目标与理想锲而不舍地追求着,因为他有广阔的胸怀
关注数: 19 粉丝数: 116 发帖数: 2,121 关注贴吧数: 54
【博测科技】测试转开发的心得 在讲述我的经历之前,我先分享下工作不到2年时间得到的几个重要的结论:   一、坚持梦想没有理由   二、世界不断在变化,该行动就要行动   三、人需要通过一些事情不断证明自己   下面就开始讲述我短短的工作心得吧~   一、在XF的测试之路   2010年大学毕业,非计算机专业,大学期间本来打算好好自学编程以后做个程序员,但因为懒惰以及恋爱,没什么时间学习,只能退而求其次,找门槛低点的,就通过校招找了一份 软件测试的工作。   2010年四月进入XF(我的第一家公司)实习,实习期间我的表现并不好,什么工作流程都不懂,每天把手头工作完成下班到点走人当时我认为是理所当然的事情,却惹的那个项目组的人都对我有意见,然后实习了一个月我就结束了实习,回学校逍遥自在到毕业。   2010年七月毕业后进入XF做 软件测试 ,入职后进行了为期一个月的培训,30号新入职测试员工一周六天从早上9点到晚上9点在科大南区的培训,培训老师(其实就是测试部门的同事)装13的苛刻教学方式,以及租房子等等事情,一下子让刚出校园的我压力大的透不过气来。依稀记得那年夏天出奇的热,租的房子在顶楼,天晴晚上睡觉热死,下雨墙体漏水停电,人累的跟鬼一样,学到的都是一些没有意义的形式主义的东西。结束一个月的培训后进入项目组,项目组还是以前实习的项目组,可是3天后我就得知我被调出项目组。我知道这个项目在事业部属于核心型项目,在这个项目组的人基本都很自傲,我觉得当时我的自尊心被严重的打击了,我很好强,培训期间我的表现并不差,数一数二,大概还是因为实习期间的表现吧,人家不愿意要我了。   其实一切都是因缘际会,因为被一个组抛弃,而进入另一个组,再到后来得到大家的肯定,拿到年终优秀新员工,结交了一群一生的朋友,只要自己努力了,自然大家都看得见。   2011年三四月的时候,来了一个实习生华仔,领导分配我作为他的指导人。华仔很亲切的一口一个小师父的喊着,他不算是一个聪明的孩子,但他却有着别人没有的执着与努力,他的进步很快,同时也分担了我的很大一部分工作,这时候我开始思考我的人生。。
【博测科技】如何提高冒烟测试的准确度 最近的项目工期紧,人手少。人手少是一直的情况,工期紧是因为老总们和客户们总是在变时间,为了讨好客户,加功能缩时间。   产品经理最近一直在犯错,就是在任何时候都会找你要版本部署给客户。   我认为,找我要版本,可以,但是你要清楚你的风险。每个版本都是有问题的,不做缺陷评审贸然将冒烟测试通过的版本给客户,这个风险,谁承担?自己承担去。   这里就涉及到了一个问题,怎么样能提高冒烟的水平?也就是准确度。   这几天在忙一个老项目,要将项目重头到尾所有功能点覆盖一点,忘记需求和无用例的情况下,却开展了,取决与一个好办法,就是 测试记录。   将测试的要点、测试步骤、测试结果和满足需求进行设计和填写,发现真的很管用。至少系统90%以上的功能点都能覆盖,先不说逻辑和业务是不是全,光光这1000多个功能点的覆盖就没有问题了。那回想一下,然后把这个表格扩充一下,加上业务逻辑和涉及页面,是不是能够形成每个项目的冒烟框架?   琢磨了琢磨,存在这样几个问题:   1.时间成本。新的项目开始,时间上是否能够承受。在只看原型的前提下,功能点是否可以就全面。   2.人员能力。谁来做?组员,还是组长,这是个问题。   3.意义。项目经理会问你,产品经理不过问,开发组长更不会问了,那这个意义,恐怕只有实验后你自己才能知道吧。   4.是否试用于每个项目。小项目肯定没有问题,那大项目呢?怎么做?组内通力合作,还是依靠个别力量。   想了那么多,恐怕还是关联上的问题。解决了管理和组织的问题,后面都好解决。   1.循序渐进,把冒烟用例使用迭代的方式进行。   2. 测试组长领导由组员完成,组员测试测试的主体力量。   3.意义,就是最好不会让我们擦屁股吧。   4.这个需要时间和实践的验证。。呵呵
【博测科技】如何提高冒烟测试的准确度 最近的项目工期紧,人手少。人手少是一直的情况,工期紧是因为老总们和客户们总是在变时间,为了讨好客户,加功能缩时间。   产品经理最近一直在犯错,就是在任何时候都会找你要版本部署给客户。   我认为,找我要版本,可以,但是你要清楚你的风险。每个版本都是有问题的,不做缺陷评审贸然将冒烟测试通过的版本给客户,这个风险,谁承担?自己承担去。   这里就涉及到了一个问题,怎么样能提高冒烟的水平?也就是准确度。   这几天在忙一个老项目,要将项目重头到尾所有功能点覆盖一点,忘记需求和无用例的情况下,却开展了,取决与一个好办法,就是 测试记录。   将测试的要点、测试步骤、测试结果和满足需求进行设计和填写,发现真的很管用。至少系统90%以上的功能点都能覆盖,先不说逻辑和业务是不是全,光光这1000多个功能点的覆盖就没有问题了。那回想一下,然后把这个表格扩充一下,加上业务逻辑和涉及页面,是不是能够形成每个项目的冒烟框架?   琢磨了琢磨,存在这样几个问题:   1.时间成本。新的项目开始,时间上是否能够承受。在只看原型的前提下,功能点是否可以就全面。   2.人员能力。谁来做?组员,还是组长,这是个问题。   3.意义。项目经理会问你,产品经理不过问,开发组长更不会问了,那这个意义,恐怕只有实验后你自己才能知道吧。   4.是否试用于每个项目。小项目肯定没有问题,那大项目呢?怎么做?组内通力合作,还是依靠个别力量。   想了那么多,恐怕还是关联上的问题。解决了管理和组织的问题,后面都好解决。   1.循序渐进,把冒烟用例使用迭代的方式进行。   2. 测试组长领导由组员完成,组员测试测试的主体力量。   3.意义,就是最好不会让我们擦屁股吧。   4.这个需要时间和实践的验证。。呵呵
C++Test静态分析BugDetective【博测科技】 一、准备工作 1. BugDetective的原理 BugDetective 是一类新的静态分析技术,该技术使用了几种分析技巧,包括模拟应用程序执行路径,以识别可能触发运行时缺陷的路径。检测到的缺陷包括,使用未初始化的内存、引用空指针、除数为零、内存和资源泄漏。 由于该分析涉及到识别和跟踪复杂路径,它会暴露通常可逃避编码规则静态分析和单元测试的错误,这些错误难以通过手动测试或检查找到。对于那些具有遗留代码库和嵌入式代码(这些情况下,此类错误的运行时检测效果较差或根本不可能)的用户而言,BugDetective 可在不执行代码的情况下显露错误的功能,就特别重要。 BugDetective 独特的静态分析通过搜索代码中的“可疑点”,开始分析正在测试的源码。可疑点是潜在的错误点。这些可疑点在BugDetective 规则中被定义。只要识别了可疑点,BugDetective 就调查导致该可疑点的可能执行路径,并检查是否有任何确实违反BugDetective规则的路径存在。如果找到了这样的路径,就报告一个违例。 例如,检测可能的“除数为零”情形的规则就规定,任何使用了"/" 或"%" 运算符的点都是可疑的。然后它检查分母中的变量,在导致它为零的任何可能执行路径的点中,是否能保持零值。如果是的话,则会报告一条错误。 对于每个发现的错误,分层结构流路径数据都会详细准确地列出导致被识别错误的完整执行路径,并以显现出错误的那一代码行作为结束。为减少每个被发现问题的诊断和纠正所需要的时间和工作量,流路径详细信息还会补充扩展注释(例如,一条关于“避免引用空指针”违例的描述就包含这样的注释,描述哪些变量、在流路径的哪一点包含null 值)。 为使分析过程更灵活、更适合于项目的独特要求,可以参数化某些规则。因此,BugDetective 甚至可以用来检测与特定的API 使用相关的违例。
C++Test静态分析BugDetective【博测科技】 一、准备工作 1. BugDetective的原理 BugDetective 是一类新的静态分析技术,该技术使用了几种分析技巧,包括模拟应用程序执行路径,以识别可能触发运行时缺陷的路径。检测到的缺陷包括,使用未初始化的内存、引用空指针、除数为零、内存和资源泄漏。 由于该分析涉及到识别和跟踪复杂路径,它会暴露通常可逃避编码规则静态分析和单元测试的错误,这些错误难以通过手动测试或检查找到。对于那些具有遗留代码库和嵌入式代码(这些情况下,此类错误的运行时检测效果较差或根本不可能)的用户而言,BugDetective 可在不执行代码的情况下显露错误的功能,就特别重要。 BugDetective 独特的静态分析通过搜索代码中的“可疑点”,开始分析正在测试的源码。可疑点是潜在的错误点。这些可疑点在BugDetective 规则中被定义。只要识别了可疑点,BugDetective 就调查导致该可疑点的可能执行路径,并检查是否有任何确实违反BugDetective规则的路径存在。如果找到了这样的路径,就报告一个违例。 例如,检测可能的“除数为零”情形的规则就规定,任何使用了"/" 或"%" 运算符的点都是可疑的。然后它检查分母中的变量,在导致它为零的任何可能执行路径的点中,是否能保持零值。如果是的话,则会报告一条错误。 对于每个发现的错误,分层结构流路径数据都会详细准确地列出导致被识别错误的完整执行路径,并以显现出错误的那一代码行作为结束。为减少每个被发现问题的诊断和纠正所需要的时间和工作量,流路径详细信息还会补充扩展注释(例如,一条关于“避免引用空指针”违例的描述就包含这样的注释,描述哪些变量、在流路径的哪一点包含null 值)。 为使分析过程更灵活、更适合于项目的独特要求,可以参数化某些规则。因此,BugDetective 甚至可以用来检测与特定的API 使用相关的违例。
白盒测试的六种用例和六种覆盖的方法【博测科技】 1.语句覆盖。这个是起码要做到的覆盖了,程序里的每条可执行的语句都要至少执行一次。这个设计起来比较简单,用例数据很直观的就能看出来。但是语句里的判定,分支等就没什么意义了。可以说这样的测试是最低的要求了。   2.判定覆盖。每个判断的真假分支至少执行一次,就是真要至少取一次,假要至少取一次。这个设计起来也不难,覆盖率要比语句覆盖高近乎一倍,但是也在判定语句中也会遗漏许多路径,因为每个条件的取值是不在考虑范围内的。   3.条件覆盖。和判定覆盖思路一样,只是把重点从判定移动到条件上来了,每个判定中的每个条件可能至少满足一次,也就是每个条件至少要取一次真的,再取一次假的。同样它也会遗漏许多路径,条件取真假并不能满足判定也取到真假两次。   4.判定条件覆盖。既然上面的判定和条件多是片面的,那么这个两个覆盖相结合是呼之欲出判定条件覆盖。它要求判断中的每个条件所有可能至少出现一次,并且每个判定本身的判定结果也要出现一次。不要以为这样就行了,要看看条件,条件和判定不一样,判定取真假就覆盖了判定,可是条件取真假两次完全不能满足条件的各种组合。所以才有了5~。   5.条件组合覆盖。每个判定中条件的各种可能组合至少满足一次。条件各种可能都出现了,必然把判定给覆盖了,它覆盖了上面的4个哦,可是用例数量大大增加了!看项目情况定吧。
白盒测试的六种用例和六种覆盖的方法【博测科技】 1.语句覆盖。这个是起码要做到的覆盖了,程序里的每条可执行的语句都要至少执行一次。这个设计起来比较简单,用例数据很直观的就能看出来。但是语句里的判定,分支等就没什么意义了。可以说这样的测试是最低的要求了。   2.判定覆盖。每个判断的真假分支至少执行一次,就是真要至少取一次,假要至少取一次。这个设计起来也不难,覆盖率要比语句覆盖高近乎一倍,但是也在判定语句中也会遗漏许多路径,因为每个条件的取值是不在考虑范围内的。   3.条件覆盖。和判定覆盖思路一样,只是把重点从判定移动到条件上来了,每个判定中的每个条件可能至少满足一次,也就是每个条件至少要取一次真的,再取一次假的。同样它也会遗漏许多路径,条件取真假并不能满足判定也取到真假两次。   4.判定条件覆盖。既然上面的判定和条件多是片面的,那么这个两个覆盖相结合是呼之欲出判定条件覆盖。它要求判断中的每个条件所有可能至少出现一次,并且每个判定本身的判定结果也要出现一次。不要以为这样就行了,要看看条件,条件和判定不一样,判定取真假就覆盖了判定,可是条件取真假两次完全不能满足条件的各种组合。所以才有了5~。   5.条件组合覆盖。每个判定中条件的各种可能组合至少满足一次。条件各种可能都出现了,必然把判定给覆盖了,它覆盖了上面的4个哦,可是用例数量大大增加了!看项目情况定吧。
白盒测试的六种用例和六种覆盖的方法【博测科技】 1.语句覆盖。这个是起码要做到的覆盖了,程序里的每条可执行的语句都要至少执行一次。这个设计起来比较简单,用例数据很直观的就能看出来。但是语句里的判定,分支等就没什么意义了。可以说这样的测试是最低的要求了。   2.判定覆盖。每个判断的真假分支至少执行一次,就是真要至少取一次,假要至少取一次。这个设计起来也不难,覆盖率要比语句覆盖高近乎一倍,但是也在判定语句中也会遗漏许多路径,因为每个条件的取值是不在考虑范围内的。   3.条件覆盖。和判定覆盖思路一样,只是把重点从判定移动到条件上来了,每个判定中的每个条件可能至少满足一次,也就是每个条件至少要取一次真的,再取一次假的。同样它也会遗漏许多路径,条件取真假并不能满足判定也取到真假两次。   4.判定条件覆盖。既然上面的判定和条件多是片面的,那么这个两个覆盖相结合是呼之欲出判定条件覆盖。它要求判断中的每个条件所有可能至少出现一次,并且每个判定本身的判定结果也要出现一次。不要以为这样就行了,要看看条件,条件和判定不一样,判定取真假就覆盖了判定,可是条件取真假两次完全不能满足条件的各种组合。所以才有了5~。   5.条件组合覆盖。每个判定中条件的各种可能组合至少满足一次。条件各种可能都出现了,必然把判定给覆盖了,它覆盖了上面的4个哦,可是用例数量大大增加了!看项目情况定吧。
有想要学习软件测试知识的吗? 软件测试人才缺口30万  近年来,中国软件产业保持了迅猛发展的态势,但是,由于一直以来,中国许多软件企业存在着“重开发、轻测试”的倾向,因此,在造成软件产品质量问题日渐突出的同时,也突显了中国软件测试人才的极度匮乏。  3784.99亿元——软件行业发展迅猛  据最新出炉的《2008年中国计算机市场预测报告》显示,2007年前三季度,软件行业实现收入3784.99亿元,同比增长23.6%,占整个电子信息行业收入比例的10.95%.   30万——软件测试人才缺口30万  据前程无忧招聘网统计,目前,国内120万软件从业人员中,真正能担当软件测试职位的不超过5万人,软件测试人才缺口已超过20万并向30万大关急速挺进。在中华英才网近期发布的2007十大热门职业中,软件测试工程师也位居三甲之列。  10万——软件测试人才年薪可达10万  为了吸引更多的人才,企业纷纷采取高薪策略。据统计,测试工程师的起步月薪在4000~5000元左右,远高于同龄人1000~2000元的薪资水平,另外还可享受带薪年假、内部培训、住房公积金等福利待遇,工作2~3年月薪大约在8000~13000元之间。但即便如此,很多企业仍旧纷纷感叹:“高薪难觅找茬人才。”   1:8——目前我国软测人员与开发人员比例  微软公司软件测试工程师对外透露,在微软内部,软件测试工程师和开发工程师的比例基本维持在1:1左右,而国内其他软件企业中这一比例却仅在1:5至1:8之间。“招个软件测试人员比招博士还难!”不少企业发出类似的感叹。  透过以上数字,可以看出我国的IT行业人才结构正处于失衡状态,软件测试人才缺口巨大。这不但已经成为影响中国软件产业发展的瓶颈,制约着软件整体质量的提高,同时也加重了软件产业的开发和服务成本负担。因此,如何尽快建立软件测试人才的系统培养机制、进而保障软件业的健康化发展已成为现阶段亟需解决的当务之急。  数字背后:  IT行业人才结构失衡  日前,我国第一个全面解读IT行业工作岗位心理素质要求及心理特征与工作绩效之间关系的研究报告——《中国IT从业人员心理特征研究报告》在北京正式公布。专家指出,《中国IT从业人员心理特征研究报告》将为IT企业制定科学的人才选拔的标准提供重要的依据。此项研究报告指出做好职业生涯规划是IT从业者应具备的能力之一,是企业在选拔IT人才时考察的心理品质。  做好职业规划的五个方面  “要做好职业规划,首先要确定一个长期明确的目标,如10年之后你要达到什么水平,还要确定短期的目标,5年的目标、1年的目标,甚至明天的目标。而且确定的目标要可行。第二就是要根据自己的性格、兴趣、成长等因素选择职业。第三就是要选准行业,看这个行业今后的发展会给你留下的发展空间有多大。IT行业属于朝阳产业,正处于发展期,现在和将来都将会是个发展潜力巨大的行业。所以个人会有很大的发展空间。第四点就要做好准备,包括学历、技能、职业素质等方面的准备。第五按照确定的目标行动。”职业规划师张苒给出如此建议,这对于求职者以及刚刚跨入社会的职场人士有着重要的启示作用。  下面以IT行业中软件测试工程师的进阶之路为例,对IT从业者做好职业规划提供一点启示。  软件测试工程师的进阶之路  初级测试工程师  刚入门拥有计算机科学学位的个人或具有一些手工测试经验的个人。开发测试脚本并开始熟悉测试生存周期和测试技术。  测试工程师/程序分析员  具有1~2年经验的测试工程师或程序员。编写自动测试脚本程序并担任测试编程初期领导工作。拓展编程语言、操作系统、网络与数据库技能。  高级测试工程师/程序分析员  具有3~4年经验的测试工程师或程序员。帮助开发或维护测试或编程标准与过程,负责同级的评审,并为其他初级的测试工程师或程序员充当顾问。  测试组负责人  具有4~6年经验的测试工程师或程序员。负责管理1至3名测试工程师或程序员。担负一些进度安排和工作规模/成本估算职责。  测试/编程负责人  具有6~10年经验的测试工程师或程序员。负责管理8至10名技术人员。负责进度安排、工作规模/成本估算、按进度表和预算目标交付产品。  测试/质量保证/开发(项目)经理  具有10多年的工作经验。管理8名或更多的人员参加的1个或多个项目。负责这一领域(测试/质量保证/开发)内的整个开发生存周期业务。  计划经理  具有15年以上开发与支持(测试/质量保证)活动方面的经验。管理从事若干项目的人员以及整个开发生存周期。负责把握项目方向与盈亏责任。  软件测试人员的三大发展方向  “软件测试人员一般有三大发展方向。”微软公司的陈宏刚博士介绍说,一是走软件测试的技术路线,成长为高级软件测试工程师。二是向管理方向发展,从测试工程师到组长,再到测试经理,以至更高的职位。三是可以换职业,做项目管理或做开发人员。经过软件测试岗位洗礼的人才往往是行业中的多面手,在技术、管理、市场甚至其他非IT领域都能得到良好的发展。当然这首先要取决于从业者是否具备长远眼光,对自己的职业生涯进行合理规划。
1 下一页