敏捷开发以用户需求为核心，采用迭代、循序渐进的方法进行软件开发。它强调适应性而非预测性，强调以人为中心，而不是以流程为中心。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果经过测试，都具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成。在此过程中，软件一直处于可使用状态。敏捷开发的宣言就是尽早的、持续的交付有价值的软件来使客户满意。

特点：

1、快速迭代；

2、让测试人员和开发者参与需求讨论；

3、编写可测试的需求文档；

4、多沟通，尽量减少文档；

5、响应变更胜过遵循计划；

6、及早考虑测试。

传统的开发模式和敏捷开发模式的对比：

当前的软件研发所面临的环节是不断快速变化的动态环境，包括新的机遇和市场、不断变化的经济条件、出现的新的竞争产品和服务。软件几乎是所有业务运行中的一部分，所以非常重要的一点是新的软件要迅速开发出来以抓住新的机遇，应对竞争和压力。在这种背景下，研发者许多时候宁愿牺牲一些软件质量、降低某些需求来赢得快速软件的交付。

传统的软件研发建立在对需求描述，然后进行设计、构造，最后再进行测试的完整计划上的软件开发过程是不适应快速软件开发的。而敏捷软件开发方法允许开发团队将主要精力集中在软件本身而不是在设计和编制文档上。敏捷方法普遍依赖迭代方法来完成软件研发，其目标是减少开发过程中烦琐多余的部分，通过避免那些从长远看未必有用的工作和减少可能永远都不会被用到的文档的方法达到目的。

参考文链接：https://blog.csdn.net/heyi5351230/article/details/105566819

5、软件测试的分类

1、按阶段分类

单元测试：指对软件中的最小可测试单元进行检查和验证。“单元”可以是一个函数、方法、类、功能模块或子系统模块。

实现方式包括：人工静态检查、动态执行跟踪。

人工静态检查：就是通常所说的“代码走读”，主要是保证代码逻辑的正确性。

动态执行跟踪：就是把程序代码运行起来，检查实际的运行结果和预期结果是否一致。

单元测试一般以白盒测试为主，测试的依据是：模块功能规格说明（详细设计）。

集成测试：也叫组装测试，联合测试，就是在单元测试的基础上，将所有已通过单元测试的模块按照概要设计的要求组装为子系统或系统，并进行测试的过程。

目的：确保各个单元模块组合在一起后能够按照既定意图协作运行，并确保增量的行为正确。不经过单元测试的模块是不应该进行集成测试的，否则将对集成的效果和效率带来很大影响，并且会大幅增加软件单元代码纠错的代价。

集成测试的内容包括模块之间的接口以及集成后的功能，主要使用黑盒测试方法测试继承的功能，并对以前的集成进行回归测试。

测试内容：

(1)、将各个具有相互调用关系的模块组装起来时，检查穿越模块接口的数据是否会丢失。

(2)、判断各个子功能组合起来是否能够达到预期要求的父功能。

(3)、检查一个模块的功能是否对其他模块的功能产生不良影响。

(4)、检查全局数据结构是否正确，以及在完成模块功能的过程中是否会被异常修改。

(5)、单个模块的误差累计起来，是否会放大到不可接受的程度。

测试过程：

1. 构建的确认过程；

2. 补丁的确认过程；

3. 系统集成测试测试组提交过程；

4. 测试用例设计过程；

5. 测试代码编写过程；

6. Bug的报告过程；

7. 每周的构建过程；

8. 点对点的测试过程；

9. 组内培训过程。

参考文：https://worktile.com/blog/pingcode-137/

实施方案：自底向上集成测试、自顶向下集成测试、Big-Bang集成测试、三明治集成测试、核心集成测试、分层集成测试、基于使用的集成测试等。

测试依据：软件和系统设计文档（概要设计），序列图，接口和通信协议规范，用例，组件或系统级别的架构，工作流，外部接口定义。

系统测试：是对整个系统的测试，将硬件、软件、操作人员看作一个整体，在实际运行（使用）环境下，对被测对象进行一系列的测试活动，并检验它是否有不符合系统说明书的地方。系统测试可以发现系统分析和设计中的错误。

目的：检验最终软件系统是否满足用户规定的需求。

系统测试策略，见下方最后分类。

验收测试：是部署软件之前的最后一个测试操作，向未来的用户表明系统的功能和性能如同用户所合理期待的那样。

2、按技术分类

