fuweihao0907 日志 - 小丸子课堂~~ - 51Testing软件测试网 51Testing软件测试网-软件测试人的精神家园

loadrunner的一些小应用整理

2008-10-10 16:26:36

测试过程一些问题的解决

由于我们使用的工具是loadrunner，loadrunner自带来比较完整的帮助文档，遇到问题的时候一定要多看

1、用到的一些函数

1） Strlen：求字符串长度，一般可以用于比较获得的字符串的长度是否和所需要判断的是否一致。（这个函数中测试中模拟进度条时用到，判断是否获得到动态数据）

例子：

if (strlen (lr_eval_string("{wscdiff2}"))-4==0)

{

i=0;

}

else

{ i=i+1;

}

2） lr_output_message：在调试窗口输出信息

在调试的时候，可以在适当的位置可以将监控的参数值打印到调试窗口，便于调试（建议调试时候多用）。

例子：

lr_output_message("循环次数 is %d",Count);

lr_output_message("循环体中lr_think_time的时间为： %d",Count*5);

lr_output_message("i 的值 is %d",i);

java脚本中的写法：lr.output_message("usercode:="+usercode);

3） lr_think_time：思考时间

在操作中适当添加lr_think_time，有时候会解决一些非常头疼的问题。

例子：

lr_think_time(5);

4） web_reg_save_param：保存动态数据到参数。一般web脚本要看同步显示的窗口的显示结果可以获得动态数据左右边界的值是多少，这样才能准确获得动态数据。

例子：

web_reg_save_param("wscdiff1","LB=taskId\":\"","RB=\"",LAST);

web_submit_data("getResult.action",

"Action=http://10.0.30.192/billing/bilcommon/getResult.action",

"Method=POST",

"RecContentType=application/json",

"Referer=http://10.0.30.192/billing/bilmonreport/landmass.action",

"Snapshot=t116.inf",

"Mode=HTTP",

ITEMDATA,

"Name=taskId", "Value={wscdiff1}", ENDITEM,

LAST);

可以根据web_submit_data所显示的信息去确定LB=？（左边界）和RB=？（右边界）从而得到参数的动态值（注意“\”等符合的表示方法，我还没有仔细研究过）。

经验总结：

1）如果有一批的用户而且几个脚本同时要用到，则最好这些脚本不要用同一组用户。

2）要检查在脚本中，哪些操作是比较耗时的，对所要监控的操作是否有影响，如果影响则需要分离出来（如果某页面非常耗时，而只使用一次，则尽量要放到vuser_init中）。

3）不要屏蔽掉脚本中的图片和样式。

4） Java脚本有时在场景中运行时会报错，这时候要检查场景的Run-time Setting是否有多余的东西。

5）中java脚本中的public int init()中，一定要用

Try{

。。。

}catch(Exception ex){

throw new RuntimeException(ex);

}

否则编译将不会通过。

查看(262) 评论(0) 收藏分享管理

1. 你如何在pocket pc 上TEST 你的程序. 你考虑了哪些方面.

2. 如果将你的程序的语言扩展到非英语,例如中文, 你如何测试.

3. 给你一个COCAN, 你如何测试(解释说就是罐装的可口可乐).

4. 当你的程序遇到BUG的时候，你选择怎样处理.

5. 你如何isolation 你程序里的BUG.

6. 给你一个产品有10个functionality,如果时间紧迫, 只能测其中的5个, 你如何选择.

其它相关：

如果别人问我这些题目，我想我会大致这样回答，各位从事软件测试的同志们帮我看看回答的怎么样。

01. 为什么要在一个团队中开展软件测试工作？

答：软件测试在整个一个团队中占有非常重要的地位，具体来说就是测试是一个发现软件错误的过程，执行软件测试会以最少的人力和时间，系统的找到软件存在的缺陷和错误，建立起开发人员和使用者对软件的信心。

02. 您是否了解以往所工作的企业的软件测试过程？如果了解，请试述在这个过程中都有哪些工作要做？分别由哪些不同的角色来完成这些工作？

答：软件测试部门配合系统分析人员软件需求分析讨论，并根据需求说明书制定《项目测试计划》，编写测试用例，建立测试环境。
软件测试人员负责软件开发部门的新产品测试及原有产品的升级测试，负责软件问题解决过程跟踪，负责软件开发文档开发工作的规范化及管理开发部门的产品文档，制作用户手册及操作手册，负责产品的上线测试，监督软件开发过程的执行，提高产品质量。

