软件测试工具可以减少软件测试执行时间，提高测试效率。但是软件测试工具不是万能的，过分强调测试工具的作用，极力追求各种软件测试工具，是软件测试本末倒置的表现。遗憾的是不少初入测试行业的新手，对软件测试工具的作用存在很多片面的认识误区。

认识误区之一：利用工具能发现软件中的全部或大部分的缺陷

实际上，软件测试过程中80%以上的缺陷是手工测试发现的，仅有不到20%的缺陷是自动测试发现的，而且这20%的发现要求测试人员合理的运用工具。

认识误区之二：软件测试工具可以放之四海而皆准

工具都是针对解决某些特定的问题而开发的，所以必然有其局限性。软件测试工具自身同时也是软件，因此也会存在软件兼容性等不可避免的软件通病。而且测试工具只能解决某一方便的问题，应用范围狭窄软件测试工具的不足。

认识误区之三：运用软件测试工具后测试工作马上减轻，进度马上缩短

由于在测试过程中增加了新的元素，必然增加了测试过程的复杂度。因此在使用工具的初期通常会使工作量、消耗时间等各项成本较手动测试增加25%--50%，而不是象多数人想象的那样可以很快降低成本。

认识误区之四：软件测试工具可以很快上手，不需要专门培训和学习

许多厂商试图通过夸大工具易于使用来宣传兜售其产品，指出工具能够简单的录制就可以用于回放。实际上有效的自动化不是那么简单， 录制期间工具生成的测试脚本必须人工修改，这需要工具脚本知识，从而使脚本健壮、可重用并可维护。

软件测试人员必须掌握工具与脚本语言。因此，要使用任何新测试工具需要专业的培训与学习，并且在测试项目中不断实践应用，才能不断掌握。

认识误区之五：通过工具我们可以达到100%的测试覆盖率

工具可以增加测试覆盖的深度和广度，但是即使面对有限的功能点，依靠工具也仍然无法进行100%的测试。

总之，是否使用测试工具，取决于软件测试的具体要求。选用什么样的软件测试工具，取决于测试的具体要求，而且测试工具并不能买来就用，需要参加专门的培训，并且不断学习；市场上能买到的软件测试工具可能并不能完全满足当前测试项目的要求。如果在时间、资源、技术许可的情况下，最好公司内部开发专用软件测试工具。

本文转载自51testing软件测试网—软件测试工具：http://www.51testing.com/html/17/n-91717.html

1 前言

　　软件生产包括六个环节：软件开发（定义/设计/实现）、软件生产管理、软件质量控制、软件配置管理、软件测试、软件维护。第一个环节加工软件产品，后五个环节决定软件生产的质量和软件产品的质量。软件测试是软件生产的一个重点和难点。软件测试具有四个层次的作用：找错、确认、组装和评审[1]，其中确认和评审的意义与难度在规模化的软件生产中远远大于找错和组装。软件生产迫切需要脱离手工作坊方式的软件调试，在规范化软件测试的基础上实现规模化软件测试，达到提高软件产品质量、降低软件生产消耗的目的。软件测试的方法学和软件测试的管理学应是软件测试工作者关注的重点。

　　1. 软件生产管理：维护软件开发过程的有序性，决定软件生产的资源消耗（人/物/信息/时间），从而决定软件产品的价格；

　　2. 软件质量控制：维护软件资源消耗与软件产品质量之间的均衡；

　　3.软件测试：保障软件产品的可接收性，为评价软件产品质量的提供依据；

　　4. 软件配置管理：保障软件产品（或其中间产品）的可标识性、完整性和一致性，为其它环节提供中介服务；

　　5. 软件维护：保障软件产品的“售后服务”，为软件产品的更新提供信息。

　　软件生产的每个环节都有自身的产品（文档/文件/代码/服务）输出，它们共同构成软件产品的三要素：（软件功用，软件质量，软件价格）。

　　计算机软件生产的方法学和计算机软件生产的管理学值得各类软件工作者关注，需要在实践与研究过程中不断发展理论和积累经验。

