明明打了电话，非说没有打，不得已拿出手机通话记录，上面写的很清楚是某年某月某时间，这厮居然跟我耍无赖，愣是说不可能不可能，一边说还一边在翻我的手机记录，最后来了一句：“啊！nana你打错号码了”怎么可能，本小姐还不至于这么蠢，夺过手机拿来，这丫居然想蒙混过关，拿了别的类似的手机号码来糊弄我，于是俺又按回那条通话记录给某人看。靠！想糊弄我啊，也不看看你姑奶奶我是谁，没接就是没接，没回拨就是没回拨，硬是找些幼稚的理由来搪塞我，最后某人居然说想起来了，是调成静音震动了，天哪，静音震动，莫非你想和我表达的是手机没有静音没有震动也没有“未接电话”的大字吗？您老做销售行业的，莫非大半天的时间都不看手机？莫非大半天的都没有其它的电话，莫非只能看到其它的电话就是看不到我的电话，莫非看到我的电话就是不再打给我？莫非ｍｓｎ在线您老都看不到我？靠！这是什么烂借口！您老成天还只能通过这儿的博客来了解我的信息？咱们是两地分居吗？靠！版权所有，您老不许再看我的博客乐。靠！老娘以后不依靠你，你爱去哪儿就去哪儿，去哪儿之后你爱理我就理我不爱理我就不理我，哪怕欺骗都没关系，你只要给我滚的远远的不要三番五次的找些幼稚的理由，你丫，这种事情你自己烦，别烦我，行吗，真怕哪一天你不能自圆其说，要不，真怕你被当场揭穿。

发泄完毕，上面说的好像俺粗话连篇极没修养似的。

不生气不生气，生气对胃不好，呼呼。。。我要自己好好照顾自己，好好对自己，多关心多惦记多爱护自己，让自己的身体变得好起来，让自己天天快乐～

原文

