展望2011

2010年工作、学习和生活总结

上一篇 / 下一篇 2011-02-12 18:16:34 / 个人分类：学习日志

2010年工作、学习和生活总结

回顾2010年记录的点点滴滴，感触颇深，原来这一年中发生了这么多的事情，有付出有收获，有得有失，有喜有悲。由于是平时工作中总结的一些经验，有点凌乱，不成文章。

51Testing软件测试网8WTa'peI/b2g

工作：2010年春节过后，就开始投简历找工作了，历时3个月后进入现在所在公司。起初的一段时间不太顺利，有时候自信心备受打击。好在后来对业务越来越熟了，以前的经验也排上了用场，工作也越来越顺手，特别是在2011年年初的那一段时间，算是跳槽以来最有成就感的一段日子，又找回了当年忘我工作的感觉。通过学习不断研究解决各种问题的过程才是最有意义的。希望2011年能再接再厉。

51Testing软件测试网sx v Ti1_*r&d

测试技术：测试经验方面，最大的收获应该是开始进行系统的自动化测试，虽然目前写的脚本水平不高，但从中学到了不少自动化测试的技术。2011年上半年争取把自动化脚本写完并通过测试。

51Testing软件测试网 Al#@K.\&x

编程技术：2010年的系统学习的内容很少，一个原因是黑盒测试，看不到代码，学习动力不足，另一个原因是时间挤不出来。2011年需要做安排，需要系统学习的有：oracle数据库(存储过程)、JAVA语言、VBScript。

健身：2010年年初办了一张健身卡，前半年还能坚持锻炼，后来由于跳槽和搬家，导致健身会所离住处太远，后半年基本上就没去了。2011年希望能找到，即能游泳又能健身离家又近的地方。

游泳：本来想在2010年年内学会蝶泳的，可惜没有完成目标，看来自学蝶泳还是有难度，需要有人指点一下才行。进入新公司后，很荣幸的成为了俱乐部游泳组的组长，希望在2011年的游泳活动中，寻觅到高人指点。51Testing软件测试网#iR:q@&E

口琴：去年学会了一些好听的曲子，比如爱尔兰画眉、天空之城等。2011年还要再接再厉，学会更难的曲子，比如卡农，还有其他流行歌曲等51Testing软件测试网 Ry)wx7d4Fh

51Testing软件测试网(T*tJ2b9L3q

阅读：由于上下班路上花费的时间太少，只安排了中午午休之前的半个小时进行阅读，结果有时候每2个月才看完3本书，和自己的目标-周读一书还差的很远。2011年还要多安排时间在阅读上。51Testing软件测试网r;]'JK(B T

51Testing软件测试网$w9Y,Q'tg,U

英语：在新公司中，有部分文档是英文的，所以又一次开始了英语的学习，目前新概念英语第二册快学完了。2011年计划增加英语学习的方法，比如阅读英文资料等

狗狗：2010年很荣幸的成为了深圳流浪狗驿站的义工队伍中的一员，刚开始只是单纯的想做自己喜欢做而且有意义的事情，总觉得自己还没能力养狗狗，后来跳槽和搬家之后，养狗狗的心愿越来越强烈，所以2010年7月4日从驿站里收养了可爱乖巧的家宜。自从家里有了家宜，每天都非常期盼下班，早点看到我那可爱的宝贝，虽然是租的房子，也感觉像个家，我和家宜的家。

做饭：跳槽之后，一开始想多带在公司一会再走，所以晚上就没再做饭了，后来，食堂的饭菜涨价而且越来越难吃，只好又开始自己做饭吃。不过厨艺还没有什么长进，2011年计划每周周末学做一两道新菜色