03. 您是否了解以往所工作的企业的软件开发过程？如果了解，请试述一个完整的开发过程需要完成哪些工作？分别由哪些不同的角色来完成这些工作？（对于软件测试部分，可以简述）
答：需求人员连同系统分析人员&测试人员开会讨论需求。系统分析人员写出需求分析说明，并连同系统分析人员&测试人员&需求人员开会讨论可行性。系统分析人员写出详细设计说明书，程式人员编码，给出系统流程图。交与测试人员，测试人员给出Bug统计表。

04. 您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？
答：从事过write test plan，creation of test case，进行功能测试，性能测试，编写测试工具，文档的管理等，比较擅长与写测试用例和进行功能测试。

05. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）
答：有功能测试，性能测试，可靠性测试，安全性测试，负载测试，压力测试，安装/卸载测试，启动/停止测试，兼容性测试，互连测试，文档测试，恢复测试，回归测试，可使用性测试，容量测试。
功能测试只对软件的功能是否满足用户需求来做测试。性能测试需要和压力和负载测试联合起来。

06. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

黑盒测试：把测试对象当成一个黑盒子，测试人员完全不考虑逻辑结构和内部特性，只依据程式的需求说明书来检查程式的功能是否满足它的功能说明。
白盒测试：把测试对象当成一个透明的盒子，允许测试人员利用程序内部逻辑结构及相关信息，设计或选择测试用例，对程式所有逻辑路径进行测试。
单元测试：白盒测试的一种，对软件设计中的单元模块进行测试。
集成测试：在单元测试的基础上，对单元模块之间的连接和组装进行测试。
系统测试：在所有都考虑的情况下，对系统进行测试。
验收测试：第三方进行的确认软件满足需求的测试。

07. 测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？
答：测试计划工作是对测试工作内容的一个有效的组织和规划，能保证测试工作有效的展开。测试计划工作包括测试目标，测试范围的定义，测试方法的选择，测试进度里程碑，测试资源的有效配置和管理。
测试计划工作也称为测试策略，主要描述测试工程的总体方法和目标，描述目前在进行那一阶段的测试（单元测试，集成测试，系统测试）以及每一阶段内进行的测试种类（功能测试，性能测试等）确定测试范围，生成测试数据等。
其中软件计划中的测试目标最重要，他的软件测试的所需要达成的最终结果。

08. 您认为做好测试计划工作的关键是什么？
答：1. 明确测试的目标，增强测试计划的实用性
2. 坚持“5W”规则，明确内容与过程，'what''why''when''where''how'
3. 采用评审和更新机制，保证测试计划满足实际需求
4. 分别创建测试计划与测试详细规格、测试用例

09. 您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
答：有黑盒和白盒两种测试种类，黑盒有等价类划分法，边界分析法，因果图法和错误猜测法。白盒有逻辑覆盖法，循环测试路径选择，基本路径测试。
例子：在一次输入多个条件的完整性查询中。利用等价类划分法则和边界分析法则，首先利用等价类划分法，可以一个或多个结果是OK的测试用例，然后确认多个NG的测试用例，然后利用边界值分析法，可以对结果分别是OK和NG的测试用例进行扩展和补充。

10. 您认为做好测试用例设计工作的关键是什么？

答：测试用例设计工作的关键是对可行的和不可行的都要考虑。
1，输入 2，详细的操作步骤 3，预期输出 4，实际输出。

11. 请以您以往的实际工作为例，详细的描述一次测试用例设计的完整的过程。

12. 您以往的工作中是否曾开展过测试用例的评审工作？如果有，请描述测试用例评审的过程和评审的内容。

13. 您以往是否曾经从事过性能测试工作？如果有，请尽可能的详细描述您以往的性能测试工作的完整过程。

14. 您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
答：有使用过LoadRunner,该工具能够录制测试人员的操作步骤，然后对这个操作步骤模拟出多个用户来播放出来。
1。Visural User Genertor创建脚本，选择协议，录制操作，编辑操作。
2。中央控制器（Controller）调度虚拟用户。创建场景，选择脚本，建立虚拟用户，设计shedual，设置ip spoofer。
3。运行脚本。分析shedual。
4。分析测试结果。

15. 您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？
答：性能测试工作的目的是检查系统是否满足在需求说明书中规定的性能，性能测试常常需要和强度测试结合起来，并常常要求同时进行软件和硬件的检测。
性能测试主要的关注对象是响应时间，吞吐量，占用内存大小（辅助存储区），处理精度等。

16. 在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
答：检测时间，系统环境，硬体环境，严重程度，程式版本，确认人，功能模块，问题描述，详细操作步骤，是否会重现。
问题描述和详细操作步骤要尽可能的详细。Bug应该尽量用书面语，对与严重程度比较高的缺陷要在相同环境下在测试一遍。

在C/S模式下，如果条件满足可以使用替换法来确认是client端的问题还是server端的问题。

