在写一个测试计划，但是有些问题不是很清楚。刚刚在网上看到这篇文章。感觉不错，

http://mattarcherblog.wordpress.com/2008/07/24/how-much-detail-should-i-write-in-my-test-case/

我现在有点忙，等我写完手上的东西，我会写点体会。

上个星期就和我朋友ORLA约好去她工作的公司看看，今天下午终于成行。

google在Mountain View，和NASA不远。从 Amphitheater parkway 这条街看过去是看不到太多的标志。只在入口有一个比较明显的小石牌，写着Google, Building 40。而即便是走进，也看不到什么比较气派的东西。Google的大牌子是对着自己内部的建筑的，从这一点上说，它比很多公司都要低调。

我朋友在43号楼，我在大厅等的时候看到一面极大的投影屏幕，黑色背景，白色字，一行一行的不断跳跃。里面显示的是现在网上的人在这一秒钟输入的搜索关键字。看了几分钟，大部分是英文，但是也赫然看见一个中文的"Window xp 破解码"－－倒是令我颇为不好意思

朋友出来了，领我进大门。首先看见的是1:1比例的 spaceship one 悬空在一个宽敞的上楼楼梯上。楼梯是木头的，楼梯旁边是一个供应饮料的吧台。大概是因为刚好是中午，走动的人比较多。加上背景的颜色是典型的google的风格，给我的感觉不是走进一家上班的公司，倒是更象一个休闲中心。

Google里面的摆设也是不寻常。这里几乎看不到规规矩矩方方正正的工作间，多数的工作间是几个人公用一个很大的隔间。里面的摆设风格各异，桌子大大小小，高矮各不一致。我不见得喜欢他们的摆法，但是我相信这样布置应该是尊重个人的选择的结果，每个人都尽量让自己的工作环境变得最舒适，所以显得整体有些凌乱－－从这点上考虑，我是很喜欢的。一路看来，我觉得大楼里的最多的是两个东西：沙发和电脑。由于隔间很多是不规则的，加上建筑物本身大概也不是很规则，所以到处都是角落。而每个角落都有一圈沙发，有几个还有枕头。想来是很舒适的－－当然，到处也都是饮料的吧台。Google里面的层高很高，走动的空间很大，Orla 告诉我说好些大楼之间都是连起来的。我个人比较喜欢这点。我有一边走一边思考的习惯。空间比较大的话，让我感觉比较自由。其他的东西也很多，我看到了专门睡觉的机器，游戏机，个人游泳池，超大的健身房，厕所旁边的浴室，随便使用随便放置的自行车。。。总的感觉是两个词：different and comfortable

硬件虽然让人感到舒适和富足，但是让我感觉更加深刻的是它的软件的部分。

Orla带我走了几个大楼，就去了餐厅。附近有好几个餐厅，她推荐的是一家西班牙风格的。每一份都是小碟子盛的，很方便，更重要的是免去了不认识洋菜的尴尬－－老实说，味道真的很好。我也不知道我吃的是什么，只知道是一碟牛肉，一碟蒸的菜混的饭，一碟甜点。

Orla介绍说Google里面有很多不定时的演讲，有些是公司内部的人，有些是公司请来的。演讲的话题未必是和电脑有关。有时候是将怎么造一个机器人，有时候纯粹是一本和社会科学有关的书的作者过来和大家交流，有时候是歌星，据说Obama前几个星期还过来过一次；员工虽然不能够对外面公司的人说自己的项目内容，但是公司内部非常开放。成为正式员工的第一天，所有的项目就全部公开；自然还有一条就是每个员工都有20％的时间属于自己，可以做任何自己喜欢的项目；虽然不能说详细的内容，但是外界也不是一点都不知道，比如说GFS。我和Orla没有讨论任何和项目有关的细节，但是讨论之下我还是有些大体的概念。简单的说，往大里想就是了。读一个文件不难，但是同时读上万个上亿的文件就有些不同了，响应一个客户请求容易，但是同时响应成千上万的客户，然后每个请求是在成千上万的资料里面查找，而这些成千上万的资料在成千上万的服务器里面，而同时这些服务器又在地球的各个角落。。。只要想象一下这种设计背后需要面对多少难题，需要多大的智慧，实在是让人不免感到自己的渺小。而反观自己，我突然发现自己的思维经常局限于一些狭小的领域，视野不够开阔，而想象力似乎也正在失去。朦朦胧胧的我似乎感觉到很多儿时的梦想和野心似乎在这里可以得到实现。Google似乎真的提供了一个让你任意驰聘的舞台。

