2022年软件测试理论基础 .pdf

《2022年软件测试理论基础 .pdf》由会员分享，可在线阅读，更多相关《2022年软件测试理论基础 .pdf（21页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件测试理论基础一、软件工程：从 管理、技术 两方面来研究如何更好的开发、维护 计算机软件的学科。七条基本原理：1、 用生命周期计划严格管理生命周期：可以概括为定义、开发、应用和维护四个时期需求提出 可行性分析 高度化设计 (HLD) 详细化设计 (LLD) coding（编码） test（测试） 上线 售发生命周期中的计划：项目概要计划里程碑计划项目控制计划产品控制计划验证计划运行维护计划项目具有特定性，产品不具有特定性2、 坚持进行阶段评审评审： （做质量保证的人）提前发现错误减少软件的损失QA 质量保证quality assurance QC 质量控制quality control 3、

2、 产品一致性控制及时的更新变更CCB 控制变更委员会 (control changing ) 基准配置管理：（变动控制）文档、代码打上标签如：配置管理工具VSS 4、 采用最新的软件设计技术5、 清楚地审查软件产品6、 人员应该少而精7、 不断改进软件工程的实践性持续改进：不断的在工作、测试中发现bug并且改进的过程测试体系、测试咨询常用的术语文档的英文名称软件需求说明书HLD 概要设计LLD 详细设计Coding 编码Unite test 单元测试System test 系统测试UAT 验收测试名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - -

3、- - - - 名师精心整理 - - - - - - - 第 1 页，共 21 页 - - - - - - - - - 1、瀑布模型：软件生命周期的阶段和工作内容：阶段研究问题给出的标准和文档问题定义问题是什么？目标个规模报告书可行性研究有可行的方法吗？高层逻辑模型、数据流图、成本效益分析需求分析系统做什么逻辑模型、 数据流图、数据字典、算法描述总体设计如何解决问题？系统流程图、系统结构层次图详细设计怎样具体实现？编码规格说明、HIPO图或 PDL 编码和单元测试给出正确的程序模块源程序清单、单元测试方案和结果综合测试给出符合要求的软件综合测试方案和结果、一致的软件配置维护持久的满足用户需求完

4、整地维护记录、文档、软件新版本2、 V 模型：名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 21 页 - - - - - - - - - 需求分析验收测试（ UAT) 概要设计系统测试详细设计单元测试Coding 二、软件质量1、质量与质量模型因素（特性）：如 正确性、精确性、可靠性、容错性、性能、效率、易用性、可理解性、简洁性、可复用性、可扩充性、兼容性等。2、质量保证软件测试概念验证程序是否符合需求的一个过程测试： 1、它能做什么2、它不应该做什么概念; 广义：软件

5、生存周期中所有的检查、评审和确认工作，其中包括了对分析、设计阶段、以及完成开发后维护阶段的各类文档、代码的审查和确认。狭义：识别错误测试目的： 为了度量和提高被测试软件的质量，对测试软件进行工程设计、 事实和维护的整个生命周期。测试分类： 1 按阶段分：单元测试：集成测试：系统测试：验收测试：2.按目的分（1）功能测试（2）非功能测试： A.性能:a.并发（响应时间） b.稳定性（ 7*24 5*8 查找内存泄漏）c.容量测试， d.压力测试。*测试数据的准备1.编造数据 2.从项目组或生产名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - -

6、 - - 名师精心整理 - - - - - - - 第 3 页，共 21 页 - - - - - - - - - 环境中获取。B安全测试（复制链接，回退）C界面测试（布局要合理，色调风格一致）D易用性测试，安装 /卸载测试E本地化测试，兼容性测试，恢复/备份测试（实时系统）F健壮性测试，可靠性测试（少）3 透明度分白盒测试黑盒测试灰盒测试4 执行方式静态测试动态测试二测试要点1.测试规律BUG 的 80-20的原则1.在分析，设计，实现阶段的复审和测试工作能够发现和避免80%的 Bug。2.而系统测试又找到其余Bug 的 80%。3.最后的 5%的 Bug只可能再有用户的大范围， 长时间使用后

