写测试用例方法软件测试基础

软件测试基础主讲：毕伟日期：2024年3月28日培训目的加强部门内测试方法的知识交流常见的测试类型及测试方法介绍

目录测试组织测试文档测试中不稳定的问题分析常见的测试类型软件测试概述测试心理学两个问题1.在2011年全年，消费者协会受理的投诉产品中，排名第一位的是什么？

手机，投诉率超过10％。2.手机产品已经连续几年蝉联该项“宝座”？

8年一组数据

◆2006~2008手机行业投诉量对比◆2008年手机产品整体满意度调查◆2010年5月手机行业投诉问题小手机频出大事故，值得我们反思！缺陷的由来——关于Bug的故事软件缺陷的概念什么是软件缺陷？“软件缺陷”就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，不能满足或不能全部满足用户的需求。——IEEESTD729软件缺陷的概念软件缺陷的产生根源技术问题• 算法错误，语法错误• 计算和精度问题• 接口参数传递不匹配管理问题• 项目没有被很好地理解• 计划不周，导致赶进度• 误解、沟通不充分• 没有充分的文档资料• 软件可靠性缺少度量的标准，质量无法保证软件本身• 软件难以维护、不易升级。• 文档错误、用户使用场合特殊• 时间上不协调、不一致所带来的问题• 系统自我恢复、数据异地备份、灾难性恢复等问题什么是软件测试“软件测试”是使用人工或自动的手段，来运行或测试某个软件产品系统的过程，其目的在于检验它是否满足规定的需求，或弄清预期结果与实际结果之间的差别。

——IEEE测试的现状目前状况测试的实践性大于理论性测试理论体系尚不成熟测试工具尚不成熟测试效果对于个人的依赖性比较大我们的测试没有基于需求进行测试，开发如何实现我们就如何测试，基本属于对开发的自测，非常不合理

为什么要进行软件测试

–“任何一个程序，无论它多么小，总存在着错误。”没有错误的程序是一则谬论，世间难寻。——某大师–因为软件缺陷（错误）的存在，而软件中存在的缺陷给我们带来的损失是巨大的。–因为只有通过测试，才可以发现软件缺陷。–因为也只有发现了缺陷，才可以将软件缺陷从软件产品或软件系统中清理出去。–为了减少产品上市之后的投诉

软件测试的两面性

BillHetzel博士（正向思维的代表）软件测试就是为程序能够按预期设想那样运行而建立足够的信心软件测试是一系列活动以评价一个程序或系统的特性或能力并确定是否达到预期的结果测试是为了验证软件是否符合用户需求，即验证软件产品是否能正常工作

GlenfordJ.Myers（反向思维的代表）测试是为了证明程序有错，而不是证明程序无错误一个好的测试用例是在于能发现至今未发现的错误一个成功的测试是发现了至今未发现的错误的测试软件测试概念的两面性测试的一些常识测试能提高软件的质量，但是提高质量不能依赖测试测试只能证明缺陷存在，不能证明缺陷不存在。“彻底地测试”难以成为现实，要考虑时间、费用等限制，不允许无休止的测试。我们应当祈祷：软件缺陷在用户换掉他的手机之前一直没有机会发作！测试的主要困难时不知道如何进行有效地测试，也不知道什么时候可以放心地结束。80---20原则，80%的缺陷聚集在20%的模块中，经常出错的模块修改后还会经常出错。如何提高测试效率减少冗余的测试掌握测试方法，减少无价值的测试

