软件测试基础讲义.ppt
《软件测试基础讲义.ppt》由会员分享，可在线阅读，更多相关《软件测试基础讲义.ppt（93页珍藏版）》请在冰点文库上搜索。
软件测试基础介绍研发二部,2013年1月30日,目录,软件测试概述软件测试模型软件测试分类软件测试过程（功能测试）软件性能测试,什么是软件测试？
软件测试是在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。
软件是由文档、数据以及程序组成，所以软件测试就不仅仅是对程序进行测试。
资料表明，60以上的错误并不是程序错误，而是分析和设计错误，因此提倡软件全生命周期测试的理念。
软件测试的定义软件测试（Softwaretesting）是软件生存期中的一个重要阶段，是软件质量保证的关键步骤。
通俗地讲，软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码进行最终复审的活动。
1983年IEEE提出的软件工程术语中给软件测试下的定义是：
“使用人工或自动的手段来运行或测定某个软件系统或系统部件的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。
为什么需要测试？
缺陷是怎样产生的？
产生缺陷的原因：
时刻想到，你的软件中是有缺陷的如果想要找到软件中的缺陷：
那只有测试你的软件,我写的代码很干净。
我查了好几遍都没找到错误我不相信还会有错误,软件测试有什么好处？
通过测试可以：
发现软件的错误行为可以界定错误的原因证明软件的正确行为软件测试是质量保证的一个重要手段,软件测试的目的,目的：
寻找软件的缺陷跟踪修正软件缺陷验证修正的软件缺陷一个好的测试在于发现了至今未发现的错误。
软件测试是为了证明软件中存在错误，而不是为了证明软件不存在错误。
软件测试的原则,原则：
所有的软件测试都应追溯到用户需求尽早进行软件测试，早期发现和报告软件缺陷完全测试是不可能的，测试需要终止全程测试，测试过程贯穿于整个项目的生命周期测试独立与开发，开发人员不能测试自己的软件测试是有组织、有计划、有步骤的，尽量避免软件测试的随意性。
有效的测试应当是：
破坏性的系统化的开发和测试过程必须严格分开：
在时间上分开在组织结构上分开在人事上分开独立测试独立测试的好处：
能找到更多其他人的错误无偏见验证设计和开发人员的设想具有专业测试的知识背景,软件测试对象,软件测试不等于程序测试，软件测试贯穿于软件定义和开发的整个期间。
需求分析,概要设计,详细设计,以及程序编码等各个阶段所得到的文档,包括需求规格说明,概要设计规格说明,详细设计规格说明以及源程序,都是软件测试的对象。
常见的引入缺陷的原因,开发过程中缺乏有效的沟通或者没有进行沟通软件复杂度越来越高需求不断变更项目进度的压力不重视开发文档软件开发工具本身隐藏的问题,解决方案,要尽早进行测试,软件测试概述软件测试模型软件测试分类软件测试过程（功能测试）软件性能测试,目录,2.软件测试模型,V模型,在V模型中，测试贯穿在整个软件开发过程活动中，测试人员可以尽早进入项目，测试人员将更加熟悉产品，更多缺陷将在早期被发现，这有利于大幅度降低成本，在项目后期发现严重缺陷的风险大大降低。
同时对设计出高质量的测试用例非常有帮助。
W模型,W模型是V模型的发展，测试伴随整个软件的开发周期，测试的对象包括需求、代码、功能和设计，只要相应的对象开发完成，测试就可以进行。
H模型,准备测试,准备就绪点,测试执行,测试流程,其他流程（如设计流程）,H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
H模型揭示了一个原理：
软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。
H模型指出软件测试要尽早准备，尽早执行。
软件测试概述软件测试模型软件测试分类软件测试过程（功能测试）软件性能测试,目录,3.软件测试分类,按照测试阶段划分单元测试单元测试主要用白盒测试方法，一般我们先静态地检查代码是否符合规范，然后动态地运行代码，检查其实际运行结果。
当然，检查程序的运行结果是否正确是一个最基本的要求，我们还要检查很多项，比如程序的容错处理，程序的边界值处理等。
单元测试是在程序员编码之后，代码通过编译后进行单元测试。
单元测试一般由白盒测试工程师或开发人员来测试。
集成测试集成测试是单元测试的下一个阶段，是指将通过测试的单元模块组装成系统或子系统，再进行测试。
重点测试不同模块的接口部分，检查各个单元模块结合到一起能否协同配合，正常运行。
集成测试的依据是单元测试的模块以及概要设计文档。
系统测试集成测试之后，就进行系统测试。
系统测试也是我们测试的重点。
系统测试将整个软件系统看做一个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。
主要依据是系统需求规格说明书文档。
目前系统测试主要由测试工程师在整个系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，以及系统在不同的软硬件环境中的兼容性等。
验收测试验收测试是以用户为主的测试。
软件开发人员与质量保证人员也应参加。
由用户参加设计测试用例。
使用用户界面输入测试数据，并分析测试的输出结果。
一般使用生产中的实际数据进行测试。
按照是否运行程序划分静态测试静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。
对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。
静态测试结果可用于进一步的查错，并为测试用例选取提供指导。
动态测试实际的执行被测对象的程序代码，输入实现设计好的测试用例，检查程序代码运行得到的结果与测试用例中设计的预期结果之间是否有差异，判定实际结果与预测结果是否一致。
动态测试有四部分组成：
设计测试用例，执行测试用例，分析比较输出结果，输出测试报告。
动态测试有三种主要方法：
黑盒测试，白盒测试和灰盒测试。
按照测试技术划分（黑盒测试）功能测试功能测试将系统看成黒盒，又称为黒盒测试，它检查软件的功能是否符合需求规格说明书，确保测试对象的功能正常，其中包括导航，数据输入，处理和检索等。
测试时用有效数据和无效数据来执行各个用例或用例流，以核实在使用有效数据时得到预期的结果，在使用无效数据时显示相应的错误信息或警告信息。
由于正确性是软件最重要的质量因素，所以其测试也最重要。
性能测试性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
性能测试的目的是为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，优化系统。
软件测试概述软件测试模型软件测试分类软件测试过程（功能测试）软件性能测试,目录,软件测试过程,制定测试计划,设计测试用例,执行测试,撰写测试报告,修正软件缺陷,回归测试,测试需求分析,功能测试概述,任何程序都可以看作是将从输入定义域取值映射到输出值域的函数功能测试将系统看成黒盒，又称为黒盒测试。
黒盒的实现是不需要了解的，只需要知道输入和预期输出。
功能性测试与软件如何实现无关，如果实现发生变化，功能性测试用例仍然可用。
测试用例开发可以与软件开发同时进行，可节省软件开发时间，通过软件的用例（usecase）就可以设计出大部分功能性测试用例。
功能测试的优点,需求分析,通过详细的分析测试需求，可以了解整个测试的规模、复杂程度，以及可能存在的风险。
测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。
整个需求分析过程分以下几个阶段和任务：
分析需求测试时，要遵循以下原则：
完整性：
每一项需求都必须将所要实现的功能描述清楚。
正确性：
每一项需求都必须准确地陈述其要开发的功能。
一致性：
是指与其它软件需求或高层（系统，业务）需求不相矛盾。
可行性：
每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
无二义性：
对所有需求说明的读者都只能有一个明确统一的解释，应尽量把每项需求用简洁明了的用户性的语言表达出来。
健壮性：
测试需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
必要性：
是指每项需求都是用来授权你编写文档的“根源”，要使每项需求都能回溯至某项客户的输入。
可测试性：
每项需求都能通过设计测试用例或其它的验证方法来进行测试。
可修改性：
每项需求只应在测试需求分析中出现一次。
这样更改时易于保持一致性。
可跟踪性：
在每项测试需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，使得每项测试需求以一种结构化的，粒度好的方式编写并单独标明，而不是大段大段的叙述。
测试计划阶段功能点整理,测试计划,软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。
对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。
测试计划包括：
测试目的测试范围测试环境测试方法测试人员和时间安排,“5W1H”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“Who”（谁去做）“How（如何做）”。
利用“5W1H”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），确定团队人员（Who），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
为了使“5W1H”规则更具体化，需要准确理解被测软件的功能特征、应用行业的知识和软件测试技术，在需要测试的内容里面突出关键部分，可以列出关键及风险内容、属性、场景或者测试技术。
对测试过程的阶段划分、文档管理、缺陷管理、进度管理给出切实可行的方法,测试计划评审,测试计划编写后，内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
测试计划包含多方面的内容，编写人员可能受自身测试经验和对软件需求的理解所限，而且软件开发是一个渐进的过程，所以最初创建的测试计划可能是不完善的、需要更新的。
需要采取相应的评审机制对测试计划的完整性、正确性、可行性进行评估。
测试计划变更,更来源于以下几个方面：
项目计划的变更；需求的变更；测试产品版本的变更；测试时间变更；测试资源的变更。
测试用例设计,什么是测试用例？
测试用例是为特定的目的设计的一组测试输入、执行条件、和预期的结果。
测试用例是执行的最小实体。
测试用例的重要性为什么要写测试用例？
测试人员工作不主动的时候测试时思维混乱的情况测试时间紧迫的情况情绪不佳、人员流动频繁,测试用例的组成元素测试用例的必要组成元素,用例编号用例名称步骤预期结果设计人员,测试用例模板解释,序号,用例名称,设计者,描述,步骤序号,具体步骤描述,预期结果,实际结果,格式：
用例编号，每个工作表的用例从1开始，例如：
1,2,3,解释：
该测试用例的名称格式：
模块名称_子模块名称_功能点名称_流水号（从01开始）举例：
客户管理_对公客户_新增客户_01,解释：
编写此测试需求点的人员姓名全拼（要求中文拼音）,解释：
对此测试案例的场景的简要描述,解释：
步骤序号举例：
步骤1、步骤2、,解释：
案例场景每一步操作对应的输入要素、数据描述（前置条件和输入值要明确填写，并用蓝色标识）要求：
多个操作才能产生一个预期结果，请作为一个步骤,解释：
每一步骤操作对应产生的预期结果要求：
在预期结果中，一定要把检查点的预期结果明确描述，以便明确判断是成功还是失败,格式：
成功、失败解释：
执行测试用例步骤的结果,测试用例设计方法,测试用例设计基本方法,等价类划分法,边界值分析法,因果图法,错误推测法,流程分析法,解释：
把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少量具有代表性的数据作为测试用例,等价类划分法,等价类某些数据的集合，该集合内每个数据都是等效的，那么可以将该集合视为等价的一类,等效对于计算机软件而言，即对于数据的处理方式完全一致,有效等价类,无效等价类,四条确定等价类的原则,在输入条件规定了取值范围的情况下,则可以确立一个有效等价类和两个无效等价类在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,则可以确立一个有效等价类和一个无效等价类在规定了输入数据必须遵守的规则的情况下,可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类,等价类划分法,示例：
对用户输入的分数进行评级A90100B8089C7079D6069E60以下输入分数要求是正整数或0（0100）,05960697079808990100,空负数大于100的数小数含字母的字符串,等价类划分法,边界值分析法,对等价类划分法的补充。
其测试用例来自于等价类的边界,步骤1：
应确定边界情况步骤2：
应选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据,边界值分析法,选择用例的原则：
如果输入条件规定了值的范围，应取刚达到这个范围的边界值和刚刚超过这个范围的边界值作为测试数据如果输入条件规定了值得长度，则用最大长度、最小长度、比最大长度多个字符、比最小个数少个字符作为测试数据,边界值分析法,示例：
对用户输入的分数进行评级A90100B8089C7079D6069E60以下输入分数要求是正整数或0（0100）,-10159606169707179808189909199100101,因果图法,概念等价类划分法和边界值分析法都是着重考虑输入条件，但没有考虑输入条件的各种组合，输入条件之间的相互制约关系。
因果图法是一种利用图解分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
因果图法考虑了输入情况的各种组合及输入情况之间的相互制约关系。
示例：
程序的规格说明要求：
输入的第一个字符必须是“#”或“*”，第二个字符必须是一个数字，在此情况下进行文件的修改；如果第一个字符不是“#”或“*”，则给出信息“N”；如果第二个字符不是数字，则给出信息“M”,步骤：
1.分析程序的规格说明，列出原因和结果；2.找出原因与结果之间的因果关系，原因和原因之间的约束关系，画出因果图；3.将因果图转换成判定表；4.根据判定表，设计测试用例的输入数据和预期输出。
列出原因和结果,原因：
c1第一个字符是“#”c2第一个字符是“*”c3第二个字符是一个数字,C1,C2,C3,1或0,E1,E2,E3,或,与,非,非,结果：
e1给出信息Ne2修改文件e3给出信息M,因果图,将因果图转化为判定表,设计测试用例,根据判定表，最左边两列，因为C1和C2不可能同时输入，排除掉，根据表可设计出6个测试用例：
错误推测法,概念：
根据经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法,例如：
一般会考虑业务中的极端、异常情况,空、空格生僻字显示乱码特殊字符等,流程分析法,概念：
将业务流程绘制成流程图，然后分析可能存在的各种路径，有针对性地覆盖这些路径的设计方法称为流程分析法。
流程分析法,业务场景1：
正常提交申请并审核通过（流程路径为：
ABCDE）业务场景2：
流程中某节点进行回退操作。
点对点单次退回：
各环节退回修改至上一环节提交人，修改后继续提交，后续审核全部通过（后续审核覆盖各环节后的全部正向分支流程）；ABABCDE，ABCBCDE等点对点循环退回：
各环节逐级依次退回修改至上一环节提交人，逐次修改提交，直至最后一级退回修改后审核通过（各正向分支流程都要覆盖）；流程路径为：
ABABCBCDCDEDE,案例研究1：
根据输入判断三角形的形状,测试场景：
一个程序读入3个整数，把这三个数值看作一个三角形的3条边的长度值。
这个程序要打印出信息，说明这个三角形是不等边的、是等腰的、还是等边的。
确定输入数据与三角形形状的关系：
设三角形的3条边分别为A，B，C。
如果它们能够构成三角形的3条边，必须满足：
A0，B0，C0，且A+BC，B+CA，A+CB；如果是等腰的，还要判断A=B，或B=C，或A=C；如果是等边的，则需判断是否A=B，且B=C，且A=C。
创建等价类表：
确定等价类输入数据：
案例研究2：
测试用户登录对话框的功能,测试场景：
在各种输入条件下，测试程序的登录对话框功能。
用户名和密码的规则如下：
用户名长度为6至10位（含6位和10位）用户名由字符（a-z、A-Z）和数字（0-9）组成不能为空、空格和特殊字符密码规则同用户名规则,确定输入数据的情形：
确定具体的输入数据：
测试用例设计原则,测试用例的代表性测试结果的可判定性测试结果的可再现性,验收测试用例设计要点,出发点：
旨在确认软件符合需求规格的验证活动范围：
用户业务需求，但不超出合同范围复杂度：
结构简单、条理清晰、屏蔽软件内部结构角度：
用户使用、根据业务场景组织测试用例和流程,测试用例的评审,覆盖面是否完全,描述是否清晰,测试用例是否正确,无遗漏,清晰易懂,正确准确,测试执行,功能测试的测试执行阶段主要完成以下工作：
配置测试环境，包括基础软硬件环境、被测系统环境和初始化测试数据；根据事先设计好的业务流程执行业务用例记录测试结果和测试过程中发现的问题对测试过程中发现的问题，提交到缺陷跟踪系统中进行跟踪收集测试过程中的各项信息，分析、控制测试过程,测试启动条件测试计划和测试用例准备完毕错误跟踪工具设置完毕被测试的Build已经可用测试的软件和硬件环境已经准备就绪,测试结束条件所有软件缺陷得到处理（最好目标：
0缺陷）在规定的时间内连续运行软件没有产生死机、系统崩溃和丢失数据的错误完成了测试计划和测试用例指定的测试工作软件经过“项目管理组”讨论，认为能达到客户的合理质量期望值软件到了发布的截止日期,测试的启动与结束条件,缺陷管理,缺陷生命周期,软件缺陷生命周期有很多个阶段。
根据不同的缺陷跟踪管理系统，下面的状态名称也会有所不同：
新建（打开）：
当测试人员汇报新的缺陷时的缺陷状态。
延后处理：
如果这个缺陷跟当前发布的这个版本没有直接关系，或者当前版本无法修复，或者这个缺陷不是很严重，不需要立刻修复，那么项目经理可以把状态设为“延后处理”。
已指派：
“指派给”这个值是由项目组长或者项目经理来填，指定给具体的某个开发人员。
已解决/已修复：
当开发人员做了某些必要的代码改动，并且确认修改之后，那么他/她就可以把状态改为“已修复”，然后就交给测试组进行回归测试。
缺陷生命周期,无法重现：
如果开发人员根据测试人员在缺陷报告里面描述的步骤，都无法重现这个缺陷的时候，那么开放人员可以把这个缺陷标为“无法重现”。
测试人员需要检查这个缺陷是否可以重现，并且把更为详细的重现步骤提供给开发人员。
需要更多信息：
如果开发人员认为测试人员提供的缺陷重现步骤不够清晰，因而无法重现缺陷的时候，那么他/她可以把状态标记为“需要更多信息”。
在这种情况下，测试人员需要提供更为详细的重现步骤，并把缺陷返回给开发小组。
重新打开：
如果测试人员不满意这个修复结果，或者说即使在修复之后，依然出现同样的问题，那么测试人员可以把状态标记为“重新打开”，这样的话，开发人员就可以采取相应的行动了。
关闭：
如果测试小组已经验证过这个缺陷的修复结果，并且问题是已经得到了解决的，那么测试人员就可以把状态改为“关闭”。
驳回/无效：
有些时候，如果这个系统的确是按照规格说明来运行的，而缺陷的产生只是由于误解而引起的，那么开发人员或者小组组长可以把这些缺陷标记为“驳回”或者“无效”。
缺陷严重性等级定义,A类（致命缺陷）导致对被描述的主要对象的理解错误、不可行、不能运转、对业务和整个系统可能造成重大损失或损害。
B类（严重缺陷）对被描述的部分对象的理解或实现错误，部分的系统或模块不可行或不能运转或部分系统和模块缺失，对整个系统有重大影响或可能造成部分的损失和损害。
C类（一般缺陷）系统中部分单元模块或单个功能描述和实现有错误、有偏差、不一致或有缺失，不影响模块的正常运行，或有影响但可以有替代办法或避免办法。
D类（微小缺陷）基本不影响系统的运行和功能的实现。
但是与标准、规范和定义不一致。
E类（建议缺陷）不在标准、规范、范围的定义和约束之内，但是从提出者来看是需要完善的建议。
如安装手册，操作手册，在线帮助，代码冗余，可跟踪性等问题。
缺陷优先级等级定义,BUG的优先级一般与BUG等级挂钩分为4级：
1级（严重）：
立即解决。
缺陷导致系统几乎不能使用或测试不能继续，需立即修复。
2级（较高）：
缺陷严重，影响测试，需要优先考虑。
3级（一般）：
正常排队缺陷需要正常排队等待修复。
4级（轻微）：
缺陷可以在开发人员有时间的时候被纠正。
测试报告,测试报告的内容一般包括以下内容：
测试的概要介绍，包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介；测试结果与缺陷分析：
这部分主要汇总各种数据并进行度量，度量包括对测试过程的度量和能力评估、对软件产品的质量度量和产品评估；测试结论与建议：
这部分主要报告本次测试执行是否充分、测试目标是否完成、测试是否通过等结论，和对系统存在问题的说明、可能存在的潜在缺陷和后续工作、对缺陷修改和产品设计的建议；有时附录有缺陷列表、缺陷等级定义标准、测试通过标准等。
软件测试概述软件测试模型软件测试分类软件测试过程（功能测试）软件性能测试,目录,什么是软件性能？
一般来说，性能是一种指标，表明软件系统或构件对于其及时性要求的符合程度；其次性能是软件产品的一种特性，可以用时间来进行度量。
软件的性能是软件的一种非功能特性，它关注的不是软件是否能够完成特定的功能，而是在完成该功能时展示出来的及时性。
由于感受软件性能的主体是人，不同的人对于同样的软件能有不同的主观感受，而且不同的人对于软件性能关心的视角也不同。
什么是软件性能测试？
性能测试的必要性性能测试的目标考察系统是否满足预期的性能要求作为对系统进行调优的参考考察系统的可扩展性用性能测试手段发现系统存在的问题提供部署方案的参考,软件性能测试的基本概念,狭义上的软件性能测试响应时间吞吐量并发用户数资源利用率广义上的软件性能测试性能测试压力测试负载测试可靠性测试配置测试失效恢复测试,响应时间,响应时间指客户端发送请求后得到服务第一个数据包反馈的时间。
响应时间包括服务器响应时间和网络传输时间两部分。
如果网络正常，网络传输时间不会超过1秒。
响应时间是衡量服务器速度和性能的一个重要指标。
响应时间=网络传输时间+服务器响应时间响应时间=（N1+N2+N3+N4）+（A1+A2+A3）,吞吐量,吞吐量是指系统在单位时间内处理请求的数量。
对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。
对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。
事务成功率,事务成功率指成功完成相关业务操作的用户数量比上总加载的用户数量。
事务的成功率是判断用户加载是否成功的重要标志。
CPU利用率,指处理器执行非闲置线程时间的百分比。
这个计数器设计成用来作为处理器活动的主要指示器。
它通过在每个时间间隔中衡量处理器用于执行闲置处理线程的时间，并且用100%减去该值得出。
可将其视为范例间隔用于做有用工作的百分比。
根据应用系统情况，在80%5%范围内波动为宜。
过低，则服务器CPU利用率不高；过高，则CPU可能成为系统的处理瓶颈。
内存指标,显示出当前空闲的物理内存总量，它等于分配给待机（缓存的）、空闲和零分页列表内存的总和。
当这个数值变小时，Windows开始频繁地调用磁盘页面文件。
如果这个数值很小，例如小于5MB，系统会将大部分时间消耗在操作页面文件上。
一般要保留10%的可用内存。
最低不能4M，此值过小可能是内存不足或内存泄漏。
性能测试需求的来源,需求文档设计文档客户备忘录,确定测试目标的原则,“以需求为本”测试目标确定的经济性考虑基于风险的测试目标确定,在开始制订方案之前确定测试目标和需求了解现状业务使用状况环境确定需要监控的指标CPU使用率Mem使用情况,用例和场景设计对业务的分析和分解根据业务确定用例不同用例按照不同
升级会员 