© SGS SA 2011 ALL RIGHTS RESERVED 1

TITEL, VERSALIEN, ARIAL, SCHWARZ Untertitel

SGS-CSTC

www.sgs-tuv-saar.com/fs

Mike Chen

Functional safety

功能安全与软件测试

2

OBJECTIVES

Risk

Functional Safety

Software test

The relationship between functional safety and software test

Test methods and process

Q&A

3

案例一

2014年， Philips Medical Systems（Cleveland）主动召回了其生产的单光子发射计算机断层扫描系统。

4

案例二： 呼吸机

2014年，柯惠医疗因软件版本出现的错误，主动召回了其生产的呼吸机。

5

案例三

国家食品药品监督管理总局信息显示，2013年10月17日和10月8日，GE

医疗先后对其生产的单光子发射断层扫描装置和诊断图像处理软件等医疗设备相关产品进行召回，原因是设备可能“在扫描过程中接触到患者肘部”和“造成错误解读和误诊”。而在同年7月30日，GE医疗对其生产的影像归档及传输系统也进行过召回，原因是“测量值可能无法准确算出”。

美国食品药物管理局（FDA）网站信息显示，GE医疗6月13日向FDA申请召回问题产品，称“不完善的机型设计可能会造成人员伤亡”，并在6月中旬通知美国各大医疗机构停止使用相关仪器。加拿大卫生部网站显示，6月14日，GE医疗向其申请对4个类型Millennium、Hawkeye、Infinia和Discovery，6款产品（MillenniumVG、Hawkeye4、Hawkeye、Infinia伽马照相机、DiscoveryNM/CT670系统和DiscoveryNM630系统）进行召回，后续在7月19日、8月9日以及10月2日又分别召回DiscoveryNM/CT570c、Optima、DiscoveryNM640主系统等更多产品。澳大利亚卫生部网站显示，GE医疗先后于6月20日、7月5日，向其申请召回包括Infinia等多种医学设备。

6

RISK含义

含义

a. 不好的或危险的事情发生的可能性;

b. 人或事物在将来发生危险或问题.

组成部分

风险因素，风险事故和风险结果

风险因素是指增加和引起风险事故发生的机会或增加损失后果程度的因素。

风险事故是指风险因素变成了风险发生的现实，是酿成事故和损失的直接原因和条件。

风险结果是指风险发生后产生的后果即风险损失。

7

风险分析

X 伤害严重度

Y 伤害发生的概率 BS EN ISO 14971:2009 Medical devices — Application of risk management to medical devices

8

风险分析

BS EN ISO 14971:2009 Medical devices — Application of risk management to medical devices

9

风险分析

BS EN ISO 14971:2009 Medical devices — Application of risk management to medical devices

10

WHAT IS FUNCTIONAL SAFETY?

目的避免由随机失效、系统失效或共因失效引起的人员伤亡、环境危害和财产损失，也就是装置或控制系统的安全功能无论在正常情况或者有故障存在的情况下都应该保证正确实施。

功能安全是依赖于系统或设备对输入的正确操作，是全部安全的一部分。当每一个特定的安全功能获得实现，并且其必需的性能等级被满足的时候，才能实现功能安全的目的。

功能安全是主动的。

part of the overall safety relating to the EUC and the EUC

control system that depends on the correct functioning of the

E/E/PE safety-related systems and other risk reduction

measures（come from IEC 61508）

Note：EUC Equipment Under Control

11

安全相关系统构成

12

IEC 61508 EDITION 2.0 2010-04

13

当操作员站在防护栏外面的时候，正常情况下是没有危险的。

而当进入护栏区域内，机器还在工作的话，就会有风险（risk），因为你已经接近了一个危险源（hazard），进入护栏区域内就是一个危险事件（hazard event），而如果发生了某种人身伤害，那么就是你受到了伤害（harm），也就发生了一起伤害事件（harm event）。

14

安全完整等级判定------风险图分析法

15

重要领域

Aerospace & Defense

Transportation Power / Energy

Medical Control Automation

Process Automation

Functional Safety

& Software

16

功能安全相关标准

IEC61513

核电设备

ISO 15998

土木机械

ISO 22201

电梯/电扶梯

IEC 60601

医疗仪器

IEC61511

过程工业

IEC 61800-5-2

电气驱动系统

EN50156

热炉设备

EN50128

轨道铁路系统 PrEN l 50495

防爆设备

IEC62061/

ISO 13849

机械设备

ISO26262