午餐之后我就离开了，据说Google每个周五的下午都有Party，但是Orla自己比较忙。回去的路上，我一直在想，也许我真的将来应该试一下这个公司，也许真的它有些不一样。Orla告诉我Google招人的程序很严格。而我自己心里也很清楚，现在的我是不够格的。我还有太多的东西要去学习。也许三五年之后我勉强可以试一试。但是无论如何，这次Google之行让我知道了世界上还有这么一块平台，一个似乎异常自由的天地可以让你将你的想象发挥到极限。

个人的成长是离不开平台的支援的。一个公司是一个平台，而且是个人发展的最大的平台。我们每个人都需要清醒的知道自己适合什么样的平台，什么样的平台适合自己。就我个人而言，我需要的不是换公司，而是如何在公司里面将自己培养起来。盲目的调换是没有意义的，但是到了该换的时候，还是要走。

对于软件而言，是不是bug越少，它的质量就越高呢？

今天在写一个软件的安装和卸载的测试计划，面临这么一种情况：如果用户强行中断安装，那么系统将处于一个不稳定的状态，这种情况下，如果重新安装无法成功的话，这是不是一个Bug呢？延伸开来，如果用户没有按照设计的规定程序进行操作而导致软件出现“问题”。那么这种问题，是否就是“bug“呢？再延伸得更加广泛一点，究竟什么才是“bug“的准确定义呢？是不是只要是软件出现了问题，就是有bug呢？bug的定义直接影响到测试计划需要要包括的具体内容。这个问题其实是一个非常基础也非常重要的问题。

刚刚和做客户服务的人聊天，才发现自己对这个问题其实还是没有太清楚的认识。不过聊天之后，自己在电脑面前发呆良久，我才发现我自己其实是人为的将问题复杂化了。我在潜意识里面将软件质量的高低和bug的多少直接联系了起来。而事实上，这两者是没有任何关联的－－没有一丝一毫的关联。

简单的说，bug是相对于PRD (Product Requirement Document)而言的。是以产品需求说明书里面规定了的操作和操作的结果为基准的。如果按照PRD的说明进行的合法操作的时候出现了问题，那么这个“问题”就是一个“bug“，否则就不是。如果PRD里面规定了，软件只能在某些环境里面安装一次，那么用户的重复安装无法成功反而是一个正确的结果。如果PRD里面规定了，用户可以反复安装，那么上述问题就是一个BUG

软件质量则是由软件设计来决定的。如果用户习惯于在同一个页面输入用户名和密码，而设计者设计成用户需要在不同的页面输入两次用户名和三次密码，那么这种重复不是一个bug，但是用户会觉得软件不好用，或者说“质量不高”

所以没有BUG的软件不一定是高质量的软件，高质量的软件也不一定没有BUG。质量的好坏，从某种程度上来讲是一个主观的判断，虽然它也有一些定量的部分（比如说软件的反应速度等等）

既然选择了不准备长篇大论，我就谈谈这方面的实际体会。

测试程序的设计和其他应用程序的设计最大的不同在于这些方面

• 不求完美
• 不厌其烦
• 结构清晰
• 逻辑简单
• 独立运行
• 目的单一
  

不追求完美。测试程序很多时候是在一个已知的环境里面运行的。所以我们不需要我们的测试程序能够在任何状态下都运行无误，从这点上来讲，测试程序允许有bug存在，甚至允许有很多Bug存在，只要能够完成测试目的

不厌其烦，测试程序需要反复验证数据的变化，测试前，测试后的数据比较是最起码的，最好是在每一个步骤执行后都能够验算一次

结构清晰：我写测试程序通常是下列结构，这个结构已经很长时间没有变化了

1. 测试环境配置  （1）读入配置文件 （2）配置测试环境 （3）验算配置环境 （4）有任何错误，退出程序
   
2. 配置测试初始值 （1）配置初始测试状态 （2）验证初始值 （3）有任何错误，退出程序
3. 开始测试
4. 检测测试结果 （1）检测测试后目标程序的数据变化（2）和预期的数据进行比较
5. 打印测试报告
6. 清除测试数据

逻辑简单：逻辑简单才能让debug的工作简单，毕竟测试程序通常都需要在比较短的时间里面写出来。代码稍微长一点问题不大

