酸甜苦辣涩，五味俱全！

一、前言
        在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能，优化性能，提高用户友好性的要求。在软件项目管理过程中，项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更，项目计划会一再调整，软件交付 日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有“需求管理”策略。
二、需求管理复杂性分析
        软件需求是整个软件开发项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把握的问题，他的复杂性体现在以下方面：
        1、需求的描述问题。缺少正式的完整的需求文档浪费了大量的人力物力，但是有了需求文档又出现了新的问题。在用户方进行的需求评审会完全是走形式，因为用户根本不去听他读那上百页的需求文档。不同层次的客户（用户）关心的问题是不一样的，想要每个客户都成为需求专家是不现实的。
        2、需求的完备程度问题。需求如何做到没有遗漏？如何准确划定系统的范围？这确实是一个两难问题，稍微大一点的系统要想穷举需求几乎是不可能的，每次开需求评审会时，总会冒出新的需求，以至于系统没有一个准确的范围界定。即使是这样，系统还是要开发，没办法，系统的范围还要硬性的划定一个，从而建立一个基线。
        3、需求开发的工期问题。在需求上花费了大量的时间，客户、软件公司是否能够忍受？为了确保需求的正确性，完备性，项目经理往往坚持要在需求阶段花费大量的时间，但是客户与公司的高层领导却会为项目迟迟看不到实际可运行的软件担心不已！他们往往会逼迫项目组尽快往前推进，而项目组的成员往往也会为系统复杂的善变的需求折腾的筋疲力尽，他们也希望尽快结束此阶段。
        4、需求的细致程度问题。需求到底描述到多细，才算可以结束了？仁者见仁，智者见智，并没有定论，如果时间允许，要想细总可以细下去的。但是，需求的周期越长，可能的变化越多，对设计的限制越严格，对需求的共性提取要求越高，所以只要大家（客户、用户、需求分析人员、设计人员测试人员）认为描述清楚了，就可以进入设计阶段了。
        5、需求的变化问题。在软件开发过程中如果只有一条真理的话，那一定是：需求的变化是永恒的，需求不可能是完备的。软件开发的过程实际上是同变化做斗争的过程，需求的变更不一定是坏事，也有可能是好事，是商业机会，对市场敏感的人可以从需求的变化中发现市场机会。
    需求变化的原因很多，如：
    ●一开始没有识别全，需要增加需求；
    ●业务发生了变化，需求必须变化；
    ●需求错误；
    ●需求不清楚。
    需求的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题，一旦发生了需求变化，你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等，需求的变化好比是万恶之源，为项目的正常的进展带来不尽的麻烦，怎么办？管理它！使需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按照标准的流程来控制需求的变化。难题随之而来，需求中的变化一般不是突发的革命性的变化，最常见的是项目需求的渐变（Project Scope Creep）问题，这种渐变很可能是客户与开发方都没有意识到的，当达到一定层度时，双方才蓦然回首，发现已经物是人非，换了一番天地。
    三、需求管理策略
        需求管理需要遵守以下策略：
   1、需求一定要与投入有必然的联系。
        需求一定要与投入有必然的联系，否则如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。人们常说世上没有免费的午餐，同样也不应该有免费的需求变更。但是，接受需求变更目前却是软件开发商不得不咽下的苦果。所以，在项目的开始无论是开发方还是出资方都要明确这一条：需求变，软件开发的投入也要变。
    2、需求的变更要经过出资者的认可。
        需求的变更引起投入的变化，所以要通过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。笔者曾经经历过一个项目，为了避免项目的风险，我们请了用户代表全程参与了开发过程，结果此用户代表在开发过程提出了大量“小的需求变更，当开发人员按此需求变更修改了软件时，在项目进入现场实施阶段时，却有大量的这些变更需要改回去，问题就是出在我们的项目组成员视该用户代表的需求为圣旨，却忽略了需求是否经过了客户方真正有决策权的人员的认可。
    3、小的需求变更也要经过正规的需求管理流程。
        小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。正是由于这种观念才使需求的渐变不可控，最终导致项目的失败。
    4、精确的需求与范围定义并不会阻止需求的变更。
        并非对需求定义的越细，越能避免需求的渐变，这是2个 层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非由于需求写细了，它就不会变化了。注意沟通的技巧。实际情况是用户、开发者都认识了到了上面的几点问题，但是由于需求的变更可能来自客户方、也可能来自开发方，作为客户他们可能不愿意为需求的变更付出更多的投资，开发方有可能是主动的变更了需求，他们的目的可能是使软件做的更精致，于是作为需求管理者、项目经理需要采用各种沟通技巧来使项目的各方各得其所。
        基于上述的问题，必须对需求进行管理，使需求能够真正成为软件工程和管理的基线，使软件计划、活动和工作产品同软件需求保持一致，使需求可以复用。