51Testing软件测试网KMEhAY [

测试经验

测试需求要考虑清楚51Testing软件测试网%yo4L'e+S L

时间再少，被测东西再熟悉，也要把测试需求分析清楚，考虑完整，不能直接就写测试用例或执行测试，这样有些测试需求很容易被遗忘或忽视。51Testing软件测试网o8vr MW

51Testing软件测试网]*`.F a N

使测试用例改动少的办法

在设计用例和执行用例可以同时执行的情况下，在设计全部用例之前，一定要手工执行部分有代表性的用例，因为有可能设计的用例和实际操作并不相符合（可能是对需求和设计并不熟悉），如果全部设计完用例后再执行，发现设计的用例大部分有问题，就需要返工修改测试用例。比较好的办法是，先设计几个具有代表性的测试用例然后马上执行，如果没有发现用例有问题，再继续设计剩余的测试用例，这样返工的可能性比较小

白盒测试用例的修改51Testing软件测试网N]%k-v(lM

相同的功能，可能会有不同的逻辑方式实现，所以根据白盒分析之后的测试用例也会有所区别，所以再测类似系统的相同的功能时，一定要注意测试用例的修改，如果沿用老的用例，很可能发生漏测。

51Testing软件测试网0{&EQCzF

有效等价类的遗漏

有次漏测，发现有效用例中，少了2种不同的有效等价类，黑盒和白盒居然都没发现漏掉了。经验是，2种特殊情况组合在一起，测试通过，不等于说2种特殊情况分开进行测试时都能正确，一定要分开测试。

维护版本的回归测试

客户环境上出现了2个问题，但是在测试过程中没有发现，经过分析后，有3种办法可以避免以后出现相同的问题，一种是做回归测试，所有游戏所有玩法（限制：测试时间太长，成本太高）。一种是版本更新控制，版本更新了哪些文件，全面了解，白盒分析，分析可能的影响范围是什么（限制：对测试人要要求较高，需要版本控制，需要看的懂代码）。第三种是将投注机自动化测试，现有系统的重要功能实现自动化测试（限制：自动化测试实现有难度，需要花人力和时间去实现），等到维护版本时，就可以发现这2个问题。51Testing软件测试网DKD2E7}-uE

51Testing软件测试网3W"w6[E*A[Hl

解决问题的根本办法

解决问题时，记录下解决问题的执行记录，算是经验积累，但不是每次出现相似问题时，上次的解决办法就会有效，因为代码在变化，逻辑在变化，问题出现的原因可能各种各样，解决的办法也就不能重复使用了，最根本的办法就是去了解和熟悉该问题出现的功能是怎么实现的，最根本的原因是什么，然后对症下药，这样才可以从容的应付各种问题。

BUG提交给具体的开发人员51Testing软件测试网OE,g"NX8i7q

在提交BUG时，BUG相关的开发人员有N个人，如果不确定要提交给谁时，首先自己定位是哪部分出了问题，比如客户端和后台共同实现的一个功能，从日志中观察客户端和后台之间通信的数据是什么？是客户端的问题还是后台的问题？如果还是无法知道是谁的问题，那么把问题提交给项目经理，让他来分派是给谁。另外一方面，如果开发人员发现不是自己的问题，应该把问题转给可以解决这个问题的开发人员，而不是直接返回给测试人员，说不是他的问题。其实道理都很简单，但真正能做到开发人员和测试人员很少。51Testing软件测试网:N^2u/h1a4J

51Testing软件测试网c#o2_M'p

描述BUG时尽可能截图

描述BUG时，如果数据或环境发生变化，BUG就有可能出现不了，开发人员也许就不明白哪里有BUG，所以一定要多尝试几次，修改数据，修改条件，试下那种输入数据和条件下都会出现这个BUG，哪些输入数据和条件下不会出现这个BUG，这样开发人员方便定位问题。如果不清楚重现的步骤是什么，那么就把图截下来，这样也有依据，即使重现不了，但可以证明确实有过这样的现象出现，不是胡说的。

51Testing软件测试网*[)O4t{H1Ua7E

客户未使用的功能，很可能存在老BUG

维护版本，在确定影响范围时，未修改部分但可能会有影响的功能点，之前都没有测的很仔细，因为没有修改，只要考虑受影响的部分就行了，但没想到的是，有可能受影响的功能点本身就有BUG，而且这个BUG一直就存在，只是之前客户没有使用这个功能点，所以没有被发现。所以，受影响的功能点如果有时间，也需要详细的测试。

重视测试人员提交的严重级别的BUG51Testing软件测试网z[c7L+e

开发人员忽悠测试人员，最后只会自食其果，比如有一次，有个严重的问题已经跟开发人员说过了，可是开发人员并不重视这个问题，可能是没有定位到原因还是不信任测试人员，答复测试人员说客户环境正常，所以可能是后台版本不是最新等原因。我也就相信了，其实当时也找后台开发人员确认，后台版本应该是最新的，然后再次找开发人员确认，结果他还是没有去管这个问题，直接把版本上线了。结果客户那发现了这个严重问题。51Testing软件测试网I(S5\*u_Uj

QTP自动化脚本编写

编写脚本的基本步骤如下：

1．理解对应的用例，在录制之前先思考可能会遇到的问题，默记将要录制的完整操作步骤，考虑好哪些输入数据需要参数化

2.录制步骤51Testing软件测试网~ c;J}4~$i3Z

3．回放测试，检查有没有操作没有录制成功，如果部分操作没有录制成功，从中间开始录制漏掉的操作

4.检查各个对象的属性值，是否会变化导致下次测试时识别不了该对象，如果是，则需要使用正则表达式

5．修改脚本，输入数据参数化，如果有输入到database的参数，则在这些参数都输入之后设置断点，方便观察参数化输入是否正确

6．修改脚本，设置检查点

7．回放测试，检查测试报告，是否有错误和警告信息，检查输入到database的参数是否正确，检查点的捕捉范围是否和自己预期的一致51Testing软件测试网iluv*` I M

8．修改错误和警告信息对应的脚本，反复调试直到成功

9．修改参数再一次回放测试

收藏举报