2011-6-15

只是想了想而已，于是就成下面的东西了：

1、测试计划：
  上次培训时提到测试策略，比如采用怎样的功能测试方法、测试入口出口标准。
  记得以前的测试策略都放在测试计划里的，并且是从组织标准过程中挪过来的。
  尤其在集成测试策略中会提到是由上及下的集成方法或是由下及上的集成方法。
  测试入口：开发完成单元测试、集成测试，并出示单元、集成测试report。
  测试出口：所发现问题都已解决，遗留问题少于5%。
  不过现在都没有测试策略一说。
  转测标准：初验通过。初验用例有测试人员提供，一般是从写好的用例中抽取能覆盖基本功能的用例。
  需要注意：如果是在基线版本上做定制，也需要验证基本版本的功能。
 
2、测试方案
   之前写测试方案都没有思路的。上次测试巴林版本，才对测试方案的结构有了一个较为明确的思路。
   首先，概述：概要提出该方案针对的测试内容；
   第二，测试对象分析：分析测试内容，详细的需求是怎样的；
   第三，测试设计：对于详细的需求，需要考虑哪些方面、哪些场景的测试；
   第四，测试用例：对于详细的场景，预置条件和预期结果是怎样。
   第四步也就是详细测试设计，粒度基本接近于测试用例。因此写用例时直接从这里开始即可。
  
   小结：测试方案的思路，和分析一个业务场景很类似。一步一步，来龙去脉都很清楚。
   将自己的方案讲解给别人听，也是一种理清思路的好方法。
  
3、测试用例：
   测试用例设计方法有很多种，但是实际使用的时候有以下问题：
   1）使用的方法比较少，一般都是：等价类划分、边界值、猜错法等。我们常用的场景覆盖应该属于等价类划分里。
   2）一旦遇到比较复杂的数据设计，希望用类似于正交法这样的方法来设计用例，由于对类似方法不熟悉，因此无从下手。
   3）对于用例的覆盖程度，目前无法计算。
     一般只计算用例覆盖率，这也是基于已有用例而言。
   4）对于缺陷与用例相关的度量，没有做。
     在提单的时候，有说明，如果这个问题是通过用例发现的，打Y，如果不是通过用例发现的，打N。
     但是在最后总结的时候，没有去统计、度量。
   5）测试用例的必要性：以前在NFS的时候，总有一种错觉：用例写了发现不了问题，还不如不写用例。
     但后来发现，用例是必须写的，至少覆盖了能想到的测试思路、测试点，这样与无用例的情况相比，漏测可能性较小。
     并且在有测试用例的情况下，也比较好分配和计算工作量。
     有人说，不是通过用例发现的问题，需要补充case，并总结、分析业务场景。
     如果能发现一个这样的场景问题，类似的场景也可能有问题。
4、业务知识：
   以前不知道什么叫做业务，在NFS的时候没这个概念，只知道需要了解需求、了解系统。
   业务覆盖面很广，任何与产品相关的都可以是业务。大到支撑的平台、小到一个输入框，都属于业务。
   学习业务知识的步骤，其实没总结过，自己接触了很多，好像伴着业务知识过两天，也就了解了。
   其实，应该是有步骤的，让我想想：
   1）了解下功能、模块是什么东西，使用场景是什么，最后的目的是什么？
   2）想想可能会涉及到哪些模块，各个模块之间是如何关联、业务是如何触发？怎样从源头一步步走到数据库结果的？
   3）针对每个关联的模块，具体做了哪些事情，进一步挖掘。
   这样，就从业务场景、关联模块等大的方面，到业务逻辑、如何实现等小的方面，就有了比较清楚的认识。
   在关注较为细节的业务逻辑实现的时候，最好借助于场景日志、存储过程，可以协助快速理解。
  
   业务知识是很重要的一块。
   对业务知识了解多、想得多，在编写测试方案和测试用例的时候也就更有思路。
  
5、测试技能：
   目前而言，也就是基本的业务掌握和数据库这块。
   总感觉还是有点浮在水面，没有去深挖问题。但我也不知道怎样才是深挖，从哪去挖，如何去挖。
   我们目前的工作面比较窄，都集中在业务这块。对于专项测试比较淡薄，基本上就是面向手工功能测试这块。
  
  
6、测试思想：
   其实，手工功能测试是其他所有测试的基础，思想基础。所谓的自动化，其实也就是工具而已。
   所以，lpb说的对，学习东西，先掌握其思想。等需要用得时候，再实际去关注细节。
   所以，tmy说的对，测试思想很重要。
   以前在NFS还总想这些问题，因为测试这块没人关注这个，而开发PM很关注这个。
   记得还跟大Boss PK过，也在bbs上和XJ对峙过。
   现在就完全浸在业务里了。一头钻进了业务，没想过外层的东西了。