一．用户注册

        只从用户名和密码角度写了几个要考虑的测试点，如果需求中明确规定了安全问题，Email，出生日期，地址，性别等等一系列的格式和字符要求，那就都要写用例测了~

        以等价类划分和边界值法来分析
        1.填写符合要求的数据注册: 用户名字和密码都为最大长度 （边界值分析，取上点）
        2.填写符合要求的数据注册 :用户名字和密码都为最小长度 （边界值分析，取上点）
        3.填写符合要求的数据注册:用户名字和密码都是非最大和最小长度的数据（边界值分析，取内点）
        4.必填项分别为空注册          
        5.用户名长度大于要求注册1位（边界值分析，取离点）
        6.用户名长度小于要求注册1位（边界值分析，取离点）
        7.密码长度大于要求注册1位（边界值分析，取离点）
        8.密码长度小于要求注册1位（边界值分析，取离点）
        9.用户名是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就行了,如含有空格，#等，看需求是否允许吧~）
        10.密码是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就行了）
        11.两次输入密码不一致(如果注册时候要输入两次密码，那么这个是必须的）
        12.重新注册存在的用户
        13.改变存在的用户的用户名和密码的大小写，来注册。（有的需求是区分大小写，有的不区分）
        14.看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否以* 之类的加秘符号显示

二．修改密码
        当然具体情况具体分析哈~不能一概而论~
        实际测试中可能只用到其中几条而已，比如银行卡密码的修改，就不用考虑英文和非法字符，更不用考虑那些ＴＡＰ之类的快捷键．
        而有的需要根据需求具体分析了,比如连续出错多少次出现的提示，和一些软件修改密码要求一定时间内有一定的修改次数限制等等。

        1.不输入旧密码，直接改密码
        2.输入错误旧密码
        3.不输入确认新密码
        4.不输入新密码
        5.新密码和确认新密码不一致
        6.新密码中有空格
        7.新密码为空
        8.新密码为符合要求的最多字符
        9.新密码为符合要求的最少字符
        10.新密码为符合要求的非最多和最少字符
        11.新密码为最多字符-1
        12.新密码为最少字符+1
        13.新密码为最多字符+1
        14.新密码为最少字符-1
        15.新密码为非允许字符（如有的密码要求必须是英文和数字组成，那么要试汉字和符号等）
        16.看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否以* 之类的加秘符号
        17.看密码是否区分大小写，新密码中英文小写，确认密码中英文大写．
        18.新密码与旧密码一样能否修改成功．

        有个朋友问我,注册的时候测试了密码长度,修改的时候为什么还要测试.
        我在这里举个我亲身经历的例子,以前我玩一个游戏,叫恋爱盒子,在游戏里我把密码改成了xuewufengtian,后来怎么也上不去了.因为资料填写不全无法找回密码.后来我在一次注册过程中发现,注册的时候密码长度最长是10位,这时我灵机一动,用了原来的用户名和xuewufengt的密码就进去了. 这表明,修改密码时候的最大长度和注册及登陆的时候密码最大长度有可能是不一致的.

TD经验谈原文

写了两篇关于测试方面的日志，今天我来回忆一下TD的历程。

    TD（TestDirector）是一个功能强大的测试管理系统，此系统涵盖了整个测试流程。相对一些其它的一些缺陷管理工具而言，TD容易操作、易学易上手。

    由于最早学习的就是TD，到现在已经有一段时间了，前两篇文章（自动化、QTP）居然把这个给淡忘了，惭愧万分   。

下面开始介绍一下TD吧：
    安装与我就不细说了，上网下载安装手册“下一步”就OK了。如果可以的话，安装程序里也有英文的帮助说明。配置此篇暂略过……  

TD主要分为四个功能版块：
    1、需求 Requirements
    2、测试计划 Test Plan
    3、测试实验室 Test Lab
    4、缺陷 Defects

    TD上需求是定义测试内容与详细的需求，理论上是由测试组完成的。但综合公司的具体环境，有些时候可能需要开发来完成。
    测试计划可以由需求直接转化（tools —> Convert to tests），也可根据需求文档自定义测试计划。
    测试实验室里，你可以创建执行流程。这里记录了所有你执行过的测试与结果。
    缺陷管理栏，记录了测试过程中发现的所有问题，与开发的交互多在于此。

    其实TD的操作并不难，没有代码，不会有太多文字，也全部都是很常用的控件组合。只要你熟悉这个测试流程，使用TD没有问题！  
    整体流程可概括为：创建项目，明确需求；根据需求生成测试计划；按照计划设计并执行测试；发现问题记录问题。
但实际应用中可能会遇到一系统的阻力了。
    例如你公司开发整个流程是否正规，是否有文档可依。你是否有权力或有能力参与需求的设计与修改。之所以我所谓的“需求有些情况由开发定义”。TD的功能就在那里，该怎么做合适，我想没有定论，需要根据企业实际情况来定了。  
    对于测试而言，我觉得能设计出一个合理有效的测试用例是最很需要的。这个需要你动脑筋，需要对你产品的功能及业务非常熟悉，否则写用例也是纸上谈兵。用例的设计格式，可以参考TD安装生成的默认测试演示库，那里就是设计整个“订飞机票”网站的测试流程，很有学习价值。  
    在测试实验室里，你可以像开发设计业务流程一样，设计出一个测试步骤一步步的执行（Execution Flow）。在执行网格里你可以看到测试的历史记录与结果，我们需要在这里查看测试的进度和BUG的分部。
    缺陷管理里，就是测试和开交流的天堂了。我个人觉得很好用！你可以通过对列的筛选，很快到找到你要需要的信息并进行分析。在测试执行时可以自动添加缺陷，里面还自动记录一些测试信息。在以后的回归测试中，R&D Comments里记录了开发和测试的交互过程，也可以查看历史记录（history）。分析结果并输出……
    有一个很隐蔽的功能，在右上角的 tools -> Document Generator 。你可以选择TD里任何你想要的信息，然后设置格式输出到WORD，下班后拿回宿舍分析。  
    菜单里的Analysis也是比较常用的工具，可以帮助你分析结果并输出报告。
      在Add-Ins Page里有很多插件，可以根据需要下载安装。有office插件、TD浏览器等等……
    不同版本的TD，功能核心都是一样的，只是外观有些变化，增加了一些小功能。至于现在出现的QC我也有幸尝试过，界面色调完全改了，多了文字处理功能、强化了图像分析功能。这些我想用过TD的朋友们肯定很容易上手的啦。
    讲到最后，连最重要的用例设计都没详细讲到。因为每家公司的产品和面对客户都不尽相同，其实没有一个固定的说法。我只浅谈一下我的感想吧：  
    1、设计用例之前，你必要非常熟悉产品。用产品的每个功能模块与关联要很清楚。
    2、更多的去了解客户的需要，有机会多和客服勾通。如果能和客户面对面最好了，客户对产品的要求往往和开发者会有一定的差距。了解业务流你会设计更实际的用例，发现更有意义的BUG。
    3、多和组内同事讨论，“三人行必有我师”。即使你再强，你也会有想不到的地方，一个人的力量是有限的。
    4、用例的描述，要简要、清晰。因为你设计的用例可能被别人执行、新员工的参考和学习。
    5、每个步骤，尽可能多的想到他的关联，但不要冗余（容易理解不容易做）。
    6、一个完整的用例应涉及所有的功能与业务需求（需要很周全的考虑）。
暂时想到的就这么多吧，欢迎广大的测试朋友们前来补充。
    所以，要设计出一个精炼而有效的测试用例，是不容易的。也是我们每个测试人员力求的！  
TD对于管理而言，相对于对工作进行了量化的标准。在TD上，你可以看到某个人什么时候在做什么事情、当前测试进度到哪了、某个版本缺陷的分布等等等等。对公司而言，产品库的建立是公司的一个资本。IT的工作量的一直是很难衡量的一个问题，TD在此对企业的管理者也提供了一些帮助。

    由于某些需要，可能我们需要尝试一些其它的管理工具。我个人也尝试过Rational、开源、其它的。Rational的那一套，我在自动化里有谈到。内容太多了，关于他的CQ，仅仅是缺陷管理，没有TD强大。但Rational是一套解决方案，CQ只是其中一个模块，拿起来和TD比有些不合适。Rational的资料在网上可利用的就更少了，我一直没有研究出什么成绩来，在此就不多说了  。网上还有很多缺陷管理工具，开源的bugzilla就有很多人推荐。但安装都很麻烦，不易维护，功能不也多，我也没有多研究了。还有试过TestTrack..... 这些功能都很少，仅相当于TD中的Defects。还是推荐用TD吧，其它小工具也有他存在的理由，适合一定的需求环境，需要大家可以搜一下。  

    这些可都是白手起家，“搜”出来的喔 :-0 

厄。。。。。。。。。。。。

郑重申明：

    鄙人从今天开始除了认真工作好好上班之外，少玩网游包括看韦小宝电视剧（每天1~2 hour），认真读书，坚持三个学习：学习LR，学习test case（厄。。。外加理论），学习TD；呼呼。

    钦此

    若一个月坚持完成，就小小奖励自己一下下，呼呼。

                                                          nana于2007-06-11申明！

note：若有变动，随加在此日志（本行之下），毕。

IIS 0x8ffe2740 错误(计算机管理中网站红色Error)

现象：发现默认网站是停用的
     点击启动网址时，报错 0x8ffe2740 
解决方法：
    1.默认网站改用其他端口
    2.停掉占用80端口的程序
    前者选8080或者什么的端口就可以了
    对于后者：
        开始->运行
        netstat -abn

或者用TCPView这个软件查占用80端口的进程
可以看到占用80端口的程序的PID(2588)，以及程序名称(PPLive.exe)
知道程序名就好办了，直接打开任务管理器，把相应程序关掉就可以了
加入只知道程序的PID，可以打开任务管理器，选择 "查看/选择列"
把PID选中，然后对应PID查找相应程序就可以了

总结：主要是端口占用，关闭相应进程即可

为了了解TD是如何进行测试用例管理的，我特意装了个TD7.6。可是装完TD服务死活就是无法启动。使用TestDirector Checker进行check，找到了两个错误，尝试了并找到了解决办法，具体如下。

1.The TestDirector installation process creates a virtual directory, which it attempts to places in High (Isolated) Application Protection. If, after the installation process, the virtual directory is otherwise protected, TestDirector cannot work properly. To rectify this situation, you must resynchronize the IWAM_XXXX account passwords, or place the virtual directory in Low (IIS process) Application Protection.For instructions on synchronizing IWAM_XXXX account passwords, refer to Article#324 on the following Web site: www.IISFAQ.com
Execute permissions: Execute (including scrīpts) permissions necessary.

解决办法：

1)进入“Internet信息服务”对话框，在“默认网站”下选择“TDBIN”，在右键菜单中选择“属性”

