<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>新科海企业培训 &#187; 软件测试培训文章</title>
	<atom:link href="http://www.jobedu.com.cn/archives/category/technology/testdoc/feed" rel="self" type="application/rss+xml" />
	<link>http://www.jobedu.com.cn</link>
	<description>专注中国高端IT企业培训,网页设计培训,网页制作培,网页美术设计培训,Java企业培训,软件测试企业培训,软件企业培训,网络管理企业培训,MAX企业培训,就业培训,项目实训,中科院企业培训,电脑培训,计算机企业培训,咨询电话010-82622282</description>
	<lastBuildDate>Tue, 07 Feb 2012 11:19:58 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
		<item>
		<title>测试新人快速入职宝典</title>
		<link>http://www.jobedu.com.cn/archives/12234.htm</link>
		<comments>http://www.jobedu.com.cn/archives/12234.htm#comments</comments>
		<pubDate>Mon, 23 May 2011 03:32:24 +0000</pubDate>
		<dc:creator>yanzhiguo</dc:creator>
				<category><![CDATA[IT文摘]]></category>
		<category><![CDATA[软件测试培训文章]]></category>
		<category><![CDATA[入职宝典]]></category>
		<category><![CDATA[新手上路]]></category>
		<category><![CDATA[新科海]]></category>
		<category><![CDATA[新科海软件测试]]></category>
		<category><![CDATA[测试技术]]></category>
		<category><![CDATA[软件测试]]></category>
		<category><![CDATA[软件测试培训]]></category>
		<category><![CDATA[软件测试工程师培训]]></category>
		<category><![CDATA[软件测试技术]]></category>

		<guid isPermaLink="false">http://www.jobedu.com.cn/?p=12234</guid>
		<description><![CDATA[新人要学习的东西很多，先学什么后学什么?该如何分配?这是新人指南知识沉淀中整理出来的，大家可参考下：业务、技能、工具、流程&#8230;&#8230;很多培训，它们之间哪个是我该首先掌握的? &#160;&#160;&#160; 1、业务方面 &#160;&#160;&#160; 你所在业务线的业务知识，肯定是重点。每位新人来后，都会被分配到不同的组，不同的组其业务重点也不相同。建议新人可以在测试环境下实际操作下。 &#160;&#160;&#160; 把握当前工作的重点：虽然你处于某一条业务线，每条业务线的业务知识也是很多的，要和tl沟通，明确自己以后的工作重点。先从当前工作的重点开始，一点带面，逐渐掌握业务 &#160;&#160;&#160; 2、技能 &#160;&#160;&#160; 不同的新人技能要求也不一样。淘宝网将其分为多种测试类型：功能测试、性能测试、自动化测试、接口测试、安全性测试。 &#160;&#160;&#160; 每位新人要根据自己&#8220;入职时主管对你的定位&#8221;+&#8220;目前的优势&#8221;+&#8220;自己打算将来的发展方向&#8221;选择不同的技能提高。 &#160;&#160;&#160; 因为市面上的技能何其多，要塑造自己的优势。 &#160;&#160;&#160; 3、工具 &#160;&#160;&#160; 工具方面总体来说，跟技能是相同的。 &#160;&#160;&#160; 另外还要考虑公司需要的工具，以后要推广的工具。现在淘宝网已用ruby取代了QTP的自动化测试。 &#160;&#160;&#160; 4、流程 &#160;&#160;&#160; 查看流程规范。最重要的2个流程，就是&#8220;项目测试流程&#8221;和&#8220;日常测试流程&#8221;。 &#160;&#160;&#160; 我觉得还有比较重要的是注意发布流程的相关约定，比如周二或周四发布要在什么时间确保提交测试、什么时间预发布测试。 &#160;&#160;&#160; 对于新人，在项目中实践，通过执行别人写的用例，可以很快的体会测试的思想，掌握一些测试的基本方法。但自己编写TC，从UC提取TC，确实还需要一定时间的锻炼。 &#160;&#160;&#160; 记得刚开始的时候，从头到尾的看完UC，很多规则，脑袋看得晕乎乎的，TC的也是像抓图似的，抓了这块忘了那块。经过一段时间的练习，我逐渐掌握了较为系统的测试用例的编写方法，现把自己的一点体会总结下： &#160;&#160;&#160; 1、在测试之前，要熟读prd和UC，深入的挖掘UC，对于新增的业务，如果对之前的老业务不了解，那么一定要找出相应的资料了解下其中的规则。可以参照 自己所在产品线业务的mm图，熟悉整个业务框架。对于自己不明确的地方，UC上没有指出来的，记录下来，以便在UC评审的时候提出，及时的得到解答。 &#160;&#160;&#160; 2、根据UC编写TC。多参照QC里写的好的用例，对照着UC，会收获很多。目前各产品线也在总结一些公用控件的测试用例，为以后的测试形成规范和指导。 &#160;&#160;&#160; 3、还需要理论结合实践。测试用例的设计方法如：等价类划分、边界值分析、因果图法、判定表法等，结合相应的实例来学习会比较快的理解。 &#160;&#160;&#160; 4、BUG的经验总结，每周周会我们社区组成员都会分享这周发现的经典bug，并记录在cf上，彼此共同进步，感觉很好。也可以多看看站点上整理的经典bug，开拓自己发现bug的思路。 &#160;&#160;&#160; 刚进入这个行业，一切还不熟悉，但身边这么多热心的有经验的人，主动与他们交流，向他们请教自己心中的疑惑，自己平时多做总结，你会在不知不觉中提高自己的测试技术。 2011年05月23号 &#8212; 测试工具：Bugzilla简明使用手则 (0) 2011年05月23号 &#8212; 软件测试步骤 (0) 2011年05月23号 &#8212; 单元测试的重要性 (0) 2011年05月23号 [...]]]></description>
		<wfw:commentRss>http://www.jobedu.com.cn/archives/12234.htm/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>测试工具：Bugzilla简明使用手则</title>
		<link>http://www.jobedu.com.cn/archives/10014.htm</link>
		<comments>http://www.jobedu.com.cn/archives/10014.htm#comments</comments>
		<pubDate>Mon, 23 May 2011 03:31:23 +0000</pubDate>
		<dc:creator>yanzhiguo</dc:creator>
				<category><![CDATA[IT文摘]]></category>
		<category><![CDATA[软件测试培训文章]]></category>
		<category><![CDATA[Bugzilla]]></category>
		<category><![CDATA[新科海]]></category>
		<category><![CDATA[新科海学校]]></category>
		<category><![CDATA[新科海软件测试]]></category>
		<category><![CDATA[测试工具]]></category>
		<category><![CDATA[软件测试]]></category>
		<category><![CDATA[软件测试培训]]></category>
		<category><![CDATA[软件测试工程师培训]]></category>
		<category><![CDATA[软件测试技术]]></category>

		<guid isPermaLink="false">http://www.jobedu.com.cn/?p=10014</guid>
		<description><![CDATA[&#160; 　　1&#160; &#160;&#160; &#160;简介： Bugzilla是Mozilla公司向我们提供的一个开源的免费缺陷跟踪工具。作为一个产品缺陷的记录及跟踪工具，它能够为你建立一个完善的Bug跟 踪体系，包括报告Bug、查询Bug记录并产生报表、处理解决、管理员系统初始化和设置四部分。并具有如下特点： ●&#160; &#160;&#160; &#160; 基于Web方式，安装简单、运行方便快捷、管理安全。 ●&#160; &#160;&#160; &#160;有利于缺陷的清楚传达。本系统使用数据库进行管理，提供全面 详尽的报告输入项，产生标准化的Bug报告。提供大量的分析选项和强大的查询匹配能力，能根据各种条件组合进行Bug统计。当错误在它的生命周期中变化 时，开发人员、测试人 员、及管理人员将及时获得动态的变化信息，允许你获取历史纪录，并在检查错误的状态时参考这一记录。 ●&#160; &#160;&#160; &#160;系统灵活，强大的可配置能力。Bugzilla工具可以对软件产品设定不同的模块，并针对不同的模块设定开发人员 和测试人员；这样可以实现提交报告时自动发给指定的责任人；并可设定不同的小组。设定不同的用户对Bug记录的操作权限不同，可进行有效的控制管理。允许 设定不同的严重程度和优先级，可以在错误的生命期中管理错误，从最初的报告到最后的解决，都有详细的记录，确保了错误不会被忽略，同时，可以让开发人员将 注意力集中在优先级和严重程度高的错误上。 ●&#160; &#160;&#160; &#160; 自动发送Email通知相关人员。根据设定的不同责任人，自动发送最新的动态信息，有效的帮助测试人员和开发人员进行沟通。 2&#160; &#160;&#160; &#160;Bugzilla操作流程： 2.1&#160; &#160;用户登录及设置流程： ●&#160; &#160;&#160; &#160;打开浏览器，输入Bugzilla服务器地址：http://server/bugzilla/ ●&#160; &#160;&#160; &#160;进入主页面后，点击【新建帐号】，进入注册页面。 ●&#160; &#160;&#160; &#160;在注册页面中输入E-Mail地址和用户代号，然后，点击【Create Account】，随后，你将收到一封包含初始密码的E-Mail。 ●&#160; &#160;&#160; &#160;在收到E-Mail之后，点击【登录】，在帐号栏输入注册时使用的E-Mail地址，在密码栏输入邮件里通知的初始密码，然后，点击【Login】。 ●&#160; &#160;&#160; &#160;如忘记密码，在登陆页面中输入注册用户名，点击【Submit Request】,根据收到的邮件进行重新设置密码。 ●&#160; &#160;&#160; &#160;如果成功登录后，点击【Edit属性】-&#62;【帐号设置】，进行密码修改。 ●&#160; &#160;&#160; &#160;点击【Edit属性】-&#62;【邮件设置】，进行邮件通知设置。 ●&#160; [...]]]></description>
		<wfw:commentRss>http://www.jobedu.com.cn/archives/10014.htm/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>软件测试步骤</title>
		<link>http://www.jobedu.com.cn/archives/12352.htm</link>
		<comments>http://www.jobedu.com.cn/archives/12352.htm#comments</comments>
		<pubDate>Mon, 23 May 2011 03:25:57 +0000</pubDate>
		<dc:creator>yanzhiguo</dc:creator>
				<category><![CDATA[IT文摘]]></category>
		<category><![CDATA[软件测试培训文章]]></category>
		<category><![CDATA[单元测试]]></category>
		<category><![CDATA[性能测试]]></category>
		<category><![CDATA[新科海]]></category>
		<category><![CDATA[新科海软件测试]]></category>
		<category><![CDATA[步骤]]></category>
		<category><![CDATA[系统测试]]></category>
		<category><![CDATA[软件测试]]></category>
		<category><![CDATA[软件测试培训]]></category>
		<category><![CDATA[软件测试工程师培训]]></category>
		<category><![CDATA[软件测试技术]]></category>

		<guid isPermaLink="false">http://www.jobedu.com.cn/?p=12352</guid>
		<description><![CDATA[软件测试步骤 • 测试过程按4个步骤进行，即单元测试、集成测试、确认测试和系统测试及发版测试。 • 开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。 • 集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。 • 确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。 • 系统测试把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。 单元测试 (Unit Testing) • 单元测试又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。 • 单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。 1. 单元测试的内容 • 在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试 的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。 (1) 模块接口测试 • 在单元测试的开始，应对通过被测模块的数据流进行测试。测试项目包括： – 调用本模块的输入参数是否正确； – 本模块调用子模块时输入给子模块的参数是否正确； – 全局量的定义在各模块中是否一致； •     在做内外存交换时要考虑： – 文件属性是否正确； –   OPEN与CLOSE语句是否正确； – 缓冲区容量与记录长度是否匹配； – 在进行读写操作之前是否打开了文件； – 在结束文件处理时是否关闭了文件； – 正文书写／输入错误， –   I／O错误是否检查并做了处理。 (2) 局部数据结构测试 • 不正确或不一致的数据类型说明 [...]]]></description>
		<wfw:commentRss>http://www.jobedu.com.cn/archives/12352.htm/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>单元测试的重要性</title>
		<link>http://www.jobedu.com.cn/archives/12372.htm</link>
		<comments>http://www.jobedu.com.cn/archives/12372.htm#comments</comments>
		<pubDate>Mon, 23 May 2011 03:24:53 +0000</pubDate>
		<dc:creator>yanzhiguo</dc:creator>
				<category><![CDATA[IT文摘]]></category>
		<category><![CDATA[软件测试培训文章]]></category>
		<category><![CDATA[单元测试]]></category>
		<category><![CDATA[新科海]]></category>
		<category><![CDATA[新科海软件测试]]></category>
		<category><![CDATA[软件测试]]></category>
		<category><![CDATA[软件测试培训]]></category>
		<category><![CDATA[软件测试工程师培训]]></category>
		<category><![CDATA[软件测试技术]]></category>

		<guid isPermaLink="false">http://www.jobedu.com.cn/?p=12372</guid>
		<description><![CDATA[　　在实际的单元测试过程中总会有一些错误的认识左右着我们，使之成为单元测试最大的障碍，在此将其一一分析如下： 　　它太浪费时间了，现在要赶进度，时间上根本不允许，或者随便做做应付领导。 　　我是一个很棒的程序员，我写的代码肯定是没有问题的。 　　做单元测试太烦了，直接集成，到时有问题在集成测试时肯定能发现的，实在不行在系统测试总该能发现吧。 　　它仅仅是证明这些代码做了什么。 　　对于以上错误认识的产生归根结底还是由于对单元测试的理解还是不够，没有真正认识到单元测试的重要性。 　　单元测试的重要性 　　单元测试是软件测试的基础，因此单元测试的效果会直接影响到软件的后期测试，最终在很大程度上影响到产品的质量。从如下几个方面就可以看出单元测试的重要性在何处。 　　时间方面：如果认真的做好了单元测试，在系统集成联调时非常顺利，因此会节约很多时间，反之那些由于因为时间原因不做单元测试或随便做做的则在集成时总会遇到那些本应该在单元测试就能发现的问题，而这种问题在集成时遇到往往很难让开发人员预料到，最后在苦苦寻觅中才发现这是个很低级的错误而在悔恨自己时已经浪费了很多时间，这种时间上的浪费一点都不值得，正所谓得不偿失。 　　测试效果：根据以往的测试经验来看，单元测试的效果是非常明显的，首先它是测试阶段的基础，做好了单元测试，在做后期的集成测试和系统测试时就很顺利。其次在单元测试过程中能发现一些很深层次的问题，同时还会发现一些很容易发现而在集成测试和系统测 试很难发现的问题。再次单元测试关注的范围也特殊，它不仅仅是证明这些代码做了什么，最重要的是代码是如何做的，是否做了它该做的事情而没有做不该做的事情。 　　测试成本：在单元测试时某些问题就很容易发现，如果在后期的测试中发现问题所花的成本将成倍数上升。比如在单元测试时发现1个问题需要1个小时，则在集成测试时发现该问题需要2个小时，在系统测试时发现则需要3个小时，同理还有定位问题和解决问题的 费用也是成倍数上升的，这就是我们要尽可能早的排除尽可能多的bug来减少后期成本的因素之一。 　　产品质量：单元测试的好与坏直接影响到产品的质量，可能就是由于代码中的某一个小错误就导致了整个产品的质量降低一个指标，或者导致更严重的后果，如果我们做好了单元测试这种情况是可以完全避免的。 　　综上所述，单元测试是构筑产品质量的基石，我们不要因为节约单元测试的时间不做单元测试或随便做而让我们在后期浪费太多的不值得的时间，我们也不愿意因为由于节约那些时间导致开发出来的整个产品失败或重来! 2011年05月23号 &#8212; 软件测试步骤 (0) 2011年05月23号 &#8212; 测试新人快速入职宝典 (0) 2011年05月23号 &#8212; 测试工具：Bugzilla简明使用手则 (0) 2011年05月23号 &#8212; 测试用例是否应该包含所有的细节？ (0) 2011年05月23号 &#8212; SQA测试流程 (0) 2011年05月23号 &#8212; 软件测试之测试工作中的缺陷跟踪管理 (0) 2011年05月23号 &#8212; 循序渐进学习QTP三步曲 (0) 2011年05月23号 &#8212; 增加、编辑、删除和密码修改测试用例 (0) 2011年05月23号 &#8212; 关于测试用例的一点思考 (0) 2011年05月23号 &#8212; 好的测试所应具有的品质 (0)]]></description>
		<wfw:commentRss>http://www.jobedu.com.cn/archives/12372.htm/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>站点测试（Web Testing）概述</title>
		<link>http://www.jobedu.com.cn/archives/12320.htm</link>
		<comments>http://www.jobedu.com.cn/archives/12320.htm#comments</comments>
		<pubDate>Mon, 23 May 2011 03:24:37 +0000</pubDate>
		<dc:creator>yanzhiguo</dc:creator>
				<category><![CDATA[IT文摘]]></category>
		<category><![CDATA[软件测试培训文章]]></category>
		<category><![CDATA[web testing]]></category>
		<category><![CDATA[兼容性测试]]></category>
		<category><![CDATA[功能测试]]></category>
		<category><![CDATA[压力测试]]></category>
		<category><![CDATA[安全测试]]></category>
		<category><![CDATA[接口测试]]></category>
		<category><![CDATA[新科海]]></category>
		<category><![CDATA[新科海软件测试]]></category>
		<category><![CDATA[站点测试]]></category>
		<category><![CDATA[软件测试培训]]></category>
		<category><![CDATA[软件测试工程师培训]]></category>
		<category><![CDATA[软件测试技术]]></category>

		<guid isPermaLink="false">http://www.jobedu.com.cn/?p=12320</guid>
		<description><![CDATA[介绍 本文将 web 测试分为 6 个部分： 用户界面测试 功能测试 接口测试 兼容性测试 负载/压力测试 安全测试 本文的目的是覆盖 web 测试的各个方面，未就某一主题进行深入说明。 用户界面 使用 Web 浏览器作为应用程序的前台的一个原因就是它易于使用。用户知道如何浏览一个构建良好的网站。如果你注重这方面的测试，那么验证应用程序是否易于使用就非常重要了。很多人认为这是测试中最不重要的部分，但是如果你想通过网站赚钱，最好使你的网站使用起来更加方便。 使用说明 应该确认你的站点有使用说明。即使你认为你的网站很简单，也可能有人在某些方面需要征实一下。测试人员需要测试说明文档，验证说明是正确的。还可以根据说明进行操作，确认出现预期的结果。 站点地图和导航条 确认你测试的站点是否有地图。有些网络高手可以直接去自己要去的地方，而不必点击一大堆页面。另外新用户在网站中可能会迷失方向。站点地图和/或导航条可以引导用户进行浏览。需要验证站点地图是否正确。确认地图上的链接是否确实存。地图有没有包括站点上的所有链接。是否每个页面都有导航条? 导航条是否一致? 每个页面的链接是否正常? 导航条是否直观? 内容 对于开发人员来说，可能先有功能然后才对这个功能进行描述。大家坐在一起讨论一些新的功能，然后开始开发，在开发的时候，开发人员可能不注重文字表达，他们添加文字可能只是为了对齐页面。不幸的是，这样出来的产品可能产生严重的误解。因此测试人员和公关部门一起检查内容的文字表达是否恰当。否则，公司可能陷入麻烦之中，也可能引起法律方面的问题。测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可能会让用户感到不舒服。在进行用户可用性方面的测试时，最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章，所以相信您也希望自己的站点能更专业一些。 最后，需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址，或者从某个站点下载浏览器。但是如果用户无法点击这些地址，他们可能会觉得很迷惑。 颜色/背景 由于 web 日益流行，很多人把它看作图形设计作品。不幸的是，有些开发人员对新的背景颜色更感兴趣，以至于忽略了这种背景颜色是否易于浏览。典型的站点是在紫色图片的背景上显示黄色的文本(如果你没有见过这样的站点，请浏览一下 GeoCities 或 AOL 上的个人主页，有不少这样的)。这种页面显得&#34;非常高贵&#34;，但是看起来很费劲。通常来说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。 图片 无论作为屏幕的聚焦点或作为指引的小图标，一张图片都胜过千言万语。有时，告诉用户一个东西的最好办法就是将它展示给用户。但是，带宽对客户端或服务器来说都是非常宝贵的，所以要注意节约使用内存。是否所有的图片对所在的页面都是有价值的，或者它们只是浪费带宽? 使用其它的文件格式(.GIF, .JPG) 是否能使图片的大小减小到 30k 以下? 通常来说，不要将大图片放在首页上，因为这样可能会使用户放弃下载首页。如果用户可以很快看到首页，他可能会浏览站点，否则可能放弃。 表格 需要验证表格是否设置正确。用户是否需要向右滚动页面才能看见产品的价格？把价格放在左边，而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽，表格里的文字是否都有折行？是否有因为某一格的内容太多，而将整行的内容拉长? 回绕 最后，需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。 　 功能测试 Web 站点的功能是贵公司雇佣开发人员而不只是艺术家的原因。就是这一部分与服务器通讯并且最终完成任务。 &#160; [...]]]></description>
		<wfw:commentRss>http://www.jobedu.com.cn/archives/12320.htm/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>测试用例是否应该包含所有的细节？</title>
		<link>http://www.jobedu.com.cn/archives/12151.htm</link>
		<comments>http://www.jobedu.com.cn/archives/12151.htm#comments</comments>
		<pubDate>Mon, 23 May 2011 03:21:39 +0000</pubDate>
		<dc:creator>yanzhiguo</dc:creator>
				<category><![CDATA[IT文摘]]></category>
		<category><![CDATA[软件测试培训文章]]></category>
		<category><![CDATA[新科海]]></category>
		<category><![CDATA[新科海软件测试]]></category>
		<category><![CDATA[测试用例]]></category>
		<category><![CDATA[测试用例内容]]></category>
		<category><![CDATA[软件测试]]></category>
		<category><![CDATA[软件测试培训]]></category>
		<category><![CDATA[软件测试工程师培训]]></category>
		<category><![CDATA[软件测试技术]]></category>

		<guid isPermaLink="false">http://www.jobedu.com.cn/?p=12151</guid>
		<description><![CDATA[&#160;&#160;&#160;&#160;&#160; 测试用例写的太细化了，则适应不了系统的变更需求；写的太粗糙，则可操作性不强，太随意。如果文档中的对操作步骤描述的过于具体，像下面这样： 　　01.　　在&#8220;用户名&#8221;项中输入&#8220;user&#8221;； 　　02.　　在&#8220;密码&#8221;项中输入&#8220;password&#8221;； 　　03.　　点击&#8220;确定&#8221;按钮。 　　这样的描述方式表面看起来可操作性似乎是增强了，任何人拿到这个文档都可以充当测试人员，检查一下这个功能是否存在缺陷。但是我们不要忘记，在开发过程中，变更的存在是必然的。一旦需求、设计或者应用程序中的某些细节发生了变化，比如&#8220;用户名&#8221;变成了&#8220;操作员&#8221;，&#8220;密码&#8221;变成了&#8220;口令&#8221;，&#8220;确定&#8221;变成了&#8220;登录&#8221;，或者输入项所接受的数据类型发生了变化，那么同这部分内容相关的所有的测试用例都需要修改。否则，我们凭什么可以保证这些描述不同的测试用例说的是同一样东西？如果我们只有这么一个测试用例，也许一切都不是问题，但是对于一个业务复杂、功能完整的系统，如果按照这样的方法描述测试用例，最终要么产生大量的测试用例文档，要么产生过长的单个文档。无论是那一种，如果发生了类似于上面 说的变化，维护文档都将变成一次地狱式的体验。这也是为什么在网络上频频出现的这个问题，而且每次出现都会受到测试同行们的关注的原因。 　　那么这个问题应该任何解决呢？测试用例是不是把所有的流程写出来就可以了呢？如何在减少测试用例文档中包含过多琐碎的细节的同时保证测试用例的可操作性呢？又有什么方法可以提高我们维护测试用例文档的效率呢？笔者的建议是：关注&#8220;测试思想&#8221;而不是关注操作步骤。 &#160;&#160;&#160;&#160;&#160;&#160; 要理解这个问题，首先要弄明白测试用例的作用。就像用例一样，测试用例并不是用来描述具体的实现的，而是着重描述处理问题的思路&#8212;&#8212;对于一项明确的测试内容进行测试的思路。作为测试用例的设计人员，如何理解基本流和备选流？如何深入分析并找到所有需要覆盖的路径和需要检查的特性？我们在测试用 例中应该用容易理解的自然语言清晰的来描述我们将要如何进行测试，而不是简单的把在应用程序上如何操作的烦琐的步骤记录下来。把测试用例设计当成填写具体 操作步骤的表格是人们对测试用例最大的误解。传统的测试用例文档编写有两种方式。一种是填写操作步骤列表：将在软件上进行的操作步骤一步一步详细的记录下 来，包括所有被操作的项目和相应的值。另一种是填写测试矩阵：将被操作项作为矩阵中的一个字段，而矩阵中的一条条记录，则是这些字段的值。网络上对于这两 种方式孰优孰劣的争论，将大家错误的引导向了两个极端：要么采用A，要么采用B。而大家却忽视了一点，对于工作方法的争论，本质上同工具的争论并不是一回 事（例如曾经的VC、BCB之挣）。如果不同的方法各有优势，我们完全可以通过变通的方法，把优势的部分组合在一起来使用。操作步骤列表的优势在于对基本 流和备选流进行分析后，它可以清晰的描述您的测试思路。而测试矩阵则更适合于用来存放测试数据，特别是那些需要人工赋予一个确定的值的特性。下面，我们来看一个例子，当然，这个例子同样是杜撰的。 需求名称：用户登录安全验证 需求描述：用户登录安全验证是为了保证所有登录到系统中的用户，都是由系统管理员预先在系统中设定的。使用系统中不存在的用户名，或者用户名输入正确，但密码输入错误情况，都无法 登录到系统中。当用户使用了不存在的用户名或错误的密码时，系统应分别给出适当的提示。如果用户连续三次无法使用正确的用户名和密码登录到系统，则系统应 给出适当的提示，并退出当前程序。如果用户使用正确的用户名和密码登录到系统，则退出界面，转到系统主界面。对于用户登录界面和程序主界面，请参考相应的 UI设计文档。 　　测试需求： 　　01.　检查能否使用正确的用户名和密码登录到系统； 　　02.　检查能否使用错误的用户名或密码登录到系统； 　　03.　检查使用错误的用户名和密码登录失败超过三次，是否会自动退出当前程序。 　　测试用例： 序号 操作过程描述 1 输入用户名。 2 输入密码。 3 确认登录。 &#160; 序号 用户名 密码 预期结果 1 正确的用户名 正确的密码 登录到系统并转到系统主界面 2 正确的用户名 错误的密码 无法登录到系统并提示密码错误 3 错误的用户名 正确的密码 无法登录到系统并提示用户名错误 4 错误的用户名 错误的密码 无法登录到系统并退出当前程序 [...]]]></description>
		<wfw:commentRss>http://www.jobedu.com.cn/archives/12151.htm/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>SQA测试流程</title>
		<link>http://www.jobedu.com.cn/archives/12307.htm</link>
		<comments>http://www.jobedu.com.cn/archives/12307.htm#comments</comments>
		<pubDate>Mon, 23 May 2011 03:16:54 +0000</pubDate>
		<dc:creator>yanzhiguo</dc:creator>
				<category><![CDATA[IT文摘]]></category>
		<category><![CDATA[软件测试培训文章]]></category>
		<category><![CDATA[SQA]]></category>
		<category><![CDATA[新科海]]></category>
		<category><![CDATA[新科海软件测试]]></category>
		<category><![CDATA[测试流程]]></category>
		<category><![CDATA[测试计划]]></category>
		<category><![CDATA[测试设计]]></category>
		<category><![CDATA[软件测试]]></category>
		<category><![CDATA[软件测试培训]]></category>
		<category><![CDATA[软件测试工程师培训]]></category>
		<category><![CDATA[软件测试技术]]></category>

		<guid isPermaLink="false">http://www.jobedu.com.cn/?p=12307</guid>
		<description><![CDATA[测试生命周期 　　测试计划 &#8594; 测试设计 &#8594; 测试开发 &#8594; 测试执行 &#8594; 测试评估 　　测试计划就是定义一个测试项目的过程，以便能够正确的度量和控制测试。 　 第一部分：测试计划 　 测试计划的问题： 　　1、测试计划经常是等到开发周期后期才开始实行，使得没有时间有效的执行计划； 　　2、测试计划的组织者可能缺乏Client/Server测试经验； 　　3、测试的量度和复杂性可能太大，没有自动化工具，很难计划和控制。 测试策略： 　　测试策略描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试（单元测试、集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试、性能测试、压力测试等）。 　　测试策略包括 　　1、要使用的测试技术和工具； 　　2、测试完成标准； 　　3、影响资源分配的特殊考虑例如测试与外部接口或者模拟物理损坏、安全性威胁。 　　测试计划最关键的一步就是将软件分解成单元，写成测试需求。 　　测试需求有很多分类方法，最普通的一种就是按照商业功能分类。把软件分解成单元元件有几个好处： 　　1、测试需求是测试设计和开发测试用例的基础，分成单元可以更好地进行设计； 　　2、详细的测试需求是用来衡量测试覆盖率的重要指标； 　　3、测试需求包括各种测试实际和开发以及所需资源。 怎样估计测试工作量： 　　1、效率假设：即测试队伍的工作效率。对于功能测试，这主要依赖于应用的复杂度，窗口的个数，每个窗口中的动作数目。对容量测试，主要依赖于建立测试所需数据的工作量大小。 　　2、测试假设：为了验证一个测试需求所需测试动作数目。 　　3、应用的维数：应用的复杂度指标。例如要加入一个记录，测试需求的维数就是这个记录中域的数目。 　　4、所处测试周期的阶段：有些阶段主要工作都在设计，有些阶段主要是测试执行。 测试资源： 　　1、人力资源 　　测试项目经理 　　为测试项目提供总体方向。开发测试计划、征集并监督测试人员、申请系统资源、监视并汇报工作进程、测试评估、测试需求的分解。 　　测试工程师 &#8212;- 设计和开发 　　设计：对被测软件的详细了解、分解测试需求的技能、选择在C/S环境下用来验证测试需求的技术。 　　开发：熟悉SQA、VB、和脚本语言。 　　测试工程师 &#8212;- 执行 　　负责测试执行和记录结果。需要能够安装系统，网络知识，初始化数据库和其他初始条件。重要的是诊断能力。 　　测试系统管理者 　　每个测试项目必须指定一个专人负责管理SQA Suite。包括在服务器上安装存储库，安装打印机连接，执行备份，以及其他维护工作。管理者必须高度熟悉SQA，网络工作经验。 　　2、系统资源 　　安装SQA Suite的硬件和软件环境 　　数据库服务器 　　该服务器必须专用于 [...]]]></description>
		<wfw:commentRss>http://www.jobedu.com.cn/archives/12307.htm/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>软件测试之测试工作中的缺陷跟踪管理</title>
		<link>http://www.jobedu.com.cn/archives/12369.htm</link>
		<comments>http://www.jobedu.com.cn/archives/12369.htm#comments</comments>
		<pubDate>Mon, 23 May 2011 03:12:23 +0000</pubDate>
		<dc:creator>yanzhiguo</dc:creator>
				<category><![CDATA[IT文摘]]></category>
		<category><![CDATA[软件测试培训文章]]></category>
		<category><![CDATA[Bugzilla]]></category>
		<category><![CDATA[新科海]]></category>
		<category><![CDATA[新科海软件测试]]></category>
		<category><![CDATA[缺陷跟踪管理]]></category>
		<category><![CDATA[软件测试]]></category>
		<category><![CDATA[软件测试培训]]></category>
		<category><![CDATA[软件测试工程师培训]]></category>
		<category><![CDATA[软件测试技术]]></category>
		<category><![CDATA[软件缺陷]]></category>

		<guid isPermaLink="false">http://www.jobedu.com.cn/?p=12369</guid>
		<description><![CDATA[　　本文介绍了基于B/S模式的软件缺陷跟踪管理系统的设计与实现。软件缺陷是在软件生命周期中不可避免的对象。缺陷跟踪管理是软件管理的重要组成。现有管理方法是将进入到系统中的问题,都认为是软件缺陷进行处理。但是实际情况却可能有虚假或重复的缺陷报告。不及时处理这些问题,它本身又可能形成新的缺陷。从软件系统考虑,应将软件缺陷跟踪管理纳入到项目管理信息系统之中,成为项目管理信息系统的一个子系统。对维护人员提交的缺陷报告认真鉴定、筛选、分类,进入不同的处理流程,以获得真正的缺陷跟踪数据。本文在分析讨论这些问题的基础上,提出新的软件缺 陷跟踪管理系统的总体结构。 　　软件缺陷跟踪管理系统在现代软件开发中已经占据了很重要的位置。每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本。可遗憾的是，并非所有的软件组织都知道如何有效地管理自己软件中的缺陷。CMM及CMMI都对软件缺陷跟踪给予了关注并做出了相关规定。本文的侧重点放在了讨论这个程序的需求分析、设计、实现及所用到的项目管理知识。借着实现这个简单的缺陷跟踪系统，探讨了个人软件开发过程当中遇到的各种问题，以及解决它们的方法，展示了个人软件开发的一般过程。 　　缺陷跟踪管理是测试工作的一个重要部分，测试的目的是为了尽早发现软件系统中的缺陷，因此，对缺陷进行跟踪管理，确保每个被发现的缺陷都能够及时得到处理是测试工作的一项重要内容。 　　1、 缺陷跟踪管理的目标 　　缺陷能够引起软件运行时产生的一种不希望或不可接受的外部行为结果，软件测试过程简单说就是围绕缺陷进行的，对缺陷的跟踪管理一般而言需要达到以下的目标： 　　确保每个被发现的缺陷都能够被解决；这里解决的意思不一定是被修正，也可能是其他处理方式（例如，在下一个版本中修正或是不修正），总之，对每个被发现的BUG的处理方式必须能够在开发组织中达到一致； 　　收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段；决定测试过程是否结束有很多种方式，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。 　　收集缺陷数据并在其上进行数据分析，作为组织的过程财富。 　　上述的第一条是最受到重视的一点，在谈到缺陷跟踪管理时，一般人都会马上想到这一条，然而对第二和第三条目标却很容易忽视。其实，在一个运行良好的组织中，缺陷数据的收集和分析是很重要的，从缺陷数据中可以得到很多与软件质量相关的数据。 　　2、 缺陷的描述 　　对缺陷的描述应该包含以下的内容： 可追踪信息 　　缺陷ID：唯一的缺陷ID，可以根据该ID追踪缺陷 　　缺陷基本信息 　　缺陷状态：缺陷的状态，分为&#8220;待分配&#8221;、&#8220;待修正&#8221;、&#8220;待验证&#8221;、&#8220;待评审&#8221;、&#8220;关闭&#8221; 　　缺陷标题：描述缺陷的标题 　　缺陷的严重程度：描述缺陷的严重程度，一般分为&#8220;致命&#8221;、&#8220;严重&#8221;、&#8220;一般&#8221;、&#8220;建议&#8221;四种 　　缺陷的紧急程度：描述缺陷的紧急程度，从1－4，1是优先级最高的等级，4是优先级最低的等级 　　缺陷提交人：缺陷提交人的名字（邮件地址） 　　缺陷提交时间：缺陷提交的时间 　　缺陷所属项目/模块：缺陷所属的项目和模块，最好能较精确的定位至模块 　　缺陷指定解决人：缺陷指定的解决人，在缺陷&#8220;提交&#8221;状态为空，在缺陷&#8220;分发&#8221;状态下由项目经理指定相关开发人员修改 　　缺陷指定解决时间：项目经理指定的开发人员修改此缺陷的deadline 　　缺陷处理人：最终处理缺陷的处理人 　　缺陷处理结果描述：对处理结果的描述，如果对代码进行了修改，要求在此处体现出修改 　　缺陷处理时间：缺陷处理的时间 　　缺陷验证人：对被处理缺陷验证的验证人 　　缺陷验证结果描述：对验证结果的描述（通过、不通过） 　　缺陷验证时间：对缺陷验证的时间 　　缺陷的详细描述：对缺陷的详细描述；之所以把这项单独列出来，是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改，描述应该尽可能详细 　　测试环境说明：对测试环境的描述 　　必要的附件：对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的 　　除上述描述项外，从统计的角度出发，还可以添加上&#8220;缺陷引入阶段&#8221;、&#8220;缺陷修正工作量&#8221;等项目。 　　3、 缺陷管理的一般流程 　　缺陷管理的流程比较简单，图1是一个缺陷状态图。 　　流程中的角色： 　　1、 测试人员：进行测试的人员，缺陷的发起者； 　　2、 项目经理：对整个项目负责，对产品质量负责的人员； 　　3、 开发人员：执行开发任务的人员，完成实际的设计和编码工作； 　　4、 评审委员会：对缺陷进行最终确认，在项目成员对缺陷达不成一致意见时，行使仲裁权力。 　　缺陷的状态 　　1、 初始化：缺陷的初始状态； 　　2、 待分配：缺陷等待分配给相关开发人员处理； 　　3、 待修正：缺陷等待开发人员修正； [...]]]></description>
		<wfw:commentRss>http://www.jobedu.com.cn/archives/12369.htm/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

