2011 工作总结

2011年已经结束了 对自己的这一年的工作做个小小的总结。并且对2012做个展望

这一年扮演的角色可真多，测试，远程，售前，实施，文档，售后。我几乎经历了除销售，系统架构，开发 之外的全部角色。从不同的角色来看待工作以及我本身更是一番滋味在心头。

测试：

     首先说说老本行测试: 这一年我依旧没有成为 工具测试er  我觉得吧作为一个测试的功底水品永远都是在提取测试点形成测试用例上面，这是基础中的基础，不论使用什么工具最终的起源点还是在测试点和测试用例上，工具只能帮我们提高工作效率，而不能代替测试本身。测试本身也是需要具备行业经验的，这在国内貌似没有形成一个统一的认识但是我还是那么认为，原因很简单因为需要测试点。测试的目的不是保证软件本身不出错，而是保证软件的每个节点都和用户的业务节点紧紧的连接在一起。就像是人的肉体和神经，肉体就是用户的业务，神经是软件本身。肉体想动起来，神经和肉体的连接点必须连接紧密。否则就像一个瘫痪的人 不管人的神经如何发出指令，肉体就是不会行动。这才是测试的最终目的。

   另外我觉得软件公司本身存在测试部门是件不太合理的事情，因为测试的立场其实应该是站在用户和软件公司之外的第三方，他的意见作为用户第软件公司产品的一种考量，可以说软件公司本身和测试就是一个对立的关系，在公司里面测试也难免沦为打杂，因为测试本身的价值无法在公司内部很明确的体现出来，而且太过严苛不光同事不高兴就连老板可能也会有意见。但是对于用户来说测试作为第三方机构介入在本身的立场上就足够让客户确定是站在自己这边的，它的专业知识能够给客户足够的参考。这样对于客户来说测试的价值就很明确的体现出来了。所以要做测试就去第三方。不过貌似现在国内市场上专业的测试机构不多。发展也不是太好，究其原因应该就是，国内客户对软件产品质量的盲从以及不愿为专业测试买单的想法，这是意识的问题。就像是其他产业的第三方鉴定机构无法做大是一个道理，不到东西破到产生纠纷的时候没人愿意为此买单。

远程：

   前段时间兼职了一段时间的远程，就是负责和客户沟通的人，相比产品的远程，做项目远程相对轻松很多，只需要面对对方几个人就可以。过程中我发现远程其实就是给前面环节的人擦屁股的工作。莫名奇妙的问题一堆堆，分析处理不外乎几种可能 1.之前代码修改后遗留的老数据到新的代码用着用着就出问题了 2.真的是测试没发现的问题（忏悔下）3.需求问题，需求记录错误，程序员理解需求错误，测试理解需求错误（课件一份好的需求是多么的重要） 4.最可恶的开发没改直接提交错误，或者各种各样的commite失败没发现的问题。

售前：

  这因该是我两年前做的角色一并说下吧。售前工作还是比较轻松的，就是配合销售做一下客户演示什么的，基本后台怎么谈的我都没有参与。不过这个阶段如果甲方的技术人员过来套消息，也只能回答比较正面的信息，为销售加把油。毕竟雇主利益至上

 

实施：

   应该不算是很专业的实施吧，不过貌似现在所在的公司的实施也不专业，装个oracle配个系统就完成了。以至于我个测试都能轻松完成。不过仅仅只针对局域网用户，对外网服务，还有服务器设置什么的。我不了解。不过我觉着这事可以由乙方实施做，也可以由甲方技术部门做，主要是看服务器是谁买的，就谁来做。

 

文档：

  其实项目组还是非常有必要配一个人专门来整理文档的。vss svn 这些版本工具的确可以来管理最原始的文件资料 如（需求修改单，需求文件，等其他记录性的基础文件） 但是如何从这些文件里面提取出，所需的信息形成报告就考验文档库的详细程度以及文档编写者对文档的熟悉程度了。用户在提交文件的时候不会理会文件是提交给谁了，只知道问文档是提交给乙方公司的工作人员了。这时候文档的适时介入就显得很必要了。这些文档放在其他用户的手上可能无法起到作用，就算是给了最终修改的用户，也只是一个人理解了，无法形成知识共享。文档管理的作用就在于形成一个完整的知识共享网络，而这个网络的管理者就是文档。所以文档就两个工作，一 是整理 二 是提取。

 

售后（合同还没正式结束项目尾声期间，不知道这是不是叫售后，姑且先叫着吧。）：

  ok软件卖出去了 项目也接近尾声用户开始要上线使用了，很多问题在这个时候会有一个集中的爆发，凡是和业务连接不紧密，需求理解错误的问题都会集中在这个时间段爆发。被客户叫过去了，客户列举软件的种种问题。好嘛，最大的那些问题全部都是关于业务流程需求不符合业务实际的问题，前期积累的一系列问题都在此刻爆发了。所以我觉得，对于项目本身来说需求是最重要最重要的东西。不过貌似公司人员的不足导致了这一项工作有三分之一都是在后期讨论中完成的。一道墙修修补补那么多当然一推就倒，因为旧需求新需求本省无法连接成一个整体。后期的工作无比艰难~现在还在艰难ing 看看今年最后有什么结局吧 敬请期待。