独立运行：面对用户的程序往往需要依靠外在的程序才能正常运行，比如网站通常需要有数据库匹配，但是对于测试软件而言，这种依托最好是0。也就是说，任何人在拿到测试程序之后，不需要任何其它辅助软件就能够直接运行。

目的单一：只有测试的目的单一才能让程序变得简单。宁愿多写一个很类似的测试程序，也不要用一个测试程序达到多个目的。

上面所有的原则都是为了两个目的：

1. 力求测试的正确性
2. 便于今后的维护

从关于logging的日记中可以看到自己的思考有些凌乱，不够系统。主要原因是因为这篇关于logging的文章是有感于我现在的手上的项目而发的。所以思考有些不正常的跳跃。从大的方面来讲，logging不过是测试软件开发这个整体里面的一个局部而已。它应该属于从属的地位。希望不要引起误会。

我想我尚不足以写有太多理论深度的东西，因为水平不够。我也不喜欢泛泛而谈的东西，而就我个人的经验来讨论这些问题反而比较好。

写测试程序，第一个碰到的实际问题就是选择什么样的语言来编程。就我个人感觉而言，选择的语言需要考虑下面两个主要因素：
1。可移植性
2。可维护性

可移植性高，所以写出来的测试软件可以在很多不同的环境里面运行，从这个方面来说，perl，python和java都是不错的选择。我写很多shell scrīpt，这时候ksh是相对比较好的选择。

可维护性是另外一个很重要的因素。这个算是我的教训。我写过一些API自动测试程序，当时我用的是JAVA。结果等我离开那个项目，接手的人并没有太多的编程经验，他花了好一段时间去熟悉我写下的程序，最后因为我的程序比较复杂而最后放弃了。这里面固然有我设计不合理的原因，但是我当时没有选择perl这个比较简单的语言也是一个很重要的原因。作为QA，我现在理解到，我们QA写的程序不仅仅是给我们自己的。我们写的程序很多时候要交给其他人使用或者维护。使用比较广泛适用和比较容易上手的语言是一个合理的选择。语言简单，我们的测试程序就不会太过于复杂。为后人（包括自己）持续使用和维护降低了门槛。

另：我不熟悉LoadRunner，没有资格评论这个。

自动化测试软件和其它的软件的最大的不同就在于其目的性：自动化测试软件的目的是为了检验其它程序。由此一般来讲，自动化测试软件的logging需要有两个独立的部分：

• 自我程序的执行的检测
• 被测试程序的执行的检测

明确了这个大的方向，logging的细化就比较容易了：

自我程序的执行的检测一般需要包含下列部分：

1. 记录程序的执行－－程序的自我执行顺序，包括初始数据，测试数据，执行步骤，目前执行状况和最后的执行结果等
2. 记录程序的逻辑－－这里的逻辑应该是指测试的逻辑之所以将这部分单列而不是放在第一项，主要是因为测试程序的特点：任何下一个步骤都必须是预知的，不允许出现例外的情况。任何例外，基本上都属于BUG的范畴。这个BUG，要么是我们自己的测试程序里面的BUG，要么是被检测的程序的BUG
3. 记录测试数据的变化－－数据的变化是QA最重要的检测手段。作为从属于第一和第二的部分，单列出来可以让程序检测变得更加清晰
   

被测试程序的执行的检测一般包含下列部分

1. 测试开始前的被检测程序的初始状态：主要是至初始数据
2. 测试执行过程中的数据变化：这个变化过程同样是必须符合预知估计的，任何不同都意味着BUG存在的可能
3. 测试执行完成之后的数据状态：主要用于比较初始状态以确认测试执行的结果。

当然，不同的测试目的也一定会导致logging的不同。比如说我们进行的是系统的performance 测试的时候，我们就需要加入对时间的计算。但是无论是何种目的，logging都需要，也应该包含以上两个大的部分

logging是任何程序都少不了的部分，但是我很少看到有关这方面的论述。学校的老师几乎从来都没有涉及到过这个领域。即便是最正规的编程书籍里面也找不到有关这方面的论述。但是就我看来，至少对于QA，logging是非常重要的了解程序的内部结构的手段之一。当我们自己写测试程序的时候，对logging有正确的理解是非常重要的。

在我看来，logging大概有下面这些目的：

• 记录系统活动 record of system activities  (general purpose):
  
