软件工程 Software Engineering

Size: px

Start display at page:

Download "软件工程 Software Engineering"

国司
4 years ago
Views:

1 软件工程 Software Engineering 廖清计算机科学与技术学院 1

2 课程简介任课老师 : 廖清, C 栋 303B 室 liaoqing@hit.edu.cn 课程网站课件作业要求各类通知 / 消息均在此网站发布 :liaoqing.me 教材及参考书 Rogers S. Pressman. Software Engineering: A Practitioner s Approach (Seventh Edition). 软件工程 : 实践者的研究方法, 第 8 版, 机械工业出版社,2016 年 11 月,ISBN ); 孙家广刘强, 软件工程 - 理论方法与实践, 高等教育出版社,2010 年 11 月,ISBN ; 考试平时作业 10% 实践项目 40% 期末考试 50% 2

3 善用开源社区助教韩浩栋 303C 室, 杨林栋 303C 室, Github 上有注册用户 2700 万人 GitHub 托管 2000 多万个开源软件,StackOverflow 超过 8600 万条在线知识条目 3

4 教学目标课程目标 : 从工程学角度认识软件在大型系统中的设计和应用, 具备作为软件工程师从事工程实践所需的专业能力能力培养目标 : 需求定义与分析权衡和选择设计方案使用 UML 建模开发高质量软件运用软件工程工具团队协作开发谈判与沟通转变对软件开发的认识 : 程序系统转变思维定式 : 程序员软件工程师 4

5 实践项目 16 学时, 实验课上报告 + 课后实践学生每 4-5 人一组, 选定一个来自实际需求的应用软件系统, 利用所学软件工程知识进行需求分析设计开发测试过程与项目管理源代码管理版本控制期间组织 4 次口试 ( 立项需求分析设计与开发最终验收 ) 不管是 4 人一组 5 人一组独立完成, 组内成员均获得同样的成绩开题报告 10% 实践项目 40% 第一轮迭代 10% 第二轮迭代 10% 测试验收 10% 5

6 课程章节安排第一章软件工程概论第二章软件项目开发过程与管理第三章软件需求工程第四章软件设计第五章软件编码测试与质量保障第六章软件实施维护与演化第七章软件工程新技术展望第八章案例分析实践项目理论课 :32 学时实践课 :16 学时 6

7 Project Schedule 第一次实验课 (4 th,december, 2018) 课上项目 PPT 介绍 ( 每组 3-5 分钟 ) 第二次实验课 (11 th, December, 2018) 第三次实验课 (18 th, December, 2018) 第四次实验课 (25 th,december,2018) 项目设计, 项目实践, 项目答疑课上 Demo 视频展示课上检查验收每完成一个必选功能算基本分每个必选功能的剩余分数从 user friendly, 时效性, 安全性等非需求功能方面按 A,B,C 三档加分 A 档 2 分,B 档 1 分,C 档 0.5 分每个必选功能查出一个 bug 扣分, 直至分数扣到只有必选功能基本分为止平时作业许诺的功能若没有完成, 会按 A,B,C 三档扣分 A 档 4 分,B 档 2 分,C 档 1 分, 扣分最多不会超过 4 分每增加一个可选功能按 A,B,C 三档加分, 加分总额不超过满分 5 分, 没有必要且高度相似功能可能会降低加分档次 A 档 3 分,B 档 2 分,C 档 1 分自由探索项目评分从项目难度, 工作量, 项目完成度综合考虑评分, 分值比基础项目分值高至多 10 分 7

8 项目 PPT 介绍 4 th, December, 2018 每组 3-5 分钟, 选一个代表上台做汇报汇报内容 ( 至少包括以下部分 ) 1. 要做的是什么项目? 2. 项目面向的用户是谁? 3. 目标应用场景是什么? 4. 预计要完成哪些功能, 并通过场景示例的方式介绍 a) 必选功能介绍 b) 预计增加功能介绍 5. 小组人员的分工 6. 项目的进度安排每组在 6 th,december,2018 提交 Software Requirements Specification Template Version 1 8

