1) 对自动化测试的理解
Ø 自动化测试，它是软件质量的保障体系，自动化测试最大的优点就是把重复性的劳动交给计算机去做，包括review静态代码，每个版本更新后都需要重复测试的功能，或者是大量的数据的重复操作。这些如果在项目之前都开发完成的话，对于软件的效率会有极大的提高。
Ø 微软自动化测试体系的最核心价值：每天都可以对所用的用例进行覆盖（日覆盖），不是常规企业的月覆盖或者周覆盖，其发现缺陷周期降到按天来计算。
（我们目前是一个发布版本累计才能做到用例的完整覆盖）
2) 自动化测试的局限性
Ø 自动化测试前期投入很大，包括编写自动化测试工具，开发自动化测试脚本。如果项目周期短，没有可持续性不适合自动化测试。
Ø 自动化测试的技术门槛相对较高，测试团队整体水平不高的情况下无法完成工具的发开，心有余而力不足。
Ø 对于没有预期结果的测试，不适合自动化。
Ø 对于用户体验的测试，主观性比较强的不适应自动化
3) 自动化测试用例设计有关原则性要点
Ø 每个case都可独立运行；
Ø 每个用例执行完毕后，清理产生的垃圾，恢复用例执行前的环境；
Ø 数据驱动、本地文件驱动
Ø 用例设计要考虑复用素材库，素材库内容包括各种对象（保存在本地文件或者数据库中）和函数(DLL库）；
Ø 自动化测试过程，既要处理测试发现的产品bug,也要处理自动化测试代码本身的bug(自动化脚本代码本身的bug)。
4) 自动化测试涉及的技术（这些技术具体实现讲师没有详细讲解）
Ø 测试探针技术
Ø 代码注射技术:修改目标码，对目标码中增加测试运行代码，包括错误注射（Fault Injection）等
Ø 单进程封装:测试代码和应用代码封装在一个进程中运行
Ø 用程序读程序（用一个懂的人将读程序的思路写成一个读程序的程序：白盒测试中的静态代码检查，检查规范、定义）
思考：
a) 微软的测试工程师都具备很强的开发能力，都可以编写自动化测试代码，我们并不具备这样的能力，目前是借助商业的自动化测试工具，开发一套自动化测试框架，采用数据驱动+关键字驱动的技术，合理的规划、封装，尽可能让测试人员易用，理想状态测试人员就像写用例一样，由框架后台解释为可自动执行的脚本。框架设计过程中可借助培训中设计原则的一些思想。
b) 将通用用例测试实现自动化是重要要考虑的一个点，通用用例在每个功能、每个页面都需要重复执行，测试的方法、标准一致或有规则可循，目前手工测试并没有完全执行，如果全部执行，工作量是非常大。这一块能够实现自动化测试，将给测试效率带来很大提升。
c) 从开发层面，可以考虑采用一些静态代码检查的工具，对代码规范、严谨性进行检查。
2 测试管理
1) 管理理念
Ø 流程就是一个无处不在的管理者
微软软件研发通过使用流程管理制度化的工作方式，代替经理们进行日常经常性的工作管理，经理可以有更多经理用于团队重要工作任务的规划
Ø 管理是为了面向现在和未来，而不是追究过去
Ø 不可能事事尽美，但要将每件事情弄清楚
Ø 认定目标必须要有结果
Ø 当某件事推动不力，特别是涉及协作时，管理者要考虑建立流程机制
Ø 很多事情看起来很难，但注意只是很难，不是无解的
Ø 人员永远不可能足够的，投资回报率的问题，人员不够要加人时，考虑以下几个问题
ü 现有的人有没有充分应用？
ü 加人是为了解决什么问题？
ü 可能通过提升效率、通过技术手段去解决？
ü 加人怎么用？现在加了，后续能够持续使用吗？
2) 让数据说话：通过对测试用例和BUG的追踪统计，看出项目组发生了什么、正在发生什么、甚至将会发生什么
Ø 建立测试度量体系
微软自主开发了一套测试平台，测试过程、结果全部统一管理，自动获取各类分析数据
ü 缺陷库建立、缺陷追踪体系
ü 用例库建立
ü 测试结果库建立
ü 数据统计与分析系统
用例库、缺陷库和结果库是数据分析、辅助决策的支撑平台
目前我们只是建立了缺陷管理系统，测试用例还是用EXCEL文档维护，测试结果库更是缺失，测试用例的维护、复用、统计都存在问题，下一步有必要建立测试用例管理系统，之前也研究过TD、QC等商业管理工具，与我们目前的用例结果、管理方式差异很大，建立考虑自主开发用例管理系统，并与BUG管理系统、自动化测试集成为同一平台。
用例库建立基础上，以后再逐步考虑结果库的建立，用于数据统计、决策分析。
