测试总结怎么写(软件测试项目总结报告模板)

一个测试活动完整的过程

项目立项前测试人员不需要提供任何工件

项目经理 通过和客户交流，完成 需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。

项目经理通过综合开发人员、测试人员以及客户的意见，完成 项目计划。然后SQA进入项目，开始进行统计和跟踪

开发人员 根据需求文档完成 需求分析文档，测试人员进行评审，评审的内容包括是否有遗漏或者双方理解不同的地方。测试人员 完成 测试计划文档。

测试人员 根据修改好的需求分析文档开始写 测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档作为测试人员撰写测试用例的补充材料。

测试用例完成后，测试和开发需要进行评审

测试人员搭建测试环境

开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现bug后提交给BugZilla

开发提交第二个版本，包括 Bug Fix 以及增加了部分功能，测试人员进行测试。

重复上面的工作，一般是 3-4 个版本后 BUG 数量减少，达到出货的要求。

如果有客户反馈的问题，需要测试人员协助重现并重新测试。

测试计划工作的目的、测试计划文档的内容包括什么？

目的：指导测试过程的纲领性文件

内容：产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流风险分析等内容。

测试用例通常包括那些内容？

不同结构的用例包括的不一样。（版本、编号、项目、设计人员、设计日期、输入、预期输出„„）

软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。

用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则：

PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。

测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。

重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为“ 高 ” ；反之亦然，一般而言，是 5 级划分。

测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。

操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。

预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在

测试人员在软件开发过程中的任务是什么？

寻找bug；

避免软件开发过程中的缺陷；

衡量软件的品质；

关注用户的需求。

总的目标是：确保软件的质量。

软件测试分为几个阶段，各阶段的测试策略和要求是什么？

按阶段分为：单元测试、集成测试、系统测试、验收测试

单元测试

单元测试能发现80%的软件缺陷。

针对软件设计的最小单位——程序模块甚至是代码段进行正确性检验的测试工作，通常由开发人员进行。通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。

单元测试测试策略：逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析

自顶向下的单元测试

方法

先对最顶层的基本单元进行测试，把所有调用的单元做成桩模块。然后再对第二层的基本单元进行测试，使用上面已测试的单元做驱动模块。依此类推直到测试完所有基本单元。

优点

在集成测试前提供早期的集成途径。在执行上和详细设计的顺序一致。不需要开发驱动模块。

缺点

随着测试的进行，测试过程越来越复杂，开发和维护成本增加。

总结

比孤立单元测试的成本高很多，不是单元测试的一个好的选择。

自底向上的单元测试

方法

先对最底层的基本单元进行测试，模拟调用该单元的单元做驱动模块。然后再对上面一层进行测试，用下面已被测试过的单元做桩模块。依此类推，直到测试完所有单元。

优点

在集成测试前提供系统早期的集成途径。不需要开发桩模块。

缺点

随着测试的进行，测试过程越来越复杂。

总结

比较合理的单元测试策略，但测试周期较长。

孤立单元测试

方法

不考虑每个单元与其它单元之间的关系，为每个单元设计桩模块或驱动模块。每个模块进行独立的单元测试。

优点

简单、容易操作，可达到高的结构覆盖率。

缺点

不提供一种系统早期的集成途径。

总结

最好的单元测试策略。

集成测试

将模块按照设计要求组装起来进行测试，主要目的是发现与接口有关的问题。由于在产品提交到测试部门前，产品开发小组都要进行联合调试，因此在大部分企业中集成测试是由开发人员来完成的。

集成测试测试策略

大爆炸集成：适用于一个维护项目或被测试系统较小

自顶向下集成：适应于产品控制结构比较清晰和稳定；高层接口变化较小，底层接口未定义或经常可能被修改；产品控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。

自顶向下测试：是从程序的初始模块开始测试。

（1）该方法会在早期发现顶层的错误。

（2）早期的程序框架可以进行演示

（3）需要开发桩模块辅助测试。有些甚至需要多个桩模块辅助，加大了桩模块本来的错误影响。

（4）测试完一个上层模块后，挑选哪个模块作为下一个测试模块，以及测试的顺序没有唯一的界定标准。

优点：较早地验证了主要控制和判断点；按深度优先可以首先实现和验证一个完整的软件功能；功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用；支持故障隔离。

缺点：柱的开发量大；底层验证被推迟；底层组件测试不充分。

注意;自底向上才需要驱动开发模块。

自底向上集成：是从程序的底层模块开始测试。

（1）I/O操作可以提前测试，更好提交测试用例。

（2）测试后比较容易观察输出。

（3）需要开发驱动模块。

（4）直到最后一个模块提交，程序才能完整的系统测试。

优点：对底层组件行为较早验证；工作最初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离。

缺点：驱动的开发工作量大；对高层的验证被推迟，设计上的错误不能被及时发现。

4. 基于进度的集成：优点具有较高的并行度，能够有效缩短项目的开发进度。缺点：桩和驱动工作量较大，有些接口测试不充分，有些测试重复和浪费。

系统测试

在集成测试通过后进行的，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有重大的影响。是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。

系统测试的测试策略