无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来要测试一个典型的输入就行了，如果有人在此区间测试了100次，那么其中的99次是无价值的。确定测试的优先级确定优先级的关注点哪些功能是软件的特色哪些功能是用户最常用的哪些是产品的主要卖点哪些功能出错后将导致用户投诉或退机哪些程序是最复杂，最容易出错的哪些程序是相对独立，应提前测试的哪些程序最容易扩散错误哪些程序是全系统的性能瓶颈所在哪些程序是开发者最没有信心的软件测试通用原则Myers提出的10条原则：《软件测试的艺术》–原则1：测试用例中的一个必需部分是对预期输出或结果的定义–原则2：程序员应当避免测试自己编写的程序•注意：调试≠测试–原则3：编写软件的组织不应当测试自己编写的软件–原则4：应当彻底检查每个测试的执行结果–原则5：测试用例的编写不仅应当根据有效和预期的输入情况，也应当根据无效和未预料到的输入情况软件测试通用原则Myers提出的10条原则(续)–原则6：检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不该做的”–原则7：应当避免测试用例用后即弃，除非软件本身就是一个一次性软件–原则8：计划测试工作时，不应当默许假定不会发现错误–原则9：程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比–原则10：软件测试是一项极富创造性、极具智力挑战性的工作经典V模型用户需求和验收测试计划验收测试产品需求和系统测试计划接口规范和集成测试计划详细设计和单元测试计划系统测试集成测试单元测试编码实现TMCTMC测试技术不实际运行程序，而是通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术。也称为静态分析技术。实际运行程序，并通过观察程序运行的实际结果来发现错误的软件测试技术。在不知道程序内部结构，只知道程序规格的情况下采用的测试技术或策略。在知道程序内部结构的情况下采用的测试技术或策略。开发组内部进行的，采用讲解、讨论和模拟运行的方式进行的查找错误的活动。开发组内部进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。开发组、测试组和相关人员(QA、产品经理等)联合进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。针对要求的程序功能，按照规范的流程进行的测试。针对要求的程序功能以外的其他要求，包括性能、安全、配置、负载等指标，按照规范的流程进行的测试。针对要求的程序功能、性能、安全、配置、负载等指标，基于破坏目的、按照经验进行的随机测试。程序修改或者版本更新以后，为了确保以前正确的功能和其他指标仍旧正确，而重新进行的测试。在测试过程中，选择足够的测试用例，使得每一个可执行语句至少被执行一次。在测试过程中，选择足够的测试用例，使得程序中的每一个分支判断的每一种可能结果都至少被执行一次。在测试过程中，选择足够的测试用例，使得程序中的每一条可能执行的路径都至少执行一次。测试的分类按照测试用例的设计方法：

测试可以分为白盒测试、灰盒测试和黑盒测试。按照测试的层次和策略：测试可以分为单元测试、集成测试、系统测试和验收测试。按照CMMI模型划分：

测试可以分为验证（verification）和确认（validation）。验证（Verification）验证的目的是确保所选择的工作产品符合它们的需求。换言之，验证保证“你正确的构建了它”。确认（Validation）证明产品或产品组件在它预定的工作环境中能实现它预期的用途。

换言之，确认保证“你构建了正确的产品”。－－－－cmmi白盒测试白盒测试也称结构测试或逻辑驱动测试，它是在知道产品内部工作过程的情况下，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条路径是否都能按预定要求正确工作，而不顾它的功能。白盒测试的主要方法有逻辑驱动、路径测试等，主要用于产品验证。灰盒测试灰盒测试，是介于白盒和黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。

黑盒测试黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能的情况下，通过测试来检测每个功能是否都能正常使用，在测试时把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边界值分析、因果图、错误推测等，主要用于产品确认测试。对于软件，单元可能是某条语句或某个函数；对于硬件，单元可能是某个元器件。集成测试是分层的，硬件集成测试（逐级）、软件集成测试、软硬件集成测试，最顶层的集成测试就是系统测试。我们目前测试部人员的测试既有集成测试也有系统测试系统测试系统测试中最关键的两个要素测试设计测试设计的主要任务是设计测试用例测试用例库是一种经验的积累，是测试活动最宝贵的财富测试用例的衡量标准：多、快、好、省测试流程系统测试的控制过程系统测试的度量过程