7、才会暴露出来。木桶原理软件质量不是只有软件测试一个方面决定的它是由各个方面共同决定的。2.测试的重点1.良好的用例设计 ，2.好的测试工作管理 （使工作有条不紊的进行减少风险）3.独立的测试环境4.软件测试的质量可以发现以下软件缺陷：1 软件实现的功能的不正确2.缺少 软件没有实现的某个功能3. 多余 ” 软件实现的某项功能在需求中没有定义。软件测试本身的质量在于：发现软件缺陷并能区分其类型，提供关于软件质量和开发过程质量的信息。5.软件测试度量A 测试覆盖率：（a有多少需求被测试用例所覆盖。被覆盖的需求/总需求 *100% b 被执行需求 /总有效需求 *100% 需求执行率或被测率c 执行

8、用例数 /总用例数 *100% 用例执行率（考察测试人员工作效率）d 通过的用例 /总的执行的用例 *100% 用例通过率（评价软件质量） ) B 缺陷发现率：1.缺陷数目（1）统计个数（按严重级别按功能分布按开发人员 按缺陷状态等统计）缺陷修复率 =修复并已经通过的缺陷/发现的有效缺陷总数*100% 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 21 页 - - - - - - - - - 缺陷遗留率 =上线后发现有效缺陷/测试发现的有效缺陷*100% （考核测试人员

9、）C 测试成功率2008-8-5笔记一 、测试分类1、阶段分：单元unite test （测试单元：把整个代码分成小的单元）最靠近编码集成integration test （自上而下、自下而上、宽度、深度四种集成方式）系统system test （把整个被测系统放到大的系统中测试）验收user acceptance test （由客户组织或委托第三方的测试，测试具有合同约定性质如果通过意味着客户接受了这个系统。包括性能、功能的测试以及文档）前三个是开发商主导测试只有验收是用户来执行性能performance test 功能functional test Weblogic 中间件 (Bea 公司

10、开发被 Oracle 收购 ) middle ware websphere (IBM 公司的 )Oracle DB2 用于大型企业SQL server 用于中小型企业 Data base administrator 数据库管理员大型企业才会有2、目的分：功能：检测功能好不好使。非功能 ：性能： 【性能测试即测试软件处理事务的速度，一是为了检验性能是否符合需求，二是为了得到某些性能数据供人们参考（例如用于宣传） 。 】性能测试涉及 -测试数据的准备 ：编造、从项目组或生产环境中获取并发：多人在线操作，响应时间，要求尽可能的短。稳定：7*24 或 5*24 小时，不当机不停机，正确执行。容量测试：

11、大数据的处理。压力测试：即负荷测试，获取系统能正常运行的极限状态。界面测试：网站，布局合理。色调、风格的统一，不能出现窜行、错别字，图片不要过大等。易用性：用户使用着方便。安装/卸载（uninstall ） ：大部分软件都需要安装後才能使用。安全测试：不允许绕过登录界面，进入系统中来。本地化：汉化。兼容性：测试软件运行在不同操作系统下，硬件环境下是否正常恢复/备份：健壮性：在异常情况下，软件还能正常运行的能力。（含义：1、容错性可靠性测试：一定环境下，在给定的时间内，系统不发生名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师

12、精心整理 - - - - - - - 第 5 页，共 21 页 - - - - - - - - - 故障的概率。3、按透明度分：黑盒测试 ：black box 只注重输入输出，不管里面的实现情况，将整个系统当成一个黑盒子常用方法： 等价类、边界值、因果图、错误推测法白盒测试 ：white box 更注重内部的逻辑结构分支。灰盒测试 ：gray box 介于二者之间，即关心输入输出，也关心内部逻辑4、按执行方式分：静态测试 ：指不实际运行软件，主要是对软件的编程格式、结构等方面进行评估动态测试 ：运行程序，输入各种值来进行测试。Alpha 测试 Beta 测试回归测试： regression t