　　缘于软件生产的特性，软件测试是软件生产的一个重点和难点。软件测试具有四个层次的作用：找错、确认、组装和评估[1]，其中确认和评估的意义与难度在规模化的软件生产中远远大于找bug和组装。软件生产迫切需要脱离手工作坊方式的软件调试，在规范化软件测试的基础上实现规模化软件测试，达到提高软件产品质量、降低软件生产消耗的目的。软件测试的方法学和软件测试的管理学应是软件测试工作者关注的重点。

　　基于一个大型复杂实时软件系统（以下简称之为“MARA”）软件测试的实践与研究，参考资料[1]从产品计划和生产管理的角度分析和讨论了软件测试，本文将从产品设计和生产组织的角度来分析和讨论软件测试。

　　以下将分析和讨论：软件测试流程、软件测试文档、软件测试用例、规模化软件测试和规范化软件测试。

　　2 软件测试流程

　　2.1 软件测试的阶段划分

　　可以从三个角度来将软件测试划分为多个阶段[1]：

　　1. 面向软件测试操作类型的划分，如调试、集成、确认、验证、组装、验收、操作；

　　2. 面向软件测试对象粒度的划分，如语句、结构、单元、部件、配置项、子系统、系统、大系统；

　　3. 面向软件测试实施者的划分，如开发者、测试者、验收者、使用者。

　　2.2 软件测试阶段的步骤

　　每个软件测试阶段都要经历以下步骤：测试需求分析、测试过程设计、测试实现、测试实施、测试评价、测试维护。

　　2.3 软件测试角色

　　每个测试步骤都对应一个测试角色，另外还定义测试配置管理的角色。

　　表1给出软件测试角色的定义。

　　表1 软件测试角色的定义

　　明确区分各类测试角色，并明确定义其资源（人/物/时间）的安排，是保障软件测试工作有序开展、有效管理的关键。

明确区分测试需求分析角色和测试过程设计的角色意义还在于：软件测试对软件功能/软件实现有了可追踪性，因而为准确评议测试用例的质量提供依据。

　　2.4 软件系统的测试流程

　　显示了大型复杂软件系统MARA的测试流程。

　　可以看到，结合测试操作类型和测试对象粒度的划分角度，MARA的测试阶段分为：单元测试、部件集成、部件确认、配置项组装、配置项确认、系统综合和系统验收。每个阶段都要经历2.2节说明的六个步骤。

　　表2说明各测试阶段的定义。

【摘要】本文针对测试的过程、测试所具备的素质、自动化测试、测试的误区等进行了简单的探讨，希望能给大家以启示。

【关键词】测试策略测试计划自动化测试

30年前，《人月神话》中说道“不为系统测试安排足够的时间简直就是一场灾难”

10年前，中国的软件公司大部分只有测试工作而没有测试人员

5年前，中国的软件公司开始让“老弱病残”做专门的软件测试

1年前， 很多中国的软件公司发现，没有通过专业测试人员测试过的软件根本不敢给客户看

• 前言

今年，我发现有一期《申江服务导报》上列举的最新职业中，其中有一项是“软件测试人员”，看到这条消息我感到由衷的欣慰，欣慰之中包含了太多的辛酸和无奈。

时至今日，我想不管是做测试的还是看测试的，都已经有一套理论了。所以本文，我就着重写点我自己从事测试工作的一些感受。

• 博弈的各方

选择意味着痛苦，这个世界上没有选择，可能生活会很简单。人是如此，公司亦然。自从公司内部多了一群专职做测试的人或者部门。管理人员发现，整个管理的对象中又多了一种人――软件测试人员。从此项目经理、业务分析人员、设计人员、程序开发人员、测试人员之间开始沟通了。下面，我个人对各种角色按照普遍的概念对其做一个简单描述：

项目经理：对项目的所有问题负责；

业务分析人员：清楚的了解客户的需求并以文档形式及时传递给每一个角色；

设计人员：根据需求文档做概要设计（或详细设计）

程序开发人员：根据设计文档（可能是自己写的）开发软件；

测试人员：根据需求文档（或设计文档）设计测试用例，并对开发人员提交的软件进行测试；

问题：

• 如果软件提交到客户那边出现无数个Bug，那么是谁的问题？
• 我们是否有一套指标体系来判断在哪个环节就已经出现问题了？
• 测试人员应该从哪个环节开始降低风险？
• 测试人员被授权到什么程度？
• 测试人员的能力是通过什么被认可的？
• 老板会相信谁？