• when did it happened, what was happened, and what is the activity result
• 记录程序的执行 （用于排除程序错误，只要是开发人员使用）trace of program executiong
• debugging -- for variable changing
  
• 记录程序的逻辑 trace of  logic (like business logic)
  
• debugging
• proof of program logic execution
  
• 记录对系统的攻击 （主要用于安全领域） trace of attack
• security
• 作为程序的一个功能部分而存在（比如所有的数据库软件都有一个重置的恢复日志）part of program function
• such as database logging:
  
• undo log
• redo log
• 记录程序的执行效率，performance calculation 
• 其它我不知道的
  

多数情况下，log是开发人员为了自己排除错误和记录系统活动而设置的。log在传统上的目的，是为了开发人员自己和程序的使用者－－和我们QA没有任何直接的关系。但是当我们编写自己的测试软件的时候，这种传统的思维必须改变。QA编程时的log，还需要考虑我们QA的特殊需要。
（待续）

写自动测试软件有一段时间了，也慢慢的感觉到写自动测试程序和普通的编程有很大的不同。这些不同，不仅仅体现在编程语言的选择，编程的风格，编程的设计和实现上，也体现在诸如logging，reporting等等这些细小的方面。

我现在的思考还有些不够系统，只好慢慢的将自己的经验和体会记录下来，等积累到一定程度，也许可以写一篇比较长的系统的文章。

我以为我很清楚，但是当我坐下来准备写写这方面的体会的时候，我才发现原来我其实也并不清楚。或者说没有我想象中的清楚。

在网上我找到很多人云亦云的讨论，似乎每个人都很了解我们为什么要测试软件，但是这些大而空泛的言论其实更多的是纸上谈兵，写这些指导理论的人究竟有多少测试软件的经验是值得怀疑的－－有一点我很清楚，软件测试领域其实还是在一个初级摸索的阶段。很多关于软件测试的理论还没有被发现。行业里面的人更多的是对自己过去的经验的总结。而这些经验在一段时间之后因为软件行业的变化而慢慢的失去实际意义了。

一个行业，如果没有健全的理论体系，终究是难以有太大的发展的。手工作坊式的传帮带需要改变－－这是我的感觉

电脑是基于1和0的，没有中间状态。我们的测试结果也应该是如此：通过或者不通过。但是当我回头看看我曾经做过的测试，我发现我原来很多的失误是因为我在测试之前不清楚我的这个测试的目的，模模糊糊的希望在一个测试里面达到多个目标。这样的后果就是浪费了大量的时间和精力而没有丝毫的进展。

软件测试的对象－－无论是应用软件，系统软件还是一个网站－－总是包罗万象纷芜复杂的。所以我们的测试也必须是多方面的。除了最基本的单元测试（这部分应该是开发人员的工作，不过好像很多人也没有做到），QA需要做诸如界面测试，模块功能测试，系统功能测试，产品安装／卸载／升级测试，API测试，系统稳定性测试，压力测试，Performance 测试，和其它产品的兼容性测试等等等等。。。但是无论是何种测试，也无论是用什么方法测试，测试的一个重要原则应该是，对于每一个单项的测试，它的目标应该是唯一的。测功能的时候只需要考虑测试对象功能是否完备，是否存在缺陷，而不要顾及诸如反应速度，内存耗费等等似乎垂手可得的相关资料。在测试系统稳定性的时候，我们只需要考虑系统在长时间运行的时候的容错能力，也不能考虑内存损耗和系统反应速度。只有当我们在做Performance 测试的时候我们才考虑这些内存，反应速度－－而不考虑系统对错误数据的处理能力。

目标单一则设计简单，结果清晰。否则是浪费时间和精力。QA是一个大量的细致的稳打稳扎的工作，不能心存侥幸。从这个方面讲，QA对人的素质的要求很高。QA的工作质量更多的取决于人的素质。

说老实话，我不觉得我合适讨论这个题目，毕竟我入行的时间也并不长，4年而已。但是最近看到两篇关于职业规划和薪资讨论的文章，觉得自己也想说一说。

对于薪资，我觉得应该市场这个角度来看。如果员工的跳槽没有受到太大的限制，那么这就是一个开放的市场，而对于一个开放的市场，一个员工的价值和他的薪资大体是对应的，不会有太大的出入。如果你抱怨老板给的薪水太低，那么你需要考虑的不是这个老板有多奸诈，而是你是否值更高的价格。总是将原因归咎于外在因素不过是不成熟的一种表现。延伸开来，我们更应该考虑的是我们的能力是否得到提高而不是薪资。做事和赚钱的关系很多人都颠倒了，事情做好了，钱自然就来了（否则你就跳槽了）。永远盯着钱跑不过是一种短视的投机行为而已。

