(ijmdlsydnda)
第三方登录：一、软件测试需要哪些知识
很多人都在各大论坛提问"我是零基础该如何学习软件测试"。关于这个问题首先应该给零基础定一个范围，到底什么样才是零基础，从来没有接触过计算机的？我是学英语的只了解一些？还是学计算机的没有接触过测试的。对于第一种我想现在应该没有了吧。为了回答这个问题，我们先看一下做软件测试工作需要掌握哪些知识。
我们要做的工作时软件测试，而不是硬件测试。那么这个就可以分为两部分了，一个是测试的知识，另一部分是软件的知识。先看一下测试的知识，这部分主要是对测试概念要了解，常见的测试策略和方法，发现缺陷后怎么处理等内容，当然这里的测试知识还是针对软件测试的。再看软件，首先软件是运行在一个操作系统中的（这里不是很准确），那么你就要对它运行的环境要了解，软件是编程语言开发的，所以也要对开发他的语言有一定的了解，现在的软件越来越多的都是基于网络的，所以还要对网络知识有一定的了解。
OK，现在就来看一下软件测试需要掌握的知识了吧。
1、首先是软件测试的基础知识，包括软件测试的概念、过程，测试用例和缺陷等相关知识。
2、第二部分就是测试环境的知识（这放在第一位也是可以的），这主要就是对常见的操作系统要了解，会搭建测试环境，主要就是Windows、Linux和Mac OS.
3、就是要了解数据库的知识，现在大多软件都是要用数据库存储数据的。而且面试也会问很多关于数据库的内容。
4、就是要熟悉一门程序设计语言，常见的有Java、C、C++……
5、了解自动化测试的知识，主要是会使用自动化工具，像QTP、Loadrunner、QC这些。
6、就是白盒测试知识和白盒工具。
其中像自动化和白盒部分的内容对于零基础来说刚开始工作肯定是接触的很少的。那么只要你把前4部分掌握好，找到软件测试的工作应该是不成问题的了。
二、如何学习每门课程
测试基础：这部分内容概念还是比较多的，也是最重要的部分，所以要重概念、重理解、重体会。重概念就是记住这些概念了，然后要理解它了，重体会就是在项目中要来体会它，有自己的见解。
数据库：数据库是一门实践性很强的课程，所以要重概念、重操作。对于基础的概念还是要理解的，只有理解了这些才能跟好的使用它。要熟练的使用的数据库，对重要的命令要牢记。多上机练习。
Java部分：这部分也是要重概念、重实践。学习程序设计的好办法就是多读代码，多写代码了。没有什么捷径。
自动化部分：这部分主要是介绍一些工具，所以还是要重概念、重操作。多去实践，熟练操作。
Linux部分：还是重概念、重实践啊，理解一些基本概念，多去实践，这样命令才能记住。
白盒部分：现阶段对它重概念就可以了，记住基本概念。
上述的具体内容可参考我的另一篇博客 零基础学软件测试V2.0：
１.基本概念
　１.１软件
　软件就是可以在计算机上运行的计算机程序，如操作系统Windows、办公软件Office、聊天ＱＱ、手机游戏等。软件和我们的生活和工作之间的联系越来越密切。
小白如何快速入门软件测试
先说点我的测试经历，让大家都软件测试有些认识.
毕业后,拿着简历想都没想一头就扎到了苏州，作为一个北方女汉子，一直被“青石板小路回眸一笑的女子”的曼妙所感动，全无他因，事后说起，一朋友评价说我是个完...
零基础学软件测试难吗？小白怎么半年内成为测试工程师
软件测试（Software Testing），描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出之间的审核或者比较过程。软件测试的经典定义是：在规...
零基础如何学软件测试？
一、软件测试需要哪些知识
很多人都在各大论坛提问&我是零基础该如何学习软件测试&。关于这个问题首先应该给零基础定一个范围，到底什么样才是零基础，从来没有接触过计算机的？我是学英语的只了解一些...
软件测试自学指南---从入门到精通
近来，软件测试行业发展迅速，企业越来越重视测试了。越来越多的人加入了测试大军中，很多人也想通过自学来学习软件测试技术加入这个行业，但是现在软件测试的书籍越来越多，也良莠不齐，而且软件测试涉及的技术也越...
软件测试知识学习路线
本人做软件测试3年多，时间说长不算长，但也不短了，这3年来对软件测试这个行业已经有了一定了解，测试这行有人说很简单，就是点点程序，看会不会出错，其实不然，测试也是有很多学问的，要真正想把测试做好，也是...
为了更好能够掌握的学习方法、提升自动化测试学习能力，限加入学习小组内成员参与学习。课程主题：基于pthon + selenium Web项目自动化测试一、课程时间：6月4日-8日二、课程亮点：1.基于...
APP自动化框架选择
目前较火的自动化工具特点对比：
Appium（适用于Android&iOS；支持多语言；不需要应用源码）Uiautomator（适用于Android；仅Java语言；不需...
导言：到底什么是自动化测试？
自动化测试的本质是：用程序测试程序。也就是说学习“编程语言”是学习自动化测试的基础。掌握自动化测试的基本概念、需要掌握的编程知识和自动化测试的分类。
一、具体...
本文档由松勤网(松勤软件测试)整理提供,详细讲解appium&em&自动化测试&/em&环境的搭建以及使用。
没有更多推荐了，购买商品：
商品价格：
价格读取中
支付方式：
请扫码进行支付
请扫码进行支付
适合人群菜鸟级小白学员已参加学习11802
会员立省49.90元，
会员立省49.90元，
帮助学习者掌握从事软件测试工作的基础理论与技能，熟知软件测试的整个流程并胜任招聘企业中初级测试工程师职位的要求。
第一章：测试工程师必备基础技能
第二章：测试流程
第三章：测试流程
第四章：测试实施
第五章：测试总结
第六章：浅尝自动化
河北师大软件学院测试教室主任、项目基地测试经理;尚大学.金牌讲师。擅长技术： 项目模块化流程设计、软件测试流程设计及优化、项目管理平台的整合与应用、功能性自动化测试工具、性能测试工具、测试管理工具、Linux、Oracle11g；至今获得证书：MCITP、国家软件测评师、OCP及华为网络工程师；出版的多本图书。
领取优惠券
正在努力加载中~~软件测试技术自学需要阅读哪些书籍__太原计算机编程入门培训
软件测试技术自学需要阅读哪些书籍
时间： 08:33
来源：公众号：鲁德
软件测试相信现在很多学习互联网IT技术的人已经都接触或者说了解过了，那么在不参加培训班的基础上，如何才能学习掌握软件测试技术呢?对了，就是通过读书来学习。下面，太原软件测试培训学校就给大家分享了关于软件测试的几本书，一起来了解一下吧。
软件测试的艺术
软件测试工程师入门“圣经”。
软件从业人员必备书。
计算机经典著作。
技术类“常青树”书籍。
本书对软件测试类型、用例设计方法、测试策略等，都有精彩具体的描述;总结的十大软件测试经典原则，至今仍被广为引用。
此书100多页，适合每年精读一次，每次都会有新的感悟。
PS：此书版出版于1979年，比八九零后存在的历史还长。
软件测试行业入门“地图”。
软件测试新人的指导书。
本书描述了软件测试行业的“概貌”，开发过程、软件产品、实战测试策略、测试相关文档、测试未来、测试职业等。
有心人，能从此书中找到软件测试世界的入口，找到知识才能的用武之地。
软件开发世界的“入口地图”。
软件行业人员的“新手圣经”，“百科全书”。
经典中的经典，大师中的大师，众多大咖联名点赞。
本书总结、归纳了，软件工程业行之有效的、细节具体的实践知识，让你可以利用前人智慧、避免重蹈覆辙。如，通过“隐喻”理解和表达软件，高质量的编程经验细节，软件质量改进方法，软件集成，软件人员，等等。
几乎每一章，都是描述了软件职业的一个深入方向，每章的“更多资源”，是更多本的深入学习的经典书籍。
此书近1000页，适合先系统化学习，了解全貌，再随时查阅，或深入研究。
PS：如果你想做一个真正的“软件行业”相关人员，此书必读。
地球上目前具创兴软件公司，从测试角度描述的公司成长史。
敏捷软件的实践总结描述。
互联网“软件测试”工程师的工作范围参考。
本书简介了Google的软件测试历史、改进，重点展示了各种测试人员的角色职责(软件测试开发工程师、测试工程师、测试工程经理)，并以Chrome浏览器为例描述了测试计划。让你体会到软件测试在公司发展中的贡献和力量。
有心人，可以从中搜索到中国软件测试人员的发展和未来。
PS：Google在软件的创新上领航地球，gtest，chrome，Android，...
本书全面介绍了进行软件性能测试的实战技术和JMeter的应用知识，本书内容通过：基础篇，部分工具篇，实践篇和提升篇这四部分让读者清楚的了解到性能测试技术方面的内容!
PS：如果你想要往性能测试方面转型，此书必读。
如何阅读一本书
阅读经典书籍，可能是重要的、系统化的有效学习方式之一。
有一个经典问题：你真的会读书吗?
也许你会嗤之以鼻：从小学到大学，我读过的教材、小说、杂志、漫画，没有上万，也定成千;何况现在还有百家讲坛、听书会，...不会读书，哼哼。
如果没看过本书，先别下结论，投资点时间先阅读理解，你的读书投资受益会几何增加的。
本书是一本老古董，版1940年发布。本书提到的阅读的目标、阅读的四个层次、学习类型等概念，指导了一代代的阅读学习有心人。
作者：陌上
节选：公众号：鲁德
【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。
软件开发过程中，为了保障项目的顺利进行，有些时候我们是需要注意许多的工作内容事项的。今天，我们就一起来了解一下，软件开发过程中需要关注哪些问题。
随着互联网的不断发展，越来越多的企业都开始通过内容运营的方式来加深用户对企业的印象，提高认知程度，方便后期的用户留存与转化。
说起小程序相信大家应该都不陌生了吧。经过长时间的推广和使用，现在大多数人都接受了小程序的使用方法。下面我们就一起来了解一下，小程序的入口都有哪些类型的。
对于外行人来说，因为知道seo优化能够提高网站关键词的排名，所以会大量堆砌关键词。今天，我们就一起来了解一下，seo优化中过度优化的行为都有哪些。
Copyright (C)
Tedu.cn All Rights Reserved 京ICP备号-56 达内时代科技集团有限公司 版权所有
选择城市和中心
达内北京亦庄大学生实训基地
达内北京网络营销中心
达内北京会计中心注 : 本文来源：& 《 && 》１.基本概念１.１软件　软件就是可以在计算机上运行的计算机程序，如操作系统Windows、办公软件Office、聊天ＱＱ、手机游戏等。软件和我们的生活和工作之间的联系越来越密切。１.２软件测试　软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件品质，并对其是否能满足设计要求进行评估的过程。　软件测试的现实定义是：软件测试是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，其目的是尽快尽早地发现在软件产品中所存在的各种问题——与用户需求、预先定义的不一致性。１.３测试的方法软件测试一般分为白盒测试和黑盒测试。黑盒测试黑盒测试，软件测试的主要方法之一，也可以称为功能测试、数据驱动测试或基于规格说明的测试。测试应用程序的功能，而不是其内部结构或运作。测试者不需具备应用程序的代码、内部结构和编程语言的专门知识。测试者只需知道什么是系统应该做的事，即当键入一个特定的输入，可得到一定的输出，这是从用户的角度针对软件界面、功能及外部结构进行测试，而不考虑程序内部逻辑结构。测试用例是应用系统应该做的功能，照规范、规格或要求等设计。测试者选择有效输入和无效输入来验证是否正确的输出。此测试方法可适合大部分的软件测试，例如单元测试(unit testing)、集成测试(integration testing)以及系统测试(system testing)。白盒测试白盒测试（又称透明盒测试、结构测试等）是一个测试软件的方法，测试应用程序的内部结构或运作，而不是测试应用程序的功能（即黑盒测试）。在白箱测试时，以编程语言的角度来设计测试案例。测试者输入数据验证数据流在程序中的移动路径，并确定适当的输出，类似测试电路中的节点。白箱测试可以应用于单元测试、集成测试和系统的软件测试流程，可测试在集成过程中每一单元之间的路径，或者主系统跟子系统中的测试。尽管这种测试的方法可以发现许多的错误或问题，它可能无法检测未使用部分的规范。１.４测试的类型功能测试& 按照测试软件的各个功能划分进行有条理的测试，在功能测试部分要保证测试项覆盖所有功能和各种功能条件组合。更详细的描述请参见“黑盒测试”。系统测试& 对一个完整的软件以用户的角度来进行测试，系统测试和功能测试的区别是，系统测试利用的所有测试数据和测试的方法都要模拟成和用户的实际使用环境完全一样，测试的软件也是经过系统集成以后的完整软件系统，而不是在功能测试阶段利用的每个功能模块单独编译后生成的可执行程序。极限值测试&&&&&& 对软件在各种特殊条件，特殊环境下能否正常运行和软件的性能进行测试。特殊条件一般指的是软件规定的最大值，最小值，以及在超过最大，小值条件下的测试。特殊环境一般指的是软件运行的机器处于CPU高负荷，或是网络高负荷状态下的测试，根据软件的不同，特殊环境也有过不同。性能测试& 性能测试是对软件性能的评价。简单的说，软件性能衡量的是软件具有的响应及时度能力。因此，性能测试是采用测试手段对软件的响应及时性进行评价的一种方式。根据软件的不同类型，性能测试的侧重点也不同。压力测试压力测试，确立系统稳定性的一种测试方法，在软件工程、金融风险管理等领域应用比较普遍。通常在系统正常运作范围之外进行，以考察其功能极限和隐患。压力测试与性能测试的区别压力测试常常和性能测试相混淆。它们主要不同点是，压力测试要求进行超过规定性能指标的测试。例如一个网站设计容量是100个人同时点击，压力测试就要是采用120个同时点击的条件测试。１.５测试的阶段单元测试单元测试是对软件组成单元进行测试，其目的是检验软件基本组成单位的正确性，测试的对象是软件设计的最小单位---模块。单元测试一般由开发人员完成。集成测试集成测试又称组装测试，是将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。其主要目的是检查软件单位之间的接口是否正确，集成测试的对象是已经经过单元测试的模块。实践表明，有时模块虽然可以单独工作，但是并不能保证组装起来也可以同时工作。系统测试系统测试主要包括功能测试、界面测试、可靠性测试、易用性测试、性能测试。 功能测试主要针对包括功能可用性、功能实现程度（功能流程&业务流程、数据处理&业务数据处理）方面测试。回归测试回归测试是为了检测代码修改而引入的错误所进行的测试活动。回归测试是软件测试阶段的重要工作，有研究表明，回归测试带来的耗费占软件生命周期的1/3总费用以上。与普通的测试不同，在回归测试过程开始的时候，测试者有一个完整的测试用例集可供使用，因此，如何根据代码的修改情况对已有测试用例集进行有效的复用是回归测试研究的重要方向，此外，回归测试的研究方向还涉及自动化工具，面向对象回归测试，测试用例优先级，回归测试用例补充生成等。Alpha测试α测试通常是阶段性的开发完成后所开始进行，一直持续到进入Beta测试阶段前的阶段。α测试是一种验证测试，在模拟的环境中以模拟的数据来运行。在这个阶段中，通常是在开发单位由开发人员与测试的测试人员，以模拟或实际操作性的方式进行验证测试。Beta测试在系统测试中通常先进行α测试以验证信息系统符合用户以及设计需求所期望的功能。当α阶段完成后，开发过程进入到β阶段；由公众参与的测试的阶段。β测试可称为确认测试，在一个真实的环境中以实际的数据来运行测试，以确认性能、系统运行有效率，系统撤消与备份作业正常，通过测试让信息系统日后可以Beta测试和黑盒测试的区别对Alpha和Beta测试常见的一个认识误区是“Beta测试＝黑盒测试”。实际上，Alpha和Beta测试对应在软件产品发布之前的Alpha和Beta阶段，而白盒、黑盒和灰盒测试技术是从技术和方法层面对测试的描述，不应该将这两部分概念混淆。验收测试验收测试是系统部署到用户环境后，用户运行系统，考察系统是否满足用户需求的过程。验收测试是用户主导的，用户可能聘请专家帮助验收测试。１.６软件测试的作用1.对产品质量完成全面的评估，为软件产品发布（如验收测试）、软件系统部署（如性能规划测试）、软件产品鉴定（第三方独立测试）委托方和被委托方纠纷仲裁（第三方独立测试）和其它决策提供信息；2.通过持续的测试（包括需求评审、设计评审、代码评审等）可以对产品质量提供持续的、快速的反馈，从而在整个开发过程中不断地、及时地改进产品的质量，并减少各种返工，降低软件开发的成本；3.通过测试发现所要交付产品的缺陷，特别是尽可能地发现各种严重的缺陷，降低或消除产品质量风险，提高客户的满意度，扩大市场份额，提高客户的忠诚度。4.通过对缺陷进行分析，找出缺陷发生的根本原因（软件过程中的问题，包括错误的行为方式）或总结出软件产品的缺陷模式，避免将来犯同样的错误或产生类似的产品问题，达到缺陷预防的目的２.初级软件测试工程师主要工作２.１编写功能测试用例１）测试用例设计步骤& 设计测试案例的时候，需要有清晰的测试思路，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。测试用例设计一般包括以下几个步骤：1、测试需求分析　　从软件需求文档中，找出待测试软件/模块的需求，通过自己的分析、理解，整理成为测试需求，清楚被测试对象具有哪些功能。测试需求的特点是：包含软件需求，具有可测试性。　　测试需求应该在软件需求基础上进行归纳、分类或细分，方便测试用例设计。测试用例中的测试集与测试需求的关系是多对一的关系，即一个或多个测试用例集对应一个测试需求。2、业务流程分析　　软件测试，不单纯是基于功能的黑盒测试，还需要对软件的内部处理逻辑进行测试。为了不遗漏测试点，需要清楚的了解软件产品的业务流程。建议在做复杂的测试用例设计前，先画出软件的业务流程。如果设计文档中已经有业务流程设计，可以从测试角度对现有流程进行补充。如果无法从设计中得到业务流程，测试工程师应通过阅读设计文档，与开发人员交流，最终画出业务流程图。业务流程图可以帮助理解软件的处理逻辑和数据流向，从而指导测试用例的设计。从业务流程上，应得到以下信息：A、 主流程是什么B、 条件备选流程是什么C、 数据流向是什么D、 关键的判断条件是什么3、测试用例设计　　完成了测试需求分析和软件流程分析后，开始着手设计测试用例。测试用例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等。在用例设计中，除了功能测试用例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。黑盒测试的测试用例设计方法有：等价类划分、边界值划分、因果图分析和错误猜测，白盒测试的测试用例设计方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。在这里主要讨论黑盒测试。在设计测试用例的时候可以使用软件测试用例设计方法，结合前面的需求分析和软件流程分析进行设计：功能测试：测试某个功能是否满足需求的定义，功能是否正确，完备。适合的技术：由业务需求和设计说明导出的功能测试、等价类划分边界测试：对某个功能的边界情况进行测试。&&&&&&&&& 适合的技术：边界值划分异常测试：对某些功能来说，其边界情况无法简单的了解或某些操作不完全是正确的但又是可能发生的，类似这样的情况需要书写相关的异常测试。&&&&&&&&& 适合的技术：由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值分析、内部边界值测试、性能测试：检查系统是否满足在需求中所规定达到的性能，性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置，系统资源使用状况；外部因素包括响应时间，吞吐量等。&&&&&&&& 适合的技术：业务需求和设计说明导出的测试压力测试：压力测试又称强度测试，主要是检查系统运行环境在极限情况下软件运行的能力，比如说给一个相当大的负荷或网络流量给应用软件兼容测试：测试软件产品在不同的平台，不同的工具，相同工具的不同版本下功能的兼容性。4、测试用例评审测试用例设计完成后，为了确认测试过程和方法是否正确，是否有遗漏的测试点，需要进行测试用例的评审。测试用例评审一般是由测试leader安排，参加的人员包括：测试用例设计者、测试leader、项目经理、开发工程师、其它相关开发测试工程师。测试用例评审完毕，测试工程师根据评审结果，对测试用例进行修改，并记录修改日志。5、测试用例更新完善测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。测试用例是“活”的，在软件的生命周期中不断更新与完善。２）测试用例设计方法黑盒测试的测试用例设计方法有：等价类划分、边界值划分、因果图分析和错误猜测，白盒测试的测试用例设计方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。在这里，主要讨论的是黑盒测试的测试用例的设计方法。一、等价类划分等价列划分设计方法是把所有可能的输入数据划分成若干部分（子集），然后从每一个子集中选取少量具有代表性的数据作为测试用例，测试某等价类的代表值就等于对这一类其他值的测试。使用等价类划分方法设计测试用例主要有两个步骤：（1）确定等价类；（2）生成测试用例。1、划分等价类等价类划分有两种不同的情况：有效等价类代表对程序的有效输入和无效等价类代表不正确的输入值，设计时要同时考虑这两种等价类。下面是确定等价类的原则：（1）在输入条件规定了取值范围的情况下，则可以确立一个有效等价类（在取值范围之内）和两个无效等价类（小于取值范围和大于取值范围）。 例如：使用手机发送短信的时候，短信内容长度必须在70个字符之内，则有效等价类：短信内容长度在70个字符之内，无效等价类：短信内容长度为0、短信内容长度大于70。（2）在输入条件规定了取值的个数的情况下，则可以确立一个有效等价类（在取值个数范围之内）和两个无效等价类（小于取值个数和大于取值个数）。例如：一名学生一个学期可以选修一至五门课程，则有效等价类为：1&=学生选修课程&=5，无效等价类为：没有选修课程、选修课程大于5（3）在输入条件规定了输入值的集合的情况下，则可以确立一个有效等价类和一个无效等价类。 比如：发送短信的编码的取值范围是0、3、4、8、15或16，则有效等价类是：短信编码为0或3或4或8或15或16，无效等价类是：短信编码不是0或3或4或8或15或16其中任何一种。（4）在输入条件规定了 “必须如何”的条件的情况下，则可以确立一个有效等价类和一个无效等价类。 例如：变量的命名比如以大写字母开头，则有效等价类为：变量命名以大写字母开头，无效等价类为：变量开头非答写字母开头。（5）在输入条件是一个布尔量的情况下，可以确立一个有效等价类和一个无效等价类。 例如：在神州行手机号码预扣费成功的情况下，允许该用户发送短信，则有效等价类为：神州行预扣费成功，无效等价类为神州行预扣费失败。（6）在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可以确立n个有效等价类和一个无效等价类。（7）在规定了输入数据必须遵守的规则的情况下，可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。（8） 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。2、生成测试用例在确立了等价类后，可建立等价类表，列出所有划分出的等价类，过程为：（1）为每一个等价类规定一个唯一的编号。（2）设计一个新的测试用例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止。（3）设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。二、边界值分析法边界条件指的是输入和输入等价类中刚好处于边界、或超过边界或小于边界的状态，使用边界值分析方法设计测试用例应先确定边界情况，然后选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。基于边界值分析方法选择测试用例的原则：（1）如果输入条件规定了值的范围，则应取刚达到这个范围的边界值设计有效测试用例，以及刚刚超过这个范围的边界值作设计无效测试用例。比如：短信内容的有效长度为70个汉字以内，则有效测试用例：短信内容长度为1，短信内容长度为70个汉字，无效测试用例：短信内容长度为0，短信内容长度为71个汉字。（2）如果输入条件规定了值的数量，则应取最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试输入的数据。 例如：短信的有效编码为1~255，则应取0、1、255、256设计边界值测试用例。（3）根据规格说明的每个输出条件，使用前面的原则1。（4）根据规格说明的每个输出条件，使用前面的原则2。（5）如果程序的输入或输出是一个有序集合，则应选取集合的第一个元素和最后一个元素设计测试用例。（6）如果程序中使用了一个内部数据结构，应当选择这个内部数据结构边界上的值设计测试用例。（7）分析规格说明书，找出其他可能的边界条件。三、因果图法因果图法是一种适合于描述对于多种条件的组合、相应产生多个动作的形式的测试用例设计方法。利用因果图生成测试用例的步骤为：（1）将规范说明书分解成可执行的片段。（2）确定规格说明书中的因果关系。分析软件规格说明描述中那些是原因，那些是结果，并给每个原因和结果赋予一个标识符。（3）分析软件规格说明描述的语义，找出原因和结果之间、原因和原因之间的关系，并将其转换成因果图。（4）在因果图上加上注解符号，用一些记号表明约束或限制条件。（5）跟踪图中的状态变化情况，把因果图转换为判定表。（6）把判定表的每一列拿出来作为依据，设计测试用例。四、错误推测法错误推测法就是根据经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。错误推测法的基本思路是列举出程序中所有可能有的错误和容易发生错误的清单，根据清单设计测试用例；另一个思路就是在阅读规格说明时有哪些容易被程序员忽略的内容来设计测试用例。错误推测法是一种非常有效的测试用例设计方法，这要求测试人员有丰富的测试经验和对业务的处理非常熟悉。比如，在短信发送的时候，如果发送短信之后，对方网关没有响应或者超时响应或者没有回复状态报告，那程序怎样处理呢？进阶参考：测试用例设计　　如何编写有效测试用例２.２执行功能测试　　根据测试计划和测试用例进行测试，在测试过程中记录测试结果和提交发现的Bug。下班前将当天的测试情况汇报给测试组长或测试经理。２.３提交Bug２.２.１Bug基本概念１）BUG的定义BUG：(小错误，缺陷，不足，过失 …) 一个计算机bug指在计算机程序中存在的一个错误（error）、缺陷（flaw）、疏忽（mistake）或者故障（fault），这些bug使程序无法正确的运行。Bug产生于程序的源代码或者程序设计阶段的疏忽或者错误。Defect：(缺陷) 在软件工程（Software Engineering）中，软件与它的需求（requirements）不一致，常常指软件无法正确完成需求所要求的功能，也称之为bug。２）BUG分级－严重性我们一般把发现的错误(Bug)/缺陷(Defect)按严重性分为4类：1.严重：系统崩溃或挂起等导致系统不能继续运行；2.主要：使系统不稳定、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的主要问题；3.次要：系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题，如：显示不正确但输出正确；4.轻微：界面拼写错误或用户使用不方便等小问题或需要完善的问题；３）BUG分级－优先级我们也把发现的错误按优先级分为三种：1.高：立即修改；2.中：必须修改，但不一定马上修改；3.低：允许不修改；一般来说是越影响用户接受或使用该产品的错误优先级越高。２.２.２怎样提交Bug首先，确保你所发现的问题是确实是一个bug，不要出现因为测试人员操作错误或配置错误所引起的“bug”，这样会降低你在开发人员心中的可信度。在测试的时候，如果发现测试的实际结果与预期测试结果不符时，不要着急马上报bug，先想想为什么会出现错误。作为专业的测试人员，应该能够对出现的问题进行跟踪，确认了在配置、操作没有错误的前提下，通过追踪分析确认所测试的业务流程确实是存在bug，并能大概对bug的产生原因进行定位。测试人员，需要做到专业，尽量少给开发找麻烦，不要制造实际上并不存在的bug。确认了所发现的问题是一个bug之后，按照测试步骤再执行一次，确保bug是可重现的而不是随机的。如果bug不能重现，应该尽量找到bug重现的规律，在一些比较难重现的问题可以找开发配合一起查找原因，如果还是无法重现则需要在bug report中对出现的问题描述清楚并说明出现的随机性。接下来就是填写bug report了，在填写bug report的时候，最重要的是bug的标题和bug描述。在bug报告中，首先用一句话对bug进行简要精确的描述作为bug的标题，让开发或项目经理一看就知道存在什么问题，比如“XX模块在压力测试2小时后出现内存泄露”。而在bug的描述中，需要使用简明准确的语言描写出现bug的测试步骤、实际的测试结果、预期的测试结果和结论；也就是说描述导致出现bug的操作步骤是怎样，由测试步骤所做的操作引起的测试结果是什么，而预期的结果应该是怎样，并由实际结果与预期结果相对比说明问题所在。比如：“在管理网页新增用户，当新增的用户登录名名称很长（例如登录名长度为输入框允许的最大长度），按‘新增’按纽新增后系统提示已经有该用户存在，而事实上该用户并不存在，建议对超长的用户名进行处理。”在测试人员发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的流程？同一个故障是否会引起更加严重的问题？如果存在，也需要提出来让开发一并处理。在开发对bug进行修改之后，测试需要报着怀疑的态度认真地对问题进行验证，需要严格按照测试步骤来进行测试，检查开发是否已经正确修改了所出现的问题，以及开发对bug进行了修复之后是否会引进新的问题。不要相信开发说“已经修改好了，肯定没问题了”就不对问题进行细致的检查了，如果开发修改得不彻底，问题仍然会存在的，或者可能会由于开发在修改bug的时候忽略了另一些细节导致了新bug的出现。尽量不要在关闭bug之后，才发现这个问题还没有修改彻底；也不要出现bug关闭之后，出现了新的bug。测试对bug进行验证确认已经修改ok之后，关闭bug。在关闭的时候，应该对Bug最终修改结果进行简要描述，如果bug的修改引起配置或数据库或业务流程的变更，也需要在bug关闭描述中进行说明。进阶参考：如何编写有效bug报告　准确报告软件缺陷２.３编写功能测试报告测试报告是测试人员在测试过程中用于反映测试状况的文档。其实测试报告的内容基本都是模板的那些，只是在实际测试过程中，如何去整理内容结构，使得报告的通常阅读者：开发人员、测试经理、产品经理、项目负责人能够一目了然地查看想要了解的内容才是测试报告最值得注意的地方。产品要想有广阔的市场，得需要切实了解用户的需求及感受，同理测试报告要想能够让阅读者能够满意，也需要能将质量情况条理性地列出。通常来说，开发人员往往希望能从报告中了解缺陷的情况，而测试经理还关心用例的执行情况及覆盖率、项目责任人则最关心还有多少问题，此次版本是否测试通过。因此测试报告根据内容的侧重点，分为『版本测试报告』和『总结测试报告』，目的也是希望不将所有内容列举在一个报告中，造成内容臃肿繁杂。总体来说，功能测试报告的编写就是要做到简约而不简单。版本测试报告ü& 主要反映开发人员提交的测试版本的质量状况。ü& 测试用例设计与执行、缺陷概况及问题概要是版本测试报告中的主要内容。ü& 测试人员在每个轮次测试结束时编写提交。其内容结构和每个章节的编写内容说明如下： 大纲子章节详细内容测试简介测试目的本次测试的背景及主要内容测试资源测试人员、本次测试开始和截止日期、花费工作日测试环境硬件环境实际情况的详细列举，过低的配置、软件版本的不匹配、网络拓扑的错误都会让提交的缺陷缺乏说服力，也会让开发人员对于某些缺陷是否由于环境因素导致而产生疑惑。软件版本网络拓扑图测试方法无本次测试的功能点、各功能点对应的测试用例设计、测试用到的测试工具测试用例用例分析测试用例维护记录用例执行情况用例执行总数、通过用例数、未通过用例数、阻塞用例数测试执行率=（已执行的用例数）/用例总数测试用例效率=发现的缺陷总数/测试用例的数量测试过程缺陷统计新建bug数、修复bug数、未修复bug数、bug总数问题摘要遗留问题、拒绝问题、挂起问题、长期验证问题、待评估问题测试结果资源占用测试项目的启动、退出时间测试项目的CPU占用率初始值、峰值（如果项目启动会有多个进程，则分多个进程进行统计）测试项目的内存占用初始值、峰值测试结论测试结论不论仅仅只是测试通过或不通过，应该使用详细的数据来支持测试结论，需要列举的数据有:『测试用例通过率』总用例未通过用例未通过比率『遗留bug情况』总bug数未修复bug遗留bug率备注用例执行记录插入测试用例的详细执行结果文档资源监控记录说明资源占用监控的场景，详细列举各场景的监控时长、监控内容，场景操作总结测试报告ü& 主要偏重于各已测试版本的缺陷变化分析，风险预估。 ü& 各测试版本质量情况概况统计、缺陷分布统计、风险分析是总结测试报告中的主要内容。 ü& 测试人员在项目发布上线前编写提交。其内容结构和每个章节的编写内容进行说明如下： 标题子章节详细内容测试简介测试目的本次测试的背景及主要内容测试资源测试人员、第一轮测试的开始日期和最后一轮测试的截止日期、总共花费工作日统计测试环境硬件环境实际情况的详细列举，过低的配置、软件版本的不匹配、网络拓扑的错误都会让提交的缺陷缺乏说服力，也会让开发人员对于某些缺陷是否由于环境因素导致而产生疑惑。软件版本网络拓扑图测试过程各版本测试状况各测试版本的计划提交日期、实际提交日期、测试类型（回归或全量）、测试耗时、备注（被打回或提交补丁次数）各版本bug统计各测试版本的新建bug数、修复bug数、遗留bug数，表格统计、线形图或饼状图辅助表示测试分析缺陷分析缺陷的总体分布情况，以线形图或饼状图辅助表示?& 根据功能模块进行划分?& 根据严重、较严重、普通、轻微级别进行划分遗留问题打开状态bug、长期验证bug、用户体验问题测试小结资源占用测试项目的启动、退出时间测试项目的CPU占用率初始值、峰值（如果项目启动会有多个进程，则分多个进程进行统计）测试项目的内存占用初始值、峰值风险分析测试进度、人员安排导致的风险测试内容考虑范围之外导致的风险测试环境不全面导致的风险其他因素导致的风险进阶参考：软件测试阶段报告编写指南http://blog.csdn.net/smilings/article/details/1032221软件测试报告编写指南http://blog.csdn.net/smilings/article/details/1032246３.测试牛人Randall W.Rice给测试新手的话前言因为已经带领和训练测试团队多年，所以按惯例我总有些东西确定需要传达给测试新手。不管你是一个测试新手还是一个经验丰富的测试专家，都有不少有益的东西需要牢记在心。1、你是一个检查者，你不需要为质量负责很多测试人员误入歧途，不明白他们是评测产品的而不是控制产品的。这两者之间有着天壤之别。例如，一个测试团队花费好几周时间测试并发现很多缺陷，只是为了看着管理层决定发布一个有已知严重缺陷的产品。测试团队经常会感到士气受挫，置疑他们测试的目的。我询问团队中的成员他们是否被支付薪水了，通常得到的回答都是“是”。我又询问他们是否尽力去做工作了，再一次，通常得到的回答都是“是”。我于是告诉他们，“你们做了你们的工作。你们尽力测试，发现了缺陷并进行了上报。那么现在可以回家休息了。实际上，作为一名测试人员唯一失败的地方是不上报一个已知的缺陷。”这不会提高士气，但却有助于事情向正确的方向发展，特别是能让人不用每天晚上都在家接着办公。很多测试人员，包括我，当我们刚开始测试工作时，似乎会觉得自己对我们所测试的系统应用的质量负责。尽管这个工作的出发点是让人钦佩的，可实际上我们测试人员对于产品的质量基本没有控制能力。也是由于这个原因，测试人员不为质量负责。现在问题是管理层并不总是能看到这种区别。所以经常看见管理层提出类似于“我们付钱给这些人不是为了获得高质量的软件吗？”的问题。2、缺陷都是有价值的每一个缺陷都是深入了解和提高的机会。我们可能只有一次机会观察到一个缺陷，所以我总是告诉测试人员始终保持高度注意力，不要为测试的乏味所折磨。缺陷信息可能是可获取的项目数据中最有效的资源之一。但是这都取决于我们能多好的捕捉和传达我们所发现的缺陷的相关信息。每个缺陷都会花费整个组织的金钱。如果我们不能从中更进一步了解产品，我们会浪费大量时间和金钱。当我们把一个错误转换成一次深入了解的机会时杠杆作用就出现了。让我们面对它――有些教训只能通过经历来学习的。由于一个缺陷而责备谁不会有任何好的作用。责备只会让士气低落、沟通中断。这就像不断鞭打一匹死马希望它能活过来一样。3、你报告第一个问题之前一切都是美好的这就是一个测试人员所面对的现实。你可以计划测试，获取所需要的资源，看起来所有人都站在你这边。可当你报告第一个问题之后，事情就开始变得紧张了。出现这种态度上的突然变化的原因是现在你在批评某些人的工作了。自尊心使得自我收到伤害，关系变得紧张。有些情况下自尊心是值得期盼的，只要知道当你开始发现问题的时候态度有可能变化就可以了。我经常建议测试人员做的一件事是读一读一些你过去写的缺陷报告，假设自己是接收缺陷报告的人。你会发现自己需要更老练一些。写一个没有任何挖苦语句的缺陷报告可能没什么乐趣，但它的确有助于和开发人员之间保持一个好的关系。4、只能测试你能观察的你可能总想测试一些真正有创造性的用例，但如果你没有办法观察到结果，那有什么意义？尽管有些应用让你能观察到很多，但仍然有你没办法接近的，例如结构、隐藏的对象、后台进程等。5、别忘记你是怎样到一个地方的我不是在谈论知道为什么你走进一个房间，而是在测试时执行的步骤。对于测试新手常见的是发现了一个重大的缺陷，但却无法复现它以便定位解决。这样你只会觉得不舒服，不知道自己到底是真发现了一个缺陷，还是说仅仅是错误的使用了应用。你能用来跟踪你的测试步骤的方法有测试脚本、测试记录、敲键记录器如Spector和屏幕视频捕捉工具如Hypercam。6、标准和流程是你的朋友尽管标准和流程让一些人觉得受限，但它们为你的工作提供了有价值的指导。不要拒绝标准因为它们是详细的、具体的。因此用它们指导自己更快、更一致的完成自己的工作。7、没有足够的时间用于测试几乎每一个测试人员都抱怨没有足够的时间用于测试，但实际情况是测试任何东西到完整的程度都是不可能有充足时间的。当你充分考虑软件的特性如可用性、安全性、兼容性、互操作性等时这一点尤其正确。不要再抱怨缺少时间，学会根据风险来进行优先级排序，把注意力都放在对管理层很重要的应用目标上。有时候我们测试的内容超出了我们需要测试的，因为我们的目标偏离了产品的价值。8、你不可能发现所有的缺陷如果你测试的东西后来有缺陷被发现，不要变得气馁。你可能已经做了非常全面的工作，获得了高水平的缺陷移除，但100%都是不可能的目标。9、保持幽默感和对前景充满信心经常微笑、保持健康可能是你最好的生存方式。如果你正处在困难条件下，请相信，这一切都将过去。10、争取做到最好而不是完美测试新手经常会陷入追求完美的过程中，认为100%的正确才是标准。我曾经也是受害者之一，但要为自己辩护的是，我以前深受80年代后期类似于“99.9%还不够好”的TQM帖子和文章的影响。追求完美的问题在于它会让测试进程变慢，将担心引入你所做的一切，使得你对别人更挑剔，而且通常会让你的朋友和家人感到失望。当然，没人愿意犯错误，但他们稍不注意就出现了。想不犯错误就是否认现实。争取做到最好是一种好的习惯，表明你对工作的态度和投入程度。如果你想努力做到最好，你就会往前再多走一点。根据我的观察，大多数人看到错误或者经历失误时都是很宽容的。人们最关心的是你对待问题的反应。11、开发人员不是敌人需要整个项目团队的努力才能递交高质量的产品。有时候似乎开发人员不太关心质量，这个时候事情背后可能存在隐情。这时候你需要更好的和开发人员合作而不是反对他们。要始终牢记良好的交流是一个项目成功的关键因素。当你和开发人员站到对立面时，交流就停止了，你测试所需的很多信息也无法获取了。12、建立和维护一个私人的交际网你的私人工作关系是一个很重要的资产。无论时当你有工作时还是当你没工作时他们都是一个很好的支持系统。找一个好的指导者，而当你学到足够的东西时成为别人的指导者。13、持续锻炼自己的技能你的技能把你和别人区分开。始终通过参加专业会议、获取认证、阅读专业资料等来不断学习。我给自己制定的目标是每周至少读一本和个人发展以及职业发展相关的书（测试、领导艺术、商业、IT等）。一个个人发展方面的专家说过如果你每天在任何特定的主题上花费30分钟进行阅读，五年之内你肯定能成为这个主题方面的专家。这一点对我是起作用的――你也可以试试。另一种让自己始终内行并建立网络的好的方式是活跃在一些QA或者测试论坛上。14、当前进变得困难，懒惰就需要创造力了当我第一次成为一个测试团队负责人时，我用这句话做了一个字条挂在我的桌上。它不断提醒我把创造力作为我解决问题的一个杠杆。学着从一个新的有创造性的方式来看待问题。你可能有一个好的测试计划，但你如何应付各种变化呢？弹性是一个优秀的问题解决负责人的关键特性。15、简单并不总是很容易我们测试中做的很多工作看起来都很简单。但是，挑战在于保持努力的连贯性。有些解决问题的方式刚开始看起来很简单，但不要由于它简单和明显就丢弃任何一种想法。同样，不要低估实现一个简单想法所需要付出的努力。一些看过我和William E.Perry合著的书“Surviving the Top Ten Challenges of Software Testing”评论说这些挑战都很简单且很容易解决。这就让我奇怪为什么人们还在年复一年的提出“人的问题”。我认为在大脑中产生想法比实际实现出来要简单的多。结论智慧比知识更重要。你可能已经学习了大量测试技术，但如果你没有足够的智慧判断什么时候采用它们，没有从整体上理解它们，你应用它们的能力将受到很大限制。对任何都有涉猎的你存在的一个问题是“你不知道什么你不知道”。智慧帮助你明白你需要知道哪些东西才能成功。４.软件测试工作求职４.１测试人员面试时常见问题及问题背后的考核内容分析1）你最近3-5年的职业规划是什么？&& 重点考察测试人员的职业发展方向是否与当前职位招聘相符? 从其中可以侧面看出来其员工稳定性。2）一个项目测试结束，有没什么经验总结？如果有，具体是如何开展的？&& 重点考察测试人员对自己能力提升方面，有没有提高总结的地方，从项目中吸取的经验与教训。从中可以看出来，测试人员是否属行自我驱动型人才！3）为什么会选择做测试这份工作？&& 重点考察测试人员对待测试工作的态度及是否有发展潜力？面试过很多测试人员，经常见到的回答，自己是女孩子，做测试细心，各位你认为这样回答你会满意吗？其码不是我想要的答案！4）请说出一个你以前参与项目，对你测试经验提升很高的，具体是哪方面？&& 重点考察测试人员在以往的测试工作中能力提升方面，有哪些？然后重点询问此部分内容，是否测试经验增长，具备一定的深度？5）通常做测试时会碰到，提交的某个bug开发人员不认同你的观点？这时你如何办？&& 重点考察测试人员是否坚持自已的价值观？是否具备协调沟通处理问题能力？6）有没有看过什么测试书，具体是哪本？带给你的收获是？& 重点考察测试人员是否为测试这个职业肯付出多少？从中也可以看出这个测试人员是否上进心？是否有求知心？我的定义是如果哪个应聘者来面试时，都没系统的看过一本测试书籍，基本上不会录取！7）如果安排一项测试技术研究工作，你如何应对？重点考察测试人员是否具体测试技术专研精神？是否喜欢接受挑战？是否属于以后培养骨干对象？8）某个项目上线后，出现问题，恰巧你是负责的，你如何应对这突如其来的事件？重点考察测试人员应对问题的压力，责任感，及如何处理项目上线后的技术问题及应对解决能力。9）周末放假有什么业余爱好？&& 重点考察面试测试人员性格特质，测试工作本身就是复杂且富有技术性的工作，而且不同的职位所需要的测试人员性格品质差异性很大。10）公司产品，具体应用什么编程技术？具体的架构是？具体的应用场景有哪些？&& 重点考察测试人员对以往的工作所负责的产品测试，是否具备一定的深度！通常我都是让面试者自己讲述或是在纸上画出具体系统架构的图！11）公司测试团队的规模如何，具体你所处的角色是什么？&& 重点考察测试人员在以往的公司测试团队中，具体的工作职责，评判其工作是否与当要求职位是否符合？是否有哪些优缺点？12）特定测试技术考察：性能测试，安全性测试，自动化测试等以前有开展过没？如果有，具体是如何实施的？&& 重点考察测试人员技术能力，是否在各方面都有所涉及？或是在各方面技术上都有一定深度？当然从中也能看出一个测试人员是否属于是技术路线发展方向！13）你自己所期待加入的测试团队是什么样的？&& 重点考察测试人员在以前测试团队中有哪些不协调？当然最重要的是也能提供给你一些信息，这个员工以后如何更好的管理与沟通！５.软件测试职业发展1）技术方向&&& 在技术方向上面，通常是初级测试工程师，中级测试工程师，高级测试工程师，资深测试工程师，专家等方向发展；当然像国外技术分工比较细如：通常有白盒测试，黑盒测试，自动化测试，性能测试，安全测试，易用性测试等。
2）管理方向&&& 在管理方向上面，通常是测试组长，测试主管，测试经理，测试总监等方向发展。
3）业务领域方向&&& 在业务领域则取决于各测试人员所处行业，通常像金融，银行，证券，ERP类的，通常有初级业务测试，中级业务测试，高级业务测试等。 ４）其他方向配置管理、质量保证（QA）等６.优秀的测试网站和个人博客６.１优秀测试个人博客（排名不分先后）软件工程专栏测试.质量.管理之最佳实践卖烧烤的鱼测试博客Smilings（永恒的旋律）--Enjoying testingJackei 的测试生活与人文社会读本OscarXie.net６.２优秀测试网站（排名不分先后）中国测试平台网TestAge 中国软件测试时代51Testing软件测试论坛７.参考资料维基百科-软件测试软件工程专栏测试.质量.管理之最佳实践Smilings（永恒的旋律）--Enjoying testing卖烧烤的鱼测试博客寻觅2010-功能测试报告的编写
阅读(...) 评论()}