查看(740) 评论(0) 收藏分享管理

初学者入门：软件测试从零开始（一）--转

2008-07-11 13:37:15

本文面向软件测试新手，从测试前的准备工作、测试需求收集、测试用例设计、测试用例执行、测试结果分析几个方面给出建议和方法。鉴于国内的软件开发、测试不规范的现状，本文为软件测试新手提供了若干个软件测试的关注点。

　　【关键词】软件测试、测试用例、测试需求、测试结果分析

　　引言

　　几年前，从学校毕业后，第一份工作就是软件测试。那时候，国内的软件企业大多对软件测试还没有什么概念，书店里除了郑人杰编写的《计算机软件测试技术》之外，几乎没有其它的软件测试相关书籍，软件测试仅仅在软件工程的教材中作为一个章节列出来，因此，我对软件测试一无所知。不过，在正式走上工作岗位之前，公司提供了为期两周的系统的软件测试技术专题培训，对接下来的软件测试工作有很大的指导意义。现在，我继续从事软件测试的培训与咨询服务，在这个过程中，亲眼目睹了很多软件测试新手面对的困惑，他们初涉软件测试行业，没有接受系统的培训，对软件测试一无所知，既不知道该测试什么，也不知道如何开始测试。下面针对上述情况，给出若干解决办法。

　　测试准备工作

　　在测试工作伊始，软件测试工程师应该搞清楚软件测试工作的目的是什么。如果你把这个问题提给项目经理，他往往会这样回答： “ 发现我们产品里面的所有 BUG ，这就是你的工作目的 ” 。作为一名软件测试新手，如何才能发现所有的 BUG ？如何开始测试工作？即便面对的是一个很小的软件项目，测试需要考虑的问题也是方方面面的，包括硬件环境、操作系统、产品的软件配置环境、产品相关的业务流程、用户的并发容量等等。该从何处下手呢？

　　向有经验的测试人员学习

　　如果你进入的是一家运作规范的软件公司，有独立的软件测试部门、规范的软件测试流程、软件测试技术有一定的积累，那么，恭喜你！你可以请求测试经理委派有经验的测试人员作为你工作上的业务导师，由他列出软件测试技术相关书籍目录、软件测试流程相关文档目录、产品业务相关的文档目录，在业务导师的指导下逐步熟悉软件测试的相关工作。其实，在很多运作规范的软件公司，已经把上述的师父带徒弟的方式固化到流程中。

　　如果你进入的是一个软件测试一片空白的软件企业，那么，也恭喜你！你可以在这里开创一片自己的软件测试事业，当然，前提是老板确实认识到软件测试的重要性，实实在在需要提高产品的质量。这时候，可以到国内的软件测试论坛和相关网站上寻找软件测试资源，这种情况下，自学能力和对技术的悟性就至关重要了。

　　阅读软件测试的相关书籍

　　现在，中文版的软件测试书籍越来越多，有的是国人自己写的，有的是翻译国外经典之作。可以到 www.chinapub.com 或者 www.cnforyou.com 等网络购书的站点查找软件测试相关的书籍。目前，从国外引入的软件测试书籍有很多经典之作，但是，翻译成中文后，翻译质量对阅读效果有很大的影响。

　　走读缺陷跟踪库中的问题报告单

　　如果您所在的公司已经有软件缺陷跟踪库了，无论采用的是商用工具，如 Clear Quest 、 TestDirecter 等工具，还是采用的 Bugzilla 、 Mantis 等开源工具，这都无关紧要，缺陷跟踪库中的缺陷报告单才是有价值的。缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现，同时也是软件产品问题的集中体现。一般来说，缺陷报告单中最关键的几个部分包括：第一部分是发现缺陷的环境，包括软件环境、硬件环境等；第二部分是缺陷的基本描述；第三部分是开发人员对缺陷的解决方法。通过对上述缺陷报告单的三个部分作仔细分析，不知不觉你已经吸收了其他软件测试人员的工作经验，并掌握了软件产品常见的基本问题。这是迅速提高软件测试经验的好方法。

　　走读相关产品的历史测试用例

　　如果你所在的公司有测试用例管理系统，那么，走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。走读测试用例也是有技巧的。测试用例写作一般会包括测试用例项和根据测试用例项细化的测试用例，下面举例说明。 “ 测试用户登录的功能 ” 是一个测试项，该测试项的目的是测试用户登录功能是否正确，是否能够完成正常的登录功能，是否能够对非法用户名和密码做异常处理等等。因此，根据该用例项，可以设计出若干个测试用例，大多数情况下，测试用例项和测试用例是一对多的关系。

