为什么要强调过程？为什么要强调文档？为什么不惜影响进度也要走一个变更流程？ 原因并不是软件方面的，而是心理学方面的。人总是轻浮的、急进的、善忘的。 没有过程的约束，人们就会在进行通盘考虑之前就开始动手，在动手之后也不做记录。 比如一个数据的长度变了，用户打了个招呼之后，急躁的开发人员抱怨了一下之后，打断手头上的事，跑到数据库里那里去改一长度，然后又回到手头上的事。页面上的长度较验他忘了改，到时用户又要投诉；相关的设计、维护文档他也忘了更新，新来的维护人员接手时也会跟着迷惑，问及前辈时，只能得到这样的回答：“哦，对对对，好像是某年某月改了一下，具体怎么改了哪里我也……”。
初学者入门：软件测试从零开始 出处：51TESTING 作者：王威 本文面向软件测试新手，从测试前的准备工作、测试需求收集、测试用例设计、测试用例执行、测试结果分析几个方面给出建议和方法。鉴于国内的软件开发、测试不规范的现状，本文为软件测试新手提供了若干个软件测试的关注点。 【关键词】软件测试、测试用例、测试需求、测试结果分析 引言 几年前，从学校毕业后，第一份工作就是软件测试。那时候，国内的软件企业大多对软件测试还没有什么概念，书店里除了郑人杰编写的《计算机软件测试技术》之外，几乎没有其它的软件测试相关书籍，软件测试仅仅在软件工程的教材中作为一个章节列出来，因此，我对软件测试一无所知。不过，在正式走上工作岗位之前，公司提供了为期两周的系统的软件测试技术专题培训，对接下来的软件测试工作有很大的指导意义。现在，我继续从事软件测试的培训与咨询服务，在这个过程中，亲眼目睹了很多软件测试新手面对的困惑，他们初涉软件测试行业，没有接受系统的培训，对软件测试一无所知，既不知道该测试什么，也不知道如何开始测试。下面针对上述情况，给出若干解决办法。 测试准备工作 在测试工作伊始，软件测试工程师应该搞清楚软件测试工作的目的是什么。如果你把这个问题提给项目经理，他往往会这样回答： “ 发现我们产品里面的所有 BUG ，这就是你的工作目的 ” 。作为一名软件测试新手，如何才能发现所有的 BUG ？如何开始测试工作？即便面对的是一个很小的软件项目，测试需要考虑的问题也是方方面面的，包括硬件环境、操作系统、产品的软件配置环境、产品相关的业务流程、用户的并发容量等等。该从何处下手呢？ 向有经验的测试人员学习 如果你进入的是一家运作规范的软件公司，有独立的软件测试部门、规范的软件测试流程、软件测试技术有一定的积累，那么，恭喜你！你可以请求测试经理委派有经验的测试人员作为你工作上的业务导师，由他列出软件测试技术相关书籍目录、软件测试流程相关文档目录、产品业务相关的文档目录，在业务导师的指导下逐步熟悉软件测试的相关工作。其实，在很多运作规范的软件公司，已经把上述的师父带徒弟的方式固化到流程中。 如果你进入的是一个软件测试一片空白的软件企业，那么，也恭喜你！你可以在这里开创一片自己的软件测试事业，当然，前提是老板确实认识到软件测试的重要性，实实在在需要提高产品的质量。这时候，可以到国内的软件测试论坛和相关网站上寻找软件测试资源，这种情况下，自学能力和对技术的悟性就至关重要了。 阅读软件测试的相关书籍 现在，中文版的软件测试书籍越来越多，有的是国人自己写的，有的是翻译国外经典之作。可以到 www.chinapub.com 或者 www.cnforyou.com 等网络购书的站点查找软件测试相关的书籍。目前，从国外引入的软件测试书籍有很多经典之作，但是，翻译成中文后，翻译质量对阅读效果有很大的影响。 走读缺陷跟踪库中的问题报告单 如果您所在的公司已经有软件缺陷跟踪库了，无论采用的是商用工具，如 ClearQuest 、 TestDirecter 等工具，还是采用的 Bugzilla 、 Mantis 等开源工具，这都无关紧要，缺陷跟踪库中的缺陷报告单才是有价值的。缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现，同时也是软件产品问题的集中体现。一般来说，缺陷报告单中最关键的几个部分包括：第一部分是发现缺陷的环境，包括软件环境、硬件环境等；第二部分是缺陷的基本描述；第三部分是开发人员对缺陷的解决方法。通过对上述缺陷报告单的三个部分作仔细分析，不知不觉你已经吸收了其他软件测试人员的工作经验，并掌握了软件产品常见的基本问题。这是迅速提高软件测试经验的好方法。 走读相关产品的历史测试用例 如果你所在的公司有测试用例管理系统，那么，走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。走读测试用例也是有技巧的。测试用例写作一般会包括测试用例项和根据测试用例项细化的测试用例，下面举例说明。 “ 测试用户登录的功能 ” 是一个测试项，该测试项的目的是测试用户登录功能是否正确，是否能够完成正常的登录功能，是否能够对非法用户名和密码做异常处理等等。因此，根据该用例项，可以设计出若干个测试用例，大多数情况下，测试用例项和测试用例是一对多的关系。 通过走读测试用例项目，你可以掌握应该从哪些功能点着手未来的测试工作；通过走读软件测试用例，你可以了解如何根据被测试的功能点开展软件测试用例的设计工作，包括如何确定测试用例的输入、测试用例的操作步骤和测试用例的输出结果等。 总之，走读其他软件测试人员设计的优秀软件测试用例，是提高自身用例设计水平的好方法。 学习产品相关的业务知识 软件测试人员不仅要掌握软件测试技术相关知识，对产品相关的业务知识也要学习。这很好理解，如果从事财务软件的测试工作，一定要学习财务知识；如果从事通讯产品测试工作，那么相关的通讯理论知识也是必须的；如果从事银行软件的测试，银行的业务流程也是不可或缺的知识点。 因此，在学习软件测试技术的同时，千万不要忽略产品相关业务知识的学习。如果你是一个软件测试技术专家，但是对产品业务知识一无所知，那么也只能测试出来纯粹的软件缺陷，而面对眼前出现的产品业务相关的缺陷，很可能是视而不见，如此这般，软件测试的效果会大打折扣。 识别测试需求 识别测试需求是软件测试的第一步。如果开发人员能够提供完整的需求文档和接口文档，那固然好。可以根据需求文档中描述的每个功能项目的输入、处理过程和输出，来设计测试用例。如果开发人员没有提供软件需求文档，那该如何是好？下面给出几个有效的方法： 主动获取需求 开发人员通常不会更好地考虑软件测试，如果没有开发流程的强制规定，他们通常是不愿意提供任何开发文档，即便有强制规定，需求文档也未必能够真正指导软件系统测试工作。因此，需要测试人员发挥主观能动性，与相关的软件开发项目经理和软件开发人员保持沟通，了解软件实现的主要功能是什么，并记录得收集到的信息。一般来说，开发人员即便没有提供相关需求文档，也会保存一些简单的过程文档，主动向开发人员索要这些文档，可以作为测试的参考。此外，可以与公司的技术支持人员交流，技术支持人员是最贴近用户的人，因此，通过交流可以获取第一手的用户使用感受，在测试的过程中会更加贴近用户。 当拿到相关的资料后，从哪些方面分析需求？如何与开发人员交流需求？其实，只要把握需求分析的几个关键的点就可以解决问题：输入、处理过程、输出、性能要求、运行环境，下面针对每一个项目逐一分析： 软件输入： 与该需求相关的一切可能输入，可以从这几方面考虑，输入来源、输入参数的数量、输入参数的度量单位、输入参数的时间要求、输入参数的精度和输入参数的有效输入范围。在测试用例设计中，这部分内容作为测试用例输入的依据。 处理过程： …
FireFly类似于ClearCase，主要做版本管理，好像没其他的 http://www.hansky.com.cn/cn/resource/prod/pdf/FireflyIntro.pdf ButterFly类似于ClearQuest，“缺陷跟踪、建议处理、任务计划以及工时周报”。“建议处理”就是需求变更 http://www.hansky.com.cn/cn/resource/prod/pdf/butterflybrochure.pdf http://www.hansky.com.cn/cn/doc/butterfly/quickstart/index.html
就应该在行事之前先写好一个文档
1.业务用户看的 2.系统管理员看的 3.开发人员看的
具体体现在： 1.重要的东西总是放在文档里，而不是放在脑子里 2.总是要保持产品和文档之间、文档和文档之间的一致性
看了一家软件公司竞标时提交的解决方案，觉得不错。我概述一下它的结构，以后我们可以仿照着写。 1.建设目标。 勿废话，直接指出你的方案可以带来的几个方面的好处 2.业务流程。简明地概括最基本的功能需求，最好以图形方式描述。这样甚至可以帮助客户理清他们的需求。我看到的方案中用了一种矩阵式的描述方式，x方向为流程的阶段，y方向为流程的参与者（子系统、外部系统、人类角色），效果非常不错 3.总体规划。将业务流程中提到的外部系统、子系统、角色提取出来，描述一下它们之间基本的交互，确定各自的边界。仍以图形方式为佳 4.重要功能的细节。提出你的一些精彩的解决方案，一些贴心的东西，可以加分不少 5.辅助功能及非功能需求。如性能、可靠性、易用性、权限、日志等 6.架构设计。包括逻辑架构和物理架构。前者多以“层”组织的方式描述，如表现层、业务层、持久层，每层中的子系统以及跨层的子系统等；后者就是服务器，交换机，路由器等
到底是选择CMM还是CMMI主要基于以下几个方面进行考虑： 实施企业的业务特点： 如果企业的规模不是很大，业务又集中在软件开发为主，那么还是软件CMM比较适用。如果企业的规模比较大（开发人员100人以上），并且业务不仅仅集中在软件开发，还包括硬件开发哪怕是硬件代理（采购）都可以考虑实施CMMI。 实施企业对过程改进的熟悉程度： 如果企业已经实施过ISO 9000，并且取得了较好的效果，那么可以考虑实施CMMI。如果企业虽然没有实施过CMM，但是对于过程改进一直比较关注，接受过不少相关培训，甚至能够自发的进行一些过程改进，那么也可以考虑实施CMMI。如果过去没有接触过类似的工作，那么最好先从软件CMM 2级开始，首先建立持续过程改进的思路。另外，软件CMM的要求也比CMMI要稍低一些。可以适当降低实施的难度。 实施企业对过程改进项目的预算： 不论怎样，几乎可以肯定地说，实施CMMI的费用肯定要比实施CMM高出一些。而就模型本身来看，CMMI的2级7个过程区域在内容上并不比软件CMM的2级6个关键过程区域多多少。这样的话，我们完全可以“少花钱、多办事”，也就是说可以采用CMM的实施和评估方法，但可以在过程改进的时候参考CMMI的要求，这样就经济很多。
个人认为，检验设计文档是否合格的唯一标准就是： 如果你辞职走人了，新人看着你的设计文档能不能迅速接手
1.流程数据保存多久 2.业务数据保存多久 需求文档里的保存期限是从业务角度出发，“数据”用需求中的概念来表示 维护文档里的保存期限则从操作角度出发，“数据”指的就是具体的表、具体的文件等