软件测试流程测试人员在熟悉和掌握项目的需求分析和概要设计后开始

1、 软件测试流程一 测试人员在熟悉和掌握项目的需求分析和概要设计后开始编写测试计划文档，测试计划是从管理和边界上对测试的目标和标准进行的规定，严格约束了项目测试的时间和测试的目标范围，有利于测试的预期完成。若测试计划有问题则会影响到整个测试的结果。二 在测试人员掌握项目的详细设计后开始编写测试设计文档，它从技术上对测试的目标和标准进行规定。（如：测试要达到的效果，哪些功能是测试的重点，哪些功能需要测试，测试用的输入数据及输出数据等都需要写入到测试设计文档中）。三 根据测试计划和测试设计来进行测试开发，这里主要做一些测试用例的开发。（测试用例：是指我们已经知道了输入数据后会得到哪些相应的输出，以此

2、来判断系统是否在按照预期来工作，一个可以检查出软件错误的用例称为好的用例。）四 测试执行：u 单元测试：主要由开发人员来完成（白盒测试）1测试目标：1) 函数，过程测试：测试函数，过程是否定义准确，功能是否达到预期要求。 主要错误有：函数，过程定义错误，功能逻辑错误2) 局部数据测试：数据的定义，名称，使用是否正常，合理。主要错误有：数型说明不明确或不一致，初始化错误或缺省值错误；变量未定义或拼写错误；数据类型不相容，下溢，上溢或指针、引用错误。3) 边界条件测试：循环边界，条件边界是否准确有效。主要错误有：由于精度误差造成的相等比较出错使得选择，循环条件边界错误。4) 执行路径测试：测试分支

3、语句中关键路和重要路径是否正常，数据是否可以正常流动。主要错误有：算术运算符优先次序不正确，运算方式不正确，初始化方式不正确，精度不够，表达式的符号表示错误，逻辑运算符不正确或优先次序错误，错误的修改循环变量。5) 出错处理：测试对于非正常输入的数据和系统自身出现的异常是否能够正常处理，报错。6) 模块接口：测试全局变量定义是否统一、调用参数是否匹配。2 测试方法：采用驱动模块来调用被测试模块，或被测试模块来调用桩模块或驱动模块调用测试模块，测试模块再调用桩模块。 测试用例测试结果驱动模块桩模块2桩模块1被测试模块测试结果被测试模块驱动模块测试用例桩模块测试结果被测试模块测试用例注：驱动模块：

4、用来调用被测试的模块，用来传送数输扩数据给被测试模块，需要来进行设计。桩模块：被被测试模块调用的模块，用来接收被测试模块的测试结果，并生成输出，需要来进行设计。u 集成测试：在所有模块开发完成和测试完成后，奖所有的模块集成为整体。（可以由开发人员进行测试，也可以由测试人员进行测试）1测试目标主要为：1) 接口测试：测试穿越模块接口的数据是否丢失，接口工作是否正常。2) 一个模块是否会对另一个模块的功能产生不利的影响。3) 各个子功能组合起来，是否能达到预期的功能要求4) 全局数据结构是否有问题5) 单个模块的误差累计效应（如：对于小数处理时多个模块的累计误差是否符合预期的要求）6) 测试软件中

5、的输入、输出、值域等是否符合商业规则。7) 值域测试：测试某一个输入操作的值域限制是否有效。8) 界面测试：查看界面中的选项、菜单、文字、图标等是否符合一般的标准。2。测试方法：采用非渐增式测试方法。即在单元测试的基础上，把所有的模块按设计要求组装在一起进行测试。u 系统测试：（由测试人员进行测试，黑盒测试）1测试目标主要为：1) 功能测试：测试人员模拟用户实际操作软件的环境，依据用户说明书和测试设计进行功能测试，确认系统实现了预期的功能要求。2) 软件设计检查：检查设计中规定的各配置项是否都齐全，包括说明书，联机帮助，外接设备等。3) 验收测试：测试软件的可移植性、兼容性、可维护性、错误的恢

6、复能力等。4) 安装测试：测试软件打包是否正确，是否有文件丢失。5) 加密测试：测试加密锁是否可以正常工作，测试有加密锁和无加密锁的情况下软件是否运转正常。6) 内存测试：测试软件是否存在内存泄漏问题。2 测试方法：按照用户说明书，软件概要设计，和测试设计来测试集成后的软件。 u 系统联调。（由测试人员来做，黑盒测试）1测试目标：1) 裸机测试：在只有操作系统的情况下测试软件是否可以正常运行。2) 操作系统测试：在不同类型的操作系统中软件是否可以正常运行。3) 冲突测试：测试所开发的软件是否与系统内其它软件不冲突。4) 配置测试：测试在不同外设的情况下软件是否可以正常工作。5) 并发性测试：在