黑盒测试：又称为功能测试，用来检测软件的每一个功能是否能够正常使用。在测试过程中，将程序看成不能打开的黑盒子，不考虑程序内部结构和特性的基础上通过程序接口进行测试，检查程序功能是否按照设计需求以及说明书的规定能够正常打开使用。

白盒测试：也称结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。根据程序的控制结构设计测试用例，主要用于软件或程序验证。

灰盒测试：是介于白盒测试和黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。

3、按执行分类

静态测试：指不运行被测程序本身，仅通过分析或检查原程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、控制针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。

静态测试方法：（1）代码检查：代码会审、代码走查、桌面检查；（2）静态结构分袖；（3）代码质量度量

动态测试：通过运行软件来检验软件的动态行为和运行结果的正确性。动态方法由三部份组成：构造测试实例、执行程序、分析程序的输出结果。

动态测试方法：（1）黑盒测试（又称为功能测试）；（2）白盒测试（又称为结构测试）。

4、按实施组织分类

α测试：（Alpha Testing）是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。

a测试的目的：评价软件产品的FLURPS（即功能、局域化、可用性、可靠性、性能和支持）。尤其注重产品的界面和特色。

a测试可以从软件产品编码结束时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。a测试即为非正式验收测试。

β测试：一种验收测试。Beta测试由软件的最终用户们在一个或多个客房场所进行，测试环境不受开发方控制，用户数量相对较多，时间不集中。

a测试和beta测试区别：a测试是软件经过测试人员测试一轮过后，能够保证软件的稳定性，可让用户进行自行操作（也可以是产品及测试人员模拟用户点击操作）。beta测试是测试软件的最后一个版本，也是产品发布前的最后一轮验收测试。

第三方测试：介于开发方和用户方之间的组织测试。目的是为了保证测试工作的客观性。

5、按测试策略分类

功能测试、性能测试、压力测试、容量测试、安全性测试、GUI测试、可用性测试、安装测试、配置测试、异常测试、备份测试、健壮性测试、文档测试、在线帮助测试、网络测试、稳定性测试。（可恢复性测试、资源消耗测试、可移植性测试）

6、软件测试的流程

不同类型的软件产品测试的方法和重点不一样，测试流程也会不一样。虽然不同软件的详细测试步骤不同，但它们遵循的最基本的测试流程是一样的。

软件的测试流程：需求分析->制定测试计划->制定测试方案->设计测试用例->执行测试->提交缺陷报告->测试分析与评审->提交测试报告->项目上线->准备下一版本测试。

需求分析：明确测试对象及测试工作的范围和测试重点。通过需求分析，测试人员可以发现软件需求中不合理的地方，如：需求描述是否完整、准确无歧义，需求优先级安排是否合理等。

在分析测试需求时要注意：被确定的测试需求必须时可核实的，测试需求必须有一个可观察、可评测的结果。无法核实的需求就不是测试需求。测试需求分析还要与客户进行交流，以澄清某些混淆，确保测试人员与客户尽早地对项目达成共识。

制定测试计划：测试计划是整个测试工作的导航图，但它时会随着项目的推进或需求的变更相应发生改变，因此测试计划的制定时随着项目发展不断调整、逐步完善的过程。

测试计划的内容：（1）确定测试范围；（2）制定测试策略；（3）安排测试资源；（4）安排测试进度；（5）预估测试风险。

设计测试用例：测试用例指的是一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。不同公司会有不同的测试用例模版，但都包含了测试用例的基本要素。

执行测试：按照测试用例进行测试的过程，这是测试人员最主要的活动阶段。执行测试过程看似简单，只要按照测试用例完成测试工作即可，但实际并不如此，测试用例数目非常多，测试人员需要完成所有测试用例的执行，每一个测试用例都可能会发现很多缺陷，测试人员要做好测试记录与跟踪，衡量缺陷的质量并编写缺陷报告。

当提交后的缺陷被开发人员修改后，测试人员需要进行回归测试。如果系统对测试用例产生了缺陷免疫，测试人员则需要编写新的测试用例。在单元测试、集成测试、系统测试、验收测试各个阶段都要进行功能测试、性能测试等，这个工作量无疑是巨大的。

编写测试报告：测试报告是对一个测试活动的总结，对项目测试过程中进行归纳，对测试数据进行统计，对项目的测试质量进行客观评价。

项目上线：测试人员写完测试报告，根据上线标准确定项目能否上线。如果达到上线标准，编写上线发布单，准备上线，上线发布单内容如下：