同样的理论，职业规划也应该是从能力的提高而不是工资的提高的角度来考虑－－钱是必须要考虑的，但是作为长期的职业规划，收入是从属于能力的提高的，如果主次颠倒了，很容易迷茫。同时软件测试工作是个技术活，如果你觉得你的目的是利用QA作为跳板，最后达到自己开公司或者从事纯粹的商业管理的阶层，那么我不觉得我能够提供任何的建议，因为我不懂。我能够说上一点点的，是QA的职业规划。

从技术的角度来讲，QA的职业规划其实不复杂，它其实取决于你对软件行业的了解。大体来讲，软件有三大类：
基础件Infrastructure software (such as Linux OS, Storage software...),
中间件 Middleware (such as IBM Websphere, BEA Weblogic, Oracle DB ...)
和用户件 Consumer product (such as MS Word 用友财务软件, 搜狐 ...)

软件测试人员的能力也分三个层次：表层，中层和核心部分［这几个是我自己捏造的说法，姑且称之］。

表层是指用户界面的测试。网站的网页的界面是最容易理解的，但是对于很多中间件的软件而言，比如说ORACLE DB，他们也有很多软件是有用户界面的，当然这里的用户不是上街买菜的大婶。界面测试的技术含量比较小。并不需要太多的专业知识，这大概是很多人觉得QA不够有技术含量的原因。

我说的中层的测试多数是指功能测试和API测试。这个时候，软件测试就更多的依赖于对软件核心功能的理解了。这个层次的测试更多的是自动化测试－－无论是用专业的测试软件还是自己写测试工具。我现在应该在这个层次。我相信大部分QA也不过是这个层次，区别在于对测试工具的掌握程度和各自的编程能力。

我想象中的核心的部分的测试更多的是白盒子测试。不要以为这个很容易，至少到目前为止我还没有看到有几个人可以做到。我已经做了一年左右的research，我还没有看到太多这方面的权威资料，也暂时不知道该如何进行（望不吝赐教！）

从技术层面来讲的职业规划到这里其实已经很清晰了。明白自己在那个层次，了解将来自己可以往什么层次发展是第一部，然后就是需要找到通往下一步的路－－这条路要找到不是很容易的，唯一找到这条路的方法就是不断学习提高，从而让自己能够迅速的从更深刻的层次了解自己需要测试的软件。

职业规划当然不能只有技术的部分，人性也是必须考虑的因素。这里的人性，是指自己对自己的了解。有些人天生就喜欢技术，有些人天生就不喜欢，有些人介于这两者之间。有些人就是能迅速理解技术，有些人没有这方面的天赋。QA的将来并非只有做技术一途。事实上，QA的职业发展比做纯粹的开发更加广阔。
－－ 因为QA需要接触的是全部的代码，所以QA需要对开发项目有更全面的了解，所以QA比开发人员更容易做好PM（项目经理）的工作
－－ 基于同样的原因，在具备了一定的开发经验之后，QA更容易也更胜任架构工程师的工作
－－ QA的工作的一个很重要的组成部分是和别人沟通，所以QA很容易转到做用户需求的领域，等于是一脚迈入产品设计的大门
－－ 基于同样的原因，QA做产品的技术支援是最自然的过度，技术支援再往上走就是专业的顾问公司了

总而言之一句话：做好职业规划需要对技术和自己有深刻的了解

昨天花了一些时间看了看51testing上面很多人的博客。最深的感觉是这里好像很多人用LR等基于微软操作系统的工具软件。很多人都在不亦乐乎的相互传授对不同工具软件的经验。我不是反对使用工具软件，但是我觉得过多的依赖于工具软件实际上是非常有害的。或许可以这么问一句：离开了工具软件你还能测试吗？

又或者换成另外一个逻辑：
QA测试依赖工具软件，工具软件依赖于开发公司，开发公司依赖于开发人员，开发人员依赖于QA－－所以绕了一个大圈子，一个过分依赖于测试工具软件的人最终是依附于另外一个QA而已。

这种情况如果不能尽快改变的话，被淘汰是应该的