摘要：这是Aaron同一位cnblogs的博友的聊天记录，他“准备给公司建立测试制度”，因为看到了Aaron这几天发的几篇文章，所以找Aaron聊了聊。过程中谈到了测试的一些内容，Aaron根据自己的草根经验对他的问题作出了回答，但Aaron担心有误人子弟之嫌，所以在获得该博友的同意后将聊天内容摘录出来，希望大家各抒己见，踊跃拍砖。
为保护隐私，将该博友的昵称换做了“QQ好友”，另外为了方便大家阅读，修正了部分错别字，并对双方的发言做了标示。大家对于Aaron的任何言论有意见或者建议，欢迎发表评论拍砖，Aaron无不感谢，但是对于那位博友，希望大家不要发表不友好言论，否则笔者将删除，望理解~
10:28:18 QQ好友
你好，正在看你的计划测试系列文章了
10:31:53 QQ好友
我对测试这块不是很熟悉，以前主要是做分析的
有几个问题请教你
现在各种各样的测试名词很多。包括什么web测试，性能测试，单元测试一堆的测试的名词
我头绪有点乱
因为现在准备给公司建立测试制度
10:31:18 Aaron
恩
你们公司规模多大？
10:32:55 QQ好友
但一想到这些概念总感觉很乱，没有头绪，感觉引进过程没有切入点
10:33:03 QQ好友
人不多，不到10个人
测试类型和公司规模也有关系吗
10:31:59 Aaron
不是，我想了解你们公司的情况，我自己的那一套东西比较适合小公司
10:34:13 QQ好友
你说的人，时间，空间，事物，目标和UML分析中的概念极其类似
10:32:46 Aaron
如果是在测试比较成熟的公司，用这一套就不合适了（注：笔者的所处的公司现在已经加入了许多规范测试流程中应该involved的流程，但是为了便于大家实践所以在“计划测试”系列中谈到。）
10:34:17 QQ好友
用例也一样
10:33:16 Aaron
那个是从测试管理上面来说的
10:34:48 QQ好友
我们公司完全没有任何测试制度
10:33:39 Aaron
测试其实也是一个场景，所以实际上也是可以用UML画出来的
10:35:22 QQ好友
是的，这个好理解，测试过程说白就是一个用例
10:35:33 QQ好友
但你提到测试的目标应该是可度量的
10:34:17 Aaron
这个场景无非就是某人某时在某地干某事
10:35:51 QQ好友
也就是说可以量化，好比绩效考核，量化后才好定进行程度
10:34:37 Aaron
测试的目标可度量这一块是很重要的
10:36:21 QQ好友
但具体量化方式我看到你在拿个系列里面只提到了两个举例，一个是BUG数量，一个是测试覆盖面
10:34:53 Aaron
关于量化的一些经验在我的后续的文章中会提到
10:36:27 QQ好友
还有其他量化指标吗
10:35:08 Aaron
当然有很多
10:36:47 QQ好友
你哪里有相关资料吗，可以给我提供一份吗，我等不到你的文章了
10:35:31 Aaron
测试覆盖率那个指标就刚起步的开发团队来讲并不是很实际的
10:37:25 QQ好友
我想也是
10:36:17 Aaron
但是在逐步发展后那个东西就显得很有用了
关于测试覆盖率你也可以看一下我的测试覆盖率系列文章，博客上面有
10:38:17 QQ好友
还有个很重要的问题，除了测试目标的量化考核标准意外，我想实际测试是有方式方法的，从各个层面，比如测试性能有专门的性能测试工具，要测试功能有专门的功能测试方法，我不知道我想的是否正确
10:37:08 Aaron
对
10:37:23 Aaron
你对测试现在还没有了解是吧？
10:39:13 QQ好友
了解不是很多
10:38:08 Aaron
推荐一本书籍，Ron patton《软件测试》
这本书非常棒，很适合你
10:40:11 QQ好友
我做软件时间不短，大概11年不到点，但以前主要是从编码，辅助分析，分析到管理一路上来的，也管理过测试团队，但涉及不深，现在刚从上海回来要给老家本地一个小公司实施测试制度，感觉以前学艺不精有点没有切入点了
10:43:30 QQ好友
还有个很重要的问题，除了测试目标的量化考核标准意外，我像实际测试是有方式方法的，从各个层面，比如测试性能有专门的性能测试工具，要测试功能有专门的功能测试方法，我不知道我想的是否正确
我这个话理解正确吗
10:42:15 Aaron
是的
测试有测试的方法
10:43:51 QQ好友
哦
单元测试是什么过程
10:42:33 Aaron
测试的分类本身就是一门学问
10:44:10 QQ好友
是的，这个我也赞同
10:43:20 Aaron
单元测试这一块主要是对具有行为的函数本身进行测试
10:45:32 QQ好友
具有行为的函数的测试，这个怎么理解，是函数都有行为啊，除了抽象类的函数可能没有任何行为外
10:44:50 Aaron
就是说抽象类中的一般是不测试的（笔者观点，欢迎拍砖~）
10:45:05 Aaron
举个例子来讲吧，
比如函数A
int A（int a1,int a2）
{
return a1/a2;
}
这个时候我们要设计单元测试用例
写一个函数TestA，调用A（2，0）来测试，或者TestB，A（1，1）
10:47:57 QQ好友
等一下，单元测试你刚才说首先是针对有行为的函数的，你刚才这个函数肯定是有行为的，因为他返回输入参数的计算结果值
10:47:13 Aaron
对于有返回值的函数我们需要检查输入输出
10:48:52 QQ好友
可我有个问题，一个系统实现后类数量很多，而且类里面方法最后综合也不小，几乎具体层类的方法都是有行为的。这么进行单元测试，不是工作量很大吗
10:47:42 Aaron
对于没有返回值函数，我们要检查它操作的变量的变化
10:49:19 QQ好友
是的，怎么检查
没有返回可能他改变另外一个类的状态
10:48:26 Aaron
对，检查函数行为是否是我们预期的
实际上单元测试的代码要比源代码多
这也是很多公司并没有很好引入单元测试的缘故
10:49:12 Aaron
对于测试的引入，建议首先引入手工功能测试 ，然后（或者同时）要求dev leader在他的代码（指核心代码）引入单元测试
10:51:56 QQ好友
你刚才说的手工功能测试是指什么
10:51:06 Aaron
手工功能测试就是一些开发人员理解的“谁都会点”的在软件上到处点点的测试
看程序会不会崩，看程序是不是正确运行
10:51:43 Aaron
这个是看起来是很简单，但是这里面也有很多道道
10:53:17 QQ好友
那接下来说的dev leader在核心代码引入单元测试什么意思
10:53:18 Aaron
程序的核心功能质量要求是很高的，而dev leader的技能和觉悟也是相对较好的，从他们开始引入单元测试更容易被接受，对项目的好处也更多
10:56:03 QQ好友
哦，可同样存在一个问题，核心功能一般在项目中的地位是底层功能，上层有一般程序员编写。但底层并不意味这类数量少，最后意味这有行为的方法数量少，数量多的情况下引入单元测试对测试团队的要求也是很搞的。甚至比写一个测试系统都高
10:55:47 Aaron
这就要权衡质量的重要性了
10:57:28 QQ好友
恩
10:56:25 Aaron
如果总是因为单元测试的代码量大而拒绝单元测试，那单元测试永远就开始不了了
10:58:07 QQ好友
单元测试是对行为的测试，这个行为的存在形式可能是函数返回值，也可能就是函数执行的代码，情况不一定了
单元测试有工具吗，还是只有框架
10:57:09 Aaron
单元测试有很多好用的框架 ，比如XUnit系列
10:58:51 QQ好友
但没有现成的软件是吧
10:58:14 Aaron
单元测试涉及的是具体的代码，而不是GUI，这些是没有标准的，所以没有你所期望的单元测试工具
但是有一些工具可以帮你分析代码其他的质量属性
11:00:08 QQ好友
可GUI也可以利用单元测试进行测试吧
10:59:55 Aaron
这个……还是建议你先看看《软件测试》，先把各种测试的概念搞清楚吧，这样对于你来讲是更迫切的
11:02:07 Aaron
你先看看这本书吧，看完之后应该会有收获
http://www.china-pub.com/s/?key1=（美）Ron%20Patton&typeid=
（注：《软件测试》Ron Patton 著 第二版 中文 PDG电子书下载）
11:06:15 QQ好友
我看到你的BLOG提到DOTNET自动化测试之道，今天也从当当订了本，这个书咋样
11:05:48 Aaron
这本书不错，但是个人觉得像你这种情况应该先把手工功能测试做好，至少积累一个项目的经验之后再开始计划自动化的那一块吧
11:07:53 QQ好友
手工测试的方法在你说的软件测试这个书上也有讲解吗
11:08:15 QQ好友
听你刚才这个话的意思，所谓的自动化测试说白了就是通过现成的软件所带的功能进行测试就叫自动化测试吧
11:07:27 Aaron
当然不是，我是指测试理论这一块对于测试很重要
11:09:13 QQ好友
哦
11:07:53 Aaron
而且事情需要一步一步来，一口气是吞不下一个大胖子的~
11:09:27 QQ好友
呵呵
我做这么多年技术，最大的体会就是技术必须多交流，呵呵，可能有偏颇但的确是最大的体会了