测试的准入准出：指什么情况下可以开始当前版本的测试工作，什么情况下可以结束当前版本的测试工作。

测试准入标准：

（1）开发编码结束，开发人员完成自测；

（2）软件需求上规定的功能都已实现，如没有完全实现，开发人员提供测试范围；

（3）测试项目通过基本的冒烟测试，界面上的功能均已经实现，符合设计规定的功能；

（4）被测项目的代码符合软件编码规范并已通过评审；

（5）开发人员提交了测试申请并提供了相应的文档资料。

测试准出标准：

（1）测试项目满足客户需求；

（2）所有测试用例都已经通过评审并成功执行；

（3）测试覆盖率已经达到要求；

（4）所有发现的缺陷都记录在缺陷管理系统；

（5）一、二级错误修复率达到100%；

（6）三、四级错误修复率达到95%；

（7）所有遗留问题都有解决方案；

（8）测试项目的功能、性能、安全性等都满足要求；

（9）完成系统测试总结报告。

测试暂停：在测试过程中可能会出现一些意外导致测试工作暂停，这种是非正常现象。

需要测试暂停的情况有：

（1）测试人员进行冒烟测试时发现重大缺陷，导致测试无法正常进行，需要暂停并返回开发；

（2）测试人员进行冒烟测试时发现bug过多，可以申请暂停测试，返回开发；

（3）测试项目需要更新调整而暂停，测试工作也要相应暂停；

（4）如果测试人员有其他优先级更高的任务，可以申请暂停测试。

项目测试流程：项目需求分析->编写测试计划->测试计划/方案评审->测试用例编写及评审->版本测试->测试完成->发布邮件/项目实施报告

版本测试流程：版本计划->是否新增功能->新增功能测试方案及评审->新增功能测试用例编写及评审->执行测试->回归测试->测试总结

7、黑盒测试，冒烟测试，回归测试，验收测试

黑盒测试

以用户的角度，从输入、输出数据的对应关系出发进行测试，完全不考虑程序内部结构和内部特性的情况下，来检验每个功能是否都能正常使用。

冒烟测试

验证软件的基本功能（或系统整体重点功能模块）是否已经实现并正常运行，只有通过冒烟测试后，才能进入更详细的测试，若测试失败，软件不再进行其他测试，直接返回给开发人员。

回归测试

指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误的一种测试方法。回归测试是指重复以前全部或部分的相同功能测试。

（回归测试指软件代码或相关配置发生变化后，采取合适的策略对原有功能重新进行确认的测试活动。---相关补充）

回归测试的场景：

（1）软件增加新功能而产生的新代码，可能给现有业务带来影响；

（2）软件中存在bug，开发人员为修复bug而修改了旧代码；

（3）软件实际上没有修改代码，但某些软件配置变了，导致某些业务功能失效；

（4）软件代码、配置文件都没变，但硬件配置（组件），如原来的硬盘停产进行替换，而硬盘生产存在批量性质量问题，可能导致软件在频繁写数据时出错。

重新测试与回归测试的区别：

1、重新测试意味着再次测试功能或错误以确保代码已修复。如未修复，则需要重新打开缺陷，如果已修复，则关闭缺陷。

2、回归测试意味着对软件程序代码更改时对其进行测试，以确保新代码不会影响软件的其他部分。

验收测试

是产品完成功能测试和系统测试之后，产品发布之前所进行的软件测试活动，目的是确保产品准备就绪，并且可以让最终用户将其用于执行产品的既定功能和任务。

8、白盒测试和黑盒测试的方法

黑盒测试方法

1、等价类划分法

主张从大量的数据中选择一部份数据用于测试，即尽可能使用最少的测试用例覆盖最多的数据，以发现更多的软件缺陷。

（1）划分等价类：有效等价类和无效等价类。

有效等价类就是有效的集合，它们是符合程序要求、合理且有意义的输入数据。
无效等价类就是无效的集合，它们是不符合程序要求、不合理或无意义的输入数据。

（2）设计测试用例时，要同时考虑到这两种等价类，因为软件不仅要能接收合理的数据，也要能经受异常数据的考验。经过正反的测试才能确保软件具有更高的可靠性。

（3）确定等价类的6个原则