　　通过走读测试用例项目，你可以掌握应该从哪些功能点着手未来的测试工作；通过走读软件测试用例，你可以了解如何根据被测试的功能点开展软件测试用例的设计工作，包括如何确定测试用例的输入、测试用例的操作步骤和测试用例的输出结果等。

　　总之，走读其他软件测试人员设计的优秀软件测试用例，是提高自身用例设计水平的好方法。

　　学习产品相关的业务知识

　　软件测试人员不仅要掌握软件测试技术相关知识，对产品相关的业务知识也要学习。这很好理解，如果从事财务软件的测试工作，一定要学习财务知识；如果从事通讯产品测试工作，那么相关的通讯理论知识也是必须的；如果从事银行软件的测试，银行的业务流程也是不可或缺的知识点。

　　因此，在学习软件测试技术的同时，千万不要忽略产品相关业务知识的学习。如果你是一个软件测试技术专家，但是对产品业务知识一无所知，那么也只能测试出来纯粹的软件缺陷，而面对眼前出现的产品业务相关的缺陷，很可能是视而不见，如此这般，软件测试的效果会大打折扣。

　　识别测试需求

　　识别测试需求是软件测试的第一步。如果开发人员能够提供完整的需求文档和接口文档，那固然好。可以根据需求文档中描述的每个功能项目的输入、处理过程和输出，来设计测试用例。如果开发人员没有提供软件需求文档，那该如何是好？下面给出几个有效的方法：

　　主动获取需求

　　开发人员通常不会更好地考虑软件测试，如果没有开发流程的强制规定，他们通常是不愿意提供任何开发文档，即便有强制规定，需求文档也未必能够真正指导软件系统测试工作。因此，需要测试人员发挥主观能动性，与相关的软件开发项目经理和软件开发人员保持沟通，了解软件实现的主要功能是什么，并记录得收集到的信息。一般来说，开发人员即便没有提供相关需求文档，也会保存一些简单的过程文档，主动向开发人员索要这些文档，可以作为测试的参考。此外，可以与公司的技术支持人员交流，技术支持人员是最贴近用户的人，因此，通过交流可以获取第一手的用户使用感受，在测试的过程中会更加贴近用户。

　　当拿到相关的资料后，从哪些方面分析需求？如何与开发人员交流需求？其实，只要把握需求分析的几个关键的点就可以解决问题：输入、处理过程、输出、性能要求、运行环境，下面针对每一个项目逐一分析：

　　软件输入：与该需求相关的一切可能输入，可以从这几方面考虑，输入来源、输入参数的数量、输入参数的度量单位、输入参数的时间要求、输入参数的精度和输入参数的有效输入范围。在测试用例设计中，这部分内容作为测试用例输入的依据。

　　处理过程：描述对输入数据所执行的所有操作和如何获得输出的过程。测试人员了解处理过程即可，在测试过程中发现 BUG 时候，如果对处理过程了解的深入，对定位问题根源有很大的帮助。

　　软件输出：描述每个需求的输出结果，包括输出的位置（如计算机显示器、打印机，文件），输出参数的数量、输出参数的度量单位、输出参数的时序、输出参数精确度、输出参数的有效输出范围、错误消息。在测试用例设计中，这部分内容作为测试用例的预期输出。

　　性能要求：与该需求相关的性能要求，比如 “ 插入 ATM 取款卡后， 3 秒钟内弹出提示用户取款的图形界面 ” 。 3 秒钟这一限制，就是对需求的基本性能要求。

　　运行环境：软件的运行所需的环境，包括硬件平台的要求、操作系统的要求、数据库的要求，以及其它相关支撑软件的要求。

　　确认需求的优先级

　　确认需求的优先级是很必要的，如果在产品进度比较紧的情况下，测试人员可以考虑优先测试优先级高的需求项，如果进度允许，那么在测试优先级低的需求项，如果进度不允许，那么就放弃测试优先级低的需求项。如果软件公司有规范的流程支撑，开发人员在提供软件需求文档的时候，应该在文档中确定需求的优先级。但是，如果开发人员连基本的软件需求文档都没有提供，又怎能指望他们确定软件需求的优先级？如果是这样，需求的优先级只能由测试人员完成了。

　　加入开发小组的邮件群组

　　测试人员需要通晓被测试产品，但是，产品在开发的过程中往往是不断变化的。如果软件开发团队有一套变更控制流程，测试人员会对产品的变更了如指掌。如果没有变更控制，那就要采用其他的土方法了。如果公司里面有自动化办公系统，也许采用的是 Lotus Notes 系统，也许使用的是 E-mail 系统，测试人员应该加入到开发人员的邮件群组中。当开发人员通过邮件讨论问题、通知召开技术会议的时候，测试人员可以及时知晓，如果必要，可以参加开发人员的技术会议。即便公司里面有了软件变更控制流程，加入到开发邮件群组也是一个很好的习惯。

