在新的环境，感觉到比以前测试要正规点，关键是不像以前那样，只做页面的点击手了，嘿嘿，还要自己到包中查找SQL。看来多学点东东还是有好处的，起码看起来比较专业

 从07年毕业到现在一直在做测试，也从开始的激情到了现在的迷茫，感觉现在还不如刚毕业时知道的东东多，感觉什么也不会似的，想想以后不做测试了，自己还能做什么？？？天知道，好像找不到个人的兴趣点，好无力，

最近想学自动化和性能测试，刚开始还信心十足，但学到一定程度发现还得要编程，晕菜，又卡脖子了，怎么办怎么办？

是继续学习还是想想第二职业，为以后的发展作准备，虽然网上测试传的是如何 前景大好，但中国的测试环境又是别外一回事，在测试的路上还能走多远？心里没底，哎，日子过得好无聊呀

如何写测试人员的周报(或日报)

上一篇 / 下一篇  2009-08-17 20:58:06 / 个人分类：实践实战

   一、 环境配置测试
　　 （1） 网络连接是否正常
　　 （2） 网络流量负担是否过重
　　 （3） 软件测试平台是否可选
　　 （4） 如果（3），是否在不同的软件测试平台进行软件测试
　　 （5） 所选软件测试平台的版本（包括Service Pack）是否正确
　　 （6） 所选软件测试平台的参数设置是否正确
　　 （7） 所选软件测试平台上正在运行的其它程序是否会影响测试结果
　　 （8） 画面的分辨率和色彩设定是否正确