9 项目 PPT 介绍 4 th, December, 2018 目标场景举例在滴滴打车等打车类 APP 未投入市场之前, 用户的典型客观场景可以描述为 : 公司职员王先生晚上 6:00 下班 ( 操作者及其背景信息 ), 需要打车回家 ( 操作者的目标 ), 在公司门口招揽出租车, 可是一直招揽不到出租车, 最终走了两公里路到附近的商场才打到了车, 而且发现商场附近待揽客的出租车非常多, 王先生觉得非常郁闷, 为什么资源不匹配呢 ( 操作者的一些列活动感受等 ) 9

10 项目 PPT 介绍 4 th, December, 2018 目标场景举例在滴滴打车等打车类 APP 未投入市场之前, 用户的典型客观场景可以描述为 : 公司职员王先生晚上 6:00 下班, 需要打车回家王先生在 5:50 时, 打开滴滴打车 APP 可以看到公司附近有很多出租车, 王先生输入出发地和目的地确认打车 30 秒后出租车司机李师傅接单, 王先生可以在手机上清晰的看到李师傅的车辆位置,10 分钟后王先生成功上车到达目的地后, 王先生用手机在线支付了打车费, 开心的回到家陪女儿吃晚饭 10

11 项目 PPT 介绍 4 th, December, 2018 目标场景举例在滴滴打车等打车类 APP 未投入市场之前, 用户的典型客观场景可以描述为 : 11

12 项目 PPT 介绍 4 th, December, 2018 项目介绍中应该包含这些信息使观众对项目有更深刻的认识 1. 人物 who - 基础背景 : 年龄性别收入职业喜好生活习惯等等 - 相关干系人 : 可能影响用户使用产品的人, 如妈妈做家务时, 可能会被宝宝爸爸因为一些突发事件而中途打断 2. 环境 where - 用户在什么地方使用产品 - 这个地方是什么样的, 室内 / 室外? 这个环境里有什么? - 这个地方对于使用产品有什么影响么? 3. 时间 when - 用户在什么时候使用产品 : 可以是绝对时间, 如上 / 中 / 下午 ; 也可以是相对时间, 如休息的时候, 跑步的时候目的 why - 用户为什么要使用产品, 产品可以帮助用户达成什么目标 - 用户使用产品是否会造成其他什么影响 12

13 项目 PPT 介绍 4 th, December, 2018 项目介绍中应该包含这些信息使观众对项目有更深刻的认识 5. 做什么 what - 用户使用产品前在做什么 - 用户用产品做什么 - 用户在使用产品时, 是否同时还在做其他的事情 - 用户在使用产品时, 是否会被其他什么事情影响 - 用户使用完产品后, 会做什么 6. 做什么 what - 用户怎么使用产品 - 用户在使用产品时, 可能遇到什么问题 - 用户在使用产品时的情绪状态是什么样的 - 使用产品的哪个阶段, 用户是最 high 的 - 为达成这个目标, 用户是否有其他的方式 13

14 本章内容软件测试概述软件缺陷术语软件测试概念软件测试基本原则软件测试团队软件测试类型 14

15 关于软件质量 The average software product released on the market is not error free. Win98 在演示中崩溃 15

16 软件缺陷比尔盖茨曾说 : 如果通用汽车能用计算机产业的速度来发展技术, 那我们今天的汽车就只要 25 美元, 每加仑汽油可以跑 1000 英里 1. 没毛病但是你会想要你的汽车每天毫无理由地撞车两次吗? 2. 你想要安全气囊弹出之前问 : 你确定吗? 3. 车子熄火的时候唯一的解决办法只有重新安装引擎? 16

17 术语解释错误 (Error): 在软件生存期内的不希望或不可接受的人为错误, 其结果是导致软件缺陷的产生缺陷 (Defect): 软件缺陷是存在于软件产品之中的那些不希望或不可接受的偏差, 其结果是软件运行于某一特定条件时出现故障故障 (Fault): 软件运行过程中出现的一种不希望或不可接受的内部状态, 若无适当措施 ( 容错 ) 加以及时处理, 便产生软件失效失效 (Failure): 软件运行时产生的一种不希望或不可接受的外部行为结果 17

18 软件缺陷的产生人的认识问题人的开发工作人工制品创造理解修改需求分析需求缺陷认识问题关注度问题策略问题创造理解修改创造理解修改实现重用修改概要设计详细设计编码调试设计缺陷编码缺陷软件产品 18

