﻿<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>IT博客-mxfooo</title><link>http://www.cnitblog.com/mxfooo/</link><description /><language>zh-cn</language><lastBuildDate>Mon, 04 May 2026 19:24:45 GMT</lastBuildDate><pubDate>Mon, 04 May 2026 19:24:45 GMT</pubDate><ttl>60</ttl><item><title>两年测试总结(1)</title><link>http://www.cnitblog.com/mxfooo/archive/2008/03/26/flier.html</link><dc:creator>flier</dc:creator><author>flier</author><pubDate>Wed, 26 Mar 2008 05:24:00 GMT</pubDate><guid>http://www.cnitblog.com/mxfooo/archive/2008/03/26/flier.html</guid><wfw:comment>http://www.cnitblog.com/mxfooo/comments/41492.html</wfw:comment><comments>http://www.cnitblog.com/mxfooo/archive/2008/03/26/flier.html#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://www.cnitblog.com/mxfooo/comments/commentRss/41492.html</wfw:commentRss><trackback:ping>http://www.cnitblog.com/mxfooo/services/trackbacks/41492.html</trackback:ping><description><![CDATA[<p>测试工作,有轻松的时候,也有繁忙的时候,但总的来说忙大于轻松<br>记得刚上手测试时,不知道从何下手?<br>产品的操作手册和命令手册,最基础的DD,却是新人最好的参考资料;<br>产品的操作手册和命令手册面向的就是用户,对于新产品,用户也是新人;<br>产品资料,不仅仅是告诉你怎么使用它,里面还包括很多概念的阐述,<br>功能的简介,和部分实现方式;对于测试来说,都是很重要的资料.</p>
<p>看产品资料的同时,也要学习产品所基于的协议,标准之类的;<br>协议,标准阐述了功能的实现方式;在动手测试之前,需要有一定的了解.<br>此时,不需要深究;以后随着测试的深入,自然而然会有更深的理解.</p>
<p>当中,还应该初步掌握测试平台,测试工具和测试方法;<br>不然开始工作时,那些测试工具会让你傻眼;虽然当你会用后是贼简单的<br>DD,但是没有用过却是不怎么好用的DD!</p>
<p>新人上手后,会经历这样的一个过程:自己测试的模块怎么问题很少,而<br>其他同事复杂的模块的问题那么多,为啥呢?实际上是这样的吗?答案是<br>否定的!因为新人刚开始,对产品的熟悉程度还不够把产品里隐藏较深的<br>问题发掘出来;还有,毕竟是新人,还没有形成适合自己的一套测试方法<br>和测试理论,这些都是需要通过长期的经验积累和总结才可以形成的.<br>这时,新人可以查看前辈们的问题单,看看前辈们是怎么样进行测试的,<br>他们的测试过程,方法是怎么样的?对于新人来说,问题单是很多的学习<br>资料.对于自己的测试方法和理论的形成有促进的作用.</p>
<p>之后,信任就开始了漫长的测试执行阶段.测试是具有重复性的,相同的<br>功能模块,相同的产品测试久了会有厌倦的心理;这时需要适当的调整下.<br>可以和同事换模块测试;不仅可以避免测试的重复性,还可以学习新的技术<br>,而因为人与人之间的测试方法和测试理论总是不一样的,一个模块让不<br>同的人来测试,可以测试出不一样的问题来,对于产品的测试,更有覆盖性.</p>
<p>而后,等测试时间的增长,测试人员除了测试执行外,其他测试工作会越来<br>越多:测试设计(测试点,测试用例的写作)、外对测试用例的协作、各种<br>开发\测试文档资料的评审、对外测试支持、自动化脚本的写作、实验局<br>开局等等;虽然这些工作对于测试执行来说,没有了相对的重复性,但是这<br>些工作的难度或者说是复杂度是大大增加了:因为测试执行只需要跟着测<br>试点跑功能就成,而后面的这些,可没有那么简单.就举对外测试支持来说,<br>外面运营商或是产家的测试注重实际运用的测试,而新研发出来的产品<br>在公司内部注重功能测试,当然也是注重实际应用的;可是是新产品,外面<br>还没有大规模应用的情况下,相对来说,实验室的测试和外面的测试差距<br>还是蛮大的,所以需要测试人员反应要快,能够在短时间内搭建好测试平台<br>和测试环境,对对面突发性的测试需要进行验证;如果在产品不支持的情况<br>下,需要研究出其他的解决方案来满足外面测试需要的功能.</p>
<p>对于测试人员来说,在测试过程中,或多或少总是会发现一些不是必现的<br>问题.对测试人员来说,需要把问题出现时的现场在问题单中描述的很清楚,<br>(配置文件,操作过程log,流量的类型和大小等等)而且尽可能的对发现<br>问题进行复现操作,当然这个过程也需要把握时间,<br>因为测试版本的时间本来就是比较赶的,不能消耗过多的时间在复现问题上.<br>当整个版本在该论测试完成后,可以考虑集中时间对不能重现的问题进行<br>复现工作.而在复现工作过程中,可以开发人员进行交流.因为开发人员对于<br>产品实现的流程比较测试人员要熟悉,一般来说开发可以提出一些很有价值<br>的观点,有利于问题复线工作.</p>
<p>测试产品时(测试资料,评审文档),测试人员需要带着怀疑的观点去测试,<br>这个观点往往对于测试新人来说,是比较困难的.新人很容易是带着去验证的<br>观点去测试(总是认为产品,文档资料都是正确),所以发现的问题比较少;<br>当如果换个角度,采用怀疑的观点去测试时,会发现很多原先没有发现的问题.<br>特别是一些设计方面的问题.虽然功能是没有问题的,但是实现的过程或是方法<br>却不是最优的,这些问题是新人很难发现的,当然也是需要一定的经验积累的.</p>
<img src ="http://www.cnitblog.com/mxfooo/aggbug/41492.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.cnitblog.com/mxfooo/" target="_blank">flier</a> 2008-03-26 13:24 <a href="http://www.cnitblog.com/mxfooo/archive/2008/03/26/flier.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>