我也转关于软件测试的文章
微软测试技术可借鉴的点
我想作者漏掉了一个最重要的方面，那就是自动化可以解决我们的测试问题。两个方面，一是自动化可以完成手工不能完成的任务，二是自动化可以替代手工重复的劳动。这才是我们搞自动化最重要的原因。关于自尊心的问题是有的。可是作者解释的好像都不在理。计算机科班出身的人都喜欢做开发？这个观点从何而来？计算机出身的人可以做开发，测试，dba，support，销售，市场，自己创业。各种工作都有可能，怎么能说都喜欢做开发呢？以我的个人经验来看，喜欢做开发的是少数。做测试经常是身不由己？我认为做开发也很多是身不由己。测试工作很多时间不需要编程？开发人员很多时间也不需要编程。后边的就不说了。总之，给人的感觉都是作者的心理。好像作者自己喜欢做开发，身不由己作了测试，发现不需要什么编程，然后就想方设法写程序，以显示自己也会编程，结果出了大问题了。这里可以提供两点信息，一是作者想做开发没有做成。可见作者的开发能力有限，老板不给提供这个机会，因为老板是要给产品负责的。还有就是，做了几年的程序，而且一直想转开发而转不过去的话，我真的不能suppose他水平有多高了。另外就是，把自己的心理，心态，引申到整体，不是很有道理。
进行第二部分的时候，我想简单说一个问题。以我个人的看法，功能测试根据被测试对象主要可以分三种类型：UI测试，Command line测试和API测试。我认为后两部分是非常适合用自动化来作为主要方法进行测试的。作者只是提到了UI自动化，然后就推广到整个的自动化。我认为这不是很reasonable的。如果谁要是认为API和command line的测试不适合自动化，我们可以单独讨论。不过这里，我们就要把topic nail down了。我们只谈UI的自动化。如果我们要谈整个的自动化，作者的观点一下子就错了，没必要继续谈下去了。
作者在自动化过程中发现的问题，和犯下的错误是初学自动化的人很容易出现的。刚开始的时候，很多人都想把自己的自动化做的多么fancy,想100%的automation.把目标定得很高，结果又相差很大。因此，就动摇了自动化的信心。我做自动化总是强调的一点是，“怎样合理的进行自动化？”。什么应该自动化，什么不应该自动化，怎样进行自动化，这都是有一定学问的，也是一个senior测试人员应该具备的基本能力。因为作者的能力问题，使得后来的测试人员不愿意用他们的代码，宁可另起炉灶。这完全不能说明自动化有什么不好的。你想想看，如果你设计，实现了一套非常好的，非常灵活的自动化系统，后来的人很轻松的能够上手，他为什么还要自己重新来过呢？以我个人的经验来看，想另起炉灶的最根本的原因是因为以前人留下的代码太滥了。这个不光测试有这个问题，开发中同样普遍。我设计的自动化框架，到我辞职后一年还没有替代品的出现，大家都是在我的基础上进行新的开发和利用，以及扩展。这又说明了什么？我从来没有试图去说服别人一定要用我的。好的东西，别人一定会看到的。
http://www.51testing.com/?uid-88979-action-viewspace-itemid-86696
1.1 测试驱动开发，尽早、不间断地进行软件测试。建立强大的支撑daily build和daily test的自动化测试体系。围绕BUG数据为中心建立缺陷管理平台、统计分析、项目管理平台。决策从经验模型转向科学模型，整个软件开发流程宏观、微观细节都用数据说话。透过数据管理者花精力在尚未做好的事情上
1.2 建立制衡制度、文化，不让有问题的代码check in，保证代码库神圣。减少围绕BUG的各种成本。
1.3 完善各种CheckList 或者模版(文档、用例)、开发测试工具（白盒…），让能力瞬间transfer 到团队，充分应用已有成员的成果，提升team Level。充分避免手工测试弊端(无知识传承、置信度低、相对持续在一个水平)
1.4 自动化测试不仅仅是技术，更是思想，自动化测试不是找BUG的而是一种质量保证手段。自动化本质是引入一种痛苦解决另外一种痛苦。基础设施不足是问题根本。脚本是自动化的最低形式。框架充分re-use、封装复杂度，提高框架的适应能力。自动化测试应在单元级上细致验证。建立自动化的平方环境
1.5 在每一个环节细致严格要求，比如BUG提交规范减少人为沟通。每一个QA把自己的事情一次作好、做专业
1.6 发布标准： 95% case通过率以及85% 代码覆盖率，<5%不重要的case bug。
1.7 强调文档价值（能力转换形式，对管理的支撑）以及定义高质量文档的要求
1.8 可靠性测试、可扩展性测试针对设计而言，尽早测试，否则即使结果不满意，成本也很高昂
1.9 Work around和彻底解决问题间，选择后者。硬碰硬突破
1.10 测试工程师业绩考核指标：增加check in前预防BUG、发现别模块的BUG、开发自动化工具等贡献度大的项比重
1.1 测试驱动开发，尽早、不间断地进行软件测试。建立强大的支撑daily build和daily test的自动化测试体系。围绕BUG数据为中心建立缺陷管理平台、统计分析、项目管理平台。决策从经验模型转向科学模型，整个软件开发流程宏观、微观细节都用数据说话。透过数据管理者花精力在尚未做好的事情上
1.2 建立制衡制度、文化，不让有问题的代码check in，保证代码库神圣。减少围绕BUG的各种成本。
1.3 完善各种CheckList 或者模版(文档、用例)、开发测试工具（白盒…），让能力瞬间transfer 到团队，充分应用已有成员的成果，提升team Level。充分避免手工测试弊端(无知识传承、置信度低、相对持续在一个水平)
1.4 自动化测试不仅仅是技术，更是思想，自动化测试不是找BUG的而是一种质量保证手段。自动化本质是引入一种痛苦解决另外一种痛苦。基础设施不足是问题根本。脚本是自动化的最低形式。框架充分re-use、封装复杂度，提高框架的适应能力。自动化测试应在单元级上细致验证。建立自动化的平方环境
1.5 在每一个环节细致严格要求，比如BUG提交规范减少人为沟通。每一个QA把自己的事情一次作好、做专业
1.6 发布标准： 95% case通过率以及85% 代码覆盖率，<5%不重要的case bug。
1.7 强调文档价值（能力转换形式，对管理的支撑）以及定义高质量文档的要求
1.8 可靠性测试、可扩展性测试针对设计而言，尽早测试，否则即使结果不满意，成本也很高昂
1.9 Work around和彻底解决问题间，选择后者。硬碰硬突破
1.10 测试工程师业绩考核指标：增加check in前预防BUG、发现别模块的BUG、开发自动化工具等贡献度大的项比重
测试人员的误区:迷信自动化
终于有时间总结一下过去几年在微软的测试经验，谈谈对测试自动化的看法。
先说说为什么做测试的人喜欢搞自动化。
第一，自尊心。计算机科班出身的人都喜欢作开发(Dev)。做测试工作经常是身不由己，可是测试工作很多时间不需要编程，于是做测试的人想方设法写些程序，以显示自己也会编程。结果往往是欲罢不能，测试自动化程序越写越多，越写越复杂。后面我会谈谈测试自动化框架复杂的代价。
第二，为了出成绩。很多测试组为了向管理层展示成绩，往往要拿出例如测试自动化达到80%，程序覆盖率达到90%。要我说，这些都是Bull Shit。就象小平同志说的“实践是检验真理的唯一标准”，我认为在测试中“用户不出问题是检验质量的唯一标准”。自动化做的再多，用户出了问题，也是白搭。另外，一个人就可以做的测试，自动化往往需要两个，三个。倒是解决就业的好方法。
我对测试自动化的认识也有一个变化的过程。刚刚入行时也是很相信自动化，想方设法写一些从头到尾自动化的框架，觉得自动测试很过瘾。到微软的Portal Media Center组后也是和另外两个人做了一个相当复杂的用户界面的自动测试。其实现在想想，用自动测试发现的问题基本上可以一个人用手工测试完成，最多写些简单的测试辅助工具就可以完成。有些人可能会说自动化可以为产品的下一个版本节省测试时间。其实Portal Media Center 下一个版本出来时，所有户界面完全变了，80%以上的自动测试程序都需要改动。做完第一个版本，我们三个人全都走掉了。后面来的人往往宁可自己再写一套，也懒得改以前人的程序。自动化的浪费就是这样造成的。想说服别人用你开发的自动测试框架是很难的，所有人都想另搞一套。
下面分几点讲讲为什么要放弃对测试自动化的幻想，和怎样进行低成本的有效测试。如果你还不能同意我对测试自动化的看法，可以去微软员工的Blog看看为什么Windows测试组用的WTT测试框架被称作“Waste of Tester Time"。我最基本的观点不是说测试自动化不能测出bug，而是想问：一个比较复杂的测试自动化框架所造成的人力浪费，值不值得最终的结果?如果不做测试自动化，能不能达到同样的效果。以我的亲身经历，去年我的测试组两个人对应开发组五个人，项目经理三个人的工作量，去年做了好几个Release，Hotfix只有两三个。我们旁边的测试组七八个人对应五六个Dev。他们又是自动化，又是搞程序覆盖率，好不热闹，Hotfix 也不少。按一个人的人工成本12万美元，我们组省至少三个人的成本36万美元。
第一，不要指望自动化能帮你找bug。软件bug和生物的bug很像，测试的规律是bug少的地方bug越少，bug多地方越找越多。做测试自动化，往往在开发自动化的时候，该发现的bug就发现了。自动化开发完成，再想发现更多bug就很难了。这是无论你怎样跑你的自动化，也不会发现新的bug。
第二，不要指望自动化对Regression Test的测试的贡献。软件的特点是如果一次做对了，以后永远不会出错。当程序出现变动时，只要针对变动的部分测试就可以了，以前测过的东西，如果和变动没有关联就不会出错。相反如果，程序出现很大变化，自动化可能完全不能用了。
第三，自动化不如测试工具加手工测试。我不建议测试人员作全面自动化，相反我建议测试人员多做小巧灵活的测试工具。自动化往往需要自动判Pass或Fail。 想想你如果测试用于生成 http://www.microsoft.com/的页面的产品，你如何判断页面框架生成的正确?很多东西是动态产生的，你很难确认所有的内容的正确性。如果你自己用这个产品手工做个页面，用肉眼很容易判断所有相关和不相关的内容生成的正确性。我就是用这个方法在工作中发现了网页上谁也想不到的bug, 如果用自动化很难在测试阶段发现这个bug。
第四，软件项目的生命周期就定了自动化的无用。现在很多网络应用项目的生命周期都很短，一个项目从生到死不过两三年。死的定义是项目进入Sustain Engineering维持状态。自动化原来的一个主要目的是使软件测试的未来阶段越来越容易，成本越来越低。可是当一个项目死掉了，自动化还有什么用。而且最新的敏捷开发，软件的要求，程序，接口，界面在不断变化，自动化怎么可能跟得上变化。与其去搞自动化，不如多理解变化，直接测试变化的东西。
如何进行有效测试?
第一，测试人员的自信心可以建立在读程序的能力上。在一个项目中，开发人员的工作是研究新技术，写出最好的程序。测试人员应该在开发人员研究的基础之上，更好的理解新技术，读懂程序。看懂程序可以使测试工作非常高效。不懂内部程序的人，可能会设计三十个test cases, 才能找到一个bug。 懂程序的人每个test case都可能发现一个或多个bug。 我有30%的bug都是读程序读出来的。由于对开发人员的程序有很深的理解，即使release后出了问题，也能很快理解问题出在什么地方，是否是bug。
第二，测试人员写测试程序的时间应该尽量最小化。测试人员测试的时间分配应该是, 30%读程序，20%写测试程序，50%写Test Cases和运行Test Cases。好的测试员的工作重点应该放在理解要求，理解客户需要，思考在什么条件下程序会出错，而不是思考如何去自动化。如果时间都放在设计自动化上了，必然会影响测试，分散测试资源。测试人员应该边读程序边测试，读程序帮助找到好的Test Case，测试帮助验证理解和猜测。
第三，测试人员要学会讨价还价。很多时候项目经理，开发人员搞得东西不是客户马上需要的，或许是永远用不到的。测试人员可以和项目经理研究先测什么，后测什么，那些不测。比如，我做的一个项目，我发现30%的功能是现在用处不大，所以我直接告诉项目经理那些东西我不会去测的。事实证明，这样做节省了很多人力。
第四，测试人员要多花时间参与设计。测试人员一定要紧跟项目经理和开发人员的要求变化和设计。理解每一个要求的影响。在每个项目周期中，去比较当前版本和以前版本的所有程序变化。重点测试变化。
总之，少做自动化，多写小工具，读懂程序，是高效省钱的测试方法，除非你钱多得没地方花。下次有谁建议搞什么测试自动化构架，告诉他“That is bullshit”。
先说说为什么做测试的人喜欢搞自动化。
第一，自尊心。计算机科班出身的人都喜欢作开发(Dev)。做测试工作经常是身不由己，可是测试工作很多时间不需要编程，于是做测试的人想方设法写些程序，以显示自己也会编程。结果往往是欲罢不能，测试自动化程序越写越多，越写越复杂。后面我会谈谈测试自动化框架复杂的代价。
第二，为了出成绩。很多测试组为了向管理层展示成绩，往往要拿出例如测试自动化达到80%，程序覆盖率达到90%。要我说，这些都是Bull Shit。就象小平同志说的“实践是检验真理的唯一标准”，我认为在测试中“用户不出问题是检验质量的唯一标准”。自动化做的再多，用户出了问题，也是白搭。另外，一个人就可以做的测试，自动化往往需要两个，三个。倒是解决就业的好方法。
我对测试自动化的认识也有一个变化的过程。刚刚入行时也是很相信自动化，想方设法写一些从头到尾自动化的框架，觉得自动测试很过瘾。到微软的Portal Media Center组后也是和另外两个人做了一个相当复杂的用户界面的自动测试。其实现在想想，用自动测试发现的问题基本上可以一个人用手工测试完成，最多写些简单的测试辅助工具就可以完成。有些人可能会说自动化可以为产品的下一个版本节省测试时间。其实Portal Media Center 下一个版本出来时，所有户界面完全变了，80%以上的自动测试程序都需要改动。做完第一个版本，我们三个人全都走掉了。后面来的人往往宁可自己再写一套，也懒得改以前人的程序。自动化的浪费就是这样造成的。想说服别人用你开发的自动测试框架是很难的，所有人都想另搞一套。
下面分几点讲讲为什么要放弃对测试自动化的幻想，和怎样进行低成本的有效测试。如果你还不能同意我对测试自动化的看法，可以去微软员工的Blog看看为什么Windows测试组用的WTT测试框架被称作“Waste of Tester Time"。我最基本的观点不是说测试自动化不能测出bug，而是想问：一个比较复杂的测试自动化框架所造成的人力浪费，值不值得最终的结果?如果不做测试自动化，能不能达到同样的效果。以我的亲身经历，去年我的测试组两个人对应开发组五个人，项目经理三个人的工作量，去年做了好几个Release，Hotfix只有两三个。我们旁边的测试组七八个人对应五六个Dev。他们又是自动化，又是搞程序覆盖率，好不热闹，Hotfix 也不少。按一个人的人工成本12万美元，我们组省至少三个人的成本36万美元。
第一，不要指望自动化能帮你找bug。软件bug和生物的bug很像，测试的规律是bug少的地方bug越少，bug多地方越找越多。做测试自动化，往往在开发自动化的时候，该发现的bug就发现了。自动化开发完成，再想发现更多bug就很难了。这是无论你怎样跑你的自动化，也不会发现新的bug。
第二，不要指望自动化对Regression Test的测试的贡献。软件的特点是如果一次做对了，以后永远不会出错。当程序出现变动时，只要针对变动的部分测试就可以了，以前测过的东西，如果和变动没有关联就不会出错。相反如果，程序出现很大变化，自动化可能完全不能用了。
第三，自动化不如测试工具加手工测试。我不建议测试人员作全面自动化，相反我建议测试人员多做小巧灵活的测试工具。自动化往往需要自动判Pass或Fail。 想想你如果测试用于生成 http://www.microsoft.com/的页面的产品，你如何判断页面框架生成的正确?很多东西是动态产生的，你很难确认所有的内容的正确性。如果你自己用这个产品手工做个页面，用肉眼很容易判断所有相关和不相关的内容生成的正确性。我就是用这个方法在工作中发现了网页上谁也想不到的bug, 如果用自动化很难在测试阶段发现这个bug。
第四，软件项目的生命周期就定了自动化的无用。现在很多网络应用项目的生命周期都很短，一个项目从生到死不过两三年。死的定义是项目进入Sustain Engineering维持状态。自动化原来的一个主要目的是使软件测试的未来阶段越来越容易，成本越来越低。可是当一个项目死掉了，自动化还有什么用。而且最新的敏捷开发，软件的要求，程序，接口，界面在不断变化，自动化怎么可能跟得上变化。与其去搞自动化，不如多理解变化，直接测试变化的东西。
如何进行有效测试?
第一，测试人员的自信心可以建立在读程序的能力上。在一个项目中，开发人员的工作是研究新技术，写出最好的程序。测试人员应该在开发人员研究的基础之上，更好的理解新技术，读懂程序。看懂程序可以使测试工作非常高效。不懂内部程序的人，可能会设计三十个test cases, 才能找到一个bug。 懂程序的人每个test case都可能发现一个或多个bug。 我有30%的bug都是读程序读出来的。由于对开发人员的程序有很深的理解，即使release后出了问题，也能很快理解问题出在什么地方，是否是bug。
第二，测试人员写测试程序的时间应该尽量最小化。测试人员测试的时间分配应该是, 30%读程序，20%写测试程序，50%写Test Cases和运行Test Cases。好的测试员的工作重点应该放在理解要求，理解客户需要，思考在什么条件下程序会出错，而不是思考如何去自动化。如果时间都放在设计自动化上了，必然会影响测试，分散测试资源。测试人员应该边读程序边测试，读程序帮助找到好的Test Case，测试帮助验证理解和猜测。
第三，测试人员要学会讨价还价。很多时候项目经理，开发人员搞得东西不是客户马上需要的，或许是永远用不到的。测试人员可以和项目经理研究先测什么，后测什么，那些不测。比如，我做的一个项目，我发现30%的功能是现在用处不大，所以我直接告诉项目经理那些东西我不会去测的。事实证明，这样做节省了很多人力。
第四，测试人员要多花时间参与设计。测试人员一定要紧跟项目经理和开发人员的要求变化和设计。理解每一个要求的影响。在每个项目周期中，去比较当前版本和以前版本的所有程序变化。重点测试变化。
总之，少做自动化，多写小工具，读懂程序，是高效省钱的测试方法，除非你钱多得没地方花。下次有谁建议搞什么测试自动化构架，告诉他“That is bullshit”。
接下来是另外一个人批判上面那个人的:
今天看到这篇关于自动化测试的文章，有很大的误导作用，我也谈一下对自动化测试的看法。首先，作者是一个在微软工作了几年的一个测试人员，总结的是在微软的测试经验。可是他总结的并不是典型的微软公司的测试观点，而是自己个人的测试观点。因此，他的观点实际上是与微软公司没有太大关系的。这点，大家还是不要被误导。众所周知，微软在几年前对测试有一个大的改变。以前微软有两种职位，STE和SDET，前者是手工测试，后者是自动化测试。微软把STE基本cut掉了，因此STE要不走人，要不转SDET。转过来的，因为以前主要是手工测试，因此就对自动化测试产生很大的抵抗情绪。这种情绪是team lead很不愿意看到的。因此，STE的困境是比较大的。还有就是在微软里做几年如一日的测试人员大有人在，因为能力问题，级别得不到提升。因此，几年还是junior。所以，在微软做几年测试，也不代表就是一个级别很高的人。
另外要说明一点，从文章的title里可以看到，这篇文章是说给迷信自动化测试人员的。作者以前本身就是一个迷信自动化测试的人，可是后来从迷信变得不相信自动化测试了。可见作者是一个很容易走极端的人，从头到尾都没有用一个公平理性的态度去面对自动化测试。还有就是，这个文章如果给迷信自动化测试的人看，还是有一定意义的。可是，我们当中有几个人像作者以前那样迷信自动化呢？大部分看了可能会觉得是针对整个自动化来讲的，而且作者确实也偏离了他的title，因此我也需要澄清一下。
我想作者漏掉了一个最重要的方面，那就是自动化可以解决我们的测试问题。两个方面，一是自动化可以完成手工不能完成的任务，二是自动化可以替代手工重复的劳动。这才是我们搞自动化最重要的原因。关于自尊心的问题是有的。可是作者解释的好像都不在理。计算机科班出身的人都喜欢做开发？这个观点从何而来？计算机出身的人可以做开发，测试，dba，support，销售，市场，自己创业。各种工作都有可能，怎么能说都喜欢做开发呢？以我的个人经验来看，喜欢做开发的是少数。做测试经常是身不由己？我认为做开发也很多是身不由己。测试工作很多时间不需要编程？开发人员很多时间也不需要编程。后边的就不说了。总之，给人的感觉都是作者的心理。好像作者自己喜欢做开发，身不由己作了测试，发现不需要什么编程，然后就想方设法写程序，以显示自己也会编程，结果出了大问题了。这里可以提供两点信息，一是作者想做开发没有做成。可见作者的开发能力有限，老板不给提供这个机会，因为老板是要给产品负责的。还有就是，做了几年的程序，而且一直想转开发而转不过去的话，我真的不能suppose他水平有多高了。另外就是，把自己的心理，心态，引申到整体，不是很有道理。
用户不出问题是唯一标准？你可以认为它是一个标准，可是你怎么衡量？用户，半年不出问题，一年不出问题，还是五年不出问题，永远不出问题？还有就是，难道只能在用户的使用上才能衡量一个软件的质量吗？我们做测试的首要目的就是在用户拿到产品之前就要保证好产品的质量。难道，自动化测试，程序覆盖率不是实现这个目标的解决方法吗？一个人做的测试，自动化需要两，三个。这又是从何而来？以我的经验，三四个人的测试，我一个人做自动化就可以完成了。我前不久的工作成绩就是，本来需要3个星期手工测试的，经过我的自动化，变成1个星期完成了。也就是说，本来需要三个手工测试人员，现在只需要一个自动化测试人员了。还有就是，我们的软件需要在不同平台下，不同环境下测试，没有自动化怎么行？比如，我们要在2000，XP，XP+sp1,XP+sp2, 2003, 2003+sp1，2003+sp2,vista。这还不包括，这种cpu，windows的不同版本呢。手工测试得需要多少人呢
进行第二部分的时候，我想简单说一个问题。以我个人的看法，功能测试根据被测试对象主要可以分三种类型：UI测试，Command line测试和API测试。我认为后两部分是非常适合用自动化来作为主要方法进行测试的。作者只是提到了UI自动化，然后就推广到整个的自动化。我认为这不是很reasonable的。如果谁要是认为API和command line的测试不适合自动化，我们可以单独讨论。不过这里，我们就要把topic nail down了。我们只谈UI的自动化。如果我们要谈整个的自动化，作者的观点一下子就错了，没必要继续谈下去了。
作者在自动化过程中发现的问题，和犯下的错误是初学自动化的人很容易出现的。刚开始的时候，很多人都想把自己的自动化做的多么fancy,想100%的automation.把目标定得很高，结果又相差很大。因此，就动摇了自动化的信心。我做自动化总是强调的一点是，“怎样合理的进行自动化？”。什么应该自动化，什么不应该自动化，怎样进行自动化，这都是有一定学问的，也是一个senior测试人员应该具备的基本能力。因为作者的能力问题，使得后来的测试人员不愿意用他们的代码，宁可另起炉灶。这完全不能说明自动化有什么不好的。你想想看，如果你设计，实现了一套非常好的，非常灵活的自动化系统，后来的人很轻松的能够上手，他为什么还要自己重新来过呢？以我个人的经验来看，想另起炉灶的最根本的原因是因为以前人留下的代码太滥了。这个不光测试有这个问题，开发中同样普遍。我设计的自动化框架，到我辞职后一年还没有替代品的出现，大家都是在我的基础上进行新的开发和利用，以及扩展。这又说明了什么？我从来没有试图去说服别人一定要用我的。好的东西，别人一定会看到的。