日历
| |||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | ||||||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 | |||
| 12 | 13 | 14 | 15 | 16 | 17 | 18 | |||
| 19 | 20 | 21 | 22 | 23 | 24 | 25 | |||
| 26 | 27 | 28 | 29 | 30 | 31 | ||||
搜索标题
最新来客
统计信息
- 访问量: 444
- 日志数: 5
- 建立时间: 2007-08-21
- 更新时间: 2008-02-29
RSS订阅
我的最新日志
-
单元测试用例与详设的同步
2008-2-29
很多朋友们，都提出过目前的单元测试用例（UT）同实际测试工作脱钩的问题，我亦深有同感。在目前的测试执行工作中，我更多的是依据详细设计文档（LLD）来进行测试的，而非单元测试用例（UT）。
为什么会出现这种情况呢？由于单元测试用例（UT）往往写于“开发工作 ”完成之前。因此，UT的编写工作同单元测试执行之间，往往存在一定的时间差。而就在这段时间差内，详细设计文档（LLD）一般会进行修改，内容发生了的变化。这样就导致了“设计文档”、“产品”同“测试文档”产生了偏差，无法再基于“测试文档”对“产品”进行测试，成了摆设。这么说来，测试人员更愿意依照设计文档（LLD）来执行测试工作，也就理所当然了。
但是，由于LLD文档属于设计文档，而非测试工作的指导文档。因此，基于LLD文档的测试工作往往更具随机性，容易产生漏测得现象。（在回归测试中可能更多的会使用随机测试方法。）而基于UT文档的测试执行，则可以贯彻最初的测试设计思路，更好的保证测试执行的完整性和连贯性。
那么，如何保证“UT文档”同“LLD文档”的一致性呢？现在测试人员的工作已经很繁重，故而很难保证随时更新UT文档。这一方面是由于工作进度的压力造成的；而另一方面，由于我们工作方法存在一些待改进的地方，也影响了我们的工作效率。
如果，我们能够在以下方面做些改进，虽然不能完全解决上述问题，但是可以让UT同LLD的对应工作变得相对简单一些：
首先，我们的“UT文档”是基于“LLD文档”设计的，而每一条测试用例，并没有标明其对应得“LLD文档”出处。这对于修改一篇拥有几百条用例的“UT文档”而言，是致命的。这导致我们在发现LLD文档被修改之后，很难定位与“LLD修改部分”对应的“测试用例”。
因此，如果能够在UT中的每一条测试用例后面，加上对应得LLD文档出处，就很容易在修改UT 时候找到对应得LLD部分。（针对前台的测试用例可以对应到相应的页面，针对后台的测试用例可以对应到相应的Method）
第二，测试和开发 人员往往不能够及时得知“LLD文档”的修改情况。很多LLD文档在修改之后，并没有通知相应得开发和测试人员，也不标注出修改过的内容。这对开发和测试人员来讲，简直就是灾难。他们要花很大的精力，去搞明白文档到底改过了什么。
要解决这个问题，恐怕就需要我们的设计人员再多费点心了，把每次的修改和修改过内容通知给开发和测试人员。也可以由设计组内部汇总，将每日的修改内容总结打包，通知开发组和测试组。
（当然，如果能够建立完善的版本和每日构建体系，则可以更好的解决这个问题。） -
测试语句的标准化和模型化
2008-2-29
我们在测试过程中可能会发现，很多程序操作拥有类似的功能或结构，其对应得SQL测试语句也是类似的。因此，如果能够将测试各种程序功能所对应的SQL测试语句总结出来作为范例，就可以将测试人员的劳动成果固化下来，实现语句复用，提高测试效率。而且这种范例有助于选择最优化的测试语句，淘汰或改进有缺陷的测试语句，提高测试语句的准确性。那么，如何针对我们的测试对象总结测试语句呢？我想大致的步骤有以下几点：
1、总结程序中的主要功能
对于某一项目而言，其主体的设计思路、功能算法，往往都有很高的相似性。我们可以对其主要功能进行分析，找出其中近似的功能，并加以归类。
2、对归类的功能进行算法分析，设计出相应得SQL测试语句模型。
在这里应当注意的是，测试语句和程序语句之间的不同：程序语句的目的是用来实现程序功能；而测试语句的目的则是验证程序语句的正确性。
3、建立良好的模型更新机制，随时改进模型。
建立SOL语句模型的目的是为了，在工作中更方便、快捷、正确的设计测试用例。但由于模型设计不可能是完美的，这就需要不断的对其进行更新、完善，以保证SOL语句模型能够紧扣实际工作。
比如说，程序针对数据库操作的主要功能就是：读取、插入、修改、删除等几种。我们就可以根据以上几种操作，做出相应的测试语句模型。
以删除功能为例，通过两个语句就可以判断应该删除的语句是否已经被删除：
测试语句A:
SELECT COUNT( ) FROM [目标数据库]
WHERE [删除条件]
测试语句 B:
SELECT COUNT( ) FROM [目标数据库]
WHERE [删除条件]
我们在程序的删除功能执行之前，先执行测试语句A，得到了符合删除条件的记录条数。然后程序执行删除操作，删除对应记录。接着执行测试语句B，得到删除操作执行之后数据库中符合删除条件的记录数。如果删除功能正确，则B的结果应该等于0。而用A结果减去B结果，则可以得出删除记录的条数。
但是仅仅凭以上两个语句还不能完全测试[删除]功能的正确性，因为以上两个语句仅仅证明程序删除了对应记录， 即：“程序做了它该做的工作”；但是并没有证明程序没有删除不该删除的记录，即：“程序没有做它不该做的事情”。要想证明这一点，我们就需要再添两条语句：
测试语句C:
SELECT COUNT( ) FROM [目标数据库]
测试语句 D:
SELECT COUNT( ) FROM [目标数据库]
在程序的删除功能执行之前，执行测试语句C，就可以得到删除操作之前目标数据库的所有记录条数。在程序执行删除操作之后，执行测试语句D, 就可以得到删除操作之后目标数据库的所有记录条数。
执行以上4条语句的结果，应该满足下面的条件表达式：
(A-B==C–D) &&(A>=B)&&(C>=D)&&(B==0) (A、B、C、D代表语句A、语句B、语句C、语句D的执行结果)
通过以上的例子，我们总结出了测试Delete操作的SQL测试语句模型。它不但实现了语句的复用和标准化，更重要的是这个模型为我们提供了一个测试 判定标准：可以最终被转化为一个确定的逻辑值（T/F）得条件表达式。 -
模块间耦合部分的测试
2008-2-29
所谓耦合就是指两个实体相互依赖于对方的一个量度。耦合依赖于模块间接口的复杂度、引用或者引进其他模块的方式、以及什么数据通过接口传递等
在计算机系统中，两个不同模块之间往往存在不同程度的耦合。由于需要两个或者多个模块之间相互协同工作，因此计算机系统的耦合部分，往往是容易产生BUG的部分。因此，在模块耦合度较高的系统之中，往往存在较高的缺陷率。
在集成测试过程中，我们应该特别注意，模块间的耦合部分。
举个例子说吧：某系统中有一个090模块。090模块被147模块调用，090的主要功能是对数据库中的TBL_001的C字段进行修改。147模块在090修改数据库后，还会读取TBL_001中被090修改的C字段的内容。如果同时存在一个模块091，也对TBL_001库的C字段进行修改，那么我们就可以认为090和091模块存在公共耦合。
如果不考虑090、091两个模块之间的集成，而仅仅对这两个模块做独立的功能性测试，很可能不会发现问题。但是，如果进行以下操作，问题可能就产生了：
1、 运行147模块，并调用090模块。
2、 090模块通过运算，将[结果集A]写入数据库TBL_001的C字段中。（此时147还未从TBL_001种读取[结果集A]）
3、 此时091模块也被执行，并将[结果集B]写入TBL_001的C字段中。
4、 147模块从读取TBL_001种读取C字段中的[结果集B]。
我们可以发现，如果按照程序设计者的意图，147应该读取被090修改的[结果集A]，但是由于091的执行，导致147错误的读取了[结果集B]。因此在我们的测试中，除了要对090和091模块的功能进行测试之外，还需要对090、091之间的结果耦合部分进行全面测试。 -
关于针对Detail Design（DD、LLD、详细设计）的同行评审
2008-1-11
同行评审（Peer Review）：是一种通过作者的同行来确认缺陷和需要变更区域的检查方法。其主要类型包括：正规检视、技术评审、走读等。
在Detail Design（DD）完成后，开发人员会按照DD的设计要求进行开发，而测试人员会按照DD的要求进行测试用例设计。因此，DD的设计是否完善、无重大缺陷；开发、测试人员是否深入的了解了DD的设计内容和设计思路，都直接关系到该模块的生产进度和产品质量。
那么怎样才能够完善模块的Detail Design（DD），并让开发、测试人员正确的贯通设计人员的思路呢？其实针对DD的同行评审可以有效地解决这个问题。
针对DD同行评审的主要目的是检查和确认设计缺陷，它可以在模块开发周期中的较早期阶段清除设计方面的缺陷。就缺陷修复的成本而言，在开发工作开始之前就清除框架设计方面的缺陷，其修复成本是较低的。而且这个检查和确认的过程，对评审的参与人员了解整个评审模块也是很有帮助的。让参与的开发人员清楚地确定，自己应该做出什么样的软件；同时也让测试人员确定自己所需要测试的内容。
那么同行评审的主要参与者，都应该是哪些角色呢？
试问，在一个软件项目团队中，除了DD设计人员自身之外，谁对DD的优劣最有发言权呢？有人可能会说是DD的Reviewer。诚然，DD的Reviewer往往是团队中比较有经验和发言权的“牛人”级角色，但是由于角色的限定，其对DD的审查往往是走马观花式的框架把握，而对于细节问题往往予以忽略。其实，对于一份DD文档质量优劣，感受最深的往往是工作在DD层下游的开发、测试人员。他们的工作，直接依照DD进行，DD文档的质量直接影响到他们实际的工作效率和产品质量。因此，各模块的开发、测试人员应该参与自己所负责模块的DD评审，并根据自己的工作需要，对DD提出相应的意见。但是，由于专业知识得限制，开发和测试人员不一定能够对“模块基本构架的合理性”提出实质性的意见，因此如果条件允许，还可以邀请一两位对程序框架设计有经验的专家，参与框架的评审。
除了保证DD设计质量外，同行评审可以给设计、开发、测试人员一个跨组交流的机会；同时也可以从“设计”、“开发”、“测试”等不同的角度来对整个模块设计的合理性提供意见；另外，相关人员汇聚到一起进行同行评审，可以较好的了解模块的相关背景，避免了日后繁琐的交流，减少了“因为对项目设计思路的理解不一致，而产生错误”的可能性。
如何进行针对DD的同行评审呢？
由开发和测试人员参与的DD同行评审，可以以“走读”为主；在有程序框架设计经验的专家参与的情况下，也可以进行“技术评审”。
所谓“走读”，其主要是对文档进行检查，通过走读发现文档中存在的缺陷（可能包括逻辑矛盾、描述模糊和文法错误等），同时参与人员也可以进行技术交流，初级人员也可以学习一些技术方面的知识，了解设计者的思路。所谓“技术评审”是一个相对正式的评审过程，其在规格、标准等方面进行评审，并在评审后给出相应得修改意见。
同行评审由专门的组织者主持，并有作者和相关同行出席。其规模不宜过大，大致可以控制在三到六人。在会议过程中，可以先由作者对其DD进行讲解，引导大家进行走读。然后参与者们共同对DD进行评审，确认问题，并对其进行分类。
一般情况下，同行评审可以被控制在两个小时之内。一些简单的模块，可以把同行评审压缩到一个小时之内。在评审过程中，如果遇到问题需要延时，可以由作者决定是否召开“第三小时会议”。评审结束后，有必要对评审问题进行跟踪，以便确认确陷的到了修改，并且没有引入新的缺陷。
-
关于周日英文测试公开课有感
2008-1-07
关于周日英文测试公开课有感
上周日，有幸参加了51Testing举行的英文测试公开课，感觉收获不少，把自己的感想，总结一下，跟大家分享。
Jason 老师给我们带来了一天精彩的英文讲解，首先在此对他表示感谢。
这次英文公开课，所讲述的内容比较简单，主要都是51课程内的一些测试基础知识。其主要的亮点，是把这些内容以英文的形式表达出来。我想，对于51大部分学员来说，英文测试是一个比较有难度的挑战。很多理论方面的东西，对我们而言是不难的，但是我们无法准确的用英文将我们的测试思想清楚地表达出来，甚至也无法顺利的阅读测试相关文档，了解我们所需要了解的。我认为这遭成这种尴尬现象的主要原因，是我们对于专业英语接触不多，缺乏专业英语环境造成的。（当然更深层次的原因可能是大家内心中对专业英文学习的不重视！）因此，我认为在我们的测试课程中适当引入英文课程，可以对我们同学的专业英文学习，提供有效的方向指引。
其实，英语学习并不难，关键是平日里多听多练，再就是敢想敢说得自信心。这些东西并不是一两节英文课程所能提供的。但是，这种测试英文呢课程，可以为我们同学提供一些引导和提示，让同学们知道自己在英文方面的缺点在那里，下一步应该向那些方向去提升自己的英语能力。我想我们大部分同学的英文功底是好的，毕竟大学四年都过了四级。但是一但涉及到专业英语和口语表达就不行了。要想提升这些东西，必须靠思想重视、平日积累、多记多练。
＂计算机专业英语＂并等同于个人的英语能力，很多人英语可能过了六级，英语基础很好，但专业词汇的积累几乎为零，那么他就很难用英文表述自己的专业知识。记得，在第二阶段末期的模拟面试中，面试老师一时兴起，让我用英文谈一谈对软件测试的认识。我顿时语塞，想来想去竟也不知道该说些什么！这件事情对我触动很大，当晚回去，便开始收集测试方面的英语词汇和文章，之后每有闲暇，便拿出来高声朗读。未曾想在第四阶段结束后参加的几次面试时，英语面试均过关，未成牵绊。我想，其实在这一个月的学习过程中，我的英文基础并无太大提升，但是测试方面的文章读多了，常用的词汇也熟悉了很多。这样便可以如使用中文般的，流利、自然、自信的表达自己所想表达的东西。
至于纯英文授课，我认为课程的时间有些久。英文授课不同于中文课程，由于大部分同学并没有建立起纯英文的思维能力，他们都是先在脑中把英文翻译成中文，在进行学习。这样无形中便增加了大脑的运算负担，很容易疲劳。这样一来，下午的课程效果便很差。因此，如果老师的时间安排允许的话，建议把一整天的课程，分散到两个上午来进行。上午，大家的精神都比较好，能够较好的理解和记忆课程内容。
另外，我个人的观点认为：学习这种英文课程，不需要在乎课堂上听懂了多少，关键在于是否能够融入一个英文的学习环境。就好像我们儿时学习汉语一样，只要时时刻刻的听与说，自然就会学会并使用。
Jason老师在讲课时所用的英文，其实已经很简洁明了，但我也只能听懂五成。不过我认为能够“五成”的收获已经很不错了～只要坚持多听、多说、多背，日久天长，我们终会像Jason老师一样，能够熟练的运用英文进行我们的测试工作，我们大家的薪水也会像我们的英文水平一样水涨船高！