输入条件规定了取值范围或值的个数的情况下，可以确立一个有效等价类和两个无效等价类。
在输入条件规定了输入值的集合或者规定了"必须如何"的条件情况下，可以确立一个有效等价类和一个无效等价类。
在输入条件是一个布尔量的情况下，可以确定一个有效等价类和一个无效等价类。
多输入的或关系，在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
多输入的且关系，在规定了输入数据必须遵守规则的情况下，可确立一个有效等价类和若干个无效等价类（从不同角度违反规则）。
细分等价类，在确知已划分的等价类中，各元素在程序处理中的方式不同的的情况下，则应该再将该等价类进一步地划分为更小的等价类。

（4）建立等价类表

输入条件	有效等价类	无效等价类
...	...	...
...	...	...

2、边界值分析法

是对软件的输入或输出边界进行测试的一种方法，它通常作为等价类划分法的一种补充测试。

（1）取值思想

选取正好等于、刚刚大于，刚刚小于等价类边界的值作为测试数据。如：

a.如果输入条件规定了值的范围，则应取刚到到这个范围的边界值，以及杠杆超越这个范围边界的值。

b.如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少，比最大个数大1的数做测试值。

c.如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作测试用例。

d.如果程序的规格说明给出的输入输出域上有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。

e.一些可能鱼边界有关的数据类型：数值（最大值/最小值），速度（最快/最慢第一/最后），字符（最长/最短），地址（相邻/最远），位置（最近/最远最高/最低），尺寸（最长/最短），数量（最多/最少），体积（空/满超过/在内）等。

（2）次边界条件

普通边界条件最容易找到，在产品说明说中有定义，但有些边界在软件的内部，最终用户几乎看不到，但是软件测试仍有必要检查。这种边界条件称为次边界条件或者内部边界条件。

寻找这样的边界不要求软件测试人员具有程序员那样阅读源代码的能力，但要求大体了解软件的工作方式。

（3）单故障假设

3、判定表法

借助表格方法完成对输入条件的组合设计，以达到完全组合覆盖的测试效果。它是黑盒测试方法中最严格，最具有逻辑性的测试方法，又称为决策表发。

（1）判定表元素：条件项、条件桩，动作项、动作桩，规则。

（2）适合使用判定表设计测试用例的条件

a.规则说明以判定表的形式给出，或很容易转换成判定表。

b. 条件和规则的排列顺序不影响执行哪些操作。

c. 当某一条规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。

d. 如果某一规则要执行多个操作，这些操作的执行顺序无关紧要。

4、因果图法

（1）实际中当输入条件的个数和取值都很多的情况下，组合数就是非常大，决策表已经不适用。

（2）因果图法，借助图形，着重分析输入条件的各种组合，每种组合条件就是“因”，输出的结果就是“果”。因果图是一种形式化的图形语言，实质上是使用简化记号表示数字逻辑图，不仅能发现输入、输出中的错误，还能指出程序规范中的不完全性和二义性。

（3）符号分析：基本符号（输入和输出之间），约束符号（输入之间，输出之间）两类

基本符号有：恒等、非、或、与。

约束符号有：互斥、或、唯一、要求、屏蔽。

5、组合覆盖法

最常用的是Pair-wise方法，即将众多因素的值两两组合起来而大大减少测试用例组合，该方法经济有效。

Pair-wise方法基本原理：

不要测试所有的组合，测试所有的“Pairwise ”即可。（覆盖任意2个因素所有状态的测试用例集合）

如果完全组合，其组合数是3 x 4 x 4 x 3 = 144种，但如果采用两两组合，其组合数只有17项

6、正交实验法

正交测试法使用已经构造好了的正交表格来安排试验并进行数据分析。

正交表的两个优越性，即“均匀分散，整齐可比”。

在这里插入图片描述

7、功能图法（黑白盒混合）

（1）使用功能图形式化地表示程序的功能说明，并机械地生成功能图地测试用例。

（2）功能图的两个组成部分：状态迁移图（STD），逻辑功能模型（LFM）。

STD用于表示输入数据序列以及相应的输出数据，由输入和当前地状态决定输出数据和后续状态。

LFM用于表示在状态输入条件和输出条件之间的对应关系。LFM只适合于描述静态说明，输出数据仅由输入数据决定。

后续要用到基本路径覆盖法。

8、场景设计法

（1）多数软件系统都是用事件触发来控制业务流程，事件触发时的情景便形成了场景，场景的不同触发顺序构成了用例。

（2）

特点：测试人员要充分发挥对用户实际业务场景的想象，关心用户做什么，而不是关心产品做什么。

