文章目录

• 一、编码
• • 1、概念
  • 2、如何选择程序设计语言
  • 3、程序设计风格
  • • （1）源程序文档化
    • (2) 数据说明
    • （3）语句构造
    • （4）输入输出
    • （5）程序效率
    • 编码时提高程序运行效率的主要规则
• 二、软件测试基础
• • 1、软件测试的目的
  • 2、 软件测试准则
  • 3、测试方法
  • • 静态测试：
    • 动态测试：
  • 4、测试步骤
  • 5、测试阶段的信息流——与测试密切相关的工作
• 三、单元（模块）测试
• • 1、模块接口
  • 2. 局部数据结构
  • 3. 重要的执行通路
  • 4. 出错处理通路
  • 5. 边界条件
  • 单元测试的工具
  • 单元测试可以采用哪两种策略和方法？
• 四、集成测试（测试和组装软件的系统化技术。
• • 1、渐增式测试
  • 2、自顶向下集成
  • 3、自底向上集成
  • 五、确认测试
  • • Alpha和Beta测试
• 六、白盒测试技术
• • 1、基本路径测试
• 七、黑盒测试技术
• • 黑盒测试技术：
• 八、调 试
• 九、软件可靠性
• • 1、概念
  • 2、 软件的可用性 =软件系统可以使用的程度
  • 3、估算平均无故障时间

一、编码

1、概念

选择一种程序设计语言，把详细设计的结果翻译成用选定的语言书写的程序。

2、如何选择程序设计语言

• 大量实践结果表明，高级程序设计语言有很多优点，除非不得已才使用汇编语言。
• 选择哪种高级语言既考虑到语言本身的特点，又要考虑到使用环境等实际因素。

3、程序设计风格

（1）源程序文档化

• 标识符的命名

标识符名包括模块名、变量名、常量名、标号名、子程序名、缓冲区名等。
这些名字应能反映它所代表的实际东西，应有一定实际意义。例如，表示次数的量用Times，表示总量的用Total，表示平均值的用Average，表示和的量用Sum等。
名字不是越长越好，应当选择精炼的意义明确的名字。必要时可使用缩写名字，但要注意缩写规则要一致，并且要给每一个名字加注释。同时，在一个程序中，一个变量只应用于一种用途。

• 安排注释

夹在程序中的注释是程序员与日后的程序读者之间通信的重要手段。
注释决不是可有可无的。
一些正规的程序文本中，注释行的数量占到整个源程序的1/3到1/2，甚至更多。
注释分为序言性注释和功能性注释。

• 程序的视觉组织

恰当地利用空格，可以突出运算的优先性，避免发生运算的错误。例如 ，将表达式 (A＜－17)ANDNOT(B＜＝49)ORC写成 (A＜－17) AND NOT (B＜＝49) OR C
自然的程序段之间可用空行隔开。
对于选择语句和循环语句，把其中的程序段语句向右做阶梯式移行(向右缩格)。使程序的逻辑结构更加清晰。

(2) 数据说明

• 数据说明的次序应该标准化。有次序的优点:易查阅、测试、调试和维护。
• 当多个变量名在一个语句中说明时，应该按字母顺序排列这些变量。
• 如果设计时使用了一个复杂的数据结构，则应该用注解说明该数据结构的方法和特点。

（3）语句构造

应该遵循的原则是：

• 每个语句都应该简单而直接，不能为了提高效率而使程序变得过分复杂；
• 也不要刻意追求技巧性，使程序编写得过于紧凑。

（4）输入输出

在设计和编写程序时应该考虑下述有关输入输出风格的规则：

• ①对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性。

• ②检查输入项的各种重要组合的合法性，必要时报告输入状态信息。

• ③使得输入的步骤和操作尽可能简单，并保持简单的输入格式。

• ④输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目。

• ⑤在交互式输入时，要在屏幕上使用提示符明确提示交互输入的请求，指明格式和取值范围。

• ⑥给所有的输出加注解，并设计输出报表格式.

（5）程序效率

程序的效率是指程序的执行速度及程序所需占用的内存存储空间。

提高程序效率的几条准则：

• ①效率是一个性能要求，应当在需求分析阶段给出。软件效率以需求为准，不应以人力所及为准。
• ②好的设计可以提高效率。
• ③程序的效率与程序的简单性相关，不要牺牲程序的清晰性和可读性来不必要地提高效率。

编码时提高程序运行效率的主要规则