7、不同数量的客户端同时访问时是否会出现等待时间过长问题。6) 数据库访问：测试客户端在访问数据库时的响应时间及出现错误数据传入数据库时，数据库的负载和容错能力。7) 其它大型设备：当包括大、中、小型机做服务器时测试客户端与服务器的连接情况，与服务器的运行情况及软件的运行情况。8) 破坏性测试：测试软件在突发条件下或长时间工作条件下的恢复能力，可以检验出软件在最坏的情况下的使用情况，及恢复能力。2 试方法：将通过集成测试的软件作为整个计算机系统的一个元素，与计算机硬件、外设、网络连接，与数据和人员等其他元素结合在一起。对计算机系统进行一系列的组装测试和确认测试。u 测试评估：测试完成后对软件的综合

8、性能进行一个整体评估，同时测试小组也要对本次测试做出评估，并写出评估报告。五、测试案例下面举了一个具体测试的例子，是以北国家电连锁前台销售模块为测试模块，我认为这样的测试流程对于我们公司是比较实际和可行的。做为一个软件测试工程师首先要明确测试的目的，测试的目的是为了证明软件有问题，而不是为了证明软件没有问题。测试是开发团队中不可少的一部分，他们的工作是交互的，如下图：、单元测试：接到测试申请后开始对模块进行分析如下：（以家电前台预销售开票为例）：对于发生的错误记录在测试报告中1、 首先对模块的要完成的常规功能进行测试(需要测试人员有一定的商业流程知识和对软件有一定的了解)：1>“新增“、

9、“删除”，“查询”、“关闭”按钮是否达到了预定的功能.2>单据头中的“销售/退货”是否可以生成不同的单据，根据不同的提货方式是否可以把单据发往物流中心。3>在单据体中插行和删行是否可完成相应的功能，输入商品编码后是否判断商品存在，因为输入商品编码后默入数量是1，所是检查此时是否判断库存，如果一个商品配置到多个柜组且有不同的价格是否可以根据不同的柜组取出不同的价格，如果有促销是否可以取出优惠价及提取出商品名称及规格，所在柜组，如果是门店要货则没有发货仓库，如果是物流送货是否可以正确的提取出发货仓库，如果一个商品存放在多个仓库选择仓库时是否判断库存，如果是经销，代销，联营定价商品，商品

10、价格是否可以提取出来并且不可更改，输入数量后是否可以判断库存，及应付金额是否正确，如果输入临时折扣应付金额和折扣是否正确，如果有多行，删除一行后应付金额和折扣是否正确。4>在付款部分用各种不同的付款方式进行付款查看应收金额及找零是否正确，积分卡和面值卡在刷卡时是否检查卡号存在，保存后积分是否正确。保存后要生成多张单据，检查每张单据是否存在且正确。生成的小票是否可以正常处理。5> 单据保存后是否还可以更改进行第二次保存。6>单据保存后从数据库中检查各表中的数据是否正确。2、 对模块的容错能力和事务的一致性进行检查：1> 单据头中如果输错卡号是否有正确的提示，修改为另一个错

11、误的卡号后是否还会有提示，如果卡号正确是否可以找到该卡。并且在保存的时候进行积分处理。2> 单据体中输入商品编码错误后是否有正确的提示，提示完成是否还可以继续正常录入，输入一个柜组是否判断该柜组的有效性如果不存在是否报错，并且可以继续录入，如果正确是否可以提取出该柜组的名称，输入一个仓库如果不存在是否报错，并且可以继续录入，如果正确是否可以提取出该仓库的名称，3> 如果付款不平是否可以保存，如果不能保存是否有正确的报错处理，修改后是否可以正常保存。刷面值卡时是否判断卡号的存在，如查要刷的金额大于卡余额时是否报错，且可以修改。4> 在保存时人为的在保存事件中设置错误，以测试保存

12、出错后事务可以完整的回滚。3、 对于模块界面的检查：1> 界面风格是否和其它类似功能的界面一至。如字体大小，颜色，样式，数据窗口样，文本框大小，对齐方式，错字的检查。至此对家电预销售模块的测试完成，把错误都已记录在测试报告中，此时将测试报告递交给开发人员，开发人员有权对测出的错误不进行修改，但要注明理由，最后交由项目经理决定，开发人员修改完成后会把测试报告递交给测试人员，测试人员对修改的部分进行测试，并对整个模块进行重新测试。直到模块中的bug全部被修改完，并未引起新的bug，此时添写验收报告提交项目经理签字。一般情况下，每修改四个较大的bug会引起一个新的bug。等其它相关的模块测试无