19 软件缺陷的演化举例 : 爱国者导弹 1991 年 2 月, 一次拦截失利造成 28 名美国士兵丧生软件系统 0.1 按十进制等于 1/10, 按二进制计算再转回来就成了 / 计时用系统时钟 (1/10 秒 ) 并以整数表达缺少防范措施激活演变缺陷故障失效寄存器存储导致误差 ( ) h = 0.34s 爱国者导弹的飞行速度约为 2000 米 / 秒, 爱国者导弹与飞毛腿导弹的距离误差就是 2000*0.3433=687 米, 而爱国者的杀伤力半径只有 20 米, 这怎么可能拦截成功呢? 19

20 本章内容软件测试概述软件缺陷术语软件测试概念软件测试基本原则软件测试团队软件测试类型 20

21 软件测试测试发现问题修复什么是软件测试? 软件测试的目的是什么? 21

22 软件测试的概念 IEEE: 测试是使用人工和自动手段来运行或检测某个系统的过程, 其目的在于检验系统是否满足规定的需求或弄清预期结果与实际结果之间的差别该定义明确提出了软件测试以检验是否满足需求为目标 22

23 软件测试的两种思维正向思维 : 验证软件正常工作评价一个程序或系统的特性或能力并确定是否达到预期的结果在设计规定的环境下运行软件的所有功能, 直至全部通过开发者系统的构建者, 理解系统测试是温和的, 试图证明系统的正确性 23

24 软件测试的两种思维逆向思维 : 假定软件有缺陷测试是为了发现错误而针对某个程序或系统的执行过程寻找容易犯错地方和系统薄弱环节, 试图破坏系统直至找不出问题独立测试组必须学会系统测试是破坏性的, 试图证明系统存在错误 24

25 软件测试的两种思维你完成了一个能够对 5 个数字从小到大的排序算法你会怎么测试? 25

26 软件测试的目的直接目标 : 发现软件错误以最少的人力物力和时间找出软件中潜在的各种错误和缺陷, 通过修正这些错误和缺陷提高软件质量, 回避软件发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险期望目标 : 检查系统是否满足需求测试是对软件质量的度量和评估, 以验证软件的质量满足客户需求的程度, 为用户选择和接受软件提供有力的依据附带目标 : 改进软件过程通过分析错误产生的原因, 可以帮助发现当前开发所采用的软件过程缺陷, 从而进行软件过程改进 ; 通过分析整理测试结果, 可以修正软件开发规则, 为软件可靠性分析提供依据 26

27 测试的局限性测试的不彻底性测试只能说明错误的存在, 但不能说明错误不存在经过测试后的软件不能保证没有缺陷和错误测试的不完备性测试无法覆盖到每个应该测试的内容不可能测试到软件的全部输入与响应不可能测试到全部的程序分支的执行路径测试作用的间接性测试不能直接提高软件质量, 软件质量的提高要依靠开发测试通过早期发现缺陷并督促修正缺陷来间接地提高软件质量 27

28 用 Venn Diagram 来理解测试考虑一个程序行为全域, 给定一段程序及其规格说明集合 S 是所描述的行为 ; 集合 P 是用程序实现的行为 ; 程序行为 ( 全域 ) 正确的部分规格说明 ( 预期的 ) S P 程序 ( 观察的 ) 被程序遗漏的部分 : 遗漏缺陷此部分程序没有被描述过 : 过错缺陷 28

29 用 Venn Diagram 来理解测试设计测试用例集合 T 没有测试的区域经过测试的区域被程序遗漏的部分 : 遗漏缺陷程序行为 ( 全域 ) 此部分程序没有被描述过 : 过错缺陷规格说明 ( 预期的 ) S P 程序 ( 观察的 ) 未通过程序实现测试用例 ( 已检验 ) T 正确的部分 29

30 本章内容软件测试概述软件缺陷术语软件测试概念软件测试基本原则软件测试团队软件测试类型 30