　　与开发人员为邻

　　建议测试人员与开发人员为邻。我所在的测试组曾经与开发组是在相邻的写字间里，开发人员与测试人员的关系非常融洽，抛去同事关系，大家还是不错的朋友。不管开发人员有什么样的活动，测试人员都能第一时间获得信息。无论从事软件测试工作，还是从事其它的工作，与工作中上下游环节的同事保持良好的个人关系对工作有很大便利。一般的公司内部都存在部门墙，良好的人际关系是打通部门墙的手段之一。向领导建议测试人员与开发人员为邻，这很必要。

查看(447) 评论(1) 收藏分享管理

界面测试的总结[10]

2008-07-07 11:23:21

软件测试时代关键字：界面测试 2)：在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS系统资源。
C1n!ts?a2P;b^V3K
L(a8]F TWT~    3)：关闭所有窗体，系统退出后要释放所占的所有系统资源，除非是需要后台运行的系统。

    4)：尽量防止对系统的独占使用。
"HW)HW'pa
    5)：窗口能否基于相关的输入或菜单命令适当地打开？

    6)：窗口能否改变大小、移动和滚动？
k$H?2e'N?0A(C
G-Mr2z}8Mq&~i#F$Ur_    7)：窗口中的数据内容能否使用鼠标、功能键、方向箭头和键盘访问？
+I1Kq6ks#xG
A3fNY@%Dg7u    8)：当被覆盖并重调用后，窗口能否正确地再生？

"W_I Uh c+~(_    9)：需要时能否使用所有窗口相关的功能？
F9c+R7Se^i,lJ#jHG
+J+S\,XB'G    10)：所有窗口相关的功能是可操作的吗？

5g1e,O0|9b)a9I$G    11)：是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口可用，并适当地显示？

    12)：显示多个窗口时，窗口的名称是否被适当地表示？
3le R W0j#U2f _+}a
    13)：活动窗口是否被适当地加亮？
%nb R Q Y5h[h F
    14)：如果使用多任务，是否所有的窗口被实时更新？
[h{*M/` u7g!G
:xf_+R"]%r"O"l-j/o    15)：多次或不正确按鼠标是否会导致无法预料的副作用？
;~tr v;rD
    16)：窗口的声音和颜色提示和窗口的操作顺序是否符合需求？
uLqB @ e(RM
$N8`*J;G$I/xWE    17)：窗口是否正确地关闭？

查看(310) 评论(0) 收藏分享管理

界面测试的总结[9]

2008-07-07 11:21:55

软件测试时代关键字：界面测试  3)：采用相关控件限制用户输入值的种类。
mo&o} \\
5pQ%u |pz'D.dkp    4)：当用户作出选择的可能性只有两个时,可以采用单选框。
V7|3kw `U M
0|o4GNj4a U^    5)：当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
/R'w(d-OX,|3`gzp w
'JV+w0wR2Cw D2hq,IA&v    6)：当选项特别多时，可以采用列表框，下拉式列表框。
5?6A i/bZ#_r
s v nmL(F    7)：在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
-S.b}1D\S9Vf*Y
$}Z_:pv Cew3\2p    8)：对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。

    9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
~s W@~yN!u;]0a(Y
;l8].C-B)ALR.F    10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
J-~'a t@#c[
l(]~H)u`nMVz2qn O    11)：对错误操作最好支持可逆性处理，如取消系列操作。
&YxO#F8xb/M|*q
    12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。

    13):对可能造成等待时间较长的操作应该提供取消功能。
.t1ib(Jj0U K@,h Q
    14)：特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!,.。?/还有空格。
-xK/I/k2J!oRG
.Na Oa"No1e    15)：与系统采用的保留字符冲突的要加以限制。
6M5cQ$s9{1F
\;M_'J%MRjI    16)：在读入用户所输入的信息时，根据需要选择是否去掉前后空格。
1n3[/u o!g$[#r-XC
    17)：有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。

*i!s*ki#B　　多窗口的应用与系统资源：
pds EM0N6B*\C?
    设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。

vX2q&?u:zWZ"@ku    1)：在多窗口系统中，有些界面要求必须保持在最顶层，避免用户在打开多个窗口时，不停的切换甚至最小化其他窗口来显示该窗口。

查看(265) 评论(0) 收藏分享管理

界面测试的总结[8]

2008-07-07 11:20:54

软件测试时代关键字：界面测试 5):　公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。

o,T&J4O3_a?1|.~/^'s    快捷方式的组合
n)j8gFE2YW%z Q5CC
@8J]7O:Z~`;T    在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些在西文Windows及其应用软件中快捷键的使用大多是一致的。
v Es2q2y7Q#VE菜单中：

    1):面向事务的组合有: Ctrl-D 删除；Ctrl-F 寻找；Ctrl –H替换；Ctrl-I 插入；Ctrl-N 新记录；Ctrl-S 保存 Ctrl-O 打开。