看了关于软件盲点的帖子,每个人都有不同的建议,没有统一起来,所以决定将相关有意义的说法整理一下:

1.简单的说，需求上明确要求的，你写成案例都应该是有效案例，在保证了基本需求用例覆盖后，再逐步的增加案例的类型考虑意外的情况等等
测试是计划出来的，不是测出来的

2. 建议从被测应用所涉及的实际业务开始学习起。

  由于Qq空间暂无法上传,所以就先放这边了,汗,最近没心情写感想了,不唠叨了!

人与人之间只有很小的差异，但是这种很小的差异却造成了巨大的差异！很小的差异就是所具备的心态是积极的还是消极的，巨大的差异就是成功和失败。

积极的心态有助于人们克服困难，使人看到希望，保持进取的旺盛斗志。消极心态使人沮丧、失望，对生活和人生充满了抱怨，自我封闭，限制和扼杀自己的潜能。积极的心态创造人生，消极的心态消耗人生。积极的心态是成功的起点，是生命的阳光和雨露，让人的心灵成为一只翱翔的雄鹰。消极的心态是失败的源泉，是生命的慢性杀手，使人受制于自我设置的某种阴影。选择了积极的心态，就等于选择了成功的希望；选择消极的心态，就注定要走入失败的沼泽。如果你想成功，想把美梦变成现实，就必须摒弃这种扼杀你的潜能、摧毁你希望的消极心态。

  

 

 

   拖着疲惫的身心

   越容易开心,越容易失落

   放弃了幻想,失去了方向

   断了线的风筝何时可以飘落

  

   候鸟失去了南方

   记忆深埋了那片心海

   让时间改变关系和位子

   倦鸟该歇何处……

  

强力推荐该图文并茂的伊索寓言：http://www4.19floor.net/thread-8200869-1-3.html

