构建之法阅读笔记03
第13章 软件测试
章节概述
本章系统介绍了软件测试的理论、方法和实践。从基本的名词解释开始，详细讲解了各种测试方法（单元测试、构建验证测试、验收测试、探索式测试、回归测试、场景测试等），并深入讨论了测试中的设计问题和实际工具应用。本章强调测试不仅仅是找Bug，更是软件工程质量保障的核心环节。
Bug的三个层次：
症状：从用户角度看，软件出了什么问题
程序错误：从代码角度看，代码的什么错误导致了软件的问题
根本原因：导致代码错误的根本原因
按测试设计方法分类：
黑箱测试：把软件系统当作一个"黑箱"，无法了解或使用系统的内部结构及知识
白箱测试：设计者可以"看到"软件系统的内部结构，并使用软件的内部结构和知识来选择测试数据及具体的测试方法
灰箱测试：介于黑白之间，实际工作中往往不会画地为牢
按测试目的分类：
功能测试：单元测试、功能测试、集成测试、场景测试、系统测试、Alpha/Beta测试
非功能测试：压力测试、效能测试、可访问性测试、本地化/全球化测试、兼容性测试、配置测试、易用性测试、安全性测试
按测试时机和作用分类：
冒烟测试：测试不通过，则不能进行下一步工作
构建验证测试：验证构建是否通过基本测试
验收测试：全面考核某方面的功能/特性
回归测试：对新版本重新运行以往的测试用例
探索式测试：随机进行的、探索性的测试
伙伴测试：开发人员作为测试人员测试特定模块
单元测试
在最基本的功能/参数上验证程序的正确性
由开发人员编写，是质量控制的基础
构建验证测试
在构建完成后自动运行，验证系统的基本功能
通不过BVT的构建称为"失败的构建"
导致问题的Bug有最高优先级，开发人员要首先处理
验收测试
按照测试计划测试各自负责的模块
可以使用场景来规划测试工作
所有场景都能通过，则构建质量是"可用的"
探索式测试
为了某一个特定目的而进行的测试，且就这一次
头脑灵活的测试人员往往能发现更多重要问题
探索式测试太多是团队管理不佳的一个标志
回归测试
对一个新的版本，重新运行以往的测试用例
确保新版本相比已知版本没有"退化"
不仅包括单元测试，也包括其他类型的测试
场景/集成/系统测试
以场景为驱动的集成测试
验证几个模块能否完成一个用户场景
用户不会独立使用各个模块，而是把软件作为一个整体来使用
伙伴测试
在签入新代码之前，开发人员找测试人员做伙伴测试
测试人员在本地做必要的回归/功能/集成/探索测试
发现问题直接与开发人员沟通，提高效率
效能测试
验证软件在设计负载内能否提供令用户满意的服务质量
要定义什么是正常的设计负载
要定义什么样的质量是令用户满意的
效能测试对硬件要有固定的要求，每次测试需要在相同环境中进行
第14章 质量保障
本章深入讨论了软件质量保障的相关概念、方法和实践。从软件质量的定义开始，详细讲解了质量保障工作的内容，测试角色的分工和价值，以及如何在团队中建立有效的质量保障体系。本章特别强调了独立测试角色的重要性，并通过实际案例分析了质量保障中的常见问题。
软件质量的多个维度：
功能质量：软件是否实现了预期的功能，是否满足用户需求
可靠性：软件在规定条件下和规定时间内完成规定功能的能力
易用性：用户学习、操作和理解软件的难易程度
效能：软件的性能表现，如响应时间、吞吐量等
可维护性：修复缺陷和进行修改的难易程度
可移植性：软件从一个环境迁移到另一个环境的难易程度
安全性：软件抵御攻击和保护数据的能力
质量成本：
预防成本：建立质量体系、培训、流程改进等
评审成本：需求复审、设计复审、代码复审等
内部故障成本：修复开发过程中发现的Bug
外部故障成本：修复用户报告的问题、客户支持等
测试vs质量保障：
测试：运用一定的流程和工具，验证软件能实现预先设计的功能和特性，工作的流程和结果通常是可量化的
质量保障：软件团队为了让软件达到事先定义的质量标准而进行的所有活动，包括测试工作
测试角色的独立性：
为什么需要独立的测试角色？
- 分工是社会和行业进化的结果
- 开发和测试其实是软件工程的两个分支
- 独立的测试角色从用户的角度出发验证产品质量
- 独立专业的测试等同于代表客户对产品进行认证
- 任何产业成熟到一定阶段，独立的质量保障角色都是不可避免的
分工带来的问题及应对：
责任转移：既然有专人负责，那我就不用负责了 → 保证质量仍然是所有成员的职责
盲目信任：相信专业人士扮演的角色一定没问题 → 即使有专业人士，还得有专人独立检查验证
局部优化：为了自己的角色绩效而忽略全局 → 从整体目标出发，平衡各角色利益
画地为牢：分工导致链条过长，信息丢失 → 打破边界，让每个人都了解整体
责任模糊：没有明确可量化的责任要求 → 设定明确的、可核查的责任标准
第15章 稳定和发布阶段
本章详细描述了软件项目从代码完成到发布的整个过程。从团队血型理论开始，系统介绍了Alpha、Beta、ZBB、RC、RTM等发布阶段，以及会诊小组（Triage Team）的运作机制。本章还提供了一系列实用的"招数"来帮助团队顺利度过稳定和发布阶段，包括设计变更管理、零Bug构建、回归测试、功能砍掉、逐步集成等关键技术。
从代码完成到发布
软件团队的"血型"理论：
A型：他们知道优秀的软件公司会发布有已知缺陷的软件
B型：他们不相信这一点
O型：他们不知道这一点，因此嘴巴惊讶成O型
AB型：他们对于自己开发的软件是A型，对于别人开发的软件是B型
会诊小组
组成与职责：
软件团队的各个角色代表（PM/Dev/Test/UX等）组成
处理每一个影响产品发布的问题
像医院的急诊室，根据病人情况安排不同处理方法
Bug处理的五种决定：
修复（Fix）：小组同意修复这一问题
设计本来如此（As Designed）：用户或测试人员可能对功能有误解
不修复（Won't Fix）：这是一个问题，但是这个软件版本不打算修复
推迟（Postpone）：留到下一个版本解决
重复（Duplicate）：已经有同样的Bug记录
复杂项目会诊的三步流程：
第一步：开发者提交参加会诊的Bug和修改方案，以及伙伴测试结果
第二步：会议决定是否同意修改方案
第三步：执行修改
会诊的四个决策选项：
Must：必须修复，缺陷很严重，修复方案可行，相关测试都通过
More Info：需要更多的信息
No：不能接受，可能推到下一个里程碑
Like：可能，不一定必须修复，但解决方案相对比较安全
第16章 IT行业的创新
本章深入探讨了IT行业的创新问题。从剖析创新的八个迷思开始，揭示了人们对创新的常见误解，然后讨论了创新的时机选择（黄金点游戏的启示），以及创新的各种策略和方法。本章特别分析了成功企业在创新中面临的困境（创新者的窘境），以及如何在大公司中推动创新的实用招数。
创新的八个迷思
迷思之一：灵光一闪出英雄，开创了新领域
事实：大多数成功的创新都建立在前人工作的基础上
很多"英雄"其实是赶上了技术成熟的关键节点
创新是长期积累和迭代的结果，不是突然的"灵光一闪"
迷思之二：创新是少数人的事情
事实：每个人都可以创新，创新能力可以学习和培养
创新不仅是技术上的突破，也包括商业模式、用户体验、流程改进等
团队的创新文化比个别天才更重要
迷思之三：创新都是颠覆性的
事实：大部分创新是渐进式的改良
颠覆性创新往往经历多次失败后才能成功
维持性创新对企业更重要
迷思之四：创新就是要做最新的技术
事实：成功的创新往往是合适的技术，而不是最新的技术
技术的先进性不等于商业成功
用户价值是创新的最终评判标准
迷思之五：创新要靠年轻人
事实：各个年龄段都有创新成功者
经验和行业洞察力对创新至关重要
不同年龄的人有不同的创新优势
迷思之六：创新就是从0到1
事实：很多成功的创新是从1到N
把已有的技术或模式应用到新领域也是重要创新
执行和细节往往比最初的想法更重要
迷思之七：成功的团队更能创新
事实：成功企业反而面临"创新者的窘境"
成功带来的流程、价值观、文化反而可能阻碍创新
大公司的内部创新往往需要特殊的组织方式
迷思之八：创新者就是冒险家
事实：创新人士的关键特点不是喜欢冒险，而是从错误中恢复并继续努力
屡败屡战"比"不怕失败"更重要
第17章 人、绩效和职业道德
本章聚焦于软件工程中"人"的因素。从领导力开始，讨论了如何知人善任、如何带领团队成长，然后分析了团队中常见的角色和问题（猪、鸡和鹦鹉的故事），接着深入探讨了绩效管理问题，最后讨论了软件工程师的职业道德。本章是全书最具人文关怀的一章，强调了人的因素在软件工程中的核心地位。
领导力
什么是领导力：
领导力不是职位，而是影响力
领导力是带领团队实现目标的能力
领导力是激励和培养他人的能力
领导力的核心要素： - 愿景：有清晰的方向和目标，能激励团队
- 沟通：善于倾听和表达，确保信息畅通
- 决策：在复杂情况下能做出正确判断
- 执行：推动事情落地，取得结果
- 培养他人：帮助团队成员成长
没有最好的风格，只有最合适的风格，需要根据情境和团队成熟度调整。
领导力——知人善任
如何识人：
看业绩（结果导向）
看能力（技能和潜力）
看态度（工作积极性和责任心）
看团队合作（能否与他人协作）
看学习能力（能否持续成长）
如何用人：
用人所长，避人所短
给合适的人安排合适的任务
提供成长机会和挑战
及时反馈和指导
信任和授权
《构建之法》从个人技术、团队协作、项目管理、软件测试、质量保障、发布流程、创新方法论到人才管理，构建了一个完整的软件工程知识体系。
一、过去怎么做
开发完成后随手测一下功能，能跑通就算测试通过
没有写单元测试的习惯，觉得是浪费时间
发现Bug就直接改，没有记录和跟踪
效能测试和压力测试完全没有概念
二、为什么不好
前期不重视测试，后期Bug爆炸式出现
一个Bug引发另一个Bug，陷入修Bug的死循环
用户体验差，口碑下降，再多的新功能也弥补不了
修复Bug的成本是开发时的5-10倍，整体效率反而更低
三、解决办法
单元测试：核心代码必须有单元测试，覆盖率不是目标，但没有绝对不行
伙伴测试：提交前找测试同学先过一遍，把问题消灭在摇篮里
浙公网安备 33010602011771号