• 写程序之前先简化算术的和逻辑的表达式。
• 仔细研究嵌套的循环，以确定是否有语句可以从内层往外移。
• 尽量避免使用指针。
• 不要混合使用不同的数据类型。
• 尽量使用整数运算和布尔表达式。

二、软件测试基础

1、软件测试的目的

软件测试的工作量约占整个项目工作量的40％以上，对于人命关天的系统测试工作量还要成倍增加（成本是其他部分的成本的3~5倍）。

尽可能多地发现并排除软件中潜藏的错误，最终把一个高质量的软件系统交给用户使用。

2、 软件测试准则

• pareto原则：测试发现的错误中的80%很可能是由程序中20%的模块造成的。 找出这些可疑的模块并彻底地测试它们。
• 为了达到最佳的测试效果，应该由独立的第三方从事测试工作。
• 应该从“小规模”测试开始，并逐步进行“大规模”测试：

3、测试方法

静态测试：

基本特征是在对软件进行分析、检查和审阅，不实际运行被测试的软件。

• 对需求规格说明书、软件设计说明书、源程序做检查和审阅，包括：
  是否符合标准和规范。
  通过结构分析、流图分析、符号执行指出软件缺陷。
• 静态测试约可找出30%～70%的逻辑设计错误。

动态测试：

通过运行软件来检验软件的动态行为和运行结果的正确性。
动态测试的两个基本要素：

• 被测试程序
• 测试数据（测试用例）

动态测试方法：

• (1) 选取定义域有效值,或定义域外无效值；
• (2) 由已选取值获取预期的结果；
• (3) 用选取值执行程序；
• (4) 执行结果与预期的结果相比,不吻合则表示程序有错。

4、测试步骤

• 1. 模块测试 —目的是保证每个模块作为一个单元能正确运行，通常称为单元测试。
• 2. 子系统测试—把经过单元测试的模块放在一起形成一个子系统来测试，着重测试模块的接口。
• 3. 系统测试—把经过测试的子系统装配成一个完整的系统来测试，以保证能提供需求说明书中指定的功能。主要发现编码、软件设计、需求中的错误。
• 4. 验收测试—将软件系统作为一个单一的实体进行测试，在用户参与下主要使用实际数据进行的，以发现需求说明中的错误。
• 5. 平行运行—新旧共存。不冒风险、让用户有一段时间熟悉新系统、以准系统的形式进行全负荷测试。

5、测试阶段的信息流——与测试密切相关的工作

三、单元（模块）测试

1、模块接口

（1）输入的实际参数与形式参数的个数是否相同；
（2）输入的实际参数与形式参数的属性是否匹配；
（3）输入的实际参数与形式参数的量纲是否一致；
（4）输入的实际参数与形式参数的次序是否一致；
（5）是否存在特征耦合；
（6）全局变量的定义和用法在各个模块中是否一致等。

2. 局部数据结构

局部数据说明、初始化、默认值等方面的错误：
（1）不合适或不相容的类型说明；
（2）变量无初值；
（3）变量初始化或省缺值有错；
（4）不正确的变量名（拼错或不正确地截断）等。

3. 重要的执行通路

由于不能穷举测试，因此，选择最有代表性、最可能发现错误的执行通路进行测试十分关键。在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。应该设计测试方案用来发现由于错误的计算、不正确的比较或不适当的控制流而造成的错误。

4. 出错处理通路

一般这种测试着重检查下列问题：

• （1）检查对错误的描述是否是难以理解；
• （2）描述错误的信息不足以确定错误的位置；
• （3）记录的错误与实际遇到的错误不相符；
• （4）对错误的处理不正确等。

5. 边界条件

由于软件常常在它的边界上失效，因此，边界测试是单元测试中最重要的任务。

单元测试的工具

• CppUnit：C++单元测试工具的鼻祖，免费的开源单元测试框架。
• C++Test：是一个功能强大的自动化C/C++单元级测试工具。
• JUnit ：Java语言的单元测试首选产品。

单元测试可以采用哪两种策略和方法？

• 1、静态测试方法<----代码审查

代码审查的步骤：
小组成员先研究设计说明书，力求理解这个设计。
由设计者扼要地介绍他的设计。
审查会上程序的编写者逐个语句地解释是怎样用程序代码实现这个设计的。
审查会上对照程序设计常见错误，分析审查这个程序。
当发现时，记录错误，继续审查。

• 2、动态测试方法<----计算机测试

四、集成测试（测试和组装软件的系统化技术。

）

1、渐增式测试

