软件测试概述

1、1 1软件测试概述软件测试概述l软件测试的发展软件测试的发展l软件测试的定义软件测试的定义l软件测试的目的和对象软件测试的目的和对象l软件测试的分类软件测试的分类l软件测试误区和原则软件测试误区和原则l软件测试生命周期软件测试生命周期l测试员应有的素质测试员应有的素质软件测试的发展软件测试的发展 故事发生在故事发生在1945年年9月的一天，一个炎热的下午，机房是一间第月的一天，一个炎热的下午，机房是一间第一次世界大战时建造的老建筑，没有空调，所有窗户都敞开着。一次世界大战时建造的老建筑，没有空调，所有窗户都敞开着。Hopper正领着她的研究小组夜以继日地工作，研制一台称为正领着她的研究小组夜以

2、继日地工作，研制一台称为“MARK II”的计算机，它使用了大量的继电器（电子机械装置，的计算机，它使用了大量的继电器（电子机械装置，那时还没有使用晶体管），一台不是纯粹的电子计算机。突然，那时还没有使用晶体管），一台不是纯粹的电子计算机。突然，MARK II死机了。研究人员试了很多次还是启动不来，然后就开死机了。研究人员试了很多次还是启动不来，然后就开始用各种方法找问题，看问题究竟出现在哪里，最后定位到板子始用各种方法找问题，看问题究竟出现在哪里，最后定位到板子F第第70号继电器出错。号继电器出错。Hopper观察这个出错的继电器，惊奇地发观察这个出错的继电器，惊奇地发现一只飞蛾躺在中间，已

3、经被继电器打死。她小心地用摄子将蛾现一只飞蛾躺在中间，已经被继电器打死。她小心地用摄子将蛾子夹出来，用透明胶布帖到子夹出来，用透明胶布帖到“事件记录本事件记录本”中，并注明中，并注明“第一个第一个发现虫子的实例发现虫子的实例”，然后计算机又恢复了正常。从此以后，人们，然后计算机又恢复了正常。从此以后，人们将计算机错误戏称为臭虫（将计算机错误戏称为臭虫（Bug），而把找寻错误的工作称为），而把找寻错误的工作称为“找臭虫找臭虫”（Debug）。）。Grace Hopper的事件记录本，连同那的事件记录本，连同那个飞蛾，现在都陈列在美国历史博物馆中。个飞蛾，现在都陈列在美国历史博物馆中。 软件测试的

4、发展软件测试的发展4 4软件测试的发展软件测试的发展l早期的软件开发过程中，软件规模小、复杂程度低，软件开发的过程混乱无序、测试的含义比较狭窄，开发人员将测试等同于“调试”。l1957年，软件测试开始与调试相区别，作为一种发现软件缺陷的活动。但测试活动始终后于开发的活动，测试通常被做为软件生命周期中最后一项活动而进行。当时也缺乏有效的测试方法，主要依靠“错误推测 Error Guessing”来寻找软件中的缺陷。因此，大量软件交付后，仍存在很多问题，软件产品的质量无法保证。l20世纪70年代，人们开始思考软件开发流程的问题，“软件测试” 这一词条已频繁出现，一些软件测试的探索者们建议在软件生命

5、周期的开始阶段就根据需求制订测试计划，这时涌现出一批软件测试大师，Bill Hetzel 博士就是其中的领导者。 软件测试的发展5 5软件测试的发展软件测试的发展l1972年6月，Bill Hetzel（代表论著The Complete Guide to Software Testing）在美国的北卡罗来纳（North Carolina）大学组织了首次以软件测试为主题的会议。l1973年，Bill Hetzel给软件测试一个这样的定义：“就是建立一种信心，认为程序能够按预期的设想运行（Establish confidence that a program does what it is sup

6、posed to do）”。 这里，“设想” 其实就是我们现在所说的用户需求或功能设计。软件测试的发展软件测试的发展软件测试的发展l1983年，Bill Hetzel又将定义修订为：“评价一个程序和系统的特性或能力，并确定它是否达到预期的结果。软件测试就是以此为目的的任何行为（Any activities aimed at evaluating an attribute or capability of a program or system）”。l在他定义中的“预期的结果”其实就是我们现在所说的用户需求或功能设计。他还把软件的质量定义为“符合要求”。l他思想的核心观点是：测试方法是试图验证软