2)在“虚拟目录”Tab页中选择将所有权限选中，点击创建网站按钮，将“执行权限”修改为“脚本和可执行文件”，“应用程序保护”选择“高（独立）”

手工同步IIS用户密码，步骤如下：

1)重新设置IIS的IWAM账号密码。右键单击 我的电脑->管理，打开计算机管理界面打开 本地用户和组->用户　右键单击 启动IIS进程帐号　IWAM_****（注：****一般是计算机名）点击设置密码，设置为一个你想要的密码。

2)同步IIS metabase中IWAM_MYSERVER的密码，在CMD中：c:\inetpub\adminscrīpts>adsutil set w3svc/wamuserpass "yourpassword"

3)同步COM+应用程序所用的IWAM_MYSERVER密码，在CMD中：c:\inetpub\adminscrīpts>cscrīpt synciwam.vbs -v。

但是在进行第三步操作时总是报8004e00f错误。进入组件服务，查看组件服务/计算机/我的电脑/COM+应用程序，结果报错"COM+ 无法与 Microsoft 分布式事务协调程序交谈"，无法查看里面的对象。在事件查看器中msdtc服务没有正常启动。解决方法：运行 msdtc -resetlog

如果还出现问题，可以参考http://www.cnqa.cn/bbs/viewthread.php?tid=380文章，将IWAM_****密码进行修改。

2.Internet Information Server-->Reports Virtual Directory 失败，提示信息为：Web Directory TDBIN\Reports Does Not Exist. TestDirector was installed incorrectly. Please Reinstall it.

把reports目录的“执行权限”设置为“纯脚本”，再次执行check，全部通过，并且可以启动TD服务。