13、est 关联性冒烟测试：在测试之前对主功能和主路径的测试前哨测试：确认测试：嵌入式测试：主要测试和硬件有直接联系的软件如路由器二、测试的一些要点1、测试的规律Bug的 80-20原则（1） 、在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的 BUG。（2） 、而系统测试也能找出其余BUG 中的 80% 。（3） 、最后的 5%的 Bug 可能只有在用户的大范围、长时间使用后才会暴露出来。80/20原则1、80%的工程量用在 20%的需求上2、80%的开发成本花费在20%的部件上3、80%的错误是由 20%的部件引起的4、80%的延期或返工木桶原理（1） 软件质量的关键因素是分析、

14、设计和实现， 测试应该是融于其中的补充检查手段， 其他管理、 支持、甚至文化因素也会最终软件的质量（2）2、软件测试的重点（1） 、测试用例的良好设计：用例覆盖是否全面用例是否有效- 测试用例的设计是整个软件工作的核心- 测试用例反映对被测对象的质量要求，决定对测试对象的质量评估（2） 、测试工作的管理：工作有条不紊的进行减少风险名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 21 页 - - - - - - - - - - 尤其是对包含多个子系统的大型软件系统，其测试工

15、作涉及大量人力和物力，有效的测试工作管理是保证有效测试工作的必要前提（3） 、测试环境的建立：（或独立的测试环境）测试环境应该与实际测试环境一致功能测试：中间件数据库一致性能测试：中间件数据库 程序 硬件 都要一致（4） 、软件测试的质量：软件测试可以发现以下软件缺陷-软件实现的功能不正确-“缺少” ，软件没有实现某项功能-“多余” ，软件实现的某项功能在需求中没有定发现第一类软件缺陷的过程-“验证validate”发现後两类软件缺陷的过程-“确认 verification”软件测试本身的质量在于：-发现软件缺陷并能区分其类型-提供冠以软件质量和开发过程质量的信息缺陷的数量+ 严重级别+ 功能

16、分布来评判软件的质量缺陷的数量+ 严重级别+ 功能分布 + 开发人员来评价开发人员的开发质量。缺陷严重级别共分 5 级（5） 、软件测试度量测试覆盖率：-有多少需求被测试用例所覆盖，代码已经被测试了。测试覆盖率 =已被覆盖/ 总数（有效） 100% 需求的执行率 =已被执行的 /总数*100% 测试执行用例执行率 =已执行的测试用例 /总数*100% 工作效率用例的通过率 =已通过的 /总的已执行数 *100% 软件质量缺陷修复率 =已修复的缺陷/ 发现有效的缺陷100% 缺陷遗留率 =上线后发现的有效缺陷/ 测试有效缺陷100% 缺陷发现率-缺陷是何时被发现，并且有多少缺陷已经被发现。缺陷：

17、按严重性来分类- 缺陷数目- 缺陷的严重性按功能分布按开发人员按缺陷状态测试成功率：3、测试的原则名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 7 页，共 21 页 - - - - - - - - - (1)、所有的测试都应追溯到用户需求(2)、应该在测试工作真正开始前的较长时间内就进行测试计划(3)、8/2 原则应用于软件测试(4)、测试应从“小规模”开始，逐步转向“大规模”。(5)、穷举测试是不可能的。(6)、为了达到最佳效果，应该有独立的第三方来构造测试。(7)、不充分的测试

18、是不负责任的；过分的测试是一种资源浪费，同样也是一种不负责任的表现。1.应当把“尽早和不断的测试”作为开发者的座右铭。2.程序员应当避免检查自己的程序，测试工作应当由独立的专业的软件测试机构来完成。3.设计测试用例时应当考虑到合法的输入合不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断；电源断电情况。4.一定要逐一测试中的错误集中发现现象，这和程序员的编程水平和习惯有很大的关系。5.对测试错误结果一定要有一个确定的过程，一般有A 测试出来的错误，一定要有一个 B 来确认，严重的错误可以召开评审会进行讨论和分析。6.制定严格的测试计划，并把测试时间安排的尽量宽松

19、，不要希望在极短的时间内完成一个高水平的测试。7.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的情况并不少见。8.妥善保存一切测试文档，意义是不言而喻的，测试的重现性往往要靠测试文档。4、测试人员的基本素质（1） 、沟通能力：表达和 获取别人表达的信息（2） 、移情能力（3） 、技术能力（4） 、自信心（5） 、外交能力（6） 、幽默感（7） 、很强的记忆力（8） 、耐心（9） 、怀疑精神(10)、自我督促(11)、洞察力5、测试人员的服务对象（1） 项目经理（2） 程序员（3） 技术文档编写人员（4） 技术支持（5） 市场开发名师资料总结 - - -精品资料欢迎下载

