《全程软件测试》第1章
1979年《软件测试的艺术》作者 Glenford J.Myers 对软件测试的定义：
测试是为了发现错误而执行一个程序或者系统的过程。
测试是为了发现缺陷，而不是证明程序无错误。
1983年Bill Hetzel将软件测试定义为：
软件测试就是一系列活动，这些活动是为了评估一个程序或软件系统的特性或能力，并确定其是否达到了预期结果。
测试是不能穷尽的 = 不能证明软件是正确的，只能说明发现的缺陷的确是缺陷。
没有发现问题，也不能说明问题不存在，而是至今未发现软件的潜在问题。
💡 树立正确的软件测试基本认知——正反思维
正向思维：证明程序没有错误而进行测试，正向验证软件系统的所有功能点，测试更具有广度，保证良好的测试覆盖面。
逆向思维：证明程序存在错误而进行测试，效率高，缺点是容易陷入局部深度测试而缺乏广度。
正确做法：正向思维 + 逆向思维 = 质量 + 效率
动态平衡决策： 当需要有所取舍时，根据情况决策，需要效率时更多采取逆向思维，需要测试广度保证完整的测试质量就多采用正向思维。再根据不同应用领域对系统质量要求的不同，做进一步把控。
从狭义测试到广义测试
狭义的软件测试： 动态测试——运行程序而进行的测试
广义的软件测试： 动态测试 + 静态测试（不运行软件系统时对软件或阶段性成果进行评审）
基于质量的认知
产品质量： 在特定的使用条件下，产品满足明示和隐含的需求所明确具备能力的全部固有特性。
使用质量： 基于现实生活考虑，用户的使用体验。
基于风险的认知
软件测试是对软件系统中各种潜在的各种风险进行评估的活动。强调测试的持续性。
在敏捷开发中，软件测试被解释为对软件产品质量的持续评估。
评估测试的风险：根据风险大小确定测试的优先级。
- 每个功能出现问题的概率有多大？
- 用户最常用的20%功能？
- 如果某个功能有问题，影响范围有多大？
基于社会性的认知
软件具有很强的社会性，测试中要理解用户的行为、人们的活动背景和目的，不断观察和学习，从而发现和质量相关的信息，从客户利益、业务特性出发来守护产品价值。
人们常常进行 A/B 测试，给出不同的解决方案，向不同的用户群发布产品，检测哪个解决方案更受用户喜欢。
基于经济的认知
如何以最小的代价获得更高的利益，要求软件测试尽早开展工作，缺陷越早发现，返工的工作量越小，损失越小。
基于标准的认知
软件测试被视为“验证”和“有效性确认”这两类活动构成的整体，缺一不可。
验证：检验软件是否已正确的实现了产品规格说明书所定义的系统功能和特性。
有效性确认：确认所开发的软件是否满足用户实际需求的活动。
基于Test Oracle的认知
测试 = 检测已知的 + 试验未知的
Test Oracle：一种决定一项测试是否通过的（判断）机制，要求被测试系统的实际输出与所期望的输出进行比较。
测试范围：相对稳定、明确的测试项和不确定的、容易变更的测试内容。
- 探索性测试：不断的
设计 + 执行 + 分析 + 学习，再反复持续改进的测试过程。 - 借助测试工具进行未知试验：随机测试、模糊测试、变异测试等。（未来有可能由人工智能完成）
总结：测试 = 基于确定性模型 / 明确测试预言的自动化测试 + 基于AI搜索的 / 工具随机 / 模糊模型的 / 手工的探索式测试
基于批判性思维的认知
软件测试就是借助观察、经验、反思、推理或沟通等收集信息，并对软件产品相关的质量信息进行分析，以此评估软件质量，并作出结论。
批判性思维促进我们重新审视问题或主题、意图和陈述之间实际的推论关系，勇于质疑证据，去分析和评估陈述、论证的过程。
软件测试就是测试人员不断质疑被测系统的过程。
基于传统开发模式的认知
基于敏捷开发模式的认知
敏捷测试特点：
- 建立良好的测试框架以适应需求变化，更关注测试系统的本身而非测试文档
- 结对测试
- 传统测试的阶段性特征相对突出一些，敏捷测试更强调持续性
- 基于自动化测试
敏捷测试 vs 传统测试：
- 传统测试更强调测试的独立性，开发与测试角色分的比较清楚；敏捷测试强调整个团队对测试负责
- 传统测试更具有阶段性，敏捷测试更强调持续测试和持续的质量反馈
- 传统测试更强调测试的计划性，敏捷测试侧重不断调整计划以适应需求的变化
- 传统测试强调测试由“验证”和“确认”构成，敏捷测试没有这种区分，始终以用户需求为中心
- 传统测试强调任何缺陷要记录，以便进行分析，区分测试与开发的各自不同的责任；敏捷测试强调面对面沟通协作
- 传统测试更关注缺陷，敏捷测试更关注产品本身，关注可以交付的客户价值
- 传统测试鼓励自动化测试，但不要求，敏捷测试的基础就是自动化测试