9Xn7NV0})D+Q3y
    2)：列表: Ctrl-R ，Ctrl-G定位；Ctrl-Tab下一分页窗口或反序浏览同一页面控件。
Ho_ GI
!qZ*eYq:Q` yJ7A    3):编辑:Ctrl-A全选；Ctrl-C 拷贝；Ctrl-V 粘贴；Ctrl-X 剪切；Ctrl-Z撤消操作；Ctrl-Y恢复操作。

SVs,h:b'?*YBTe JT    4)文件操作:Ctrl-P 打印；Ctrl-W 关闭。
rF.aw Q(i7b.Q
    5):系统菜单Alt-A文件；Alt-E编辑；Alt-T工具；Alt－W窗口；Alt－H帮助。
+lt Qy^ \
    6):MS Windows保留键:Ctrl-Esc 任务列表；Ctrl-F4 关闭窗口； Alt-F4 结束应用；Alt-Tab 下一应用；Enter 缺省按钮/确认操作；Esc 取消按钮/取消操作；Shift-F1 上下文相关帮助。按钮中：可以根据系统需要而调节，以下只是常用的组合。Alt-Y确定(是)；Alt-C取消；Alt-N 否；Alt-D删除；Alt-Q退出；Alt-A添加；Alt-E编辑；Alt-B浏览；Alt-R读；Alt-W写。

;F:fa6C:R8R    这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母。

O*N } NpDrVw#rz　　安全性考虑：

x?~d3F$n    在界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。

    安全性细则：
,~+W~'G$J Y `-T
-i\KcD@3?d9WjM    1)：最重要的是排除可能会使应用非正常中止的错误。
_"Oh'F:I z`#[7d x
"Z\],SB6W'yc    2)：应当注意尽可能避免用户无意录入无效的数据。

查看(432) 评论(0) 收藏分享管理

界面测试的总结[7]

2008-07-07 11:19:43

软件测试时代关键字：界面测试 18):是否可能通过鼠标访问所有的菜单功能？

    19):相同功能按钮的图标和文字是否一致？
|*\3][0~r3?
!M9LDD|XP's    20):是否能够用其他的文本命令激活每个菜单功能？
"_j4xj`b"W
7^7n]$m~.c[    21):菜单功能是否随当前的窗口操作加亮或变灰？

    22):菜单功能是否正确执行？

Y rn lZ    23):菜单功能的名字是否具有自解释性？
C8B$p8Fs} {#V&w!Tl
-s]@J,y ^    24):菜单项是否有帮助，是否语境相关？
6m4Yih`l0VOd
    25):在整个交互式语境中，是否可以识别鼠标操作？

    26):如果要求多次点击鼠标，是否能够在语境正确识别？

    27):如果鼠标有多个按钮，是否能够在语境中正确识别？
9DS'^/?!x'U}
    28):光标、处理指示器和识别指针是否随操作恰当地改变？

　　独特性：

I$?+Y9F%p(qu    如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。
;_v9~ }b^h1@8r kI测试细则：
},z!Jw{3B
    1):　安装界面上应有单位介绍或产品介绍，并有自己的图标。
v-\{vTw
3p-YG{i#Q`7N    2):　主界面，最好是大多数界面上要有公司图标。

    3):　登录界面上要有本产品的标志，同时包含公司图标。
tS-e'n SR? @
    4):　帮助菜单的“关于”中应有版权和产品信息。

查看(338) 评论(0) 收藏分享管理

界面测试的总结[6]

2008-07-07 11:18:36

软件测试时代关键字：界面测试菜单测试细则：

)x6]\B7e {    1): 菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格。
1u+BV5U0rOqz@f
a$xb-LX ~7]#j    2): 常用的有“文件”、“編輯”，“查看”等，幾乎每個系統都有這些選項，當然要根據不同的系統有所取捨。
CQgZnt5khN.Z {
PT'e{a(su/^*W    3): 下拉菜单要根据菜单选项的含义进行分组，並且按照一定的规则进行排列，用横线隔开。

    4): 一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
D#E$k4U&r`'M$n-O [
    5): 没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头，不常用的靠后放置；重要的放在开头，次要的放在后边。

A)]1A-ST[E,\B    6): 如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。

    7): 菜单深度一般要求最多控制在三层以内。