20、 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 8 页，共 21 页 - - - - - - - - - （6） 管理层和项目相关人员（7） 用户测试人员关注失效，客户才能关注成功 6、缺陷报告 Bug Report FAQ常见问题解答用途：1、报告提示大家注意缺陷，并帮助程序员定位内部问题2、报告提示大家注意规格说明和测试文档、用户文档或开发工具中的问题3、为技术文档编写愿提供背景信息， 编写元要编写手册或公司网站中的问题定位部分4、报告提示需要通过客户培训解决的问题5、报告为客户售后技术人员提供关键的信息，他们会了解到

21、产品上线后还没有被解决或没有完全解决的问题6、报告向管理层提供正在开发的产品的状态和质量7、报告在开始计划产品下一个版本是，提供初始改进建议永远不要假设明显的程序缺陷已经写入报告明确严重等级和优先级的差别严重级别（ sevenity ）表示程序错误的影响后果优先级别（ priority）一般情况下严重级别和优先级别成正比。1、 为每一步编号2、 不要跳过重现缺陷的人和步骤3、 精简缺陷重现步骤4、 通过空行提高报告的可读性。8.6 号集成测试：集成测试的任务：1模块连接起来检查模块互相调用数据是否会丢失。2组合后是否能达到预期功能。3模块间是否相互影响。4全局的数据结构是否会有问题会不会被一场

22、修改。5单个模块误差累计错误是否会放大。集成测试方法：1. 非增量式测试方法。一步到位进行测试。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 9 页，共 21 页 - - - - - - - - - 2. 增量式测试方法（1）自顶向下增量测试（2）自底向上增量式测试三系统测试需求：功能需求和非功能需求。在需求分析阶段要确定软件的可测性（通过某种方式进行验证），保证有效完成系统测试工作。需求具有准确性没有二义性。系统测试内容：功能测试所有性能要求得到满足。其它需求（）系统测试的任务：

23、1. 功能测试2.性能测试3.恢复测试4.安全测试5.强度测试6.其它限制条件的测试系统测试技术和测试数据： 完全采用黑盒测试， 测试数据尽可能像真实数据一样精确和有代表性，也必须和真实数据的大小和复杂性相当。测试用例 Test Case （TC）要求复用性。四.验收测试名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 10 页，共 21 页 - - - - - - - - - 一般也是黑盒测试，数据用生产环境的备份数据。验收的四类内容：1. 功能需求2. 性能需求3. 交互质量需求4

24、. 全面的软件质量需求五，回归测试（ R）可以采用人工也可以使用工具（QTP）来执行。分类：全回归工作量大耗人力部分回归工作量小 功能肯能有遗漏测试流程：1. 测试文档及作用测试文档是对要执行的软件测试及测试的结果进行扫描，定义，规定和报告的任何书面或图示信息。测试文档的作用1 促进项目组的成员的交流沟通2 便于对测试项目的管理3 决定测试的有效性4 检验测试资源5 明确任务的风险6 评价测试结果7 饭便在测试名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 11 页，共 21 页 -

25、 - - - - - - - - 8 验证需求的正确性。测试文档分类：前置作业文档和后置作业文档日常测试情况汇报包括：周报和日报。测试流程测试计划 *工作规划（资源使用安排进度风险预估及规避方法测试范围）测试计划测试方案测试设计测试需求分析测试需求文档用例设计 TC 测试准备及实现测试环境测试数据测试脚本 SQL语句模拟客户端等产生脚本 (script)文件数据文件程序测试执行执行测试用例发现缺陷产生文档：测试日报周报和缺陷报告测试评估对软件进行质量评估分析报告在以上每个阶段完成进行评审以保证质量。测试前评审获取相关部门的认可。 2 测试人员沟通使认识没有偏差3. 4分析报告的评审对软件最后能

