一、项目立项
立项阶段的主要任务是确认立项的理由，提出立项建议，使立项建议成为正式项目。
二、软件开发
项目确定后，需求人员设计详细需求文档及产品原型，并制定项目计划。项目计划是一个用来协调所有其他计划，以指导项目执行和控制的可操作文件。它体现了对需求的理解，是开展项目活动的基础，也是软件项目跟踪与监控的依据。开发人员根据需求文档及产品原型编写代码。在开发阶段如果需求发生变更时，应及时以文档形式说明。
三、软件测试
项目测试的目的是检查系统是否符合项目需求规定的要求。主要进行功能测试、健壮性测试、易用性测试、用户界面测试、性能测试等（根据项目要求选择不同测试方法）测试过程在测试环境中进行。
四、基本流程
立项
主要对项目的可行性进行分析，并且确定项目是否需要测试
需求评审
需求定义完成，开发人员和测试人员对需求中不清楚、不完整、太概括或存在疑义的地方提出问题，相关人员解答并确认。需求人员在对需求进行修改的同时，应以文档形式告知开发
及测试人员。
测试工作启动
在正式测试任务下达前，开发团队应在项目（产品）开发计划完成后及时向测试团队下达预通知，告之较为确切的测试日期，提供当前最新的相关资料。部门经理和测试组长组建测试小组，并视具体情况决定是否需要调整人力、时间安排、测试环境等其它资源。测试人员可预先熟悉必要的项目（产品）资料。针对需求分析文档和项目开发计划文档测试完成后，测试组需要确定测试过程中的风险，并设计出合理的规避分险的策略，为后续的测试工作提供直接的指导。
软件测试流程
软件项目的前要工作主要是需求分析。事实上一个软件项目或产品的成败与需求分析有着非常重要的联系。因此在没有明确用户需求的情况下盲目地进行开发和测试都不能够取得理想的效果。若具备条件，测试人员应从客户需求调研阶段就介入到项目中。软件产品需求调研阶段工作流程如图所示
通过软件产品需求调研阶段工作流程图可以看到，在这一阶段有两个与软件测试相关的输出，它们分别是软件总体测试计划和系统测试方案。它们的作用是将软件细化为可检验的测试需求。一般情况下要重点考虑以下问题
1、产品基本情况调研
这部分应包括产品的一些基本情况介绍，例如产品的运行平台和应用的领域，产品的特点和主要的功能模块等。对于大的测试项目，还要包括测试的目的和侧重点。具体的要点如表所
示。
目的 | 重点描述如何使测试建立在客观的基础上，定义测试的策略及测试的配置，粗略地估计测试大致需要的周期和最终测试报告递交的时间 |
变更 | 说明有可能会导致测试计划变更的事件。包括测试工具改进了，测试环境改变了，或者是添加了新的功能 |
技术结构 | 可以借助画图，将要测试的软件划分成几个组成部分，规划成一个适用于测试的完整的系统，包括数据是如何存储的，如何传递的，每一个部分的测试是要达到什么样的目的，每一个部分是怎么实现数据更新的。还有就是常规性的技术要求，比如运行平台、需要什么样的数据库等 |
产品规格 | 制造商和产品版本号的说明 |
测试范围 | 简单地描述如何搭建测试平台，以及测试的潜在风险 |
项目信息 | 说明要测试的项目的相关资料。例如，用户文档、产品描述、主要功能的举例说明 |
2、测试需求说明
这一部分要列出所有要测试的功能项。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。有了测试需求说明，可以帮助我们了解被测试软件所有功能项当前的测试情况如何，即所有功能项中测了什么和没测什么。具体要点如表所示。
功能的测试 | 理论上测试是要覆盖所有的功能项。例如，在数据库中添加、编辑、删除记录等，这会是一个浩大的工程，但是有利于测试的完整性 |
设计的测试 | 对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试 |
整体考虑 | 这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性 |
3、测试策略和记录
这是整个测试计划的重点所在，要描述如何公正客观地开展测试，要考虑模块、功能、整体
、系统、版本、压力、性能、配置和安装等各个因素的影响。要尽可能地考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备，测试记录的具体要点如表所示。
软件测试流程公正性声明 | 要对测试的公正性、遵照的标准做一下说明，证明测试是客观的。在整体上，软件功能要满足需求，实现正确，与用户文档的描述保持一致 |
测试用例 | 描述测试用例是什么样的，采用了什么工具，工具的来源是什么，如何执行的，用了什么样的数据。测试的记录中要为将来的回归测试留有余地。当然，也要考虑同时安装的其他的软件对正在测试的软件会造成的影响 |
特殊考虑 | 有时针对一些外界环境的影响，要对软件进行一些特殊方面的测试 |
经验判断 | 对以往的测试中经常出现的问题加以考虑 |
设想 | 采取一些发散性的思维，往往能帮助您到测试的新途径 |
4、测试资源配置
项目资源计划：制定一个项目资源计划，包含的是每一个阶段的任务、所需要的资源，当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。
5、计划表
测试的计划表可以做成一个或多个项目通用的形式，根据大致的时间估计来制作，操作流程要以软件测试的常规周期作为参考，也可以是根据什么时候应该测试哪一个模块来制定。
6、配置测试环境
配置测试环境是测试实施的一个重要环节，会直接影响测试过程的效率和最终测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必要的服务器、客户端、网络连接设备，以及打印机／扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其它应用软件构成的环境。在实际测试中，软件环境又可分为主测试环境和辅助测试环境。主测试环境是测试软件功能、安全可靠性、性能、易用性等大多数指标的主要环境。一般来说，配置主测试环境可遵循下列原则。
◇符合软件运行的最低要求。测试环境首先要保证能支撑软件正常运行。
◇选用比较普及的操作系统和软件平台。
◇营造相对简单、独立的测试环境。除了操作系统外，测试机上只安装软件运行和测试必需的软件，以免不相关的软件影响测试实施。
◇无毒环境。利用有效的正版杀毒软件检测软件环境，保证测试环境中没有病毒。
辅助测试环境常常用来满足一些特殊的测试需求或测试项目。
◇兼容性测试：在满足软件运行要求的范围内，可选择一些典型的操作系统和常用应用软件对其安装卸载和主要功能进行验证。
◇模拟真实环境测试：有些软件，特别是面向大众的商品化软件，在测试时常常需要考查在真实环境中的表现。
◇横向对比测试：利用辅助测试环境“克隆”出完全一致的测试环境，从而保证横向对比测试结果的可靠性。
7、设计用例
测试用例的设计过程可以是一个由简到繁逐步细化的过程，即一个从简单的测试描述（测试功能点、测试需求等）逐步细化到能够去依照执行的测试用例的过程。
如果没有测试用例或者仅有简单的测试功能描述，测试过程难以控制，测试结果将毫无可靠性可言，同时简单的测试用例可靠性低、重用性差，并且有可能导致不同人员的理解不同。详细的测试用例就不同了，它的可靠性高，而且便于执行所需时间，易于控制。但是，要写出详细的测试用例，付出的人力、物力的代价是很大的。因此测试用例到底细化、详细到什么程度，就要综合考虑各种因素。例如，在时间要求上确定测试时间是否充足，测试执行者对系统的了解程度如何，将测试用例交给其人人执行时是否需要过多的解释等各个方面的问题。
8、问题跟踪报告
在测试的计划阶段，应该明确如何准备去做一个问题报告，以及如何去界定一个问题性质。问题报告要包括问题的发现者和修改者、问题发生的频率、用了什么样的测试用例测出该问
题，以及明区问题产生的测试环境。问题描述尽可能是定量地、分门别类地列举，问题有如表所示的3种。
严重问题 | 严重问题意味着功能不可用，或者是权限限制方面的失误等，也可能是某个地方的改变引发了其他的问题。功能没有按设计要求实现或者是一些界面交互的实现不正确 |
一般问题 | 严重影响系统或基本功能的实现，但存在合理的更正方法 |
建议问题 | 功能运行得不像要求的那么快，或者不符合某些约定俗成的习惯，但不影响系统的性能，界面显示错误，格式不对，含义模糊混淆的提示信息等 |
9、测试计划的评审
测试计划的评审，在测试真正实施开展之前，必须要认真负责地检查一遍，并获得整个测试部门人员的认同，包括部门负责人的同意和签字。
需求调研阶段完成后，人们会根据需求说明书的要求开始设计软件。首先是概要设计，之后是详细设计，最后开发人员根据产品的详细设计进行编码。这一过程叫做软件设计和编码阶段。软件设计和编码阶段的工作流程如图所示
通过软件设计和编码阶段的测试工作有两方面的内容。一方面，根据概要设计生成集成测试方案；另一方面，根据详细设计生成单元测试方案并在编码过程中开始进行单元测试，编码结束后生成单元测试总结报告。接下来进入到集成、验收测试阶段，该阶段的工作流程如图所示
通过以上的分析，可以得出这样一个结论：软件测试工作贯穿了整个软件生命周期，渗透到
从分析、设计、编程，以及测试的各个阶段中，如测试计划的编写从需求分析和设计阶段就开始了，而具体的测试工作随编程工作的不断深入也在进行中。在实际工作中，测试环节可分为明显的、同等重要的3个阶段，即：单元测试、集成测试和系统测试。测试工作中的第4个阶段是验收测试阶段，验收测试无论在规模上或性质上都和系统测试很相似，它们的根本区别在于：前者是内部的，而后者则是受“客户”控制的。如图所示是软件测试的过程流程图
◇单元测试（由开发人员进行测试）
单元测试又称为模块测试，是最小单位的测试，单元测试是在系统开发过程中进行的测试活动。在单元测试活动中，各独立单元模块将在与系统的其它部分相隔离的情况下进行测试，单元测试针对每一个程序模块进行正确性检验，检查各个程序模块是否正确地实现了规定的功能。例如，一个窗口、函数、菜单、报表或一个存储过程都可以作为一个单元进行测试。单元测试是测试的第一步，其依据是详细设计，单元测试应对模块内所有重要的控制设计测试用例，以便发现模块内部的错误。
◇集成测试（由开发人员协助测试人员进行测试）
集成测试也称综合测试，是在单元测试的基础上将已经通过测试的单元测试模块按照设计要求组装成系统或子系统，再进行的测试。很多实际例子表明，软件的一些模块虽然能够单独工作，但并不保证连接之后也肯定能正常工作。例如，一个模块可能对另一个模块可能产生不利的影响；将子功能合成时不一定产生所期望的主功能；独立可接受的误差在组装后可能会超过可接受的误差限度；全程数据结构可能有错误；可能会发现单元测试中未发现的接口方面的错误；在单元测试中无法发现时序问题（实时系统）；在单元测试中无法发现资源竞争问题。
发布评论