道路车辆

IEC 61508

E/E/PES

功能安全

17

功能安全业务范围

AEROSPACE MEDICAL

RAILWAY ELECTR. APPLIANCES AGRICULTURE

MACHINERY

18

功能安全概况

From Wind River material: Hypervisor an Off-the-Shelf Based Separation Concept to Improve Time-to-Revenue Medical

19

IEC 61508 CONTENTS

20

IEC 61508-SIL

SIL 高需求率的失效率λ

（危险的故障/小时）

低需求率的PFD

(Probability of failure on demand ）

4

3

2

1

IEC 61508以系统化评定方法制定出安全完整等级－SIL (safety integrity level)

SIL数字越大表示安全等级越高，且有高需求率(high demand rate)和低需求率(low demand rate)的区分，以一年内安全相关功能被使用过一次以上时，成为高需求率。而车辆的的刹车系统和安全气囊各为高和低要求率范畴。

21

3-LEVEL MODEL OF FUNCTIONAL SAFETY

22

LEVEL OF REVIEW IN SAFETY LIFECYCLE

23

安全要求分配

24

安全相关系统的抽象级别

25

实施过程中的系统安全生命周期

26

实施过程中的软件安全生命周期

27

SUPPORTING PROCESSES

28

V-MODEL

29

IEC-61508 VS IEC-62304

30

什么是软件？

软件是一系列按照特定顺序组织的指令和数据的集合。一般来讲软件被划分为系统软件、应用软件和介于这两者之间的嵌入式软件。软件并不只是包括程序代码，与程序相关的文档一般也被认为是软件的一部分。简单的说软件就是程序加文档的集合体。

软件渗透了大量的脑力劳动，涉及到逻辑思维、智能活动和技术水平等关键因素；

软件不会像硬件一样老化磨损，但存在缺陷维护和技术更新；

软件的开发和运行必须依赖于特定的计算机系统环境，对于硬件和环境有很强的依赖性，为了减少依赖，开发中常常提出了软件的可移植性；

软件具有可复用性，软件开发出来很容易被复制，从而形成多个副本。

31

什么是软件测试？

软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

广义：指软件生存周期中所有的检查、评审和确认工作，其中包括了分析、设计阶段，以及完成开发后维护阶段的各类文档、代码的审查和确认；

狭义：识别软件缺陷的过程，即实际结果与预期结果的不一致

Q1：函数的功能正确与否？（正确性）

Q2：有没有做任何不期望的事情？（健壮性或可靠性）

Q3：那里还没有测试？（coverage）

32

V&V

验证（Verification）

▬保证软件产品可以正确实现某一功能

▬软件开发生命周期中每个阶段的正确性与完整性

▬我们是否正确的开发了产品

确认(Validation)

▬确认软件复合功能要求

▬需求规格的确认，软件逻辑性的确认

▬我们是否正确的开发了产品

33

34

软件测试目的

测试的目的就是发现软件中的各种缺陷

测试只能证明软件存在缺陷，不能证明软件不存在缺陷

测试可以使软件中缺陷降低到一定程度，而不是彻底消灭

以较少的用例、时间和人力找出软件中的各种错误和缺陷，以确保软件的质量

以更少的支出（需求变更、维护、客服等成本）来谋取收入支出比达到最大化

最终目的是确保软件的功能符合用户的需求，把尽可能多的问题在发布或交付前发现并改正

35

软件测试的原则

Good-enough: 一种权衡投入/产出比的原则：选择测试

保证测试的覆盖程度，但穷举测试是不可能的：有限测试

所有的测试都应追溯到用户需求

越早测试越好，测试过程与开发过程应是相结合的

测试的规模由小而大，从单元测试到系统测试

为了尽可能地发现错误，应该由独立的第三方来测试

不能为了便于测试擅自修改程序

既应该测试软件该做什么也应该测试软件不该做什么

36

软件测试的规律

木桶原理：软件质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终软件的质量，测试是提高软件质量的必要条件，最直接、最快捷的手段，但决不是一种根本手段。（木桶原理与反木桶原理？）

Bug的80-20原则（群集现象）

在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug（提前测试）

而系统的测试又能找出其余Bug中的80%

最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来

37

软件测试的重点

测试用例的良好设计

• 测试用例的设计是整个软件测试工作的核心

• 测试用例反映了对被测对象的质量要求，决定了对测试对象的质量评估

测试工作的管理

• 尤其是对包含多个子系统的大型软件系统，其测试工作涉及大量人力和物力，有效的测试工作管理是保证有效测试工作的必要前提

测试环境的建立

• 测试环境应该与实际测试环境一致

38

软件测试度量

覆盖率 Coverage

衡量测试工作所覆盖到的范围占整体被测对象的比率。应用比较多的主要有基于测试需求的覆盖和基于测试代码的覆盖。前者主要指覆盖被测对象的功能逻辑，后者顾名思义是指对被测对象的代码覆盖，它又分为很多种类型，如语句覆盖、路径覆盖、分支覆盖和MC/DC覆盖等。

39

软件测试度量

圈复杂度Cyclomatic Complexity Metric

衡量一个模块判定结构的复杂程度，数量上表现为独立行路径条数，即合理的预防错误所需测试的最少路径条数，复杂度大说明程序代码可能质量低且难于测试和维护，根据经验，程序的可能错误与高的复杂度有着很大关系。

缺陷发现率

缺陷是何时被发现，并且有多少缺陷已经被发现。缺陷可以根据严重性来分类。需记录以下值：缺陷数目和缺陷的严重性

测试成功率：

有多少测试已经通过了，并且有多少是运行正常的？需记录：已通过的测试用例的数目和可利用的测试用例的数目

40

软件测试的误区

由于大多企业没有软件安全文化和软件质量的概念，缺乏软件测试与实践的知识，所有对软件测试工作容易有几点误解：

• 产品开发最后阶段才进行软件测试，软件测试=程序测试；

• 软件品质问题全是软件工程师的错；

• 测试技术要求不高，比编程容易，随便找一个人就可以了；

• 测试是测试人员的事，与开发人员无关；

• 谁写的代码，自己测试下就可以了；

• 测试要执行所有可能的输入；

• 好的测试一定要使用很多的测试工具

• 文档化过程太浪费时间，口头说说就好

• 产品出了问题，临时解决就可以

41

软件测试&软件开发

2000年，微软全球员工52000人，其中开发人员10000人，测试人员15000人

测试费用占60%

Exchange产品开发：开发人员140人，测试人员350人

Windows 2000产品开发：开发人员1700人，测试人员3200人

在典型的软件开发项目中，软件测试工作量往往占软件开发总工作量的40％以上。而在软件开发的总成本中，用在测试上的开销要占30％到50

％。

42

测试人员专业要求

对于系统测试，把握需求是第一位的。对产品熟练，能够快速熟悉新的产品需求， 很强的需求理解能力显得很重要；（业务素质、需求分析能力）

测试基础：明确测试流程中各个阶段的工作，对测试的认知程度，决定了测试流程管理的规范性，测试工作的质量；

测试方案的分析设计能力、测试用例的设计能力(测试用例的覆盖率、优先级等)；

测试工具的使用(包括测试管理和测试执行工具，也包括开发工具的能力)；

编程能力，数据库知识，网络知识，操作系统知识；

团队协作能力，与各个小组之间的沟通能力，以及管理测试工作的能力。

43

静态测试

不实际运行被测软件，只是静态地检查程序代码、界面、和文档中可能存在的错误的过程。评估软件是否满足规格要求，规格技术审查、文件审查、资料库审查、演算法分析审查。（代码测试，测试代码是否符合相应的标准和规范；界面测试，测试软件的实际界面是否与需求中的说明相符；文档测试，测试手册、需求说明、设计规格要求等文档与实际要求是否符合。）

# include< stdio.h>

max(float x, float y)

{ float z;

z=x>y? x:y

return (z);

}

Main()

{

float a, b;

int c;

scanf(“% f,% f,&a,&b);

c=max(a,b);

Printf(“Max is % d\n”,c);

}

这个示例的代码存在那些缺陷？如何修改？

44

/*程序名称：求两个实数中的大树

作者：* * *

版本：1.0

创建时间：2013.-10-14

*/

# include<stdio.h>

float max(float x, float y) //返回两个单精度数中的大数

{

float z;

z=x>y? x:y;

return(z);

}

main()

{

float a;

float b;

float c;

scanf(“% f, % f”, &a,&b);

c=max(a,b);

printf(“Max is % f\n”, c;)

}

45

动态测试

分为黑箱测试与白箱测试，实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所谓我们判断一个测试属于动态还是静态，唯一的标准就是看是否运行程序。 1、正常输入输入数字：1 2 3 4 0

Enter

2、非法数据的容错性：a b c d e

Enter

3、边界值输入：如果我们输入1

2 3 4 5 6 7 Enter

/* 程序名称：数组循环

作者：***

版本：1.0

创建时间：2014-01-01 */

# include<stdio.h>

void iszero( int m) //数组元素循环输出

{

If (m!=0)

Printf(“% d”,m);

Else

Printf(“% d”,1)

}

void main(void)

{

int a[5]

int i=0;

printf(“请输入5个整数\n”);

for(i=0;i=4;i++) // 输入数组数据

{

Scanf(“% d”,&a[i]);

Iszero(a[i]);

}

46

单元测试

单元测试

对软件中的最小可测试单元进行检查和验证。C 语言中，单元一般指一个函数，Java里一般指1个类，图形化软件中一般指一个窗口或一个菜单。

方法：1、先规则检查；2、运行代码，通过验证测试来验证代码的正确性、非法数据的容错性和边界值等问题。

要求：程序通过所有的单元的测试用例；语句覆盖率达到100%，分支覆盖率达到85%。

• 接口测试：保证进出单元模块的数据流是正确的。

• 内部数据结构：保证临时存储的数据在算法执行过程中的完整性

• 全局数据结构：全局数据结构对单元模块的影响应当审查

• 边界：采用边界值分析技术，保证模块在边界条件和极限情况下正常执行

• 语句覆盖：保证每个语句均执行一次

• 错误路径：对所有处理错误的路径进行测试

依据：1.程序源代码，包括代码和注释；2.《详细设计》的文档

47

桩模块和驱动模块

在程序中函数并不是一个独立的程序，在考虑测试函数时，也要考虑它和外界的联系，用一些辅助模块与被测模块联系其它的模块。

桩模块（Stub）：指模拟被测模块所调用的模块，

驱动模块（Driver）：指模拟被测模块的上级模块，驱动模块用来接受测试数据，启动被测模块并输出结果。

驱动模块

被测模块

桩模块 桩模块 桩模块

测试用例 测试结果

# include<stdio.h>

void main(void)

{

int a;

int b;

int c;

c=funl(a,b);

}

Int fun1(int x, int y)

{

return x+y;

}

48

A

B

D E

F J

G

I H C

#include <stdio.h>

void hello_world(void)

{

printf("Hello, world!\n");

}

void three_hellos(void)

{

int counter;

for (counter = 1; counter <= 3;

counter++)

hello_world();/*调用此函数*/

}

void main(void)

{

three_hellos();/*调用此函数*/

}

49

集成测试

集成测试也称联合测试，是将通过测试的单元模块组装成系统或者是子系

统，再进行测试，重点是测试不同模块的接口部分。目的是检查各个单元模

块结合到一起能否协同配合，正常工作，需要考虑的问题：

把各个模块连接起来的时候，函数之间的参数传递是否正确；

一个模块的功能是否会对另一个模块的功能产生不利的影响；

各个子功能组合起来，能否达到预期预期的功能；

全局数据结构是否有问题；

单个模块的误差累计起来，是否会放大，从而达到不能接受的程度

依据：1.单元测试的模块；2.《概要设计》文档

50

为什么要进行软件测试？

Question：

4W（Why？When？Where? Who?）

1H( How? )

Answer: in the following

51

Why

52

Because

Functional Safety

53

功能安全标准的应用

54

功能安全对覆盖率的要求

Avionics (DO‐178 B/C)

Level A (Statement, Branch, MC/DC),

Level B (Statement, Branch)

Level C (Statement)

Automotive (ISO‐26262) ASIL D (Statement, Branch, MC/DC)

ASIL B/C (Statement, Branch)

ASIL A (Statement)

Industrial (IEC‐61508) SIL4 (Statement, Branch, MC/DC)

SIL3 (Statement, Branch)

SIL 1/2 (Statement)

Railway (EN‐50128)

SIL4 (Statement, Branch, MC/DC),

SIL3 (Statement, Branch)

SIL 1/2 (Statement)

Medical (IEC‐62304 ) Class C (Statement, Branch, MC/DC)

Class B (Statement, Branch)

Class A (Statement)

55

IEC 61508-3 FIGURE 6

Software systematic and the development lifecycle

56

Medical Device

Software

57

MEDICAL STANDARD

U.S. FDA General Principles of Software Validation;

Final Guidance for Industry and FDA Staff

Section 5.2.5

Testing by the Software Developer

•Unit Testing

•Integration Testing

•System Testing

IEC 62304 Medical Device Software – Software Lifecycle Processes First edition 2006-05

Section 5.5

Software Unit Implementation and Verification

Section 5.6

Software Integration and Integration Testing

Section 5.7

Software System Testing

58

Legalization Science

59

法规要求

目的：保障消费者的安全

食品法规

安全法规

• 电器产品

• 玩具

• 纺织衣物

• 房屋建材

功能安全法规

• 轨道、高铁

• 核电厂、化工厂

• 家电类产品，自动化设备、汽车等

符合法规的科学：就是如何达到法规要求的技术，从一开始设计产品就要考虑

60

Product Liability

61

产品责任案例

德国有一个特殊的案例，乘客的侧面安全气囊在处于断路开关的位置时，气囊激活了。

这是一个软件缺陷。断路开关状态被正确检测到，但数据在存储到EEPROM/从EEPROM读取过程中产生了错误。

在低速正面碰撞时，乘客侧面安全气囊展开会杀死在乘客座位上的婴儿。

被以过失杀人罪起诉的负责软件工程师经过几次出庭后，被判无罪。

但这意味着犯罪记录

尽管工程师不是来自发生起诉的国家，只要最终产品在商场销售，无论他的住所在哪儿也要承担责任。即使刑法可能会没有结果，但犯罪记录也不是好玩的。

62

案例 软件错误导致的灾难

1963年 美国太空总署，一个FORTRAN程序循环

• DO 5 I=1,3 ------(正确)

• 被人为错误打成

• DO 5 I=1.3 ------(错误)

• FORTRAN编译器视为

• DO 5 I=1.3 ------(缺陷)

导致飞往火星的火箭(失效)，造成一千万美元的损失。

1994年 华航名古屋空难：自动驾驶软件(Auto-Pilot)重飞模式和手操作的控制杆的升降拖舵相互对抗。

1995年 美国航空在哥伦比亚撞山159人丧生（导航软件问题）。

1997年 韩国空难，225人丧生（雷达控制软件问题）。

63

FDA数据

FDA深信软件验证与其他好的软件工程活动是避免上述问题的基本原则

FDA公布因软件问题而回收的案件数统计

原始数据来自FDA

64

数据统计

1999-2005年期间，因故障而被召回的医疗器械3771个，因软件故障而被找回的有425个，占全部被召回产品的11.3%。

65

美国国防部要求每千行0.01以下的错误，电信/银行的系统平均每千行0.05个错误，一般企业软件为每千行0.5个错误。

依据行业的统计经验，每千行代码大约有60个缺陷。

66

When

67

测试需求

依据行业的统计经验，每千行代码大约有60个缺陷，2/3的缺陷是在需求与设计阶段，在这个阶段发现问题的修正费用最低，如果在系统测试才发现要花10倍以上的经费，若在产品验收阶段，则需要花费100倍以上

IE4产品开发：开发时间6个月，测试时间8个月

测试需要花费庞大的人力、物力与时间

代价

需求>设计代码>单元测试>集成测试>系统测试>验收测试

68

W模型——测试领域的主流模型

需求分析 需求测试

系统设计

详细设计

编码实现

模块集成

系统构建

系统安装

概要设计测试

详细设计测试

单元测试

集成测试

系统测试

验收测试

69

Where

70

FUNCTIONAL SAFETY V MODEL

71

Who

72

设计工程师

测试工程师

安全经理

产品经理

销售经理

用户

总经理

其他人员

73

How

74

75

系统的层级划分

76

系统工程&软件工程

美国国防部 ： United States Department of Defense ，简称DoD

77

系统工程&软件工程

78

软件分析方法

Software Fault Tree Analysis (SFTA) 软件工程领域使用的自顶而下的一种分析方法

Software Failure Mode and Effect Analysis (SFMEA)

用于分析系统中独立部件失效或故障时对系统的影响，FMEA用于单点故障模式，软件FMEA的输出可以用于FTA的输入。

Software Hazard and Operability Studies (SHAZOP软件危险与可操作性分析)

软件FTA和FMEA结合使用，可以为彼此的分析提供输入，是一种从系统到单元的相互验证和确认的系统分析方法。

79

FTA EXAMPLE

80

FTA EXAMPLE

嵌入式系统软件FTA实施的总体设计

Source from: Software FMEA and Software FTA – An Effective Tool for Embedded Software Quality Assurance, white paper Marhindra Satyan

81

FMEA EXAMPLE

82

业界现状

部分器械厂商已经被FDA及国外客户要求提供软件确认报告，但对如何进行完全没有概念

绝大多数的软件仅进行正常功能的确认测试，甚少探讨可预见的异常操作，且测试者通常即为软件开发人员本身，无法抓出潜在的软件异常问题（潜在的庞大成本支出）

国内对医疗器材的认证已经逐渐成熟，然而对医疗软件的认证推广才刚刚起步

开发内含软件医疗器材的厂商逐渐重视软件认证的重要性

83

LEVEL OF CONCERNS

评估一项装置可能会直接或间接让病人或者操作者遭受伤害的严重性，分为Major， Moderate 与 Minor 3种Levels.

Major Level

● 一次的故障或潜在因素，直接造成病人或操作者的死亡或严重伤害

● 间接性造成病人或操作者的死亡或严重伤害亦同。如不正确/延迟的咨询、或者是经由照护者的行为造成

Moderate Level

● 一次的故障或潜在因素，直接造成病人或操作者的较小的伤害

● 间接性造成病人或操作者的较小伤害亦同。如不正确/延迟的咨询、或者是经由照护者的行为造成

Minor Level

● 指故障或潜在因素，不会造成病人或操作者任何伤害

84

软件审查文件 Minor Moderate Major

影响等级 都需要

软件描述 都需要

风险缝隙 都需要

软件需求规格 软件功能的描述 所有软件需求与详细规格

软件设计架构 描述软件系统与子系统的架构图

描述软件系统与子系统的架构图，以及功能模组符合软件需求规格的说明

设计规格 不需要 软件设计规格书

可追溯性分析 不需要 软件需求、风险的鉴别与验证、确认及测试之间的可追溯性记录

软件开发 不需要 软件生命周期的开发计划书，包括型态管理和软件维护活动的概要

软件生命周期的开发计划书，开发过程中产生的管制文件及索引，包括型态管理和软件维护计划书

确认、验证及测试 软件功能测试计划书，通过/失败的判定准则与测试结果

单元、集成和系统V&V&T活

动的描述。系统测试计划包括通过/失败的判定准则和测验结果

单元、集成和系统V&V&T活动的描

述。单元、集成和系统测试计划包括通过/失败的判定准则、测试报告概要和测验结果

修订记录 不需要 修订的历史记录

软件未解决的错误（Bugs）

不需要 器械未解决的软件错误项目说明，并依据操作原理与人因工程，说明这些项目不对安全性与功效性造成影响的依据。

发行版本与序号 发行版本、序号，以及发行日期等记录

85

FDA软件确效需求文件

Software Description（软件描述）

contents：1.软件控制要点（角色、界面、是否可修改已经做到或做不到的事情）；2、特色说明（功能、性能、方法、优点等概述）；3、软硬件平台概述（代码语言、硬件平台与操作系统）

Device Hazard Analysis（医疗设备危险分析）

contents:1. 危害情形的鉴定；2.危险的严重性；3.造成的后果；4.控制与改善方法；5.验证控制方法可行

Software Requirements Specification（软件需求规格）

contents：软件系统描述；功能需求；界面需求

Software：程序开发语言要求；程序大小限制；执行时间要求；自测功能通过与否；反应时间要求；显示数值内容；数值显示精度；安全处理功能（如数据无法判断或出现硬件故障判断）；界面需求（如USB连接成功等）

Hardware：微处理器；电源供应；安全功能；通信方式；感测元件精度要求

86

FDA要求医疗软件送审文件

Architecture Design Chart（架构设计图）

content：系统方块图（硬件、软件）；状态分析图；软件控制流程图（Flow Chart）

Software Design Specification（软件设计规格）

contents：设计方法与工具；组织架构；系统流程；软件元件规格；界面设计规格；资料结构设计规格

Traceability Analysis（可溯性分析）

设计需求 对应的设计规格 对应的V&V测试 对应的危险防护

87

FDA要求医疗软件送审文件

Software Development Environment Description （软件开发环境描述）

contents：开发环境、硬件平台、操作系统

Verification and Validation Documentation（确认与验证文件）

contents: 1、提供设计者观点的测试计划及需求采样的样本资料（属性与数量及预期结果）；2、验收标准

Note ：Testing documents

Revision Level History（校订版本历史记录）

contents：1、修正历史记录；2、修改内容说明；3、日期、编号、负责人签；4、修正内容与前版本关系

Unresolved Anomalies（未解决异常记录）

contents：问题所在；对于设备效能的影响；解决问题计划或时间范围

88

VERIFICATION AND VALIDATION

DOCUMENTATION（确认与验证文件）

使用列表的方式，摘要说明如何针对单元/集成/系统三种Levels进行V&V的相关测试，该测试须与危险分析互相对照。

报告内容

• 测试项目编号

• 软件版本

• 测试人员、检查人员

• 测试项目 名称、目的、设备与使用工具

• 测试方法、输入规格、输出规格、环境要求

• 测试通过标准、测试步骤描述、测试结果

89

软件测试流程

测试计划（Test Plans）

——测试的范围、方式与流程

测试设计（Test Design）

——测试的功能与方法设计

——回归测试（Regression Test）

测试用例（Test Cases)

——精简的测试案例执行

测试程序（Test Procedure）

——测试系统的执行步骤

测试执行（Test Execution）

——从单元测试开始，集成测试到系统测试

测试报告（Test Report）

——验证、确认及所有测试结果

90

软件测试（一）

制定测试计划（Test Plan）

测试结果与事先规划相同

规划成功的测试用于找到Bugs

设计者与使用者均需参与

设计者与测试者各自独立

测试者须采用与设计者不同的工具

91

软件测试（二）

测试方法

白箱（白盒）测试：以代码为基础的结构性测试（静态测试或单元层级）

黑箱（黑盒）测试：以功能定义或者规格说明书为基础的功能性测试（由单元层级至系统层级）

单元测试、集成测试、系统测试等等

软件变更测试（回归测试）

文件记录测试通过与失败的结果

92

软件测试（三）

测试层级

单元层级（Unit Test）

●专注于程序单元的验证

集成测试（Integration Test）

●横跨程序单元内部与模组间界面的资料及控制传递

系统层级

●展现所有指定的功能均已完成，软件为可信赖

93

软件测试（四）

软件验证（Verification）测试

测试计划

结构性、功能性测试方案确认

回溯分析

执行单元、整合、功能性、系统性测试

测试结果评估及错误解决

测试报告

软件确认（Validation）测试

执行接受度测试

测试结果及错误评估

测试报告

94

软件测试V模型

95

白箱（白盒）测试

需要深入到软件的内部，去查看源代码，去分析程序的内部结构，如数据类型、算法、异常处理等。白盒测试可分为静态分析和动态测试。

动态测试方法：

1、边界值测试：错误隐藏在角落，问题聚焦在边界；

2、逻辑驱动覆盖技术（顺序、分支、循环结构）：专门测试程序中的分支机构和循环结构；

3、循环语句测试

4、MC\MC测试

96

MISRA C

增进嵌入式系统软件安全性（目的）

MISRA-C&C++ MISRA C： the motor industry software reliability

association 汽车工业软件可靠协会是提出的C语言开发标准，其目的是在增进嵌入式系统的安全性及可移植性。

MISRA C一开始主要是针对汽车产业，但随着其不断的发展和影响力的扩张，航天、电信、国防、医疗设备、铁路等领域都已广泛的采用了MISRA C。

针对C++也有与之相对的MISRA C++

97

MISRA C 2004

98

MISRA C EXAMPLE

14.4 [强制]

不应使用goto语句

15.3 [强制]

switch语句的最后子句应该是default语句.

16.2 [强制]

函数不能调用自身，无论是直接还是间接。

18.4[强制]

不允许使用联合体

99

基本路径测试

条件覆盖

●根据每个路径上条件陈述式中列出的所有条件来选出输入资料

●此类测试覆盖率是所有路径测试中最为彻底。

分支覆盖

●依照条件陈述式，分别针对条件为真、条件为假各设计测试用例。

语句覆盖

●对每个语句至少进行一次测试。

100

举例说明

范例代码

If (x>0 and y != x)

z = y ;

Else

z = x ;

1. x>0 , y!= x

2. x>0 , y=x

3. x<0 , y!=x

4. x<0 , y=x

5. x=0 , y!=x

6. x=0 , y=x

1. x>0 , y!= x

2. x>0 , y=x

x>0 , y!= x

条件覆盖

语句覆盖

分支覆盖

101

MC/MD 测试

修正条件/判定覆盖（Modified Condition/Decision Coverage)