该方法每次将一个要测试的模块同已经测试好的那些模块结合起来进行测试，如此反复,直到所的模块都测试完毕。

渐增式测试包括:自顶向下集成和自底向上集成。

2、自顶向下集成

• 不足：因为存根代替了低层次的模块，因此在软件结构中没有自底向上的数据流。

• 解决办法：可将测试推迟到用真实的模块代替存根模块以后再进行，或自底向上进行组装软件。

3、自底向上集成

混合法：

• 对软件的顶部两层模块使用自顶向下方法，以减少驱动程序；

• 对软件结构中较下层使用自底向上方法相结合。以早期发现低层模块的错误，并充分利用人力。

五、确认测试

• 确认测试也称为验收测试，它的目标是验证软件的有效性。

• 需求分析阶段产生的软件需求规格说明书，准确地描述了用户对软件的合理期望，因此是软件有效性的标准，也是进行确认测试的基础。

Alpha和Beta测试

• Alpha测试由用户在开发者的场所进行（不能由程序员或测试员完成 ），并且在开发者对用户的“指导”下进行测试。开发者负责记录发现的错误和使用中遇到的问题。该测试是在受控的环境中进行的。
• Beta测试由软件的最终用户们在一个或多个客户场所进行。Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户记录在Beta测试过程中遇到的一切问题（真实的或想像的），并且定期把这些问题报告给开发者。接收到在Beta测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。

六、白盒测试技术

白盒测试：也叫结构测试，它允许测试人员利用程序内部的逻辑结构及有关信息，设计测试用例，对程序的逻辑路径进行测试。
测试用例:为测试设计的数据。主要由测试输入数据和预期的输出结果两部分组成。

1、基本路径测试

• 第1步：画出程序流图
• 第2步：计算程序的环形复杂度P （表示程序基本路径集中的独立路径数的上限）
• 第3步：确定独立路径的基本集合
• 第4步：从该基本集合导出测试用例
• 第5步：执行测试用例
• 第6步：写测试报告

七、黑盒测试技术

黑盒测试着重测试软件功能。黑盒测试并不能取代白盒测试，它是与白盒测试互补的测试方法，它很可能发现白盒测试不易发现的其他类型的错误。

黑盒测试力图发现下述类型的错误：

• ①功能不正确或遗漏了功能；
• ②界面错误；
• ③数据结构错误或外部数据库访问错误；
• ④性能错误；
• ⑤初始化和终止错误。

黑盒测试技术：

• (1)等价划分法：把程序的输入域划分成若干个数据类，据数据类导出测试用例。
• (2)边界值分析法
• (3)错误推测法
• (4)因果图法等

八、调 试

调试（也称为纠错）作为成功测试的后果出现，也就是说，调试是在测试发现错误之后排除错误的过程。

九、软件可靠性

1、概念

对于软件可靠性有许多不同的定义，其中多数人承认的一个定义是：
软件可靠性是程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。

2、 软件的可用性 =软件系统可以使用的程度

如果在一段时间内，软件系统故障停机时间分别为td1，td2，…，正常运行时间分别为tu1，tu2，…，则系统的稳态可用性为：
Ass=Tup/(Tup+Tdown) (7.1)
其中Tup=∑tui，Tdown=∑tdi
如果引入系统平均无故障时间MTTF和平均维修时间MTTR的概念，则(7.1)式可以变成
Ass=MTTF/(MTTF+MTTR)

3、估算平均无故障时间

经验表明，平均无故障时间与单位长度程序中剩余的错误数成反比，即
MTTF=1/[K(ET/IT-Ec(τ)/IT)] (7.5)
其中K为常数，它的值应该根据经验选取。美国的一些统计数字表明，K的典型值是200。

由(7.5)式可得
Ec=ET-IT/(K×MTTF) (7.6)
因此，也可以根据对软件平均无故障时间的要求，估计需要改正多少个错误之后，测试工作才能结束。

example：

对一个长度为100,000条指令的程序进行测试，记录下来的数据如下：
测试开始，发现错误个数为0；
经过160小时的测试，累计改正100个错误，此时， MTTF = 0.4小时；
又经过160小时的测试，累计改正300 个错误（表示自始至目前），此时，MTTF = 2小时；

给出估计程序中固有的错误总数ET的公式并估算ET和经验常数K的数值。

解：MTTF=1/[K(ET/IT-Ec(τ)/IT)]
0.4=1/[k(ET/100000-100/100000)]
2=1/[k(ET/100000-300/100000)]
得到： K=1000, ET=350