俺为测试小虾米,谢谢大家帮助米!!

发布新日志

  • 毕业了!

    2007-06-20 17:16:24

        刚刚写了很多,但删掉了,没有办法再在重写一次,就像我大学的时光一样,过去了就回不来了。

        人总是在失去后,才明白珍惜;只有错过了,才知道可贵。这是大家都懂得,但是又有多少人能真正的不让它发生,那是很少很少的。

        6月27日,我就完全离开学校了,我的前途怎样,我都还是没有看清楚,我还担心自己这样,可是却还是这样了,努力吧,我会知道自己的方向的。我祝福我自己,也祝福那些和我一样,即将迈进或迈出大学学校大门的朋友们!

  • 毕业了!

    2007-06-13 14:48:56

       后天毕业答辩了,感觉好累,但是却不知道自己在忙什么,好空虚.与其说是空虚,不如说是迷茫,觉得自己好浪费时间,对于生存的意义都有些迷茫了,不知道怎的,不知道怎么走下去!

            

  • 好累哦!

    2007-05-29 13:08:22

        快毕业了,有很多事,真的很烦!工作上也有很多事,希望这忙过了就会好起来!

  • [转贴]你绝没见过的小学生作业实拍

    2007-05-09 10:27:45

    你绝没见过的小学生作业实拍















    有这样的老师中国的教育才有希望

















    有这样的老师中国的教育才有希望

  • [转]女人过了25岁应该知道的事

    2007-05-09 10:13:26


    1.视爱情为生活奢侈品:有最好,没有也能活。
    2.若工作计划与男友约会档期冲突,取前者——前者不会辜负你(且越老越不会,除非你当三陪)。
    3.签任何合同之前至少看三遍——最具挑战性的合同是婚约。
    4.小女孩用吸烟,夜游,多交男友表示成熟,你就不必了。
    5.随缘,但不是说不努力。
    6.手袋内必备物品:丝袜一双(穿裙子时),小手电筒一个(夜归时),防身喷雾一瓶(偏僻处单独行动时——最好不要到偏僻处单独行动),巧克力或蔬菜饼干一小板(加班时),好牌子护肤霜一盒(任何时候),钱包,里面有钱(任何时候)。
    7.为了你的身心健康可养一只宠物,为了宠物的身心健康,则不要养——据说它们太孤独了也会得忧郁症。
    8.每天吃维生素丸,坚持补钙,否则在浴缸里面一跤摔断腿,即使你能爬出来打急救电话并在医生赶来之前披上衣服恐怕也得在床上躺3月,一个夏天不能穿裙子。
    9.每月记帐。
    10.人越少则冰箱要越要大,精神空虚,食物(高蛋白,多纤维,低脂肪,少热量,少食多餐)填充,若打开冰箱没有食物可鼓励你努力工作。
    11.若常常需要早起开会,请备高分贝闹钟一个——睡眠特好的人备三个。
    12.酒吧里认识的男子就不必留电话了。
    13.最好不要让初次约会的异性知道你住所,若对方坚持送,那么到楼下即可——相信我,他不"顺便上去喝杯茶"也不会渴死。
    14.若连续六个月每月置衫超过十件,考虑买房。
    15.自己开车,车子比男人好的地方是:它不会自己跑掉----当然它可能被偷,但你可以买保险,男人则不能买保险。
    16.买保险。
    17.如果没车,不要买白皮鞋。
    18.办公室备一件厚外套,一把伞。
    19.同事的恭维就象香水,可以闻,但不要喝。
    20.如果不幸你爱的男子有另一个女人,无论是老婆,未婚妻或女朋友,请不要动念头和她"见面谈一下",没必要——即时走人!
    21.永远不要问这个问题:"为什么不爱我"
    22.不要预先说出决心
    23.男人对自己的好色就象律师对罪犯:明知有罪也要辩护---你知道就是啦。
    24.没有任何事,任何人会重要到需要你过了半夜12点还苦想不睡。
    25.即使美若天仙,也要讲道理。
    26.也可以去相亲,但事先一定打听清楚对方的尊姓大名——否则连续三个周末梳妆打扮齐整,跟着不同的红娘羞答答去见同一个无聊男子,那实在太戏剧性了。
    27.若没有五位数出场费,不要参加"非常男女"之类的电视节目。
    28.务必结交三五死党(同性最好),否则有可能在头疼脑热时要汤没汤要水没水最后把嘴伸进热带鱼缸或马桶内解渴```或心脏病突发死在床上八天都没人发觉。
    29.任何时候都不要喝多,头天晚上吐的东西次日早上还要自己收拾,可能会吐第二次。
    30.抽屉里放好必备药品。
    31.家里的安眠药不要超过10粒。
    32.即使你"真的"没有男友,备一只安全套也不多余。
    33.真诚微笑,别怕皱纹。
    34.获得智慧,需以青春为代价。
    35.元宵节,中秋节,情人节若无节目可主动要求加班——免得出门触景生情或回家独自神伤,且给老板一个好印象。
    36.生日时自己预定大束鲜花差人送到办公室和父母家。
    37.学会做几个好菜。
    38.周末给自己炖汤。
    39.已结婚的前男友打电话来问最近好不好——说好。
    40.过去,童话故事是以“很久很久以前”开头的,现在,童话故事是以“如果我还没有结婚”开头的,你已经过了听童话的年龄了。
    41.若确实有需要,可(在办公室以外的地方)上网给自己定购一个"仿真物品"但注意卫生,防止感染塑胶细菌。
    42.同居前请查体。
    43.想的时候,想想再说。
    44.不想的时候,说不。
    45.若没有感情,不如去打网球。
    46.爱你的工作,不要爱上你的上司。
    47.不要动念头做单亲妈妈——孩子不需要父亲,但你需要一个照顾孩子的人,非常需要有人照顾。
    48.多赚点钱,但不要多到谁看上你你都要疑心的地步。
    49.有望得到的要努力,无望得到的不介意,则无论输赢,姿态都会好看。
    50.其实,人生即使有伴也是寂寞的----不如及早培养兴趣,中年之后,种花养鱼。
    51.有人称赞你年轻,还是应该高兴的。
    52.谈恋爱就象打麻将,不认真没乐趣,太认真易伤心,培养点游戏精神。
    53.不必对新男友坦白过去,如果爱他,尤其不必。
    54.与任何人,在任何情况下都不拍欢爱之镜头。
    55.真喜欢一样东西,就买吧。
    56.穿新鞋出门前,多试几步。
    57.家具轻便,简洁,易清理,好搬动,若没有工程天才,别买"宜家"之类需自己动手装配的新潮玩艺(名词解释:锤子:一种专门用来砸破手指的工具。)
    58.中年发迹而离婚的男人求婚,说不。
    59.曾经背叛过你的男人想回头,说不。
    60.你曾经背叛的男人请你回头,说不。
    61.已经到了这个时候,就更不要将就了。
    62.答应请求时面带微笑,说不的时候清晰肯定。
    63.男人的主要功能是产生精子——但我们现在有了精子银行。
    64.独居的好处之一是,你不必在一个很久以前爱过的人的臂弯醒来。
    65.保持青春的秘诀,有颗不安定的心!
    66.征婚广告不是情书。
    67.出门散步穿双平底鞋,带好电话。
    68.无论蕾丝内衣还是工作报告,简洁都是最好的。
    69.浪漫是一袭美丽的晚礼服,但你不能一天到晚都穿着它啊。
    70.嫁大款就象抢银行,收益总很大,但后患无穷,若能不试,还是不试为好。
    71.对男人的考验,怎么说呢——就像智力测验,目的就是想看看他到底有多蠢。
    72.对于一个错误的诺言,你要有勇气违背它。
    73.大事坚持原则,小事学会变通。
    74.培养些小小的好习惯,比如早睡,比如饭后漱口,比如喝淡茶,比如工间操——好习惯如同零钱罐,每天放一点,年终会惊喜。
    75.任何东西都不能以健康做交换。
    76.一个人是否可靠,全看你用什么样的手段控制他。
    77.一切都不需争论,只需给出结果。
    78.男人总是向不把他看在眼里的女人献殷勤----命运也是。
    79.想满意,自己做,菩萨合掌念菩萨,求人不如求己。
    80.不要借钱,若一定要借,借银行。
    81.不要借给人钱,若一定要借,别打算他还。
    82.学着理财,即使你学的是考古或小提琴。
    83.别用男朋友的生日做密码——常常换,很烦的。
    84.换男朋友的时候,记得换防盗门。
    85.太在意一个男人往往得不到他——钱也一样。
    86.床买大一点,可以横着睡,枕头要两个,枕一个,抱一个。
    87.床头放本好书。
    88.床上用品一定要品质好的,男人也是一种床上用品。
    89.每天大笑几次对身体好——若没人给你讲笑话,看(猫和老鼠)。
    90.找一项有兴趣的体育活动。(做爱不算),坚持。
    91.心情失落时不要淋雨,听慢歌,看悲情电影。泡在浴缸内喝红酒,叫个女友去爬山。
    92.每天抱怨,唠叨,自怜的时间不要超过10分钟。
    93.不要常常计算得失——那是保险公司和你的对手的事。
    94.遇到好男人不妨追。
    95.若你的女友的丈夫是律师,医生,经济人,出版商,电脑高手——不妨请他给自己参考买搂,保险,投资,出书,装软件——但记得每次均邀伉俪同往。
    96.诚实是一种美德,但不必因此就随和女友抨击她丈夫,跟同事一起讨伐老板。
    97.衣服买少一点,好一点,三季没穿一次的衣服即可送人。
    98.里子比面子重要,保养品当然比化妆品多,好,贵。
    99.工作之余,尽量在室外活动。
    100.若无杀伐决断之天才,不要给人做情妇。
  • 好累哦!

    2007-05-09 00:39:19

        5.1 本想好好休息,可是却要赶毕业设计,呜呜,累死了。不过还好做完了,嗯!!

  • 要放假了!!!

    2007-04-30 09:15:03

       明天5.1了,呵呵,可以好好的休息几天。

       祝大家节日快乐呀!

  • [转贴]软件测试常识--作者: dasdfalei

    2007-04-30 09:08:17

    软件测试常识

    Acceptance testing(验收测试),系统开发生命周期方法论的一个阶段,这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。

    Ad hoc testing (随机测试),没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。

    Alpha testing (α测试),是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。

    Automated Testing(自动化测试),使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试中用得较多。

    Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。

    Black box testing(黑盒测试),指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。

    Bug (错误),有时称作defect(缺陷)或error(错误),软件程序中存在的编程错误,可能会带来不必要的副作用,软件的功能和特性与设计规格说明书或用户需求不一致的方面。软件缺陷表现特征为:软件未达到产品说明书标明的功能;软件出现产品说明书指明不会出现的错误;软件功能超出产品说明书指明的范围;虽然产品说明书未指出但是软件应达到的目标;软件测试人员或用户认为软件难以理解,不易使用,运行速度缓慢等问题。

    Bug report(错误报告),也称为“Bug record(错误记录)”,记录发现的软件错误信息的文档,通常包括错误描述、复现步骤、抓取的错误图像和注释等。

    Bug tracking system(错误跟踪系统,BTS),也称为“Defect tracking system,DTS”,管理软件测试缺陷的专用数据库系统,可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。

    Build(工作版本),软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本,也可以是展示要在最终产品中提供的部分功能的部分系统。

    Compatibility Testing(兼容性测试),也称“Configuration testing(配置测试)”,测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

    Capture/Replay Tool (捕获/回放工具),一种测试工具,能够捕获在测试过程中传递给软件的输入,并且能够在以后的时间中,重复这个执行的过程。这类工具一般在GUI测试中用的较多。

    Crash(崩溃),计算机系统或组件突然并完全的丧失功能,例如软件或系统突然退出或没有任何反应(死机)。

    Debug(调试),开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时,或者根据测试错误报告指出错误以后,开发人员需要执行调试过程来解决已存在的错误。

    Deployment(部署),也称为shipment(发布),对内部IT系统而言,指它的第一个版本通过彻底的测试、形成产品、交付给付款客户的阶段。

    Dynamic testing(动态测试),通过执行软件的手段来测试软件。

    Exception(异常/例外),一个引起正常程序执行挂起的事件。

    Functional testing (功能测试),也称为behavīoral testing(行为测试),根据产品特征、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。

    Garbage characters(乱码字符),程序界面中显示的无意义的字符,例如,程序对双字节字符集的字符不支持时,这些字符不能正确显示。

    GB 18030 testing(GB 18030测试),软件支持GB 18030字符集标准能力的测试,包括GB 18030字符的输入、输出、显示、存储的支持程度。

    Installing testing(安装测试),确保该软件在正常情况和异常情况的不同条件下,例如,进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    Integration testing(集成测试),被测试系统的所有组件都集成在一起,找出被测试系统组件之间关系和接口中的错误。该测试一般在单元测试之后进行。

    International testing(国际化测试),国际化测试的目的是测试软件的国际化支持能力,发现软件的国际化的潜在问题,保证软件在世界不同区域中都能正常运行。国际化测试使用每种可能的国际输入类型,针对任何区域性或区域设置检查产品的功能是否正常,软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语(可选)的混合字符。

    Localizability testing(本地化能力测试),本地化能力是指不需要重新设计或修改代码,将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本,提高测试效率,本地化能力侧是通常在软件的伪本地化版本上进行。本地化能力测试中发现的典型错误包括:字符的硬编码(即软件中需要本地化的字符写在了代码内部),对需要本地化的字符长度设置了国定值,在软件运行时以控件位置定位,图标和位图中包含了需要本地化的文本,软件的用户界面与文档术语不一致等。

    Load testing(负载测试),通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。

    Localization testing(本地化测试),本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试,安装/卸载测试,当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量,包含软件、文档和联机帮助等部分。

    Performance testing(性能测试),评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。

    Pilot testing(引导测试),软件开发中,验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中,引导测试通常是客户检查软件测试公司测试能力的一种形式,只有通过了客户特定的引导测试,软件测试公司才能接受客户真实软件项目的软件测试。

    Portability testing(可移植性测试),测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。
    Priority(优先权),从商业角度出发是指错误的重要性,尤其是从客户和用户的角度出发,是指错误对于系统的可行性和可接受性的影响。与“Severity(严重性)”相对照。

    Quality assurance(质量保证QA),采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。

    Regression testing(回归测试),在发生修改之后重新测试先前的测试以保证修改的正确性。理论上,对软件的任何新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再现。

    Review(评审),在产品开发过程中,把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。

    Sanity testing(健全测试),软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考“Smoke testing(冒烟测试)”。

    Screen shot(抓屏、截图),软件测试中,将软件界面中的错误(窗口、菜单、对话框等)的全部或一部分,使用专用工具存储成图像文件,以便于后续处理。

    Severity(严重性),错误对被测系统的影响程度,在终端用户条件下发生的可能性,软件错误妨碍系统使用的程度。与“Priority(优先权)”相对照。

    Smoke testing(冒烟测试),冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。参考“Sanity testing(健全测试)”。

    Software life cycle(软件生命周期),开始于一个软件产品的构思,结束于该产品不再被使用的这段期间。

    Static testing(静态测试),不通过执行来测试一个系统。如代码检查,文档检查和评审等。

    Structured query language(结构化查询语句,SQL),在一个关系数据库中查询和处理数据的一种语言。

    TBD(To be determined,待定),在测试文档中标是一项进行中的尚未最终确定的工作。

    Test(测试),执行软件以验证其满足指定的需求并检测错误的过程。检测已有条件之间的不同,并评价软件项的特性软件项的分析过程。软件工程过程的一个活动,它将软件在预定的条件下运行以判断软件是否符合预期结果。

    Test case(测试用例),为特定目标而开发的一组测试输入、执行条件和预期结果,其目标可以是测试某个程序路径或核实是否满足某个特定的需求。

    Testing coverage(测试覆盖),指测试系统覆盖被测试系统的程度,一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。

    Testing environment(测试环境),进行测试的环境,包括测试平台、测试基础设施、测试实验室和其他设施。

    Testing item(测试项),作为测试对象的工作版本。

    Testing plan(测试计划),描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务,并且任何风险都要冲突计划。

    Testing procedure(测试过程),指设置、执行给定测试用例并对测试结果进行评估的一系列详细步骤。

    Testing scrīpt(测试脚本),一般指的是一个特定测试的一系列指令,这些指令可以被自动化测试工具执行。

    Testing suite(测试包),一组测试用里的执行框架;一种组织测试用例的方法。在测试包里,测试用例可以组合起来创造出独特的测试条件。

    Unit testing(单元测试),指一段代码的基本测试,其实际大小是未定的,通常是一个函数或子程序,一般由开发者执行。

    User interface(用户界面,UI),广义是指使用户可以和计算机进行交互的硬件和/或软件。狭义是指软件中的可见外观及其底层与用户交互的部分(菜单、对话框、窗口和其它控件)。

    User interface testing (用户界面测试),指测试用户界面的风格是否满足客户要求,文字是否正确,页面是否美观,文字,图片组合是否完美,操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

    White box testing(白盒测试),根据软件内部的工作原理分析来进行测试,基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。

    Acceptance testing(验收测试),系统开发生命周期方法论的一个阶段,这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。

    Ad hoc testing (随机测试),没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。

    Alpha testing (α测试),是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。

    Automated Testing(自动化测试),使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试中用得较多。

    Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。

    Black box testing(黑盒测试),指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。

    Bug (错误),有时称作defect(缺陷)或error(错误),软件程序中存在的编程错误,可能会带来不必要的副作用,软件的功能和特性与设计规格说明书或用户需求不一致的方面。软件缺陷表现特征为:软件未达到产品说明书标明的功能;软件出现产品说明书指明不会出现的错误;软件功能超出产品说明书指明的范围;虽然产品说明书未指出但是软件应达到的目标;软件测试人员或用户认为软件难以理解,不易使用,运行速度缓慢等问题。

    Bug report(错误报告),也称为“Bug record(错误记录)”,记录发现的软件错误信息的文档,通常包括错误描述、复现步骤、抓取的错误图像和注释等。

    Bug tracking system(错误跟踪系统,BTS),也称为“Defect tracking system,DTS”,管理软件测试缺陷的专用数据库系统,可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。

    Build(工作版本),软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本,也可以是展示要在最终产品中提供的部分功能的部分系统。

    Compatibility Testing(兼容性测试),也称“Configuration testing(配置测试)”,测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

    Capture/Replay Tool (捕获/回放工具),一种测试工具,能够捕获在测试过程中传递给软件的输入,并且能够在以后的时间中,重复这个执行的过程。这类工具一般在GUI测试中用的较多。

    Crash(崩溃),计算机系统或组件突然并完全的丧失功能,例如软件或系统突然退出或没有任何反应(死机)。

    Debug(调试),开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时,或者根据测试错误报告指出错误以后,开发人员需要执行调试过程来解决已存在的错误。

    Deployment(部署),也称为shipment(发布),对内部IT系统而言,指它的第一个版本通过彻底的测试、形成产品、交付给付款客户的阶段。

    Dynamic testing(动态测试),通过执行软件的手段来测试软件。

    Exception(异常/例外),一个引起正常程序执行挂起的事件。

    Functional testing (功能测试),也称为behavīoral testing(行为测试),根据产品特征、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。

    Garbage characters(乱码字符),程序界面中显示的无意义的字符,例如,程序对双字节字符集的字符不支持时,这些字符不能正确显示。

    GB 18030 testing(GB 18030测试),软件支持GB 18030字符集标准能力的测试,包括GB 18030字符的输入、输出、显示、存储的支持程度。

    Installing testing(安装测试),确保该软件在正常情况和异常情况的不同条件下,例如,进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    Integration testing(集成测试),被测试系统的所有组件都集成在一起,找出被测试系统组件之间关系和接口中的错误。该测试一般在单元测试之后进行。

    International testing(国际化测试),国际化测试的目的是测试软件的国际化支持能力,发现软件的国际化的潜在问题,保证软件在世界不同区域中都能正常运行。国际化测试使用每种可能的国际输入类型,针对任何区域性或区域设置检查产品的功能是否正常,软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语(可选)的混合字符。

    Localizability testing(本地化能力测试),本地化能力是指不需要重新设计或修改代码,将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本,提高测试效率,本地化能力侧是通常在软件的伪本地化版本上进行。本地化能力测试中发现的典型错误包括:字符的硬编码(即软件中需要本地化的字符写在了代码内部),对需要本地化的字符长度设置了国定值,在软件运行时以控件位置定位,图标和位图中包含了需要本地化的文本,软件的用户界面与文档术语不一致等。

    Load testing(负载测试),通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。

    Localization testing(本地化测试),本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试,安装/卸载测试,当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量,包含软件、文档和联机帮助等部分。

    Performance testing(性能测试),评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。

    Pilot testing(引导测试),软件开发中,验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中,引导测试通常是客户检查软件测试公司测试能力的一种形式,只有通过了客户特定的引导测试,软件测试公司才能接受客户真实软件项目的软件测试。

    Portability testing(可移植性测试),测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。
    Priority(优先权),从商业角度出发是指错误的重要性,尤其是从客户和用户的角度出发,是指错误对于系统的可行性和可接受性的影响。与“Severity(严重性)”相对照。

    Quality assurance(质量保证QA),采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。

    Regression testing(回归测试),在发生修改之后重新测试先前的测试以保证修改的正确性。理论上,对软件的任何新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再现。

    Review(评审),在产品开发过程中,把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。

    Sanity testing(健全测试),软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考“Smoke testing(冒烟测试)”。

    Screen shot(抓屏、截图),软件测试中,将软件界面中的错误(窗口、菜单、对话框等)的全部或一部分,使用专用工具存储成图像文件,以便于后续处理。

    Severity(严重性),错误对被测系统的影响程度,在终端用户条件下发生的可能性,软件错误妨碍系统使用的程度。与“Priority(优先权)”相对照。

    Smoke testing(冒烟测试),冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。参考“Sanity testing(健全测试)”。

    Software life cycle(软件生命周期),开始于一个软件产品的构思,结束于该产品不再被使用的这段期间。

    Static testing(静态测试),不通过执行来测试一个系统。如代码检查,文档检查和评审等。

    Structured query language(结构化查询语句,SQL),在一个关系数据库中查询和处理数据的一种语言。

    TBD(To be determined,待定),在测试文档中标是一项进行中的尚未最终确定的工作。

    Test(测试),执行软件以验证其满足指定的需求并检测错误的过程。检测已有条件之间的不同,并评价软件项的特性软件项的分析过程。软件工程过程的一个活动,它将软件在预定的条件下运行以判断软件是否符合预期结果。

    Test case(测试用例),为特定目标而开发的一组测试输入、执行条件和预期结果,其目标可以是测试某个程序路径或核实是否满足某个特定的需求。

    Testing coverage(测试覆盖),指测试系统覆盖被测试系统的程度,一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。

    Testing environment(测试环境),进行测试的环境,包括测试平台、测试基础设施、测试实验室和其他设施。

    Testing item(测试项),作为测试对象的工作版本。

    Testing plan(测试计划),描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务,并且任何风险都要冲突计划。

    Testing procedure(测试过程),指设置、执行给定测试用例并对测试结果进行评估的一系列详细步骤。

    Testing scrīpt(测试脚本),一般指的是一个特定测试的一系列指令,这些指令可以被自动化测试工具执行。

    Testing suite(测试包),一组测试用里的执行框架;一种组织测试用例的方法。在测试包里,测试用例可以组合起来创造出独特的测试条件。

    Unit testing(单元测试),指一段代码的基本测试,其实际大小是未定的,通常是一个函数或子程序,一般由开发者执行。

    User interface(用户界面,UI),广义是指使用户可以和计算机进行交互的硬件和/或软件。狭义是指软件中的可见外观及其底层与用户交互的部分(菜单、对话框、窗口和其它控件)。

    User interface testing (用户界面测试),指测试用户界面的风格是否满足客户要求,文字是否正确,页面是否美观,文字,图片组合是否完美,操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

    White box testing(白盒测试),根据软件内部的工作原理分析来进行测试,基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。

    Acceptance testing(验收测试),系统开发生命周期方法论的一个阶段,这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。

    Ad hoc testing (随机测试),没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。

    Alpha testing (α测试),是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。

    Automated Testing(自动化测试),使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试中用得较多。

    Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。

    Black box testing(黑盒测试),指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。

    Bug (错误),有时称作defect(缺陷)或error(错误),软件程序中存在的编程错误,可能会带来不必要的副作用,软件的功能和特性与设计规格说明书或用户需求不一致的方面。软件缺陷表现特征为:软件未达到产品说明书标明的功能;软件出现产品说明书指明不会出现的错误;软件功能超出产品说明书指明的范围;虽然产品说明书未指出但是软件应达到的目标;软件测试人员或用户认为软件难以理解,不易使用,运行速度缓慢等问题。

    Bug report(错误报告),也称为“Bug record(错误记录)”,记录发现的软件错误信息的文档,通常包括错误描述、复现步骤、抓取的错误图像和注释等。

    Bug tracking system(错误跟踪系统,BTS),也称为“Defect tracking system,DTS”,管理软件测试缺陷的专用数据库系统,可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。

    Build(工作版本),软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本,也可以是展示要在最终产品中提供的部分功能的部分系统。

    Compatibility Testing(兼容性测试),也称“Configuration testing(配置测试)”,测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

    Capture/Replay Tool (捕获/回放工具),一种测试工具,能够捕获在测试过程中传递给软件的输入,并且能够在以后的时间中,重复这个执行的过程。这类工具一般在GUI测试中用的较多。

    Crash(崩溃),计算机系统或组件突然并完全的丧失功能,例如软件或系统突然退出或没有任何反应(死机)。

    Debug(调试),开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时,或者根据测试错误报告指出错误以后,开发人员需要执行调试过程来解决已存在的错误。

    Deployment(部署),也称为shipment(发布),对内部IT系统而言,指它的第一个版本通过彻底的测试、形成产品、交付给付款客户的阶段。

    Dynamic testing(动态测试),通过执行软件的手段来测试软件。

    Exception(异常/例外),一个引起正常程序执行挂起的事件。

    Functional testing (功能测试),也称为behavīoral testing(行为测试),根据产品特征、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。

    Garbage characters(乱码字符),程序界面中显示的无意义的字符,例如,程序对双字节字符集的字符不支持时,这些字符不能正确显示。

    GB 18030 testing(GB 18030测试),软件支持GB 18030字符集标准能力的测试,包括GB 18030字符的输入、输出、显示、存储的支持程度。

    Installing testing(安装测试),确保该软件在正常情况和异常情况的不同条件下,例如,进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    Integration testing(集成测试),被测试系统的所有组件都集成在一起,找出被测试系统组件之间关系和接口中的错误。该测试一般在单元测试之后进行。

    International testing(国际化测试),国际化测试的目的是测试软件的国际化支持能力,发现软件的国际化的潜在问题,保证软件在世界不同区域中都能正常运行。国际化测试使用每种可能的国际输入类型,针对任何区域性或区域设置检查产品的功能是否正常,软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语(可选)的混合字符。

    Localizability testing(本地化能力测试),本地化能力是指不需要重新设计或修改代码,将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本,提高测试效率,本地化能力侧是通常在软件的伪本地化版本上进行。本地化能力测试中发现的典型错误包括:字符的硬编码(即软件中需要本地化的字符写在了代码内部),对需要本地化的字符长度设置了国定值,在软件运行时以控件位置定位,图标和位图中包含了需要本地化的文本,软件的用户界面与文档术语不一致等。

    Load testing(负载测试),通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。

    Localization testing(本地化测试),本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试,安装/卸载测试,当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量,包含软件、文档和联机帮助等部分。

    Performance testing(性能测试),评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。

    Pilot testing(引导测试),软件开发中,验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中,引导测试通常是客户检查软件测试公司测试能力的一种形式,只有通过了客户特定的引导测试,软件测试公司才能接受客户真实软件项目的软件测试。

    Portability testing(可移植性测试),测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。
    Priority(优先权),从商业角度出发是指错误的重要性,尤其是从客户和用户的角度出发,是指错误对于系统的可行性和可接受性的影响。与“Severity(严重性)”相对照。

    Quality assurance(质量保证QA),采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。

    Regression testing(回归测试),在发生修改之后重新测试先前的测试以保证修改的正确性。理论上,对软件的任何新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再现。

    Review(评审),在产品开发过程中,把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。

    Sanity testing(健全测试),软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考“Smoke testing(冒烟测试)”。

    Screen shot(抓屏、截图),软件测试中,将软件界面中的错误(窗口、菜单、对话框等)的全部或一部分,使用专用工具存储成图像文件,以便于后续处理。

    Severity(严重性),错误对被测系统的影响程度,在终端用户条件下发生的可能性,软件错误妨碍系统使用的程度。与“Priority(优先权)”相对照。

    Smoke testing(冒烟测试),冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。参考“Sanity testing(健全测试)”。

    Software life cycle(软件生命周期),开始于一个软件产品的构思,结束于该产品不再被使用的这段期间。

    Static testing(静态测试),不通过执行来测试一个系统。如代码检查,文档检查和评审等。

    Structured query language(结构化查询语句,SQL),在一个关系数据库中查询和处理数据的一种语言。

    TBD(To be determined,待定),在测试文档中标是一项进行中的尚未最终确定的工作。

    Test(测试),执行软件以验证其满足指定的需求并检测错误的过程。检测已有条件之间的不同,并评价软件项的特性软件项的分析过程。软件工程过程的一个活动,它将软件在预定的条件下运行以判断软件是否符合预期结果。

    Test case(测试用例),为特定目标而开发的一组测试输入、执行条件和预期结果,其目标可以是测试某个程序路径或核实是否满足某个特定的需求。

    Testing coverage(测试覆盖),指测试系统覆盖被测试系统的程度,一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。

    Testing environment(测试环境),进行测试的环境,包括测试平台、测试基础设施、测试实验室和其他设施。

    Testing item(测试项),作为测试对象的工作版本。

    Testing plan(测试计划),描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务,并且任何风险都要冲突计划。

    Testing procedure(测试过程),指设置、执行给定测试用例并对测试结果进行评估的一系列详细步骤。

    Testing scrīpt(测试脚本),一般指的是一个特定测试的一系列指令,这些指令可以被自动化测试工具执行。

    Testing suite(测试包),一组测试用里的执行框架;一种组织测试用例的方法。在测试包里,测试用例可以组合起来创造出独特的测试条件。

    Unit testing(单元测试),指一段代码的基本测试,其实际大小是未定的,通常是一个函数或子程序,一般由开发者执行。

    User interface(用户界面,UI),广义是指使用户可以和计算机进行交互的硬件和/或软件。狭义是指软件中的可见外观及其底层与用户交互的部分(菜单、对话框、窗口和其它控件)。

    User interface testing (用户界面测试),指测试用户界面的风格是否满足客户要求,文字是否正确,页面是否美观,文字,图片组合是否完美,操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

    White box testing(白盒测试),根据软件内部的工作原理分析来进行测试,基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。
     
    此文来源于51testing博客,转载请注明出处
  • [转贴]软件测试的14种类型

    2007-04-26 11:48:13

    作者:啄木鸟(Sawin网站)

    软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程,其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的类型。

    1 数据和数据库完整性测试

    数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。
    数据库完整性原即:
    主码完整性:主码不能为空;
    外码完整性:外码必须等于对应的主码或者为空。
    数据合理性指数据在数据库中的类型,长度,索引等是否建的比较合理。
    在项目名称中,数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时,不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS),还需要进行深入的研究,以确定可以支1持测试的工具和技术。

    比如,有两张表:部门和员工。部门中有部门编号,部门名称,部门经理等字段,主码为部门编号;员工表中有员工编号,员工所属部门编号,员工名称,员工类型等字段,主码为员工编号,外码为员工所属部门编号,对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空,他就违反主码完整性原则。如果某个员工所属部门的编号为##,但是##在部门编号中确找不到,这就违反外码完整性原则。
    员工类型如下定义:0:职工,1:职员,2:实习生。但数据类型为Int,我们都知道Int占有4个字节,如果定义成char(1).就比原来节约空间。


    2 白盒测试

    白盒测试是基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试
    2.1 静态白盒测试
    利用眼睛,浏览代码,凭借经验,找出代码中的错误或者代码中不符合书写规范的地方。比如,代码规范中规定,函数必须为动宾结构。而黑盒测试发现一个函数定义如下:
    Function NameGet(){
    ….
    }
    这是属于不符合开发规范的错误。
    有这样一段代码:
    if (i<0) & (i>=0)

    这段代码交集为整个数轴,IF语句没有必要
    I=0;
    while(I>100){
    J=J+100;
    T=J*PI;
    }
    在循环体内没有I的增加,bug产生。

    2.2 动态白盒测试
    利用开发工具中的调式工具进行测试。比如一段代码有4个分支,输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。
    看一段代码
    if(I<0){
    P1
    }else{
    P2
    }
    在调试中输入I=-1,P1程序段通过, P2程序段未通过,属于动态黑盒测试的缺陷

    3.功能测试

    功能测试指测试软件各个功能模块是否正确,逻辑是否正确。
    对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面 (GUI) 与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。
    比如一个对电子商务系统,前台用户浏览商品-放入购物车-进入结账台,后台处理订单,配货,付款,发货,这一系列流程必须正确无误的走通,不能存在任何的错误。

    4.UI测试

    UI测试指测试用户界面的风格是否满足客户要求,文字是否正确,页面美工是否好看,文字,图片组合是否完美,背景是否美观,操作是否友好等等
    用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外,UI 测试还可确保 UI 中的对象按照预期的方式运行,并符合公司或行业的标准。包括用户友好性,人性化,易操作性测试。UI测试比较主观,与测试人员的喜好有关
    比如:页面基调颜色刺眼;用户登入页面比较难于找到,文字中出现错别字,页面图片范围太广等都属于UI测试中的缺陷,但是这些缺陷都不太严重。

    5.性能测试

    性能测试主要测试软件测试的性能,包括负载测试,强度测试,数据库容量测试,基准测试以及基准测试
    5.1负载测试
    负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。
    在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。
    比如,在B/S结构中用户并发量测试就是属于负载测试的用户,可以使用webload工具,模拟上百人客户同时访问网站,看系统响应时间,处理速度如何?
    5.2强度测试
    强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。
    实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
    比如:一个系统在内存366M下可以正常运行,但是降低到258M下不可以运行,告诉内存不足,这个系统对内存的要求就是366M。
    5.3数据库容量测试
    数据库容量测试指通过存储过程往数据库表中插入一定数量的数据,看看相关页面是否能够及时显示数据。
    数据库容量测试使测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如,如果测试对象正在为生成一份报表而处理一组数据库记录,那么容量测试就会使用一个大型的测试数据库,检验该软件是否正常运行并生成了正确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录,计算相关页面的调用时间。
    比如,在电子商务系统中,通过insert customer 往user表中插入10 000数据,看其是否可以正常显示顾客信息列表页面,如果要求达到最多可以处理100 000个客户,但是顾客信息列表页面不能够在规定的时间内显示出来,就需要调整程序中的SQL查询语句;如果在规定的时间内显示出来,可以将用户数分别提高到20 000 , 50 000, 100 000进行测试。
    5.4基准测试
    基准测试与已知现有的系统进行比较,主要检验是否与类似的产品具有竞争性的一种测试。
    如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据,你可以测试你这套系统,看看哪些地方比用友财务系统好,哪些地方差?以便改进自己的系统,也可为产品广告提供数据。
    5.5竞争测试
    软件竞争使用各种资源(数据纪录,内存等),看他与其他相关系统对资源的争夺能力。比如:一台机器上即安装您的财务系统,又安装用友财务系统。当CPU占有率下降后,看看是否能够强过用友财务系统,而是自己的系统能够正常运行?

    6. 安全性和访问控制测试

    安全性和访问控制测试侧重于安全性的两个关键方面:
    应用程序级别的安全性,包括对数据或业务功能的访问
    系统级别的安全性,包括对系统的登录或远程访问。
    6.1应用程序级别的安全性
    可确保:在预期的安全性情况下,主角只能访问特定的功能或用例,或者只能访问有限的数据。例如,可能会允许所有人输入数据,创建新账户,但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性,测试就可确保“用户类型一”能够看到所有客户消息(包括财务数据),而“用户二”只能看见同一客户的统计数据。
    比如B/S系统,不通过登入页面,直接输入URL,看其是否能够进入系统?
    6.2系统级别的安全性
    可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问。
    比如输入管理员账户,检查其密码是否容易猜取,或者可以从数据库中获得?

    7.故障转移和恢复测试

    故障转移和恢复测试指当主机软硬件发生灾难时候,备份机器是否能够正常启动,使系统是否可以正常运行,这对于电信,银行等领域的软件是十分重要的。
    故障转移和恢复测试可确保测试对象能成功完成故障转移,并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
    故障转移测试可确保:对于必须持续运行的系统,一旦发生故障,备用系统就将不失时机地“顶替”发生故障的系统,以避免丢失任何数据或事务。
    恢复测试是一种对抗性的测试过程。在这种测试中,将把应用程序或系统置于极端的条件下(或者是模拟的极端条件下),以产生故障(例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字)。然后调用恢复进程并监测和检查应用程序和系统,核实应用程序或系统和数据已得到了正确的恢复。一定要注意主备定时备份
    比如电信系统,突然主机程序发生死机,备份机器是否能够启动,使系统能够正常运行,从而不影响用户打电话?
    8.配置测试

    又叫兼容性测试。配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。(如浏览器版本,操作系统版本等)
    下面列出主要配置测试
    8.1浏览器兼容性
    测试软件在不同产商的浏览器下是否能够正确显示与运行;
    比如测试IE,Natscape浏览器下是否可以运行这套软件?
    8.2操作系统兼容性
    测试软件在不同操作系统下是否能够正确显示与运行;
    比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件?
    8.3硬件兼容性
    测试与硬件密切相关的软件产品与其他硬件产品的兼容性,比如该软件是少在并口设备中的,测试同时使用其他并口设备,系统是否可以正确使用.
    比如在INTER,舒龙CPU芯片下系统是否能够正常运行?
    这样的测试必须建立测试实验室,在各种环境下进行测试。

    9.安装测试

    安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如,进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。
    安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    10.多语种测试

    又称本地化测试,是指为各个地方开发产品的测试,如英文版,中文版等等,包括程序是否能够正常运行,界面是否符合当地习俗,快捷键是否正常起作用等等,特别测试在A语言环境下运行B语言软件(比如在英文win98下试图运行中文版的程序),出现现象是否正常。
    本地化测试还要考虑:
    l 当语言从A翻译到B,字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”,翻译到英文版本中为 “View advertisement”可能影响页面的美观程度
    l 要考虑同一单词在各个国家的不同意思,比如football在英文中为足球,而美国人使用中可能理解为美式橄榄球。
    l 要考虑各个国家的民族习惯,比如龙个美国中被理解邪恶的象征,但翻译到中国,中国人认为为吉祥的象征。

    11.文字测试

    文字测试测试软件中是否拼写正确,是否易懂,不存在二义性,没有语法错误;文字与内容是否有出入等等,包括图片文字。
    比如:“比如,请输入正确的证件号码!”何谓正确的证件号码,证件可以为身份证,驾驶证,也可为军官证,如果改为“请输入正确的身份证号码!”用户就比较容易理解了。

    12.分辨率测试

    测试在不同分辨率下,界面的美观程度,分为800*600,1024*768,1152*864,1280*768,1280*1024,1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率,而在其他分辨率下也都能可以运行。

    13发布测试

    主要在产品发布前对一些附带产品,比如说明书,广告稿等进行测试

    13.1说明书测试
    主要为语言检查,功能检查,图片检查
    语言检查:检查说明书语言是否正确,用词是否易于理解;
    功能检查:功能是否描述完全,或者描述了并没有的功能等;
    图片检查::检查图片是否正确
    13.2宣传材料测试
    主要测试产品中的附带的宣传材料中的语言,描述功能,图片
    13.3帮助文件测试
    帮助文件是否正确,易懂,是否人性化。最好能够提供检索功能。
    13.4广告用语
    产品出公司前的广告材料文字,功能,图片,人性化的检查

    14 文档审核测试

    文档审核测试目前越来越引起人们的重视,软件质量不是检查出来的,而是融进软件开发中来。前置软件测试发越来越受到重视。请看一个资料:

    文档审核测试主要包括需求文档测试,设计文档测试,为前置软件测试测试中的一部分。

    14.1需求文档测试

    主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现;

    14.2设计文档测试

    测试设计是否符合全部需求以及设计是否合理。

    总结

    据美国软件质量安全中心2000年对美国一百家知名的软件厂商统计,得出这样一个结论:软件缺陷在开发前期发现比在开发后期发现资金,人力上节约90%;软件缺陷在推向市场前发现比在推出后发现资金,人力上节约90%。所以说软件的缺陷应该尽早发现。不是所有的软件都要进行任何类型的软件测试的,可以根据产品的具体情况进行组装测试不同的类型。

    参考文献
    《Rational统一过程模型》
    《软件测试》

  • [转贴]软件回归测试及其实践

    2007-04-26 11:35:18

    软件回归测试及其实践

    来源:赛宝软件评测中心 作者:信息产业部电子第五研究所 李丹 刘杰

    摘要:本文描述了软件回归测试的概念和进行回归测试的基本步骤,介绍了可用于回归测试的测试用例库的维护方法,给出了几种可以可保证回归测试效率和有效性的回归测试策略,总结了回归测试时应该注意的一些实际问题。

    关键词:回归测试;测试用例;基线测试用例库

    Software Regression Testing and It’s Practice

    Abstract:The article present the conception of regression testing and the step of executing this testing. Introduce how to maintenance the test case library which used in regression testing ,and provide the method of ensure regression testing’s validity. Finally, it gives some problem must be careful in the period of regression testing.

    Keywords:regression testing;test case;baseline test case library

    作者简介:李丹(1978-),女,江苏如东人,信息产业部电子第五研究所助理工程师,从事软件可靠性研究及测试工作。

    一、 概述

    在软件生命周期中的任何一个阶段,只要软件发生了改变,就可能给该软件带来问题。软件的改变可能是源于发现了错误并做了修改,也有可能是因为在集成或维护阶段加入了新的模块。当软件中所含错误被发现时,如果错误跟踪与管理系统不够完善,就可能会遗漏对这些错误的修改;而开发者对错误理解的不够透彻,也可能导致所做的修改只修正了错误的外在表现,而没有修复错误本身,从而造成修改失败;修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题,使本来工作正常的功能产生错误。同样,在有新代码加入软件的时候,除了新加入的代码中有可能含有错误外,新代码还有可能对原有的代码带来影响。因此,每当软件发生变化时,我们就必须重新测试现有的功能,以便确定修改是否达到了预期的目的,检查修改是否损害了原有的正常功能。同时,还需要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。

    回归测试在软件生命周期中扮演着重要的角色,因忽视回归测试而造成严重后果的例子不计其数,导致阿里亚娜5型火箭发射失败的软件缺陷就是由于复用的代码没有经过充分的回归测试造成的。

    回归测试作为软件生命周期的一个组成部分,在整个软件测试过程中占有很大的工作量比重,软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中,新版本的连续发布使回归测试进行的更加频繁,而在极端编程方法中,更是要求每天都进行若干次回归测试。因此,通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。

    二、 回归测试策略

    对于一个软件开发项目来说,项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中,并对其进行维护和管理。当得到一个软件的基线版本时,用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候,就可以根据所选择的回归测试策略,从基线测试用例库中提取合适的测试用例组成回归测试包,通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本,也有可能是测试用例的手工实现过程。

    回归测试需要时间、经费和人力来计划、实施和管理。为了在给定的预算和进度下,尽可能有效率和有效力地进行回归测试,需要对测试用例库进行维护并依据一定的策略选择相应的回归测试包。

    1、测试用例库的维护

    为了最大限度地满足客户的需要和适应应用的要求,软件在其生命周期中会频繁地被修改和不断推出新的版本,修改后的或者新版本的软件会添加一些新的功能或者在软件功能上产生某些变化。随着软件的改变,软件的功能和应用接口以及软件的实现发生了演变,测试用例库中的一些测试用例可能会失去针对性和有效性,而另一些测试用例可能会变得过时,还有一些测试用例将完全不能运行。为了保证测试用例库中测试用例的有效性,必须对测试用例库进行维护。同时,被修改的或新增添的软件功能,仅仅靠重新运行以前的测试用例并不足以揭示其中的问题,有必要追加新的测试用例来测试这些新的功能或特征。因此,测试用例库的维护工作还应包括开发新测试用例,这些新的测试用例用来测试软件的新特征或者覆盖现有测试用例无法覆盖的软件功能或特征。

    测试用例的维护是一个不间断的过程,通常可以将软件开发的基线作为基准,维护的主要内容包括下述几个方面。

    (1)、删除过时的测试用例

    因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统,这些测试用例就会过时。例如,某个变量的界限发生了改变,原来针对边界值的测试就无法完成对新边界测试。所以,在软件的每次修改后都应进行相应的过时测试用例的删除。

    (2)、改进不受控制的测试用例

    随着软件项目的进展,测试用例库中的用例会不断增加,其中会出现一些对输入或运行状态十分敏感的测试用例。这些测试不容易重复且结果难以控制,会影响回归测试的效率,需要进行改进,使其达到可重复和可控制的要求。

    (3)、删除冗余的测试用例

    如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试,那么这些测试用例是冗余的。冗余测试用例的存在降低了回归测试的效率。所以需要定期的整理测试用例库,并将冗余的用例删除掉。

    (4)、增添新的测试用例

    如果某个程序段、构件或关键的接口在现有的测试中没有被测试,那么应该开发新测试用例重新对其进行测试。并将新开发的测试用例合并到基线测试包中。

    通过对测试用例库的维护不仅改善了测试用例的可用性,而且也提高了测试库的可信性,同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。

    2、回归测试包的选择

    在软件生命周期中,即使一个得到良好维护的测试用例库也可能变得相当大,这使每次回归测试都重新运行完整的测试包变得不切实际。一个完全的回归测试包括每个基线测试用例,时间和成本约束可能阻碍运行这样一个测试,有时测试组不得不选择一个缩减的回归测试包来完成回归测试。

    回归测试的价值在于它是一个能够检测到回归错误的受控实验。当测试组选择缩减的回归测试时,有可能删除了将揭示回归错误的测试用例,消除了发现回归错误的机会。然而,如果采用了代码相依性分析等安全的缩减技术,就可以决定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏。

    选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括:

    (1)、再测试全部用例

    选择基线测试用例库中的全部测试用例组成回归测试包,这是一种比较安全的方法,再测试全部用例具有最低的遗漏回归错误的风险,但测试成本最高。全部再测试几乎可以应用到任何情况下,基本上不需要进行分析和重新开发,但是,随着开发工作的进展,测试用例不断增多,重复原先所有的测试将带来很大的工作量,往往超出了我们的预算和进度。

    (2)、基于风险选择测试

    可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试,而跳过那些非关键的、优先级别低的或者高稳定的测试用例,这些用例即便可能测试到缺陷,这些缺陷的严重性也仅有三级或四级。一般而言,测试从主要特征到次要特征。

    (3)、基于操作剖面选择测试

    如果基线测试用例库的测试用例是基于软件操作剖面开发的,测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定,回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例,释放和缓解最高级别的风险,有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠性,但实施起来有一定的难度。

    (4)、再测试修改的部分

    当测试者对修改的局部化有足够的信心时,可以通过相依性分析识别软件的修改情况并分析修改的影响,将回归测试局限于被改变的模块和它的接口上。通常,一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下,回归测试尽可能覆盖受到影响的部分。

    再测试全部用例的策略是最安全的策略,但已经运行过许多次的回归测试不太可能揭示新的错误,而且很多时候,由于时间、人员、设备和经费的原因,不允许选择再测试全部用例的回归测试策略,此时,可以选择适当的策略进行缩减的回归测试。

    3、回归测试的基本过程

    有了测试用例库的维护方法和回归测试包的选择策略,回归测试可遵循下述基本过程进行:

    (1). 识别出软件中被修改的部分;

    (2). 从原基线测试用例库T中,排除所有不再适用的测试用例,确定那些对新的软件版本依然有效的测试用例,其结果是建立一个新的基线测试用例库T0。

    (3). 依据一定的策略从T0中选择测试用例测试被修改的软件。

    (4). 如果必要,生成新的测试用例集T1,用于测试T0无法充分测试的软件部分。

    (5). 用T1执行修改后的软件。

    第(2)和第(3)步测试验证修改是否破坏了现有的功能,第(4)和第(5)步测试验证 修改工作本身。

    三、 回归测试实践

    在实际工作中,回归测试需要反复进行,当测试者一次又一次地完成相同的测试时,这些回归测试将变得非常令人厌烦,而在大多数回归测试需要手工完成的时候尤其如此,因此,需要通过自动测试来实现重复的和一致的回归测试。通过测试自动化可以提高回归测试效率。为了支持多种回归测试策略,自动测试工具应该是通用的和灵活的,以便满足达到不同回归测试目标的要求。

    在测试软件时,应用多种测试技术是常见的。当测试一个修改了的软件时,测试者也可能希望采用多于一种回归测试策略来增加对修改软件的信心。不同的测试者可能会依据自己的经验和判断选择不同的回归测试技术和策略。

    回归测试并不减少对系统新功能和特征的测试需求,回归测试包应包括新功能和特征的测试。如果回归测试包不能达到所需的覆盖要求,必须补充新的测试用例使覆盖率达到规定的要求。

    回归测试是重复性较多的活动,容易使测试者感到疲劳和厌倦,降低测试效率,在实际工作中可以采用一些策略减轻这些问题。例如,安排新的测试者完成手工回归测试,分配更有经验的测试者开发新的测试用例,编写和调试自动测试脚本,做一些探索性的或ad hoc测试。还可以在不影响测试目标的情况下,鼓励测试者创造性地执行测试用例,变化的输入、按键和配置能够有助于激励测试者又能揭示新的错误。

    在组织回归测试时需要注意两点,首先是各测试阶段发生的修改一定要在本测试阶段内完成回归,以免将错误遗留到下一测试阶段。其次,回归测试期间应对该软件版本冻结,将回归测试发现的问题集中修改,集中回归。

    在实际工作中,可以将回归测试与兼容性测试结合起来进行。在新的配置条件下运行旧的测试可以发现兼容性问题,而同时也可以揭示编码在回归方面的错误。

    参考文献:

    [1] Glenford J.Myers,计算机软件测试技巧,清华大学出版社,1985。

    [2] Robert V. Binder,面向对象系统的测试,人民邮电出版社,2001。

    [3] Rex Black, 测试流程管理,北京大学出版社,2001。
  • [转贴]软件测试职业发展方向-作者:叶赫华

    2007-04-26 11:01:35

    软件测试职业发展三步曲之一

    ——软件测试职业发展方向

    作者:叶赫华

       天地玄黄,宇宙洪荒;所谓光阴似箭,因为一转眼滚滚的历史车轮就将人类文明推进了二十一世纪的信息时代!葛大爷有对白曰:“二十一世纪最宝贵的是什么?”对曰:“人才!”何为人才?sincky曰:“适应时代潮流,把握社会需求,并为我中华老大帝国创造社会价值的人!”哎哟,不诹了,其实今天笔者在这里要和大家探讨的,是软件测试的职业发展问题,重点要阐述的是软件测试从业者的职业发展方向,欢迎大家按enter键换行,继续浏览!

       一个人从大学毕业,即开始发生从学生时代向职业人士的过渡,这种过渡走的好,可以实现毕生宿愿,体现个人价值,不管你是否喜欢,功名、利禄尽收眼底;如果走的不好,则会误入歧途,纵有凌云壮志、万丈豪情,难免一生郁郁不得志,终归化作片片飞尘,无语对穹苍!那么如何才能顺利的完成这种过渡、踏上我们豪迈的职业旅程呢?答曰:认清自己,选择适途!战国的魏人荆轲具有“十步杀一人,千里不留行”的本领,曾向魏王献策曰:“国君,我是职业杀手,我杀人的技术很强!”魏王问:“那么你想杀谁呢?”对曰:“杀他个国君如何?”魏王大惊,慌然离去!后来荆轲离开魏国,与燕太子丹密谋,留下了“图穷匕首见”、“荆轲刺秦王”的千古佳话。荆轲,良禽也,择木而栖和太子丹合作,是他的高明之处;不过笔者认为他是一个典型的“低管理、高技能”的人才,当他紧握嬴政的脖领、持剑相逼时,他太得意忘性了,可见他没有领导的“统御力”和“决断力”,所以落了个刺杀失败、拔剑自刎的下场,虽然他的侠义与胆识流畅千古,但是终究是个“杀手”而已;当今社会下,如果“低管理、高技能”的人干工作干到丢了性命,那也真是一个笑谈了!

       目前我们国家高等学历大幅度扩招,造成社会的低端人才严重过剩,大学生毕业找不到工作、或者找不到合适的工作例子鳞次栉比;但是社会各行各业对高端人才的需求又求贤若渴;那么如何解决这种矛盾呢?从大环境来说,国家应该改革教育体制、提高教学质量、重视高端人才的培养,但是,一个问题一旦上升到国家的层次,就要等它个十年八年!我们没有办法改变世界,但是我们有能力改变自己;所以我们从个人的角度来讲,讲讲我们这些软件测试的从业者们,如何“认清自己、选择适途!”

       纵观当今社会各行各业,对于个人的职业发展方向,从宏观上都可以划分为四个群体,即:

       “低管理、低技能”
       “高管理、低技能”
       “低管理、高技能”
       “高管理、高技能”

       而在IT 行业这种划分方法更为合理,sincky为其命名为“一起点-三方向示意图”:

       告别了象牙塔,带着对校园生活里那段风花雪月的追忆,年轻的毕业生们走上了社会;这时候的年轻人,大多数是属于“低管理、低技能”的群体,我们没有工作经验,不知道企业的工作流程,不清楚各个职业的工作技能,更不具备任何行业的管理能力;然而值得庆幸的是,人类问明发展到现在所出现的众多行业,都已经有了众多可以参考的群体,这些群体就理所当然的成了我们可以借鉴的发展方向!虽然我们的起点都是一个,但是可以选择的发展方向却是丰富多样!

       高管理-低技能,即是我们通常所说的管理路线!在IT业,这个方向的成功者不乏项目经理、项目总监直至企业的最高管理层;但是走这个方向也要有技术方面的积累,因为管理者的影响力中,除了职位赋予的权力以外,还包括个人人格方面的能力和专业领域的专业能力,而后者就是技术水平!而计算机行业本身,也决定了技术底蕴对职业发展的重要影响,所以年轻的IT朋友们,如果想为自己的职业人生设计成这个路线,除了适当的技术积累外,更要有意识的锻炼自己的管理素质,下图可做参考:

       低管理-高技能,即通常所说的技术路线!IT业以技术为主导,对于喜欢钻研技术、探讨技术的人,可以选择该条路线,走的深入、走的彻底!只因中国对于技术与管理的认识不同,造成很多人认为做技术不赚钱、不被重视,自身误以为不过是个工程师而已,所做事情只是辅助企业的运作。实际上,在欧美发达国家,资深技术人员的薪资非常高,从业时间的周期也相当长,在Microsoft、IBM等巨头企业,不乏年龄在50岁以上的资深程序员或系统架构师,而其薪资也和高级管理者一样高!而另外一个不争的事实是,企业对于管理的职位是有限的,并且一些优秀的技术人员不愿做管理,或者不适合做管理,因此社会上出现的资深技术专家(或者类似职位),为喜好技术的从业人员提供向上的通道。

       高管理-高技能,即咨询方向是较为均衡、全面的路线,也是众多企业希望员工努力的方向。然而有调查结果显示,由于现实种种因素的制约,大约90%的个人是分别沿着管理方向或者专家方向发展的,真正实现在咨询方向达到一定的高度的人少之又少,而且在这为数不多的咨询方向达到又一定高度的人才,往往又会由于企业资源的限制无法将个人价值完全发挥而最终离开所在企业,成为专业培训师、咨询师;一些国际知名的咨询公司如麦肯锡、安达信乃至毕博或其他,可谓大家在个人职业生涯到达一定阶段,作为自己继续突破职业瓶颈的发展路线。

       那么,对于软件测试的从业者,我们的出路在哪里?我们的职业发展该如何设计?我们的发展方向又有哪些呢?这里笔者和大多数测试同行意识相同,笔者也曾在多篇文章里标明,中国的软件测试行业尚属起步阶段,其发展的步履上布满了荆棘与泥泞;然而其发展速度可谓惊人的,从笔者刚毕业时候对软件测试的“0”概念、从业同行者寥寥无几,到最近2年的各大媒体纷纷报道的中国软件测试人才缺口20万、软件测试工程师将成为未来10年最紧缺的人才之一、包括笔者所接触的众多国内外优秀企业对高端测试人才年薪10万、15万、20万的招聘需求……可见,选择软件测试这个朝阳行业的朋友,做了一个比较正确的选择!然而,如何任何事物总有它的两面性和矛盾性:2006年初在北京、上海、深圳举办的几次春季大型招聘会上,多家企业纷纷打出各类高薪招聘软件测试人员的海报,出人意料的是,收到的简历尚不足招聘岗位数的50%,而合格的竟不足30%……引起我们思考的是,我们的软件测试从业人员还有很大一部分不满足当今社会的需求;而另一层含义是,我们还有很大的提升空间!因此解决该矛盾的突破点是:每个人在这个行业里找到自己的发展方向,规划自己的职业蓝图,从而有针对性的锻炼自己的职业技能,增加个人的职业砝码!

       软件测试职业发展方向,大体上与上述的通用职业发展路线图相吻合,也可以分为管理路线、技术路线、管理+技术路线;只是针对该行业本身,有其特殊性和细致性。其图示如同两个重叠的”V”字样,我们为其命名为“双V模型”;该模型适用于大多数行业性软件测试从业人员,一些特殊领域如游戏测试、嵌入式测试、硬件测试,也可作为参考。本文是三部曲之一,只介绍职业发展方向定义,在下一曲会介绍各个职业方向应该具备的知识与技能体系!

       双V的底点是测试工程师,属于软件测试职业生涯的初级域,其适用范围是入行软件测试3年内的常规测试从业者,其主要工作内容是按照测试主管(即直接上司)分配的任务计划,编写测试用例、执行测试用例、提交软件缺陷,包括提交阶段性测试报告、参与阶段性评审等。初入测试行业,进入企业从事测试工作的人员,都要从该层次做起,虽然有时感觉乏味无趣,甚至迷茫困惑,但是我们可以根据个人的兴趣与特长,向上选择适合自己的路线,因为谁都不会甘心一辈子只做一个普通的测试工程师,那么大家看到这里,就可以摩拳擦掌,看看向上发展的通道中,哪一个适合自己,然后立刻从现在开始,确定自己未来5年、10年甚至一生的发展目标迈进,用笔者经常跟学员说的一句话来形容:把握现在,即刻做起,相信自己是最强的!

       首先是常规路线,即双V模型的重叠线,这条发展路线要求管理与技术并重,因为软件测试的行业特点决定了这个因素:测试工程师向上晋升到测试主管、测试经理、测试总监,直至咨询域的更高方向!

       测试主管是企业项目级主管,对于中小型软件公司也可以是企业级主管,属于中级发展域,适用范围是2到5年职业经验的测试从业者。其工作内容是根据项目经理或测试经理的计划安排,调配测试工程师执行模块级或项目级测试工作,并控制与监督软件缺陷的追踪,保证每个测试环节与阶段的顺利进行。严格来说,这个级别更多属于测试的设计者,因为企业的测试流程搭建是由更高级别的测试经理或相关管理者来做的,测试主管负责该流程的具体实施;而更多的工作,是思考如何对软件进行更加深入、全面的测试。因此笔者认为测试主管比较有创造性的工作内容就是测试设计,而恰恰很多公司忽略了或没有精力来执行此工作内容!应该说,在一个企业里做了3年左右测试工作的人员,很容易晋升到该职位,而之所以晋升,是与个人测试技术的过硬、测试方法的丰富,加上对测试流程的监控力与执行力的职业素质息息相关!

       测试经理是更高级别的测试管理者,属于高级测试方向域。对于大中型软件公司,该职位尤为重要,并且对其职业要求也比较高,一般适合4到8年的测试从业者,在管理与技术能力双双比较成熟的情况下,可以结合具体环境晋升到该级别。测试经理负责企业级或大型项目级总体测试工作的策划与实施。随着软件行业的发展,企业对软件工程里各个角色的定位逐渐明显,测试经理完全与开发经理(一些公司也成为项目经理)平齐,除了需要统筹整个企业级或项目级测试流程外,还要对于不同软件架构、不同开发技术下的测试方法进行研究与探索,为企业的测试团队成员提供指导与解决思路,同时还要合理调配不同专项测试的人力资源(如业务测试工程师、自动化测试工程师、白盒测试工程师、性能测试工程师),对软件进行全面的测试;另外,一些企业里,测试经理还需要与客户交流与沟通,负责部分的销售性或技术支持性工作。嘿嘿,看看那些高薪招聘测试经理的企业对该职位的要求里外语口语的描述,就可见一斑!

       测试总监,属于常规发展路线的最高域,如果再往上发展,那只能是咨询域了;不过笔者并没有将其在图中标记出来,因为该职位对于国内目前的大多数软件公司根本没有设立,也就没必要再在图中体现了。该职位一般在大型或跨国型软件企业,或者专向于测试服务型企业有所设立,由于其企业自身的职位定位不同,以及软件测试整体行情所处的阶段,这里不好归纳陈述;但是一般设立测试总监的企业,该职位都相当于CTO或副总的级别,是企业级或集团级测试工作的最高领导者,驾驭着企业全部的测试与测试相关资源,管理着企业的全部测试及质量类工作。而其职业要求,也是技术与管理双结合;基于目前软件测试行情看,这种高管理-高技能的发展目标,不会适合大多数人的选择,社会也不会提供如此众多的测试总监职位让我们去应征!

       应该说,大多数测试从业者都不是技术与管理双优的人,而如今一些到达测试经理或测试总监级别的优秀测试人才,已经领先一步开辟了这条发展路线的先河,希望这些朋友和大家多多分享经验,让更多的朋友弥补自己管理或技术上的不足,在这条路线上有所建树,共同提高,在实现个人人生价值的同时,也自然而然的推动了软件测试行业的发展;行业发展了,测试人员不再被忽视了,待遇自然也提高了,也就不会有很多朋友迷茫的跟我说“我的日常工作只是点击按钮和按键盘”了,因为我们相信行业的不断成熟,会逐渐将软件测试职业细化,我们的从业者就可以真正的在如下的管理路线和技术路线找到自己的位置,并潜心走向深入的!

       软件测试,是技术主导的职业;不管选择哪条发展路线,都是需要一定的技术沉淀,只是相对来说,管理路线对技术方面要求不高而已。那么我们就先挑重头的技术路线展开讨论。一般来说,一个普通的测试工程师刚入行,3个月左右熟悉企业的工作流程和模式,那么今后的工作内容趋于平稳。然而社会是残酷的!如果单单停留在测试工程师的阶段,若干年后,相信你再也竞争不过那个时候的应届毕业生,当你的工作技能和职业素质趋于与那些朝气蓬勃的年轻人相当时,企业会毫不留情的选择他们,而release你,因为你的成本消耗要比他们高,这是大实话!然而现实又是公平的!因为软件开发技术的不断日新月异,软件功能需求的不断丰富多样,决定软件开发这一系统工程的错综复杂,因此为了保证软件的质量,就要提高测试的水平,这也就为软件测试职业的细化起到先决因素,也是目前社会上出现招聘专项测试工程师的必然趋势!因此,这个趋势给了我们这些常规测试工程师一个空前的好机会!所谓“以毒攻毒”,软件开发靠的是技术,为了测试软件,也必须用技术;那么我们就来看一下从技术路线,软件测试职业发展有哪些方向。

       技术路线,笔者结合国内外软件测试行业现状,划分为三个半方向,分别是自动化测试工程师、白盒测试工程师、性能测试工程师和认证测试工程师,在“双V模型”中右侧体现;前三者适用于通用软件测试领域,认证测试工程师乃嵌入式测试领域职位,至少目前仅出现在嵌入式领域,因此以虚线标记,即“三个半”的“半”。前三条路线对技术的要求程度逐渐增加,三条曲线的斜率也依次递增(认证工程师不参与比较)。

       自动化测试工程师,笔者为其定义在功能测试范畴,指通常所说的依靠自动化测试工具进行软件黑盒测试的工程师。笔者接触的很多测试界朋友,尤其年轻的刚入行者,对测试工具充满了无限的兴趣,他们喜欢那种编写脚本、调试成功后的快感,喜欢看到自定义的日志里记录了本来手工测试烦琐的无聊头顶的工作、而采用自动化方式实现后如此清晰丰富的内容后的兴奋!可以理解,因为笔者也是从那段时光走过来的,现在也负责于我们学员的自动化测试教学工作。从大环境讲,自动化测试是软件测试执行阶段的必然趋势,社会对于软件测试的认可度以及对自动化测试人才的需求必将日益增加,从目前国内做自动化测试的从业者薪资情况看,也普遍高于常规测试工程师,最浅显的道理是“自动化测试比手工测试有了技术含量,^--^”虽然自动化测试在整个行业的普及不是一朝一夕,但是从个人角度讲,自动化测试可以作为个人的发展方向之一,因为如果你率先掌握了这种技术,等到社会需要时,你已成为这个职位的成熟操作者!而国内的51testing把握了时代前沿,与自动化测试工具巨头厂商Mercury(美科利)合作,在中国唯一推出Mercury自动化测试全套技能认证(CPE/SP/CPC),相比其它初等认证,它的实效性和价值性更具意义,也为测试从业者提供了一个进入自动化测试领域的快捷方式!

       白盒测试工程师,笔者定位于在软件测试周期的单元测试阶段对软件进行的代码级测试的人,包括代码走读、代码功能与逻辑测试、代码内存泄漏检查、代码运行效率检查、代码测试覆盖率分析等。如果说,自动化测试只是依靠脚本语言完成测试脚本编写与调试的过程(因为自动化测试工程师的工作重点不在编写脚本),对于自动化测试工程师的技术要求要相对偏低的话,那么白盒测试工程师就要对大型程序开发语言的完全掌握,因此其技术要求相对偏高!而另一方面,白盒测试在目前国内软件行情下,一些公司根本不做,其成本高、代价大的特点决定了这个现状,而一些对软件质量要求非常高(如军事类、电信类、财务金融类等)的企业,也会调动开发工程师来实施此事。但是,还是那句话,测试行业在发展,测试人员能力在提升,软件的开发技术在复杂化,要对软件进行尽可能全面的测试,白盒测试不可忽视!当下专门高薪招聘白盒测试工程师的企业也比比皆是,从中我们可以感知,白盒测试工程师会是很多有开发背景、意欲进入测试行业的良好突破口,白盒测试人员的需求也会逐渐增加。

       性能测试工程师,即在系统测试阶段、功能测试后对软件系统性能指标进行采集分析和运行效率检测的人。笔者认为,在一个尽量压缩的测试流程里,功能测试可以手工进行,白盒测试可以不做,但是性能测试必须要做,除非该软件非网络类软件即单机版软件!这里笔者再提一个观点供大家参考:软件测试,从宏观上可以划分为三个大方面:功能测试、性能测试、安全性测试,功能测试说明软件做对了,功能测试+性能测试说明软件做好了,三者结合起来说明软件做的非常好!安全测试暂且抛之不提,这是下一个发展域的内容,但是为了把软件做好,为了真正保证软件的质量,性能测试绝不容忽视;只因目前很多企业由于时间、成本、人力条件的限制,暂且不做性能测试。性能测试工程师相对来说,是三个技术路线里技术要求最高的,因为软件的性能瓶颈归根结底落实到代码的运行效率这个问题上,因此性能测试要做好,性能测试工程师起码要懂开发;而为了发现性能问题,要懂软件开发架构;为了定位性能问题,要懂操作系统、网络协议、应用服务器乃至数据库的原理与使用;为了最终解决性能问题,要根据定位的问题有针对性的对代码、操作系统、网络架构、服务器、数据库进行优化!当然性能测试是一个系统工程师,绝对不是一两个人的事情,对于常规性能测试工程师,具备定位性能问题的能力即可。正因为性能测试工程师技术要求的高超,该职位的待遇也是目前测试技术路线最高薪的一个,实为综合技术能力较强的测试人员的明智选择!

       上述四职业路线由于其技术程度的突出,一般在企业里由测试经理直接所属,与测试主管级别具有相同的待遇,并处于相同发展域。

       进入技术路线的高级域,根据中级域的四个路线,可以细分成五个路线,分别是资深自动化测试工程师、资深白盒测试工程师、资深性能测试工程师、安全性测试工程师、标准化工程师,这些高级技术类人才完全与常规测试经理平齐,属于软件测试职业发展高级域。

       资深自动化测试工程师由自动化测试工程师晋升而来。如果说常规自动化测试工程师只是负责自动化测试脚本本身的设计与开发,那么资深自动化测试工程师的工作内容就是自动化测试这项工作的实施!笔者早年在IBM公开讲座时候,讲过一篇《以RUP原则实施自动化测试》的主题,RUP里提倡自动化测试是一个庞大的系统工程,绝对不是有了技术、有了工具、有了掌握技术和使用工具的人就可以实施的,而是应该把自动化测试当成一个针对企业自身的项目来看待,需要经过引入、计划、设计、测试、执行、配置管理等环节(参加sincky的blog“天行健-君子以自强不息”),而这些自动化测试的流程搭建,就是资深自动化测试工程师的份内之事。另外,笔者要强调,按照国内外自动化测试领域的发展趋势,我们把自动化测试划分为四个发展阶段(我的blog里也有阐述);也就是说,录制脚本-添加验证点-回放脚本只是最初始的自动化阶段,要在企业实施自动化测试,要有资深自动化测试工程师来设计数据驱动,开发测试框架,甚至一些企业内部自主开发小型测试工具(而非商业工具)的先例,这些也都是建立在资深自动化测试工程师具有深厚的技术底蕴后,主导其他人员协调完成的事情。

       资深白盒测试工程师,其工作内容包含常规白盒测试工程师的内容,除此之外,要协助测试经理或测试总监攻关测试方法与技术性难题,因此其技术水平更加雄厚。如果常规白盒测试工程师是停留在某种程序设计语言类型的代码级测试,那么资深白盒测试工程师就要脱离程序设计语言本身,结合不同架构、多种开发技术交互的情况下,寻找代码测试方法,并具有对代码优化的能力。由于该路线在国内很少有实例参考,这里不再赘述。

       资深性能测试工程师,来源于常规性能测试工程师,按照常规性能测试工程师的技术要求,资深性能测试工程师应该具备性能测试整体方案的设计能力,以及软件系统性能问题定位和性能优化的能力!初此之外,也要对主流的软件开发模式下的应用系统具有敏锐的洞察意识和感知意识。软件开发的架构会日益复杂化,软件应用的各种软硬件平台、数据库类型、服务器类型、网络协议层出不穷,不得不说,都为性能测试的从业者们提出了严峻的考验!值得庆幸的是,各种同类产品的厂商在开发产品时都遵从业内统一标准,性能测试人员结合自身的丰富经验,加上对软件性能测试技术的研究,这样的考验我们欣然面对,这样的人才则会日益增多,在软件测试行业里充当佼佼者地位。

       安全性测试工程师,笔者将其从性能测试工程师衍生出来,因为只有具备性能测试经验的人,才对软件的开发模式、实现架构和技术本身充分了解,才会感知和预见软件系统存在的安全漏洞,加上其本人是测试出身,才知道如何通过系统漏洞尝试攻击软件系统,达到测试的目的。目前国内软件行业对于安全性测试的认识尚未清晰,该职业也更没有普及,一般只限于军事类、机密类、防病毒类或其他高安全性软件的测试工作中。

       再次强调,人类进入文明社会后,任何社会活动都不是独立的个体能够实现的;在高度讲究团队合作、协同办公的今天,软件测试工作更不是测试工程师几个人就能做完所有的事情的;上述各发展路线的技能要求,只是为了增强个人职业突破的砝码,你的砝码越多,“被利用”价值越大,为企业创造利润的程度越高,企业自然给予你更丰厚的回馈!达尔文伯伯的“优胜劣汰”自然规律不会变,“多劳多得、少劳少得”的市场规律也不会变!

       曾经有如此众多的测试职业发展路线放在我面前,结果我没有珍惜;等到软件测试行业发展到成熟阶段,我想入行却入不了行的时候,我才后悔莫及;尘世间干测试最大的不幸莫过于此;如果非要问sincky:再往上的发展通道是什么,那么sincky一定要告诉你,技术专家域!

       在技术路线,向上继续提升的方向,我们称之为“技术专家”;如果说前面描述的技术职位的所涉范围都定位在企业内部,即企业级资深性能测试工程师,那么技术专家,我们可以看作是领域级专项人才!随着软件测试行业的职位不断细化,每个人在自己擅长的领域走向深入,都可以成为该领域的技术专家,技术专家在自已经营的领域里,具有个人独到的见解和深厚的技术实力,而这类人才可以不再从事具体的测试工作,而是提供行业性测试技术咨询、培训等,为软件测试整体行业的发展,起到了鲜明的带头作用。在一些专业的咨询、培训公司,或者IBM、Microsoft等巨型公司,不乏这样的人才;然而目前在我国,这样的人才较少,但是却可以为我们大家提供努力方向,只要我们每个在技术路线供职的测试从业者,规划好自己的职业人生,并以坚韧的毅力和顽强的斗志,若干年后,你我皆可笑谈测试人生,把酒临风,其喜洋洋者矣!而目前在国内几个IT行业发达的省市,专项于软件测试服务或一些大型软件企业,也有这样的职位暂露头角,我们深信,社会对高端人才的需求趋势是越来越大的,更多的优秀企业也会为员工提供更多、更广的发展空间,值此大好形势,就看我们个人如何充分利用这些上升通道了。

       在我们的软件测试从业人员里,有这样一部分群体:他们非计算机相关专业毕业,不懂软件开发,由于国内种种对软件测试人才的偏激认识,认为测试人员不需要懂开发,只要会编写文档、执行用例即可;因此很多测试工程师并不具备开发背景,并且对软件技术掌握肤浅,而对于没有技术底蕴的人强迫其走技术路线,不能不说是一种折磨!因此,这个群体里的朋友,是不是认为自己只能做一辈子常规测试工程师呢?答案是否定的,因为在“双V模型”的左侧,是软件测试职业发展的管理路线。软件测试的管理路线,与通用职业发展示意图的“高管理-低技能”并不完全相同,只因软件测试独具的行业特点,我们认为软件测试行业的非技术路线发展方向,更多的是从软件测试行业衍生出来的职位,如质量保证、配置管理。如果说软件测试职业发展的技术路线更侧重于职业技能的提升,那么这条管理路线则更侧重于职业素质的积累(笔者强调是“侧重”,并不表示不需要);换句话说,技术路线更侧重人的智力因素,而管理路线更侧重人的非智力因素。

       从事了1到3年左右的常规测试工程师,在经过对个人性格特点剖析后,如果认为自己是一个倾向于“高管理-低技能”的类型,那么想要实现自己的职业提升,可以向中级发展域的配置管理工程师、质量保证工程师、业务测试工程师转型。

       配置管理(SCM)与质量保证(SQA)同是CMM中的关键过程域(KPA),也同是现代软件工程里的必要角色,与软件测试同属软件开发团队的重要组成部分。只因这两个角色在软件工程里的人员配比数量相对较少,还不如软件测试这样规模化乃至于形成行业,而最多是一个职业;另外一个社会现象是,企业很少直接从社会直接招聘配置管理工程师和质量保证工程师,而通常的做法是从企业内部的现有测试员工队伍里选拔,而转型后的测试工程师,就成为SCM或SQA。分析其原因,我们可以感知,SCM、SQA与软件测试工程师都是关注于软件质量的相似职位,社会对于配置管理、质量保证的定义和工作内容并未普及,与其直接从社会招聘“0”基础的人来培养,倒不如从软件测试人员里升华!一般来说,这两种职位的上报对象是项目经理或相同级别管理者。

       转型后的配置管理与质量保证工程师,一定要转变一个意识,那就是常规测试工程师的工作范围很大一部分(不是全部)只限于测试流程,而配置管理和质量保证的工作范围是面向整个软件开发流程,二者的职业要求都非常重视软件工程知识体系的建立和软件开发总体流程的实施能力。由于配置管理工程师除了企业配置管理流程的搭建与实施外,一般会涉及配置管理工具的管理与维护,而质量保证工程师更多的工作是软件开发流程的控制与维护,故而配置管理对技术的要求稍高于质量保证。随着我国软件行业水平的不断发展,众多软件公司纷纷通过CMM/CMMI,企业对于软件开发团队的角色配比制度也将逐渐健全,当前社会对配置管理与质量保证工程师的职位需求日益增加,种种现象表明,对于软件测试工程师出身的从业者,转型至SCM/SQA不失为突破个人职业生涯瓶颈的又一通道!

       业务测试工程师,笔者定义为面向行业类软件业务逻辑与工作流测试的人员。当前软件开发类型,很大一部分是行业类软件的应用,如ERP、SCM、CRM、OA、电信、金融、财务、嵌入式、通信、手机、游戏……这就要求从事行业类软件测试的人员具备行业背景、业务知识,熟练该行业工作流程。从社会上出现的很多对此类经验要求的测试工程师招聘信息中,我们更加肯定这种趋势;所谓存在即是道理,既然社会上有了需求,那么就可以作为个人发展的方向。而另外一个特点是,业务测试工程师的工作内容主要是黑盒测试,属于功能范畴,因此对技术要求不大,设置一些大型行业类软件公司的业务测试工程师薪资丰厚,但是完全可以不懂技术,因为它的工作性质决定了不需要懂很多的技术!他们甚至连软件的界面测试都不做——交给常规测试工程师实施,而完全关注软件的业务性和易用性,由于其深厚的行业背景,可以为软件的在正式发布前提出很多建设性的意见,而这些建议正是软件开发商提高产品易用性、增加用户满意度、开拓市场、创造利润的关键因素之一!

       当管理路线的中级域方向继续上升至高级域,就分别到达配置管理经理、质量保证经理、产品经理、业务专家,这类人才地位高、待遇厚,一般资深的软件工程领域专家都聚集于此。

       如果说配置管理工程师、质量保证工程师更加侧重于配置管理流程、质量保证流程的实施与日常管理维护,那么配置管理经理、质量保证经理就是更侧重于配置管理流程、质量保证流程的建立与改进。一般在中小软件企业,可能没有这两个角色,而全部的配置管理或质量保证工作都由工程师担当;但是大中型软件企业对资深配置管理经理、资深质保经理求贤若渴。软件系统越庞大,软件开发团队规模就越庞大,软件开发流程中出现问题的几率就越高,高效管理软件开发流程,不断改进软件质量,是每个软件公司在技术上没有顾虑后的下一个急需攻破的难关!

       业务专家,属于行业内咨询、顾问的角色,已经几乎脱离了测试工作本身,而更多为企业的产品需求分析、设计、开发、测试等各个环节提供指导工作,其目的也是提高软件的易用性和稳定性,减少后期不必要的需求变更。该职位也同样在目前热点行业的大中型软件企业有所设立。

       产品经理,这个职位在很多企业有所设立,笔者认为它是质保经理的派生,只是它更侧重于软件在产品化之前的质量监控工作,包括软件开发流程、软件测试等技术与管理的各个方面。由于该职位在业内没有明显定义,而根据不同企业的职位定位不同,这里无法统一陈述。

       管理路线的最高发展域是咨询域,与技术路线的专家域类似,在配置管理、质量保证、软件产品化、行业领域达到高深造诣的人才,他们有丰富的从业经验、深厚的管理底蕴,具有对软件工程高瞻远瞩的慧眼和胆识,往往供职在专业的咨询与培训公司,提供IT业管理类咨询与培训的服务,推动着软件行业的前进。国内外很多为软件企业进行CMM咨询和实施的公司里,就是这些人才的大本营之一!

       笔者认为,在“双V模型”的管理路线里,中低级发展域的人才对技术与管理的区分较为明显,而到了高级与更高级发展域,更多的是复合型人才,软件业以技术为主导,没有一定技术积累,还是很难达到高级境界;要在管理路线练出“上乘武功”,还是希望大家在主攻管理与流程类课题的同时,多丰富下自身的技术层面,嘿嘿!

    另外,笔者提倡管理与技术两条路线的平齐,而并非目前社会上认为的技术要比管理低一等,技术是靠吃青春饭,在这些人才到达最高发展域的“咨询”与“专家”层面,二者应该完全具有相同的地位和待遇,只是“称谓”不同罢了!

       “双V模型”是sincky结合当前国内外软件测试行业现状提出的职业发展流程图,仅供测试从业者参考,并非一个“死”的框架,大家不要拘泥于流程图本身;其实目前国内很多上升到高级域或最高域的资深人才,很多都是跳跃式、甚至跨越式的职业发展,因为命运掌握在自己手里,任何人都剥夺不了设计自身人生蓝图的权利;而另外一个角度是,任何人都不该不珍惜为自己规划职业生涯的机会!

       软件测试,一个日出东方的国际型行业,虽然偶尔会弥漫晨雾,甚或有暴雨来袭,但是我们都该坚持!有人说:“什么叫失败?”答曰:“放弃就是失败!”每一次当我们身处逆境时,决不能用软弱的眼泪作为走向明天的见证,更不能用脆弱的感情去拴住生命的航线;是雄鹰就该搏击长空,是蛟龙就该挽起狂澜;沧海横流,方显英雄本色,疆场搏斗,可露壮士肝胆!人生没有豁免权,每位从业者只有怀着不息的斗志,乘千里长风,破万里巨浪,才能支配命运走向辉煌的明天!

       后记:sincky,网名叶赫华;在我从事软件测试培训业的1年多里,接触了国内很多除了我们学员以外的软件测试界朋友,其中新手居多。在我们的网站、论坛、我个人的blog、我的qq群乃至其他朋友以我名义建的qq群里,最让大家感冒的话题就是测试人员的职业发展!大家都在做测试工作,可以不知道明天做什么,明年做什么,或者若干年后做什么!“行有行规”,除非不在软件测试这个行业,否则就要遵守这个行业的规律!我觉得,我们的学员有职业发展培训课程,可是面对外界这些热心朋友的提问,长久以来,我一直想集中的写点东西,起码让刚入行的新手对这一行业的职业发展方向有一个直观的感性认知,我也心满意足!但是这个行业还太嫩,并没有章据可循,我搜索了几天的国外网站,可是没有成文的观点可以参考!后来决定自己来写,参照的对象就是国内现状下的测试从业者,于是在和国内各个领域的测试高手朋友们的交流后,我在2006春节前夕用了一白天的时间画出了“双V模型”图,而这篇文章的撰稿,用了我一天一夜的满满时间。在经历几次修改后,这篇文章在今天终于正式发布了,没有别的,只是希望给国内测试界朋友一个参考,欢迎大家批评、讨论,发表自己的观点!(我的msn地址:sinckyzhang@gmail.com)“双V模型”里很多职位名词在国内叫法不一,比如有人把初级测试工程师叫做测试员,我不赞同这种叫法,毕竟不是主流;而我的目的,只是通过这些职位的工作内容来告诉大家在职业定位上需要达到的高度,名字嘛,只是个代号而已!

       我的设想是写三篇文章,叫做《软件测试职业发展三步曲》系列,本文是第二曲,也是三步曲的核心,首先问世,主题是“软件测试职业发展方向”,将来还会陆续推出第一曲“软件测试职业选择”、第三曲“软件测试技能体系”,呵呵,如果大家对本文表示肯定的态度比较多,我会继续写下去,否则我还是回家干我的山贼那份很有前途的职业吧!^-^ (2006年4月10日)

     

     

    茶茶很喜欢这文,所以转贴一下,以便自己以后不时看看,呵呵呵!

  • <转贴>

    2007-04-26 10:58:02

       两个和尚住在东、西两座相邻的山上寺庙里,两山之间有一条清澈的小溪。这两个和尚,每天都在同一时间下山去溪边挑够一天用的水,久而久之,他们就成为好朋友了。光阴如梭,日复一日不知不觉已经过了三年。有一天,东山的和尚没有下山挑水,西山的和尚没有在意:“他大概睡过头了。哪知第二天,东山的和尚还是没有下山挑水;第三天、第四天也是如此,西山的和尚担心起来:“我的朋友一定是生病了,我应该去拜访他,看是否有什么事情能够帮上忙。”于是他爬上了东山去探望他的老朋友,到达东山的寺庙,西山和尚看到他的老友正在庙前打太极拳一点也不像十天没喝水的样子,他好奇的问:“难道你已经修炼到可以不用喝水就能生存的境界了吗?”东山和尚笑笑,带着他走到寺庙后院,指着一口井说:“这三年来,我每天做完功课,都会抽空挖这口井。如今终于挖出水来了,我就不必在下山挑水中啦。”西山和尚不以为然:“挖井花费的力气远远甚于担水,你又何必多此一举呢?”

        这个是茶茶转贴的,茶茶有自己的想法。

  • 茶茶的空间开通了!!!!

    2007-04-26 10:12:36

        茶茶的日志空间开通了,呵呵,希望茶茶自己以后可以勤快的来这里更新哦!

我的栏目

数据统计

  • 访问量: 5365
  • 日志数: 13
  • 建立时间: 2007-04-26
  • 更新时间: 2007-06-20

RSS订阅

Open Toolbar