2010年一封邮件

                     

 话说两头 各表一枝

                                        -- 软件测试总结

前言

首先，写这篇稿子的初衷是为了总结、归纳自己的一些测试心得，也有一部分是自己的工作经验分享，或许更多的是个人的一些感悟，本篇主题意旨是针对程序员和测试员两个角度看软件测试工作，但个人的意思仅仅是为了表达它们两种从业者对待软件测试这一工作性质上的一些看法、做法，更多的是希望能够通过这篇短短的文字，彼此学习，互相促进，我本人目前从事测试工作，但并不排斥一个程序员对待测试的看法，做法。

希望每个人，不管自己是程序员或是测试员，在看这篇短文的时候，也能跳出自己的从业身份，站在更高的角度，比如说站在软件工程的角度上审视，程序员和软件测试人员在软件测试上到底做了哪些工作，哪些值得对方学习的，哪些是不足的，这样看问题，我想我们的心情是舒畅的，态度是中立的。作为我写这篇稿子的时候，也一样尽量保持这样的心态，祈求自己能客观，中立对待，稿子里面绝对不希望把程序员和测试员比作一矛一盾，那不是我的初衷，当然因为总结的目的是为了完善和提升自我，在每个方面观点后面加入了希望作为测试者（自我）应提高的地方，感谢你的耐心阅读。

 

正文

我们知道从软件工程的角度讲，软件的定义是指包括程序、数据及其相关文档的完整集合。同时我们也知道软件有一些比较特殊的特点，比如说软件是一种逻辑实体，不是具体的物理实体，它具有抽象性、软件成本昂贵、软件工作涉及到很多社会因素等等特点。而从软件的生命周期来讲，软件和任何生物一样，也有孕育、诞生、成长、成熟、衰亡的这么个过程，对应的讲就是制定计划、需求分析、设计、程序编码、测试及运行维护。

上面是从软件工程角度看软件，统计显示，在整个软件生命周期中，程序编码占的工作量还是比较小的，而作为测试我个人觉的也类似于程序编码的工作量，但就是这看似不起眼的软件测试环节也许能让你喜欢、也能让你忧。当然，在软件开发、软件测试中也许用到了很多技术手段，比如说OOP，OOA，白盒子，黑盒子等等，这些我想在这里没有作书写，原因有两点，第一，无论在代码编写或是软件测试上，就我个人能力来讲，都没有太多突出的地方，即不是个高手，固不能给大家写一些技术方面的东西；第二，我想任何技术都是为了加快或是提高开发、测试进度、质量，但是，它们始终是由人去完成，所谓的“以人为本”，当然这里不是回避和排斥新方法、工具的学习和应用，相反自己很需要学习一些工具、方法的应用。

我是从几下几个方面做的总结，分别是职责分明、态度信念、思维方式、技能学习、流程执行五个方面总结，随着积累，可能还会有新的体会，以后的工作中我希望能把它逐步完善。

 

第一 职责分明

从一个工程或产品的角度讲，任何工程或产品的问世都是集体协作的力量，当然在这里面有分工的轻重、技术难易等因素，在这里先不谈，只是阐述一点，任何产品大多是由多部门，多环节、多团队完成的事情。既然涉及多人协助，难免存在工作交叉，彼此谦让等复杂的管理问题，当然，我在这里也没能力谈管理的问题，只是为了引出职责这两个字。

软件测试技术里面讲到软件测试从测试分类到测试方法做了详细的理论知识，它也从程序员和测试角度做了相应的对号入座，比如说单元测试、集成测试由程序员完成，系统测试、可靠性测试、专项性测试由测试员或客户完成，这里面就很好地提到职责问题，同时也很分明，这样的理论知识一定在实际操作中有一定的道理，我们公司组织部门的划分，人员岗位的相对固定也是一种职责的划分形式，从项目角度来说，比如SIMportal平台、OTA平台、空中营业厅平台、Mepay等平台，在每一个平台上的项目的测试也会涉及多方人员，接触最多无疑的卡片部门的人员，这里有点跑题，下面只谈谈在平台上做测试的一些关于职责分明的话题。

