《《黑盒测试培训》PPT课件.ppt》由会员分享，可在线阅读，更多相关《《黑盒测试培训》PPT课件.ppt（35页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、软件测试培训内容l l什么是软件测试什么是软件测试l l软件测试对象软件测试对象l l测试的目的测试的目的l l测试的分类测试的分类l l功能测试方法与内容功能测试方法与内容l l测试策略测试策略l l测试流程及相关文档测试流程及相关文档l l测试人员的基本素质测试人员的基本素质l l测试驱动开发介绍测试驱动开发介绍什么是软件测试l l软件测试是一种有效的提高软件质量的手段软件测试是一种有效的提高软件质量的手段,但即使在投入但即使在投入上有所保证上有所保证,测试也不能百分为百发现所有质量隐患测试也不能百分为百发现所有质量隐患.况且况且软件质量并不仅仅是测试出来的软件质量并不仅仅是测试出来的.l
2、 l很多人认为软件测试就是运行一下软件很多人认为软件测试就是运行一下软件,看看结果对不对看看结果对不对.但实际上但实际上,如何在有限的投入下如何在有限的投入下,提高软件测试的效率和产提高软件测试的效率和产出是一件很见功底的事出是一件很见功底的事.好的测试人员不仅要掌握各种测试好的测试人员不仅要掌握各种测试技术技术,还要具备丰富的编程经验和对还要具备丰富的编程经验和对BUGBUG的敏感的敏感.测试的复测试的复杂之处杂之处,除了测试技术问题之外除了测试技术问题之外,还有测试管理问题还有测试管理问题.l l测试不是可有可无测试不是可有可无,随心所欲的随心所欲的.规范化的软件开发需要对规范化的软件开发
3、需要对软件测试早做计划软件测试早做计划,分配必要的时间分配必要的时间,人力和财力等资源人力和财力等资源,并并将其作为项目管理的一个部分加以控制和协调将其作为项目管理的一个部分加以控制和协调.l l开发和测试是软件项目相辅相成的两个过程开发和测试是软件项目相辅相成的两个过程,人员间的交流人员间的交流,协作和配合是提高整体效率的重要因素协作和配合是提高整体效率的重要因素.l l开发与测试的 V 型关系l l如果软件开发过程采用严格的瀑布模型，那么如果软件开发过程采用严格的瀑布模型，那么开发与测试有开发与测试有“V”V”型的对应关系型的对应关系 。需求开发高层设计详细设计编程单元测试集成测试系统测试
4、验收测试l l软件产品开发完毕,再进行测试的观念是有悖于生命周期理论的.软件产品质量问题越晚发现,修复的代价越大.需求设计编程内部测试外部测试发布修正BUG的代价l l一些常识和经验之谈一些常识和经验之谈l l测试能提高软件的质量，但是提高质量不能依赖测试。测试能提高软件的质量，但是提高质量不能依赖测试。l l测试只能证明缺陷存在，不能证明缺陷不存在。测试只能证明缺陷存在，不能证明缺陷不存在。“彻彻底地测试底地测试”难以成为现实，要考虑时间、费用等限制，难以成为现实，要考虑时间、费用等限制，不允许无休止地测试。我们应当祈祷：软件的缺陷在不允许无休止地测试。我们应当祈祷：软件的缺陷在产品被淘汰之
5、前一直没有机会发作。产品被淘汰之前一直没有机会发作。l l测试的主要困难是不知道如何进行有效地测试，也不测试的主要困难是不知道如何进行有效地测试，也不知道什么时候可以放心地结束测试。知道什么时候可以放心地结束测试。l l每个开发人员应当测试自己的程序（份内之事），但每个开发人员应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据（所以项目需是不能作为该程序已经通过测试的依据（所以项目需要独立测试人员）。要独立测试人员）。l l80-2080-20原则：原则：8080的缺陷聚集在的缺陷聚集在2020的模块中，经常出的模块中，经常出错的模块改错后还会经常出错错的模块改错后还会经常出
6、错l l测试应当循序渐进，不要企图一次性干完，注意测试应当循序渐进，不要企图一次性干完，注意“欲欲速则不达速则不达”。l l软件测试的定义 软件测试是为了发现错误而执行程序的过程 软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例(即输入数据及其预期的输出结果),并利用这些测试用例去运行程序,以发现程序错误的过程.l l软件测试不等于程序测试.软件测试贯穿于软件定义和开发的整个期间.需求分析,概要设计,详细设计,以及程序编码等各个阶段所得到的文档,包括需求规格说明,概要设计规格说明,详细设计规格说明以及源程序,都是软件测试的对象.软件测试的对象 l l软件生存各个阶段
7、间的确认和验证软件生存各个阶段间的确认和验证测试的目的l l测试的目的是寻找错误,并且是尽最大可能找出最多的错误.在选取用例时,考虑那些易于发现程序错误的数据；l l一个好的测试用例在于发现至今未发现的错误;l l一个成功的测试是发现了至今未发现的错误的测试.l l正确理解测试的目的十分重要。如果认为测试的目的是为了说明程序中正确理解测试的目的十分重要。如果认为测试的目的是为了说明程序中没有缺陷，那么测试人员就会向这个目标靠拢，因而下意识地选用一些没有缺陷，那么测试人员就会向这个目标靠拢，因而下意识地选用一些不易暴露错误的测试示例。这样的测试是不真实的。不易暴露错误的测试示例。这样的测试是不真
8、实的。l l为什么需要测试？因为软件中有为什么需要测试？因为软件中有BugBug。l l为什么软件中有为什么软件中有BugBug？以下是一些原因：？以下是一些原因：（1 1）开发人员不太了解需求，不清楚应该）开发人员不太了解需求，不清楚应该“做什么做什么”和和“不做什么不做什么”，常常做不合需求的事情，因此产生了，常常做不合需求的事情，因此产生了BugBug。（2 2）软件系统越来越复杂，开发人员不太可能精通所有的技术，如果）软件系统越来越复杂，开发人员不太可能精通所有的技术，如果不能正确地使用技术，将产生不能正确地使用技术，将产生BugBug。（3 3）技术文档普遍比较糟糕，文档本身就有）技
9、术文档普遍比较糟糕，文档本身就有BugBug，导致使用者产生更多，导致使用者产生更多的的BugBug。（4 4）软件需求、设计报告、程序经常发生变更，每次变更都可能产生）软件需求、设计报告、程序经常发生变更，每次变更都可能产生新的新的BugBug。（5 5）任何人在编程时都可能犯错误，导致程序中有）任何人在编程时都可能犯错误，导致程序中有BugBug。（6 6）人们常处于进度的压力之下，急忙之下容易产生）人们常处于进度的压力之下，急忙之下容易产生BugBug，尤其是在期，尤其是在期限临近之际。限临近之际。（7 7）人们过于自信，喜欢说）人们过于自信，喜欢说“没问题没问题”，不真实的，不真实的“
10、没问题没问题”将产生将产生真正的问题。真正的问题。测试的分类l l从测试方法的角度可以分为手工测试和自动化测试。l l手工测试：不使用任何测试工具，根据事先设计好的测试用例来运行系统，测试各功能模块l l自动化测试：利用测试工具，通过编写测试脚本和输入测试数据，自动运行测试程序。目前最常用的自动化测试工具是基于GUI的自动化测试工具，基本原理都是录制、回放技术。l l从整体的角度可以分为单元测试、集成测试、系统测试、从整体的角度可以分为单元测试、集成测试、系统测试、确认测试。确认测试。l l单元测试：是针对软件设计的最小单位单元测试：是针对软件设计的最小单位程序模块，进行程序模块，进行正确性检
11、验的测试工作。一般包括逻辑检查、结构检查、正确性检验的测试工作。一般包括逻辑检查、结构检查、接口检查、出错处理、代码注释、输入校验、边界值检查。接口检查、出错处理、代码注释、输入校验、边界值检查。单元测试的依据是系统的详细设计；一般由项目组开发人单元测试的依据是系统的详细设计；一般由项目组开发人员自己完成。员自己完成。l l集成测试：在单元测试的基础上，将所有模块按照设计要集成测试：在单元测试的基础上，将所有模块按照设计要求组装进行测试。一般包括逻辑关系检查、数据关系检查、求组装进行测试。一般包括逻辑关系检查、数据关系检查、业务关系检查、模块间接口检查、外部接口检查。业务关系检查、模块间接口检
12、查、外部接口检查。l l系统测试：系统测试是在所有单元、集成测试后，对系统系统测试：系统测试是在所有单元、集成测试后，对系统的功能及性能的总体测试。的功能及性能的总体测试。l l确认测试：模拟用户运行的业务环境，运用黑盒测试方法，确认测试：模拟用户运行的业务环境，运用黑盒测试方法，验证软件系统是否满足用户需求或软件需求说明书中指明验证软件系统是否满足用户需求或软件需求说明书中指明的软件特性（功能、非功能）上的。的软件特性（功能、非功能）上的。l l从测试原理上分为：白盒测试、黑盒测试。从测试原理上分为：白盒测试、黑盒测试。l l白盒测试：是通过程序的源代码进行测试而不使用用白盒测试：是通过程序
13、的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。进而加以修正。l l黑盒测试：是通过使用整个软件或某种软件功能来严黑盒测试：是通过使用整个软件或某种软件功能来严格地测试格地测试,而并没有通过检查程序的源代码或者很清而并没有通过检查程序的源代码或者很清楚地了解该软件的源代码程序具体是怎样设计的。测楚地了解该软件的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了试人员通过输入他们的数据然后看输
14、出的结果从而了解软件怎样工作。在测试时，把程序看作一个不能打解软件怎样工作。在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收和正确的输出序是否能适当地接收和正确的输出l l黑盒测试方法主要有等价类划分、边界值分析、错误推测法等。黑盒测试方法主要有等价类划分、边界值分析、错误推测法等。l l等价类划分：等价类划分：是把所有可
15、能的输入数据是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法该方法是一种重要的是一种重要的,常用的黑盒测试用例设计方法常用的黑盒测试用例设计方法.设计测试用例时设计测试用例时,要同时考虑这两种等价类要同时考虑这两种等价类.因为因为,软件不仅要能接收合软件不仅要能接收合理的数据理的数据,也要能经受意外的考验也要能经受意外的考验.这样的测试才能确保软件具有更高这样的测试才能确保软件具有更高的可靠性的可靠性.l l边界值分析：边界值分析
16、：长期的测试工作经验告诉我们长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的大量的错误是发生在输入或输出范围的边界上边界上,而不是发生在输入输出范围的内部而不是发生在输入输出范围的内部.因此针对各种边界情况设因此针对各种边界情况设计测试用例计测试用例,可以查出更多的错误。可以查出更多的错误。l l错误推测法：错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性从而有针对性的设计测试用例的方法的设计测试用例的方法.错误推测方法的基本思想错误推测方法的基本思想:列举出程序中所有列举出程序中所有可能有的错误和容易发生错误
17、的特殊情况可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例根据他们选择测试用例.例例如如,在单元测试时曾列出的许多在模块中常见的错误在单元测试时曾列出的许多在模块中常见的错误.以前产品测试中以前产品测试中曾经发现的错误等曾经发现的错误等,这些就是经验的总结这些就是经验的总结.还有还有,输入数据和输出数据输入数据和输出数据为为0 0的情况的情况.输入表格为空格或输入表格只有一行输入表格为空格或输入表格只有一行.这些都是容易发生这些都是容易发生错误的情况错误的情况.可选择这些情况下的例子作为测试用例。可选择这些情况下的例子作为测试用例。l l从软件特性上分为功能测试和性能测试。从软件特性
18、上分为功能测试和性能测试。l l功能测试：是指为了确保软件系统功能实现的正功能测试：是指为了确保软件系统功能实现的正确性，完整性和其他特性而进行的测试。确性，完整性和其他特性而进行的测试。l l性能测试：是指为了评估软件系统的性能状况，性能测试：是指为了评估软件系统的性能状况，和预测软件系统性能趋势而进行的测试和分析。和预测软件系统性能趋势而进行的测试和分析。l l1 1、数据输入测试：向系统输入数据或输入数据库操作命令时，一般、数据输入测试：向系统输入数据或输入数据库操作命令时，一般是测试系统对数据库中数据操作的过程。是测试系统对数据库中数据操作的过程。l l数据类型测试：由于不同的数据库系
19、统对数据类型要求的不同，在定数据类型测试：由于不同的数据库系统对数据类型要求的不同，在定义数据库表时，也规定了数据字段的数据类型。测试步骤和方法：在义数据库表时，也规定了数据字段的数据类型。测试步骤和方法：在系统的数据维护功能界面上，录入或修改数据时，特意输入非系统设系统的数据维护功能界面上，录入或修改数据时，特意输入非系统设计的数据类型，检查系统是否可以接受，若不能接受则检查是否满足计的数据类型，检查系统是否可以接受，若不能接受则检查是否满足了系统在这方面的设计要求，如即刻清除非法内容、输入焦点不能到了系统在这方面的设计要求，如即刻清除非法内容、输入焦点不能到下一输入位置、出现系统自定义的提
20、示信息、不允许出现开发工具的下一输入位置、出现系统自定义的提示信息、不允许出现开发工具的报错信息等。若系统可以接受并保存，则要看数据库表的字段类型设报错信息等。若系统可以接受并保存，则要看数据库表的字段类型设计是否与用户或习惯上不一致，并且要注意其他模块在调取该数据时，计是否与用户或习惯上不一致，并且要注意其他模块在调取该数据时，是否有特定要求。是否有特定要求。l l边界值测试：根据数据取值范围的要求，输入符合取值范围的数据、边界值测试：根据数据取值范围的要求，输入符合取值范围的数据、取值范围的上、下限和超过取值范围的数据。注意，除要测试数据库取值范围的上、下限和超过取值范围的数据。注意，除要
21、测试数据库系统本身数据类型取值范围外，还要根据软件系统设计中的一些特定系统本身数据类型取值范围外，还要根据软件系统设计中的一些特定要求，设计测试用例来测试。要求，设计测试用例来测试。功能测试方法与内容l l数据合法性测试：测试人员除了要测试输入数据是否满足所使用数据数据合法性测试：测试人员除了要测试输入数据是否满足所使用数据库系统本身的数据类型和取值范围的要求外，还应该根据经验和软件库系统本身的数据类型和取值范围的要求外，还应该根据经验和软件系统和需求的特定要求检查输入数据的合法性。比如：日期合法性系统和需求的特定要求检查输入数据的合法性。比如：日期合法性（出生年月、参保日期、发生时间、根据习
22、惯和业务逻辑顺序对日期（出生年月、参保日期、发生时间、根据习惯和业务逻辑顺序对日期合理性的要求等）。工资、比例、率等，都要注意输入的合理、合法合理性的要求等）。工资、比例、率等，都要注意输入的合理、合法性。性。l l单引号和双引号：不要忽略输入单引号和双引号可能引起的错误和数单引号和双引号：不要忽略输入单引号和双引号可能引起的错误和数据问题。在功能录入界面上，在某字段的输入框输入了包括单引号和据问题。在功能录入界面上，在某字段的输入框输入了包括单引号和双引号的数据，以后在通过双引号的数据，以后在通过Select Select 语句查询时可能会出问题。特别在语句查询时可能会出问题。特别在基于基于
23、WEBWEB方式的系统，输入了单引号，在查询数据记录时，肯定会出方式的系统，输入了单引号，在查询数据记录时，肯定会出现页面链接错误（页面无法链接或找不到或链接对象错误）。现页面链接错误（页面无法链接或找不到或链接对象错误）。l l空值测试：在测试数据录入或修改的功能界面时，若不输入任何东西，空值测试：在测试数据录入或修改的功能界面时，若不输入任何东西，系统又没有设计成系统又没有设计成NOT NULLNOT NULL，则这时，要非常注意其影响。因为数，则这时，要非常注意其影响。因为数据可以正常保存，但数据表该字段是空值，那么所有与该字段有关的据可以正常保存，但数据表该字段是空值，那么所有与该字段
24、有关的操作，如：查询操作，如：查询(AND)(AND)、计算（累加、连乘）等，则可能出现数据问、计算（累加、连乘）等，则可能出现数据问题（计算结果为题（计算结果为0 0，无记录返回）。对于测试人员首先要检查系统到，无记录返回）。对于测试人员首先要检查系统到底是作为空值，还是作为空串或空字符处理。另外对于允许不输入任底是作为空值，还是作为空串或空字符处理。另外对于允许不输入任何值的字段，在测试过程中，要检查是否在界面显示或打印报表时，何值的字段，在测试过程中，要检查是否在界面显示或打印报表时，这些字段作为了关键要素或标题等情况。这些字段作为了关键要素或标题等情况。l l空格：在数据维护的功能界面
25、上，输入数据时，要注意是否在输入位空格：在数据维护的功能界面上，输入数据时，要注意是否在输入位置有空格，首先看系统设计时，是怎么考虑的，若系统允许输入空格，置有空格，首先看系统设计时，是怎么考虑的，若系统允许输入空格，则检查条件查询或作为调用参数时的数据返回情况；另外检查程序是则检查条件查询或作为调用参数时的数据返回情况；另外检查程序是否使用了去掉空格的函数。否使用了去掉空格的函数。l l数据校验的不一致：测试时，对于一些编号、编码、代码等主键或作数据校验的不一致：测试时，对于一些编号、编码、代码等主键或作为查询或调用条件的字段，要注意系统对他们的输入合法性检查与查为查询或调用条件的字段，要注
26、意系统对他们的输入合法性检查与查询或调用条件的要求是否是一致的。特别是对于数据结构设计中没有询或调用条件的要求是否是一致的。特别是对于数据结构设计中没有特定约束，而由程序进行校验控制的情况。特定约束，而由程序进行校验控制的情况。l l分析：数据输入测试的主要目的是保证输入到系统中数据的合法、合分析：数据输入测试的主要目的是保证输入到系统中数据的合法、合理性。我觉得，数据输入过程的检查是非常重要的，若在编程过程中，理性。我觉得，数据输入过程的检查是非常重要的，若在编程过程中，不注重数据的校验功能，虽然看起来加快了开发进度，但给以后会带不注重数据的校验功能，虽然看起来加快了开发进度，但给以后会带来
27、一些不可预计的编程或维护工作量。来一些不可预计的编程或维护工作量。l l2 2、目录路径测试、目录路径测试l l测试系统中规定的路径要求，更改路径，检查系测试系统中规定的路径要求，更改路径，检查系统的是否可以正确运行及系统的排错功能。测试统的是否可以正确运行及系统的排错功能。测试时，根据系统设计说明书（详细设计）或通过对时，根据系统设计说明书（详细设计）或通过对程序源代码的熟悉，找出系统运行过程中指定的程序源代码的熟悉，找出系统运行过程中指定的路径或在运行过程中，需要使用者选择路径的地路径或在运行过程中，需要使用者选择路径的地方。特意更改路径（选择正确的路径、选择另外方。特意更改路径（选择正确
28、的路径、选择另外的路径、输入不存在的路径）。检查系统是否具的路径、输入不存在的路径）。检查系统是否具有路径上的容错性和灵活性。比如，原则上在程有路径上的容错性和灵活性。比如，原则上在程序中，最好不要写绝对路径，另外可以提供配置序中，最好不要写绝对路径，另外可以提供配置路径的对话框，若输入了非法路径，系统有无提路径的对话框，若输入了非法路径，系统有无提示等。示等。l l3 3、数据操作测试：包括数据操作测试和用户界面操作的测试。数据操作测试：包括数据操作测试和用户界面操作的测试。修改、新增数据：对于新增和修改数据，要注重以下几个方面修改、新增数据：对于新增和修改数据，要注重以下几个方面的测试。界
29、面上，新增数据成功后，数据列表是否立即刷新，的测试。界面上，新增数据成功后，数据列表是否立即刷新，输入有错误时，是否清空错误的数据，输入焦点是否得以控制。输入有错误时，是否清空错误的数据，输入焦点是否得以控制。在提示信息上，是否有保存成功的提示，输入有错误时，提示在提示信息上，是否有保存成功的提示，输入有错误时，提示的错误信息是否准确，可读。数据方面，要通过的错误信息是否准确，可读。数据方面，要通过SQLSQL检查数据检查数据提交是否正确。提交是否正确。删除数据：测试删除记录时，系统是否有确认提示，能否批量删除数据：测试删除记录时，系统是否有确认提示，能否批量删除，根据系统详细设计，检查删除主
30、表记录时，在业务上，删除，根据系统详细设计，检查删除主表记录时，在业务上，其他相关表是否相应更改。其他相关表是否相应更改。事物的提交与回滚事物的提交与回滚:熟悉熟悉C/SC/S模式开发或数据库应用系统开发的模式开发或数据库应用系统开发的人都知道，数据库事物的概念。对于一个比较复杂的业务逻辑人都知道，数据库事物的概念。对于一个比较复杂的业务逻辑或业务上有数据一致和完整性要求时，尽量使用事物对数据进或业务上有数据一致和完整性要求时，尽量使用事物对数据进行提交，这样一旦由于意外原因引起系统或硬件故障时，可以行提交，这样一旦由于意外原因引起系统或硬件故障时，可以回滚。根据系统的设计要求在测试时，可人为
31、模拟意外故障，回滚。根据系统的设计要求在测试时，可人为模拟意外故障，来测试系统的数据完整性和容错能力。来测试系统的数据完整性和容错能力。l l4 4、工具条和快捷键测试：在功能界面测试时，对系统菜单、工具条和快捷键测试：在功能界面测试时，对系统菜单中定义的快捷键和菜单工具条中的工具按钮要测试。主要是中定义的快捷键和菜单工具条中的工具按钮要测试。主要是有效性和一致性测试。有效性：检查是否有效，界面有无反有效性和一致性测试。有效性：检查是否有效，界面有无反应。一致性：定义或提示的信息是否与实际完成的功能一致。应。一致性：定义或提示的信息是否与实际完成的功能一致。l l5 5、操作顺序测试操作顺序测
32、试按钮顺序测试：在功能界面上，不按照设计上或习惯上的操按钮顺序测试：在功能界面上，不按照设计上或习惯上的操作顺序点击功能按钮，看系统有什么反应；多次、反复点击作顺序点击功能按钮，看系统有什么反应；多次、反复点击某一按钮，看系统有什么反应。主要是测试系统的控制、校某一按钮，看系统有什么反应。主要是测试系统的控制、校验和容错能力。验和容错能力。业务逻辑顺序：不按照系统的正常业务逻辑、流程操作，来业务逻辑顺序：不按照系统的正常业务逻辑、流程操作，来测试系统是否控制了业务流程的顺序。测试系统是否控制了业务流程的顺序。l l6 6、按钮有效性控制测试：主要是测试当不具备条件或无实、按钮有效性控制测试：主
33、要是测试当不具备条件或无实际意义的情况下，按钮的际意义的情况下，按钮的“Enabled”Enabled”属性。比如：某一业务未属性。比如：某一业务未处理，下一环节的功能按钮则应变灰（不可用）。逐条显示处理，下一环节的功能按钮则应变灰（不可用）。逐条显示数据记录，当游标已经指到了最后一条时，数据记录，当游标已经指到了最后一条时，“下一条下一条”和和“末记末记录录”按钮则应变灰等。按钮则应变灰等。l l7 7、同时刻操作测试：对于删除、修改、增加数据和一些、同时刻操作测试：对于删除、修改、增加数据和一些业务功能，进行多客户端同时刻操作测试，看系统有什么业务功能，进行多客户端同时刻操作测试，看系统有
34、什么反应。反应。l l8 8、附件压力测试：对于有发送、上传、下载、邮件等功、附件压力测试：对于有发送、上传、下载、邮件等功能的系统，选取大的文件，进行测试，来检查系统的界面能的系统，选取大的文件，进行测试，来检查系统的界面效果和稳定性，看是否会死机或长时间无任何反应等。效果和稳定性，看是否会死机或长时间无任何反应等。l l9 9、数据输出测试：数据输出测试：数据处理输出测试：主要测试对数据的排序、条件查询是数据处理输出测试：主要测试对数据的排序、条件查询是否按照输入的条件或要求输出了正确的数据。否按照输入的条件或要求输出了正确的数据。打印输出：测试打印功能是否能够正常打印出报表，打印打印输出
35、：测试打印功能是否能够正常打印出报表，打印设置后，是否能按照设置的要求打印。设置后，是否能按照设置的要求打印。l l1010、WEBWEB测试：基于测试：基于WEBWEB方式的应用，对于一些提交表方式的应用，对于一些提交表单的页面，通过多次点击单的页面，通过多次点击“back”back”键，来测试系统的处理情键，来测试系统的处理情况。对于有保存数据功能的页面，多次点击况。对于有保存数据功能的页面，多次点击“保存保存”，来测，来测试系统的处理情况。试系统的处理情况。测试策略l l 理念：l l降低测试成本。降低测试成本。l l用较低的代价实现有效的测试，不应为了追求完美的测试而不失一切代价。用较
36、低的代价实现有效的测试，不应为了追求完美的测试而不失一切代价。l l 如何合理地减少测试工作量l l减少冗余的测试减少冗余的测试l l白盒测试与黑盒测试的方式虽然不同，但往往有白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工异曲同工”之妙。在很多地之妙。在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来），这样的方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。测试是冗余的。l l在集成测试、系统测试阶段，可能要执行多次在集成测试、系统测试阶段，可能要执行多次“回归测试回归测试”。每一次。每一次“回归测回归测试试”都会存在不少的冗余，应当设法
37、剔除不必要的重复测试工作。都会存在不少的冗余，应当设法剔除不必要的重复测试工作。l l减少无价值的测试减少无价值的测试l l无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来只要测试一个典型的输入就行了，如果有人在此区间测试了之中，本来只要测试一个典型的输入就行了，如果有人在此区间测试了100100次，次，那么其中那么其中9999次就是无价值的。次就是无价值的。l l如何如何“偷工减料偷工减料”l l有有一一些些“短短、平平、快快”的的项项目目，经经费费本本来来就就少少，用用户户对对质质量量要要求求
38、也也马马马马虎虎虎虎。为为了了能能多多挣挣一一点点钱钱，开开发发方方不不得得不不采采用用“偷偷工工减减料料”的的方方式式来来降降低低测测试试代代价价。偷偷工工减减料料的的途途径径无无非非就就是是减减少少测测试试的的内内容容和和频频度度。但但不不能能砍砍得得太太狠狠，否否则则软软件件拿拿不不出出手手。基基本本方方法法是是找找出出软软件件中中需需要要优优先先测测试试的的部部分分，其其它它次次要要部部分分可可以以忽忽略或将来再测试。略或将来再测试。l l“偷工减料偷工减料”方法的测试优先级：方法的测试优先级：l l哪些功能是软件的特色？哪些功能是软件的特色？l l哪些功能是用户最常用的？哪些功能是用
39、户最常用的？l l如果系统可以分块卖的话，哪些功能块在销售时最昂贵？如果系统可以分块卖的话，哪些功能块在销售时最昂贵？l l哪些功能出错将导致用户不满或索赔？哪些功能出错将导致用户不满或索赔？l l哪些程序是最复杂、最容易出错的？哪些程序是最复杂、最容易出错的？l l哪些程序是相对独立，应当提前测试的？哪些程序是相对独立，应当提前测试的？l l哪些程序最容易扩散错误？哪些程序最容易扩散错误？l l哪些程序是全系统的性能瓶颈所在？哪些程序是全系统的性能瓶颈所在？l l哪些程序是开发者最没有信心的？哪些程序是开发者最没有信心的？l l l l测试何时结束？测试何时结束？测试何时结束？测试何时结束？
40、l l一、基于测试用例的规则一、基于测试用例的规则一、基于测试用例的规则一、基于测试用例的规则l l（1 1）先构造测试用例（并请有关人员进行评审）。）先构造测试用例（并请有关人员进行评审）。l l（2 2）在测试过程中，当测试用例的不通过率达到）在测试过程中，当测试用例的不通过率达到2020时，则拒绝继续测试，待开时，则拒绝继续测试，待开发人员修正软件后再进行测试。发人员修正软件后再进行测试。l l（3 3）当功能性测试用例通过率达到）当功能性测试用例通过率达到100100，非功能性测试用例通过率达到，非功能性测试用例通过率达到9090时，时，允许正常结束测试。允许正常结束测试。l l该规则
41、的优点是适用于所有的测试阶段，缺点是太依赖于测试用例。如果测试该规则的优点是适用于所有的测试阶段，缺点是太依赖于测试用例。如果测试用例非常糟糕，那么该规则就失效了。用例非常糟糕，那么该规则就失效了。l l二、基于二、基于二、基于二、基于“测试期缺陷密度测试期缺陷密度测试期缺陷密度测试期缺陷密度”的规则的规则的规则的规则l l把测试一个把测试一个CPUCPU小时发现的缺陷数称为小时发现的缺陷数称为“测试期缺陷密度测试期缺陷密度”。绘制。绘制“测试时间缺测试时间缺陷数陷数”的关系图，如果在相邻的关系图，如果在相邻n n个个CPUCPU小时内小时内“测试期缺陷密度测试期缺陷密度”全部低于某个值全部低
42、于某个值mm时，则允许正常结束测试。例如时，则允许正常结束测试。例如n n大于大于1010，mm小于等于小于等于1 1。该规则比较适用于系统测。该规则比较适用于系统测试阶段。试阶段。l l三、基于三、基于三、基于三、基于“运行期缺陷密度运行期缺陷密度运行期缺陷密度运行期缺陷密度”的规则的规则的规则的规则l l把软件运行一个把软件运行一个CPUCPU小时发现的缺陷数称为小时发现的缺陷数称为“运行期缺陷密度运行期缺陷密度”。绘制。绘制“运行时间运行时间缺陷数缺陷数”的关系图，如果在相邻的关系图，如果在相邻n n个个CPUCPU小时内小时内“运行期缺陷密度运行期缺陷密度”全部低于某全部低于某个值个值
43、mm时，则允许正常结束测试。例如时，则允许正常结束测试。例如n n大于大于100100，mm小于等于小于等于1 1。该规则比较适用于。该规则比较适用于验收测试阶段，即客户试运行软件期间。验收测试阶段，即客户试运行软件期间。l l需求经常变更怎么办需求经常变更怎么办需求经常变更怎么办需求经常变更怎么办l l需求变更可能会让项目所有成员遭殃，如何需求变更可能会让项目所有成员遭殃，如何“预防变更预防变更”以及以及“降低变更降低变更的代价的代价”是软件工程的经典问题。本节仅论述需求变更对测试的影响。是软件工程的经典问题。本节仅论述需求变更对测试的影响。l l需求变更将导致软件设计和实现的变更，也导致了
44、测试变更。最让人难过的是需求变更将导致软件设计和实现的变更，也导致了测试变更。最让人难过的是上一次测试有可能白做了，如果软件变更比较大的话。上一次测试有可能白做了，如果软件变更比较大的话。l l测试人员不要只是自认倒霉，应当主动作些应变：测试人员不要只是自认倒霉，应当主动作些应变：l l（1 1）及时了解需求变更的详细情况，尽早调整测试计划，不要闷头按原计划测）及时了解需求变更的详细情况，尽早调整测试计划，不要闷头按原计划测试。试。l l（2 2）将软件中稳定的部分与易变的部分区别对待，前者先测试，后者后测试。）将软件中稳定的部分与易变的部分区别对待，前者先测试，后者后测试。l l（3 3）向
45、领导反映需求变更对测试造成的影响，为自己争取余地。）向领导反映需求变更对测试造成的影响，为自己争取余地。l l（4 4）设计一些比较灵活的测试用例，能适应某些变更（不过技术难度比较高）。）设计一些比较灵活的测试用例，能适应某些变更（不过技术难度比较高）。l l引申问题：如果在系统测试时，对照需求文档，发现软件多了功能或少了功能，引申问题：如果在系统测试时，对照需求文档，发现软件多了功能或少了功能，该怎么办？该怎么办？l l如果发现软件少了功能，测试人员不可为了少干些活而隐瞒事实。如果发现软如果发现软件少了功能，测试人员不可为了少干些活而隐瞒事实。如果发现软件多了功能，测试人员不可认为这些功能反
46、正是件多了功能，测试人员不可认为这些功能反正是“锦上添花锦上添花”，便自作主张地，便自作主张地测试了事。两种情况都要报告给项目经理，有可能导致一系列的变更。测试了事。两种情况都要报告给项目经理，有可能导致一系列的变更。测试流程及相关文档l l测试流程l l第一步：制定测试计划。该计划被批准后转向第二步。第一步：制定测试计划。该计划被批准后转向第二步。l l第二步：设计测试用例。该用例被批准后转向第三步。第二步：设计测试用例。该用例被批准后转向第三步。l l第三步：如果满足第三步：如果满足“启动准则启动准则”，那么执行测试。，那么执行测试。l l第四步：撰写测试报告。第四步：撰写测试报告。l l
47、第五步：消除软件缺陷。如果满足第五步：消除软件缺陷。如果满足“完成准则完成准则”，那么正常结束测试。，那么正常结束测试。制定测试计划设计测试用例执行测试写测试报告消除软件缺陷审批审批回归测试完成测试完成准则启动准则l l测试启动准则测试启动准则l l同时满足以下条件，允许开始测试：同时满足以下条件，允许开始测试：l l（1 1）测试计划已经制定并且通过了审批；）测试计划已经制定并且通过了审批；l l（2 2）测试用例已经设计并且通过了审批；）测试用例已经设计并且通过了审批；l l（3 3）被测试对象已经开发完毕并等待测试。）被测试对象已经开发完毕并等待测试。l l 测试完成准则测试完成准则l
48、l对对于于非非严严格格系系统统可可以以采采用用“基基于于测测试试用用例例”的的准准则则。同同时时满满足足以以下下条条件允许结束测试：件允许结束测试：l l（1 1）功能性测试用例通过率达到）功能性测试用例通过率达到100100；l l（2 2）非功能性测试用例通过率达到）非功能性测试用例通过率达到9090时。时。l l测试相关文档l l测试计划测试计划：指明范围、方法、资源，以及相：指明范围、方法、资源，以及相应测试活动的时间进度安排表的文档。应测试活动的时间进度安排表的文档。l l测试用例测试用例：指明为完成一个测试项的测试输：指明为完成一个测试项的测试输入、预期结果、预期执行条件等因素的文
49、档。入、预期结果、预期执行条件等因素的文档。l l测试报告测试报告：指明执行测试结果的文档。：指明执行测试结果的文档。测试人员基本素质l l(1)(1)首先，应对软件测试感兴趣和对自己有自信，如果具备了这两点，那么在首先，应对软件测试感兴趣和对自己有自信，如果具备了这两点，那么在开发过程中不管遇到什么样的困难，我相信你一定能克服。开发过程中不管遇到什么样的困难，我相信你一定能克服。(2)(2)善于怀疑，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别善于怀疑，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生。别人认为是对的，我却认为不人认为不可
50、能发生的事，我却认为可能发生。别人认为是对的，我却认为不是对的。是对的。(3)(3)打破砂锅问到底的精神，对于只出现过一次的打破砂锅问到底的精神，对于只出现过一次的bugbug，一定找出原因，不解，一定找出原因，不解决誓不罢休。决誓不罢休。(4)(4)保持一个良好的心情，否则可能无法把测试作好。不要把生活中的不愉快保持一个良好的心情，否则可能无法把测试作好。不要把生活中的不愉快的情绪带到工作中来的情绪带到工作中来 (5)(5)做测试时要细心，不是所有的做测试时要细心，不是所有的bugbug都能很容易的找出，一定要细心才能找都能很容易的找出，一定要细心才能找出这些出这些bugbug。(6)(6)