笔者认为，在任何一个公司做测试工作首先要搞清楚以上问题。回答好上述问题那么测试工作基本上算入门了；能妥善的协调上面的问题那么就可以独当一面了；

• 测试的过程

如果拉住一个测试负责人一问，软件测试的过程是怎么样的，应该会从计划说到发布。实际上各个项目在开展测试的时候：1、各个阶段划分的不会太明显；2、某些阶段的功能会弱化，某些阶段的功能会延伸；下面我指出目前测试工作中基本上做的不足的或者比较常见的问题（有则改之、无则加勉）：

• 测试策略文档的普遍缺失；
• 测试范围的确认经常被其他文档或经验所取代；
• 测试计划受制于开发计划；
• 测试任务应该像BUG一样有明确的分级，不同类型的测试应该有相应的测试用例集合与之对应；
• 关键路径概念在测试规划时容易被项目经理弱化。

• 测试所具备的素质

很多人都在问我，如果我去做测试需要学一些什么东西比较好。我的答案是，大学学了四年，有多少是工作中直接用到的？对工作有指导意义的往往是当年根本不当一回事的那些知识。

其实，对于多数工作，短期内能提高的只是方法和技巧。基本的素质决定了你人生最终能走多远，而方法和技巧必须要到实际的工作中去摸索。我的建议是：

• 不要去做自己内心就抵制的工作；
• 不要首先给自己下一个定义，“我适合做什么”；
• 在中国很少有人把自己的工作当作自己的乐趣，如果你是这样，那么放下这篇文章，去工作吧；
• 我们在做一件必须要做的事情时，不管你喜欢不喜欢，先把它做好； 
• 自动化测试
• 这是一个不得不提的话题。
• 没有做过自动化测试的人，都梦想能精通一个自动化工具，期望以此来提高自己的江湖地位，并解决手工测试带来的痛苦；
• 正在做自动化测试的人，都很清楚自动化往往是一个大麻烦，老板总认为自动化上来了（当然是盗版的）就能解决所有的问题，堵枪眼就靠他了；

其实，自动化测试是一个很广泛的概念，目的不同需要的工具也不一样，每种工具都有自己独特的属性，在做一般功能测试的时候往往觉得所有的工具都差不多，当自动化测试开展到一定精细程度的时候，就会发现最初选择工具的重要性了。

开展自动化测试必须要做的两件事情：1、首先需要判断所测试的软件是否合适做自动化测试；2、选择一个合适的工具；

• 测试的误区

作为测试人员我们一定要搞清楚一点：我们不是救世主

软件开发是一个系统工程，决定一个项目（产品）的成败是所有环节和参与人员的合力的结果，在整个过程中的任何一个环节出现问题都可能导致最终的客户满意度的下降。问题往往暴露在测试这个阶段，即使很多企业号称全面质量管理，往往也是如此。

并不是有了测试人员软件质量就有了保障。目前所有有测试人员的公司都或多或少的有一种倾向：有了测试人员那么质量就有保障了，这句话反过来理解就是，如果软件质量出了问题那么就是测试人员的问题。如果这种观点是正确的话，那么没有测试人员参与的产品质量就应该是最好的，而事实上并非如此。

本文转载自51testing软件测试网：http://www.51testing.com/html/14/n-8714.html

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

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

引言

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

•  测试准备工作

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

• 向有经验的测试人员学习

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

• 阅读软件测试的相关书籍

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

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

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

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

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

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

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

• 学习产品相关的业务知识

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

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

•  识别测试需求

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

• 主动获取需求

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

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

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

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

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

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

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

总结：

限于文章的篇幅，本文不可能给出一个类似于 checklist 的指导性的软件测试新手入门。无论从事软件测试还是从事其它的工作，技术上的和技巧上的问题都可以通过查询相关的软件测试技术书籍获取，掌握一套基本的方法论是最重要的。以上文字，都是作者从事软件测试工作积累的经验之谈，如发现谬误之处请不吝指出。更多内容请登陆51testing软件测试网如下连接查看。

本文转载自：51testing软件测试网http://www.51testing.com/html/19/n-6519.html

刊首语……………………………………………………2

扼杀QTP检查点…………………………………………4

在LoadRunner脚本中使用关联………………………9

我的测试生活……………………………………………20

RationalClearQuest性能调优…………………………24