图很美，故事是偶们曾经童年的故事！

  匆匆感冒半月，症状却非并发，痛苦死偶！

 

  感冒发展史：头痛，发烧－－－咽痛－－－咳嗽－－－鼻塞－－－喷嚏

  第一天：头痛，发烧－－－>301挂急诊，折腾了三个小时才挂上盐水，最后的医药费令我痛恨之，不提也罢！

  第二天：头痛还是继续，坚持挂了一天的盐水，头痛症状未减轻，还是自己去买了百服宁头痛得以缓解！可恶，花钱也没见好。

  第三天－－－忘记了：扁导体发炎了，没敢再去医院，去药店买了消炎药，所谓的中成药，结果吃了两天一点都没改善，愤恨之！

            终于，在去空总讲完系统之后，整个人就垮了，车子坐的我下车就想吐，因为中饭没怎么吃，吐不出东西来；在同去的同事建议之下去了中西医结合医院，所谓的二级医院，环境还真是……，让我想到了电影中，某些卖血，卖肾，卖小孩之类的那种地方!不过进去后医生，还算客气没让我挂盐水，估计让我去那里挂盐水，我就要考虑针管是否卫生的问题了。配了些西药的消炎药，中药的中成药。再自己加上润喉药之后，终于可以开口讲话了。－－－臭美一下，我发现感冒的时候，讲话声音还是满好听的，比平常温柔了很多哈！hoho

  忘记了－－－到昨天为止，消炎药吃完了，咳嗽开始来袭，咳的我晚上都睡不好，而且还影响了别的室友，罪过呀！

  今天，为了止咳，昨天买了瓶止咳药，结果昨天晚上没睡好，早上起来就鼻塞，喷嚏也不断！

  该死的感冒，怎么会有这么长的周期呢！

  又聊到了这个问题，觉得考研还是理我这么近，可是我已经不再去想这个事情了，不是我堕落了，而是我更理智了。

  好久没联系的朋友，告诉我，考研分数出来了，线是上了，但是数学分数不理想，说不想再考了。

  但是听她的语气似乎放弃考研对她来说是件痛苦的事情。

  她想考的理由：她男朋友是研究生，她觉得自己也最好是研究生。

                    她想考研，以后当个老师。

                    她想考研后，如果上了公务员可以有更好的发展。

 如果她对自己的未来的职业规划是教师或者公务员，我认为那就继续考吧！总会考上的。如果是因为和男朋友文凭上的差距，那实在是没必要这么做。

她说，她为了她男朋友留在了绍兴，很感人哈！挺伟大的！扪心自问，我似乎暂时还做不到!

但是也因为这样，她在绍兴的待遇相对杭州就差了很多。多少还是很可惜的。毕竟她还是个文字和谈吐都不错的人。

我对考研的理解是，如果你已经有了比较稳定的男朋友，你的男朋友工作比较不错。那么为何不考虑采用自由的学习方式让自己快乐又能学以致用呢！

何况，研究生毕业后也不见得你能找到更好的工作，很多公司都不见得雇佣的起研究生，或者对于一些简单事宜，如果一个专科生能做，那为什么要请一个研究生多付那么多钱呢？

如果想要在专门为研究生提供的岗位上竞争，那不是比本科生的工作竞争更加困难吗？

良好的心态，快乐的学习方式，也许是能放开心境的！

 

现在社会，年龄，身高都不是问题了，何况学历呢！