7、件是他思想的核心观点是：测试方法是试图验证软件是“工作工作的的”。所谓“工作的”就是指软件的功能是按照预先的设计执行的，以正向思维，针对软件系统的所有功能点，逐个验证其正确性。软件测试业界把这种方法看作是的软件测试的第一类方法。67 7软件测试的发展软件测试的发展l这一方法还是受到很多业界权威的质疑和挑战。代表人物是Glenford J. Myers。l1979年，Glenford Myers发表的The Art of Software Testing是软件测试方面的圣经。Myers定义及诠释的测试方法论已成为软件测试的基本模块。提出测试的目的是证伪。l业界把这看作是软件测试的第二类方法，简单

8、地说就是验证软件是验证软件是“不工作的不工作的”，或者说是有错，或者说是有错误的。误的。软件测试的发展软件测试的发展软件测试的发展l1983年IEEE提出的软件工程术语中给软件测试下的定义是：“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。这个定义明确指出：软件测试的目的是为了检验软件系统是否满足需求。它再也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。软件测试已成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。89 9软件测试的发展软件测试的发展l1990年的IEEE/AN

9、SI标准将软件测试进行了这样的定义：“就是在既定的状况条件下，运行一个系统或组建，观察记录结果，并对其某些方面进行评价的过程。The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component (IEEE/ANSI, 1990 Std 610.12-1990)”这里所谓“既定的状况”也可理解为需求或设计。软件测

10、试的发展1010软件测试的发展软件测试的发展l从80年代中后期开始，软件生产进入以个体软件过程PSP(Personal Software Process)、过程成熟度模型CMM和群组软件过程TSP(Team Software Process)为标志的、以过程为中心的第二阶段。但CMM 没有充分的定义软件测试，没有提及测试成熟度的概念，没有对测试过程改进进行充分说明，对于如何有效提高机构的测试能力和水平没有提供相应指导。为此，许多研究机构和测试服务机构从不同角度出发，提出有关软件测试方面的能力成熟度模型，作为SEI-CMM的有效补充。软件测试的发展软件测试的发展软件测试的发展l1996年提出：l

11、测试支持度TSM（Testing Support Model）：评估测试小组所处环境对于他们的支持程度。l测试成熟度（Testing Maturity Model）。由Burnstein博士提出，依据CMM的框架提出测试的5个不同级别，关注于测试的成熟度模型。它描述了测试过程，是项目测试部分得到良好计划和控制的基础。11软件测试的发展软件测试的发展TMM 测试成熟度分解为 5 级别：l1级(初始级)：测试过程无序，有时甚至是混乱的，几乎没有妥善定义。 测试和调试没有区别，除支持调试外，测试没有其他目的。 l2级(定义级)： 测试被定义为软件生命周期中的一个阶段，在编码阶段之后。l3级(集成级)

12、： 测试与软件生命周期融（集成）为一体。l4级(管理和测量级)：测试活动除测试被测程序外，还包括软件生命周期中各个阶段的评审，审查和追查，使测试活动涵盖了软件验证和软件确认活动。l5级(优化，预防缺陷和质量控制级)：优化调整和持续改进测试过程。 测试过程的管理为持续改进产品质量和过程质量提供指导，并提供必要的基础设施。121313软件测试的发展软件测试的发展l软件测试发展趋势l测试与质量保证体系的融合l测试方法越来越细分测试方法的细分，如网站测试、安全性测试等；l测试技术不断发展l软件验证技术方面l软件静态测试方面l测试用例的选择方面l自动化测试方面l测试走向专业化道路软件测试的发展1414广

13、义软件测试的定义广义软件测试的定义软件测试是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，其目的是尽快尽早地发现在软件产品中所存在的各种问题与用户需求、预先定义的不一致性。 软件测试的定义1515广义软件测试的定义广义软件测试的定义l确认确认l评估将要开发的软件产品是否正确无误、可行和有价值的。l确认意味着确保一个待开发软件是正确无误的，是对软件开发构想的检测。l验证验证l检测软件开发的每个阶段、每个步骤的结果是否正确无误，是否与软件开发各阶段的要求或期望的结果相一致。l验证意味着确保软件会正确无误地实现软件的需求，开发过程是沿着正确的方向进行的。软件测试的定

14、义1616软件测试的对象软件测试的对象软件测试的定义软件测试目的软件测试目的l发现软件缺陷软件缺陷l发现软件缺陷，尽可能早一些l发现软件缺陷，尽可能早一些，并确保其得以修复，从而提高软件产品质量软件产品质量1818软件测试的分类软件测试的分类l按测试过程 （开发阶段）l单元测试单元测试：又称模块测试，是针对软件设计的最小单位程序模块进行正确性检验的测试工作。l集成测试集成测试：又称组装测试，是将模块按照设计要求组装起来进行测试，主要目标是发现与接口有关的问题。l确认测试确认测试：验证软件的功能和性能及其它特性是否与用户的要求一致。l系统测试系统测试：是在集成测试通过后进行，目的是充分运行系统，