原文

1           目的：统一测试用例编写的规范，以保证使用最有效的测试用例，保证测试质量。

2           范围：适用于公司对产品的业务流程、功能测试测试用例的编写。

3           术语解释

3.1         测试分析：对重要业务、重要流程进行测试前的分析。

3.2         业务流程测试用例：关于产品业务、重要流程的测试用例。

4           业务流程测试用例编写原则

   4.1         系统性

   4.1.1       对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；

   4.1.2       对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系；

   4.2         连贯性

   4.2.1       对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链接是否正确；

   4.2.2       对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯；

5           测试用例设计的方法

5.1         等价类划分法

5.1.1       确定等价类的原则

5.1.1.1     如果输入条件决定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。

5.1.1.2     如果输入条件规定了输入值的集合，或者规定了“必须如何”的条件，此时可确立一个有效等价类和一个无效等价类；

5.1.1.3     如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类；

5.1.1.4     如果规定了输入数据的一组值，而且程序对每个输入值分别进行处理，此时可为每一个输入值确立一个有效等价类，此外，针对这组值确立一个无效等价类，它是所有不允许输入值的集合；

5.1.1.5     如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同的角度违反规则）。

5.1.1.6     如果确知，已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分成更小的等价类。

5.1.2       测试用例的选择原则

5.1.2.1     为每一个等价类规定一个唯一的编号；

5.1.2.2     设计一个新的测试用例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步，直至所有的有效等价类都被覆盖过；

5.1.2.3     设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直至所有的无效等价类都被覆盖为止。

5.2         边界值分析法

5.2.1       测试用例的选择原则

5.2.1.1     如果输入了条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超越这个边界范围的值作为测试输入数据；

5.2.1.2     如果输入条件规定了值的个数，则用最大个数、最小个数、比最大多1、比最小小1的数作为测试输入数据；

5.2.1.3     根据规格说明的每个输出条件，使用前面的原则；

5.2.1.4     如果程序的规格说明给出的输入输出域是有序集合，则应选取集合的每一个元素和最后一个元素作为测试用列；

5.2.1.5     如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例；

5.2.1.6     分析规格说明，找出其他可能的边界条件。

 6           测试用例设计的原则

6.1         全面性

6.1.1       应尽可能覆盖程序的各种路径

6.1.2       应考虑存在跨年、跨月的数据

6.1.3       大量数据并发测试的准备

6.2         正确性

6.2.1       输入界面后的数据应与测试文档所记录的数据一致

6.2.2       预期结果应与测试数据发生的业务吻合

6.3         符合正常业务惯例

6.3.1       测试数据应符合用户实际工作业务流程

6.3.2       兼顾各种业务变化的可能

6.4         仿真性

   人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例；不允许出现与知名人士、小说中人物名等雷同情况。

 6.5         可操作性

       测试用例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果。

 7           测试用例编写格式细则

     7.1         测试用例内容

     7.1.1       具体实施可以采用EXCEL和图形相结合，可用EXCEL编写测试用例的同时插入图形来加以说明。测试用例设计的内容可由：模块名、功能说明或图形说明、测试用例输入、应输出结果、实际输出结果、结论、BUG编号、BUG级别8部分组成。

     7.1.2       在测试用例设计模版中有“业务流程测试用例设计模版”（包含整体业务流程）和“功能测试用例设计模版”两个模板可按需要选择。

     7.2         测试用例表格格式

     7.2.1       表格内容的字体为宋体；

     7.2.2       表格内容的字型为12号；

 8           测试用例优先级

    对于A、B 级应重点考虑

   

9           BUG级别

    参考软件测试停止标准中的错误级别.

原文

关于web测试
1页面部分
（1） 页面清单是否完整（是否已经将所需要的页面全部都列出来了）
（2） 页面是否显示（在不同分辨率下页面是否存在，在不同浏览器版本中页面是是否显示）
（3） 页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）
（4） 页面特殊效果（如特殊字体效果、动画效果）是否显示
（5） 页面特殊效果显示是否正确

2 页面元素部分
（1）页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）
（2）素是否显示（元素是否存在）
（3）页面元素是否显示正确（主要针对文字、图形、签章）
（4）页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等）
（5） 页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接）
（6） 页面元素的容错性列表（如输入框、时间列表或日历）
（7） 页面元素的容错性是否存在
（8） 页面元素的容错性是否正确

