第五章 软件测试基础
一、软件测试的定义：
- 使用人工或自动的检测方法，检测被测对象（软件文档、软件数据、运行程序）是否满足用户需求，若不满足，则为错误。找出预期结果与实际结果之间的差异。
二、软件测试的目的：
1、需求阶段：对需求文档进行评审，检查需求文档是否有错误、描述不清楚的情况；
2、软件设计阶段：检查软件运行的环境是否合理，业务功能模块之间组织是否合理；
3、编码阶段：测试对应的代码和程序；
4、验收阶段：检查软件是否符合用户要求；
5、运维阶段：检测软件更新和补丁修复，是否会因为之前发生的问题引入新的问题。
- 无论哪个阶段，目的都是通过测试活动，检验被测对象是否与预期一致。测试工程师是希望证明被测对象存在缺陷，而开发人员则希望被测对象无错误。
三、软件缺陷定义：
- 任何与用户需求不一致的软件表现。包括错误、bug、缺陷、失效（如无法开机、突然断线）。
四、缺陷产生的主要原因：
1、需求表述、理解、编写引起的错误；
2、开发过程缺乏有效的沟通和监督，甚至没有沟通和监督；
3、程序员编程中产生的错误；
4、软件复杂度越来越高。
五、常见缺陷种类：
1、遗漏：软件没有实现用户需求：记录需求时遗漏；开发故意遗漏，为了提前交付或做不完，甩锅给测试，利用改bug的时间补需求，如若多次出现此情况应向领导反映；开发非故意遗漏。
2、错误：软件的实现与用户需求（期望）不一致
3、冗余：软件的实现超出用户需求，如果不影响正常功能使用或者是比较好的就保留。
4、不满意：用户觉得不符合使用习惯、审美等问题。
六、软件缺陷报告遵循原则：
1、Correct（准确）：每个组成部分描述需准确，不会引起误解；
2、Clear（清晰）：每个组成部分描述需清晰，易于理解；
3、Concise（简洁）：只包含必要的信息；
4、Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息；
5、Consistent（一致）：按照一致的格式编写全部缺陷报告。
七、缺陷管理流程：
八、软件测试原则：
1、测试证明软件存在缺陷；
2、不可能执行穷尽测试：一个软件有很多维度，测试不可能覆盖所有。因此通过风险分析、被测对象测试点优先级分析、软件质量模型及不同测试方法的运用来确定测试点，从而替代穷尽测试，提高测试覆盖率。
3、测试应尽早启动、尽早介入；
4、缺陷存在群集现象：群集现象是指在测试中发现缺陷越多的地方，存在的未被发现的缺陷也就越多。
5、杀虫剂悖论：测试用例经过多次迭代测试后，将不再发现缺陷。因此测试用例应定期评审、及时调整，还可进行交叉测试。
6、不同的测试活动依赖于不同的测试背景；
7、不存在缺陷的谬论。
九、软件测试级别;
1、需求测试：重点是检查需求规格说明书中是否存在描述不准确、定义模糊、需求用例不正确、语言存在二义性等问题。主要考虑方面：
1）完整性；2）正确性；3）一致性；4）可行性；5）无二义性；6）健壮性（容错性）；7）必要性；8）可测试性；9）可修改性。
2、组件/单元测试：针对软件基本组成单元来进行正确性检验。
3、集成测试：对组件/单元之间及组件/单元与第三方接口之间进行测试，使用自底向上或自顶向下渐增式策略。目的是检测软件模块对《概要设计说明书》的符合程度，关注模块间接口和接口数据传递关系，以及模块组合后的整体功能。
4、系统测试：将通过集成测试的软件，部署到某种较为复杂的计算机用户环境进行测试。目的是测试整个系统对于用户需求的符合程度。主要采用黑盒测试，考察被测软件的功能和性能。
5、验收测试：根据合同、《需求规格说明书》或《验收测试计划》对成品进行验收测试。此阶段目的不是在于发现缺陷，而是使用户建立对即将交付应用的软件系统的信心。有Alpha测试、Beta测试、UAT测试等形式。
1）Alpha测试：用户在开发环境下测试，用户模拟实际操作环境测试。需开发者陪同，记录错误情况和使用问题。主要是评价软件的功能、局域性、可用性、可靠性、性能和技术支持等是否达标。
2）Beta测试：由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在场，测试者发现问题后，统一收集提交至开发人员修复。
3）UAT测试：User Acceptance Test，用户接受度测试。一般用于商业用户验证系统的可用性，会安排一些实际使用软件或项目人员来验收。
十、软件测试类型：
1、功能测试：验证软件在指定条件下使用时，提供满足明确和隐含功能需求的能力情况。主要检测情况：
1）是否有不正确、遗漏或多余的功能；
2）是否满足用户需求和系统设计的隐藏需求；
3）是否对输入做出正确的响应，输出结果能否正确展示。
- 注意点：一般来说，功能测试是其他测试类型开展的基础，功能实现不正常，其他测试开展的意义不大。
2、性能测试：通过模拟系统运行业务压力和使用场景组合，验证系统性能是否满足预先定义的性能要求。
特点：
1）主要目的是验证系统是否具有宣称具有的能力；
2）需了解测试系统典型场景，并具有确定的性能目标；
3）要求在真实的运行环境下执行。常用性能监控指标：
1）并发数：单位时间内某个业务场景或综合业务场景有多个用户同时发送业务请求；
2）响应时间：用户发起请求到接收到正确响应所花费的时间；
3）吞吐量：网络消耗的数据量，包括响应和请求数据；
4）TPS：每秒完成的用户事务数（每秒成功登陆的数量）；
5）硬件资源耗用：CPU使用率、内存使用率、硬盘等；注意点：性能测试一般只需关注软件系统的典型或者重要的业务场景。性能测试中，包含了性能、负载、压力、容量、兼容性、可恢复性等测试类型，这些测试类型都会在执行性能测试中提到，按照用户需求来测试。
3、负载测试：在超过被测对象标准性能负荷指标下，验证系统的负载承受能力，并要求在超负荷时，被测对象依然能够正常实现业务功能，关注的是不同负载。
- 特点：
1）主要目的是找到系统处理能力极限和性能临界点，便于设定阈值；
2）在超过被测对象性能负荷情况下实施；
3）一般用来了解系统性能容量，或者配合性能调优来使用。
4、压力测试：在性能负荷指标峰值，系统处理业务的能力情况，以及系统是否会出现错误，关注的是不同周期。
- 特点：
1）主要目的是检查被测对象在峰值情况下应用的表现；
2）一般使用负载测试的思想实施压力测试，持续关注被测对象持续服务的能力；
3）一般用于系统的稳定性测试。
5、容量测试：检测软件在单位时间内处理数据的能力，用户在并发情况下请求数据，看数据能否正确使用。可与负载、压力测试一同进行，关注的是数据。
6、安全测试：验证被测对象的安全保护机制能否在实际应用中保护系统不受非法入侵，用来保证系统本身数据的完整性和保密性。
7、兼容性测试：验证被测对象与硬件、其他其他软件之间的兼容情况。
8、可靠性测试（稳定性测试）：软件系统在一定压力下，稳定运行一定时长，运行期间不会出现宕机等故障。
衡量指标：平均故障间隔时间（MTBF）、平均故障修复时间（MTTR），MTBF越长越好，MTTE越短越好。
9、可用性测试：检测软件是否容易被用户群学习、方便使用。
10、移植测试：业务功能基本不变的情况下，根据用户需求安装到新的硬件或平台上。从适应性、易安装性、共享性、易替换性等方面考虑。
11、维护测试：软件系统在部署运行交付使用后，在实际使用过程中，因改正错误或需求变更而引发的确认验证测试活动。
- 根据引起软件维护的原因，分为以下类型：
1）改正性维护测试；
2）移植性维护测试；
3）完善性维护测试；
4）预防性维护测试。
12、确认测试：测试工程师发现缺陷，开发人员修复生成新的版本后，测试工程师需要确认是否已经修复了该缺陷。
13、回归测试：对已测对象在修复缺陷后进行的重复测试，目的是验证修复缺陷后是否引发新的缺陷或问题。
- 回归测试的策略：
1）完全回归：需执行被测对象的所有用例，不仅仅执行缺陷对应的用例。
2）选择性回归：
A、基于风险回归，根据项目或产品的风险大小，确定回归用例。除了确认缺陷是否成功修复外，还要执行风险较高的用例；
B、基于操作剖面回归，根据项目或产品功能、业务的使用频率确定回归用例。除了确认缺陷是否成功修复外，还要执行使用频率较高的业务或功能。
C、缺陷覆盖回归，仅回归已修复缺陷对应的用例，此方法适用于经过风险分析的被测对象。
十一、软件测试方法：
1、黑盒测试：手工测试的一种，只关注输入和输出数据、展示数据、按钮等实际结果与期望结果（需求文档）是否一致。只能用在系统测试和验收测试阶段。
2、白盒测试：关注实现逻辑、覆盖情况。
3、灰盒测试：更多关注内部功能模块的接口实现。性能测试与自动化测试就采用灰盒测试。
4、静态测试：包含阅读程序代码、文档资料等，与需求规格说明书进行比较，找出测试对象设计、描述、编码等方面的错误。
5、动态测试：运行被测对象的程序代码，执行测试用例，检查软件系统运行结果与预期结果的差异。
6、手工测试：模拟终端用户的业务流程应用软件系统。
7、自动化测试。
