通常把编码和测试统称为实现
编码:
-
选择程序设计语言
-
选择标准:
-
系统用户要求
-
可以使用的编译程序
-
可以得到的软件工具
-
工程规模
-
程序员的只是
-
软件可移植性要求
-
软件的应用领域
-
-
-
编码风格
-
应该遵循的标准:
-
程序内部的文档:包括恰当的标识符,适当的注解和程序的视觉组织(通常在每个模块开始有一段序言性注解,简要描述模块的功能,主要算法,接口特点,重要数据以及开发简史)
-
数据说明:
-
语句构造:每个语句应该简单直接,适当拆分语句,避免复杂田间测试,避免大量循环嵌套条件嵌套,适当用括号
-
输入输出:
-
对所有输入数据都进行检验
-
检查输入项重要组合的合法性
-
保持输入格式简单
-
使用数据结束标记,不要要求用户指定数据的数目
-
明确提示交互式输入的要求,详细说明可用的选择或边界值
-
当程序设计语言对格式有严格要求是,应该保持输入格式一致
-
设计良好的输入报表
-
给所有输出数据加标志
-
-
效率:主要指处理机时间和存储器容量两个方面,属于性能要求
-
程序运行时间
-
存储器效率
-
输入输出效率
-
-
-
软件测试基础:
测试的根本目的:尽可能多地发现并排除软件中潜藏的错误,最终把一个高质量的软件系统交给用户使用。
软件测试的目标定义:
-
测试时为了发现程序中的错误而执行程序的过程
-
好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案
-
成功的测试是发现了至今为止尚未发现的错误的测试
测试准则:
-
所有测试都应该能追述到用户的需求
-
应该远在测试开始之前就指定测试计划。实际上在完成需求模型之后就可以着手制定测试计划,在完成详细设计之后,在编码前就可以开始设计详细的测试方案。
-
把Pareto原理应用到软件测试中。Pareto原理:测试发现的错误80%由程序中20%的模块造成
-
应该从小规模测试,逐步进行大规模测试
-
穷举测试是不可能的。限于人力物力,把程序所有流程分支检查测试是不可能的
-
应该由第三方承担测试工作。通常开发人员主要承担模块测试
测试方法:
-
黑盒测试(功能测试):完全不考虑程序内部结构和处理过程,只检查程序功能是否能够按照规格说明书的规定正常使用
-
白盒测试(结构测试):按照程序内部的逻辑测试程序,检测程序中的主要执行通路是否都能按预定的要求正确工作
测试步骤:
-
模块测试
-
子系统测试
-
系统测试
-
验收测试:测试过程与系统测试基本类似,但需要用户积极参与,使用实际数据测试
-
平行运行:关系重大的软件产品验收之后往往并不立即投入生产性运行,而是经过一段平行运行时间的考验,与旧系统同时运行,比较两个系统处理结果
-
平行运行优点:
-
可以在准生产环境中运行新系统而又不冒风险
-
用户能有一段熟悉新系统的时间
-
可以验证用户指南和使用手册之类的文档
-
能够以准生产模式对新系统进行全负荷测试,可以用测试结果验证性能指标
-
-
测试阶段的信息流:
-
软件配置:包括需求说明书,设计说明书和源程序清单
-
测试配置:包括测试计划和测试方案。实际上测试配置是软件配置的一个子集,最终交出的软件配置应该包括上述测试配置以及测试的实际结果和调试记录
-
测试方案:包含测试用例,每组输入数据和预定要检验的功能,以及每组输入数据预期应该得到的正确输出。
-
在对测试结果进行收集和评价的时候,软件可靠性所达到的定性指标已经有所显现。如果经常出现要求修改设计的严重错误,那么软件的质量和可靠性是值得怀疑的,应该进一步仔细测试。反之若极少错误,则应该考虑测试配置是否不足。
单元测试:主要使用白盒测试技术
-
测试重点:
-
模块接口
-
局部数据结构
-
重要的执行桐庐
-
出错处理通路
-
边界条件
-
-
代码审查:可以编写者本人,也可以由审查小组进行
-
审查小组最好由4人组成:
-
组长,很有能力的程序员
-
设计者
-
编写者
-
测试者
-
-
-
计算机测试(自动化测试):把以人为驱动的测试行为转化为机器执行的一种过程。
集成测试:测试和组装软件的系统化技术
-
非渐增式测试:分别测试模块,再把所有模块按设计要求放在一起结合成所要的程序
-
渐增式测试(目前普遍采用):把下一个要测试的模块同已经测试好的模块结合进行测试,依次递增
-
自顶向下集成
-
自底向下集成
-
确认测试(验收测试):验证软件有效性,必须有用户积极参与,或以用户为主进行
-
确认测试范围
-
软件配置复查:保证软件配置的所有成分都齐全,质量符合要求,文档与程序完全一致,具有完成软件维护所必须的细节,而且已经编好目录
-
Alpha和Beta测试:Alpha测试指用户在开发者场所,经开发者指导下的测试,Beta则是用户场所下进行的测试
白盒测试技术:
-
逻辑覆盖
-
语句覆盖
-
判定覆盖
-
条件覆盖
-
判定/条件覆盖
-
条件组合覆盖:选取足够多地测试数据,使得每个判定表达式中条件的各种可能组合都至少出现一次
-
点覆盖
-
边覆盖
-
路径覆盖
-
-
控制结构测试
-
基本路径测试
-
根据过程设计结果画出相应的流图
-
计算流图的环形复杂度
-
确定线性独立路径的基本集合
-
设计可强制执行基本集合中每条路径的测试用例
-
-
条件测试
-
循环测试
-
简单循环:
-
跳过循环
-
只通过循环一次
-
通过循环两次
-
通过循环m次,其中m<n-1
-
通过循环n-1,n,n+1次
-
-
嵌套循环
-
串接循环
-
-
黑盒测试技术:着重测试软件功能,白盒测试在测试过程的早期阶段进行,而黑盒测试主要用于测试过程的后期
黑盒测试力图发现如下类型错误:
-
功能不正确或遗漏了功能
-
界面错误
-
数据结构错误或外部数据库访问错误
-
性能错误
-
初始化和终止错误
设计黑盒测试方案应该考虑:
-
怎样测试功能的有效性
-
哪些类型的输入可以构成好的测试用例
-
系统是否对特定的输入值特别敏感
-
怎样划定数据库的边界
-
系统能够承受什么样的数据率和数据量
-
数据的特定组合对系统运行产生什么影响
黑盒测试技术:
-
等价划分:把程序的输入域划分成若干个数据类,据此导出测试用例。一个理想的测试用例能独自发现一类错误
-
边界值分析:选取测试数据应该刚好等于,刚刚小于,刚刚大于边界值
-
错误推测
经验表明,在一段程序中已经发现的错误数目往往和尚未发现的错误数成正比。
调试:目标都是寻找错误原因并改正错误
软件错误的特征:
-
症状与产生症状的原因可能在程序中相距甚远,紧耦合的程序更是如此
-
当改正了另一个错误之后,症状可能暂时消失
-
症状可能不是由于错误引起的,而是一些精度问题
-
症状可能是由不易跟踪的人为错误引起
-
症状可能是由定时问题导致,而不是由处理问题引起
-
症状可能时有时无,这种情况在嵌入式系统中比较常见
-
症状可能是多线程引起
调试途径:
-
蛮干法
-
回溯法
-
原因排除法:
-
对分查找法:
-
归纳法:从个别现象推断出一般性解饿论
-
演绎法:设想所有可能的出错原因,然后用测试来排除精化
-
一旦找到错误,在动手改正错误之前,工程师要考虑3个问题:
-
是否同样的错误也在程序其他位置出现
-
修改之后,是否引入新错误,是什么
-
为防止今后出现类似的错误,应该作什么
软件可靠性:程序在给定的时间间隔内,按照规格说明书的规定成功地运行的概率
软件的可用性:程序在给定的时间点,按照规格说明书的规定,成功运行的概率
估算平均无故障时间:平均无故障时间与单位长度程序中的剩余错误数成反比 MTTF=1 / K(单位长度程序中的剩余错误数) K为常熟,典型值为200
根据对软件平均无故障时间的要求,估计需要改正多少个错误之后,测试工作才能结束
估计错误总数方法:
-
植入错误法:植入错误引发错误与原有错误引发错误的比例
-
分别测试法:标记已知错误的代码,与未标记代码的比例
通常把编码和测试统称为实现
编码:
-
选择程序设计语言
-
选择标准:
-
系统用户要求
-
可以使用的编译程序
-
可以得到的软件工具
-
工程规模
-
程序员的只是
-
软件可移植性要求
-
软件的应用领域
-
-
-
编码风格
-
应该遵循的标准:
-
程序内部的文档:包括恰当的标识符,适当的注解和程序的视觉组织(通常在每个模块开始有一段序言性注解,简要描述模块的功能,主要算法,接口特点,重要数据以及开发简史)
-
数据说明:
-
语句构造:每个语句应该简单直接,适当拆分语句,避免复杂田间测试,避免大量循环嵌套条件嵌套,适当用括号
-
输入输出:
-
对所有输入数据都进行检验
-
检查输入项重要组合的合法性
-
保持输入格式简单
-
使用数据结束标记,不要要求用户指定数据的数目
-
明确提示交互式输入的要求,详细说明可用的选择或边界值
-
当程序设计语言对格式有严格要求是,应该保持输入格式一致
-
设计良好的输入报表
-
给所有输出数据加标志
-
-
效率:主要指处理机时间和存储器容量两个方面,属于性能要求
-
程序运行时间
-
存储器效率
-
输入输出效率
-
-
-
软件测试基础:
测试的根本目的:尽可能多地发现并排除软件中潜藏的错误,最终把一个高质量的软件系统交给用户使用。
软件测试的目标定义:
-
测试时为了发现程序中的错误而执行程序的过程
-
好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案
-
成功的测试是发现了至今为止尚未发现的错误的测试
测试准则:
-
所有测试都应该能追述到用户的需求
-
应该远在测试开始之前就指定测试计划。实际上在完成需求模型之后就可以着手制定测试计划,在完成详细设计之后,在编码前就可以开始设计详细的测试方案。
-
把Pareto原理应用到软件测试中。Pareto原理:测试发现的错误80%由程序中20%的模块造成
-
应该从小规模测试,逐步进行大规模测试
-
穷举测试是不可能的。限于人力物力,把程序所有流程分支检查测试是不可能的
-
应该由第三方承担测试工作。通常开发人员主要承担模块测试
测试方法:
-
黑盒测试(功能测试):完全不考虑程序内部结构和处理过程,只检查程序功能是否能够按照规格说明书的规定正常使用
-
白盒测试(结构测试):按照程序内部的逻辑测试程序,检测程序中的主要执行通路是否都能按预定的要求正确工作
测试步骤:
-
模块测试
-
子系统测试
-
系统测试
-
验收测试:测试过程与系统测试基本类似,但需要用户积极参与,使用实际数据测试
-
平行运行:关系重大的软件产品验收之后往往并不立即投入生产性运行,而是经过一段平行运行时间的考验,与旧系统同时运行,比较两个系统处理结果
-
平行运行优点:
-
可以在准生产环境中运行新系统而又不冒风险
-
用户能有一段熟悉新系统的时间
-
可以验证用户指南和使用手册之类的文档
-
能够以准生产模式对新系统进行全负荷测试,可以用测试结果验证性能指标
-
-
测试阶段的信息流:
-
软件配置:包括需求说明书,设计说明书和源程序清单
-
测试配置:包括测试计划和测试方案。实际上测试配置是软件配置的一个子集,最终交出的软件配置应该包括上述测试配置以及测试的实际结果和调试记录
-
测试方案:包含测试用例,每组输入数据和预定要检验的功能,以及每组输入数据预期应该得到的正确输出。
-
在对测试结果进行收集和评价的时候,软件可靠性所达到的定性指标已经有所显现。如果经常出现要求修改设计的严重错误,那么软件的质量和可靠性是值得怀疑的,应该进一步仔细测试。反之若极少错误,则应该考虑测试配置是否不足。
单元测试:主要使用白盒测试技术
-
测试重点:
-
模块接口
-
局部数据结构
-
重要的执行桐庐
-
出错处理通路
-
边界条件
-
-
代码审查:可以编写者本人,也可以由审查小组进行
-
审查小组最好由4人组成:
-
组长,很有能力的程序员
-
设计者
-
编写者
-
测试者
-
-
-
计算机测试(自动化测试):把以人为驱动的测试行为转化为机器执行的一种过程。
集成测试:测试和组装软件的系统化技术
-
非渐增式测试:分别测试模块,再把所有模块按设计要求放在一起结合成所要的程序
-
渐增式测试(目前普遍采用):把下一个要测试的模块同已经测试好的模块结合进行测试,依次递增
-
自顶向下集成
-
自底向下集成
-
确认测试(验收测试):验证软件有效性,必须有用户积极参与,或以用户为主进行
-
确认测试范围
-
软件配置复查:保证软件配置的所有成分都齐全,质量符合要求,文档与程序完全一致,具有完成软件维护所必须的细节,而且已经编好目录
-
Alpha和Beta测试:Alpha测试指用户在开发者场所,经开发者指导下的测试,Beta则是用户场所下进行的测试
白盒测试技术:
-
逻辑覆盖
-
语句覆盖
-
判定覆盖
-
条件覆盖
-
判定/条件覆盖
-
条件组合覆盖:选取足够多地测试数据,使得每个判定表达式中条件的各种可能组合都至少出现一次
-
点覆盖
-
边覆盖
-
路径覆盖
-
-
控制结构测试
-
基本路径测试
-
根据过程设计结果画出相应的流图
-
计算流图的环形复杂度
-
确定线性独立路径的基本集合
-
设计可强制执行基本集合中每条路径的测试用例
-
-
条件测试
-
循环测试
-
简单循环:
-
跳过循环
-
只通过循环一次
-
通过循环两次
-
通过循环m次,其中m<n-1
-
通过循环n-1,n,n+1次
-
-
嵌套循环
-
串接循环
-
-
黑盒测试技术:着重测试软件功能,白盒测试在测试过程的早期阶段进行,而黑盒测试主要用于测试过程的后期
黑盒测试力图发现如下类型错误:
-
功能不正确或遗漏了功能
-
界面错误
-
数据结构错误或外部数据库访问错误
-
性能错误
-
初始化和终止错误
设计黑盒测试方案应该考虑:
-
怎样测试功能的有效性
-
哪些类型的输入可以构成好的测试用例
-
系统是否对特定的输入值特别敏感
-
怎样划定数据库的边界
-
系统能够承受什么样的数据率和数据量
-
数据的特定组合对系统运行产生什么影响
黑盒测试技术:
-
等价划分:把程序的输入域划分成若干个数据类,据此导出测试用例。一个理想的测试用例能独自发现一类错误
-
边界值分析:选取测试数据应该刚好等于,刚刚小于,刚刚大于边界值
-
错误推测
经验表明,在一段程序中已经发现的错误数目往往和尚未发现的错误数成正比。
调试:目标都是寻找错误原因并改正错误
软件错误的特征:
-
症状与产生症状的原因可能在程序中相距甚远,紧耦合的程序更是如此
-
当改正了另一个错误之后,症状可能暂时消失
-
症状可能不是由于错误引起的,而是一些精度问题
-
症状可能是由不易跟踪的人为错误引起
-
症状可能是由定时问题导致,而不是由处理问题引起
-
症状可能时有时无,这种情况在嵌入式系统中比较常见
-
症状可能是多线程引起
调试途径:
-
蛮干法
-
回溯法
-
原因排除法:
-
对分查找法:
-
归纳法:从个别现象推断出一般性解饿论
-
演绎法:设想所有可能的出错原因,然后用测试来排除精化
-
一旦找到错误,在动手改正错误之前,工程师要考虑3个问题:
-
是否同样的错误也在程序其他位置出现
-
修改之后,是否引入新错误,是什么
-
为防止今后出现类似的错误,应该作甚恶魔
软件可靠性:程序在给定的时间间隔内,按照规格说明书的规定成功地运行的概率
软件的可用性:程序在给定的时间点,按照规格说明书的规定,成功运行的概率
估算平均无故障时间:平均无故障时间与单位长度程序中的剩余错误数成反比 MTTF=1 / K(单位长度程序中的剩余错误数) K为常熟,典型值为200
根据对软件平均无故障时间的要求,估计需要改正多少个错误之后,测试工作才能结束
估计错误总数方法:
-
植入错误法:植入错误引发错误与原有错误引发错误的比例
-
分别测试法:标记已知错误的代码,与未标记代码的比例