数据和数据库完整性测试；功能测试；用户界面测试；性能评测；负载测试；强度测试；容量测试；安全性和访问控制测试；故障转移和恢复测试；配置测试；安装测试；加密测试；可用性测试；版本验证测试；文档测试。

回归测试

回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。根据修复好了的缺陷再重新进行测试。回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。

验收测试

验收测试是指系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。验收测试包括Alpha测试和Beta测试。

Alpha测试：是由用户在开发者的场所来进行的，在一个受控的环境中进行。

Beta测试：由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件。

请回答集成测试和系统测试的区别，以及它们的应用场景主要是什么？

区别：

1、计划和用例编制的先后顺序：从V模型来讲，在需求阶段就要制定系统测试计划和用例，HLD的时候做集成测试计划和用例，有些公司的具体实践不一样，但是顺序肯定是先做系统测试计划用例，再做集成。

2、用例的粒度：系统测试用例相对很接近用户接受测试用例，集成测试用例比系统测试用例更详细，而且对于接口部分要重点写，毕竟要集成各个模块或者子系统。

3、执行测试的顺序：先执行集成测试，待集成测试出的问题修复之后，再做系统测试。

应用场景：

集成测试：完成单元测试后，各模块联调测试；集中在各模块的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能、以及结果的正确性验证等等；可以是整个产品的集成测试，也可以是大模块的集成测试；集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。集成测试对测试人员的编写脚本能力要求比较高。测试方法一般选用黑盒测试和白盒测试相结合。

系统测试：针对整个产品的全面测试，既包含各模块的验证性测试（验证前两个阶段测试的正确性）和功能性（产品提交个用户的功能）测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。系统测试测试软件《需求规格说明书》中提到的功能是否有遗漏，是否正确的实现。做系统测试要严格按照《需求规格说明书》，以它为标准。测试方法一般都使用黑盒测试法。

你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎么解决？

将问题提交到缺陷管理库里边进行备案；

获取判断的依据和标准：根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；

与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；

合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不掺杂个人情绪。

等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。

请问你觉得测试项目具体工作是什么？

搭建测试环境

撰写测试用例

执行测试用例

写测试计划，测试报告

测试，并提交BUG表单

跟踪bug修改情况

执行自动化测试，编写脚本，执行，分析，报告

进行性能测试，压力测试等其他测试，执行，分析，调优，报告

软件测试方法

常用的软件测试方法有两大类：静态测试方法和动态测试方法

静态测试

不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试。

动态测试

通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。在动态分析技术中,最主要的测试有白盒和黑盒。

黑盒测试

也叫功能测试或数据驱动测试，已知产品应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看做一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，因此不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

常用的黑盒测试方法有：等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。

边界值分析法

某购物中心电梯限坐15人。在电梯中安装计数器来统计乘客数量。如出现超出规定人数以外的任何情况，会有不同的警示音。软件编写后进行边界值测试，应选取的边界值是：（ ）

0,1,15,16

因果图法

等价类划分法和边界值分析法都是着重考虑输入条件，但没有考虑输入条件的各种组合，输入条件之间的相互制约关系，这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。

如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合，相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

因果图法要需要注意考虑：

所有输入/输出条件的相互制约关系以及组合关系

输入条件的依赖关系，也就是什么样的输入组合会产生什么样的输出结果，即“因果关系”

因果图中的基本符号

通常在因果图中用Ci表示原因，用Ei表示结果，各结点表示状态，可取值‘0’或‘1’。‘0’表示某状态不出现‘1‘表示某状态出现。

案例：交通一卡通自动充值软件系统需求

系统只接收50或100元纸币，一次只能使用一张纸币，一次虫子金额只能为50元或100元；

若输入50元纸币，并选择充值50元，完成充值后退卡，提示充值成功；

若输入50元纸币，并选择充值100元，提示输入金额不足，并退回50元；

若输入100元纸币，并选择充值50元，完成充值后退卡，提示充值成功，找零50元；

若输入100元纸币，并选择充值100元，完成充值后退卡，提示充值成功；

若输入纸币后在规定时间内不选择充值按钮，退回输入的纸币，并提示错误；

若选择充值按钮后不输入纸币，提示错误

找到所有输入条件编号

找到所有输出条件编号

找出所有输入，输出的制约关系

判定表法

也叫决策表，能表示输入条件的组合，以及与每一输入组合对应的动作组合，与因果图法相似，但更侧重输入条件之间的逻辑关系。

包括5个部分：

条件桩：列出所有可能的条件

条件项：列出所有的条件取值组合

动作桩：列出所有可能的操作

条件项：列出在每一种条件取值组合的情况下，执行动作桩中的哪些动作。

规则：一种条件取值组合与其对应的动作组合（即判定表中贯穿条件项和动作项的一列）构成判定表的一个规则。条件组合的数目就是规则的数目。

白盒测试

白盒测试也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，但仍然有可能存在错误。因为：穷举路径测试无法检查出程序本身是否违反了设计规范，即程序是否是一个错误的程序；穷举路径测试不可能检查出程序因为遗漏路径而出错；穷举路径测试发现不了一些与数据相关的错误。