自动化测试指南…………………………………………38

嵌入式系统测试方法研究………………………………49

框架经理-FrameworkManager简介……………………57

软件测试中的3个W……………………………………63

可追溯矩阵………………………………………………72
【资料下载】

　　象我这样初学QTP的朋友刚开始时很可能没有注意到QuickTest Plus，因为QTP安装后默认是没有安装plus的，千回百转知道了plus，大概看了看，发现plus虽然都是些辅助性的小工具，但往往会给你的工作带来事半功倍的效果。

　　一、安装QuickTest plus

　　QTP安装后，在 程序 > QuickTest Professional下点击QuickTest Plus，然后按照提示一步步往下安装即可，其中要求输入序列号，输入和QTP安装时相同的序列号就可以了（8888-8888888888）。

　　二、提示和技巧

　　plus不仅提供了一些工具，还在它的帮助手册里给出了一些提示和技巧，以及一些实用的Function。

　　在这里我把一些比较常用的好东东贴出来，其他的就看plus的帮助吧。

　　1、创建action template.

　　当希望在每一个新建action时都增加一些头部说明，比如作者、创建日期、说明等，用action template来实现最简单快捷。

　　方法：用记事本等文本编辑器，输入如下类似的内容：

　　'Company: xxxx

　　'Author: xxx

　　'Product: xxx

　　'Date: xx

　　然后将文件保存为ActionTemplate.mst，并存放到QTP安装目录下的dat目录，重启QTP，新建一个action试试，新建的action会包含以上信息。

　　2、关于设置测试报告里只显示error的信息。

　　帮助中说：修改安装目录下bin\QTReport.ini文件，增加以下内容：

　　[FilterDialog]

　　ReportAppDefaultFilter=1 # for error only

　　ReportAppDefaultFilter=3 # shows all messages (default)

　　但根据我的测试结果，不尽其然：

　　1)当ReportAppDefaultFilter＝1时，如果Object Repository中缺少对象，在报告中会在相应的action前打叉，但不会提示具体错误，而成功的步骤都有具体信息显示。

　　2)用Reporter.ReportEvent测试的结果是：

　　ReportAppDefaultFilter＝1时，只显示micDone的具体信息；

　　ReportAppDefaultFilter＝2时，只显示micFail的具体信息；

　　ReportAppDefaultFilter＝3时，只显示micDone和micFail的具体信息；

　　ReportAppDefaultFilter＝4时，只显示micPass的具体信息；

　　似乎无规律可寻，所以我的结论暂时是：不要设置这个参数，用默认的，显示所有信息，更多的信息有利于分析结果。

　　3)启动IE的语句：SystemUtil.Run "iexplore.exe", "http://www.mercuryinteractive.com"

　　4)关闭IE或其他程序的语句：SystemUtil.CloseProcessByName "app.exe"　　or SystemUtil.CloseProcessByWndTitle "Some Title"

查看原文点击：http://www.51testing.com/html/200811/n97551.html

查看更多文章：http://www.51testing.com/html/news.html

　　测试……在我的理解是优化的前半部分，也就是优化策划，一个东西让你去测试，无非就是说要去根据客户的要求完善它，测试占的就是要把这个东西还没有符合的或者是和客户要求不一样的，或者是客户要求还没有完全达到要求的部分找出来，那要怎么去修练呢，这里我说一下我的方法：

　　1.首先要锻炼自己的能力（包括需求的分析能力，提取能力，逻辑化思想能力，通俗一点来说，就是给你一个系统的时候，你要先看客户在哪方面有要求，能够把系统中表现出来的提取出来校对，能够把整个业务流程很清晰的理出来）

　　2.学习测试理论知识并与你锻炼的能力相结合（学习理论的时候其实公式不需要管的，其中一部份的原因是目前测试方面还没有一套真正标准的公式能用得，大部分都是前人提出的想法，实用性不高。）

　　3.想和做（想就是说你看到任何的系统都要有习惯性的思考；做就是把实际去做练习，然后提取经验）

　　这些是我做了一年测试总结出来的，是我的个人见解，或者很多人在看了以后会问，测试用例，计划啊之类的那些那些怎么都没有提到？其实，那些东西不是说不重要，而是和你的测试能力和思想并没有太大的关联，能力和思想一旦到位了，你在写相关文档的时候也就基本知道需要表示哪些内容了……