3 功能部分
（1） 数据初始化是否执行
（2） 数据初始化是否正确
（3） 数据处理功能是否执行
（4） 数据处理功能是否正确
（5） 数据保存是否执行
（6） 数据保存是否正确
（7） 是否对其他功能有影响
（8） 如果影响其他功能，系统能否作出正确的反应
（9） 其他错误
（10） 对模块的具体功能进行测试时可以列出功能模块的所有功能，进行排列组合，测试所有情况
如：某一功能模块具有最基本的增删改查功能，则需要进行以下测试
单项功能测试（增加、修改、查询、删除）
增加——>增加——>增加 （连续增加测试）
增加——>删除
增加——>删除——>增加 （新增加的内容与删除内容一致）
增加——>修改——>删除
修改——>修改——>修改 （连续修改测试）
修改——>增加 （新增加的内容与修改前内容一致）
修改——>删除
修改——>删除——>增加 （新增加的内容与删除内容一致）
删除——>删除——>删除 （连续删除测试）
（11）查询功能分为两种情况，验证操作结果。
一、打开页面时自动显示结果，则不特别强调；
二、需要手工操作进行查询，则每次在其他功能完成后进行。
4 提示信息
（1） 成功、失败提示
（2） 操作结果提示
（3） 确认提示
（4） 危险操作、重要操作提示
（5） 返回页面 提示后显示的页面
5 容错性
注意以下几种情况
（1） 为空、非空
（2） 唯一性
（3 ）字长、格式
（4） 数字、邮政编码、金额、电话、电子邮件、ID号、密码
（5） 日期、时间
（6） 特殊字符 （对数据库）英文单、双引号，&符号
6 权限部分
功能权限： 指定用户可以使用那些功能，不能使用那些功能
数据权限： 指定用户可以处理那些数据，不可以处理那些数据。可
以合并到功能测试
操作权限： 在逻辑关系上，操作前后顺序、数据处理情况。可以合
并到功能测试
权限变化： 可以合并到功能测试

（1） 功能权限是否存在
（2 ）功能权限是否正确
（3） 数据权限是否存在
（4） 数据权限是否正确
（5）操作权限是否存在
（6） 操作权限是否正确
（7） 引起权限变化的功能列表
（8） 功能权限变化还是数据权限变化，或两者兼有
（9） 权限变化是否正确

7 键盘操作
（1） Tab键的使用
（2） 上下方向键的使用
（3） Enter键的使用
（4） 系统设定快捷键的使用（如果设置有快捷键）

8 测试中还应注意的其他事项
（6） 完整性：是否是一个整体，没有功能缺损
（7） 易用性：使用是否方便
（8） 一致性：类似的问题用类似的方法处理
（9） 提示信息：提示信息是否完整、正确、详细
（10） 帮助信息：是否提供帮助信息，帮助信息的表现形式（页面文字、提示信息、帮助文件），帮助信息是否正确、详细
（11） 兼容性：包括操作系统兼容和应用软件兼容，可能还包括硬件兼容
（12） 可扩展性：是否由升级的余地，是否保留了接口
（13） 稳定性：运行所需的软硬件配置，占用资源情况，出现问题时的容错性，对数据的保护
（14） 运行速度：运行的快慢，带宽占用情况

有几点：
1.功能点测试：是否满足需求所要求的功能
2.字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
3.字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
4.标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
5.中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.
6.信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
7.界面测试：界面的正确性、一致性、友好性、易用性。

用户界面测试是从最终的使用者用户的角度来看软件，软件难以理解，不易使用就是软件缺陷。可以从以下几个方面重点来检查用户界面：
1.易用性检查：确保软件易于理解，方便使用。
2.一致性检查：
a.注意系统页面的风格是否一致，如字的大小、颜色、字体要相同。
b.提示信息的表达方式是否一致。
c.按钮排列顺序是否一致。
d.back, cancel等按钮跳转页面处理是否一致。
e.各字段的名称，位置、长度、类型是否和设计文档要求一致，如Employee No和LoginName不一致。
3.正确性检查：检查页面上的form, button, table, header, footer,提示信息，还有其他文字拼写，句子的语法等是否正确。
4.友好性检查：
a.提示信息是否友好.
b.系统应该在用户执行错误的操作之前提出警告，提示信息.
c.页面分辨率检查，在各种分辨率浏览系统检查系统界面友好性。
5.合理性检查：做delete, update, add, cancel, back等操作后，查看信息回到的页面是否合理。
6.检查本地化是否通过：英文版不应该有中文信息，英文翻译准确，专业。
7.页面最大化检查：测试最大化/最小化/还原时页面是否做了对应的处理。

怎么 这么 的 不 开心 呢 。 。 。

怎么 能 这么 的 不 开心 呢 。 。 。

困。只 睡了 5 个 小时 多 点点 。。。。

我 不要 这样 的 状态 。。。

我 要 吃好 睡好 。。。

才 有 精力 做 事情 。 。 。

这样 我 的 胃 也 才 能 好 起来 。 。 。

自己 要 好好 照顾 自己 。 。 。

[原创]测试用例输入数据的设计方法和测试用例设计方法不可混淆