NbR2ihhm    8): 对常用的菜单要有快捷命令方式，组合原则见8。

1n3C,J`#z,F] cQ#S2Z    9): 对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式——即只有需要的菜单才显示——最好。
hr q,X,[f%T3@
/tVs2i7k#g @T Y    10): 菜单前的图标不宜太大，与字高保持一直最好。
/v1?%s7{2e7A:RL
    11): 主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
.J2j Rq~[C0T8_ s m
i-^1e0s'WCd*J/q    12): 主菜单数目不应太多，最好为单排布置。
Ux(r!@8k)C5plx
M,@n/Z3jIdi`    13):菜单条是否显示在合适的语境中？

/GA1A @V?5u#B    14):应用程序的菜单条是否显示系统相关的特性（如时钟显示）？

gz8_7`_B{N    15):下拉式操作能正确工作吗？

    16):菜单、调色板和工具条是否工作正确？
L0kM!gG bQl
    17):是否适当地列出了所有的菜单功能和下拉式子功能？
J~E'd6Ax

查看(301) 评论(0) 收藏分享管理

界面测试的总结[5]

2008-07-07 11:17:33

软件测试时代关键字：界面测试美观与协调性细则：
^;@4\ LL${(z(h2O
    1): 长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。

    2): 布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。

)bn |v'G4NVgO:ow    3): 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
AZ1tXok&n'v
    4): 按钮的大小要与界面的大小和空间要协调。
po{h0_.jq
    5): 避免空旷的界面上放置很大的按钮。

f!s[+p iZ    6)：放置完控件后界面不应有很大的空缺位置。

ZWt8T j    7): 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。
(l2W|r LrX`!vq
    8): 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调。

    9): 如果使用其他颜色，主色调要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
0hIF ~\:H ^
Zlg]xi%R.h    10): 大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
Bc i$`N}&])ld)z
    11): 界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
!Ca3d-?JkR _M fc
lF+QiA}4W    12): 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。

6r3c;J_CbZB&rd    13)：对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。

    14): 通常父窗体支持缩放时，子窗体没有必要缩放。
)S^2v5k,oJA1_
"a/aF VGz S;I    15)：如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。

　　菜单位置：

E k%Ns+D@@j {    菜单是界面上最重要的元素，菜单位置按照按功能来组织。

查看(300) 评论(0) 收藏分享管理

界面测试的总结[4]

2008-07-07 11:14:48

软件测试时代关键字：界面测试  6)：用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。
WL4I\NF9c-{"O k
4W:]"Q[C7h.~k7d3O o    7)：如果没有提供书面的帮助文档的话，最好有打印帮助的功能。

    8)：在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。

%uW"VXS,P*o    合理性：

9M9a C3DE mmkV    屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。
.u3}iVjbP mj b
    合理性细则：
U9\amS#d v n@
@.Q4d~7P \i    1)：父窗体或主窗体的中心位置应该在对角线焦点附近。

    2)：子窗体位置应该在主窗体的左上角或正中。

"ZTS o-O1~c{t    3)：多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
m%UbtL4W.H
    4)：重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。

_0{D4^'g4k0IB7da    5)：错误使用容易引起界面退出或关闭的按钮不应该放在易点击的位置。横排开头或最后与竖排最后为易点位置。

    6)：与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。

    7)：对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。

    8)：非法的输入或操作应有足够的提示说明。

#?c)q1s#j.Ii    9): 对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
ZPN_!`F2b
    10): 提示、警告、或错误说明应该清楚、明了、恰当。