26、否上线达成一致。测试方案（既怎么做）制定测试计划目的：1. 是测试工作更顺利2. 促进项目参加人员彼此沟通3. 是软件测试工作更易于管理。制定测试计划的原则：（时间 1.5 倍预测时间）名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 12 页，共 21 页 - - - - - - - - - 1. 制定测试计划应尽早开始2. 保持测试计划的灵活性3. 保持测试计划简洁易读4. 尽量争取多渠道评审测试计划5. 计算测试计划的投入。制定测试计划是面对的问题：(解决办法多沟通 ) 1. 与

27、开发者意见不一致2. 缺乏测试工具3. 培训不够4. 管理部门缺乏对测试工作的理解和支持5. 缺乏用户的参与6. 测试时间不足7. 过分依赖测试人员8. 测试人员处于进退两难的状态9. 不得不说“不” property 属性：作者（ author ）覆盖状态（ cover status ）not completed( 没有测试用例覆盖 )NO Run 与用例关联但没有被执行 Passed 所有测试用例都通过 failed 测试用例有没有通过的 not Iomplete 3个用例两个测试通过一个还没有测创建时间 Creation Date修改时间 modified 测试需求：优先级 priori

28、ty需求 ID Req ID 产品 Product 名称 Name 类型 Type 复查 Reviewed（蓝字必须有）来源于业务需求或软件需求测试设计：名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 13 页，共 21 页 - - - - - - - - - 测试用例：一般指对一项特定的软件产品进行测试任务的描述体现测试方案，方法技术和策略。测试用例的设计： 1. 为实施一次测试而向被测系统提供的输入数据操作和各种环境设置，期望结果的一个特定的集合。2. 控制着软件测试的执行步骤3

29、. 是对测试方案中每个测试项的进一步实例化。测试用例属性：创建日期描述（Description） 设计者（Designer ）估计开发时间 (Estimated DevTime) 执行状态 (Execution Status) 修改（ Modified ） 状态（ Status ） 步骤（Steps）主题 (Subject) 模板(Template) 测试名称 (Test Name) 类型（ Type）前置条件输入数据输出数据测试用例的编写原则1. 测试用例的代表性2. 测试结果的可判定性3. 测试结果的可再现4. 准确性5. 简洁性（ 3-9 步之内）6. 可重用性7. 可跟踪性8. 适用性

30、名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 14 页，共 21 页 - - - - - - - - - 复用的意义： 1. 减少工作量 2. 易于维护 3. 易于复审。对测试数据的要求：1. 功能测试不需要大量数据2. 功能测试需要数据覆盖率高3. 功能测试的测试数据要求尽量真实4. 性能测试需要大量的数据5. 性能测试的测试数据应尽可能的达到符合实际的数据分配。测试执行：是执行所有的的或选定的一些测试用例，并观察其测试结果的过程。其过程由四部分组成1. 输入2. 执行过程3.

31、检查过程4. 输出软件测试的执行内容：-执行测试用例-记录原始测试数据-记录缺陷-多所有的缺陷进行跟踪，管理和监控。测试集 test set(存在有 TD工具中的再测试纯理论中不存在) 作用可以重复 TC ，执行结果执行流： execute flow. 具有先后顺序的一些测试用例的组合。执行条件状态： Finish完成做了不管结果名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 15 页，共 21 页 - - - - - - - - - Pass 通过做了必须做对。实际结果：用来和预期

32、结果进行对比的。缺陷：就是与需求不符的地方。不符合下面五个规则里的一个就叫做缺陷：1. 软件未达到软件规格说明书中行规定的功能2. 软件超过软件规格说明书知名的范围3. 软件未达到软件规格说明书中指出的应达到的目标4. 软件运行出现错误5. 软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。软件缺陷的种类：1. 功能不正常2. 使用上不方便3. 软件的结构为做到良好的规划4. 功能不充分5. 与软件操作者的互动不良6. 使用性能不佳7. 为做好错误处理8. 边界错误9. 计算错误10. 使用一段时间所产生的错误11. 控制流程的错误名师资料总结 - - -精