15、验证各子系统是否都能正常工作并完成设计的要求。 l验收测试验收测试：用户为主，开发人员参与，以规格说明书为蓝本的测试。Class Amethod mA1()method mA2()Class Bmethod mB1()method mB2()main Class Pn验收测试:由用户执行系统进行测试n集成测试: 测试模块之间的交互n单元测试: 测试单个类，文件，模块或组件n系统测试:测试系统所有功能和非功能是否满足需求软件测试的分类软件测试的分类2020软件测试的分类软件测试的分类 被测模块 设 软 系统 客 计 件 其他 户 信 需 元素 参 息 求 与 被测模块 被测模块 单元测试 单元测

16、试 单元测试 集成测试 确认测试 系统测试 验收测试 已 经 测试 过 的模块 已集成的软件 已确认的软件 可交付的软件 2121软件测试的分类软件测试的分类l按测试用例设计方法l白盒测试白盒测试也称结构测试或逻辑驱动测试，它是从程序的控制结构出发进行的测试，测试程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。l黑盒测试黑盒测试又称功能测试、数据驱动测试或基于规格说明书的测试，是一种从用户观点出发的测试，在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。l灰盒测试灰盒测试是介于白盒测试与黑盒测试之间的测试，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这

17、种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。白盒测试和黑盒测试白盒测试和黑盒测试功能测试功能测试数据驱动测试数据驱动测试 结构测试结构测试逻辑驱动测试逻辑驱动测试 客户需求事件驱动输入输出23软件测试的分类软件测试的分类l按执行方式l人工测试人工测试：手工执行的测试；l自动化测试自动化测试：希望能够通过自动化测试工具或其他手段,按照测试工程师的预定计划进行自动的测试。如：负载测试、性能测试、可靠性测试等。2324软件测试的分类软件测试的分类l按程序的执行方式划分l静态测试静态测试静态测试方法的主要特征是在用计算机测试源程序时，计算机并不真正运行被测试

18、的程序，只对被测程序进行特性分析。因此，静态测试常称为“分析”，静态分析是对被测程序进行特性分析的一些方法的总称。l动态测试动态测试动态测试方法的主要特征是计算机必须真正运行被测试的程序，通过输入测试用例，对其运行情况(输入/输出的对应关系)进行分析。 242525软件测试的分类软件测试的分类l按测试目的划分l功能测试功能测试l性能测试性能测试l易用性测试易用性测试l完全性测试完全性测试l安装测试安装测试l文档测试文档测试l软件测试误区软件测试误区p 误区一：如果发布出去的软件有质量问题，都是软件测试误区一：如果发布出去的软件有质量问题，都是软件测试人员的错人员的错p 误区二：软件测试技术要求

19、不高，至少比编程容易多了误区二：软件测试技术要求不高，至少比编程容易多了p 误区三：有时间就多测试一些，来不及就少测试一些误区三：有时间就多测试一些，来不及就少测试一些 p 误区四：软件测试是测试人员的事，与开发人员无关误区四：软件测试是测试人员的事，与开发人员无关 p 误区五：根据软件开发瀑布模型，软件测试是开发后期的误区五：根据软件开发瀑布模型，软件测试是开发后期的一个阶段一个阶段软件测试原则软件测试原则l尽早和不断地测试尽早和不断地测试 l所有的测试都应追溯到用户需求所有的测试都应追溯到用户需求l最严重的错误(从用户角度)是那些导致软件无法满足需求的错误。l程序中的问题根源可能在开发 前

20、期的各阶段解决、纠正错误也必须追溯到前期工作。l并非所有软件缺陷都能修复并非所有软件缺陷都能修复不需要修复软件缺陷的原因：l没有足够的时间l不算真正的软件缺陷l修复的风险太大l不值得修复软件测试原则软件测试原则l由独立的第三方或专门的测试小组进行独立测试由独立的第三方或专门的测试小组进行独立测试lPareto（帕雷托，意大利经济学家）原则（帕雷托，意大利经济学家）原则l20%的模块消耗80%的资源l20%的模块隐藏80%的错误l20%的错误消耗80%的修改成本l20%的模块占用了80%的执行时间l经验表明，测试后程序残存的错误数目与该程序中以发现的错误数目或检错率成正比。应该对错误群集的程序段

