第2章 软件测试策略.pptVIP

软件测试 第2章 软件测试策略 目 录 软件测试的分类 按照开发阶段划分 单元测试：模块测试，检查每个程序单元嫩否正确实现详细设计说明中的模块功能等。 集成测试：组装测试，将所有的程序模块进行有序、递增的测试，检验程序单元或部件的接口关系 系统测试：检查完整的程序系统能否和系统（包括硬件、外设和网络、系统软件、支持平台等）正确配置、连接，并满足用户需求。 确认测试：证实软件是否满足特定于其用途的需求，是否满足软件需求说明书的规定。 验收测试：按照项目任务或合同，供需双方签订的验收依据文档进行的对整个系统的测试与评审，决定是否接受或拒收系统。 软件测试的分类 按照测试技术划分 白盒测试：通过对程序内部结构的分析、检测来寻找问题。检查是否所有的结构及逻辑都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。--结构测试 黑盒测试：通过软件的外部表现来发现错误，是在程序界面处进行测试，只是检查是否按照需求规格说明书的规定正常实现。 灰盒测试：介于白盒测试与黑盒测试之间的测试，关注输出对输入的正确性；同时，也关注内部表现，不像白盒那样详细，只是通过一些表征性现象、事件、标志来判断内部的运行状态。 软件测试的分类 按照测试实施组织划分 开发方测试：开发方通过检测和提供客观证据，证实软件的实现是否满足规定的需求，在开发环境下，开发方对提交的软件进行全面的自我检查。 用户测试：在用户的应用环境中，用户通过运行软件，检测软件实现是否符合自己预期的要求，这里指用户的使用性测试。 第三方测试：介于软件开发方和用户方之间的测试组织的测试。 软件测试的分类 按程序对象分 面向测试对象粒度的划分 按测试方法分类 按运行状态分类 面向软件测试实施者的划分 嵌入式软件测试与非嵌入式软件测试 软件测试的原则 1 完全测试的不可能性 例: 测试windows计算机器 原因： 输入量太大 输出结果太多 软件执行路径太多 软件说明书是主观的，没有客观标准。 2 软件测试是有风险的活动 Software Testing is a Risk-Based Exercise 如果不选择完全测试所有情况，那就是选择了冒险 Not to test every possible test scenario, Customer will eventually find it someday. 如：1024+1024=2048 矛盾： Testing vs. Release deadline Stop testing vs. Costly bug 关键测试要点： 把数量巨大的可能测试减少到可以控制的范围 针对风险做出明智的选择，哪些测试重要，哪些不重要 3.测试无法显示潜伏的软件缺陷和故障 软件测试员可以报告软件缺陷存在,却不能报告软件缺陷不存在. 可以进行测试,发现并报告软件缺陷,但是任何情况下都不能保证软件缺陷不存在. What can you do?! 唯一的方法: 继续测试,找到更多的缺陷 4. 充分注意测试中的群集现象 缺陷可能成群出现 发现一个,附近就可能有一群 缺陷一个接一个 可能的原因: A.程序员也有心情不好的时候 B.程序员往往犯同样的错误 C.有些软件故障可能是冰山一角 6.并非所有的软件缺陷都要修复 虽然测试员尽了最大的努力，但并非找到的所有软件缺陷都要修复。 并非意味着软件测试员没有达到目的. 解决办法 依赖软件测试员的素质—进行良好的判断，根据风险决定哪些缺陷需要修复，哪些不需要修复。 7.难以描述的软件缺陷 如果软件中存在缺陷，但没有人能够发现，算不算缺陷？ 软件缺陷的定义： (1)软件未达到产品说明书中已经标明的功能； (2)软件出现了产品说明书中指明不会出现的错误； (3)软件未达到产品说明书中虽未指出但应当达到的目标； (4)软件功能超出了产品说明书中指明的范围； (5)软件测试人员认为软件难以理解、不易使用，或者最终用户认为该软件使用效果不良。 一棵树在森林中倒下，没有人看见听见，它发出声音了吗？ 8） 80-20 原则 第一个含义：80% 的软件缺陷常常生存在软件 20% 的空间里。如果想使软件测试有效，就要更加关注那些经常或者可能出现错误的程序段 ，在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。 8） 80-20 原则  第二个含义：在系统分析、设计、实现阶段的复审工作中能够发现和避免 80% 的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的 80% ，最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。 8