测试用例的设计是测试设计的重要内容，关于测试用例的设计方法，当前不少出版的测试书和发表的测试文章，不少存在着表述错误，主要是把测试用例中的输入数据的设计方法与测试用例的设计方法混为一谈，对测试初学者和测试用例设计人员产生误导。

这种错误的主要表现举例如下：

测试用例的设计方法包括：
（1）等价类划分法
（2）边界值法
（3）功能图与判定表法
（4）错误推测法
（5）用户场景法
（6）......
其实，测试用例中输入数据的设计方法只是测试用例设计方法的一个子集，上面列出的集中方法都是确定黑盒测试用例的输入测试数据的一般方法，而不是测试用例的设计方法。

除了确定输入数据之外，测试用例的设计还包括如何确定测试用例的设计策略，如何组织设计用例，如何从测试需求等文档创建完整的测试用例。

对测试执行人员来说，测试用例的表示内容包括以下几个方面：
（1）测试用例的测试目标
（2）测试用例的被测功能点描述
（3）测试用例的测试运行环境
（4）测试用例的执行方法（包括测试步骤，输入测试数据或测试脚本）
（5）测试期望的结果
（6）执行测试的实际结果
（7）其他辅助说明
从以上几点，我们可以看到输入测试数据只是设计测试用例的一个步骤，而不是全部。

测试用例的设计是一项复杂的测试工作，测试用例的设计方法需要考虑测试的目标，被测试软件的特性，测试者人力资源的技术和能力，测试组织形式，测试进度、测试成本等多个方面。

原文

我说几句吧：最近一直在写测试用例，一直疑惑自己的测试用例特象ＧＵＩ测试用例，然后不断的思考，努力把数据测试都写成功能测试，因为整个系统是我一个人写，没有人指导，文档不全，自己也没有完全参加过什么系统的培训，完全靠自己。。。发现的问题是功能测试用例不是完完全全等同于数据测试，且数据测试一直被我名为ＧＵＩ测试，看了这篇文章之后，发现数据测试也不等同于ＧＵＩ测试，现在有一个很大的问题，就是级联菜单的功能测试用例的设计，呼呼，有人知道的麻烦告诉我一下。。。问题

原文

从去年6月底开始正式做软件测试以来，我个人经过了很多阶段。从一开始的网站功能测试，到后来开始接触ERP，做了LR性能测试，然后开始做WR的自动化，到这时候大概半年时间去掉了。之后做了2个月的C#开发，在自动化测试方面用QTP开始逐渐替代了WR。然后我调到了市区“前线”工作。开始着手做NUNIT单元测试和基于.NET开发环境下的LR压力测试代码编写及面向Oracle存储过程的性能测试。06年7月，我开始担任测试管理的角色，开始从事培训新人，安排测试任务，与开发协调测试任务方面的工作，直到今天。我写这篇总结的原因，是由于自己对测试工作的职业发展开始感到迷茫，对技术发展没有方向。

我个人认为，我上班16个月以来所走过的路，是比较合理的。这样的路建立的经过测试专业培训的基础上（个人感觉，新人接受专业培训是很有必要的），否则可能先需要在基础方面努力3个月左右。基于对测试的正确理解以及对各种测试工具的了解，在正式工作中可以快速的应用上去。

下面说下我认为“菜鸟”应有的发展路程。

测试新人应该从系统手工测试开始，首先应该对整个软件的开发流程（软件工程）有正确的认识，了解测试工作在整个开发流程中的切入点和所起的作用。就项目而言，测试是其中的一部分，想要做好系统测试，首先应该学会怎么看SRS（需求规格说明书），对需求的正确理解将直接影响你的用例设计。其次，是用例设计的方法，这包括很多种，我就不多说了。主要的一点是，看SRS所设计的用例可能不全面，在实际测试过程中，应该从系统的操作中继续发现应该测试的点。另外，对于测试用例和BUG的编写，应该规范，清晰。出色的完成你的初测。其次，当开发修改完BUG之后开始复查时，首先你需要明白一个名词，它就是：版本。然后你开始复查BUG，如果时间允许，我强烈建议你重新执行所有用例，以防万一。

当你的系统测试做的“炉火纯青”的时候，你应该开始了解配置管理，质量保证，CMM以及一些开发上的相关知识。这可以巩固你对整个项目流程各个环节的了解，让你对他们有全面正确的认识。我认为这一点，很重要！

之后，公司的测试水平开始升华，你的经理发现，总是复查BUG是一件多么耗费时间和人力的事情啊！他开始要求做自动化测试。这时候你就应该加入其中。对于自动化测试怎么做法我就不仔细说了，东西太多，我自己目前可能处于中级应用阶段，大家可以去51testing上看相关帖子了解一下。需要说明的是，自动化虽然好，但是不可能替代手工测试。另外，它不适用于一些小项目，对于小项目来说，上自动化所带来的项目成本，将远大于手工测试。