一种实用的软件结构覆盖率测试准则， 已被广泛地应用于软件验证和测试过程中，指的是程序中入口和出口的每个点至少被调用一次，从而每个程序的判定到所有可能的结果值都要至少转换一次，判定中的每个条件可以独立地显示出它对判定结果的影响。复杂的布尔表达式需要开发一个逻辑运算的真值表，对布尔表达式中的每个变量进行“真”和“假”的设置。

条件是指不含任何逻辑操作符的布尔表达式，由关系操作符构成。

判定是指包含逻辑操作符的布尔表达式。

一个没有逻辑算子的结果就是一个条件。

if((A==0 || B==0) && (C==0 || D==0))

printf(“TRUE”);

else

printf(“FALSE”);

A,B,C,D是一个条件,而((A==0 || B==0) && (C==0 || D==0))叫一个Decision

102

黑箱(黑盒)测试

所谓黑箱测试是将整个被测试的软件当成一个黑箱子，看不见里边的任何细节，知识进行操作、输入资料、观察输出资料。

主要在测试软件的需求功能，对软件界面进行测试，也就是以测试资料检查软件功能是否正确，输入资料是否正确接受、是否产生正确的输出结果、外部资料的完整性是否得到维护等。

●功能性测试

●非功能性测试----GUI状态切换

