走入测试行业：兴趣、知识
说实话，我做测试工作的时间不是很长，学完软件测试课程后，到现在也就是一年多的时间吧，现把自己学习和工作中积累起的这些点滴与大家分享。
我走入测试行业完全是因为兴趣，兴趣产生学习和工作的热情，真的是一点都不假。从我选择走入这个行业，学习、工作，从测试员到测试主管，我都是快乐的，也很充实，很有成就感。
我觉得，在决定走入测试行业后，就要在这方面多做准备和积累，首先要有坚实的测试理论基础，这些知识不仅是学习的时候要学的扎实，在以后的工作中还要继续不断的完善。其次，要有一定的行业知识。找工作时，有做电信系统测试的，也有做银行系统测试的，我做的是DW产品，各行各业都需要。大家都知道，DW(Data Warehouse)是DSS–企业决策支持系统的一部分，是指建立在信息技术基础上，以系统化的管理思想，为企业决策层及员工提供决策支持的数据库和商业智能平台。
初来乍到：熟悉环境，尽快融入
开始进入公司的时候首先要熟悉公司的环境。还有就是要尽快的熟悉公司的测试环境，操作系统、开发语言、平台，接着就是要了解公司的产品，掌握产品相关的知识。你要了解公司产品的时候，可以向BSA，或Development要些相关的说明文档，尽快的介入这个行业，熟悉自己要做的测试项目。说实话，我是学习经贸专业的，不是学计算机的，所以我当初的时候有点晕，我就直接拿着产品自己在那儿摸索，自己写出一个产品说明。像这样的事情，可能在大的公司会有专门的Training，在小公司可能就要自己学习产品了。
尽可能多的参加需求分析或设计开发的会议
员工间的交流很重要。在我们公司像这样的会一周大概要有一到两次，大家相互交流工作进展情况，或者是一些相关的产品功能或技术方面的交流。不一定是非常正式的，但我感觉这样的会议是非常有必要的。
还有就是公司开发部召开的会议，你也应该介入、参加。我当初介入最早的是他们的开发意向，然后一些需求分析啊，还有其他的一些设计啊等等一些会议。像这样的会议我觉得是一定要参加，因为这确实是对你的工作有很大的帮助的。因为在立项会议上，你可以了解项目的可操作性，以及项目的特点；在调研会议上，了解需求，市场需求是开发的依据，也是测试的依据。同时一定要参加需求更改会议，以便你更好的进行测试工作。在这些都做到位后，我们就开始写测试计划了。
测试计划
写测试计划就像我们在课堂上学到的那些，Test Plan、Test Case，开始我们的QA Process。这时就是具体应用的时候。写测试计划的时候要跟开发部要详细设计文档、产品规格说明书和产品使用说明这样的相关文档。如果在大公司的话，他的设计部会写产品使用说明。还有就是一定要他的开发计划，因为你做每一步测试是根据开发进度来进行的，开发计划是必不可少的。
最后根据上述的文档，从时间、内容、资源、所用工具，还有人力安排，这样一份简单的测试计划已经成形。像一般小的公司，它会对哪个人在哪天完成哪项工作是很关注的，像我们原来学的那种比较完整的文档，在这样小的公司是需要变通的，因为他们也没有很多的人力物力没有很多的时间去管理那样的文档。
编写Test Case首先要根据产品的特点编写。你的产品的特点在产品没有成型之前，你肯定不是特别了解也不是特别清楚，但是你可以根据它的框架大概的给搭出来，你能想到的尽量给细化写到文档里面，然后在测试过程中不断的完善。如果在测试执行的过程中突然间发现一个比较好的Test Case，一定要及时给补充进去，你不给它补充上去是你的一大损失，因为你以后的工作中可能还会需要这样的文档，或者以后接手你工作的人，他可能会看到这个文档，这对他以后的工作也会有很大的帮助。在大的公司有专门的测试人员分工来编写这些东西，在小公司就是测试主管或者测试员编写。像我们公司从Test Case、Test Plan、Test Execution什么的都是我来做的。
在设计Test Case的时候要考虑周到，不要重复。就我的工作来说做DW产品就是注意各个数据层次之间的数据转换及数据测试。接下来说执行测试。要按照Test Case来执行。你不能说做了Test Case而在工作的时候根本就不看，这样对你的工作是没有帮助的。因为你按照Test Case来执行的话基本就是按照自己的思路来做，这样你走到哪一步心里都非常的清楚。这样最大的好处就是减少重复的工作，可以提高工作效率。我想这点无论是在小公司还是大公司，还是就我们工作的本身都是很重要的。
然后，最好是做测试日记录，目的就是明确自己测试到哪里，以免重复工作。就我自己来说，我在做测试的时候每天都会做测试日记，一个是记录我今天发现了多少个bug，工作到哪一步了？做了哪些工作。我发现这个做测试日记录是很有意思的。每天测出了多少各bug，我虽然在QA管理工具上录了一遍，但是我还是要把它记录下来。我当初第一天去上班的时候，第一次接触到这个执行测试的时候，我记得特别清楚，我是找出了65个bug。我觉得这说明两个问题，一个是我工作特别认真，一个是开发出的软件确实是有问题。所以，你不要觉得搞开发的都很厉害，很牛啊，你会有点怵。
和开发人员的沟通。这个是对测试人员很重要的。这个我在前面提到过，每个人不是独立的在做事情，工作中都是需要相互的配合，特别是测试工作，有问题，你需要及时的和开发人员沟通。如果你连沟通都做不好，那么，你的测试工作根本就没有办法进行。在这当中，你要坚持自己的原则，就是对事不对人，因为，这个产品有问题，它就是存在bug，那么，就要有人负责去修改。你不能说，对方是部门领导你就不敢坚持自己提出的问题。第二，就是要坚守其他的测试原则，这就是我们在学习理论的时候所掌握的一些知识。因为，我们学习时的课程设计就是根据项目来设置的，很多东西基本和实际工作中相吻合。
作为测试负责人，在测试工作中我给自己订了一个基本的工作流程，现在也就当作是部门的规章制度在执行。就是录入bug以后，我会在下面做bug描述，下一步由谁接手，如何重复等等，这样既帮助了对方，也督促了对方的，会有利于工作的进度。不然，如果工作没有完成，就会出现相互推诿的现象。
查出bug后就是督促开发人员修改bug。同时也要注意bug管理工具。自己要用好bug管理工具，也要督促开发人员用好bug管理工具。因为，有很多开发人员还都是比较懒的，他当时会跟你说，都有什么bug，你到我的机器上演示给我看不就行了吗？这是一个不好的习惯，也很费时间。所以，你一定要督促他们使用bug管理工具。
接着就是测试报告的编写。这些我们在就业班的时候都学过，就是测试背景、内容、测试通过率。以及产品的优点、缺陷，还有你对项目的建议，这一切都做好了就是开测试评估会了。
关于自动化测试的一点意见
现在很多的公司，无论是大是小，无论这公司有没有用过这个测试工具，他都会问你会用几种测试工具，会自动化测试吗？我当时去面试的时候，也遇到这个问题，当时我首先问他的是，咱们公司做过手工以外的不管是性能啊还是功能其他测试吗？他们回答说没有。一个没有做好手工测试的产品，是坚决不能用工具代替手工的。自动化测试是不能代替手工的。自动化测试用好了可以节省时间提高效率。但是如果你用不好，反而会增加自己的工作量。如果你的需求和界面一直在增加，那么自动化也是用不起来的。我觉得适合自动化测试的公司，一个是产品对安全和性能要求严格的；一个可以有专人对脚本文档进行维护的。像那些手工测试不过关，需求经常变动，人员少，产品的GUI 经常改动的公司都不太适合用自动化测试。
(更多详细信息，请电：416-644-1998，或查询：www.NewJob123.com)