13、误后就可以进行集成测试。、集成测试：首先要对整个大模块进行分析（以家电连锁为例：如下图）1> 做门店预销售（门店送货）并在数据库中查看各个表中的数据是否正确。小票是否被处理，并记录到单品三组账。（重复做多张单据）2> 做门店预销售（物流送货）并在数据库中查看各个表中的数据是否正确。由其是数据是否发送到相应的物流中心中的相应的表，小票是否被处理。3> 在门店审核要货单，然后去物流查看要货单是否已发送到物流。若已发送到物流则在物流审核这电要货单。4> 去物流查看是否正确生成并审核由要货单生成的配送单。5> 去门店查看在物流审核的配送单是否已发送到门店并且被审核。6&g

14、t; 若是退货还要去物流查看门店审核后的配退单是否发送到物流。7> 在门店和物流查看单品三级账中是否有相应的进销存数据。8> 重复步骤17至此对家电预销售模块的测试完成，把错误都已记录在测试报告中，此时将测试报告递交给开发人员，开发人员有权对测出的错误不进行修改，但要注明理由，最后交由项目经理决定，开发人员修改完成后会把测试报告递交给测试人员，测试人员对修改的部分进行测试，并对整个流程进行重新测试。直到整个流程没有问题后添加验收报告递交项目经理签字。这样就做完了从模块级到流程级的测试。这样出来的软件基本上不会有太大的问题出现。软件经过测试是完全没有问题的，这样的认识是错误的，下面是

15、微软exchange2o0o和windows2000的团队的人员结构(这里只分析三类主要的人员，即项日经理、开发人员及测试人员) exchange 2000windows 2000项目经理25人约250人开发人员140人约1700人测试人员350人约3200人测试人员/开发人员2.51.9在经过这么庞大的测试后，windows2000还仍然存在几千个bug，经过测试的软件仍然存在问题，是因为：测试人员不可能想到所有的情况，也不可能对所有的情况进行测试，即无法进行穷举测试。注：在测试过程中发现好的测试用例要记录下来，以备下次复用。白盒测试：就是测试者能够看到程序内部结构的测试，应用于结构化开发环

16、境。黑盒测试：基于系统的功能测试，主要应用于快速开发环境。（rad）。附：1。软件测试的六大原则：1) 所有的测试都应追溯到用户需求。2) 应该在测试工作开始前较长时间内就开始编写测试计划。3) 80%的错误源于20%的模块。4) 测试应从小规模开始。5) 穷举测试是不可能的。6) 为了达到最佳效果，应由独立的第三方来构造测试。2测试中用到的文档及文档基本结构：1）测试计划书，其中应包括的条目：u 产品名称（中文名称，英文名称）u 项目名称和编号u 测试时间u 测试组组成人员u 测试目标u 测试工具u 测试用硬件环境（台式机、服务器、配件配置、其他外围设备）u 测试用软件环境（操作系统及其字配

17、套软件）u 开发方提供的文档和支持u 项目组长签字。2）测试设计书，其中应包括的条目：u 菜单及其中的选项u 按钮u 对话框u 快捷键u 组合功能u 操作流程u 输入操作u 输出结果u 配套软件的使用情况u 其他一些非功能性测试。3）测试用例：测试用例应有统一的模式，根据软件的不同有各种不同的测试用例。4）版本变更记录，主要说明修改了哪些错误或增加了哪些功能，及开发人员建议的测试重点，基中应包括的条目：u 产品名称u 项目组名称u 版本号u 测试环境变更说明（软件环竟、硬件环境）u 功能需求变更说明u 主要改动说明u 修改错误清单（或修改错误报告单）u 建议测试要点u 开发组长签字5）。说明书初稿：用户使用软件使用说明书的初稿。随着软件中的错误的修改，说明书也要做相应的修改和更新。6）。测试评估，其中包括的条目有：u 测试期产品的名称（中、英文名称）u 产品正式名称（中、英文名称）u 项目组名称和编号u 版本号u 构造号u 新增功能u 修改了上一版本哪些遗留问题u 产品建议配置（软件、硬件、配套使用产品）u 产品最低配置（软件、硬件、配套使用产品）u 加密方式u 实际测试时间u 实际测试人员u 实际测试环境u 测试活动简述u