103

例子

一个医疗软件的操作界面，使用者可以输入想要的输入年龄的范围，例如下限为：1，上限为100。且以1为最小单位的整数。

等价区域：

有效资料区（n=1)：

●1n,2n,3n,……30n

无效区域

输入值＜1、＞100、输入小数或者是负数

边界值

●有效数据： 1；100

●无效数据：0、1000

104

状态转移测试

软件的执行过程是通过不同的状态转换实现的，而最基本的就是初始状态和中断状态。

在状态转移的测试过程中，如果有发现和软件规格说明书不同的地方，都应列入测试报告中。

以远端挂号系统软件的读值功能为例

设备初始状态

分析判断并处理操作者输入的资料

将资料送到伺服机中

资料处理完毕将有关资料传回给使用者界面（显示及选择挂号科别，资料处理及确认）

进入提款的终端状态（询问是否还需要其它服务或退出）

105

白箱测试与黑箱测试的主要差异

白箱测试（结构性测试） 黑箱测试（功能性测试）

验证代码处理流程逻辑运作 验证处理功能，测试个案输入直接影响到输出结果

专业人士 内部或者委外进行皆宜

深度（depth） 以广度（coverage）测试为主

应用于代码设计初期 应用于软件完成后

106

软件测试工作流程

自下而上（V模型右半边）