　　 二、 代码测试
　　 A． 静态测试
　　 （1） 同一程序内的代码书写是否为同一风格
　　 （2） 代码布局是否合理、美观
　　 （3） 程序中函数、子程序块分界是否明显
　　 （4） 注释是否符合既定格式
　　 （5） 注释是否正确反映代码的功能
　　 （6） 变量定义是否正确（长度、类型、存储类型）
　　 （7） 是否引用了未初始化变量
　　 （8） 数组和字符串的下标是否为整数
　　 （9） 的数组和字符串的下标是否在范围内（不“越界”）
　　 （10） 进行数组的检索及其它操作中，是否会出现“漏掉一个这种情况”
　　 （11） 是否在应该使用常量的地方使用了变量（例：数组范围检查）
　　 （12） 是否为变量赋予不同类型的值
　　 （13） （12）的情况下，赋值是否符合数据类型的转换规则
　　 （14） 变量的命名是否相似
　　 （15） 是否存在声明过，但从未引用或者只引用过一次的变量
　　 （16） 在特定模块中所有的变量是否都显式声明过
　　 （17） 非（16）的情况下，是否可以理解为该变量具有更高的共享级别
　　 （18） 是否为引用的指针分配内存
　　 （19） 数据结构在函数和子程序中的引用是否明确定义了其结构
　　 （20） 计算中是否使用了不同数据类型的变量
　　 （21） 计算中是否使用了不同的数据类型相同但长度不同的变量
　　 （22） 赋值的目的变量是否小于赋值表达式的值
　　 （23） 数值计算是否会出现溢出（向上）的情况
　　 （24） 数值计算是否会出现溢出（向下）的情况
　　 （25） 除数是否可能为零
　　 （26） 某些计算是否会丢失计算精度
　　 （27） 变量的值是否超过有意义的值
　　 （28） 计算式的求值的顺序是否容易让人感到混乱
　　 （29） 比较是否正确
　　 （30） 是否存在分数和浮点数的比较
　　 （31） 如果（30），精度问题是否会影响比较
　　 （32） 每一个逻辑表达式是否都得到了正确表达
　　 （33） 逻辑表达式的操作数是否均为逻辑值
　　 （34） 程序中的Begin…End和Do…While等语句中，End是否对应
　　 （35） 程序、模块、子程序和循环是否能够终止
　　 （36） 是否存在永不执行的循环
　　 （37） 是否存在多循环一次或少循环一次的情况
　　 （38） 循环变量是否在循环内被错误地修改
　　 （39） 多分支选择中，索引变量是否能超过可能的分支数
　　 （40） 如果（39）,该情况是否能够得到正确处理
　　 （41） 子程序接受的参数类型、大小、次序是否和调用模块相匹配
　　 （42） 全局变量定义和用法在各个模块中是否一致
　　 （43） 是否修改了只作为输入用的参数
　　 （44） 常量是否被做为形式参数进行传递
　　 B 动态测试
　　 （1） 测试数据是否具有一定的代表性
　　 （2） 测试数据是否包含测试所用的各个等价类（边界条件、次边界条件、空白、无效）
　　 （3） 是否可能从客户那边得到测试数据
　　 （4） 非（3）的情况下，所用的测试数据是否具有实际的意义
　　 （5） 是否每一组测试数据都得到了执行
　　 （6） 每一组测试数据的测试结果是否与预期结果一致
　　 （7） 文件的属性是否正确
　　 （8） 打开文件语句是否正确
　　 （9） 输入/输出语句是否与格式说明书所记述的一致
　　 （10） 缓冲区大小与记录长度是否匹配
　　 （11） 使用文件前是否已打开了文件
　　 （12） 文件结束条件是否存在
　　 （13） 产生输入/输出错误时，系统是否进行检测并处理
　　 （14） 输出信息中是否存在文字书写错误和语法错误
　　 （15） 控件尺寸是否大小适宜
　　 （16） 控件颜色是否符合规约
　　 （17） 控件布局是否合理、美观
　　 （18） 控件TAB顺序是否从左到右，从上到下
　　 （19） 数字输入框是否接受数字输入
　　 （20） （19）的情况下、数字是否按既定格式显示
　　 （21） 数字输入框是否拒绝字符串和“非法”数字的输入
　　 （22） 组合框是否的能够进行下拉选择
　　 （23） 组合框是否能够进行下拉多项选择
　　 （24） 对于可添加数据组合框，添加数据后数据是否能够得到正确显示和进行选择
　　 （25） 列表框是否能够进行选择
　　 （26） 多项列表框是否能够进行多数据项选择
　　 （27） 日期输入框是否接受正确的日期输入
　　 （28） 日期输入框是否拒绝错误的日期输入
　　 （29） 日期输入框在日期输入后是否按既定的日期格式显示日期
　　 （30） 单选组内是否有且只有一个单选钮可选
　　 （31） 如果单选组内无单选钮可选，这种情况是否允许存在
　　 （32） 复选框组内是否允许多个复选框（包括全部可选）可选
　　 （33） 如果复选框组内无复选框可选，这种情况是否允许存在
　　 （34） 文本框及某些控件拒绝输入和选择时显示区域是否变灰或按既定规约处理
　　 （35） 密码输入框是否按掩码的方式显示
　　 （36） Cancel之类的按钮按下后，控件中的数据是否清空复原或按既定规约处理
　　 （37） Submit之类的按钮按下后，数据是否得到提交或按既定规约处理
　　 （38） 异常信息表述是否正确
　　 （39） 软件是否按预期方式处理错误
　　 （40） 文件或外设不存在的情况下是否存在相应的错误处理
　　 （41） 软件是否严格的遵循外设的读写格式
　　 （42） 画面文字（全、半角、格式、拼写）是否正确
　　 （43） 产生的文件和数据表的格式是否正确
　　 （44） 产生的文件和数据表的计算结果是否正确
　　 （45） 打印的报表是否符合既定的格式
　　 （46） 错误日志的表述是否正确
　　 （47） 错误日志的格式是否正确

水因地而制行，兵因敌而制胜——测试感悟（针对手动、黑盒）

北大方正技术研究院 李守亮

1999年6月

编者按：这是一篇好文章，不在于他的文笔，而在于他的用"心"工作，用心总结。是他的工作经验和心路历程的记录，值得大家学习。

一直以来，总想写一写关于测试方面的文章。今天，真的接到这个题目时，却欲言又止，迟迟不能落笔。在这里，我也只将自己的实际经验介绍给大家，抛砖引玉，和大家共同探讨。

刚开始做测试的同事会有一种感觉，认为测试实际上是在充当这个产品的第一用户。也有人认为，测试其实很简单，没有什么技术可言。

其实，测试说易也易，因为进入门槛低；说难也难，因为测深测精不简单。黑盒测试很讲究策略，测试也是一门学问。

初涉测试的心路历程

        对测试的认识，每个测试人员都有一个过程。我对测试的认识，在每个阶段各不相同，其中也走了不少弯路。在此，我用第三人称把自己对测试工作的认识过程写出来，希望后来的同事能从中得到启发。

第一阶段学习+验证

对于新来的同事，刚刚涉及测试，往往踏不下心来。感觉测试是件没完没了地事情，并且单调重复、枯燥乏味，没有激情、没有成就感。这是很正常的现象，刚进入一个新的岗位，总有一个适应过程。

