标签：sp 数据 问题 代码 bs 工作 时间 管理 服务器
近日小组讨论会中，对项目工作过程做了些总结；我自己也针对自己经历的项目做了一点思考。
一个项目的成败衡量标准就是软件质量，软件测试关乎软件质量，所以我就谈谈自己经历过的软件测试。
（注，纯属个人观点，不同的公司，不同的项目，不同的领导，软件流程不同）
在我早期工作过的一个软件项目中，还是一个严格的CMMI流程。一个项目团队分为2组：开发组合测试组；开发测试各司其职。测试与开发流程齐头并进：需求分析（需求分析）->测试规格（设计规格）->测试计划(开发计划)->简要测试方案（概要设计）->测试方案（详细设计）->测试用例（编码、单元测试）->集成测试（联调）->循环(系统测试（解bug））->回归测试(打补丁)->验收测试…
在如今敏捷盛行的时代，项目流程基本上都迈入敏捷模式，在敏捷项目团队中，开发与测试干脆混为一个团队，并没有明显的开发测试，只是不同的成员根据自己的喜好选择不同的任务。敏捷通常以3周（2周或1月）为一个迭代周期，测试工作根据需求被划分为一个个小的任务，通常在1个或多个迭代完成。迭代的宗旨就是快速交付，测试任务和产品质量也随着不断交付加强。
随着流程在业界不断标准化，国内外流程基本上大同小异，只是在执行时会不同。
说说流程的好处吧：流程必然是经验的总结，走流程总比瞎折腾好。让我记忆最深刻的一次走流程就是：写测试用例；在某一项目中，项目经理严格要求写用例（根据预估代码比例），哪怕是一个参数的验证都要写7、8个用例（空值、边界内、边界值、边界外、超长大值、乱码…），起初我觉得非常消耗时间，是没有意义的；待真正测试执行时，我认识到很多以前写的用例是当前想象不到的，加上灵感激发新增的用例，覆盖率加大，感觉踏实多了。
有时，当面对进度与质量博弈时，常常、流程被抛弃了。在我上述的那个标准CMMI项目中，详细设计评审未过，计划时间又到了，项目经理一声令下：详细设计暂时先过了，开始写代码吧。在后续测试阶段，一堆堆bug追溯到详细设计中未解决的问题。后来，边写文档，边改代码，边测试。
敏捷，有时也同样会被玩的变味。每个敏捷周期都有一个目标，当周期结束，目标没达到时，我经历过两种截然不同的方式：A公司，加班；搞不定，继续加班；有时，3个星期的迭代硬是拖6个星期才完结。B公司，照常结束，总结目标达不到的原因。
无论测试流程怎么变，测试手段不会改变：手工，参考模型、自动化，持续集成、性能、实景测试等等。在这里主要讲一下参考模型吧，因为参考模型非常“昂贵”，一般项目不会采用。参考模型就是在开发过程中，从开发或测试人员中挑一批人马出来用不同的方式来实现相同的系统。测试时，测试人员通过相同的接口输入，比较2个系统的输出，输出结果一致是必须的；开发过程中，主开发团队与参考模型团队是隔离的。
在一个项目中，自动化能力强的项目质量必然好于非自动化、半自动化的项目。如今，越来越多的公司注重自动化和持续集成测试。在我工作过的某个项目中，功能、系统、性能、持续集成等已经做到了全自动化，测试代码与应用代码环环相扣，每一句应用代码的改动、每一个考虑不周全的地方都有可能牵一发而动全身，确保基础版本绝对的安全。
自动化的优势是不言而喻的，但是自动化维护难度大、要对系统有足够的理解，测试人员必须稳定，才能有效的与开发人员沟通。非自动化测试产品质量因人而定，人的随机性太强了，数据遗失、离职都会让测试执行推倒重来。
在测试越来越受重视的同时，对测试人员的要求越来越高。说说软件测试工程师，软件测试工程师相对开发的路子更广，因为软件测试人员需要接触客户，了解系统业务，系统运行环境、协调与开发、运维的关系，测试人员将来走向市场、管理更容易些。一个测试人员最基本的素质是：严谨、注重细节但不钻牛角尖、追求完美、不断学习。
在大肆节约成本的时代，测试流程常常还是会随心而定；很多项目经理不管测试与开发人员的思维、意愿不同，在项目初期，经常拿测试当开发用，后期，又拿开发当测试用，全然不管什么流程。但是，一个成熟的团队项目中，流程是永远不会变的，流程只是会被优化、改进，面对问题时一直在总结、解决、继续前行。
……
写这篇文章，是因为自己曾经在测试岗位上干过一段时间，依稀还记得那年一个人在几百台服务器环绕的移动机房，伴随着冰冷、噪声、辐射做性能测试时的场景。
标签：sp 数据 问题 代码 bs 工作 时间 管理 服务器
原文地址：http://blog.csdn.net/since20140504/article/details/40892593
