时隔一年多，又回来了，这段时间公司业务调整个人机会把握，期间做了很多事情，PPT方案撰写，需求调研分析，业务流程优化，商业模式设计，项目管理办法制度建设以及项目跟踪、成本管理。表面看来与测试脱钩了，实质上对于软件工程生命周期的理解更加深入了。
    现在思考的越来越多的是项目质量管理、过程改进的方面的问题，从公司的实际业务来说，二次构建需要一个变革的过程，这个过程会痛，因为这是一个模式的变革。这几天读了林锐博士的一些文章，感觉收益匪浅，小公司是人治，大公司就要靠法治。但从软件生命周期过程来看，涉及到立项、调研分析、进度管理、变更控制、质量管理、配置管理、文档管理等。项目经理要做的就是维持好软件产品质量、进度、成本三者之间关系。
    从某种意义上来说，企业的存在是为了盈利，那么在各阶段过程中，就必须提升质量，提高效率，降低成本。这就靠有效的管理方法。过程改进也是一样，因为软件生产按照当前阶段流程无法满足成本最小化收益最大化，所以我们要参考行业先进的模型为我们活动做指导，但是不能照搬，否则流程冗长，实施困难，根本无法执行。现在流行敏捷开发模式，
   我们可以将CMMI、iso9000，PMBOK等理论知识与流行的敏捷开发模式结合，制定适合自己公司的流程制度，用一定的激励措施来提升全员工作的积极性。
  

   自从换工作了以后，不大不小的项目也做了几个，可是总有一种感觉，测试的整体流程衔接还是不完善，需求变得太快，版本控制做不到位，可能这是中国软件企业普遍的现状，上个周末，有个以前的同行的朋友，说是要回天津去一个小的公司，也是纯手工的功能测试，跟我说对测试行业的前途有点怀疑了，她的这种感觉我很能理解，其实我不是在否定功能测试的重要性，对于一个软件公司来说，测试技术的高低其实在一定程度上影响着这个公司产品或软件的质量，从而在一定程度上影响了软件产品在市场推广中的占有额，而手工测试，其实是能找出最多的系统中问题。理想中的软件公司，无论是开发还是测试方面，都需要个成熟的团队，如同现在互联网业的发展一样，都需要细分，横向纵向的关联，宏观微观的考察，这当然是需要丰富的经验。
    每天也在持续的关注51，作为测试行业的一份子，其实也特别想将来有所建树，因为年轻，所以觉得多学一点东西是不吃亏的，从某种意义上也可以说是一本万利的事哈，前几天看了各个公司的高手参加的第二届互联网测试技术大会的东西，对于测试的观点，每个人都从各自的行业角度发表的看法，百度，阿里巴巴，淘宝，腾讯。。。，在看完PPT的同时，一方面觉得有欣慰，在这些公司里边一些技术的运用还是很让人向往的；另一方面又觉得压力，测试人员只有在掌握编码能力的技术上才能更娴熟的运用测试的技术，例如自动化脚本编写，版本的每日构建，Linux/Unix下命令行的操作，数据库技术，性能测试数据分析，每一项从本质上来说都需要了解系统的架构和一些开发的技术。我们可以不开发，但是我们一定要看懂代码。
    昨天在我负责的一个系统的测试过程中，遇到了这样一个问题，关于附件上传验证，创建或修改页面，点击浏览本地文件，选择后，提交页面就报一大串错误代码，追究其根源是程序中对于附件路径的验证逻辑写错了，才导致了这样的问题。这样的问题我习惯提前分析原因，和开发人员讨论问题的解决方案，其实这对于自身的提高时是有益处的。
    我觉得现在一切的核心都是如何去拥抱一种变化，就连哲学中都说任何事情变是绝对的，不变是相对的，软件过程也是一样，如何让用例拥抱变化的需求，让测试脚本拥抱变化的测试用例，都是需要一个完善的流程和规范。
    刚入门时，急切的看高手的分享资料，实用技术，那会就是想我怎么能让自己的技术提高，现在算是入了测试行业这一门槛了，又要想更高一级的方向去努力，学习如何进行测试管理，人员的沟通，团队的建设。细微做起，才是基础。
    希望将来测试行业变得更加成熟一点，人员有所分类，各自精通，马云说过踏实勤奋一点，遇事乐观一点，做事执着一点，我想这是在任何行业中都通用的东西！

    这几天跟着去客户方那边做系统使用反馈的事情，亲身的感受到了解业务的重要性，无论我们在自己脑海中描绘想象的整个业务流程有多么好，一旦脱离了实际生活，这个东西根本不能使用，也就失去了它的价值。
    说明白了，我们做这个东西是为客户服务的，只有客户真正的用上了这个东西，我们的努力才会有成果。因此一个项目的成功是多方面的，横向的项目管理，需求管理，测试管理，配置管理。。。，纵向的从需求调研，系统架构设计，数据库设计，测试用例设计，系统实施计划等，每一个环节都必须对业务有个整体的了解。从某些意义上说，从一个业务需求点到测试用例的过程其实是一个逐渐扩展的金字塔，例如一个电子商务的系统，客户从网上下订单，如果B2C的，可以说是就是需求方下订单，供应方接收订单进行确认，再进行发货。但是对于B2B的网上购物，很大程度上有些需求方与供应方已经形成一种长久合作的关系，可以说是固定的客户，因此一些合同订单功能点的业务流程，可能就会与B2C有一些不同，最根本的宗旨是客户使用的简易方便性。
   作为一个系统的测试人员，应该时刻让自己站在用户的角度去看这个系统，尽量让自己处于业务中，运用多重角色的变换来操作这个系统，每个角色应该重点关注的东西是什么，对于电子商务网上商城，客户最希望的是将传统的销售方式转变为网上商务销售时，会保持销售量的持续增长，经营模式的转换可以更大的提升工作的效率，用最便捷的方式方法来获得更好的利益。当这个东西真正使用推广后，我们的价值也得到了体现。
    本来还想写点，发现手头又有事了。。。

   又纠结了，我的工作突然之间到了十字路口了，还要做一个选择，心里明白现在做的一个选择是很关键的决定了将来的生活，以后的生活如何，这两天闲着突然不知要干啥，学习好像也学不进去，买的书在枕边搁着，下决心要好好把性能测试看看，现在看来还是需要实践中学的

  

   真是罪过，这么久没来空间，虽说是每天也在论坛上晃悠，看看帖子，学习一些经验，可是始终没静下心来写一些东西，趁今天在家把自己的工作总结总结。
   从年前2月份到北京出差到现在可以说这段时间经历了很多很多，工作生活都有，出差的日子很忙，加班是平常事（不要被吓到O(∩_∩)O~），不过出差对于我还是学到了很多东西，客户现场的工作很紧张，我一直在鞭策自己年轻时一定要多学习，现在辛苦将来就舒服，道理就是这样。
   再说说测试这个老生长谈的话题，干了2年了，无论是认识上，实践上有了深入但远远不够，项目不断的在做，其实很多东西时通用的，我一直在努力学习一种思考解决问题的方法以及处理突发问题的技巧，做软件产品，出问题是预料之中的，没问题才是预料之外的，关键的一点是你如何做到以最高的效率来解决问题。
   上边说的都是宏观理论的东西，测试细微之处的掌握是非常重要的，测试流程，测试规范，用例设计，还有环境的搭建都需要知道，其实更确切的说测试人才要求是全才，一个项目做完了，测试人员应该是最了解这个整个系统，架构，业务功能操作，服务器搭建，数据库，系统性能等等，测试人员心中会有一个掌握，然后在这个基础上我们可以进行总结，日常中发现得问题记录积累，项目采用的方法进行引用，慢慢就形成经验，在下一个项目中使用，而我们自身的能力也逐渐的提高，你的生活水平也会慢慢提升。
   另外一点操作系统和数据库的掌握的熟练程度也是很重要的，一些大型的项目比如对于安全保密级别高的项目用到的底层的技术，操作系统的命令行控制，文件系统的权限设置等等，当我们脱离了熟悉图形化界面和鼠标操作，是否有能力做到相同的事情呢，这些只需要我们平时多积累，多实践，Unix系统没用过，我们就应该找到安装盘，自己试着安装，再把Oracle安装Linux/Unix基础上自己建表空间，表，视图一点点的学习,实践是最好的老师，我相信这句话。
   

    好久没来空间了，感觉杂草荒芜，没有生机，这一段时间实在是忙，有时加班会到凌晨，实在困了，自个休息会，测试的生活依然在重复的继续着，感受着...
    最近的项目忙得晕头转向，想想之前的和现在比起来都很简单了，测试发布环境不仅仅是windows，还有lunix，来发布版本，命令行控制web服务器的关闭与重启等，一切在不知不觉中慢慢融化，渗透，其实有些东西只是你不用它，感觉很神秘，当你走近时，发现其实很简单
    日子照样过着，希望自己每一天能进步着，奋斗着，充实着...
  

    这段时间一直处于学习中，感觉很有收获，CMMI的认证促使了公司举行了一系列的培训访谈，对测试的整个过程可以说已经基本清楚。以前模糊的细节也在渐渐的趋向清晰，看完那些文档，感悟最深的就是CMMI的过程体系的实施真的很有必要，它的价值会在以后慢慢体现出来。
   从软件作坊发展到软件工程是一个很艰难的过程，其实了解一下CMMI实施的原因就可以知道答案，它的目的是以每个项目作为采集数据的源头，来达到企业整体效益的提升。随之带来的是企业过程能力和管理能力的提升，运用数字化的管理方式来管理团队。
   软件测试作为项目过程中的一个阶段，在CMMI中的体现为验证和确认两个过程域。测试的活动是要一直贯穿在整个项目中的，不过验证强调的是过程的正确性，；而确认关注的是结果正确性，
    测试做长了，就变的越来越喜欢，当一些东西都了然于胸时，那种感觉是欣喜的，因为你已经把一些东西构建在自己心中了，将测试之路进行到底！
   
  

    项目做到后期了，有了一点点空闲时间，终于可以说说测试管理的一些东西。前段时间项目忙时白天做测试，晚上有时间一直在看朱少明的《全程软件测试》这本书，也有些收获，从项目启动到最后测试结束总结，说得很详细，也有实例，感觉很不错。
   不过现在想说的一个测试团队的管理问题。从决定要做测试这行开始，就下决心自学了几个月的测试知识，每天在百度，google上搜索，在51上徜徉，学习测试前辈们的经验之谈。在公司做第一个项目的时候，我以很虔诚的心态认真的来做我的第一份工作，很意外的担任了测试的负责人，虽然只有3个人，但这使得我考虑时更多的从整体，全局去看问题，考虑一个团队的构建和发展。
   说到管理，其实是人与人群体之间的一种关系，一个项目最基本的单位就是人，由多个人才组成了团队，团队成员之间靠的是个人的沟通能力，所以从人员的招聘，培训，组织，评估等一切方面来考察个体的沟通合作能力，作为管理者，他想要的人一定是自我时间管理很好，在团队中知识管理构建也优秀的人才，所以我们提倡开放式的交流，知识的共享达到最大化。
    在团队的基础上就是过程，这个要靠企业自身发展来决定，对于软件企业，一个良好的质量保证体系是很有必要的，还有测试流程的管理控制，缺陷生命周期等，整个过程定义好了，发展成熟了，项目才会做的更好。 
    过程之上是方法的应用，测试过程中我们要知道白盒测试，黑盒测试方法，测试的策略，测试用例设计和一些测试文档的模板，自动化测试工具软件的使用，只有方法策略正确的情形下，才能保证测试整个过程的正确性。
    方法正确，在此基础上，整个项目的管理流程会更加协调，项目计划，资源进度，角色任务，风险评估，里程碑控制每一个都是既相互独立又有联系的部分，达到整体与局部的自然融合。
    每个测试人员所期盼的就是在良好的项目管理下，执行测试，配置测试环境，分配任务状态，查看缺陷报告，跟踪解决缺陷，项目总结分析，每个部分都是测试管理活动的一部分，都离不开人的活动。
    测试这条路还很长很长，如果说国内测试行业的发展慢，地位不高的话，不如说测试行业还有更大发展空间，有人说测试这道门槛很低，的确进门容易，发展难，门槛是一个终点也是一个起点，在2009年的门槛上我会为自己的测试之路走出一个新的起点！
 

   近来有些忙，英语的学习也落了几天，没有办法，项目进入了紧张的编码阶段，我的任务是把几个模块的详细设计写出来，再写整个系统的测试用例，包括流程性的和功能的，界面的都要考虑周全。
   前天开会，项目组的人把系统的整个业务流程走了一遍，感觉认识上更深了一些，对我们后期做测试很有帮助，这个系统的流程很强，开发人员也在天天讨论，数据库的字段常常会更新，感觉到配置管理真的是很重要，