iB(q.@7y
;d"~ \)ML[y4g　　美观与协调性：
/Vw5DZu6Vg
    界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。

查看(345) 评论(0) 收藏分享管理

如何编制软件测试用例[3]

2008-07-07 11:08:29

软件测试时代关键字：测试4、评估测试结果的度量基准完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。

HBg.TMY8A8rD6M 5、分析缺陷的标准通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

"`3V k'yNg,t 五、相关问题

1、测试用例的评审测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。

2、测试用例的修改更新测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。

一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。

ycu _hs 3、测试用例的管理软件运用测试用例还需配备测试用例管理软件。它的主要功能有三个：第一、能将测试用例文档的关键内容，如编号、名称等等自动导入管理数据库，形成与测试用例文档完全对应的记录；第二、可供测试实施时及时输入测试情况；第三、最终实现自动生成测试结果文档，包含各测试度量值，测试覆盖表和测试通过或不通过的测试用例清单列表。

"|4UMAis5w8| 有了管理软件，测试人员无论是编写每日的测试工作日志、还是出软件测试报告，都会变得轻而易举。

:VyzGCpP| 开发一个软件产品，会发布多个版本，伴随着测试用例（Test case）的不断维护，使测试用例不断完善并与产品功能、特性（features）的变化保持一致，所以测试用例是和产品版本相关联的。特别是对提供软件服务的软件产品，多个版本常常共存，为客户提供服务，这时多个版本的测试用例也是并存的，所以在新建、修改、删除测试用例时要十分小心，并有相应的规则。

P:D,ZR;x g|WW.z 根据产品特性和test case一致性，分下面几种情况分别处理：

A|:d:~8S1j 1. 产品特性没变，只是根据Late Discovery Bug 或 Remedy Ticket 来完善 test case，只有这时候可以修改Test case，也就意味着当前修改的test case，对目前和以前的版本都有效。

1Qu1S~UGEB 2. 原有产品特性发生了变化，不是new feature，而是enhanced features（功能增强），这时候原有的 test case 只对先前版本（如version 1.0、2.0）有效，而对新的版本（如 version 3.0）无效，这时绝不能修改 test case ，只能增加新的 test case，这一点很重要。原有的 test case 依然对原有版本有效（如version 1.0、2.0）。

\ FNo n+AX2D] _ 3. 原有功能取消了，这时只要在新版本上使之对应的test case置为inactive（无效）。

4. 完全新增加的特性，大家比较清楚，增加对应的、新的测试用例。

这样，新旧版本的相同测试用例得到一致的维护，测试用例数也不会成几、十几倍的增加，可以真正保证 test case 的完整性、有效性！

查看(386) 评论(0) 收藏分享管理

界面测试的总结[2]--转

2008-07-07 11:05:16

软件测试时代关键字：界面测试
!O.x7{ R&O!B x    12):复选框和选项框要有默认选项，并支持Tab选择。

    13):选项数相同时多用选项框而不用下拉列表框。

'}_!Zo8T    14):界面空间较小时使用下拉框而不用选项框。
gF-K7@x
6^ZOY-iIH9[`U    15):选项数叫少时使用选项框，相反使用下拉列表框。

1_hB)b mq    16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。

　　规范性：

    通常界面设计都按Windows界面的规范来设计，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具厢。

| f_$Tm1w    规范性细则：

&d i;F`K x    1):常用菜单要有命令快捷方式。
K8C"W^h"A,ok,UW
7e4T+B)W ^s    2):完成相同或相近功能的菜单用横线隔开放在同一位置。
| c"^#?(KO
    3):菜单前的图标能直观的代表要完成的操作。
X&D]jRG8Vy3Gx
    4):菜单深度一般要求最多控制在三层以内。

^YT/Rp#q    5):工具栏要求可以根据用户的要求自己选择定制。
wU(Arw4?'l`?7|
    6):相同或相近功能的工具栏放在一起。
!QMT!T|5cT*P{
    7):工具栏中的每一个按钮要有及时提示信息。

0?%W VY*h    8):一条工具栏的长度最长不能超出屏幕宽度。
"yi2tF0R5r
    9): 工具栏的图标能直观的代表要完成的操作。
$O tw t*x-u
    10):系统常用的工具栏设置默认放置位置。

查看(330) 评论(0) 收藏分享管理

界面测试的总结[1]

2008-07-07 11:01:39

软件测试时代

关键字：界面测试  界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。

P'FV/PGj&o9Z　　目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。

\fkdf　　易用性：

`:{mOhTP　　按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。

3A}hNCw    易用性细则：

6R w&x _/yO!h(z,i    1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。

z@n0_/|4Xy(F    2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。

fQ5VzQJjWA    3):按功能将界面划分区域块，用Frame框括起来,并要有功能说明或标题。

8q Xma%H@    4):界面要支持键盘自动浏览按钮功能，即按Tab键、回車鍵的自动切换功能。
^ e WBPK.A D
    5):界面上首先要输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
+f%CJU)M[
    6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。

fn PPx)uwxo    7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab

fsdMhKc    8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。
J'X4n-@c;m
    9):可写控件检测到非法输入后应给出说明并能自动获得焦点。
7^|2K)n#Ly d
    10):Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。
,tf8d'G-Xr7]'q
    11):复选框和选项框按选择几率的高底而先后排列。

查看(370) 评论(0) 收藏分享管理

loadrunner的一些小应用整理

微软测试工程师面试题—转

初学者入门：软件测试从零开始（一）--转

界面测试的总结[10]

界面测试的总结[9]

界面测试的总结[8]

界面测试的总结[7]

界面测试的总结[6]

界面测试的总结[5]

界面测试的总结[4]

如何编制软件测试用例[3]

界面测试的总结[2]--转

界面测试的总结[1]

用户菜单

我的栏目

标题搜索

我的存档

数据统计

RSS订阅