项目测试节奏把握和工作挖掘090714.doc

项目测试节奏把握和工作挖掘一、 前言由于受老思想观念的影响比较深，我一直认为做事应该前紧后松，先苦后甜（关于这个想法，今后如果还有“雅兴”，我会另外找时间论述），但是我觉得我们软件测试在这一点上一直做得不是很好。一个典型的表现，就是在项目最关键的前两轮全面测试时，测试任务不够饱满，对于测试工作的挖掘不够深，加班时间时间比后期少（呵呵，这个论据或许有很多人不会认同）。这一现象带来的一个结果，就是开发人员常抱怨我们bug报的晚，影响进度，同时我们的项目测试变成“跑基本功能、跑基本功能、跑基本功能、跑基本功能、跑基本功能还有一堆问题复现不了，专项测试、集中攻关客户反馈一堆问题，救火”这么一个单调而痛苦的过程。而另一个更不好的结果，是大家慢慢习惯于这种模式，慢慢以为带项目最重要的就是攻关救火能力，做项目更多的成就感也慢慢来自于参与了什么问题的攻关，救了几处火，处理的多少客户急需的版本。这种思路蔓延开来，大家也慢慢觉得整天救火、忙得吐血的人是表现最好的，最应该得到表扬和奖励（连我现在也有点这种思路），而那些计划安排、节奏把握好，带项目游刃有余，显得比较“清闲”的，往往就会遭受不太公正的待遇。就这个现象，我琢磨了一晚上，随便写一些概念和方法供大家参考。当然，现实当中会存在各种因素和困难，导致我们无法做到理想化，比如一个版本就集成所有功能，一个版本就测出所有bug。同时即便了解、掌握、运用了所有的测试理论，也不可能解决现实中的所有问题，正如唐僧取了西经，也没见大唐个个成佛。但是了解一些并在实际中尝试做一些应用，一定会带来一些改进，哪怕只是一点点（毕竟去取经的几位还都成佛了嘛）。同时也希望大家知道，测试其实是一件很有趣的事情，关键是你怎么做。二、 测试模型测试模型一定是和开发模型和项目要求相匹配的，常见的主要有两种：大爆炸式和渐增式。模型的名字都挺好听，因为那是搞理论研究的人取的。简单来说，大爆炸式就是把所有功能都集成了才开始测，渐增式就是先集成部分功能模块进行测试，过程中再逐步增加功能。我们目前的一些项目测试，形式上非常类似渐增式测试模型，只是前期的规划和计划欠缺了一点。说模型的事，只是希望大家了解，平时大家认为不太合理的一些情况，在现实中是普遍存在的，并且测试理论的研究人员已经把它上升为一种“模型”，所以我们要摆正心态，把更多精力放在如何更好的处理好这种“模型”下的诸多现实问题上。同时了解到这种现状不可避免，我们更应该提早把能做的事情做好做透。三、 测试基线和节奏不论是啥模型，从项目的测试管理角度来说，最重要的就是测试基线的管理。这里又来了一个名词，具体的解释网上可以查到一些解释和讨论，从我的粗浅理解来说，基线就是我们项目测试过程主要分支上的一些节点，尤其在平台版本测试过程中最需要应用这个概念。结合我们的实际测试过程，第1个全case版本、第一个全功能版本、2k版本、量产版本都是重要的基线版本。对于一些功能更多或者新平台项目来说，可能还需要增加更多的基线点。基线最重要的一个作用，就是使我们在某些节点上，能够对版本状态有一个全面的了解，避免由于一直做回归测试而造成对整体状态的失控。后续出现问题回溯时也会更加的方便，同时后续的版本出现问题时也可以提供一个比较有底的“退路”。另外一个作用，就是可以根据基线的设定，合理安排各个版本的测试策略，把一些测试活动分解到过程中，避免每个版本都仅仅停留在基本功能的测试层面。从上面2个作用我们可以看出，基线的选择和数量控制都是非常重要的。具体的选择和控制方法和实际的关联性非常大，虽然也有一些理论，我这里就不展开了。这方面我们以前吃过多次亏。比如F500项目，我们在后面一直在跟踪Java相关的两个问题，忽视了其他模块的全面测试，结果经过很长Java问题解决了，突然发现其他模块还有问题漏测，直接影响了项目进度。再比如近期的C108项目，我们一直在应付各类版本，因为每个版本都可能外发使用，所以担心每个版本测不全，所以每个版本都在跑基本功能，导致一些应该提前做的压力测试、专项测试到很后面才开始做，也对整体的项目进度造成了一定的影响。说完这一部分，主题好像有点散了，这完全是理论功底和思维能力不够的表现其实我想强调的就是“节奏”这两个字。四、 挖掘测试工作的一些思路最后回到最前面说的那个前紧后松的问题。大家前期紧不起来，可能还有一个方法的问题，部分同事可能跑完case之后就不知从何下手了。对于如何在测试过程中多进行一些挖掘，把前期的测试工作做得更充分一些，我提供两个思路给大家参考。1、 对于case的挖掘随便举个例子。比如有这么条case（不是实际的case，我也省略了一些要素）编写一条短信并发送，确认接收方能够收到短信，内容正确。这条case可能半分钟就能执行完，但是仔细想想还是有很多能够挖掘的地方，一般可以从以下四个方面入手：（1） 测试环境（预置条件）插几张SIM卡、联通卡还是移动卡或者不插卡、卡1还是卡2、短信中心设置对不对、短信回复有没有打开、其他短信设置、有没有其他应用运行（比如mp3背景播放）（2） 程序入口从哪个入口进入写短信（正常从主菜单信息进入，还是快捷键进入、IDLE快捷图标进入，或者通过读新短信、回复短信方式进入），什么方式进入（触屏、按键）（3） 中间操作方式什么方式写短信和写什么内容（手写、按键、输入法、是否插入短信模板或其他内容、内容排版方式、内容长度），接收方选择（对方是联通、移动或其他、号码是直接输入还是从电话本选、号码输错了呢）（4） 程序出口和后续发送方式选择，后续操作（错误操作是否有提示、短信回复）.上面这个例子其实反映了一个写case的思路。不过由于实际条件的限制，我们目前的case数量不多，其中的一些要素（比如预置条件、一些具体操作方法）也有诸多模糊之处，因此每一条case都留给大家很大的拓展空间。同样一个模块，想的简单的可能半天就能测完，想的多点可能就能琢磨两三天。这其实就对我们测试人员提出了更高的要求。另外还有一些常见的测试思路，比如边界值、压力等，这些通常的测试知识都会提到，大家可以想想平时是不是也会经常的运用一下？2、 对于bug的挖掘对于bug本身的挖掘，可以从下面几个目的来考虑：（1） 为bug的解决提供更充分的信息。随便举个例子，比如有这么条PR：文件管理后台播放 FM, 打开文件管理，复制一文件，然后快速按右软键盘，RESET可以进一步考虑一下，这个PR里提到的因素是否都和结果相关，是否可以排除一些，或者还有哪些相关因素没有提到？故障的产生是否和选择的文件相关，或者和文件的类型、大小相关，是否可以先排除？快速按键从什么时候开始，是复制过程中还是复制完成后？和按哪个键是否有关呢？如果只和右软键相关，右软键关联的功能是什么？（2） 做好bug相关的波及分析，为bug的彻底解决和充分验证提供依据。这次真是随便想的例子了，大家不要过多关注内容本身。比如发现这么条bug：开机后IDLE界面可拖动任务栏中备忘录条目不刷新我们可能就需要考虑一下各种不同的开机是否有所不同，验证是也一样。这种情况的案例应该有很多，我们往往解bug、验bug不充分，就是因为关联部分的波及分析做得不全面。（3） 找到bug复现的规律。我们在测试过程中经常会发现一些偶现bug，其实很多bug只要认真去分析一下，还是能够找到复现路径的。这方面我就不多举例，以前唐廷蓉、侯进强、丁沈吉都写过类似的技术总结