项目越大，你的感受会越深刻。
   英语学习只能在晚上抽时间看了，现在要赶快写测试用例了，最后测试的缺陷还需要提交到缺陷管理库中，努力！

   测试计划提交了，好像是走个形式似的，没有什么实质的东西，现实里的项目理想的计划总要有点差距，原想打算今天要和项目里的需求分析人员核实一下系统的业务流程，就可以进行下一步写测试用例了。毕竟现在做的还是黑盒功能测试，利用数据驱动测试，一定要熟悉需求才行。不凑巧，她有事没来，只能等下周一了。
   其实很希望现在的工作忙一点，充实一些，所谓有压力才有动力，每天在电脑前翻看一些东西，时间久了，有一点麻木的感觉，对外界都不敏感了，有时会想，再过几十年，科技发展了，是不是人都不会思考交流了。
   不过今天还是有点收获的，看了一份08年的软件评测师考试试题，涉及到了很多的知识，不会的利用网络资源来了解，性能测试好像是每年的必考题，还没接触实际的性能测试，不过觉得很有挑战力的，以前在学校时参加过软件工程师的考试，觉得也不是很难，呵呵，
   公司的图书馆说是能借书了，改天去看看，把思维视野转换一下!

  
   其实从今天早上来公司，心情就不太好，原本还想着到公司可以换个心情，没想到变得更糟了。
   项目开始一段时间了，项目组的一个技术高手设计数据库，开发人员也都做着界面，正如曾经书上看到的，测试的工作很难开展，有时连项目经理也不知道我们干什么，我们告诉他要写测试计划了，可是很多的文档都不全，