程序员 当软件项目完成前期的需求讨论、概要设计、详细设计、代码编写工作后，在提交到版本控制流前会做单元测试，对集成后的模块会做集成测试，这些测试无疑是白盒子的，是透明的测试，以前工作经验和理论知识已经告诉我们，由程序员做的这些前期测试工作，会对产品的质量产生重大意义，可以尽多地将级别严重的问题及早发现并解决。在项目参与人数多、采用迭代开发模式下，更应注重前期由程序员参与的测试，站在软件工程的角度至少程序员是有义务这项职责去履行，不管我们是采用Unit系列工具，还是team Review方式，在测试过程进度上，应该有时间作保证和约束，测试结果应该有报告的方式呈现。

测试员 在项目版本集成测试结束后进入系统测试阶段，测试员参与项目的系统测试工作，在系统测试阶段，不管是功能测试、性能测试、还是压力、文档、兼容性、可靠性等等测试类别，它们都是为了通过这么多测试来保证项目的功能或性能能满足其所指定的要求，在系统测试阶段是项目面向最终使用用户的最后一个关卡，这一关应该保证测试的足够充分和彻底，即时是修改很小的地方，也应该有针对性的做系统测试，另外，在以前的工作过程中，我感觉有一个误区，那就是如果一个项目做了系统测试，没有发现任务问题，似乎这是浪费资源，其实不然，后来偶尔看一本书，发现了里面的一段话，大概意思是讲，在系统测试阶段，即使没有一个bug，但是从软件管理的角度也是一项非常有意义的工作，而且是必须要做的一项工作。我看了很不理解，但是后来自己琢磨了一下，也认为有道理，因为一个系统测试发布后的版本，意味这这个版本是经过测试，应该是有信心发布的版本，当然，发布后的版本出现了问题，那我们会从测试人员的态度、技能、流程等方面去回溯，这是另一个话题。至少在测试员职责划分上，作为一个测试员，应该无条件去执行，即使这个版本没有做任何大的改动，但只要分派了任务，就应该做积极完成。