　　希望我的这段话能够给大家带来启发。

　　最近收到一封邮件这样写道：

　　陈工：

　　您好，冒昧给您发邮件，没有不良的目的。我叫小范，计算机系毕业的，现在从事检索数据库的服务工作，现在想学一门技术，所以选择了“软件测试”这个行。

　　对于一个计算机专业，不懂代码编写、只懂数据库的简单语言的我，只能请求你教我，拜师学艺了，希望你能成为我的良师益友。

　　对软件测试工程，我要从最简单开始学起，希望您能指点。等待你的回复！

　　我想这是很多软件测试初学者共性的问题，因此决定把邮件的回复POST出来：

　　哈哈，“为师”则不敢当了，但是感谢你称我为陈工，我想“工”代表的是“工程师”，我为自己是一名工程师而感到骄傲，我甚至想到将来我的女儿在学校被人问起“你爸爸是干什么的啊？”的时候，她可以很骄傲地说“我爸爸是一名工程师”。

　　而且，作为软件测试工程师，我更加感到骄傲，因为软件测试作为IT业中新兴的职业（虽然早就有测试这个角色），近年来得到了大家的认可和重视，各企业纷纷招聘优秀的软件测试人才，组建软件测试队伍。我在这几年也亲身经历了软件测试由“无人问津”到目前“身价百倍”的过程。其实，这不仅仅是软件测试从业人员本身的进步和提高，而且是中国的整个软件行业对软件测试和软件质量的认识的提高。

　　另外，你把软件测试称之为一门“技术”，我想未免过于单纯，软件测试不是一门单纯的技术，它是一门融合了软件开发技术，软件设计和建模，业务和领域知识分析，用户模型分析等各方面知识的学科，它是一门讲求全面知识综合利用的学科，这也是为什么有经验的测试工程师那么地“值钱”，为什么有经验的测试工程师能轻易地发现很多别人不能发现的BUG的原因。

　　我喜欢你把软件测试的学习称之为“拜师学艺”。确实，软件测试需要掌握的知识很广泛和丰富（虽然有些知识看起来与软件测试没有什么直接的关联，或者暂时用不上），软件测试的学习就想修炼武工，需要坚持不懈，博采众家之长，融汇贯通，为我所用。

　　我说上面的这些，目的都是想你明白，软件测试目前在国内非常地“炙手可热”（我也面试过很多人是希望从软件的其它角色转换过来的人，例如开发转测试，技术支持转测试等，我在我的新书《软件测试技术全书》中对这个问题有一些阐述），但是其实很多人没有真正把它作为一个“工程师”的职业来看待，而是看到它目前很“HOT”，前景很可观，所以“趋之若鹜”。我希望更多的人能把软件测试作为终身的职业，正确地认识软件测试和质量管理，找到其中的乐趣，若干年后可以 “无愧”而“骄傲”地对自己的儿子或女儿说“我是一名软件测试工程师”。

查看更多文章：http://www.51testing.com/html/news.html

查看原文点击：http://www.51testing.com/html/news.html

        1、测试项目：删除
　　测试方法：对已拨/已接/未接/拒接中的电话记录进行单条删除和全部删除操作，当电话记录达到最大容量时，手机自动删除最老的记录，并且保存最近的电话记录。

　　判断标准: 手动删除操作能够实现，而且当电话记录达到最大容量时，能够自动删除最老的记录，并且保存最近的电话记录。

　　2、测试项目：保存

　　测试方法：对已拨/已接/未接/拒接中的电话记录进行保存操作?

　　判断标准: 电话记录保存操作能够实现。

　　3、测试项目：呼叫

　　测试方法: 对已拨/已接/未接/拒接中的电话记录进行呼叫操作?

　　判断标准: 电话记录呼叫操作能够实现。

　　4、测试项目：发信息

　　测试方法: 对已拨/已接/未接/拒接中的电话记录进行发信息操作。

　　判断标准: 对电话记录能够实现发信息操作。。

　　5、测试项目：存储空间确认

　　测试方法: 正确显示存储空间总量，并且区分已用空间、未用空间。

　　判断标准: 能够正确显示存储空间

阅读全文：http://www.51testing.com/?action_viewnews_itemid_87741.html