31 软件测试原则原则 1: 原则 2: 原则 3: 原则 4: 测试用例中一个必需部分是对预期输出或结果的定义编程人员应当避免测试自己编写的程序编写软件组织不应测试自己编写的软件应当彻底检查每个测试的执行结果原则 5: 测试用例不仅根据有效的和预期的输入情况, 也应根据无效的和未预料到的输入情况原则 6: 检查程序是否未做应该做的仅是测试的一半, 另一半是检查是否做了不应该做的原则 7: 原则 8: 原则 9: 应避免测试用例用后即弃, 除非是一次性软件计划测试工作时不应默许假定不会发现错误程序某部分存在更多错误的可能性, 与该部分已发现错误的数量成正比原则 10: 软件测试是一项极富创造性极具智力挑战性的工作 31

32 缺陷的集群性软件错误具有聚集性, 对存在错误的部分应重点测试 80/20 原则 :80% 的软件错误存在于 20% 的代码行中经验表明 : 测试后程序中残留的错误数目与该程序中已检出的错误成正比残存错误可能性已知错误数量 32

33 杀虫剂悖论用同样的测试用例多次重复进行测试, 最后将不再能够发现新的缺陷如同给果树喷撒农药, 为了杀灭害虫只打一种杀虫药, 虫子就会有抗体而变得适应, 于是杀虫剂将不再发挥作用测试用例需要定期评审和修改, 同时要不断增加新的不同测试用例来测试软件的不同部分, 从而发现更多潜在的缺陷 33

34 本章内容软件测试概述软件缺陷术语软件测试概念软件测试基本原则软件测试团队软件测试类型 34

软件测试团队的任务软件测试与质量保证合二为一 1 2 3 4 5 6 7 发现软件程序

35 软件测试团队的任务软件测试与质量保证合二为一发现软件程序系统或产品中所有的问题尽早地发现问题督促开发人员尽快地解决程序中的缺陷帮助项目管理人员制定合理的开发计划对问题进行分析分类总结和跟踪帮助改善开发流程, 提高产品开发效率提高程序编写的规范性易读性可维护性等 35

36 测试人员角色测试经理 : 建立和完善测试流程以及部门管理体制, 审核测试项目并分配资源, 监控和协调各项目的测试工作, 负责与其他部门的协调和沟通工作测试组长 : 制定测试项目计划 ( 包括人员进度软硬件环境和流程等 ), 实施软件测试, 跟踪和报告计划执行情况, 负责测试用例质量, 管理测试小组并提供技术指导测试工程师 : 理解软件产品的要求, 对其进行测试以便发现软件中的错误, 验证软件是否满足规格说明所描述的需求, 编写相应的测试方案和测试用例测试工具工程师 : 编写软件测试工具, 并利用所编写的测试工具对软件进行测试, 或者为测试工程师开发测试工具 36

37 举例 : 微软研发团队 DEV QA 产品部门经理 PM 开发团队经理测试团队经理程序经理团队经理开发组长测试组长程序经理组长可用性工程师开发工程师测试工程师程序经理产品设计师开发工程师测试工程师程序经理用户培训 37

38 软件测试人员核心素质 : 责任心测试技术能力掌握理论方法工具开发测试工具自动化测试框架测试脚本等掌握操作系统网络数据库中间件等知识非技术能力沟通能力, 协作精神自信心耐心专心洞察力记忆力怀疑精神, 创造性反向思维与发散思维自我督促幽默感专业领域经验了解业务知识积累实践经验 38

39 本章内容软件测试概述软件测试策略软件测试对象软件测试过程软件测试类型测试用例 39

40 软件测试的对象软件测试并不等于程序测试, 应贯穿于软件定义与开发的各个阶段测试对象包括 : 需求规格说明设计规格说明源程序 40

41 软件测试对象之间关系理解正确性设计正确性表达正确性分析文档分析员 : 可以提供什么设计文档设计员 : 让软件怎么做理解正确性编码正确性源程序程序员 : 让计算机做什么理解正确性表达正确性需求文档相符吗? 运行结果输入正确性运行正确性用户 : 要什么计算机 : 程序运行得到的结果 41

42 本章内容软件测试概述软件测试策略软件测试对象软件测试过程软件测试类型测试用例 42

43 软件测试过程计划准备执行报告识别测试需求分析质量风险拟定测试方案组织测试团队设计测试用例开发工具和脚本获得测试版本执行和实施测试记录测试结果分析测试结果评价测试工作提交测试报告制定测试计划准备测试数据跟踪和管理缺陷 43