都以为测试人员就是项目大体完成后，去点鼠标的工作，唉，今天开会了，对设计的数据库表要和需求文档中的业务对应统一起来，本应该我们参与的，不弄懂业务需求，我们后期怎么测试，可是项目经理感觉这个好像与我们无关，偏偏没有通知我们，可能是在一起沟通的比较少吧，我感觉到了自己的任务，做测试，将来一定要多与人沟通，很想好好的认真干一场，却没有机会。
  这或许就是理想与现实的无奈吧！

    
    早就想好好学习英语，无论是口语交流还是英文文档翻译写作，毕竟在企业工作，将来肯定会有用的。在学校时买了新概念的书，坚持了一段时间，结果因为某种原因又荒废了。毕业了做了软件测试的工作，几个月里，看了很多的测试书籍，有中文的，也有英文的，还浏览了一些测试英文网站，觉得英语真是重要，毕竟很多先进的技术有时英文版的，所以下决心好好学了。
   申请了这个测试的空间，觉得自己有了点东西去支持，虽然接触这个行业才有几个月，但是，真是觉得要学习的东西还很多很多。在这就开了一片每日英语这个空间，把每天看到的与英语相关的，或是常用的口语，名言都记录下来，形成习惯，因为习惯会产生你意向不到的效果！

   又是周五了，每每到此时，心情会变得有点慵懒，想着周末时该干什么，这些天在网上总会看到金融危机的消息报道，回头想想，2008中国经历了许多许多，有激情，有欢乐，有痛苦，有平静，很多网站还一直在说各大著名企业裁员的新闻，可以说现在金融业，IT业等都处于一个冬季，我们所能做的就是一起努力，期待春天的到来。
   写着很多时候就不由自己了，还是说测试的事情吧，今天加入一个51上的测试翻译群，希望自己测试技术与英语能力可以得到提高，既然入了这个行业了，就尽力做到最好，而且又没有脱离自己的专业；偶然之间看到一个英文测试的网站，感觉挺好，文章都很通俗，每天看看，也可一提高一下英文水平，昨天项目组开会讨论需求，现在的任务就是做好当前的工作，只是心情也变得比前沉稳了，对于测试这职业有了深点的理解，任何一行都有他的精华所在，我们不求最好，但求更好。因为测试行业将来的发展潜力会很大的
  唠叨了这些，该整理一些东西了，暂时就写这么多吧！

    

    很多东西看得再多，也是别人的；那仅仅是一种量的积累，只有把它转化为自己的东西，才能达到质的提升。

     昨天看了一些需求分析师的电子文档，感觉很有道理。忍不住多写了几句，其实对于国内的任何的软件项目或是产品来说，需求分析是所有一些工作的根本。但是在国内的中小企业里，很多都是以开发为中心，需求，测试成了可有可无的角色，项目忙时，开发人员做完了开发就转作测试，整个项目没有一个规范的流程可言。实际做时，在需求不明，周期时间紧迫，资源不够用的情形下，早就抛掷脑后了。现在我成了测试人中的一员，在等待项目需求的日子里，在每天从网上博客论坛搜刮测试前辈经验的日子里，在心里虔诚的默念着我一定要在这个行业有所发展的日子里，我忍不住写下了这篇文章，算是对这些日子在电脑前的一点回报吧。
   

  怎样从需求分析中获得测试需求功能点

 

   项目开始时，客户交给我们的需求说明书是业务需求，需求分析师要将业务需求说明书转化为计算机行业的的系统需求说明书，而后测试人员再根据系统需求说明书提取测试需求的功能点，并以此扩展测试思路，设计出测试用例。

 那么关键之处就在于怎样提取测试需求功能点,其实不同项目的需求视图是不一样的，对于信息系统，主要是管理信息系统和事务处理系统，本质是流程电子化，数据信息化。在不同视角下的信息系统对于需求分析人员来说要了解，