在自动化测试过程中，你可能需要自己去写一些脚本。这就需要对编程有一定了解。在这里我想说，会编程不是测试人员必须会的技能，但是，不懂编程将不会成为一个高级测试人员，它会成为你发展的一个绊脚石。我在做程序员的2个月中，学到了很多，它会影响你对系统的认识，拓展你的测试思路，增强你对数据库的了解。在这个阶段中，我建议你有空时学习相关网络拓扑，系统架构，数据库的知识，为将来打下基础。

做到这样我可以说，这个人已经是测试方面的中高级人才了。当然，如果你想做技术全能选手，那就开始接触性能测试和白盒吧。我认为这两个是高阶的玩意。

在性能测试领域，我是只会用LR，关于怎么学我不想说，自己找资料。需要说明的是，性能测试有两个难点。第一，是对面向被测系统的认识，如何确认到底需要监控测试哪些性能点的问题。第二，是对于测试出来的结果，能否正确分析找出瓶颈的问题。这两面都需要大量的工作经验，以及对系统，网络等各方面的深刻认识。这是一个具有挑战性的工作。

在白盒测试方面，首先你要懂编程，要写过程序，其次，你要会使用相关工具实现测试过程。基于代码级的测试和系统测试在理念上是差不多的，你也需要对被测的方法或者基类设计测试用例，然后用测试代码去实现它。这是一个自己构造输入参数，执行代码并获取结果的过程，有兴趣学习的自己找资料看去吧！在每日构建方面我没有做过，所以也不好多说什么，别误导了大家，我只能说，每日构建是每天对配置库中的代码进行自动的单元测试，确保每天配置库中得下得代码是编译可通过的一个过程。

当你在技术上有了一定造诣，你得到了领导的赏识，可能你会步入测试管理的行列。强力的技术背景将成为你做领导的支柱，但不是全部。我想说的是，做测试管理和做技术完全不是一回事，管理基本关注两点，一是成本，二是进度。在确定这两点是可控的情况下，可以说你的管理工作是合格的。你的技术背景为你提供了如下的好处：第一，手下人对你的信服；第二，有利于和开发方沟通；第三，协助解决技术难题；第四，强力的自信。这一切都为实现控制成本和进度提供保障。这方面我就不多说了，我自己做这个时间也不长，大家自己摸索一下吧。

做任何事情都是没有止境的，不论是系统测试，自动化测试，性能测试，单元测试还是测试管理（当然还有做配置管理和质量控制的），都有需要继续学习的东西。目前国内没有超级牛的人带领大家在技术和发展方向上奔走，大家可能都是在爬行。当你在某个领域做到一定程度的时候，你会发现走到了瓶颈点，无法继续提高。这个是无法避免的问题，我给大家一个偏激但可行的方法，那就是跳槽。新的环境会带给你新的思路和活力。测试需要学习的东西太多太多，以上说的都是纯软件方面，我自己现在仍然不熟悉JAVA方面以及类似UNIX之类的操作系统，如果你做的是通信或其他方面的测试工作，你还需要掌握这方面的知识，实在是有的学，我相信经过3年的磨练，应该可以成为一个较为成熟的测试工程师。另外，前面提到了做CMO和SQA的方向，这个和做纯测试工作是不同的发展方向，CMO的工作我太熟悉，不过SQA实在又是一个博大而又精深的领域，据我所知，国内这方面的牛人很少，精英QA可以和PM相媲美，他对项目成功的贡献是巨大的，好像大多这类人是做了PM或系统分析员多年的人转做的。在这方面就不深入探讨了。

补充一点，公司的流程不可能像你学到的那样完美和规范，不要奢求，尽量去改善它才是你要做的。另外我想说下待遇问题，我建议新手不要太计较这个，也许你在51testing培训花了10K（不清楚现在具体价格，只是假设），你觉得自己从那培训出来已经是个牛人了，你要马上把你的投资赚回来。其实这么做实在是想法有问题，首先，你即使培训了，其实你仍旧是菜鸟，其次，中国人太多，人力资源不值钱，除非你是高级人才。新人在第一年不应该计较工资，而应该关注对方单位将会带给你的工作环境和发展潜力。讲工资的时候，应该在2－3年以后，需要强调的是，英文实在重要，我确实的体会，只是我太懒，一直不肯好好学，大家千万别学我啊！

以上是我个人的一些观点，大家随便看看吧，说错了我可不负责啊 ^_^
另外，我目前对于个人职业发展也比较迷茫，哪个牛人看了对我有所建议，请不吝赐教。。。。
                                                胡  睿
                                        2006年11月18日星期六

唉。。。昨天一天没有上班，在家休息。。。

最近精神状态不好。。。有时候会非常的不好。。。