优点：实用性强，有效，设计出来的用例有价值。

缺点：可能使用的场景不一定能对事件系列进行全面的分析，设计出来的用例不完整。

9、错误推测法

（1）测试者根据经验、知识和直觉来发现软件的错误，来推测程序中可能存在的各种错误，从而有针对性地进行测试。

（2）

特点：没有依据，只能靠测试着自身实力和经验。

优点：快速切入体会到程序易用与否。

缺点：难以准确知道测试覆盖率。

（3）地位：作为辅助方法（不像边界值分析法（BVA）是必用的黑盒测试方法）

黑盒测试方法参考文链接：https://blog.csdn.net/weixin_44997802/article/details/109352327

白盒测试方法

白盒测试主要检查程序的内部结构、逻辑、循环和路径。

1、逻辑覆盖法

以程序或系统的内部逻辑结构为基础，分为语句覆盖、判定覆盖、判定-条件覆盖、条件组合覆盖等。

2、基本路径测试法

在程序或业务控制流程的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。

更多介绍可看链接：https://blog.csdn.net/qq_41431406/article/details/99320982

黑盒白盒测试的优缺点

1、优点

黑盒测试：

（1）比较简单，不需要了解程序内部的代码和实现；

（2）与软件的内部实现无关；

（3）从用户角度出发，能很容易的知道用户会用倒哪些问题，遇到哪些问题，提高软件的易用性；

（4）基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；

（5）在做软件自动化测试时较为方便。

白盒测试：帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中吟唱的问题。

2、缺点

黑盒测试：

（1）不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%；

（2）自动化测试的复用性较低。

白盒测试：

（1）程序运行会有很多不同的路径，不可能测试所有的运行路径；

（2）测试基于代码，只能知道测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；

（3）系统庞大时，测试开销会非常大。

9、软件文档类型

（1）软件类：可执行程序、源程序、配置脚本、测试脚本等。

（2）开发类文档：《需求规格说明书》《概要设计说明书》《详细设计说明书》《数据库设计说明书》《测试计划》《测试报告》《测试用例》《缺陷报告》《程序维护手册》《程序员开发手册》《用户操作手册》《项目总结报告》等。

（3）管理类文档：《项目计划书》《质量控制计划》《配置管理计划》《用户培训计划》《质量总结报告》《评审报告》《会议记录》《开发进度报告》。

10、业务测试，系统测试

业务测试

1、概念：业务测试是测试人员把系统各个模块串接起来运行、模拟真实用户实际的工作流程，满足用户需求定义的功能来进行测试流程。

2、测试时间：已完成功能测试并保证功能正常使用。

3、业务流程分为：基础数据和业务数据，

执行时：（1）在执行业务测试之前，清空业务数据，保留基础数据；

（2）按照业务用例执行测试；

（3）执行完之后，清空业务数据；

（4）产品稳定后，采用自动化测试工具开展测试：做业务回归测试。

业务测试、功能测试、黑盒测试的区别

（1）测试目的不同：

功能测试：功能测试的测试目的是对产品的各功能是否符合需求进行验证。

业务测试：业务测试的测试目的是对产品的操作是否符合业务的逻辑流程。

黑盒测试：黑盒测试的测试目的是检测每个功能是否都能正常使用。

（2）测试方法不同：

功能测试：功能测试的测试方式为不考虑程序内部的逻辑结构和内部特性，只检查产品的功能是否符合它的功能说明。达到了用户的需求，则证明该软件通过测试，未达到需求，则需尽快解决。

业务测试：业务测试的测试方式为测试人员以业务逻辑流程线使用产品，运行正常，则证明该软件通过测试，运行出现报错，则需尽快解决。

黑盒测试：黑盒测试的测试方式为从数据输出时若与预计数据一致，则证明该软件通过测试，若数据与预计数据有出入，即便出入较小亦证明软件程序内部出现问题，需尽快解决。

（3）测试顺序不同：

功能测试：功能测试的测试顺序在业务测试之前，黑盒测试之后。

业务测试：业务测试的测试顺序在黑盒测试和功能测试之后。

黑盒测试：黑盒测试的测试顺序在功能测试和业务测试之前。

系统测试

1、定义：系统测试是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行(使用)环境下，对被测对象进行一系列的测试活动。系统可能包含硬件，也可能是纯软件。

2、目的：

（1）通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。

（2）系统测试的测试用例应根据需求分析说明书来设计，并在实际使用环境下运行。