白盒测试包括：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖,其中最强的逻辑覆盖法是（条件组合覆盖）

语句覆盖

“语句覆盖”是一个比较弱的测试标准，它的含义是：在测试时，首先设计若干个测试用例，然后运行被测程序， 使程序中的每个可执行语句至少执行一次。这时所谓“若干个”，自然是越少越好。

语句覆盖在测试被测程序中，除去对检查不可执行语句有一定作用外，并没有排除被测程序包含错误的风险。

判定覆盖

比“语句覆盖”稍强的覆盖标准是“判定覆盖”(或称branch coverage分支覆盖)标准。判定覆盖准则进行测试是指，设计若干测试用例，运行被侧程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断的真假值均曾被满足。判定覆 盖又称为分支覆盖。

条件覆盖

程序中每个判断中每个条件的可能值至少得到一次。条件覆盖并不能保证判定覆盖，条件覆盖只能保证每个条件至少有一次为真，而不是考虑所有判定的结果。

判定/条件覆盖

判断中每个条件的所有（真、假）取值至少出现一次，并且每个判断的所有（真、假）判断结果也至少出现一次

条件组合覆盖

每个判定中各条件的每一种组合至少出现一次。

为下列代码设计测试用例，要求满足条件组合覆盖，需要设计测试用例的个数为（ ）

都符合，都不符合，一个符合一个不符合（有两种情况）。

路径覆盖使程序中每一条可能的路径至少执行一次。

性能测试

测试人员通常是做为软件质量控制的一个角色，不仅仅是找bug,需要对整个软件的质量负责，性能也属于质量的一部分，因此测试人员眼中的性能应该是全面的，考虑的东西也需要全面。

测试人员需要考虑全面的性能，包括用户、开发、管理员等各个视角的性能。

测试人员在做性能测试时除开要关注表面的现象如响应时间，也需要关注本质，比如用户看不到的服务器资料利用率，架构设计是否合理？代码是否合理等方方面面。

性能测试类型

1.基准测试：在给系统施加较低压力时，查看系统的运行状况并记录相关数据作为基础参考

负载测试：是指对系统不断地增加压力或增加一定压力下的持续时间，知道系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等

模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。负载测试更多地体现了一种方法或一种技术。

压力测试:压力测试是评估系统处于或超过预期负载时系统的运行情况，关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。

是在**强负载（大数据量、大量并发用户等）**下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。

压力测试可以被看作是负载测试的一种，即高负载下的负载测试，或者说压力测试采用负载测试技术。通过压力测试，可以更快地发现内存泄漏问题，还可以更快地发现影响系统稳定性的问题。例如，在正常负载情况下，某些功能不能正常使用或系统出错的概率比较低，可能一个月只出现一次，但在高负载（压力测试）下，可能一天就出现，从而发现有缺陷的功能或其它系统问题。

通过负载测试，可以证明这一点，某个电子商务网站的订单提交功能，在10个并发用户时错误率是零，在50个并发用户时错误率是1%，而在200个并发用户时错误率是20％。

负载测试是为了发现系统的性能问题，负载测试需要通过系统性能特性或行为来发现问题，从而为性能改进提供帮助，从这个意义看，负载测试可以看作性能测试的一部分。但它们两者的目的是不一样的，负载测试是为了发现缺陷，而性能测试是为了获取性能指标。因为性能测试过程中，也可以不调整负载，而是在同样负载情况下改变系统的结构、改变算法、改变硬件配置等等来得到性能指标数据，从这个意义看，负载测试可以看作是性能测试所属的一种技术，即性能测试使用负载测试的技术、使用负载测试的工具。性能测试要获得在不同的负载情况下的性能指标数据。

通过负载测试和压力测试都可以获得系统正常工作时的极限负载或最大容量。容量测试，自然也是采用负载测试技术来实现，而在破坏性的压力测试中，容量的确定可以看作是一种副产品——间接结果。

压力测试

稳定性测试：在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定

并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题

容量测试（Volume Testing）：确定系统最大承受量，譬如系统最大用户数，最大存储量，最多处理的数据流量等

性能测试应用场景（领域）主要有：能力验证、规划能力、性能调优、缺陷发现、性能基准比较

恢复测试

恢复测试检测系统的容错能力。检测方法是采用各种方法让系统故障，检验系统是否按照要求从故障中恢复过来，并在约定的时间内开始事务处理，而且不对系统造成任何伤害。

强度测试

对系统在异常情况下的承受能力的测试，是检查系统在极限状态下运行时，性能下降的幅度是否允许的范围内。检查系统能力的最高实际限度，即软件在一些超负荷情况下的运行情况。

疲劳强度测试

指材料在无限多次交变载荷作用而不会产生破坏的最大应力，称为疲劳强度或疲劳极限。就像是寻找项目的极值，当到达极值后，会首先出现内存泄漏。

内存泄漏（Memory Leak）是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。

每一阶段测试基于的文档

单元测试：软件设计文档

集成测试：软件结构设计文档

配置项设置：需求规格说明书

系统测试：用户需求

验收测试：软件研制合同