早上去医院的路上准备坐公车。。。那时候疼的受不了，掐的某人。。。唉。。。现在想想。。。站都站不住了，某人居然还让我坐公车。。。事后居然还说路程短，早上凉快，报销报不了。。。接着到了医院，某人就直愣愣的一声不吭，弄得他好像和后面来排队的人差不多都是旁观者。。。

早上出去我们又不是散步！昨天去医院看病看得有点心凉。。。sigh...还不如自己去看。。。我自己照顾自己都没这么糟糕。。。

原文　by 上官若冰

一个好得测试用例，需要满足16个字：
   结构清晰
   内容准确
   易于统计
   便于维护

让我们来分析和了解一下测试用例得结构。测试用例的结构一般依照项目的层次，可以划分出一定目录结构。如何来做到结构清晰呢？

假设，如果有一个复杂而庞大的项目，需要对其每个模块，每个模块中的的功能点，每个功能点中的细节分别设计用例，你将用什么方法来使你得测试点体现得条理又准确呢？下面我们以学生管理系统这样一个项目来做例子分析。如下是这个项目的框架式功能介绍：



从该项目功能点上可将系统划分成如下的关系：



任何一个的项目，不管其难以程度，都需要将它由大到小，由复杂到简单去划分。从上面这个关系我们可以得出，一个项目从上到小可以出现多个层级关系：
* 最大的层级就是一个项目，如学生信息管理系统这个项目；
* 其次组成这个项目的各个分支（模块）功能，如登陆，数据库管理，学生信息管理，账户管理，成 绩分析统计管理；
* 再次，每个分支（模块）功能内部，外部功能点。

所以，至少有三层关系在其中。那么，如何让我们的测试用例也能很好的体现出这样的层级关系呢，我们引入如下概念：

WookBook:
模块，各产品根据各自特性划分成不同的子模块

WookSheet:
子模块，在各模块基础上分成不同的细分模块

Secnario:
A set of test cases ensure that the business process flows are tested from end to end. They may be independent tests or a series of tests that follow each other, each dependent on the output of the previous one.

Part:
同一个细分模块中的层次划分，比如按照每个页面一个Part进行细分

Case:
用例，针对一个或者多个Objective的具体测试用例

Pre Requisite
包括整个子模块以及每个测试用例的测试前提条件

Test Procedure
每个分组中的测试用例执行顺序，当测试用例顺序执行时可省略

WookBook，WookSheet, Secnario, Part, Case的层级关系如下：


Figure 1: The diagram of relationship among the Worksheet, Scenario, Part and Case in one project



Figure 2: The Diagram of relationship among the Worksheet, Scenario, Part and Case in one workbook


现在，我们一起根据上图的层级关系，来为学生管理系统构建其测试用例的框架。

1. 首先我们用一个excel类型的WookBook来定义这个项目，如C050505 SIMS TC 01 01. xls





2. 在一个WookBook中，用多个WookSheet去定义项目中的主要功能点





3. 对模块中需要根据不同场景处理的功能点，再细分出它的场景模块。如在学生信息管理模块，因为权限的不同，所涉及到的场景和功能也会有各自的特点：





4. 在一个WookSheet里面，根据流程和子功能划分成不同的part, 例如在学生管理_助教这个sheet里面：



注：在Part中，如果需要继续划分，可以允许Sub-Part


5. 在每个Part中，设计唯一的Case。Case是测试用例中的最小单位，不可再分。

这样，一个层次鲜明，条理分明的测试用例的结构框架就出来了。拥有清晰结构的测试用例，不仅阅读方便，同时也为测试用例的管理，提供有效的目录组织。

例如：
1.   登陆
2.   帐号管理
3.   学生信息管理
3.1.   管理员权限
  3.1.1.   新增学生信息
  3.1.2.   修改学生信息
  3.1.3.   复制学生信息
  3.1.4.   删除学生信息
  3.1.5.   查询学生信息
3.2.   教职权限
3.3.   助教权限
4.   成绩分析与统计
5.   数据库管理

卡巴斯基在线杀毒专业版

赛门铁克安全门诊

电脑有病毒，我们项目软件有一个功能没法使用　　

难怪前段时间很恐怖，每次我关机，然后闪人，可是第二天早上来每次都是开机的　

我杀毒，杀，杀，杀。。。

喜欢阿穆隆的城市的脚步

ZPCSRY 论坛乞丐 UID 29962 精华 0 积分 5 帖子 1 经验 2 点 威望 0 点 金钱 0 ￥ 阅读权限 10 注册 2007-5-18 状态 离线

#1 使用道具   发表于 2007-5-18 22:19  资料  个人空间  短消息  加为好友  华为技术招聘软件测试(深圳) 华为技术招聘软件测试(深圳) 要求: 1 本科以上,CET-4,证书齐全(学位证/毕业证) 2 06年以前毕业(包括06年) 招聘公司为华为技术,不是子公司 有意者请发简历到我信箱,马上通知面试(除周末外,第2天) zpcsry@163.com

原文