在这一阶段，新员工需要做的事情是，先学会使用所测的软件，熟悉他的每一个功能，弄清楚每一个功能的正确效果应该是什么？然后才开始尝试着去找一些肤浅的问题。这一阶段的感觉是："测试实际上就是验证产品每个功能的有效性"。新员工这一阶段虽然不太出成绩，但却很重要，因为这是以后工作的基础。

第二阶段与开发对立的误区

   当熟悉了所测产品的功能，并且找到测试的感觉后，就开始较深入地测试了。

在这一阶段，新员工会逐渐发现一些严重的BUG。当看到自己发现的问题被解决后，才真正感觉到自己在参与产品的生产。渐渐地，渐渐地，就会感觉到测试其实也挺有趣。尤其是发现一些死机或特别严重的错误时，有时会兴奋上几个小时。这是他进入状态的必然过程。

此时，他对测试的认识是："测试，就是要找出产品的缺陷，是证明当前产品不可用的一种行为"。这一阶段非常值得注意！很多软件公司常说："开发和测试的行为是对立和矛盾的"，这实际上是测试工作的误区。

第三阶段与开发主动配合

   随着测试经验的积累，对工作的认识也逐步深入。最后，他会发现，开发和测试之间，本质上是一个合作的过程，目标本是一致的。都是为了尽量减少发布产品中的错误，达到用户可接受的程度。于是，他会更多地站在用户角度考虑问题，测试的目的也越来越明确，工作也越来越主动。

第四阶段责任感+验证

   当经历了产品的几个生命周期之后，从不断的需求、开发、维护、升级循环过程中，逐渐认识到，测试实际上是降低产品风险的一种行为。逐步认识到，测试介入的环节越早，风险也就越小。

在和最终用户多次打交道，亲身体验用户的心情之后，油然而生出一种强烈的责任感，对测试的理解也随之升华为一种产品意识：测试工作和研发工作，实际上是一种荣辱与共的关系，取得的成绩和造成的失误，其荣誉和责任是同等的。此时，当他发现一个致命的错误或缺陷时，第二阶段的那种兴奋也许只会存在3秒钟。此时的他，更多考虑的是怎样帮助研发组尽快地把该问题解决掉。在这一阶段，测试工作中更注重产品的实用性和易用性。

   从学习阶段对产品的验证，到与研发的对立，到主动地和研发配合，到一种责任感使命感自发地对功能的验证，这是一个高级测试人员所必然要经历的一个心路历程。  

测试中的几种思维方式

   测试能否出成绩？以及测试工作的优劣，与个人的素质和修养有关。

测试工作说易也易，只要认真、负责，就能做出一些成绩。但说难也难，测试讲究很多方法和策略，要测的精，问题定位的及时准确，规律找的准确有效，那是需要下一番功夫的。在此，我把测试中常用的几种思维方式共享如下：  

正向思维  

         在测试一个产品之前，需要做的重要事情是，熟读产品的设计文档，详细了解每个功能的正确效果。然后针对每个模块，顺着程序员的思路，逐个验证，以验证测试功能的有效性。这是以后深入测试的基础，也是做自动测试的前提。

         搞清楚每个模块是干什么的，弄清楚正确的效果，才知道什么是错误的。这是非常关键的一个环节，如果在这方面不下功夫，也就很难测试出有价值的BUG。因为，很明显的错误结果可能就在你眼前大摇大摆地经过，而你却认为这是正确的！我就曾经一度陷入这一误区，好在很快地补上了这一课。  

逆向思维  

         关于"逆向思维"，我有两种解释，一是针对开发人员。

开发人员在调试或自测时，总爱顺着已有的思路进行。所以，在很多情况下容易忽略自己所犯的错误，例如边缘条件检查，异常处理等等。所谓当局者迷，旁观者清，是因为你可以跳出他的思维定式，从另外的角度来思考问题。所以，只要你肯动脑筋，不按他的逻辑进行检测，就一定能找出许多破绽。  

关于"逆向思维"的第二种解释，是针对具体问题。

当发生严重问题时，首先要保护好现场，然后努力地回忆，努力地理清思路。要善于从错误现象的最后一步往前倒推。例如死机问题，仅一个现象并不能说明问题，关键要找出它的规律。规律有时是最后一步操作导致，而有时则是前几十步操作的累加，这需要我们追忆刚才的几十步操作，并大胆怀疑其中的疑点，有目的的undo、redo。这一招叫顺藤摸瓜，抓住规律的尾巴，从最后一步开始。  

跳跃性思维  

         我也称它为联动思维。