目录测试组织测试文档测试中不稳定的问题分析常见的测试类型软件测试概述测试心理学常见测试类型功能测试性能测试压力测试交互性测试外场测试兼容性测试易用性测试手机软件的质量属性功能性质量属性正确性（correctness）健壮性（robustness）非功能性质量属性性能（performance）易用性（usability）兼容性（compatibility）手机软件质量的要素市场角度：用户最关注的、能够成为卖点的功能研发角度：对软件整体质量产生重大影响功能测试功能测试概念–依据产品设计规格说明书，完成对产品功能进行操作，以验证系统是否满足用户的功能性需求–这是手机软件测试工作中最核心和最基本的一项测试，该测试的主要内容是检查软件是否符合需求定义，并通过构造正常的操作来检查手机的动作是否正确；在这个测试里，正确性是最最重要的手机软件质量要素。功能测试测试重点手机的功能（若无特别指明，均指软件功能）按照可见性可以分为两类：显性功能和隐性功能。隐性功能就好像是地下党员，你在共产党员的花名册里永远找不到他们的名字。显性功能：指在菜单里可以看得到的功能隐性功能：指在菜单里看不到的功能举个例子，电话本的显性功能有增加、编辑、删除、拨打等，这些功能可以在电话本的菜单里面看得到，姓名列表排序则属于一个隐性功能，因为在电话本的菜单里没有这样一个子菜单，但它却是一个实实在在的功能在实际的测试过程中，显性功能通过菜单遍历可以很容易地进行无遗漏的测试，但是隐性功能却很容易为我们所忽略！性能测试•性能测试概念–为获取或验证系统性能指标而进行的测试–常常与强度测试结合起来进行。为记录性能需要在系统中安装必要的量测仪表或是为度量性能而设置的软件(或程序段)。•测试重点–最终用户的体验，如2-5-10原则–商业需求，如“比竞争对手的产品好”–技术需求，如CPU使用率不超过70％–标准要求•举例–验证Wap2.0浏览网页速度是否符合需求定义–验证批量同步电话簿记录是否符合需求定义压力测试压力测试概念考察手机在高负荷状态下的运行情况。所谓高负荷，就是多个功能快同时在运行，使手机CPU资源高负荷地运转。考察手机在满容量状态下的运行情况。在测试前，应设法使手机所有的用户内存全部存满，然后在进行一些相应的操作，观察手机的性能情况。压力测试测试重点–稳定性压力测试：持续高负载下的压力测试–破坏性压力测试：通过不断加载的手段，快速造成系统的崩溃，让问题尽快地暴露出来–渗入测试：通过长时间运行，使问题逐渐渗透出来，从而发现内存泄漏、垃圾收集或系统的其他问题，以检验系统的健壮性–峰谷测试：高低突变加载方式的压力测试•举例–验证从样机复制1000条号码簿记录到手机卡上–验证后台播放大容量音频的同时，反复按键进退某些应用健壮性测试健壮性测试概念健壮性是指在异常情况下，软件还能正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力。----小时候看电影发现，日本鬼子往往一枪就over了，八路军打一枪顶多流几滴血，仍然能够冲锋陷阵，这说明八路军的健壮性比日本鬼子的健壮性要强容错测试用于检查系统的容错能力，测试系统在遇到系统崩溃、硬件损坏或其他灾难性问题后能否很好地恢复。健壮性测试测试重点：容错性测试通常构造一些不合理的输入来引诱软件出错，例如：输入错误的数据类型，如“猴”年“马”月；输入定义域之外的数值。异常测试法。除了不能拳打脚踢嘴咬外，什么招数都可以使出来。恢复测试重点考察以下几项：系统能否重新运行；有无重要的数据丢失；是否毁坏了其它相关的软件硬件。

交互性测试

•交互性测试概念–主要测试某个功能模块与其他模块的交互操作。•测试重点–电路域（CS）业务交互：语音业务、可视电话等–分组域（PS）业务交互：数据增值业务等–终端应用软件交互：播放器、照相机等•举例–验证发送短息时有来电呼入，手机是否正常–验证通话过程中，系统自动关机时间到，手机是否正常外场测试外场测试概念–主要用于验证系统在实际使用环境中能够正常工作，因为很多测试在实验室中难于模拟，如：小区切换–执行成本相当昂贵，需要投入大量人力和物力–场点的选择要具有代表性，通常是精心策划的结果•测试重点–小区选择、重选、切换–网络选择、网络接入与注册–分组域、电路域数据业务–各类机卡接口–弱信号区域、特殊地形•举例–山地、湖泊、高原的通话测试–高速车载环境的手机上网测试兼容性测试兼容性测试概念软件兼容性测试就是要检查软件能否在不同组合的环境下正常运行，或者软件之间能否正常交互和共享信息。测试重点–数据的兼容性–操作系统兼容性–不同品牌的兼容性–网络制式兼容性–第三方应用的兼容性–不同字数、不同大小之间的兼容测试–不同厂商的外设与手机的兼容性：SD卡、手机卡、蓝牙耳机、有线耳机。橘生淮南为之橘，橘生淮北为之枳，这说明橘的兼容性太差在3G时代，手机业务软件日趋复杂，手机操作的友好性，成为消费者评价一个产品和品牌的重要因素。在业界企业手机产品设计制造技术日趋相近的情况下，给用户带来使用上的美好体验，是产品差异化的表现。用户体验将直接影响用户对手机产品满意度。符合大众使用习惯的人性化设计的手机，已越来越受到用户的青睐。易用性测试易用性测试原则少而精，少就意味专注，专精就是竞争力（苹果）不能凭想象和猜测用户永远是对的用户不总是对的设计人员不是用户用户不是设计人员及早并持续关注用户需求用户为什么要用这个应用用户希望提供什么样的功能他们何时使用这个功能这些用户有什么特点他们在哪里使用这个应用程序他们对所要完成的任务有多了解他们是否经常使用这个应用技术的采用对用户是否合适手机涉及易用性的内容视觉外型、颜色、布局、图片、字体大小、界面美观听觉声音播放音质及内容、来电铃声、音乐播放、闹钟铃声、通话音量触觉按键手感、触屏灵敏度、手写输入可用性