内在美不是用学历衡量的。

     1.我买了两头小猪，可爱的恭喜发财的小猪哈，不用喂食！贴办公桌上两边了，^_^

     2.我的MSN能上了

     3.我试图远程控制别人，以失败告终

     4.我开开心心的把钱花完了，然后很无辜的告诉妈妈，我没钱了。

     5.我今天去足疗了，还去拔灌了……拔灌师说我太瘦了，让我不要拔了……我用坚强的眼泪告诉她，偶行，偶可以！终于在我的一惊一诧中，拔完了……擦干眼角的泪，我下次还要拔，能不能轻点！

     6.加班成了习惯，^_^，加班看来不是什么特别不能接受的事情哈！

     7.这个周末睡懒觉了，是我第一次在北京睡懒觉哦！也是第一个没有冲动去逛街的周末哦！

     8.怂恿了某个人买了“法腾”，不知道是对是错，我也是在别人的思想灌输下变坏的，所以最终不是我的错，^_^

     9.跟一个买化妆品的老板侃了1个多小时哈！

     10.去理发店咨询了一下关于“卷发”还是“直发”问题！

     11.去小豆面馆，找了个靠窗的位置，吃了一小时的饭，杂志相伴

     12.下了“原来爱情那么伤”，“连哭都是我的错”，“有一种爱叫做放手”，最近很稀饭“花落随”这首歌名！

     13.看了“落叶归根”，第一次在北京看电影，呵呵，当然是自己电脑上啦，^_^！正在看“家族荣誉”……    

     14.整理了一下QQ，不聊的，老隐身的，不认识的都删除的干干净净！

     15.当然给自己也搞了一下卫生，^_^，手工洗衣，嘿嘿！勤快的吧……

     16、为了拿某些东西，尝试了两次等人的心里考验（足足两个小时呢，汗）……幸亏，我发脾气还看场合，心理素质经受住了考验

     17.红了一次脸，见到大领导慌了，怕怕的，抖抖的，还要进一步锻炼哈！

     18.对于别人的减肥，有了进一步的理解……

     19.我要开始跑步啦，否则细腰就没啦……^_^

     20.我决定今天开始八点后不吃高热量食物了，宁可饿死，也不胖死……^_^，别扔鸡蛋哈……防患于未然嘛！

     21.酸奶还是要天天喝的，面包还是要天天吃的！

     22.极度厌恶第二家送饭的，那个老板真黑，把基本干扁，烂了的苹果给我们送来，有些烧坏了的菜也给我们送来，分明是欺负我们老实人的嘛！^_^，强烈BS

     23.曾因亲人的身体状况一度心烦气噪，现在好多了……

     24.看上一个锅了，可是以后怎么整回杭州呢！

     25.12号晚上从北京出发，13号早上到上海，然后——出现了分歧，是先回杭州，还是直接回宁波呢？子弹头还是很想去坐坐的说！汗！

    

 

    

       

      

  容错性测试和安全性测试容易被忽视，但这两项测试越来越显示其重要性，容错性对系统的稳定性、可靠性影响很大，而随着网络应用、电子商务、电子政务等越来越普及的同时，安全性越来越重要。容错性测试和安全性测试，相对来说，是比较难的，需要得到足够关注，需要得到设计人员、开发人员的更多参与。

1．容错性测试

容错性测试包括两个方面的测试：

     输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好的话，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。
     灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失、系统和数据是否能很快恢复。

      关于自动恢复测试，需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。
      从容错性测试的概念可以看出，容错测试是一种对抗性的测试过程。要测试软件出现故障时，如何进行故障的转移与恢复有用的数据。故障转移（Failover）是确保测试对象在出现故障时，能成功地将运行的系统或系统某一关键部分转移到其它设备上继续运行，即备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务，不影响用户的使用。要进行故障转移的全面测试, 一个好的方法是将测试系统全部对象用一张系统结构图描绘出来, 对图中的所有可能发生的故障点设计测试用例。例如，系统设计架构图中，如果存在单点失效的关键对象，就是设计的重大缺陷。

2．安全性测试
   在进行安全测试时，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如：

   想方设法截取或破译口令；
   专门开发软件来破坏系统的保护机制；
   故意导致系统失败，企图趁恢复之机非法进入；
   试图通过浏览非保密数据，推导所需信息等等。
   安全性一般分为两个层次，即应用程序级别的安全性和系统级别的安全性，针对不同的安全级别，其测试策略和方法也不相同：

应用程序级别的安全性，包括对数据或业务功能的访问，在预期的安全性情况下，操作者只能访问应用程序的特定功能、有限的数据。其测试是核实操作者只能访问其所属用户类型已被授权访问的那些功能或数据。测试时，确定有不同权限的用户类型，创建各用户类型并用各用户类型所特有的事务来核实其权限，最后修改用户类型并为相同的用户重新运行测试。
系统级别的安全性，可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问，包括对系统的登录或远程访问。其测试是核实只有具备系统和应用程序访问权限的操作者才能访问系统和应用程序。

 

   对于以上两种测试方法，容错测试，尽管没有写过完整的测试用例，也没有进行过系统的的容错测试，但是在一般的测试过程中还是会涉及到一部分该操作。但是安全测试，只能无奈的说，最多就是捡了一跟皮毛。就目前的水平和能力，还是做不到这方面的测试。需要好好努力了哈，希望一两年后，偶可以干的很顺手了哈………………！！！◎◎◎