学习笔记之 软件测试基础理论知识

一、什么是软件测试

IEEE定义：使用人工或自动的手段来运行或测量软件系统的过程，以检验软件系统是否满足规定的要求，并找出与预期结果之间的差异。

测试是为发现错误而执行程序的过程。
作为测试工程师，你的目标是要保证系统在各种应用场景下的功能是符合设计要求的，要考虑的测试用例就应该更多、更全面。

二、测试对象

从前期的软件需求，到软件概要设计、软件详细设计、软件源代码、可运行软件程序、软件运行环境都是软件测试的测试对象。

三、测试原则

1. 测试显示故障缺陷的存在，但不能证明系统不存在的缺陷。
2. 发现bug仅仅是测试工作的开始。提交bug后还需要继续跟踪，回归测试。
3. 穷尽测试是不可能的，应设定及时终止的条件。
4. 测试应该尽早进行。不间断测试，只要具备测试条件（如某模块功能编写完了），就可以开始测试。越早发现缺陷，软件开发成本就越低。
5. 缺陷具备群集特性。模块中发现的缺陷越多，那么未发现的缺陷也越多。
6. 测试的杀虫剂悖论。测试用例和测试方法应该不定期评审和修改。
7. 测试的二八原则。测试的时间和资源是有限的。将80%的测试时间用在系统20%的重要模块上。
8. 测试活动依赖于测试背景。不同的测试背景有不同的测试活动。比如电信软件对性能、大并发量的访问要求更高；金融软件、银行相关的软件对安全性的要求更高。
9. 不会代码的测试，不是一个好测试。要把自己的影响力扩展到别人，帮助整个团队。

四、测试流程（功能）

1. 了解产品功能需求

开会议，需求分析和评审

2. 制定测试计划

一般由测试负责人/测试组长编写
计划内容包括：测试范围？人员、任务分配、时间规划、进度安排等。即每轮测试所需时间？需要多少人测？做什么类型的测试？测试方法？测试机型？测试工具？测试环境等

测试的目的和范围；（功能需求范围）
测试的人员和任务分配、进度安排；（分配测试模块任务和项目进度任务）
测试策略；（根据需求制定，包括测试方法、工具、环境）
测试风险分析和预防；

3. 编写测试用例

根据产品需求的逻辑，考虑用户或系统的所有可能发生的操作以及系统中可能会出现故障的各个点，还有边界情况，如输入边界值、字段长度限制、断网、断电、事件中断、进程中断等。
如用户发送文件大小的限制；无网发送等。
用例设计不仅需要考虑明确的显式功能性需求，还可考虑安全性、性能以及兼容性（不同浏览器下，页面显示以及功能的正确性）等一系列非功能性的测试

步骤：需求文档及原型分析 --> 功能模块划分 --> 测试用例编写 --> 测试用例整理与维护

3.1 需求文档分析

文档阅读：

仔细阅读原型文件，理解需求设计的意图和思路，避免粗略理解带来的用例遗漏。

沟通探讨功能细节：

尽早确认细节，关注需求变更。

逻辑梳理：

梳理出框架后，逐步细分。
如：简单逻辑：建筑点击后可领取奖励。细化逻辑：建筑是否可点击 ，点击后有无特效，领取后能再次领取等。

功能拓展思考：

设计缺陷思考；测试难点思考；关联度思考；特殊情况思考。
如：建筑时候是否可升级拆解？道具领取有没有限制？领取的数量？道具的种类？领取后怎么提示？领取奖励的刷新时间？领取后道具的存储问题？重复的道具如何放置？叠加放置还是排列放置？领取奖励过程中断电断网或服务器维护中，会导致什么问题？

兼容拓展思考：

版本兼容；功能兼容；操作系统版本兼容；分辨率兼容
如：同一时刻不同版本运行时交互的版本兼容？老功能中添加不同类型的新功能时的兼容问题？不同操作系统中的