针对错误的设计、不同的交互风格、与第三方软件的兼容性浏览器，照相机，播放器，手机电视、联系人易用性测试实践1.一致性手机界面外观、菜单风格与布局、显示风格、操作序列、提示术语等均要风格一致；对于相同的操作，系统给予的处理方式应统一；同一厂商的不同手机的操作界面保持一致，减少用户学习时间。2.反馈与呈现对用户动作、事件、消息所做出的响应。若系统没有反馈，用户并不知操作是否为系统所接受，是否正确响应，操作响应结果等；最终反馈信息可多种方式来呈现，如文字、图像或声音。易用性测试实践3.合理利用空间和颜色，保持界面简洁：多媒体播放界面控件利用；行列整齐，行距一致合理利用颜色、显示效果来实现内容与形式的统一4.保持用户习惯状态：用户在输入短消息时，使用一种输入法，在下一次进入该界面时，仍保持该输入法。情景模式中支持用户自定义设置。易用性测试实践5.合理使用快捷键方式，自定义环境模式和个人设定对于没有五向键的手机，音量上下键可以控制短信列表界面查看上一条、下一条操作。6.速度响应及显示刷新加载网页时响应速度慢，网页不能及时刷新。2-5-10原则7.给用户提供便捷的操作要考虑到用户在走路时的单手操作，如发短信、查看短信、接打电话等查找联系人时，支持三笔定位。8.允许操作可逆删除用户数据、恢复出厂设置等可能给用户带来损失的操作，必须要有提示。短信、彩信、邮件发送时支持取消操作。批量删除短信、联系人等可以取消。9.减少用户记忆大部分用户不依赖说明书就可以使用手机的主要功能。手机的操作容易记忆，如停用一段时间后，用户仍然能使用而不必从头学起。“基伍基因”。不同的手机的界面及操作风格保持一致当你挑选了一款诺基亚手机并感觉不错，这就是质量；当你觉得这部手机易于使用，这就是质量；当客户服务迅速地回应你的要求，这就是质量；当我们的产品满足并超越用户的期望，这更是质量。提升用户体验最好的方法就是在设计过程中尽早地开始用户测试，每一步都坚持做测试！

倾听用户的声音，满足并努力超越用户的期望。

目录测试组织测试文档测试中不稳定的问题分析常见的测试类型软件测试概述测试心理学测试中不稳定问题的分析在手机A上能够再现的问题却不能够在手机B上再现重新下载软件之后，问题无法再现张三能够再现，李四却不能再现换张SIM卡之后问题无法再现问题不稳定的现象跟手机硬件或附件有关跟历史操作记录有关系，手机软件是一个有记忆效应的系统，历史操作产生的数据或信息会被手机存储起来，从而对后面的动作产生影响。重新下载软件会擦除这些历史数据或信息。小日本无论现在怎么表现，都无法改观他们在亚洲人民心目中的形象，这是因为小日本在历史上的滔天罪行已经被亚洲人民深深地记忆在心里！跟操作员本身的因素有关，GC20写短消息输入问题重启需要很快的速度，换一个输入速度慢的操作员是不能再现这个问题的。问题不能稳定再现的原因测试中不稳定问题的分析首先要确定这是不是由于非软件的因素造成的。多用几部手机去尝试再现这个问题，如果是纯软件问题，它应该在任何一部手机上都可以再现的，这里假设这个问题跟历史操作记录无关。使用历史追溯法去再现这个问题使用一些辅助工具去查找原因一条原则：大胆假设，小心求证测试中不稳定问题的分析发现不稳定的问题怎么办