44 软件测试活动输入 : 项目计划需求文档设计文档经过审查和修正之后的代码配置库测试计划活动 : 测试准备测试执行测试报告输出 : 测试计划测试修正之后的代码测试报告 44

45 软件测试阶段功能规格实际使用环境规格说明书审查单元测试设计规范非功能需求客户实际需求单元测试集成测试功能测试系统测试安装测试验收测试系统和程序设计审查单元测试已集成系统功能正常的系统可发布的系统投入使用 45

46 本章内容软件测试概述软件测试策略软件测试对象软件测试过程软件测试类型测试用例 46

47 软件测试类型测试对象角度单元测试集成测试系统测试验收测试测试技术角度黑盒测试 ( 功能测试 ) 白盒测试 ( 结构测试 ) 程序执行角度静态测试动态测试人工干预角度手工测试自动化测试 47

48 单元测试单元测试 (Unit Testing) 是对软件基本组成单元进行的测试, 其测试对象是软件设计的最小单位 ( 模块或者类 ) 单元测试单元测试单元测试单元测试单元测试单元测试一般由编写该单元代码的开发人员执行, 用于检测被测代码的功能是否正确 48

49 单元测试单元测试环境驱动模块 (driver): 模拟被测模块的上一级模块, 接收测试数据, 把这些数据传送给所测模块, 最后再输出实际测试结果 ; 桩模块 (stub): 模拟被测单元需调用的其他函数接口, 模拟实现子函数的某些功能驱动模块被测模块接口局部数据结构边界条件独立的路径循环路径错误处理桩模块桩模块桩驱动驱动驱动驱动器测试用例 49

50 集成测试集成测试 (Integration Testing) 是在单元测试的基础上, 将所有模块按照总体设计的要求组装成为子系统或系统进行的测试集成测试一次性集成方式 : 分别测试每个单元, 再一次性将所有单元组装在一起进行测试渐增式集成方式 : 先对某几个单元进行测试, 然后将这些单元逐步组装成较大的系统, 在组装过程中边连接边测试集成测试的对象是模块间的接口, 其目的是找出在模块接口上, 包括系统体系结构上的问题 50

51 集成测试的方法 : 整体集成整体集成方式 ( 非增量式集成 ) 把所有模块按设计要求一次全部组装起来, 然后进行整体测试例如 : A Test A (with stubs for B, C, D) Test B (with driver for A and stub for E) Test C (with driver for A) Test D (with driver for A and stub for F) B C D Test E (with driver for B) Test F (with driver for D) Test (A, B, C, D, E, F) E F 51

52 集成测试的方法 : 整体集成优点 : 效率高, 所需人力资源少 ; 测试用例数目少, 工作量低 ; 简单, 易行 ; 缺点 : 可能发现大量的错误, 难以进行错误定位和修改 ; 即使测试通过, 也会遗漏很多错误 ; 测试和修改过程中, 新旧错误混杂, 带来调试困难 ; 52

53 集成测试的方法 : 增量式集成 A 自顶向下的增量集成 : B C D 从主控模块开始, 按软件的控制层次结构, 以深度优先或广度优先的策略, 逐步把各个模块集成在一起 E F A A A A Test A (with stubs for B,C,D) s1 s2 s3 B s2 s3 B s2 s3 B C s3 广度优先的测试过程 : Test A;B (with stubs for E,C,D) Test A;B;C (with stubs for E,D) Test A;B;C;D (with stubs for E,F) 深度优先的测试过程 : 测试 A s4 E 加入 B 加入 E 加入 C A A E Test A;B;C;D;E (with stubs for F) B C D B C D Test A;B;C;D;E;F E 加入 D S5 E 加入 F F 53

54 集成测试的方法 : 增量式集成自底向上的集成测试 : 从软件结构最底层的模块开始组装测试 A Test E (with driver for B) Test C (with driver for A) Test F (with driver for D) B C D Test B;E (with driver for A) Test D;F (with driver for A) Test (A;B;C;D;E;F) E F 54