21、进行重点测试。l完全测试是不可能的，测试需要设置终止条件完全测试是不可能的，测试需要设置终止条件2929软件测试的原则软件测试的原则软软件件缺缺陷陷故故障障数数量量测试工作量测试工作量测试中测试中测试后测试后测试费用测试费用遗漏缺陷数目遗漏缺陷数目优化测试量优化测试量图 测试工作量和软件缺陷数量之间的关系软件测试原则软件测试原则l制定严格的测试计划，并把测试时间安排得尽量宽制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测松，不要希望在极短的时间内完成一个高水平的测试。试。l回归测试的关联性一定要引起充分的注意，修改一回归测试的关联性一定要引起充分的注意，

22、修改一个错误而引起更多错误出现的现象并不少见。个错误而引起更多错误出现的现象并不少见。l妥善保存一切测试过程文档，意义是不言而喻的，妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档测试的重现性往往要靠测试文档软件测试生命周期软件测试生命周期软件测试生命周期软件测试生命周期测试条件、资源、进度和测试的优先级设计测试用例（确定怎么测试）测试开发（搭建环境、设计脚本、数据等）运行被测程序，执行测试分析测试结果评估测试完成情况测试计划测试计划确定测试需求确定测试需求根据需求收集和组织测试需求信息，确定测试需求制定测试策略制定测试策略针对测试需求定义测试类型、测试方法以及需要的测

23、试工具等。建立测试通过的准则建立测试通过的准则根据项目实际情况为每个层次测试建立通过标准确定资源和进度确定资源和进度确定测试需要的软硬件资源、人力资源以及测试进度评审测试计划评审测试计划根据同行评审的规范对测试计划进行同行评审测试设计测试设计对每个测试需求，确定所需的测试用例。对每个测试用例，确定其输入和预期结果。测试环境配置编写测试用例文档对测试用例进行同行评审测试用例定义测试用例定义为某个特殊目标而编制的一组测试输入、执行条件为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。个特定需求

24、。 测试用例测试用例l测试用例组成元素测试用例组成元素l测试用例组成元素l1.用例ID Test Case ID l2.用例名称 Test Case Namel3.测试目的 Test Objectivel4.测试级别 Test Level l5.参考信息 l6.测试环境 Test Environmentl7.前提条件 Prerequisites/Dependencies/Assumptionsl8.测试步骤 Test Steps/test scriptl9.预期结果 Expected Resultl10.设计人员 Designerl11.执行人员 Testerl12.实际的结果/测试的结果 A

25、ctual Result/Test resultl可能还有l13. 相关的需求和功能模块，需求描述 requirement descriptionl14. 测试数据 Test Datal15. 测试结果的状态（反应测试是否成功） Test case status (passed, failed, hold, attention; also case use colors)良好测试用例的特征良好测试用例的特征完整的完整的完整性是对测试用例最基本的要求，尤其是一些基本功能项上，完整性是对测试用例最基本的要求，尤其是一些基本功能项上，不应有遗漏。不应有遗漏。完整性还体现在临界测试、压力测试、性能测试

26、等方面，这方面完整性还体现在临界测试、压力测试、性能测试等方面，这方面测试用例也要能够涉及到。测试用例也要能够涉及到。2准确准确测试者按照测试用例的输入一步步测完后，要能根据测试用例描测试者按照测试用例的输入一步步测完后，要能根据测试用例描述的输出得出正确的结论述的输出得出正确的结论,不能出现模糊不清的语言。不能出现模糊不清的语言。3清晰、简洁清晰、简洁 好的测试用例描述清晰，每一步都应有相应的作用，有很强的针好的测试用例描述清晰，每一步都应有相应的作用，有很强的针对性，不应出现一些冗繁无用的操作步骤。对性，不应出现一些冗繁无用的操作步骤。测试用例不应太简单，也不能太过复杂，最大操作步骤最好控

27、制测试用例不应太简单，也不能太过复杂，最大操作步骤最好控制在在15步之内。步之内。良好测试用例的特征良好测试用例的特征5可维护性可维护性由于软件开发过程中需求变更等原因的影响，常常需要对测试由于软件开发过程中需求变更等原因的影响，常常需要对测试用例进行修改、增加、删除等，以便测试用例符合相应测试用例进行修改、增加、删除等，以便测试用例符合相应测试要求。测试用例应具备这方面的功能。要求。测试用例应具备这方面的功能。6适当性适当性测试例应该适合特定的测试环境以及符合整个团队的测试水平，测试例应该适合特定的测试环境以及符合整个团队的测试水平，如纯英语环境下的测试用例最好使用英文编写。如纯英语环境下的