单元测试>集成测试>系统测试（功能测试）

自上而下

系统测试（功能测试）>集成测试>单元测试

107

新项目（自下而上的测试流程）

.h

测试报告

fail

开发模式

.h, .c, .cpp

创建/调试/修改单元-集成测试用例

执行测试用例

执行结果

测试覆盖率是否符合要求

资深测试工程师对测试用例的合理性和是否充分覆盖功能需求进行复审

测试用例数据和测试脚本

定期执行测试用例进行回归测试

是否还有其它需要开发的新增测试模块

系统功能测试

系统测试的代码覆盖率

单元测试完成

是否有测试用例执行失败

修正或开发源代码 （测试驱动模式下，测试用例执行失败可能是因为源代码还未开发导致）

继续开发其他功能模块

pass

符合

不符合

合格

不合格

是 否

是

108

已有项目（自上而下的测试流程）

执行测试用例

系统功能测试

新开发功能

创建/调试/修改单元-集成测试用例

修正源代码

定期执行测试用例进行回归测试

系统测试的代码覆盖率

测试覆盖率是否符合要求

执行结果

测试覆盖率是否符合要求

资深测试工程师对测试用例的合理性和是否充分覆盖功能需求进行复审

测试用例数据和测试脚本

是否还有需要开发的新增测试模块

测试报告

测试报告

单元测试完成

.h, .c, .cpp

是否还有需要开发的新增测

试模块

是

否

pass

fail

符合

不符合

不合格

合格 是

否

是

109

IEC 61508 软件测试要求

110

IEC 61508 软件测试要求

111

IEC 61508软件测试要求

112

TEST SAMPLE

113

METRICS REPORT

114

WHAT SGS CAN DO FOR YOU

符合FDA要求医疗软件送审文件

Software

V&V&Testing

Training for

software test

IEC-62304 Test Report

Software

V&V&Testing Report

© SGS SA 2011 ALL RIGHTS RESERVED 115

Thank you！

Mike Chen/ 陈修锋

Mike-xf.chen@sgs.com

15921566153/ 021-61191881

2014.10.20