55 两种集成测试的优缺点自顶向下集成 : 优点 : 能尽早地对程序的主要控制和决策机制进行检验, 因此较早地发现错误 ; 较少需要驱动模块 ; 缺点 : 所需的桩模块数量巨大 ; 在测试较高层模块时, 低层处理采用桩模块替代, 不能反映真实情况, 重要数据不能及时回送到上层模块, 因此测试并不充分 ; 自底向上集成 : 优点 : 不用桩模块, 测试用例的设计亦相对简单 ; 缺点 : 程序最后一个模块加入时才具有整体形象, 难以尽早建立信心 55

56 系统测试系统测试 (System Testing) 是在实际运行环境或模拟实际运行环境下, 针对系统的非功能特性所进行的测试, 包括负载测试性能测试压力测试恢复测试安全测试和可靠性测试等系统测试容量测试性能测试兼容性测试安全性测试负载测试故障转移测试验证测试基准测试规划测试性能可用性扩展性维护性兼容性安全性可靠性质量需求 56

57 系统测试 : 恢复测试恢复测试 (Recovery Testing) 恢复测试是检验系统从软件或者硬件失败中恢复的能力, 即采用各种人工干预方式使软件出错, 而不能正常工作, 从而检验系统的恢复能力恢复性测试的例子当供电出现问题时的恢复恢复程序的执行对选择的文件和数据进行恢复恢复处理日志方面的能力通过切换到一个并行系统来进行恢复 57

58 系统测试 : 安全性测试安全性测试 (Security Testing) 安全性测试检查系统对非法侵入的防范能力安全性测试期间, 测试人员假扮非法入侵者, 采用各种办法试图突破防线安全性测试的例子想方设法截取或破译口令专门定做软件破坏系统的保护机制故意导致系统失败, 企图趁恢复之机非法进入试图通过浏览非保密数据, 推导所需信息 58

59 系统测试压力测试 (Press Testing) 压力测试是检查系统在资源超负荷情况下的表现, 特别是对系统的处理时间有什么影响压力测试的例子对于一个固定输入速率 ( 如每分钟 120 个单词 ) 的单词处理响应时间在一个非常短的时间内引入超负荷的数据容量成千上万的用户在同一时间从网上登录到系统引入需要大量内存资源的操作压力测试采用边界值和错误猜测方法, 且需要工具的支持 59

60 系统测试性能测试 (Performance Testing) 在实际应用的环境下系统性能的表现常与压力测试一起进行 60

61 验收测试验收测试是在软件产品完成了功能测试和系统测试之后产品发布之前所进行的软件测试活动, 其目的是验证软件的功能和性能是否能够满足用户所期望的要求验收测试进行 α 测试得到 β 版本进行 β 测试 α 版本 α 测试 β 版本 β 测试通过系统测试后软件公司组织内部人员模拟各类用户测试使用 α 版本经过 α 测试后软件公司组织典型用户在日常工作中实际使用 β 版本 61

62 回归测试在软件生命周期中的任何一个阶段, 只要软件发生了改变, 就可能给该软件带来问题为了验证修改的正确性及其影响就需要进行回归测试 62 制定测试计划设计测试用例执行测试撰写测试报告消除软件缺陷审批审批回归测试完成准则完成测试启动准则

63 黑盒测试黑盒测试 (Black Box Testing): 又称功能测试, 它将测试对象看做一个黑盒子, 完全不考虑程序内部的逻辑结构和内部特性, 只依据程序的需求规格说明书, 检查程序的功能是否符合它的功能说明客户需求输出输入事件驱动 63

64 白盒测试白盒测试 (White Box Testing): 又称结构测试, 它把测试对象看做一个透明的盒子, 允许测试人员利用程序内部的逻辑结构及有关信息, 设计或选择测试用例, 对程序所有逻辑路径进行测试 64

65 静态测试与动态测试静态测试 : 通过人工分析或程序正确性证明的方式来确认程序正确性非正式正式互审走查审查会议动态测试 : 通过动态分析和程序测试等方法来检查程序执行状态, 以确认程序是否有问题 65

66 手工测试与自动化测试手工测试 : 测试人员根据测试大纲中所描述的测试步骤和方法, 手工地输入测试数据并记录测试结果自动化测试 : 相对于手工测试而言, 主要是通过所开发的软件测试工具脚本等手段, 按照测试工程师的预定计划对软件产品进行的自动测试 66

