[关键词]测试流程、需求分析、测试用例、测试计划、缺陷管理
一、概述
一般而言，软件测试从项目确立时就开始了，前后要经过以下一些主要环节：
需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→RTM.
在进行有关问题阐述前，我们先明确下分工，一般而言，需求分析、测试用例编写、测试环境搭建、测试执行等属于测试开发人员工作范畴，而测试执行以及缺陷提交等属于普通测试人员的工作范畴，测试负责人负责整个测试各个环节的跟踪、实施、管理等。说明：
1． 以上流程各环节并未包含软件测试过程的全部，如根据实际情况还可以实施一些测试计划评审、用例评审，测试培训等。在软件正式发行后，当遇到一些严重问题时，还需要进行一些后续维护测试等。
2． 以上各环节并不是独立没联系的，实际工作千变万化，各环节一些交织、重叠在所难免，比如编写测试用例的同时就可以进行测试环境的搭建工作，当然也可能由于一些需求不清楚而重新进行需求分析等。这就和我们国家提出建设有中国特色的社会主义国家一样，只所以有中国特色，那是因为国情不一样。所以在实际测试过程中也要做到具体问题具体分析，具体解决。
二、测试流程
需求分析
需求分析（Requirment Analyzing）应该说是软件测试的一个重要环节，测试开发人员对这一环节的理解程度如何将直接影响到接下来有关测试工作的开展。可能有些人认为测试需求分析无关紧要，这种想法是很不对的。需求分析不但重要，而且至关重要！一般而言，需求分析包括软件功能需求分析、测试环境需求分析、测试资源需求分析等。其中最基本的是软件功能需求分析，测一款软件首先要知道软件能实现哪些功能以及是怎样实现的。比如一款Smartphone包括VoIP、Wi-Fi以及Bluetooth等功能。那我们就应该知道软件是怎样来实现这些功能的，为了实现这些功能需要哪些测试设备以及如何搭建相应测试环境等，否则测试就无从谈起！既然谈了需求分析，那么我们根据什么来分析呢？总不能凭空设想吧。总得说来，做测试需求分析的依据有软件需求文档、软件规格书以及开发人员的设计文档等，相信管理一些规范的公司在软件开发过程中都有这些文档。
测试计划
测试计划（Test Plan）一般由测试负责人来编写。测试计划的依据主要是项目开发计划和测试需求分析结果而制定。测试计划一般包括以下一些方面：
1． 测试背景a. 软件项目介绍；b. 项目涉及人员（如软硬件项目负责人等）介绍以及相应联系方式等。
2． 测试依据a. 软件需求文档；b. 软件规格书；c. 软件设计文档；d. 其他，如参考产品等。
3． 测试资源a. 测试设备需求；b. 测试人员需求；c. 测试环境需求；d. 其他。
4． 测试策略a. 采取测试方法；b. 搭建哪些测试环境；c. 采取哪些测试工具以测试管理工具；d. 对测试人员进行培训等。
5． 测试日程a. 测试需求分析；b. 测试用例编写；c. 测试实施，根据项目计划，测试分成哪些测试阶段（如单元测试、集成测试、系统测试阶段，α、β测试阶段等），每个阶段的工作重点以及投入资源等。
6． 其他。测试计划还要包括测试计划编写的日期、作者等信息，计划越详细越好了。计划赶不上变化，一份计划做的再好，当实际实施的时候就会发现往往很难按照原有计划开展。如在软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。所以，这些就要求测试负责人能够从宏观上来调控了。在变化面前能够做到应对自如、处乱不惊那是最好不过了。
测试设计
测试设计主要包括测试用例编写和测试场景设计两方面。一份好的测试用例对测试有很好的指导作用，能够发现很多软件问题。测试场景设计主要也就是测试环境问题了。
测试环境搭建
不同软件产品对测试环境有着不同的要求。如C/S及B/S架构相关的软件产品，那么对不同操作系统，如Windows系列、unix、linux甚至苹果OS等，这些测试环境都是必须的。而对于一些嵌入式软件，如手机软件，如果我们想测试一下有关功能模块的耗电情况，手机待机时间等，那么我们可能就需要搭建相应的电流测试环境了。当然测试中对于如手机网络等环境都有所要求。
测试环境很重要，符合要求的测试环境能够帮助我们准确的测出软件问题，并且做出正确的判断。为了测试一款软件，我们可能根据不同的需求点要使用很多不同的测试环境。有些测试环境我们是可以搭建的，有些环境我们无法搭建或者搭建成本很高。不管如何，我们的目标是测试软件问题，保证软件质量。测试环境问题，还是根据具体产品以及开发者的实际情况而采取最经济的方式吧。
测试执行
测试执行过程又可以分为以下阶段：单元测试→集成测试→系统测试→出厂测试，其中每个阶段还有回归测试等。从测试的角度而言，测试执行包括一个量和度的问题。也就是测试范围和测试程度的问题。 比如一个版本需要测试哪些方面？每个方面要测试到什么程度？从管理的角度而言，在有限的时间内，在人员有限甚至短缺的情况下，要考虑如何分工，如何合理地利用资源来开展测试。当然还要考虑以下问题：
1． 当测试人员测试的执行不到位、敷衍了事时该如何解决？
2． 测试效率问题，怎样提高测试效率？
3． 根据版本的不同特点是只做验证测试还是采取冒烟测试亦或是系统全面测试？
4． 当测试过程中遇到一些偶然性随机问题该怎样处理？
5． 当版本中出现很多新问题时该怎样对待？测试停止标准？
总之，测试执行过程中会遇到很多复杂的问题，还是那句话，具体问题具体解决！本文不做过多阐述。
测试记录
缺陷记录总的说来包括两方面：由谁提交和缺陷描述。一般而言，缺陷都是谁测试谁提交，当然有些公司可能为了保证所提交缺陷的质量，还会在提交前进行缺陷评估，以确保所提交的缺陷的准确性。在缺陷的描述上，至少要包括以下一些方面内容：
序号、标题、预置条件、操作步骤、预期结果、实际结果、注释、严重程度、概率、版本、测试者、测试日期
以上是描述一个bug时通常所要描述的内容，当然在实际提交bug时可以根据实际情况进行补充，如附上图片、log文件等。另外，一个版本软件测试完毕，还要根据测试情况出份测试报告，这也是所要经过的一个环节。
缺陷管理
缺陷管理方面，很多公司都采取缺陷管理工具来进行管理，常见缺陷管理工具有Test Director、Bugfree等。下图是一个bug从提出到close所经过的一些流程，其他比如keep No actionkeep spec等一些状态流程都未包含在内，在此仅做示范说明。
注：软件缺陷和bug两者在含义上有着细微差别，本文统称缺陷。件进行测试、评估、发行。
软件评估
这里评估指软件经过一轮又一轮测试后，确认软件无重大问题或者问题很少的情况下，对准备发给客户的软件进行评估，以确定是否能够发行给客户或投放市场。软件评估小组一般由项目负责人、营销人员、部门经理等组成，也可能是由客户指定的第三方人员组成。
测试总结
每个版本有每个版本的测试总结，每个阶段有每个阶段的测试总结，当项目完成RTM后，一般要对整个项目做个回顾总结，看有哪些做的不足的地方，有哪些经验可以对今后的测试工作做借鉴使用，等等。测试总结无严格格式、字数限制。应该说，测试总结还是很总要的。
测试维护
由于测试的不完全性，当软件正式release后，客户在使用过程中，难免遇到一些问题，有的甚至是严重性的问题，这就需要修改有关问题，修改后需要再次对软件进行测试、评估、发行。