而对于软件产品的需求来说，信息系统类的产品，对业务域的了解是关键；工具软件类产品，从工作场景的分析导出产品特性。

需求是什么？从业务需求到用户需求再到功能和非功能需求，导出了软件系统需求。

软件需求是指从系统实现的角度描述的，还要考虑到相关的硬件方面需求   

功能需求：定义了系统必须完成哪些事，为向用户提供有用的功能，产品必须执行的动作；

非功能需求：是指接口，系统安全，性能指标等等。

可以说，功能需求决定了项目的业务架构，而非功能需求决定了项目的技术架构

作为一名测试人员，对需求的了解程度决定了你设计的测试用例的优劣， 在较大的项目组中，往往是一个测试组长下边带着几个测试人员进行，在测试组长制定完测试计划后，心中对于项目的整体流程有个了解，知道项目在什么平台下开发，用什么语言，开发模式（B/S或C/S），架构的思想，建模技术（UML,E/R模型）数据库用什么（SQL 还是ORACLE）版本控制工具是什么（VSS还是CVS）等等。

（待续）...

 

    几个月前就想申请自己的空间，记录以后测试工作中的点点滴滴，看了51testing测试网上许多前辈的经验总结，也在论坛上获得了许多测试的知识，日子在一天天的流逝，终于找了个时间，开通了自己的博客。

   测试者具备的不仅仅是某一方面的技术，更多的是对计算机相关的知识有广泛的了解，初进此行业，看到的只是冰山的一角，了解的是一本厚书中的小小一点，所有的一切都要从头开始。

   测试者，重要的是拥有一种测试的思维，曾有人问：“对测试人来说，是工具重要还是思维重要？”的确，测试工具的给我们的工作带来了不少的便利，让我们工作的效率更高，但是测试思维是根本.

   我会一直坚持，走出自己的测试之路！