没有总结，就不能认识自己，就不知成功在哪里，失败在哪里；没有思考，就没有提高，没有进步。
1. 软件测试的现实和原则
1.1 测试的现实
(1).测试始终是一个具有风险的工作；
(2).测试不能提高质量；
(3).测试人员的素质和待遇；
(4).测试时间往往被压缩。
1.2 测试的原则
软件测试的基本原则是站在用户的角度，对产品进行全面测试，尽早、尽可能多地发现缺陷，并跟踪和分析产品中的问题，对不足之处提出质疑和改进意见。
(1).想用户所想。在需求评审和测试阶段，应该摒弃产品思想，而从用户角度去审视当前所做的产品，是否是用户迫切需要的，实现方式是否是用户喜闻乐见的。
(2).尽早和不断地测试
(3).质量第一
可以为时间牺牲质量，但这绝不是长远之计，质量是决定企业生存的最关键因素
(4).有据可依
事先定义好产品的质量特性指标，测试时才能有据可依，所以特地的质量要求极其指标，都应该在产品的需求文档、设计规格说明书中明确定义，所以需要做需求测试，对于需求不明确的低档需要产品明确。
(5).测试计划是过程，不是一份文档
(6).测试用例是设计出来，不是写出来的
要确保测试用例的质量，就需要思考，需要画出工作流图、数据流图，全面理解产品的特性及其实现机制。
(7).穷举测试是不可能的
(8).发现缺陷更多的地方，其风险更大
(9).重视回归测试
1.3 软件测试的多维空间
1.4 软件测试方法的应用之道
软件测试的众多方法是辩证统一，相互依赖、相互独立又相互补充，每一种测试方法都有其优势，有其适用的特定环境。
1.4.1 白盒测试和黑盒测试
白盒测试适用于独立单元，耦合性低的模块，黑盒测试偏重流程，端到端的功能逻辑测试；
白盒测试可以对程序的每一行语句、每一个条件或分支进行测试，针对性强，能清楚知道已测试的覆盖程度；
白盒测试可以检查代码程序没有问题，但不能保证软件的行为是否完全符合用户的需要。
1.4.2 静态测试和动态测试
静态测试时对程序源代码和各类阶段性文档的成果采用走查、同行评审、会审等方法发现其中的错误，不运行程序；
动态测试通过观察程序运行时所表现出来的状态、行为等发现缺陷；
静态测试比动态测试早，而且发现问题时修复成本低。
1.4.3 手工测试和自动化测试
手工测试发现的缺陷占比在70%~85%，自动化测试只能发现15%~30%；
手工测试灵活性强，举一反三能力强，可以设想出其他一些测试用例，且执行效率高；
自动化测试只能按照事先设定的测试用例执行测试，其运行效率高；
所以实际中二者是相辅相成的：
新功能、稳定性低、变化频繁的系统适用于手工测试，而回归测试、已固化、的部分则适用于自动化测试。
1.4.4 有计划测试和随机测试
计划测试是按照测试计划设计的测试用例，是测试的主旋律，但其受规格说明书等影响颇大，设计的用例思路有所局限，所以需要随机测试来补强；
随机测试是一种重要的测试辅助手段，在测试中，要留出一定的时间，且较早安排；
随机测试应该是全员参与、全员测试，鼓励和调动各部门积极性，参与测试。
1.4.5 新功能测试和回归测试
调查显示，95%的用户喜欢功能稳定，不要经常变化的软件，只有5%的用户喜新厌旧，所以从这个意义上说，回归测试显得更为重要。
1.5 测试计划的最佳实践
(1).在确定测试项目的任务之前，应清楚测试的范围和测试目标；
(2).让所有合适的相关人员参与测试项目的计划制定，合格的相关人员包括产品经理、开发人员、技术支持人员、运维和市场；
(3).对测试各阶段所需要的时间、人力及其他资源进行预估，要留有余地，一般在10%~15%;
(4).制定测试项目的输入、输出和质量标准，并和有关方面达成一致；
(5).建立变化处理的流程规范，识别风险以及如何控制。
1.6 测试用例设计中的最佳实践
(1).责任到人。资深的测试人员往往更适合测试用例的设计工作，对模块熟悉的人更适合测试用例的设计工作；
(2).持续改进测试用例；
(3).测试用例设计不能局限于输入数据。测试用例的设计需要综合考虑软件的功能特性、测试目标、风险等，以及如何根据测试需求等确定测试用例的结构和设计策略、设计思路等；
(4).尽量避免含糊的、冗长的货复杂的测试用例。测试用例需要明确、准确；
(5).类似功能的用例抽象并归类。好的测试用例应该能代表一组同类的数据或相似的数据处理逻辑，此处可以借助测试用例思路设计来做。
1.7 测试自动化中的最佳实践
(1).准确的认识、切合实际的目标和切入点
自动化测试知识手工测试的一种补充，自动化测试宜先易后难，从最基本的模块、最基本的功能推进，有足够的时间进行测试脚本的开发；
(2). 把测试脚本开发纳入整个软件开发体系
流程上，自动化测试工作在想妈妈启动时就开始介入；
白盒测试工具需要开发使用后有对应的测试报告；
自动化测试工具测试的测试用例不需要再进行手工测试，将自动测试与手工测试有效的结合，并在最终的测试报告中体现自动化测试结果；
测试脚本需要积极创造条件构造数据驱动的脚本和结构化脚本，并通过关键词驱动将测试的逻辑层分离出来。同时将测试用例和测试脚本写入数据库，并进行动态管理；
(3).降低测试自动化的投入、提高其产出
可自动化测试模块选择上有讲究；
测试脚本数据驱动、关键字驱动；
测试和脚本开发合二为一；
