软件测试从哪里开始到哪里结束？中间要经过哪些环节以及各环节要注意哪些事项。
鉴于每个环节都可以做为一个专题来进行探讨，所以受篇幅和时间限制，本文对有关问题未做深入剖析，只做一个宏观上的介绍。文章源自玩技e族-https://www.playezu.com/11989.html
一般而言，软件测试从项目确立时就开始了，前后要经过以下一些主要环节：文章源自玩技e族-https://www.playezu.com/11989.html
需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→RTM.文章源自玩技e族-https://www.playezu.com/11989.html
在进行有关问题阐述前，我们先明确下分工，一般而言，需求分析、测试用例编写、测试环境搭建、测试执行等属于测试开发人员工作范畴。文章源自玩技e族-https://www.playezu.com/11989.html
而测试执行以及缺陷提交等属于普通测试人员的工作范畴，测试负责人负责整个测试各个环节的跟踪、实施、管理等。文章源自玩技e族-https://www.playezu.com/11989.html
文章源自玩技e族-https://www.playezu.com/11989.html
需求分析：文章源自玩技e族-https://www.playezu.com/11989.html
需求分析由产品人员制定，他们要做的不是一份简单的文档，而是细化每一个功能的细节，每一个按钮的位置，对于稍大或复杂一点的需求都进行建模。文章源自玩技e族-https://www.playezu.com/11989.html
测试计划：文章源自玩技e族-https://www.playezu.com/11989.html
测试计划（TestPlan）一般由测试负责人来编写。文章源自玩技e族-https://www.playezu.com/11989.html
测试计划的依据主要是项目开发计划和测试需求分析结果而制定。如背景，依据，资源，策略，日程等等。
测试设计：
测试设计主要包括测试用例编写和测试场景设计两方面。
测试环境搭建：
不同软件产品对测试环境有着不同的要求。
如C/S及B/S架构相关的软件产品，那么对不同操作系统，如Windows系列、unix、linux甚至苹果OS等，这些测试环境都是必须的。
而对于一些嵌入式软件，如手机软件，如果我们想测试一下有关功能模块的耗电情况，手机待机时间等，那么我们可能就需要搭建相应的电流测试环境了。当然测试中对于如手机网络等环境都有所要求。
测试执行：
测试执行过程又可以分为以下阶段：
单元测试→集成测试→系统测试→出厂测试，其中每个阶段还有回归测试等。
测试记录：
缺陷记录总的说来包括两方面：由谁提交和缺陷描述。
一般而言，缺陷都是谁测试谁提交，当然有些公司可能为了保证所提交缺陷的质量，还会在提交前进行缺陷评估，以确保所提交的缺陷的准确性。
另外，一个版本软件测试完毕，还要根据测试情况出份测试报告，这也是所要经过的一个环节。
缺陷管理：
缺陷管理方面，很多公司都采取缺陷管理工具来进行管理，常见缺陷管理工具有Test Director、Bugfree等。
软件评估：
这里评估指软件经过一轮又一轮测试后，确认软件无重大问题或者问题很少的情况下，对准备发给客户的软件进行评估，以确定是否能够发行给客户或投放市场。
软件评估小组一般由项目负责人、营销人员、部门经理等组成，也可能是由客户指定的第三方人员组成。
测试总结：
每个版本有每个版本，每个阶段的测试总结，当项目完成RTM后，一般要对整个项目做个回顾总结，看有哪些做的不足的地方，有哪些经验可以对今后的测试工作做借鉴使用，等等。
测试总结无严格格式、字数限制。
测试维护：
由于测试的不完全性，当软件正式release后，客户在使用过程中，难免遇到一些问题，有的甚至是严重性的问题，这就需要修改有关问题，再对软件进行测试、评估、发行。
流程分析：
我们来看测试的工作内容，测试计划、测试用例、测试结论、测试报告、验收方案、问题的提交跟踪。
其实，我们真用于测试的时间是非常少的，在一周的时间，也许只有一天或不到一天的时间是在进行测试的。
测试人员只有在测试的时候才会体现出他的价值。而大部分工作却不能体现他的价值。
软件测试按照研发阶段一般分为5个部分：单元测试、集成测试、确认测试、系统测试、验收测试，下面将不同阶段需要的一些工作内容做一下梳理。
单元测试（也称为模块测试）
单元测试又称为模块测试，是针对软件设计的最小单位程序模块进行正确性检查的测试工作，单元测试需要从程序内部结构出发设计测试用例，多个模块可以平行地独立进行单元测试。
一、单元测试的内容：
1、模块接口测试
应对通过所测模块的数据流进行测试
调用所测模块时的输入参数与模块的形式参数的个数、属性和顺序是否匹配
所测模块调用子模块时，输入子模块的参数与子模块的形式参数在个数、属性和顺序上是否匹配。
输出给标准函数的参数的个数、属性和顺序是否正确。
全局变量的定义在各个模块中是否一致。
当模块通过外部设备进行输入/输出操作，文件属性是否正确、open和close语句是否正确，规定的I/O格式说明与I/O语句是否匹配；缓冲区容量是否与记录长度匹配，在读写之前是否打开了文件，读写之后是否关闭了文件，对I/O错误是否做了处理。
2、 局部数据结构测试
局部数据结构是最常见的错误来源
不一致的数据类型
不正确或不一致的数据说明
使用尚未赋值或尚未初始化的变量
错误的初始值或错误的缺省值
3、 路径测试
运算的优先次序、常见的比较和控制流
4、错误处理测试
遇见出错的条件，并设置适当的出错处理
5、边界测试
例如循环的次数，最大或最小值
6、增量测试【包括自顶向下测试：从程序顶部或初始化模块开始 与自底向上测试：程序中的终端模块开始】与非增量测试
利用设计文档设计测试用例；
创建被测模块的桩模块或驱动模块；
利用被测试模块、驱动模块和桩模块来建立测试环境，进行测试
驱动模块：相当于所测模块的主程序，它接收测试数据，把这些数据传送给所测模块，最后再输出实际结果
桩模块：用以代替所测模块调用的子模块。
//No.2//
集成测试
又称为组装测试或联合测试，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
在把各个模块连接起来的时候，穿越各个模块的接口的数据时候会丢失
一个模块的功能是否会对另一个模块的功能产生不利的影响
各个子功能组装完成后，能否达到预期的父功能
全局数据结构是否有问题
单个模块产生的误差累计起来是否会放大
模块组装成系统的方式：一次性组装方式和增殖式组装方式
一、一次性组装方式
先对模块分别进行测试，再把所有模块组装进行测试
缺点：发现错我不容易定位
二、增值式组装测试
先对一个个模块进行模块测试，然后将这些模块逐步组装成系统，分为两种方式：自顶向下的增殖方式和自底向上的增殖方式
1、自顶向下的增殖方式（不需要驱动模块）
将模块铵系统程序结构，严控制层次自顶向下进行组装。
首先以主模块作为被测模块兼驱动模块，所有直属主模块的下属模块全部用桩模块代替，对主模块进行测试。再采用深度优先或广度优先的策略，用实际模块代替桩模块，再用桩模块代替它们的直接下属模块，与已经测试的模块构成新的子系统。然后进行回归测试。
2、自底向上的增殖方式（不需要驱动模块）
由驱动模块控制最底层模块的并行测试。
3、混合增殖式
自顶向下增殖方式：
优点：能够较早的发现主要控制方面的问题
缺点：需要建立桩模块，增加了一些附加的测试，涉及算法和输入输出的模块一般在底层，这些底层模块要到组装和测试的后期才能发现。一旦发现问题就会出现过多的回归测试。
自底向上增殖方式：
优点：不需要建立桩模块，建立驱动模块要比建立桩模块要简单得多，同时涉及到算法已近输入输出的模块要先测试，把最容易出现问题的部分在早期解决。
缺点：程序一直未能作为一个实体存在，直到最后一个模块加上才能形成一个实体,控制方面最后才能接触。
三、集成测试完成的标志：
1、成功执行了测试计划中规定的所有集成测试
2、修改了所发现的错误
3、测试结果通过专门小组的评审
4、集成测试需要提交的测试报告：
5、集成测试计划、集成测试规格说明书以及集成测试分析报告
//No.3//
确认测试
确认测试的目标是验证软件的功能和性能以及其他特性是否与用户的要求一致。确认测试一般包括有效性测试和软件配置复查。一般有第三方测试机构进行。
一、进行有效性测试
现软件确认要通过一系列黑盒测试。确认测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。
无是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。
确认测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；
另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法
二、软件配置复查
保证软件配置的所有成分齐全，质量都符合要求。应该遵守用户手册和操作手册中的规定步骤。
//No.4//
系统测试
软件作为计算机系统的一部分，与硬件、网络、外设、支撑软件、数据以及人员结合在一起，在实际或模拟环境下，对计算机系统进行测试，
目的在于与系统需求比较，发现问题。
利用程序的用户文档或书面材料。通过分析目标文档来设 计系统测试，分析用户文档来阐明测试用例。
由于没有一个方法，系统测试需要大 量的创造性。事实上，设计好的系统测试用例比设计系统或程序需要更多的创造性、 智慧和经验。
为了避免有所遗漏，设计测试用例时应考虑全部的 15 种类型。
能力测试、容量测试、强度测试、易用性测试、安全性测试、
性能测试、存储测试、配置测试、兼容性/配置/转换测试、安装测试、
可靠性测试、可恢复性测试、适用性测试、文档测试、过程测试。
//No.5//
验收测试
以用户为主的测试，软件开发人员和质量保证人员参加，由用户设计测试用例。
不是对系统进行全覆盖测试，而是对核心业务流程进行测试。
部分图文来自网络，如有侵权联系删除
觉得文章不错的记得点赞哦，转发就更好了
评论