33、品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 16 页，共 21 页 - - - - - - - - - 12. 在大数据量压力之下所产生的错误13. 在不同硬件环境下产生的错误14. 版本控制不良所产生的错误15. 软件文档错误缺陷分类：操作级和结果级的缺陷的属性：实际修复时间分配给关闭日期注释缺陷 ID 描述检测者检测版本检测日期修改日期计划关闭版本优先级可重现状态主题概要8.7 号缺陷的生命周期名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - -

34、 - 名师精心整理 - - - - - - - 第 17 页，共 21 页 - - - - - - - - - 缺陷的生命周期：缺陷从发现到修复（关闭）的全部过程。缺陷状态： 1. 新 2. 打开 3. 修复 4. 重新打开 5. 关闭 6. 否决缺陷是独立的， 缺陷管理分为缺陷跟踪和缺陷管理（除了追踪还包括汇总分析缺陷种类的定义， 市面上有专门的管理工具如bugziller和jira ） 。TD(测试管理工具 ) 测试评估与报告测试评估是在测试结束后对整个测试过程与产品进行评估的过程。评估过程包括：工作总结，过程评估，缺陷分析，（结论，留给上司）测试评价主要包括覆盖评价和及质量和性能评价。测

35、试评估： 1. 结合量化的测试覆盖率及缺陷跟踪报告2. 对软件项目的质量和开发团队的工作进度及工作效率（最好别写）进行综合评价3. 生成相应的报告或报表评估包括： 1 测试工作的评估 测试覆盖面，用力执行，工作完成情况2 软件质量的评估：需求通过，用例通过，缺陷情况，测试报告的意义：1. 以测试报告的形式像整个软件开发部门报告测试结果既发现的缺陷或错误。2. 撰写测试报告的目的是为了让整个软件开发部门了解软件开发的进展情况以使缺陷能够迅速得到修复；名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - -

36、- - 第 18 页，共 21 页 - - - - - - - - - 3. 测试报告的格式并无定义，要求能够完整，清楚的反应当前的测试进展情况，明白易懂，无二义性。测试计划模板：1. 测试计划标识2. 介绍3. 测试项4. 需要测试的功能5. 不需要测试的功能6. 方法7. 测试项的通过 / 失败准则8. 暂停准则和恢复准则9. 测试完成所提交的材料10. 测试任务分配11. 环境需求12. 职责和分工13. 人员及培训要求14. 时间表15. 风险及规避方法（应急措施1. 增加人员 2. 延时 3. 增加预算 4. 减少工作量）16. 审批人17. 策略 两种标准一 . 以时间为目标二.

37、以质量为目标名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 19 页，共 21 页 - - - - - - - - - *制定策略考虑以下内容：a 要使用的测试方法b. 确定质量风险c. 测试完成和测试成功所采用的评价标准d. 有关资源要求或涉及进度的特殊考虑e. 测试类型，评估标准以及测试方法f. 确定资源测试需求：软件需求完整的话直接转为测试需求。按照以下步骤来执行：1. 确定软件提供的主要任务2. 对每个任务，确定完成该任务所要进行的任务3. 对于对时间有要求的交易，确定所要的

38、时间和条件4. 确定会产生大量意外的压力测试，包括内存硬盘空间高的交易率5. 确定应用需要处理的数据量6. 确定需要的软件和硬件配置7. 确定其他与应用软件设置没有直接关系的商业交易8. 确定安装过程9. 确定没有隐含在功能测试中的用户界面要求。用功能分解的方法做测试需求含义：把软件分解为相对独立的功能单元。首先按系统来分例STTE分为七个模块，每个模块下还有子模块；再名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 20 页，共 21 页 - - - - - - - - - 往下，功

39、能，比如知识点管理，增删改。A级高风险B级中等风险C低级风险功能类型数据计算 / 验证例子：利息的计算数据的改变例子：修改客户信息数据的显示例子：显示客户信息业务影响合法性例子：违反权限管理机制错误信息例子：普通错误无使用频率非常频繁例子：开户每天都有 N次经常例子：销户极少例子：挂失受影响客户数量大量 / 非常重要例子： 取款/VIP 客户组/ 群例子：网上缴电话费一些例子：营业员报表一个需求最少对应两类用例正向的和反向的。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 21 页，共 21 页 - - - - - - - - -