11、集成测试与系统测试

1、区别

（1）集成测试是在单元测试之后和系统测试之前。它是把不同的系统（模块）连接起来，通过测试发现它们之间的接口是否有问题。比如：

1.数据可能在通过接口的时候丢失；

2.一个系统（模块）可能对另一个系统（模块）产生无法预料的副作用。

（2）系统测试包括恢复测试、安全测试、压力测试和性能测试等。虽然每一个测试都有不同的目的，但所有都是为了整个系统集成到一起以完成分配的功能。

2、应用场景

（1）集成测试：完成单元测试后，各模块联调测试；集成在各模块的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能、以及结果的正确性验证等等。

可以是整个产品的集成测试，也可以是大模块或者多个系统的集成测试；集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。

（2）针对整个产品的全面测试，既包含各模块的验证性测试（验证前两个阶段测试的正确性）和功能性（产品提交给用户的功能）测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。

系统测试测试软件《需求规格说明书》中提到的功能是否有遗漏，是否正确地实现。做系统测试要严格按照《需求规格说明书》，以它为标准。

12、软件测试的原则（七大基本原则）

1、测试证明软件存在缺陷。

2、穷尽测试是不可能的。

3、今早介入测试。

4、缺陷具有集群性。

5、杀虫剂悖论。

6、测试是上下文相关的。

7、无错误谬论。

具体详情可查看：https://blog.csdn.net/zhengshuguo1990/article/details/124099877

8、测试要以用户的需求为标准，考虑实际操作情况。

9、测试需要把握好时间和质量，当时间和质量冲突时，质量要第一。

10、软件项目一启动，测试也就开始。

11、第三方进行测试会更客观，更有效。

12、软件测试计划是做好测试工作的前提。

13、测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试效率，更多地发现错误，提高程序的可靠性。

14、对发现错误较多的程序段，应进行更深入的测试（二八原则）。

15、重视文档，编写对应的测试过程文档和妥善保存。

16、回归测试的关联性一定要注意，因为修改一个错误往往会引起更多的错误出现。

17、测试应从“小规模”开始，逐步转向“大规模”。

18、重视测试用例，排除随意性，并根据测试进度，不断补充测试用例。

19、对测试的错误结果（bug）一定要有一个确认的过程。

13、软件测试的职责

面对不同的公司，不同的岗位要求，软件测试所对应的职责也会不同，以下为测试组长职责：

1、参与项目开发各个阶段的评审工作（需求评审，设计评审、用例评审等）；

2、负责产品、研发团队沟通，明确业务流程，确定测试范围；

3、指定详细测试计划、方案和用例，建立并优化测试过程，知道和带领测试团队完成测试过程和确保上线产品质量；

4、把控测试进度，控制项目测试风险；

5、负责缺陷跟踪和管理，推动缺陷及时有效沟通和解决；

6、负责测试工具、自动化系统和测试流程的不断改进和应用，提高测试效率。

14、软件测试的策略

1、测试策略是为了以最低的成本最大程度地揭示（或降低）产品的质量风险，或尽早地完成测试所选择（或制定的）的最合理／合适的方式、方法、过程等。

2、测试策略内容主要包括：测试目标、测试范围、测试优先级（重点）、测试过程（阶段）、测试技术、开始标准、完成标准，以及需要考虑的特殊事项。

3、为什么要制定测试策略？一个优秀的测试执行应先制定一个好的测试策略，俗话说“不打无准备之仗”。提前规划好测试策略，可以避免盲目测试，规避测试风险，可以提前捕捉到测试过程中会产生的一些问题，提前解决，大大提高测试效率、产品质量。

当然，测试策略是在测试之前做出的一套方案，无法完全预测到测试中会发生的事，所以测试策略也要做到随机应变，因时制宜。

4、测试策略主要关注“测什么？” 和 “怎么测？”

可以从四个方面来考虑制定测试策略：（1）测试阶段，（2）产品成熟度，（3）测试范围，（4）测试风险。

参考文：http://www.51testing.com/html/48/n-4475248.html?nomobile=1

15、软件测试通过的标准

1、版本发布的标准：

（1）上线功能需求全部实现并测试是通过；

（2）主流程畅通，系统没有1级2级bug；

（3）版本带bug发布，遗留的3级4级bug数不能超过该系统bug总数的5%，并且有争议的bug需要项目管理者确定是否遗留；

（4）

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/一键难忘520/article/detail/916569