目录测试组织测试文档测试中不稳定的问题分析常见的测试类型软件测试概述测试心理学古代中国的科技举世辉煌，秦帝国修灵渠、直道，其地理知识超越了它的时代600年；越王宝剑的制造工艺，超越了青铜器材的物理极限；宋代的科技创新举世瞩目！可惜这些宝贵的科技财富很多都没有流传下来，因为古人不喜欢写文档！我们今天只能望历史而一声叹息！中华民族有师承的传统，武艺高强的师傅总是在自己还剩下一口气的时候把看家本领教给徒弟，说：“徒儿，师傅只能打一遍，你用心看吧，能学多少就算多少。”打完之后师傅便悲壮死去，失望的徒弟翻遍师傅的屋里墙外，掘地三尺也找不出一页武功秘籍！多少绝世武功因此失传！改变这种不爱写文档的习惯，要从我们做起，热爱写文档，写高质量的文档！写文档的重要性测试文档软件测试中的关键文档测试计划（TestPlan）测试用例（TestCase）/测试规范（TestSpecification）测试报告（TestReport）缺陷报告（BugReport）测试文档测试文档测试计划（TestPlan）应该明确测试的范围，即测什么，如果说不清楚测什么，至少要说清楚不测什么，否则测试将是苦海无边，回头也找不到岸；计划还应该明确测试项目在时间上怎么安排，先测什么，后测什么；第二步应该明确测试的方法，即怎么样测，要对在第一步中所确定的测试项目进行展开，明确测试的需求并编制测试规范（TestSpecification）及测试用例（TestCase）；第三步执行测试用例（TestCase）；最后要撰写测试报告（TestReport），目的是使软件缺陷能够得到迅速的修复，同时也使相关的部门或同事能够清楚地了解软件开发的进展情况，软件测试报告并无固定的格式，只要能够完整、清楚地反映当前的测试情况就可以了。测试文档测试流程规范测试文档不知道怎么去写，要写些什么样的内容、要写成什么样的格式，这些都不知道。对手机软件测试本身没有深刻和全面的理解，不清楚手机软件测试到底要做哪些工作，不知道手机软件测试的范围，从而无法对测试工作进行阶段性分解。我们可以借鉴一下现代项目管理的一些理念，首先定义出手机软件测试的范围及边界，其次对这些工作内容按照项目总体进度进行关键性的划分，最后对各项内容逐级分解到具体的测试，这样就可以把手机软件测试的大概脉络给理清了。为什么有人不喜欢写测试计划中国有句俗话，叫做“计划赶不上变化“，很多提前作好的计划在实际的执行过程中往往变成了一张废纸！久而久之，也没有人再愿意再做计划了。造成这样的原因有：计划本身做得不周全，或者是为了应付某个检查而随意编制计划。实施中发生了变化，但计划却没有及时地修正。计划是相对的，变化是绝对的，既然时时事事处处都充满着变数，那计划的意义何在呢？回答是：计划为控制事物向预期方向发展提供了可能！没有计划的事物其发展就象“身如柳絮随风飘，飘到哪就是哪”。变化是相对于计划而言的，没有计划，变化则无从谈起。测试文档

目录测试组织测试文档测试中不稳定的问题分析常见的测试类型软件测试概述测试心理学测试组织测试团队测试团队一般5-10人，否则应该细分为测试组测试经理/测试负责人制定测试计划和测试方案分配测试任务并检查测试进度代表测试团队与开发、产品、用户沟通设计测试用例测试员设计测试用例执行测试用例并填写缺陷报告检查缺陷处理结果测试与开发的比例与产品大小、复杂度、质量要求相关目前国内比例平均为1:62000年M$全球52000人，利润$300亿，10000开发人员，15000测试人员，测试费用占研发费用的60%Exchange2000程序经理25人；开发人员140人；测试人员350人Windows2000：$50亿程序经理250人；开发人员1700人；测试人员3200人IE4.0开发时间6个月，测试时间8个月测试组织测试的组织测试工程师的素质

沟通能力技术概念和能力熟悉业务的能力很强的记忆力耐心责任心洞察力工作运作机制测试的运作方式----制度化并形成应用建立一套规范化的测试工作流程建立一套规范化的测试文