结构化系统实现
一、编码
编码的目的
- 把模块的过程性描述翻译为用选定的程序设计语言书写的源程序
依据
- 编码的主要依据是概要设计和详细设计说明文档
任务
- 理解概要设计和详细设计说明书
- 遵循编码原则和风格进行翻译,形成源代码
程序设计语言分类
-
优点
- 比机器语言易读写、易调试和修改
- 执行速度块、占内存少
- 针对硬件编制
-
缺点
- 不能编写复杂程序
- 依赖于机型、不通用、不可移植
高级语言
与自然语言相近,面向用户的语言
- 优点
- 编码效率高
- 通用性强,兼容性好,便于移植
- 缺点
- 运行效率低
- 对硬件操作不如汇编
语言选择标准
-
系统用户要求
如果开发系统由用户维护,通常要求用熟悉的语言书写
-
可以使用的编译程序
运行目标系统环境可提供编译程序限制可选用语言的范围
-
可以得到的软件工具
有支持程序开发的软件工具可以利
-
工程规模
规模庞大,现有语言不适用,设计实现供该工程项目使用程序设计语言
-
程序员知识
如果和其他标准不矛盾,应选择程序员熟悉的语言
-
软件可移植性要求
若目标系统在不同计算机上运行,选择可移植性好的语言
-
软件的应用领域
选择语言时应充分考虑目标系统的应用范围
编码风格
逻辑简明清晰、易读易懂是重要标准
可遵循一下五方面规则
- 程序内部的文档
- 数据说明
- 语句构造(简单)
- 输入输出
- 效率(和存储容量)
二、软件测试基础
软件测试的目标:
- 测试是为了发现程序中的错误而执行程序的过程;
- 好的测试方案是极有可能发现迄今尚未发现的尽可能多的错误的测试;
- 成功的测试是发现了迄今尚未发现的错误的测试。
黑盒测试和白盒测试
- 黑盒测试:如果知道产品应具有功能,可通过测试来检验是否每个功能都能正常使用。
- 白盒测试:如果知道产品内部工作过程可通过测试来检验产品内部动作是否按照规格说明书的规定正常进行。
测试准则
-
所有测试应能追溯到用户需求,测试的目的是发现错误,其中最严重的是不能满足用户需求的错误。
-
应尽早地和不断地进行软件测试。
不应把软件测试看作是软件开发一独立阶段,应把它贯穿到软件开发各阶段中。
-
充分注意测试中群集现象
测试后程序中残存错误数与程序中已发现错误数目成正比,80%错误与20%模块有关。
-
测试应从小规模开始,逐步进行大规模测试。
耽搁模块,逐步集成。
-
不能做到穷举测试
穷举测试:程序所有可能执行路径都检查遍。
-
第三方测试原则
从心理学角度考虑。
三、逻辑覆盖
-
语句覆盖
选择测试数据,使被测程序中每个语句至少执行一次。
-
判定覆盖
每个语句至少执行一次,每个判定的真假分支至少执行一次。
-
判定/条件覆盖
取足够多测试数据,使判定表达式每个条件都取各种可能值,且每个判定表达式也都取到各种可能结果
四、控制结构测试
4.1 基本路径测试
Tom McCabe提出的一种白盒测试技术
-
根据过程设计结果画出相应流图
-
计算流图的环形复杂度
-
确定线性独立路径的基本集合
-
独立路径:至少包含一条在定义改路径之前不曾用过的边。
-
简单循环
- 零次循环:从循环入口直接跳到循环出口。
- 一次循环:查找循环初始值方面的错误。
- 二次循环:检查在多次循环时才能暴露的错误。
- m次循环:此时的m
- 最大循环次数、比最大循环次数多一次循环、比最大次数少一次的循环。
-
嵌套循环
- 从最内层循环开始,置所有其他层循环为最小值
- 对最内层循环做简单循环的全部测试
- 逐步外推,测试时保持所有外层循环变量取最小值,其他嵌套内层循环变量取“典型”值。
- 反复进行,直到所有各层循环测试完毕
-
连锁循环
- 各个循环相互独立,可用与简单循环相同方法进行测试
- 几个循环不是相互独立,需要使用测试嵌套循环
-
非结构化循环
使用结构化程序设计方法重新设计。
五、黑盒测试
黑盒着重:软件功能
黑盒发现错误类型:
- 功能不正确或遗漏
- 界面错误
- 数据结构或外部数据库访问错误
- 性能错误
- 初始化或终止错误
5.1 等价类划分
把程序的输入域划分成若干数据类,从每一数据类选取少数有代表性数据做为测试用例。
在各数据类中,各输入数据对揭露程序中的错误等效。
-
划分等价类
-
有效等价类:合理,有意义输入数据构成集合。
-
无效等价类:不合理,无意义输入数据构成的集合。
-
等价类划分原则
-
输入条件规定范围,定义一有效等价类和两无效等价类。
-
为每一等价类规定一唯一编 ;
-
设计一新测试用例,尽可能多覆盖尚未被覆盖有效等价类,重复,直到所有有效等价类被覆盖。
-
设计一新测试用例,仅覆盖一尚未被覆盖无效等价类,重复,直到所有无效等价类被覆盖
6.1 单元测试
模块通过编译的语法检查后进入单元测试
-
6.3 集成测试
-
渐增集成
将模块逐步组装成较大系统
-
自顶向下集成
-
混合策略
-
改进的自顶向下测试方法
基本用自顶向下方法,早期用自底向上测试关键模块
-
混合法
软件结构上层模块用自顶向下,下层用自底向上。
-
-
-
回归测试
重新执行已作过测试的某子集,保证变化没带来非预期副作用。
回归测试集:
- 检测软件全部功能的代表性测试用例
- 专门针对可能受修改影响的软件功能附加测试
- 针对被修改过软件功能测试
6.4 系统测试
使软件和其他系统元素(硬件、数据库等)结合测试
- 从错误现场入手,确定程序出错位置;
- 找错误的内在原因;
- 找出则排除错误,回归测试;
- 否则,加测试用例证明猜测原因。
7.2 调试方法
-
强行排错
-
将内存内容打印出来分析。
-
程序特定部位位置打印语句。
各关键变量改变部位、重要分支部位等,监视重要变量变化。
-
自动调试工具。
程序语言调试功能或专门交互式调试工具,不必修改程序。如设置断点,观察程序断点处状态,包括变量、表达式值等。
-
-
回溯法排错(小程序常用)
确定最先发现“症状”位置,人工沿程序控制流程向回追踪源代码,直到找到错误根源或确定错误产生范围。
-
原因排除法
对分查找法、归纳法、演绎法。
-
对分查找法
- 如已知每个变量在程序内若干关键点正确值,用赋值或输入语句在程序中点附加“注入”正确值,运行程序检查输出。
- 正确,错误原因在程序上半部分;反之,在程序后半部分。
- 反复使用,将程序出错范围缩小到容易诊断的程度。
-
归纳法是一种从特殊推断一般的逻辑方法。
归纳法调试的想法是:从一些线索(错误征兆)着手,通过分析它们之间的关系来找出错误。
-
演绎法排错
演绎法是从一般原理或前提出发,经过排除和精化过程来推导出结论的逻辑方法。
-
根据已有测试用例,设想所有可能出错原因;
-
逐个排除不正确的;
-
验证余下假设确是出错原因。
-
-
基本假定
8.3 估算错误总数方法
-
植入错误法
测试之前由专人在程序中随机植入错误,测试后,根据发现错误中原有的和植入的两种错误的比例,估计程序中错误总数。
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!
-
-
-
-
-
-