有时，一个问题表现出来的现象和问题的本质会差着十万八千里，这类问题的规律也极难准确地捕捉到。处理这类问题，需要有扎实的测试基本功，并对产品非常地熟悉，才能把表面上毫不相关，却有着千丝万缕关系的孤立的两点联系起来；才能从一处错误得到启示，联想到其他模块也可能存在类似的问题......  

关于测试技巧  

黑盒测试，尤其是手工黑盒测试的业绩，有七成决定于个人因素。

测试需要有高度的责任心和使命感，要有主人翁精神。任何工作只有敬业才能做出成绩，工作主动了，自然会得到回报。  

在很多情况下，问题的现象出现了，但规律却不明显。当问题提交后，在开发那里却死活不能重现，这种情况是很尴尬和无奈的。所以，作为一个出色的测试工程师，仅仅捕获到问题的现象是远远不够的，还要找到其规律，甚至弄懂它更深层次的原因。

遇到这类问题怎么办？很多人可能就此放弃了，因为说他是"无规律或不能重现事件"。在我看来，这种说法是错误的。我认为，一定要树立起一个观念，那就是："任何错误的出现，都绝不是偶然的。每个错误现象背后都隐含着一个必然的规律，不管是肤浅的，还是深奥的。"而测试的目的，就是要把这个规律挖出来。因为，规律总结得越准确，对问题的定位和解决帮助就越大。  

         做好测试工作必须要做到几条：首先，要努力培养起对测试的兴趣；要培养对所测产品的感情，要像对待自己孩子一样去热爱它，呵护它。其次，要胆大并心细。要有游走于高山峡谷边缘的那种"如临深渊，如履薄冰"的胆量和谨慎。要敢于怀疑，大胆假设而小心求证。再次，要有耐心，戒骄戒躁，心要安静。  

如果说测试有技巧的话，也仅占到三成：

         1、对待问题要锲而不舍，并善于总结经验。

         举一个案例，对于"方正飞腾（报社专用排版软件）自动勾边死机问题"规律的发现，我现在还记忆犹新。我1997年刚接触这款软件时就遇到了该问题，但问题变化无常，当时找不到一点儿规律：有时，在关键位置点一下鼠标就死，有时点100多次才死，有时怎么点都不会死。该问题整整困扰了我一年，直到有一天，我盯着屏幕发呆，发现鼠标变成了漏斗，我随便点了一下<调整>按钮，程序立刻死机。当时灵机一动，莫非跟"自动存盘"有关？判断是正确的！一年来的谜终于被解开了，而受此启发，后来遇到"非法字体窗口"、"自动翻页"、以及"删除表格"所引发的死机，不到1秒的时间，我就准确定位与自动存盘有关。  

         对于疑难问题，不妨先放他一放，过几天再去想，说不定就会有新思路冒出来，有新灵感被激发出来。对于每一个解决的疑难问题，都要认真分析它的原因，总结定位经验，并推演联想到其他模块。测试过程是一个循序渐进的过程，是一个经验积累的过程。以一年的摸索换来若干个一秒钟的思索，值！还有很多典型案例，限于篇幅，不便罗列。  

         2、善于推理，善于运用逆向思维。善于换位思考，变换角色对待问题；

         3、善于和别人共享经验，站在别人已有的思路上进一步深入，多动脑筋，多动手。

         4、简化问题规律的步骤，弄清楚问题产生的原因，总结程序员的教训，对类似问题可以触类旁通。

         5、不断地怀疑，不断地推翻怀疑。突破跳出思维定式，大胆假设，小心求证。  

将军围猎  

曾经在文字所和测试中心流传一句话："软件里的bug如同海绵里的水，要想挤总会有的"。旧bug的修改往往会引发新bug的产生，所谓"按下葫芦起来瓢"。  

如何培养测试人员的对测试工作的兴趣呢？不妨把bug比作藏匿在深山丛林中的猎物，把自己比作围猎的将军。程序中的bug变化莫测，要有将军指挥作战的气度，怎样更快更准更有效地定位它们，捕获住它们？围追堵截之中，尽显英雄本色。  

兵法上说，水因地而制行，兵因敌而制胜。兵无常势，无恒形，能与敌变化而取制者，谓之神。仅仅通过黑盒测试，你就能知道程序员做了什么改动？怎样做的改动？还存在什么缺陷？并快速准确地把它定位出来。若能达到这种境界，让你的思维能力受到如此的锻炼和考验，难道还不会有成就感么？  

当你全身心地投入在测试中，你会感觉到测试，实际上是一场智力游戏。所谓"气痴者技精"，因为一进入状态，坐下来就会忘记时间的流逝。