1、软件测试简介第1页，共38页。第十二章 软件测试简介软件测试基本概念软件测试分类自动化测试常见测试工具BUG管理流程第2页，共38页。软件测试的定义：使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度(Correctness)、完全度(Completeness)和质量(Quality)的软件过程；软件测试是为了发现程序中的错误而执行的过程。定义第3页，共38页。软件测试历史1947年，测试等同于调试1957年，测试是为了表明程序正确而进行的1972年，
2、测试是为发现错误而至此能够的一个程序或者系统的过程2019年，提出测试能力成熟度TCMM(Testing Capability Maturity Model)，测试支持度TSM（Testability Support Model)，测试成熟度TMM（Testing Maturity Model)，测试工具流行。2019年，测试是为了度量和提高被测软件的质量，对测试件进行工程设计、实施和维护的整个生命周期过程。第4页，共38页。软件测试著名失败案例狮子王案例：缺乏配置测试Intel浮点除法软件缺陷美国航天局火星登陆爱国者导弹防御系统第5页，共38页。软件缺陷软件未达到产品说明书（简称，SPEC）
3、标明的功能；软件出现了产品说明书指明不会出现的错误；软件功能超出产品说明书指明范围；软件未达到产品说明书虽未指出但应达到的目标，此条的目的是抓住产品说明书上遗漏之处；软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。第6页，共38页。软件模型或者说业务建模制定不正确，更直观的理解是，SEPC本身不明确或有错误，没有能很好的描述要开发的软件，这类原因占了70%左右，并且很难于纠正；软件庞大，功能十分复杂；编程过程出错，此类原因导致的错误大概占20%，一般来说比较容易纠正；个别功能要求改变而影响到其他部分；与要开产的软件对接的第三方软件有缺陷；人为因素，常见的因素包括：项目
4、组管理方法、项目进度要求时间紧、项目组配备人力不足、组内及组外沟通不充分等几种情况。产生软件缺陷的原因第7页，共38页。纠错阶段纠错阶段单位费用单位费用1功能需求搜集分析/软件设计阶段1单位费用2编程或分块测试阶段5单位费用3整体或系统测试阶段10单位费用4早期用户试用或Beta测试阶段15单位费用5软件推出市场后30单位费用发现阶段修正花费对照表第8页，共38页。软件测试的原则为了能够更好的进行软件测试，提高测试的整体效率，降低项目的整体成本，我们在执行软件测试过程中可以参照以下几点原则：1、完全测试程序是不可能的，不可能找出软件的所有缺陷，这是因为：输入量太大输出结果太多软件实现途径太多软
5、件说明书没有客观标准，从不同的角度来看，软件缺陷的标准不同。第9页，共38页。2、软件测试是有风险的行为，如果决定不去测试所有的情况，那就是选择了风险。软件测试人员要学会的一个主要原则是如何把无边无际的可能减少到可以控制的范围，以及如何针对风险制订作出明智抉择，去粗存精。3、测试无法显示潜伏的软件缺陷，软件测试工作与防疫员的工作极为相似，可以报告已发现的软件缺陷，却无法报告潜伏的软件缺陷，更不可能保证找到全部的缺陷。4、找到的软件缺陷越多，就说明软件缺陷越多。生活中的寄生虫和软件缺陷几乎完全一样，两者都成群出现。发现一个附近就会有一群。软件测试的原则（续）第10页，共38页。5、杀虫剂怪事，与
6、农药杀虫是一样的，软件对测试方法及技术也有免疫力，只有发明新的杀虫剂（测试技术或方法）去找虫子。6、并非所有软件缺陷都能修复。7、难以说清的软件缺陷，因为开发小组使用的最佳工作方式千差万别，大家对缺陷的理解也不一致。8、产品说明书不断变化，整个行业变化太快，同时软件变得更庞大、更复杂，功能越来越多，这些都会导致用户描述和定义软件的产品说明书一变再变。9、软件测试员在小组中不受欢迎，软件测试员的任务是检查和批评同事的工作，挑毛病，公布发现的问题。10、软件测试是一项讲究条理的技术专业，当前软件行业已经发展到强制使用专业软件测试员的阶段了，因为生产低劣软件的代价太高。软件测试的原则（续）第11页，
7、共38页。软件常见的版本在整个软件开发的生命周期中，可能会出现各种版，每个公司对版本的定义也不一样，通常情况下有以下的几个版本是比较通用的：1、Alpha版公司内部测试的版本，该版本的特征为：软件的所有功能已基本实现所有的功能已通过测试，一般情况下推向市场前不再增减（一般为集成测试）已到的缺陷中，严重级别的已修正并通过复测软件性能测试可提供基本数据第12页，共38页。2、Beta版对外发布公测，该版本的特征为：次严重缺陷基本完成修正并通过复测完成测试计划中的每一项具体测试（一般为系统测试计划）一段时间内缺陷的发现离低于修正率所有相关文件（用户指南、软件说明、版本说明等）得到最后修正3、发布版正
8、式发布版本，该版本的特征为：缺陷发现率低于修正率，此距离逐渐拉开并一直保持稳定的一段时间测试部门对所有已修正的缺陷重新测试并通过技术支持部门对产品的提出认为可行所有用户反馈都已妥善处理所有文件准备就绪得到测试部门认可软件常见的版本（续）第13页，共38页。优秀软件测试员必备想成为一名优秀的软件测试员，可以从以下几方面去努力：1、探索精神，软件测试员不会害怕进入陌生环境。2、故障排除能手，软件测试员善于发现问题的症结，喜欢猜谜。3、不懈努力，软件测试员总是不停尝试。4、创造性想出富有创意甚至超常的手段来寻找软件缺陷。5、追求完美，他们力求完美，但是知道某些无法企及时，不去苛求，而是尽力接近目标。
9、6、判断准确，软件测试员要决定测试内容、测试时间，以及看到的问题是否算作真正的缺陷。7、老练稳重，软件测试员不害怕坏消息，必须告诉程序员，你的孩子很丑，知道和不够冷静的程序员怎样合作。8、表达能力，软件测试员要善于表达观点，表明软件缺陷为何必须修复，并通过实际演示力陈观点。9、在编程方面受过教育。第14页，共38页。第十二章 软件测试简介软件测试基本概念软件测试分类自动化测试常见测试工具BUG管理流程第15页，共38页。软件测试分类按软件测试特性可以把软件测试分为白盒测试、灰盒测试和黑盒测试三种，其特征及包含的内容如下：、白盒测试测试人员直接在软件的源程序上进行测试、修改、复测。要求测试工程师
10、对软件的内部结构及逻辑有深入的了解，并掌握写成该源程序的语言。分为：语句测试；分支测试；路径测试；条件测试；目测、灰盒测试介于白、黑两者之间，是两者的结合。测试工程师对软件程序结构有一定了解，但了解的程度又不需要达到白盒测试的深度。、黑盒测试测试人员不必深入了解软件的内部设计，只是从一个终端用户的角度，根据产品说明书的指标，从外部测试软件的各项功能及性能。黑盒测试主要是功能测试。第16页，共38页。按软件开发过程可以把软件测试分为单元测试、集成测试、系统测试、用户验收测试以及回归测试。此分类一般可以使用V模型来表示，如下图所示：软件测试分类（续）第17页，共38页。各类测试用时表按开发过程分类
11、测试用时第18页，共38页。按软件测试要求可以把软件测试分为基本功能测试、全面测试和基准测试。按此方法分类的各种测试解释如下：、基本功能测试（Smoke test）：只对软件的关键功能做测试，而不必卷入细致的测试，不必面面俱到。、全面测试（Sanity test）：不仅对软件关键功能测试，还要覆盖软件的全部功能，是回归测试的主要组成部分。、基准测试（Benchmark test）：对指定的一个或一组程序及数据在不同的计算机上执行测试，以测定其在标准情况下、特定配置下的工作性能，并将其执行速度、完成需时等加以比较。软件测试分类（续）第19页，共38页。l按软件特性可以把软件测试分为功能测试和非功
12、能测试：功能测试主要包括：等价区间测试，把输入空间划分几个“等价区间”，在每个区间中只需要测试一个典型值即可；边界值测试；随机测试；状态转换测试；流程测试等。非功能测试主要包括：安装/卸载测试；使用性测试；恢复测试；兼容性测试；安全测试；性能测试；强度/压力测试；容量测试；任意测试等。软件测试分类（续）第20页，共38页。第十二章 软件测试简介软件测试基本概念软件测试分类自动化测试常见测试工具BUG管理流程第21页，共38页。自动化测试优点l自动化测试：就是使用（自动化测试）工具来进行的测试，一般不需要人干预。l自动化测试优点：一旦积累了一套自动化测试的程序，日后自动化测试节省大量的时间和资源
13、；没有时间限制一般安排在下班后；可以反复执行；保证测试执行过程的一致性及准确性；有较高的功能测试覆盖率；模拟操作，进行压力测试，这是手测很难实现的。第22页，共38页。并非所有的测试都可用自动测试来实现，比如使用性测试、兼容性测试等；没有创造性，只能安排设计好的用例去测，碰到新问题不会应变；受具体项目资源限制：受时间及人力的限制，因为自动化测试编程很费时；受资金预算的限制，商用测试软件价格比较高；对测试工程师要求比较高。自动化测试缺点第23页，共38页。l根据自动化测试的特点，建议以下测试优先考虑自动测试：回归测试，每次有新版本发布前都必须执行，在整个开发过程中需要多次执行，很适合编写成自动测
14、试程序。涉及大量不同数据输入的功能测试。如各种各样的边界值测试，需要大量时间去完成的网页连接测试等等。用手测完成难度较大的测试，如性能测试、压力（负荷）测试、强度测试等。例如：对于一个网站，要测试1万个用户在某一时间内同时登录时，服务器运行是否正常及速度是否仍然可以接受，这是手测很难完成的。自动化测试应用场景第24页，共38页。编写测试用例；分析、分析、验证测试用例；对已有测试用例归类，编写测试自动化计划方案；编写自动化测试程序；尽量用“数据驱动”来提高测试覆盖率；将测试用例编写成自动测试程序；执行测试程序，记录并反馈BUG；不断完善自动化测试系统或程序。自动化测试实现步骤第25页，共38页。
15、第十二章 软件测试简介软件测试基本概念软件测试分类自动化测试常见测试工具BUG管理流程第26页，共38页。不是专业测试工具的工具查看器和监视器，各类编译器的代码调试器均可看作查看器；任何能够洞察系统，看到一般用户看不到的数据的工具，都可以称之为查看测试工具；驱动程序，用于控制和操作测试软件的工具，最简单的是批处理文件；仿真器，为测试工具或程序提供数据或响应软件发送的数据；分析工具，电子表格软件、文件比较软件、抓屏软件和比较软件、计算器、秒表等；干扰发射器和噪声发生器，模拟由于数据中断、干扰能产生的通信错误。第27页，共38页。常见测试工具窗口/网络软件用户界面测试WinRunner、Quick
16、Test ProfessionalSilkTestFunctional TesterTest PartnerVisualTest性能测试LoadRunnerSilkPerformerRational Performance TesterQALoad第28页，共38页。常见测试工具（续)软件测试管理工具TestDirectorSilkCentral Test ManagerRational TestManager/ClearQuestQADirector/TrackRecordX窗口软件测试X Runner自开发测试软件，适用于特定领域第29页，共38页。第十二章 软件测试简介软件测试基本概念软
17、件测试分类自动化测试常见测试工具BUG管理流程第30页，共38页。微软研发中的BUG管理微软有一个研发框架叫MSF（微软解决方案框架），开发过程中主要有三个角色：PM(程序规划经理）、Dev（软件开发工程师）、Tester（软件测试工程师）。在研发过程中，三者分工明确、接口清晰。PM来定义需求、书写每个功能特性的设计文档(SPEC)；Dev写代码来实现这些SPEC；Tester来测试Dev做出来的东西是否符合PM定义的SPEC。第31页，共38页。微软不少项目都使用完善的研发管理工具，其中Bug管理系统（原来叫Raid系统，现集成在VSTS中）居于核心地位。整个软件研发过程中，特别是在测试产品
18、、修复BUG的中后期，团队中所有人都生活在Raid中。Tester只要发现问题就立即新建一个Bug予以跟踪并指派给相关的开发小组长（Dev Leader)，开发小组长会判断这个BUG属于某个特定的开发人员并指派他处理。开发人员会根据BUG的详细描述信息找到问题所在，修改程序解决这个BUG，并把BUG返回给当初的测试人员；或者有争议的时候，把BUG指派给这个需求定义者PM，要求澄清说明。测试人员在看到某个BUG被解决后，就去验证这个BUG是否真的不存在了，根据最初的发现步骤去证实问题真的解决了就关闭这个BUG；否则，可以激活这个BUG，返回给当初的开发人员做进一步处理。当测试人员与开发人员无法达
19、成一致意见时，由对应的PM出面做协调，判断这个BUG的严重程序，对用户可能的影响。根据产品的进度和项目资源做出评估，是否真的需要解决这个问题。管理团队利用BUG管理系统来跟踪整个进度，单个人的工作、小组的进度、整个产品研发进度。微软研发中的BUG管理（续）第32页，共38页。l在微软的BUG管理或者说研发管理思想里有以下几点需要注意：报告BUG不仅仅是测试人员的事情，团队的每个人发现问题时都会提交一个BUG来跟踪；BUG管理系统不仅仅是跟踪软件功能方面的BUG，其他各种问题，如需求文档的变更、界面上错别字、帮助文档的语言、某项任务指源等都可以通过此来跟踪。在VSTS中全部被称之为工作项。Eve
20、rything should be tracked in VSTS（Raid）。微软研发中的BUG管理（续）第33页，共38页。通用BUG管理流程l比较通用的Bug管理流程如下：BUG登记测试工程师，初始；指派任务项目经理，激活；修改BUG开发工程师，修改；验证测试工程师，通过则转第五步，否则转二步，状态为再激活；关闭测试工程师。l为了能使开发人员准确理解Bug，Bug描述应当具有以下特征：短小只解释事实和演示、描述软件缺陷必需的细节；单一每个报告只针对一个软件缺陷，切记不要把几个软件缺陷放在一起描述，这样修复人员很容易漏掉缺陷；明显和通用用简单步骤描述软件缺陷，得到修复的机会较大；再现按照预
21、定步骤可以使软件达到缺陷再次出现相同状况。第34页，共38页。BUG的分类按缺陷状态分为：Open：确认提交的缺陷，等待处理Rejected：不需要修复或不是缺陷Resolved：缺陷被修复Reopen：回测后，缺陷没有被修复Closed：回测后，缺陷被修复，将其关闭第35页，共38页。l按缺陷严重级分为：严重：不能完全满足系统要求，基本功能未完全实现；或者危及人身安全。比如：系统崩溃、数据丢失、数据毁坏等。较严重：严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。比如：操作性错误、错误结果、遗漏功能等。一般：严重地影响系统要求或基本功能的实现，但存在合理的更正办法（重新安装或重新启动该软件不属于更正办法）。比如：小问题、错别字、UI布局、罕见故障等。轻微：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。BUG的分类（续）第36页，共38页。l按缺陷优先级分为：高：立即解决，否则将影响进一步测试中：正常排队，在产品发布前按正常安排进行修复低：可暂缓解决，如果时间允许应该修复，不修复也能发布大部分Bug管理工具都支持多种分类方式，以方便不同关注点的人员使用Bug分析统计数据BUG的分类（续）第37页，共38页。本章结束，谢谢!第38页，共38页。