测试员(自我）通过这两年多的在公司的测试工作磨练，我作为一个程序员，在职责分明上由不知、茫然、清晰经历了三个阶段，我现在回头想，这和我们的领导、团队里面不断的强调职责分明有大的关系，作为团队的一员，我感觉，职责分明的确立就好比我们在战场上红旗的不倒（这里比喻可能有点不准），只要红旗不到，战士们永远不会退缩、投降。在我们测试上也一样，明确职责能更好的完成任务，提高工作效率，才能保证测试质量，职责分明不是推三推四，而是为了保证一个团队整体士气和战斗力，职责分明可以让自己更好地有方向性地去工作。

第二 态度信念

每个人无论从事何工作，无论干什么事情总有个态度。这种态度，说到底就是神情，就是言行举止所表现的神态。态度信念，首先认识是个“总开关”。认识，归根结蒂，是指个人对有关事物的信念。信念有，则认识明；信念坚，则认识深。如果把以人为本仅仅看作是别人的事、领导的事，就会只想着别人、社会对自己还有哪些不足，还“欠”自己什么，而不会考虑自己应该为别人、为社会做些什么，哪些事应该做得更好一些以少留点缺憾等，这也许就是态度信念问题，人活着，无论在生活中或工作中，仔细想想，这个态度信念问题，放之四海而皆有之。

软件测试工作讲的态度信念，我觉的更应该是我们一个人在自己对待工作态度的问题，在现实生活中我们也常常讲态度如何等等之类的话题，不过，我写这篇总结的时候，仅仅是从工作而且只希望局限于对待测试任务上这点拙见。

程序员 在软件测试领域，作为程序员需要测试的地方也不少，面对测试，也有一个态度信念问题，我们知道，开发代码是一种脑力劳动活动，它不同于一般意义上的脑力活动，这种脑力劳动显的更高级、更智慧。所以，程序员也会辛苦，也会累，也有埋怨的时候。如果再让测试，有的时候会感觉乏力，这里也许就需要有态度、信念在指导和告诉程序员，辛勤开发的代码此刻正是检验成果的时候了。自己应该对自己的代码走查，测试，发现不足，可以即使修改，或许你会发现昨天写的东西今天看起来有问题，再说，只要是人一定会有犯错误的时候，在书写拼写、语法规则、逻辑实现等地方难免有出错的地方，而测试是为了亡羊补牢，何乐而不为。

测试员 作为测试员，不管是何级别的测试员，我想，关键问题就是测试两个字，测试就是自己工作的主题，自己一切行为应该以测试为核心和总则，而作为产品即将面试的最后检验者，态度信念更显的重要，讲究客观、实事求是、坚定的态度。态度不应该和资历、能力做挂沟，在职责分明中，提到过作为测试、即时是一次零缺陷的测试也是有意义的，所以讲，作为一个测试员，只要是分配了测试任务，都应该尽自己的最大的努力去完成它，不管你是老人、新人，你是普通测试人员、还是高级测试人员。这里我只是强调的态度，和具体的如何化分测试或安排测试任务没有一点关系。在测试理论的书籍或是一些招聘测试人员的门户网站上我们也可以看到，测试员需要如何如何的态度，相信必有它的意义在里面。态度信念是个大的东西，更是一个很抽象的东西，我觉得的，作为一个人也是在不断的工作和学习中积累，然后才有了归纳和感悟吧。我在这里只是就事论事，只是从我们作为一个测试员当你对待测试时这点出发的，这里没有其他意思。不涉及个人价值观、人生观等问题，因为每个人都是独一无二的个体，不能以偏盖全。回到测试员话题，作为一个测试员，秉承讲究客观、实事求是、坚定的态度这一点没错，当一个测试员处在一个团队中时，除了上面的态度信念外，我们还应该通过部门的一些流程执行来规范和约束自己的一些行为，从另一个角度讲，这也时提升整体态度信念的方式，关于流程执行后面再谈。

测试员(自我）在态度信念方面，从自己是一个测试人员的角度讲，完全认可讲究客观、实事求是、坚定的态度。下面这段话是我在2010Q2总结中写给，摘出来能代表自己对测试态度信念的一些理解，“对工作本身我觉得测试并没有那么枯燥，其实任何一种工作，都有重复性，而在重复的过程中也是对自身熟练程度、反复理解的过程，如果在测试过程中能够作到不怕麻烦、不嫌烦琐，这应该是一个测试人员最好的状态。对生活我觉得，生活犹如一本书，需要我们慢慢翻阅和思考，不要太急躁，如同走马观花，也不要停止不前，那就成孤芳自赏了”。

第三 思维方式

作为成年人，我们做任何事情按常理下都会先想一想，琢磨一下，再行动，这应该就是一种思维方式，在《成功者的思维方式》这本书中，它对思维方式做了很多解释，虽然书名叫成功者的思维方式，但在这里关注的更多的不是讨论成功或失败结果，只是说明一下我们做测试工作也应该树立一个良好的思维方式来指引我们开发工作。在书的正面写这样写到“成功的来临在很大程度上有赖于正确的思维方式，有了正确的路子，你才知道沿着什么路子走下去。”这段话写虽然简短，但里面包含的意思我们还是能够理解的，抛砖引玉下，如果在测试工作上，掌握了一些正确的思维方式，应用一些正确的测试方法，一定是一次成功的测试。

程序员 在软件测试方面，作为程序员通常关注的应该是一个方法、一段代码、一个模块在debug后，测试结果是否实现了逻辑功能，是否按需求的定义实现了该功能。至于当前自己写的code在项目集成后，能否一定实现其整体功能，或者说满足用户的需求，这个作为此刻的程序员，是无法在此刻做到的。那是应该是在项目系统测试阶段应该做的工作，应该是测试员的职责，这个我们做软件的都能明白。不过，从软件工程角度将，一个项目或软件产品的跌代开发，总是由粗到细，由大到小，逐步完善和细化的过程。而做为程序员，在测试自己的代码或模块是，无论是单元测试或是集成测试阶段，在测试上，同样也需要具备良好的思维方式，也是一个高技术程序员所追求的境界。比如说，在测试上，是否考虑代码的可扩展性，健壮性，弱耦合性等等方面技术，另外，作为程序员，不论是何级别的程序员，人和人写出的代码总是不尽相同的，我们知道，一个需求，用同一种语言，不同的程序员可能会写出的代码千差万别，风格窘异。这可能就是一个人的思维方式、经验、认识等等因素决定的吧。因为这样的结果，作为一个以团队开发为单位的组织，应该尽力讲究代码风格一致，目的当然是为了给阅读、维护的人带来高效、方便。这里也许涉及到一个流程问题，在后面在谈。

测试员 测试员是产品的把关者，作为测试员，除了在测试方法上具备良好的思维习惯，在对待bug的生命周期始终，产品的发布等等也有一个思维习惯在里面。在测试技术上，测试员始终围绕的是功能是否实现，实实在在，不论它内部机制到底是如何实现的，作为测试员，只关注的是当前版本下某一个功能是否实现，这就是作为一个测试员最基本的思维方式。而在测试技术上，作为测试员应该具备的应该更多，比如说，测试某一个功能点，从多个角度，多条路径等这就是思维方式，就好比我们写作文，思路活跃，也许写的文章也能更吸引人。还有一点，作为测试员应该去关注我们做出来的产品是否真的好用，这也许就是易用性方面，在目前，测试员也许做到这些很难，但我个人觉得，对产品反复测试后，或者你有一些测试积累后，就应该去关注一些，这些或许正是提升我们产品、提高自己测试思维习惯的最好方式，试想，你对一个产品测试一个月，一年，三年，应该讲，到这个时候，作为测试员应该讲就有自己的一些“内功”，应该能从产品角度、客户体验角度去发现问题，提出问题，这些更能体现出一个测试员的价值，努力向这方面靠近。

测试员(自我）在测试员思维方式上，我自己作为一个测试员，在公司已经有两年多的时候，自我感觉做的不够，说实在的，在技术上可能只做到了按部就班，在测试技术思维有时候会扩散一些，对某一个项目，尽力去测试全部，把想到的都用上，但是，这些其实是不够的，就向在上面写到的，作为一个已经具备了一定测试经验的测试人员，思维习惯不能停留在此处，测试员不应该只关注其功能实现，那是作为一个测试员最基本的思维，而作为测试员除了具备基本的这些思维习惯外，还要有更高的思维方式，那就是从产品角度、客户体验角度去测试你要测试的产品。

第四 技能学习

无论是技术，还是技能，应该讲都是可以通过学习来掌握的，无论是通过何种渠道、方式都是可以掌握的。正如卖油翁的话“无它，唯手熟尔”。当然，掌握了某种技能如果不经常使用、应用，技能将很快变得生疏。技能可以分为很多种，在下面的文字中，从软件测试的角度谈谈自己的一些对技能上的认识，目的的总结过往，更好的在自己未来的工作中鞭策、督促自己。

程序员 在技能学习方面，程序员应该是永远不满足的那种，我们知道，软件知识更新很快，无论是刚刚毕业的学生，还是工作多年的老手，其实做为程序员大家都是在学习中工作，在工作中学习，当通过学习掌握了某种开发方式，或某个新的架构实现方法，那作为程序员应该是最快乐的时候。很多的时候，程序员学习不光是为了工作，他们更多的是一种对新事物的求知欲，在软件测试上，程序员也是充分利用自己的技能做测试，在测试技能掌握，学习上，程序员有强的独立性。在技能学习方面，程序员似乎对一个方法的实现，架构的学习等更感兴趣，当然，在逐渐的工作中，程序员对自己开发的产品的业务功能也充满了兴趣。当然，从一个软件部门或者软件小组来说，对新知识、新技能的学习凭一个人毕竟是需要时间相对常的，而且对个体来说也是浪费很大的精力，所以，才有了知识共享，“一花独放不是春，满院春色才是春”，很好的诠释了共享的意义。也许从程序员到领导早已经意识到这一点，才有了论坛的出现。

测试员 测试员在测试上，技能的掌握和学习可能不是那么的专，比如说某一个功能的实现方法，应该讲不是诸如此类的技能，对测试人员我们感觉要求的技能知识也许更宽泛，也许不能用某一点来做衡量，但我觉得，作为一个测试员应该至少具备三点技能：1，基本软件测试理论知识 我们知道，理论知识是用来指导一个人实践的最好的老师，我们在没有理论知识的前提前工作和有理论指导下工作的结果是不一样的，虽然不是教条主义，但一个人有了理论知识，再能够通过自己融会学习，再应用到实践中去，应该讲是有很大意义的，而测试也是如此。2，基本操作能力 技能是通过学习掌握的，而掌握的程度和学习的程度也许直接会影响到你在实践中应用它的效率，比如说我们在测试中部署环境的、数据库基本的操作、Linux基本命令的操作，这些基本知识在测试人员的工作中，会经常用到，而且占部分相对大，因为作为测试人员，你这些基本技能的掌握程度，直接会在工作中体现，经验告诉我们，熟练的基本技能掌握，会大大提高测试前的准备工作和测试中的基本操作速度。当然，这些基本操作能力也不是一朝一夕所能学习会并熟练掌握它的，这需要不断学习和总结，同时，应该学会分享，分享的过程对自己也是一次再熟练的过程。3，基本业务知识 对测试人员来说，相对前面两种技能知识来说，我们讲这种能力是最需要掌握和关注的，应该从一个测试人员来说，你对业务知识的熟练程度，也许很大程度上能决定我们测试的知道，试想，我们都不熟悉产品的业务知识如何才能测试好一个产品，业务你会问，既然这一项知识对测试人员来说如此重要，为何放在最后呢？我是想，最为测试员，前面两条是一个人长久和持续去学习并关注的，就好比一个练武功的人，前面两条是你的内功，总之，个人认为，测试员应该有具备上面三条基本技能知识。

测试员（自我）通过两年的软件测试工作，自己感觉在知识技能上有一些提高，但不是很满意，在上面总结的测试员需要具备的三点技能上，目前自我感觉前面两种能力有一些提升，但在基本业务知识尚欠缺很多，比如对规范的理解、对行业知识的理解甚少，这也许是以后工作中需要加强和学习的地方。而作为一个独立的测试人员，在基本技能、基本操作能力上应该下苦工去学习，对一些行业规范、基本业务知识应该去学会倾听和思考，并产生自己的一些想法，

第五 流程执行

一个组织一定需要一套流程来规范和约束，流程的目的不是限制人们的思想，而是约束人的行为方式。遵守流程的好处可以让我们工作很高效，更和谐。养成凡事走流程的工作习惯。可以培养一个人做事情的方法、理念，既对个人提高效率、提升职业化水平有很大意义，同时对组织规范化建设具有深远的价值。

    软件测试工作也是一种组织行为，而对个体测试员也应该遵循奇流程，这样的好处是对，对测试的效率、版本的质量把握、问题的回溯都有很大的好处，下面是还是就软件测试话题，从程序员和测试员角度总结下流程执行的利弊。

程序员 通常情况下，程序员需要先做单元测试、集成测试后能提交并打包做系统测试，这应该就是流程问题，可能一般程序员都会遵循，这样做的好处，程序员的测试阶段发现的问题能很轻松解决，对个人、团队都是一种积极行为。假如我们没有按这个流程执行，或者说没有这些完全遵循，那么到了系统测试阶段暴露的问题再解决，我们发现花的时间相对多一些，而且影响大其他人员的工作。所以，作为测试员，应该遵循这样的流程，就是在系统测试前，应该有单元和集成测试。

测试员 作为测试员，虽然只参加项目的系统测试阶段，但是，在流程执行方面也不能马虎，系统测试阶段大体分三个环节来遵循流程，1，测试准备阶段 这个阶段需要测试员按流程规定撰写测试文档，在测试文档的编写上，按流程来执行，比如文档模板的、内容格式、测试计划等。2，测试过程 测试过程也是按流程执行的重要体现，比如对bug的提示提交、对测试轮次的评估、对问题解决的回归等。3，测试结束 测试结束阶段需要对报告的发布、版本发布、对遗留问题的详实记录等等有好的流程监管。这些也许作为一些细节，作为测试人员，应该慢慢体会并遵循下去，通过时间的积累，能发现它的好处，那就是会提高测试进度。

测试员(自我）对流程执行，在测试方面，自己也走了一些误区，由不理解，到明白再到后来的执行，我觉得的也是一种成长吧，通过慢慢体会，也完全理解了流程对我们个人、对一个团队、对一个部门乃至整个公司的意义。

 

结束

    通过上面的总结，写的可能比较仓促，里面有的地方可能表达的意思也不够清晰，或许会有些使人误解的地方，但总体出发点还是希望向前言说的那样，目的是希望自己能在总结中有所发展和进步，当结束这篇短文的时候，也体会到了一个人应该总结对意义，希望自己能以此为起点，学会不断总结，这应该感谢部门领导，团队同事，谢谢！

                                                       

 

 

 

总结人：武晓兵

部  门：软件开发中心

 时  间：2010-08-30