28、测试用例最好使用英文编写。7可复用性可复用性要求不同测试者在同样测试环境下使用同样测试用例都能得出要求不同测试者在同样测试环境下使用同样测试用例都能得出相同结论。相同结论。8其他其他如可追朔性、可移植性也是对编写测试用例的一个要求。另外，如可追朔性、可移植性也是对编写测试用例的一个要求。另外，好的测试用例也是最有可能抓住错误的；不重复、多余的；是好的测试用例也是最有可能抓住错误的；不重复、多余的；是一组相似测试用例中最有效的；一组相似测试用例中最有效的；39测试用例设计概述测试用例设计概述l设计测试用例的基本准则l测试用例的代表性 能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越

29、界的以及极限的输入数据、操作和环境设置等。l测试结果的可判定性 即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。l测试结果的可再现性 即对同样的测试用例，系统的执行结果应当是相同的。40测试用例设计概述测试用例设计概述l设计测试用例的着眼点l根据产品规格，测试基本功能；l考虑设计一般用户（非专业人员）的使用方案；l考虑设计稀有或特殊的使用方案；l与系统其他组成部分的配合（如FAX和上网可能要用到MODEM，测试中考虑对设备的共享）；l考虑特殊情况（如内存和硬件的冲突等）；l设计极端情况（如内存泄漏、破坏性测试等）；好的测试用例集能花费最小的代价（人力、物力、财力、时间）做

30、最好的测试。41测试用例设计概述测试用例设计概述l测试用例的编写标准在ANSI/IEEE829-1983标准中列出了和测试设计相关的测试用例编写规范和模板。标准模板中主要元素如下：l标识符惟一标识每一个测试用例l测试项准确的描述所需要测试的项及其特征l测试环境要求表征执行该测试用例需要的测试环境l输入标准执行测试用例的输入需求（这些输入可能包括数据、文件或者操作）l输出标准按照指定的环境和输入标准得到的期望输出结果l测试用例之间的关联标识该测试用例与其它的测试（或其它测试用例）之间的依赖关系42测试用例设计概述测试用例设计概述l测试用例示例：对Windows记事本程序进行测试，选取其中的一个测

31、试项文件菜单栏的测试：测试对象记事本程序文件菜单栏 （测试用例标识10000，下同）所包含的子测试用例描述如下：|-文件/新建（1001）|-文件/打开（1002）|-文件/保存（1003）|-文件/另存为（1004）|-文件/页面设置（1005）|-文件/打印（1006）|-文件/退出（1007）选取其中的一个子测试用例文件/退出（1007）作为例子，测试用例如下表所示。 43字段名称描 述标识符1007测试项记事本程序，“文件”菜单栏中的“文件”|“退出”命令的功能测试测试环境要求Windows 2000 Professional 中文版输入标准(1) 打开记事本程序，不输入任何字符，单击

32、“文件”|“退出”命令(2) 打开记事本程序，输入一些字符，不保存文件，单击“文件”|“退出”命令(3) 打开记事本程序，输入一些字符，保存文件，单击“文件”|“退出”命令(4) 打开一个记事本文件（*. txt），不做任何修改，单击“文件”|“退出”命令(5) 打开一个记事本文件，修改后不保存，单击“文件”|“退出”命令输出标准(1) 记事本未做修改，单击“文件”|“退出”命令，能正确地退出应用程序，无提示信息(2) 记事本做修改未保存或者另存，单击“文件”|“退出”命令，会提示“未定标题文件的文字已经改变，想保存文件吗？”单击“是”，Windows将打开“保存”/“另存为”对话框，单击“否

33、”，文件将不被保存并退出记事本程序，单击“取消”将返回记事本窗口测试用例间的关联44测试用例设计概述测试用例设计概述l下表是另一个测试用例示例(登录功能测试)该测试用例并未涵盖所有的非法输入，如非法输入中可能会有 “user=*,pw=*”的组合，对回车的默认操作，空格输入，对输入上溢的处理的处理（可能会跳过身份验证） 等等。如果你有兴趣，至少可以再补充5-10条左右的输入组合（当然，如果步骤超过15步，用例的易操作性就降低，可以再创建一个测试用例）。45项目项目/软件软件 XXXX系统系统 程序版本程序版本 1.0.25 功能模块名功能模块名 Login 编制人编制人 xxx 用例编号用例编