67 手工测试与自动化测试自动化测试只是对手工测试的一种补充, 但绝不能代替手工测试, 二者有各自的特点在系统功能逻辑测试验收测试适用性测试涉及物理交互性测试时, 多采用黑盒测试的手工测试方法 ; 单元测试集成测试系统负载或性能稳定性可靠性测试等比较适合采用自动化测试 ; 对那种不稳定软件的测试开发周期很短的软件一次性的软件等不适合自动化测试 ; 工具本身并没有想象力和灵活性, 一般自动化测试只能发现 15~30% 的缺陷, 而手工测试可以发现 70~85% 的缺陷 ; 自动化测试工具在进行功能测试时, 其准确的含义是回归测试工具 67

68 测试的 V 模型需求分析和定义系统设计需求定义评审 + 验收测试用例设计系统设计评审 + 系统测试用例设计 + 测试环境准备系统测试验收测试详细功能设计功能设计评审 + 测试用例设计功能测试构建过程编码代码验证单元测试验证过程 68

69 本章内容软件测试概述软件测试策略软件测试对象软件测试过程软件测试类型测试用例 69

70 测试用例的重要性设计良好的测试用例是关键降低软件测试成本评估和检验测试效果保证测试工作质量 70

71 测试用例的定义与特征测试用例 (testing case): 测试用例是为特定的目的而设计的一组测试输入执行条件和预期的结果测试用例是执行的最小测试实体测试用例就是设计一个场景, 使软件程序在这种场景下, 必须能够正常运行并且达到程序所设计的执行结果测试用例的特征 : 最有可能抓住错误的 ; 不是重复的多余的 ; 一组相似测试用例中最有效的 ; 既不是太简单, 也不是太复杂 71

72 测试用例的重要性指导人们系统地进行测试临时性发挥也许会有灵感出现, 但是多数情况下会感觉思维混乱, 甚至一些功能根本没有测到而另一些功能已经重复测过几遍测试用例可以帮助你理清头绪, 进行比较系统的测试, 不会有太多的重复, 也不会让你的测试工作产生遗漏有效发现缺陷, 提高测试效率测试不可能是完备的而且受到时间约束, 测试用例可以帮助你分清先后主次, 从而更有效地组织测试工作编写测试用例之后需要标识重要程度和优先级, 以便在时间紧迫的情况下有重点地开展测试工作 72

73 测试用例的重要性作为评估和检验的度量标准测试用例的通过率和软件缺陷的数量是检验软件质量的量化标准, 通过对测试用例的分析和改进可以逐步完善软件质量, 不断提高测试的水平测试用例也可以用于衡量测试人员的工作量进度和效率, 从而更有效地管理和规划测试工作积累和传递测试的经验与知识测试用例不是简单地描述一种具体实现, 而是描述处理具体问题的思路设计和维护测试用例有助于人们不断积累经验和知识, 通过复用测试用例可以做到任何人实现无品质差异的测试 73

74 测试用例测试用例值完成被测软件的某个执行所需的输入值测试用例测试集测试用例值的集合期望结果前缀值后缀值当且仅当程序满足其期望行为, 执行测试时产生的结果将软件置于合适的状态来接受测试用例值的任何必要的输入测试用例值被发送以后, 需要被发送到软件的任何输入验证值 : 查看测试用例值结果所要用到的值结束命令 : 终止程序或返回到稳定状态所要用到的值 74

75 测试用例设计要求具有代表性和典型性寻求系统设计和功能设计的弱点测试用例设计既有正确输入也有错误或异常输入考虑用户实际的诸多使用场景 75

PowerPoint 演示文稿

PowerPoint 演示文稿网络工程师之系统开发运行与配置 ( 三 ) 高级项目经理任铄 QQ: 2105639303 第 3 章系统开发运行与配置 3.1 系统的 RAS 特性 3.2 软件开发生命周期模型 3.3 软件测试与维护 3.4 项目管理基础软件测试是指在规定的条件下对程序进行操作, 以发现程序错误, 衡量软件质量, 并对其是否能满足设计要求进行评估的过程软件的正确性证明尚未得到根本的解决, 软件测试仍是发现软件错误和缺陷的主要手段