《软件测试基础：方法与度量-王锐》由会员分享，可在线阅读，更多相关《软件测试基础：方法与度量-王锐（34页珍藏版）》请在金锄头文库上搜索。
1、软件测试基础： 方法与度量（1）,王锐 2018/9/12,提纲,软件测试现状 软件测试与质量保证 软件测试的方法：MIT方法介绍 软件测试度量基础,引子,主管问测试人员，“你已经测试过了吗？可以进行发布了吗？” 测试人员回答：“是的，我测试过了。可以往下进行了。” 主管问道：“那么，你测试了什么？” 测试人员回答：“我测试过它了”,现实：我经常被问到的问题 测试覆盖了哪些需求？ 测试效率（编写用例、执行测试）如何？ 缺陷收敛吗？缺陷曲线合理吗？ 版本可以正常发布吗？思考： 为什么不能准确回答以上问题？,对于软件测试人员的一份调查结果： 在测试中常用到的度量类型仅仅是错误数以及将错误按严重等级
2、分类 多数测试人员具有自动测试工具经验，但测试自动化也是实现和维护测试过程的最困难的测试技术。 测试经历较少的被调查者对测试术语提供了最精确的定义，而经常执行测试的人对测试提供了最糟糕的定义。,结论： 测试人员的认知水平有待改进。为什么会有这种认知现状？这种局限性是如何产生的？,历史回顾,20世纪80年代大铁家伙的统治时代，只有少数人开发和测试软件，多数人为工程中各层次的工程师。 20世纪90年代快速应用开发技术（RAD）被采纳竞争加剧，市场驱动发布策略，消费者最有可能购买市场上第1个能满足其功能的产品，而不一定是最可靠的产品。 过去10年大多数质量改进得益于标准化和开发过程改进,测试人员的转
3、机当消费者把可靠性看得比功能和费用更重要的时候，质量的砝码则从市场第一转向可靠性，使用正规方法和度量的好坏成为公司生存和毁灭的差别所在。 问题：许多组共同分割预算，因此测试组必须有充分的理由。对测试人员的最低要求是测试的效果是必须能为产品增值，而增加测试可信度的方法就是使用正规方法和良好的度量。,当前测试人员所面临的挑战,1、没有规格说明就没有测试 名词解释： 测试将实际结果与标准进行比较 验证通过研究，与标准比较或引用事实的方式测试或检查精确性或正确性。即“系统做了应该做的事情吗” 确认按照法规或约定，证明有效的状态、质量或事实。确认回答“系统执行正确吗”，要求测试人员的主观判断。 测试人员
4、的工作验证确认 经常发生的事：为说服开发人员软件中有错误，测试人员必须具有说服力和较高的个人威信，因为没有标准可以参照。,当前测试人员所面临的挑战,2、迫于市场或企业压力而忽略测试测试还没能被证明是成功发布产品的需要，测试被认为是主要的开销部分，而不是为底线增值的贡献者。,当前测试人员所面临的挑战,3、缺乏训练有素的测试人员在安全性苛刻的企业中：552在商业软件企业中：上世纪90年代后期只有10的测试人员和开发人员具有测试技术培训的经历。在大多数公司中测试不是一个受尊敬的职业，只是职业生涯中的一个阶段。 4、标准减少了对测试的需求最重要的和可见的软件质量改进并非是测试的结果，而是被intern
5、et驱动的标准化结果，消除了对大量底层测试的需要。,软件测试与质量保证,质量保证定义：为确保产品或服务满足规定的质量要求，提供所有必要的计划和系统的活动。 软件测试是质量保证的手段之一。 在美国，很少有软件开发公司有全职的质量保证人员。原因：在大多数情况下，传统的正规质量保证并非是为产品增值而具有良好费效比的方式。,软件测试与质量保证,一些正规的质量保证原则与当今商用软件开发现实不太相符。 关于质量的六大谬误： 1、质量需求决定进度 2、质量可靠性 3、用户清楚他们的需求 4、需求就是正确的 5、如果功能和可靠性好的话，用户就会接受产品 6、要求产品的成熟性,改进质量过程,质量要在时机、价格、
6、功能、可靠性以及为客户提供满意支持之间达到平衡。 1、为质量选择正确的构成质量可以通过客户满意度最有效的量化 2、正确选择适合开发环境的质量控制工具 自动化跟踪协同 改进文档技术 3、使用可行的方法和度量培训测试人员,管理软件测试的方法,拉斯维加斯的例子管理者不能靠猜测行事,管理软件测试的方法,必须设计一种测试方法作为被使用的开发方法的补充，最后将度量数据转换为管理者认为确实有价值的信息。,工程方法,工程实践的一些基本规则，对软件工程师和测试人员具有特定意义： 说明遵循的方法及理由：说我所做的 说明你的假设：公布并进行广泛评审 考虑适当安全系数 始终听取乙方评价：让别人检查你的工作如何确定安全
7、系数并不重要，重要的是使用安全系数改进评估,集成和测试的方法,自底向上方法 过程：单元测试后将模块组合起来测试，使用模拟器代替必要但还没有实现的模块，当组合好的模块稳定后，再增加更多的模块直到整个系统被组装完成。 优点：比较严格和彻底 缺点：费时，测试人员在测试模拟器而不是实际系统，需要预先知道在一些单元功能不正常时系统将会如何运行。 没有一个实际的系统其功能完全与模拟器一样。,集成和测试的方法,自顶向下方法 过程：每个模块单元测试后将所有可用的模块组装在一起，作为一个系统的整个组从最顶层，通常是从用户界面开始测试，尽可能少用模拟程序。 优点：关注整个系统 缺点：覆盖率低，单元模块要完整，如果
8、大部分时间用于诊断错误较多的单元，则整个系统的测试无法顺利完成。,测试组的组织策略,在管理层之下成立独立的测试组织 将测试组放到开发阶段中 完全没有测试组织 将测试组放到运行阶段中,最佳方法,理想情况下，尽可能根据需要使用多种方法，在测试中想法越多，发现的缺陷就越多。 如果构造块或单元比较稳定，自顶向下测试是完成测试的最有效方法。 如果单元的质量不确定，或出于高可靠性、安全性的考虑，自底向上方法是必要的。 如果开发倾向于RAD/Agile工作方式，具有一个综合管理者协调组间沟通的自顶向下的测试可能是最佳的方法。,MIT方法,最重要测试（Most Important Test）方法是一种基于系统
9、故障风险辅助规划测试工作的方法，主要用于自顶向下的系统测试、集成测试和功能测试。 MIT方法的核心是基于一个测试统计表，测试人员通过几种技术识别需要测试的部分，评估项目的各个组件、特性和功能的风险。风险被转化为优先级系统，其中最重要的部分是重点测试部分。,MIT能做什么,计划阶段 为确定适合规定时间段的测试工作量提供了手段 测试阶段 跟踪过程并确定测试工作的合理结束日期。 度量测试工作的效果，一遍在今后调整和改进测试方法、假设及测试说明。,MIT是如何工作的,我们对项目有多了解？ 测试工作量有多大？ 如果我们不能测试所有测试项，应该测试什么？ 测试工作将持续多长时间？ 测试开销是多少？ 如何表
10、示要执行的测试？ 我们能满足进度要求吗？我们的测试充分吗 测试工组成功吗？测试覆盖率适当吗？,MIT方法的步骤,计划驱动测试工作的MIT 结构化的RAD或敏捷测试工作的MIT 完全自由的RAD/Agile测试工作的MIT 具有多种开发方法的集成项目,软件测试度量基础,外祖母做蛋糕的例子度量的基础是标准,基本测试度量：它有多大,时间运行测试所需时间测试工作可用时间 开销 测试数量、大小、重要性或优先级,错误的度量,严重性 错误类型分类 发现错误数 在产品发布或投入使用前发现的测试人员每小时发现错误的数量：错误发现率 产品发布后的错误：产品故障数,错误的度量,每个单元模块的错误密度用于分配测试和开
11、发资源。 在最新模块或试验性最强的模块中往往错误密度大。 错误组成：有多少错误是严重的？ 错误修复率：修复了多少发现的错误错误修复率测试中修复的错误数/测试中发现的错误100一份研究说明：出现在产品中的问题有三分之二已经在系统测试过程中被检测出来，然后因为测试工作不能再现或者隔离这些错误，错误已被转移到系统的生产中。,度量测试工作的度量元,测试覆盖率：有多少已被测试 测试覆盖率（绝对值）执行的测试/整个测试100单元测试能做到，但系统测试做不到。 系统测试覆盖率（相对值）执行的测试/整个测试说明100这个度量依赖于测试说明的质量和完整性。 测试有效性：测试有多好 目标：在一定时间范围内从测试说
12、明中选择最小测试集合发现最多的错误。 有效性测试发现的错误/总共发现的错误100其中发现错误总数测试中发现的错误用户发现的错误 测试有效性不同于效果度量，因为它不统计错误是否被修正,测试它的开销是多少,当使用MIT测试方法时，就有可能向管理者说明它有多大以及在给定时间和资源内要求什么级别的测试覆盖率。基于这一点，就有可能计算开销。,衡量效果的度量：它值得吗,评估一个正在进行的测试工作是有一定困难的，测试人员持之以恒的度量是证明效果的关键。测试工作效果修复的错误数/总共发现的错误数100测试工作的最终效果，还包括其测试覆盖率、错误修复率、在发布产品中出现或要求修复的严重错误数。,答案,正如我们所
13、承诺的那样，已经完成了测试说明的67。我们所运行的测试是通过风险分析所确定的测试说明中最重要的测试。错误发现率以及错误的严重程序均在预期范围内，错误修复率为85。 自从发现严重等级1的问题到现在已经3周了，目前还未发现严重等级1的问题，对于上次发现的严重等级2的问题已经修复并进行了回归测试。测试人员针对一些新模块进行了一些附加测试，从整体上看，系统是稳定的。 负载测试结果已见分晓，系统运行负载达到设计指标的90即出现故障，系统工程师认为她们已经知道这个问题，但声称需要3个月完成修复。项目组声明的负载峰值为75，如果实际负载超过90，系统将失败。 我们的建议是按时发布，在安装修复版本之前，如果系统的使用超出项目的限制，这种情况是可以理解的。,谢谢！,