34、号TC-TEP_Login_1 编制时间编制时间 20XX.3.8相关的用例相关的用例 无无 功能特性功能特性 用户身份验证用户身份验证 测试目的测试目的 验证是否输入合法的信验证是否输入合法的信息，允许合法登陆，息，允许合法登陆，阻止非法登陆阻止非法登陆 预置条件预置条件 无无 特殊规程特殊规程说明说明 如数据库访如数据库访问权限问权限 参考信息参考信息 需求说明中关于需求说明中关于“登陆登陆”的说明的说明 测试数据测试数据 用户名用户名=yiyh 密码密码=1 46操作操作步骤步骤 操作描述操作描述 数数 据据 期望结果期望结果 实际实际结果结果 测试状态1 输入用户名称，按输入用户名称，

35、按“登陆登陆”按钮。按钮。 用户名用户名=yiyh，密码为空密码为空 显示警告信息显示警告信息“请请输入用户名和密输入用户名和密码！码！” 2 输入密码，按输入密码，按“登登陆陆”按钮。按钮。 用户名为空，用户名为空，密码密码=1 显示警告信息显示警告信息“请请输入用户名和密输入用户名和密码！码！” 3 输入用户名和密码，输入用户名和密码，按按“登陆登陆”按钮。按钮。 用户名用户名=yiyh，密码密码=2 显示警告信息显示警告信息“请请输入用户名和密输入用户名和密码！码！” 4 输入用户名和密码，输入用户名和密码，按按“登陆登陆”按钮。按钮。 用户名用户名=xxx，密码密码=1 显示警告信息显

36、示警告信息“请请输入用户名和密输入用户名和密码！码！” 5 输入用户名和密码，输入用户名和密码，按按“登陆登陆”按钮。按钮。 用户名用户名=xxx，密码密码=2 显示警告信息显示警告信息“请请输入用户名和密输入用户名和密码！码！” 6 输入用户名和密码，输入用户名和密码，按按“登陆登陆”按钮。按钮。 用户名用户名=空，密空，密码码=空空 显示警告信息显示警告信息“请请输入用户名和密输入用户名和密码！码！” 477 输入用户名和密输入用户名和密码，按码，按“登陆登陆”按钮。按钮。 用户名用户名=yiyh，密码密码=1 进入系统页面。进入系统页面。 8 输入用户名和密输入用户名和密码，按码，按“登

37、陆登陆”按钮。按钮。 用户名用户名=Admin，密，密码码=admin 进入系统维护进入系统维护页面。页面。 9 输入用户名和密输入用户名和密码，按码，按“登陆登陆”按钮。按钮。 用户名用户名=yiyh,密码密码=1 显示警告信息显示警告信息“请输入用户请输入用户名和密码！名和密码！” 10 输入用户名和密输入用户名和密码，按码，按“登陆登陆”按钮。按钮。 用户名用户名=yiyh，密码密码=1 显示警告信息显示警告信息“请输入用户请输入用户名和密码！名和密码！” 11 输入用户名和密输入用户名和密码，按码，按“重置重置”按钮。按钮。 用户名用户名=yiyh，密码密码=1 清空输入信息清空输入信

38、息 测试人测试人员员 开发人员开发人员 48测试用例设计误区测试用例设计误区 l测试用例设计的误区测试用例设计的误区 l能发现到目前为止没有发现的缺陷的用例是好的用例能发现到目前为止没有发现的缺陷的用例是好的用例作为测试实施依据的测试用例，应当作一个集合来认识，要能作为测试实施依据的测试用例，应当作一个集合来认识，要能完整覆盖测试需求，而不应针对单个的测试用例去评判好坏。完整覆盖测试需求，而不应针对单个的测试用例去评判好坏。 l测试用例应该详细记录所有的操作信息，使一个没有接触过测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试系统的人员也能进行测试 测试用例维护费用太高，测试资源难保证测试用例维护费用太高，测试资源难保证l测试用例设计是一劳永逸的事情测试用例设计是一劳永逸的事情 测试用例是动态的，一旦测试环境、需求、设计、实现发生了测试用例是动态的，一旦测试环境、需求、设计、实现发生了变化，测试用例都需要相应发生变化变化，测试用例都需要相应发生变化49测试用例设计误区测试用例设计误区l测试用例不应该包含实际的数据测试用例