下午公司安排了一个国内项目测试。
首先介绍的是《测试规程》，未来这些规程都将会放到TCOE上面。
测试的分类和概念
单元测试
集合测试：会比单元测试多出“准备”这样一个活动；
系统测试：会比集合测试多出“规划”，“搭建”活动。
接下来介绍的是《测试模板》
测试估计书，基于一些方法来对测试进行评估；
系统测试计划书：测试策略，人员安排等，测试设计（目标，用例）；
在应用过程中是可以对测试规程和模板进行裁剪，这里就像PMP的项目管理一样，他提供了一个标准的详尽的结构/架构，然后使用过程中对其进行裁剪和添加，保证过程的标准。
场景测试
就是站在客户的角度来编写用例。这个和User Story/User Case比较类似，举得例子和语言都要贴近客户。
场景测试有两类流程：基本流和备用流，场景1是基本流，场景2是基本流+备用流1；场景3是基本流+备用流2；
测试，不是一个活动，而是一个流程，流程就是由多个活动（阶段）组成的。或者说是有它的生命周期的。如果你把一个对象理解了它的生命周期，才算了解它。测试的活动有：准备，设计，测试，报告。
测试的阶段和关注点
集成测试的关注点：接口交互就OK。
确认测试的关注点：功能层面是是否满足客户的需求；
之所以要把测试分成不同阶段目的就是不同的阶段关注点不同，其实我们把开发划分成需求，概要设计，详细设计，开发等阶段也是为了分离阶段来分离关注点，所以搞懂阶段的关键是搞懂阶段的关键点。
测试的目的，确定测试的核心目标：发现系统不满足客户需求。
测试的滞后问题
测试有一个滞后的问题，如何才能将测试前置，测试流程中的测试活动无法提前，但是测试用例的编写是可以提前的，如果开发人员在开发之前就知道测试的用例，并在开发过程中加以注意就可以节省大量返工的成本，测试人员测试工作量也会减少。
测试原则
1.证明有缺陷；
2.穷尽不可能；
3.集群原则（发现问题的地方/人，可能还存在问题）；
4.杀虫剂悖论。伴随着测试用例水平的提高，所发现的Bug也是更加深层次，当然，系统的安全性稳定性也就越高；
5.依赖测试背景（测试结果和效果和测试人的水平/背景有关系）；
6.不存在缺陷就是有用系统悖论。作为测试人员不能仅仅满足于设计书的测试，还要深挖客户需求，现有的系统是否是客户的原始需求，当然，这就跳出开发，而是站在客户的需求角度来测试。
测试介入的时机和深度
尽早介入。还是回到刚才谈到的问题，介入可能不是测试人员介入，而是开发接入到测试阶段，比如在需求设计之时，就开始设计系统测试用例。设计阶段设计集成测试用例，开发阶段设计单元测试用例。所以前期测试人员可能之时介入一个测试需求人员，到后来再介入大量介入测试人员，这一点其实和开发是一致的。
测试策划
本质是工作量和资源的分配。考虑点：
1.受限情况（人力，资源）；
2.可预见的重要缺陷及早发现；
3.做多少个用例（如何确保覆盖率）；
4.各个阶段如何安排测试。
5.测试覆盖度，测试的深度。关于覆盖率其实是一个水平的概念就是测试用例覆盖了多少个业务点，测试深度则是针对单个业务点而言多次测试，多角度测试。 
6.进行回归测试。回归测试不仅要测试曾经异常的Bug还要测试关联业务，是否有受到影响。
7.测试环境的搭建
测试管理过程
1.测试套件的管理。测试套件包括测试用例，测试环境，以及测试的应用程序。对于测试的应用程序，就有一个版本管理问题：防止发生一个Bug在一个版本下面可重现，换了版本后Bug不见了，但是无法追溯了。
2.测试数据和测试用例分开。首先是因为测试用例和测试数据是1：1..*的关系，分开可以减少Case本身描述的数量；另外不同的阶段对于同一个Case所需要的数据可能是不同的，所以测试数据不要和测试用例绑定过于紧密。可以考虑在备注中对于测试数据进行描述，而不是指定。
3.测试是一个流程，他的一个很重要的环节就是交流和报告。交流是指使整个测试过程在成员组内部透明，测试进行到什么程度，大家需要注意什么问题，测试有什么好的方式；报告则是向团队外的人，比如干系人，部门领导汇报项目的进展情况，让项目情况对于上级也是透明的。在报告的环境就需要对于测试进行分析，这里常见的是趋势分析法。是收缩还是扩张，从而判定项目的风险。
测试设计
1.边界值法；
2.等价分类法：对于达到同等目的的不同测试用例进行合并；
3.决策表；
4.功能图法