《手机软件测试的基本理论与方法幻灯片.ppt》由会员分享，可在线阅读，更多相关《手机软件测试的基本理论与方法幻灯片.ppt（112页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、手机软件测试的基本理论与方法第1页，共112页，编辑于2022年，星期六测试的基本理论及方法l l对软件测试的误解l l如何理解软件测试如何理解软件测试l l软件测试的定义软件测试的定义l l软件测试的对象软件测试的对象l l软件测试分类和比较软件测试分类和比较l l软件测试的目的软件测试的目的l l软件测试组织软件测试组织l l软件测试规范l l软件测试的内容和技术l lWEBWEB应用测试应用测试第2页，共112页，编辑于2022年，星期六对软件测试的误解l l如果发布出去的软件有质量问题,那是软件测试人员的错.l l软件测试技术要求不高,至少比编程容易多了.l l软件测试随便找一个能力差
2、的人就能做.l l有时间就多测试一些,来不及就少测试一些.l l软件测试是测试人员的事,与开发人员无关.l l设计-实现-测试,软件测试是开发后期的一个阶段第3页，共112页，编辑于2022年，星期六如何理解软件测试l l软件测试是一种有效的提高软件质量的手段软件测试是一种有效的提高软件质量的手段,但即使在投入但即使在投入上有所保证上有所保证,测试也不能百分为百发现所有质量隐患测试也不能百分为百发现所有质量隐患.况且软况且软件质量并不仅仅是测试出来的件质量并不仅仅是测试出来的.l l很多人认为软件测试就是运行一下软件很多人认为软件测试就是运行一下软件,看看结果对不对看看结果对不对.但实但实际上
3、际上,如何在有限的投入下如何在有限的投入下,提高软件测试的效率和产出是一件提高软件测试的效率和产出是一件很见功底的事很见功底的事.好的测试人员不仅要掌握各种测试技术好的测试人员不仅要掌握各种测试技术,还要具还要具备丰富的编程经验和对备丰富的编程经验和对BUGBUG的敏感的敏感.测试的复杂之处测试的复杂之处,除了测试除了测试技术问题之外技术问题之外,还有测试管理问题还有测试管理问题.l l测试不是可有可无测试不是可有可无,随心所欲的随心所欲的.规范化的软件开发需要对软规范化的软件开发需要对软件测试早做计划件测试早做计划,分配必要的时间分配必要的时间,人力和财力等资源人力和财力等资源,并将并将其作
4、为项目管理的一个部分加以控制和协调其作为项目管理的一个部分加以控制和协调.l l开发和测试是软件项目相辅相成的两个过程开发和测试是软件项目相辅相成的两个过程,人员间的交流人员间的交流,协作和协作和配合是提高整体效率的重要因素配合是提高整体效率的重要因素.第4页，共112页，编辑于2022年，星期六l l软件产品开发完毕,再进行测试的观念是有悖于生命周期理论的.软件产品质量问题越晚发现,修复的代价越大.需求设计编程内部测试外部测试发布修正BUG的代价第5页，共112页，编辑于2022年，星期六l l一些常识和经验之谈l l测试能提高软件的质量，但是提高质量不能依赖测试。测试能提高软件的质量，但是
5、提高质量不能依赖测试。l l测试只能证明缺陷存在，不能证明缺陷不存在。测试只能证明缺陷存在，不能证明缺陷不存在。“彻底地测试彻底地测试”难以成为现实，要考虑时间、费用等限制，不允许无休止地测难以成为现实，要考虑时间、费用等限制，不允许无休止地测试。我们应当祈祷：软件的缺陷在产品被淘汰之前一直没有机试。我们应当祈祷：软件的缺陷在产品被淘汰之前一直没有机会发作。会发作。l l测试的主要困难是不知道如何进行有效地测试，也不知道测试的主要困难是不知道如何进行有效地测试，也不知道什么时候可以放心地结束测试。什么时候可以放心地结束测试。l l每个开发人员应当测试自己的程序（份内之事），但是不能每个开发人员
6、应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据（所以项目需要独立测试人作为该程序已经通过测试的依据（所以项目需要独立测试人员）。员）。l l80-2080-20原则：原则：8080的缺陷聚集在的缺陷聚集在2020的模块中，经常出错的的模块中，经常出错的模块改错后还会经常出错模块改错后还会经常出错l l测试应当循序渐进，不要企图一次性干完，注意测试应当循序渐进，不要企图一次性干完，注意“欲速则欲速则不达不达”。第6页，共112页，编辑于2022年，星期六软件测试的定义l l软件测试是为了发现错误而执行程序的过程l l软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精
7、心设计一批测试用例(即输入数据及其预期的输出结果),并利用这些测试用例去运行程序,以发现程序错误的过程.第7页，共112页，编辑于2022年，星期六l l软件测试不等于程序测试.软件测试贯穿于软件定义和开发的整个期间.需求分析,概要设计,详细设计,以及程序编码等各个阶段所得到的文档,包括需求规格说明,概要设计规格说明,详细设计规格说明以及源程序,都是软件测试的对象.软件测试的对象第8页，共112页，编辑于2022年，星期六软件生存各个阶段间的确认和验证 第9页，共112页，编辑于2022年，星期六l软件配置：软件配置：包括软件需求规格说明、软件设计规格说明、源代码等；l测试配置：测试配置：包括
8、测试计划、测试用例、测试驱动程序等。实际上，在整个软件工程过程中，测试配置只是软件配置的一个子集。l测试工具：测试工具：为提高软件测试效率，可使用测试工具支持测试工具。例如：测试数据自动生成程序、测试结果分析程序等。第10页，共112页，编辑于2022年，星期六测试的目的l l测试是程序的执行过程,目的在于发现错误;l l一个好的测试用例在于发现至今未发现的错误;l l一个成功的测试是发现了至今的错误的测试.第11页，共112页，编辑于2022年，星期六测试的种类名称说明黑盒测试基于软件需求，而不是基于软件内部设计和程序实现的测试方式。白盒测试基于软件内部设计和程序实现的测试方式。单元测试主要
9、测试软件模块的源代码。一般由开发人员而非独立测试人员来执行，因为测试者需要懂得该单元的设计与程序实现，测试者可能需要编写额外的测试驱动程序。集成测试将一些“构件”集成一起时，测试它们能否正常运行。这里“构件”可以是程序模块、客户机服务器程序等等。功能测试测试软件的功能是否符合功能性需求，通常采用黑盒测试方式。一般由独立测试人员执行。系统测试测试软件系统是否符合所有需求，包括功能性需求与非功能性需求。一般由独立测试人员执行，通常采用黑盒测试方式。回归测试指错误被修正后或软件功能、环境发生变化后进行的重新测试。回归测试的困难在于不好确定哪些内容应当被重新测试。验收测试由客户或最终用户执行，测试软件
10、系统是否符合需求规格说明书。第12页，共112页，编辑于2022年，星期六名称说明负载测试测试软件系统的最大负载，超出此负载软件可能会失常。压力测试概念上与负载测试相似，叫法不同。性能测试测试软件在各种状况下的性能，如在正常或最大负载下的状况。易用性测试测试软件是否易用，主观性比较强。一般要根据很多用户的测试反馈信息，才能评价易用性。安装与反安装测试测试软件在“全部、部分、升级”等状况下的安装/反安装过程。恢复测试测试该系统从故障中恢复过来的能力。安全性测试测试该系统防止非法侵入的能力。兼容性测试测试该系统与其它软件硬件兼容的能力。比较测试通过与同类产品比较，考察该系统的优点、缺点。Alpha
11、测试一种先期的用户测试，此时系统刚刚开发完成。Beta测试一种后期的用户测试，此时系统已经通过内部测试，大部分错误已经改正，即将正式发行。第13页，共112页，编辑于2022年，星期六测试的分类与比较l l测试方式测试方式l l白盒测试：关心软件内部设计和程序实现，主要测试依据是设计文档白盒测试：关心软件内部设计和程序实现，主要测试依据是设计文档l l黑盒测试：不关心软件内部，只关心输入输出，主要测试依据是需求文档黑盒测试：不关心软件内部，只关心输入输出，主要测试依据是需求文档l l 测试阶段测试阶段l l单元测试、集成测试、单元测试、集成测试、系统测试、系统测试、验收测试。是验收测试。是“从
12、小到大从小到大”、“由内至外由内至外”、“循序渐进循序渐进”的测试过程，体现了的测试过程，体现了“分而治之分而治之”的思想。的思想。l l单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合是否符合“设计设计”。l l集成测试界于单元测试和系统测试之间，起到集成测试界于单元测试和系统测试之间，起到“桥梁作用桥梁作用”，一般由开发小，一般由开发小组采用白盒加黑盒的方式来测试，既要验证组采用白盒加黑盒的方式来测试，既要验证“设计设计”又要验证又要验证“需求需求”。l l系统测试的粒度最大，一般由独立测试小组采用
13、黑盒方式来测试，主要测试系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合系统是否符合“需求规格说明书需求规格说明书”。l l验收测试与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。验收测试与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。第14页，共112页，编辑于2022年，星期六l l开发与测试的V型关系l l如果软件开发过程采用严格的瀑布模型，那么开发与测试有“V”型的对应关系。需求开发高层设计详细设计编程单元测试集成测试系统测试验收测试第15页，共112页，编辑于2022年，星期六l l测试内容l l接口与路径测试。l l功能
14、测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试测试阶段测试阶段 主要依据主要依据 测试人员、测试方式测试人员、测试方式 主要测试内容主要测试内容 单元测试单元测试单元测试单元测试系统设计文系统设计文系统设计文系统设计文档档档档由开发小组执行白盒测试由开发小组执行白盒测试由开发小组执行白盒测试由开发小组执行白盒测试 接口测试、路径测试接口测试、路径测试接口测试、路径测试接口测试、路径测试 集成测试集成测试集成测试集成测试系统设计文系统设计文系统设计文系统设计文档档档档需求文档需求文档需求文档需求文档由开发小组执行白盒测试由开发小组执行白盒测试由开发小
15、组执行白盒测试由开发小组执行白盒测试和黑盒测试和黑盒测试和黑盒测试和黑盒测试 接口测试、路径测试接口测试、路径测试接口测试、路径测试接口测试、路径测试功能测试、性能测试功能测试、性能测试功能测试、性能测试功能测试、性能测试 系统测试系统测试系统测试系统测试需求文档需求文档需求文档需求文档由独立测试小组执行黑盒由独立测试小组执行黑盒由独立测试小组执行黑盒由独立测试小组执行黑盒测试测试测试测试 功能测试、健壮性测试、性功能测试、健壮性测试、性功能测试、健壮性测试、性功能测试、健壮性测试、性能测试、用户界面测试、安能测试、用户界面测试、安能测试、用户界面测试、安能测试、用户界面测试、安全性测试、压力
16、测试、可靠全性测试、压力测试、可靠全性测试、压力测试、可靠全性测试、压力测试、可靠性测试、安装性测试、安装性测试、安装性测试、安装/反安装测试反安装测试反安装测试反安装测试 验收测试验收测试验收测试验收测试需求文档需求文档需求文档需求文档由用户执行黑盒测试由用户执行黑盒测试由用户执行黑盒测试由用户执行黑盒测试 第16页，共112页，编辑于2022年，星期六黑盒测试与白盒测试的比较测试方式特征依据测试人员测试驱动程序黑盒测试只关心软件的外部表现，不关心内部设计与实现。软件需求任何人（包括开发人员、独立测试人员和用户）一般无需编写额外的测试驱动程序白盒测试关注软件的内部设计与实现，要跟踪源代码的运
17、行。设计文档由开发人员兼任测试人员的角色需要编写额外的测试驱动程序第17页，共112页，编辑于2022年，星期六l l问题1：有了“黑盒”测试为什么还要“白盒”测试？l l黑黑盒盒测测试试只只能能观观察察软软件件的的外外部部表表现现，即即使使软软件件的的输输入入输输出出都都是是正正确确的的，却却并并不不能能说说明明软软件件就就是是正正确确的的。因因为为程程序序有有可可能能用用错错误误的的运运算算方方式式得得出出正正确确的的结结果果，例例如如“负负得正，错错得对负负得正，错错得对”，只有白盒测试才能发现真正的原因。，只有白盒测试才能发现真正的原因。l l白盒测试能发现程序里的隐患，象内存泄漏、误
18、差累计问题。在这方面，黑盒测试存白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。在严重的不足。l l问题2：由于单元测试要写测试驱动程序，非常麻烦，能否等到整个系统全部开发完后，再集中精力进行一次性地单元测试呢？l l如果这样做，在开发过程中，缺陷会越积越多并且分布得更广、隐藏得更深，如果这样做，在开发过程中，缺陷会越积越多并且分布得更广、隐藏得更深，反而导致测试与改错的代价大大增加。最糟糕的是无法估计测试与改错的工反而导致测试与改错的代价大大增加。最糟糕的是无法估计测试与改错的工作量，使进度失去控制。因此为图眼前省事而省略单元测试或者作量，使进度失去控
19、制。因此为图眼前省事而省略单元测试或者“偷工减料偷工减料”，是，是“得不偿失得不偿失”的做法。的做法。l l问题3：如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？集成测试是否多此一举？l l要要把把N N个个单单元元集集成成一一起起肯肯定定靠靠接接口口耦耦合合，这这时时可可能能会会产产生生在在单单元元测测试试中中无无法法发发现现的的问问题题。例例如如：数数据据通通过过不不同同的的接接口口时时可可能能出出错错；几几个个函函数数关关联联在在一一起起时时可可能能达达不不到到预预期期的的功功能能；在在某某个个单单元元里里可可以以接接受受的的误误差差可可能能在在集集成成后后被被扩扩大大到到
20、无无法法接接受受的程度。所以集成测试是必要的，不是多此一举。的程度。所以集成测试是必要的，不是多此一举。第18页，共112页，编辑于2022年，星期六l l问题4：在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试?l l不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系统。再者，单元测试和集不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系统。再者，单元测试和集成测试通常由开发小组执行。根据测试心理学的分析，开发人员测试自己的工作成果虽然是成测试通常由开发小组执行。根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的
21、，但不能作为成果已经通过测试的依据。必要的，但不能作为成果已经通过测试的依据。l l问题5：既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？l l首先是首先是“信任信任”问题。对于合同项目而言，如果测试小组是开发方的人员，客户怎问题。对于合同项目而言，如果测试小组是开发方的人员，客户怎么能够轻易相信么能够轻易相信“别人别人”呢呢?所以当项目进行系统测试之后，客户再进行验收测试所以当项目进行系统测试之后，客户再进行验收测试是情理之中的事。否则，那是客户失职。是情理之中的事。否则，那是客户失职。l l不论是合同项目还是非合同项目，软件的最终用户各色各样（如受教育程度不同、不论是合同项
22、目还是非合同项目，软件的最终用户各色各样（如受教育程度不同、使用习惯不同等等）。测试小组至多能够模仿小部分用户的行为，但并不具有普遍使用习惯不同等等）。测试小组至多能够模仿小部分用户的行为，但并不具有普遍的代表性。的代表性。l l问题6：能否将系统测试和验收测试“合二为一”？l l系系统统测测试试不不是是一一会会儿儿就就能能做做完完的的，比比较较长长时时间间的的用用户户测测试试很很难难组组织织。用用户户还还有有自自己己的的事事情情要要做做，他他们们为为什什么么要要为为别别人人测测试试呢呢？即即使使用用户户愿愿意意做做系系统统测测试试，他他们消耗的时间、花费的金钱大多比测试小组的高。们消耗的时间
23、、花费的金钱大多比测试小组的高。l l系统测试时会找出相当多的软件缺陷，软件需要反反复复地改错。如果让用户发现系统测试时会找出相当多的软件缺陷，软件需要反反复复地改错。如果让用户发现“内幕内幕”，一是丢脸，二是会吓跑买主。所以还是关起门来，先让测试小组做完系统测试的好。，一是丢脸，二是会吓跑买主。所以还是关起门来，先让测试小组做完系统测试的好。第19页，共112页，编辑于2022年，星期六l l回归测试回归测试l l回归测试是指对某些已经被测试过的内容进行重新测试。每当软件增加了新的功能，或者软件中的缺陷被修正，这些变更都有可能影响软件原有的功能和结构。为了防止软件的变更产生无法预料的副作用，
24、不仅要对新内容进行测试，还要对某些老内容进行回归测试。第20页，共112页，编辑于2022年，星期六测试人员的组织l l了解开发人员的测试心理了解开发人员的测试心理l l测试的目的是找出尽可能多的缺陷。所以测试是测试的目的是找出尽可能多的缺陷。所以测试是“破坏性破坏性”的，而开发却是的，而开发却是“建设性建设性”的。开发人员总是喜欢欣赏程序的成功之处，而不愿看到失败之处。让开发者去做的。开发人员总是喜欢欣赏程序的成功之处，而不愿看到失败之处。让开发者去做“蓄意破坏蓄意破坏”的测试，就象杀自己的孩子一样难以接受。的测试，就象杀自己的孩子一样难以接受。l l开发者对自己的程序印象深刻，并总以为是正
25、确的（自信是应该的）。倘若在设计时就开发者对自己的程序印象深刻，并总以为是正确的（自信是应该的）。倘若在设计时就存在理解错误，或因不良的编程习惯而流下了隐患，他本人很难发现这类错误存在理解错误，或因不良的编程习惯而流下了隐患，他本人很难发现这类错误.l l开发者对自己的程序的功能、接口十分熟悉，他自己几乎不可能因为使用不当开发者对自己的程序的功能、接口十分熟悉，他自己几乎不可能因为使用不当而引发错误，这与大众用户的情况不太相似，所以测试自己的程序不具备典型而引发错误，这与大众用户的情况不太相似，所以测试自己的程序不具备典型性。性。l l结论：结论：结论：结论：开发人员应当测试自己的程序，这是他
26、分内的工作。但是开发人员在开发人员应当测试自己的程序，这是他分内的工作。但是开发人员在测试自己的程序时，很难做到客观、公正，所以自我测试不具有说服力。测试自己的程序时，很难做到客观、公正，所以自我测试不具有说服力。第21页，共112页，编辑于2022年，星期六l l如何组织测试人员：应当视企业的人力资源而定如何组织测试人员：应当视企业的人力资源而定l l条条件件特特别别好好的的公公司司，可可以以为为每每一一个个开开发发人人员员分分配配一一名名独独立立的的测测试试人人员员。这这样样的的测测试试人人员员职职业业化化程程度度很很高高，可可以以完完成成单单元元测测试试、集集成成测测试试和和系系统统测测
27、试试工作，能够实现开发与测试同步进行。工作，能够实现开发与测试同步进行。l l条条件件比比较较好好的的公公司司，可可以以设设置置一一个个独独立立的的测测试试小小组组，该该测测试试小小组组轮轮流流参参加加各各个个项项目目的的系系统统测测试试。而而单单元元测测试试、集集成成测测试试工工作作由由项项目目的的开开发发小小组组承担。承担。l l条条件件一一般般的的公公司司，养养不不起起独独立立的的测测试试小小组组。单单元元测测试试、集集成成测测试试工工作作由由项项目目开开发发小小组组承承担担。当当项项目目进进展展到到系系统统测测试试阶阶段段，可可以以从从项项目目外外抽抽调调一一些些人人员员，加加上上开开
28、发发人人员员，临时组织系统测试小组。临时组织系统测试小组。l l条条件件比比较较差差的的公公司司，也也许许只只有有一一个个项项目目和和为为数数不不多多的的一一些些开开发发人人员员。那那么么就就让让开开发发人人员员一一直直兼兼任任测测试试人人员员的的角角色色，相相互互测测试试对对方方的的程程序序。如如果果人人员员实实在在太太少少了了，只只好好让开发者测试自己的程序，有测试总比没有测试好吧！让开发者测试自己的程序，有测试总比没有测试好吧！第22页，共112页，编辑于2022年，星期六l l避免开发人员与测试人员产生矛盾避免开发人员与测试人员产生矛盾避免开发人员与测试人员产生矛盾避免开发人员与测试人
29、员产生矛盾l l开发人员不能很好地测试自己的程序是因为做不到开发人员不能很好地测试自己的程序是因为做不到“无情无情”。但如果测试人员真的做到了。但如果测试人员真的做到了“无情无情”却会引起开发人员的愤怒，遭人白眼。由于开发与测试存在却会引起开发人员的愤怒，遭人白眼。由于开发与测试存在“对立对立”关系，开发人员与测试人员很关系，开发人员与测试人员很容易产生矛盾，这对项目而言是一种伤害。容易产生矛盾，这对项目而言是一种伤害。l l开发人员的注意事项：开发人员的注意事项：（1 1）不要敌视测试人员。要理解测试的目的就是发现缺陷，是测试人员的工作职责。不要以为测试人员）不要敌视测试人员。要理解测试的目
30、的就是发现缺陷，是测试人员的工作职责。不要以为测试人员吃饱了没事干，存心找茬。吃饱了没事干，存心找茬。（2 2）不要轻视测试人员，别说人家技术水平差，不配搞开发只好搞测试。）不要轻视测试人员，别说人家技术水平差，不配搞开发只好搞测试。l l测试人员的注意事项：测试人员的注意事项：（1 1）发现缺陷时不要嘲笑开发人员，别说他的程序真臭、到处是）发现缺陷时不要嘲笑开发人员，别说他的程序真臭、到处是BugBug。（2 2）在开发人员压力太大时或心情不好时不要火上浇油，发现缺陷时别大声嚷嚷。）在开发人员压力太大时或心情不好时不要火上浇油，发现缺陷时别大声嚷嚷。l l尽量不要相互讽刺对方，例如：尽量不要
31、相互讽刺对方，例如：l lA A对对B B说：你唯一的特点就是无能。说：你唯一的特点就是无能。l lB B对对A A说：你唯一的特点就是粗鲁。说：你唯一的特点就是粗鲁。l l还要注意的是，如果测试人员与开发人员的关系非常好，可能会导致在测试的时候还要注意的是，如果测试人员与开发人员的关系非常好，可能会导致在测试的时候还要注意的是，如果测试人员与开发人员的关系非常好，可能会导致在测试的时候还要注意的是，如果测试人员与开发人员的关系非常好，可能会导致在测试的时候“手手手手下留情下留情下留情下留情”，这对项目也是一种伤害。，这对项目也是一种伤害。，这对项目也是一种伤害。，这对项目也是一种伤害。第23
32、页，共112页，编辑于2022年，星期六企业的测试策略l l理念：l l企业的主要目的是获取利润，降低测试成本也是盈利的一种方式。企业的主要目的是获取利润，降低测试成本也是盈利的一种方式。l l用较低的代价实现有效的测试，不应为了追求完美的测试而不失一切代价。用较低的代价实现有效的测试，不应为了追求完美的测试而不失一切代价。l l如何合理地减少测试工作量l l减少冗余的测试减少冗余的测试l l白盒测试与黑盒测试的方式虽然不同，但往往有白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工异曲同工”之妙。在很多地方，白盒测试与之妙。在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来
33、），这样的测试是冗余的。黑盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。l l在集成测试、系统测试阶段，可能要执行多次在集成测试、系统测试阶段，可能要执行多次“回归测试回归测试”。每一次。每一次“回归测试回归测试”都会都会存在不少的冗余，应当设法剔除不必要的重复测试工作。存在不少的冗余，应当设法剔除不必要的重复测试工作。l l减少无价值的测试减少无价值的测试l l无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来只要测试一无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来只要测试一个典型的输入就行了，如果有人在此区间测
34、试了个典型的输入就行了，如果有人在此区间测试了100100次，那么其中次，那么其中9999次就是无价值的。次就是无价值的。l l如何如何“偷工减料偷工减料”l l有有一一些些“短短、平平、快快”的的项项目目，经经费费本本来来就就少少，用用户户对对质质量量要要求求也也马马马马虎虎虎虎。为为了了能能多多挣挣一一点点钱钱，开开发发方方不不得得不不采采用用“偷偷工工减减料料”的的方方式式来来降降低低测测试试代代价价。偷偷工工减减料料的的途途径径无无非非就就是是减减少少测测试试的的内内容容和和频频度度。但但不不能能砍砍得得太太狠狠，否否则则软软件件拿拿不不出出手手。基基本本方方法法是是找找出出软软件件中
35、中需需要要优优先先测测试试的的部部分分，其它次要部分可以忽略或将来再测试。其它次要部分可以忽略或将来再测试。第24页，共112页，编辑于2022年，星期六l l“偷工减料”方法的测试优先级：l l哪些功能是软件的特色？哪些功能是软件的特色？l l哪些功能是用户最常用的？哪些功能是用户最常用的？l l如果系统可以分块卖的话，哪些功能块在销售时最昂贵？如果系统可以分块卖的话，哪些功能块在销售时最昂贵？l l哪些功能出错将导致用户不满或索赔？哪些功能出错将导致用户不满或索赔？l l哪些程序是最复杂、最容易出错的？哪些程序是最复杂、最容易出错的？l l哪些程序是相对独立，应当提前测试的？哪些程序是相对
36、独立，应当提前测试的？l l哪些程序最容易扩散错误？哪些程序最容易扩散错误？l l哪些程序是全系统的性能瓶颈所在？哪些程序是全系统的性能瓶颈所在？l l哪些程序是开发者最没有信心的？哪些程序是开发者最没有信心的？l l第25页，共112页，编辑于2022年，星期六l l测试何时结束？测试何时结束？测试何时结束？测试何时结束？l l一、基于测试用例的规则一、基于测试用例的规则一、基于测试用例的规则一、基于测试用例的规则l l（1 1）先构造测试用例（并请有关人员进行评审）。）先构造测试用例（并请有关人员进行评审）。l l（2 2）在测试过程中，当测试用例的不通过率达到）在测试过程中，当测试用例的
37、不通过率达到2020时，则拒绝继续测试，待开发人员修正软件时，则拒绝继续测试，待开发人员修正软件后再进行测试。后再进行测试。l l（3 3）当功能性测试用例通过率达到）当功能性测试用例通过率达到100100，非功能性测试用例通过率达到，非功能性测试用例通过率达到9090时，允许正常时，允许正常结束测试。结束测试。l l该规则的优点是适用于所有的测试阶段，缺点是太依赖于测试用例。如果测试用该规则的优点是适用于所有的测试阶段，缺点是太依赖于测试用例。如果测试用例非常糟糕，那么该规则就失效了。例非常糟糕，那么该规则就失效了。l l二、基于二、基于二、基于二、基于“测试期缺陷密度测试期缺陷密度测试期缺
38、陷密度测试期缺陷密度”的规则的规则的规则的规则l l把测试一个把测试一个CPUCPU小时发现的缺陷数称为小时发现的缺陷数称为“测试期缺陷密度测试期缺陷密度”。绘制。绘制“测试时间缺陷数测试时间缺陷数”的关系图，如果在相邻的关系图，如果在相邻n n个个CPUCPU小时内小时内“测试期缺陷密度测试期缺陷密度”全部低于某个值全部低于某个值mm时，则允时，则允许正常结束测试。例如许正常结束测试。例如n n大于大于1010，mm小于等于小于等于1 1。该规则比较适用于系统测试阶段。该规则比较适用于系统测试阶段。l l三、基于三、基于三、基于三、基于“运行期缺陷密度运行期缺陷密度运行期缺陷密度运行期缺陷密
39、度”的规则的规则的规则的规则l l把软件运行一个把软件运行一个CPUCPU小时发现的缺陷数称为小时发现的缺陷数称为“运行期缺陷密度运行期缺陷密度”。绘制。绘制“运行时间缺运行时间缺陷数陷数”的关系图，如果在相邻的关系图，如果在相邻n n个个CPUCPU小时内小时内“运行期缺陷密度运行期缺陷密度”全部低于某个值全部低于某个值mm时，时，则允许正常结束测试。例如则允许正常结束测试。例如n n大于大于100100，mm小于等于小于等于1 1。该规则比较适用于验收测试阶段，。该规则比较适用于验收测试阶段，即客户试运行软件期间。即客户试运行软件期间。第26页，共112页，编辑于2022年，星期六l l需
40、求经常变更怎么办需求经常变更怎么办需求经常变更怎么办需求经常变更怎么办l l需求变更可能会让项目所有成员遭殃，如何需求变更可能会让项目所有成员遭殃，如何“预防变更预防变更”以及以及“降低变更的代价降低变更的代价”是软件工是软件工程的经典问题。本节仅论述需求变更对测试的影响。程的经典问题。本节仅论述需求变更对测试的影响。l l需求变更将导致软件设计和实现的变更，也导致了测试变更。最让人难过的是上一次测试有可能白需求变更将导致软件设计和实现的变更，也导致了测试变更。最让人难过的是上一次测试有可能白做了，如果软件变更比较大的话。做了，如果软件变更比较大的话。l l测试人员不要只是自认倒霉，应当主动作
41、些应变：测试人员不要只是自认倒霉，应当主动作些应变：l l（1 1）及时了解需求变更的详细情况，尽早调整测试计划，不要闷头按原计划测试。）及时了解需求变更的详细情况，尽早调整测试计划，不要闷头按原计划测试。l l（2 2）将软件中稳定的部分与易变的部分区别对待，前者先测试，后者后测试。）将软件中稳定的部分与易变的部分区别对待，前者先测试，后者后测试。l l（3 3）向领导反映需求变更对测试造成的影响，为自己争取余地。）向领导反映需求变更对测试造成的影响，为自己争取余地。l l（4 4）设计一些比较灵活的测试用例，能适应某些变更（不过技术难度比较高）。）设计一些比较灵活的测试用例，能适应某些变更
42、（不过技术难度比较高）。l l引申问题：如果在系统测试时，对照需求文档，发现软件多了功能或少了功能，该引申问题：如果在系统测试时，对照需求文档，发现软件多了功能或少了功能，该怎么办？怎么办？l l如果发现软件少了功能，测试人员不可为了少干些活而隐瞒事实。如果发现软件多了功如果发现软件少了功能，测试人员不可为了少干些活而隐瞒事实。如果发现软件多了功能，测试人员不可认为这些功能反正是能，测试人员不可认为这些功能反正是“锦上添花锦上添花”，便自作主张地测试了事。两种情，便自作主张地测试了事。两种情况都要报告给项目经理，有可能导致一系列的变更。况都要报告给项目经理，有可能导致一系列的变更。第27页，共
43、112页，编辑于2022年，星期六测试规范l l测试流程l l第一步：制定测试计划。该计划被批准后转向第二步。第一步：制定测试计划。该计划被批准后转向第二步。l l第二步：设计测试用例。该用例被批准后转向第三步。第二步：设计测试用例。该用例被批准后转向第三步。l l第三步：如果满足第三步：如果满足“启动准则启动准则”，那么执行测试。，那么执行测试。l l第四步：撰写测试报告。第四步：撰写测试报告。l l第五步：消除软件缺陷。如果满足第五步：消除软件缺陷。如果满足“完成准则完成准则”，那么正常结束测试。，那么正常结束测试。制定测试计划设计测试用例执行测试写测试报告消除软件缺陷审批审批回归测试完成
44、测试完成准则启动准则第28页，共112页，编辑于2022年，星期六测试的信息流l l测试信息流如下图所示：第29页，共112页，编辑于2022年，星期六软件测试的策略l l在软件工程中，测试过程应该按在软件工程中，测试过程应该按在软件工程中，测试过程应该按在软件工程中，测试过程应该按4 4个步骤进行，即单元测试、个步骤进行，即单元测试、个步骤进行，即单元测试、个步骤进行，即单元测试、组装（集成）测试、确认测试和系统测试。下图给出了软件测试组装（集成）测试、确认测试和系统测试。下图给出了软件测试组装（集成）测试、确认测试和系统测试。下图给出了软件测试组装（集成）测试、确认测试和系统测试。下图给出
45、了软件测试经历的经历的经历的经历的4 4个步骤。个步骤。个步骤。个步骤。第30页，共112页，编辑于2022年，星期六测试规范l l测试启动准则测试启动准则l l同时满足以下条件，允许开始测试：同时满足以下条件，允许开始测试：l l（1 1）测试计划已经制定并且通过了审批；）测试计划已经制定并且通过了审批；l l（2 2）测试用例已经设计并且通过了审批；）测试用例已经设计并且通过了审批；l l（3 3）被测试对象已经开发完毕并等待测试。）被测试对象已经开发完毕并等待测试。l l 测试完成准则测试完成准则l l对对于于非非严严格格系系统统可可以以采采用用“基基于于测测试试用用例例”的的准准则则。
46、同同时时满满足足以以下下条条件件允允许结束测试：许结束测试：l l（1 1）功能性测试用例通过率达到）功能性测试用例通过率达到100100；l l（2 2）非功能性测试用例通过率达到）非功能性测试用例通过率达到9090时。时。l l对于严格系统，应当补充对于严格系统，应当补充“基于测试期缺陷密度基于测试期缺陷密度”的规则：的规则：l l（3 3）相邻）相邻n n个个CPUCPU小时内小时内“测试期缺陷密度测试期缺陷密度”全部低于某个值全部低于某个值m m。例如。例如n n大于大于1010，m m小于等于小于等于1 1。第31页，共112页，编辑于2022年，星期六测试的文档l l测试计划：指明
47、范围、方法、资源，以及相应测试活动的时间进度安排表的文档。l l测试方案：指明为完成软件或软件集成特性的测试而进行的设计测试方法的细节文档。l l测试用例：指明为完成一个测试项的测试输入、预期结果、预期执行条件等因素的文档。l l测试规程：指明执行测试时测试活动序列的文档。l l测试报告：指明执行测试结果的文档。第32页，共112页，编辑于2022年，星期六测试计划的参考模板第33页，共112页，编辑于2022年，星期六建立测试计划l l定义测试目标定义测试目标l l开发测试矩阵开发测试矩阵l l软件模型软件模型l l结构特性结构特性l l批量测试的阶段和用例批量测试的阶段和用例l l为在线系
48、统作概念上的测试脚本为在线系统作概念上的测试脚本l l软件测试矩阵软件测试矩阵l l定义测试管理定义测试管理l l测试计划的一般性信息测试计划的一般性信息l l定义测试里程碑定义测试里程碑l l定义管理上的检查点定义管理上的检查点l l书写测试计划书写测试计划第34页，共112页，编辑于2022年，星期六评审测试计划l l涉及评审的问题涉及评审的问题l l评审测试的开始时间是否会延期评审测试的开始时间是否会延期l l有没有抵触评审的角色有没有抵触评审的角色l l一段时间内是否很难得到工作的检查信息。一段时间内是否很难得到工作的检查信息。l l更换工具有可能导致他们反感评审工作更换工具有可能导致
49、他们反感评审工作l l评审结果可能会影响对个人的工作评价评审结果可能会影响对个人的工作评价l l对于最终成品的检查对于最终成品的检查l l项目的需求规格说明书项目的需求规格说明书l l软件返工软件返工/维护的文档维护的文档l l升级后的技术文档升级后的技术文档l l被更改的源程序被更改的源程序l l测试计划测试计划l l用户手册（包括在线帮助）用户手册（包括在线帮助）第35页，共112页，编辑于2022年，星期六测试用例测试用例的基本要素有：目的、前提条件、输入数据或动作、期望的响应。第36页，共112页，编辑于2022年，星期六建议测试方法l l测试方法测试方法l l测试用例的概念是简单的测
50、试用例的概念是简单的l l建立有效的测试用例是复杂的建立有效的测试用例是复杂的l l设计测试文件设计测试文件l l测试用例应当包含合法的和非法的输入测试用例应当包含合法的和非法的输入l l每一个动作只进行一次关键操作每一个动作只进行一次关键操作l l输入测试数据输入测试数据l l分析结果分析结果l l尝试将测试文件违反程序的规则进行输入尝试将测试文件违反程序的规则进行输入l l压力测试的测试工具压力测试的测试工具l l以大信息量的数据进行输入以大信息量的数据进行输入l l这是一个昂贵的测试，应根据需要来选择这是一个昂贵的测试，应根据需要来选择l l在线系统需要做压力测试在线系统需要做压力测试第