第十三章 软件测试
13.1 名词解释
Bug ：软件的缺陷
Test Case ：测试用例。测试用例描述了一个完整的测试过程，包括测试环境、输入、期望的结果等
Test Suite ：测试用例集。即一组相关的测试用例
13.2 Bug解释与实例
①Bug可以分解为：症状（Symptom）、程序错误（Fault）、根本原因（Root Cause）
症状：即从用户的角度看，软件出了什么问题
程序错误：即从代码的角度看，代码的什么错误导致了软件的问题
根本原因：错误根源，即导致代码错误的根本原因
②Bug例子
症状：用户报告，一个windows应用程序有时会有在启动时报错，继而不能运行
程序错误：有时候一个子窗口的handle有空，导致程序访问了非法内存地址，此为代码错误
根本原因：代码并没有确保创建子窗口，因此子窗口的handle变量有时会在访问时处于未赋值状态（为空），导致出现代码错误
13.3测试方法
①黑箱：指的是设计测试的过程中，把软件系统当做一个“黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是行为测试设计，即从软件的行为，而不是从内部结构出发来设计测试
②白箱子：指的是在设计测试的过程中，设计者可以“看到”软件系统的内部结构，并使用软件的内部结构及知识来选择测试数据及具体的测试方法。
第十四章 质量保障
14.1 软件质量
软件 = 程序 + 软件工程
软件（质量） = 程序（质量） + 软件工程（质量）
14.2 软件质量的保障与软件的测试
软件测试：运用一定的流程和工具，验证软件能实现预先设计的功能和特性，工作的流程和结果通常是可量化的
软件质量的保障工作：软件团队为了让软件达到事先定义的质量标准而进行的所有活动，包括测试工作
第十五章 稳定和发布阶段
15.1 从代码完成到发布
第一步：开发者提交参加会诊的Bug和修改方案，以及伙伴测试结果。开发者必须向与会者报告的是：
- Bug是什么
- 危害是什么，如果不修复，有何后果
- 用户会有什么变通办法
- 是否经过代码复审，是否经过伙伴测试
第二步：会议决定是否同意修改方案
决定哪些缺陷必须现在就进行修复，哪些可以推迟到下一个里程碑。会诊应该对每一个修复选择下列处理方式。
- Must——必须修复，缺陷很严重，修复方案可行，相关的测试都通过
- More Info——需要更多的信息
- No——不能接受，可能是推到下一个里程碑，可能是提出的解决方案不符合要求
- Like——可能，不一定必须修复，但是解决方案相对比较安全。在更复杂的项目中，可以考虑引入这一个中间的状态“Like”（在相对简单的系统中，这个选项可以不用）。如果在今天的会诊中有“Must”，那么处于待命状态的“Like”修复就可以一起集成到代码库中。如果没有“Must”级别的修复，那么“Like”级别的修复就只能处于“待命”状态，直到以后出现了“Must”级别的修复为止
第十六章 IT行业的创新
影响产品竞争的各种因素
- 产品行业的因素
这是影响产品发展的最重要的因素，2012年流传着一句俗话——“站在风口上，连猪都可以飞起来”，就是说明产业发展的成长期（竞争产品少，市场空间大，用户容忍度强）能给产品提供巨大的助力。相反，如果是在一个产业的衰落期进入这个产业（例如，在2008年做小灵通手机业务，在2013年进军网络团购市场，等等），那么就会面临巨大的发展阻力。 - 公司和市场因素
公司在目前目标用户中的品牌号召力如何？公司的现有市场能力如何？现有的市场能力能帮助打开新的领域么？从传统的产品开发角度来看，“市场”总是在产品之后才出现，而且和“产品开发”似乎没有直接的联系。但是从长期来看，产品的质量就是最有效的市场能力，产品经理往往就是市场经理。 - 团队执行因素
根据产品特性的不同（基础软件、企业管理软件、行业通用软件、办公软件、互联网服务软件、移动应用软件等），商业模式不同，团队的战略也会不一样。在正确的时间，有正确的产品，却执行了错误的策略，或者不能做出决定，那么产品也会失败。执行力的一个有效衡量标准是一个决定需要多少次会议才能达成。一些团队对市场展现的机会往往陷入过度的分析和评价，力争要弄清所有情况再动手，最后的结果是动不了手。这是“分析麻痹”（Analysis Paralysis）。 - 产品的价值因素
产品给用户带来什么价值，这是和“软件工程”最相关的内容。考虑新产品或产品的新功能时，团队要问：我们给用户带来了什么价值，这个产品是提供了独家的价值，还是“人有我也有”的价值？这个价值足以让本产品和目前市场上已有的产品区分开么？我们怎么能进一步放大产品差异性？让我们越来越领先，或者让用户觉得我们很领先？我们是否在非差异化功能上花费了太多时间和资源？