软件测试思想_V0728

对软件的简单认识是：数据+程序

数据：包括键盘输入，鼠标单击，磁盘文件，打印输出 程序：可执行的流程，转换，逻辑和运算。

软件并不是只是包括在计算机上运行的程序，与程序相关的文档，也被称为是计算机软件的一部分。它是程序(Doucunetm)、文档，的集合体。

系统软件：负责计算机系统中各种独立的硬件，使他们可以协调工作。系统软件使计算机使用者和他软件当作一个整体而不需要考虑底层每个硬件是如何工作的。

应用软件：是为了某种特定的目的而开发的软件，他可以是一个特定的程序，如一个图像浏览器，也可以是一组功能联系密切，可以互相协作的程序的集合，比如微软的office，也可以是独立的程序组成的庞大的软件系统，如数据库管理系统。 编写软件的目的：为了解决现实问题。

软件产品到底是什么：软件不仅指从互联网上下载下来或DVD光盘安装到计算机程序，实际上制作软件还包含很多隐含的内容。如：数据库，操作动作，中间件（tomcat 、iis、weblogic、wordpress websphere），不同平台，这些地方都有可能存在缺陷（隐含内容等扩展）。这些地方要铭记在心，因为这些全是可测试的象，并且有可能包含缺陷。

BOOS BSD dos linux 电脑操作操作系Mac OS/更名为(IOS) OS/2 QNX 操作系统 windows OS Anroid 软件系统ios 手机操作系统 Windows phone 塞班

操作系统补丁程序 驱动程序 编译器 数据库管理 存储器格式化 文件系统管理 用户身份验证 驱动管理 网络连接 机器语言 语言处理程序 汇编语言 诊断程序 CPU 主板 高级语言 2、 软件缺陷

（1） 美国电气工程师按外部、内部给缺陷的定义：从产品内部看，是软件开发或维

护过程中存在的错误、毛病等问题。从产品外部看，缺陷是系统所需实现的某种功能的失效和违背。简单地说，用户在软件使用过程中，遇到软件的某种功能，错误和异常都可以称为“软件缺陷”

（2） 计算机软件或程序中的存在的某种破坏性的正常运行能力的问题，错误或隐藏

的内容功能缺陷。

（3） 软件缺陷除了失效以外，还体现在其他方面，如软件未实现产品说明书要求的

功能；软件出现产品说明书指明不应该出现的功能，

（4） 软件出现说明书指明未提到的功能。

（5） 软件难以理解，不易使用，运行缓慢，或者从软件测试人员的角度看，认为用

户最终会觉得不好。

软件测试人员是真正第一个使用软件的人，如果软件测试人员在使用软件的时候发现某些地方要不对劲，无论什么原因，都要认定为缺陷。但每一个使用软件的人都会有自己的想法和意见，要编写所有的用户都满意的软件是不可能的，所以在运用第5时，要记住一点：要全面，客观准确，并非所有测试发现的缺陷都要修改的。不能判定是否是缺陷的时候要进行确认和验证两个过程。

软件缺陷的定义二：是人工的自动化的手段来运行机制或测试村个系统过程其目的在于检验它是否满足规定的需求，或弄清预期结果与实际结果的差别。

3、 缺陷报告的组成

一、 缺陷编号

缺陷类型(type) 缺陷严重程度 (severity) 缺陷优先级(priority)

缺陷状态status)

微小的(minor) 一般的(major) 严重的（critical） 致命的(Fatal) urgent Very high high medium low urgent Very high high medium low 激活状态（open/reopen） 已修正状态（fixed） 关闭状态（closed） 拒绝的状态（reject） 新提交的状态（new） 缺陷起源(origin)：被引起故障帮第一次检测的阶段 缺陷来源(source)：引起缺陷的起因 需求不清晰 系统结构复杂 对实时的应用要精心处理 没有考虑到系统崩溃后的自我恢复或数据库备份，灾难性问题 缺陷根源(root sause)：缺陷根源指发生错误的根本因素

1、软件本身 系统运行的复杂，不仅用户使用的计算机千变万化，包括用户输入的数据容易引起一些问题。 通信端口多，加密手段的矛盾性，会造成系统的安全性和适用性 新技术的采用，可能涉及技术或系统的兼容性问题，事先没有考虑到 系统需求分析对客户需求理解不清楚，和用户的沟通存在一些困难。 不同阶段的开发人员相互理解不一致，

如：软件设计对需要分析有误差，编程人

员对系统设计规格说明书某些内容不够 2、团队重视，或存在误解 工作

对于设计或编程上的一些假定或依赖性， 相关人员没有充分沟通。

项目组成员水平参差不齐，新员工多，培

训不足

算法错误

语法错误

计算和精度问题

3、技术

问题 系统结构不合理，算法不科学

接口参数传递不匹配，导致模

块集成出现问题

1、缺乏质量文化，不重视质量计划，对质量、

资源，任务，成本等平衡性把握得不好，容易挤

掉需求分析，评审，测试时间，遗留的缺陷会比

较多。

系统分析时对客户需求不是很清楚，或者和用户

沟通存在一些困难。

4、项目 开发周期短 管理问

题

开发流程不够完善，存在太多随机性或缺乏严谨

的内审或评审机制，容易产生问题

文档不完善，风险评估不足

]

大多数软件缺陷并非源自编程错误，从众多从小到大的项目进行研究而得出的结论是一致的，导致软件最大的原因是产品说明书，第二大来源是设计院，这里产生软件缺陷的原因与产品说明书是一样------随意，易变，沟通不足，有一句话叫“说不出就做不到”用到软件开发和测试身上再合适不过。代码错误可以照片于的复杂性，文档不足或普通

低级错误。而看上去是编程错误的代码是产品说明书和设计方案造成的。还有一类误解，即本来正确的当成缺陷，还有一些是多处重复出现，实际上是一个原因引起的，一些可归咎于测试错误。

产品说明书常常没写，说不出来就做不到，其他原因是说明虽然有，但是不完整，不停的更改，不停的更改，或者产品说明书内容没有同开发小级其他成员沟通过。

缺陷报告（二） 缺陷编号(Defect ID) 缺陷标题(summary)

缺陷的发现者(Defect by) 缺陷发现日期(Defect By) 缺陷所属模块(subject)

指派缺陷的版本(Defected in release) 指派给谁处理(assigned to)

缺陷状态:status:new open,rejected ,fixed,reopen,closed 缺陷的严重程度:urgent,very high high,medium,low 优先级urgent,very high high,medium,low

缺陷的严重程序和优先级的关系：严重程度一般不会修改，优先级可以适当妥协，严重程度较低的，但是优先级可能最高。

4、 第一个软件缺陷的领导者是美国海军将军，编译器的发明者，领导了cobol语言，（面商

业的通用语言）-cobol common business oriented language

5、 以另外一种方式来思考，两个人对同一个软件都会持不同的见解，一个说很完美，一个

说缺陷很多，一定是一个人以某种运行软件时暴露了大量的问题。 6、 软件结构的分类

单机软件

C/S(client/server客户端)服务器：如：qc,msn,qq，游戏，特 点：客户端采用专门的软件 分布式软件 B/S(broner/server)浏览器/服务器电子商务网站，论坛，优点， 软件的更新，只需要服务器程序。

客户端：是更新后的效果，开发维护容易。不足：客户显示效果不如b/s，但是目前正在优

化，朝着(rich client富客户端趋势发展)，技术javascript jquery

7、 主流的浏览器

IE,firefox,safari(苹果),chrome，opear

8、 ENIAC:电子数字积分计算机，elect onic numberical integrator and caluator 美国宾西法尼

亚大学，莫尔学院，1946 9、 测试的步骤

（1）编写测试用例 （2）编写测试用例

（3）执行用例，发现缺陷，提交缺陷报告 （4）验证所发现的缺陷是否得到修改 （5）编写测试总结报告 10、测试计划的组成 简介 参考文档 测试文档 提交文档 熟悉系统需求 编写测试计划 执行用例 测试进度 总结报告 Alpha测试 Beta测试 描述严重程度 测试资源 缺陷优先级 问题的严重程度和优先级 缺陷跟踪及返测 版本号 风险分析

测试策略 黑盒测试，白盒测试，灰盒测试 手工测试、自动化测试， 基准测试 并发测试 综合场景测试 功能测试，性能测试 疲劳强度测试 内存泄漏测试 数据容量测试 极限测试 递增测试 负载测试70吨是负 压力测试70吨是压力 容量测试60是容量 安装测试 硬件兼容 测试策略 兼容性测试 软件兼容 界面测试 文档测试 恢复测试 回归测试 易用性测试 对比测试测试 测试策略中的术语： 黑盒测试（功能测试）：软件测员只需要知道要什么-----而无法看到盒子里的软件是如何运行的。只要进行一些输入，就能得到输出结果。他不知道软件如何运行，为什么这样，只知道程序做了什么？动态黑盒测试常常称为行为测试，因为测试的是软件在使用过程中的实际行。 有效的动态测试需要关于软件行为的一些定义-----即需求文档或产品说明书。好的产品说明书会提供这些细节。 白盒测试（透明盒测试）：软件测试员可以访问程序员的代码，并通过检查代码的线索来协助测试---可以看到盒子里面。测试员根据代码检查判断多或少可能出错的数据。并据此定制测试。有时也称为结构化分析，找出动态黑盒测试难以发现或隔离的软件缺陷，为黑盒测试测试员在接受软件进行测试时设计和应用测试用例提供思路。

动态白盒测试是指利用查看代码功能（做什么）和实现方式（怎么，做）得到的信息来确定哪些测试，哪些不需要测试，如何开展测试，如何开展测试。动态白盒测试的另一个常用名称是结构化测试，因为软件测试员可以查看并使用代码的内部结构从而设计执行测试。 动态白盒测试不仅仅是查看代码的运行情况，还包括直接测试和控制软件，动态白盒测试包括以下四个部分：直接测试底层函数，过程，子程序和库，在micrsoft windows 中这样[称为应用程序编程接口（API）。以完整的程序的方式从顶层测试软件，但是根据对软件运行的了解调整测试用例；从软件获得读取变量和状态信息的访问权，以便确定测试与预期结果是否相符，同时强制软件以正常测试难以实现的方式运行；估算执行测试时“命中”的代码量和具体代码，然后调整测试，却掉多余的测试用例，补充遗漏的用例。

一定不要把动态白盒测试和调试(debugging)搞浑了，不是一个概念。动态白盒测试的目标寻找软件缺陷，调试的目标是修复缺陷。软件测试员应该把问题缩减为能够演示软件缺陷的最简化的测试用例。如果白盒测试，甚至还要包括那些值得怀疑的代码行信息静态测试：测试不运行的部分，只是检查和审核。 如果要进行了动态白盒测试的思路：

一， 首先可以确定模块属于程序中的底层模块，可以由高层模块调用，但是自己不能调

用其他模块，通过查看代码可以确认这一点。（合理的做法是编写一个测试驱动以独立于程序其他部分的形式测验该模块），测试可以是多种形式的，可以是输入字符串并查看结果的，也可以是文件读取测试字符串的预期结果的独立程序。 二， 分析说明书，确定应该采用户黑盒测试用例，运用等价类划分技术减少测试用例集

合。在进行了白盒测试之前，一定要根据说明书建立黑盒测试用例，用[这种方式可以真正测试模块的功能和作用。如果先从模块的白盒角度建立测试用例，检查代码，就会偏向于以模块工作方式建立测试用例。程序员或许误解了说明，于是测试用例就会不对。 动态测试：是通常意义上的测试----使用和运行软件。

10、 11、缺陷报告要注意的问题

（1） 一个报告只提交一个缺陷

（2） 缺陷描述准确，易读，使用最少必须步骤，保证缺陷可以重现，缺陷的描述要

做到追根溯源，简明扼要，面面俱到。

制定统一的checklist，并且经过项目负责人的评审，如果遇到歧义，和开发人员交流，以checklist为准，对缺陷的严重性，优先级准确，客观。

（3） 在提交缺陷时，一定要认真审核，确保缺陷是有限的。 （4） 不要为了引起开发的重视而夸大缺陷 （5） 及时报告缺陷 （6） 不做任何评价

（7） 对于不可重现的缺陷也要报告

（8） 因类测试人员以边界值或错误猜想法的设计用例而发现的缺陷，可能引起开发

的不认同，测试人员要分析引导开发了解系统的潜在风险，提高开发人员的质量意识。

12、 缺陷报告的处理流程 测试人员 提交缺陷报告new 开发经理/项目经理 分配缺陷报告open 开发人员 处理缺陷报告 fixed 测试人员 返测通过 关闭 13、 八种编写测试用例方法

（1） 等价类 （2） 边界值 （3） 因果法 （4） 判定法 （5） 场景法 （6） 正交法 （7） 状态转换法 （8） 测试大纲法

（9） 随机测试（猴子测试）

等价类：对程序的规格说明有意义的，合理的输入数据集合。

如果用户输入的是有效等价类中的数据，程序应该正确计算执行。等价类划分是把海量（无限）的测试用例减得很小。一个等价类和等价划分是指测试相同目标或者暴露相同软件缺陷的一组测试用例。

步骤：一、划分等价类，二细分等价类，三建立等价类，编写测试用例 适合场合：任何有输入的地方都可以使用等价类。

无效等价类：对程序的规格说明不合理无意义的输入数据集合，如果用户输入无效等价类中的数据，程序应该给予错误提示，不允许用户输入。相比于有效等价类，无效等价类主要软件的健壮性（容错性），程序异常处理能力。 选择等价类的原则：对于不同的有效等价类，尽可能在一条测试用例中使用测试仪，这样可以减少测试数量，在一条用例中覆盖多的有效等价类，对于不同控制的无产等价类，一条用例只覆盖一条，一个控制的无效等价类，可以考虑无效的组合，排除其他因素的干扰。(注：老采矿者的话，适用于这个原则：“出去找一样东西，并且就只找这样东西”。

根据一些关键的关键来进行等价划分，这些关键就是：边界条件，次边界条件，空值，无效数据（非法，错误，不正确，垃圾数据（重复，压迫，重负）），默认值，空值，0值，，空白，无

等价类划分的目标：把可能的测试用例集缩减到可控制且仍然足以测试软件的范围内。不过，为了减少测试用例的数量的过度划分等价类，就有漏掉那些可能暴露软件缺陷的风险。

边界值法：一般取六个值。 边界的数据类型：

数值，字符，位置，数量，速度，地点，尺寸

而这些类型需要考虑的特征：

第一个/最后一个,最小值/最大值,开始/完成,超过/在内,空/满,最短/最长,最慢/最快,最早/最迟,最大/最小,最高/最低,相邻/最远。 软件的每一部分寻找边界是非常重要的，，边界就会发现得越多，可能得出的软件缺陷就越多。 因果法：

因果法适合场合：因果限制每个控件的条件，不宜过多，最多两个，比较适合单选钮，复选框，下拉列表。 四个因果符号：恒等=

非~ 或V 与^

因果中的条件：互斥E 包含I 唯一O 要求R 屏蔽M

使用因果法的步骤：（1）找出所有的输入动作，编写，（2）找出所有的结构。 （3）在步骤1的基础上，找出输入动作限制关系和组合关系。如2,3互斥 注：哪些是不能组合的，哪些是能组合在一起的确，是测试用例的数量。

（6） 在步骤2的基础上，找出输入输出的限制组合关系。 （7） 什么样的输入组合步骤，会产生什么样的输出组合 （8） 根据判定表编写测试用例

正交表：正交排列法是以正交表为基础的，根据控制的个数与每个控制取值个数不同，选定一个合适的正交表后，然后进行映射即可。

正交表的使用场合：在一个界面中有多个控件，有多个值，测试时考虑不同组合。 LnMk

N下标k上标

N表示表的行数，也就是需要测试的组合的次数。 K表示表的列数，表示控件的个数，（因素的个数或因子数）

M是每一个控件的取值个数（各因素的水平数，在因素状态数表示每个摈件有两种选择）

使用正交表编写测试的步骤：

（1） 根据控件的个数把每个控件的取值个数，选择一个合适的正交表编写用

例。

（2） 把程序的控件的取值整理成表格（熟悉需求）

（3） 把控件名称映射到正交表，把每个控件取值正交表的每道取值。 （4） 编写测试仪用例。正交表的一对应一条用例。

正交表的特点：正交表的思想选择数据时要均匀，零星一的进行的进行选取，而不能集中某个局部，保证控件都组合，并且每个控件组合的次数都在应该相同，每个控件的取值应该接近；控件的取值个数相同最多个（也就是说其中的选项数都是几种，如打印范围和颜色灰度都是3可选项，所以选底为3的，按控件值最多的选取，）

注：正交表360网盘

场景法：

场景法的定义模拟用户使用可能场景（情景）主要测试仪软件重要功能，是否实现，此方法结合等价类使用，以软件需求为中心，充分理解业务之上，以等价类为基础。

场景法的主要概念，基本流（正确流）-有效等价类-按照正确的业务流来实现的一样操作路径。备选流（出错流）-无效等价类，导致程序出错。

状态转换图的应用场合把所有的状态操作步骤，操作顺序是场景法具体实施应用。

核心：一连串状态分解，进行程序分析，可以把复杂的程序，流程简单化。 定义：找出软件的所有状态惟及导致状态变化的所有的输入动作，进而图形的方法把相关联的用户输入动作状态一起，真实的模拟出用户操作顺序流程，编写测试用例。

状态转换图的步骤：（1）找出程序的所有的输入入动作，并进行编号，找出所有的状态，找出是什么动作导致状态发生，画出状态转换图（一般情况下这是个反复的过程）

把关联的动作和状态联系起来。 状态转换图注意事项：

每种状态的至少访问一一次，无论用什么办法，每一种状态都必须测试； 从一种状转入另一种状态所需的输入和条件；

进入或者退出某种状态时的设置条件及输入出结果。

测试看起来最常见最普通的状态，可以根据产品说明书，通过与客户开发人员沟通，了解哪些是常用更重要的：

测试状态之间最常用户分支，这此分支最容易产品设计者忽略，也要测试 测试所有错误状态及其返回值，错误提示不正确等情况是常有。

测试大纲法：

应用场合：在程序和模块中，涉及到多窗口和多动作间有一定关联性，为了弄甭窗口口之间的关系，或者说动作与动作之间的关系，我们可以用大纲法 测试大纲法，找出所有窗口以及窗口的输入动作。找出窗口与窗口之间的关联。 随机测试：向普通用户一样，对软件进行测试。

测试方法的重要级：高到低

场景法/等价类和边界值/因果法/判定表/正交排列法/状态转换法/测试大纲法/使用错误猜测和随机/测试补充用例（根据需求文档中如果有错误类型，用报错来看用例有无遗漏，特别适合硬件测试的错误码报错）

个人觉得这么多方法，就场景，等价，边界值是最最常用的。

14、 软件测试阶段的划分

单元测试的概念：针对性每个单元的测试，确保每个模块正常工作。

在底层进行的测试称为单元测试（unit testing）或者模块测试(module testing)，单

元测试，底层软件缺陷被找出并修复之后，就集成在一起，对模块组合进行了集成测试。直到整个产品，至少是产品的主要部分，在称为系统测试的过程中一起测试。

驱动模块：模拟上一个模块（调用被测模块的那个模块）

集成测试：通常单元测试基础上，将所有的程序模块进行了有序的测试。集成测试是检验单元或部件的接口关系，逐步成为符合要求程序部件或整个系统。 自顶向上：成佬，深度优先。自底向上；面向过程的系统采用的两种方法。

系统测试仪：对集成的软件进行了整理体的测试仪确认测试，在系统测试之前，对软件的重要性进行测试，确认软件的主要功能，可以全面的系统测试修复。

Alpha测试：开发环境下进行的测试，由于开发方包括测试仪人员进行的测试，主要由用户参与，最好在测试仪人员的指导下，进行了全面细致的测试仪，

Beta用户环境下进行测试，主要由用户参与，最好在测试人员的指导下，进行了全面细致的测试。 自顶向下 单元测试 增式集成 自底向上 非增式集成 集成测试 混合测试 系统测试：功能性测试、安全性测试、可靠性，负载测试、易用性测试，强 度测试仪，配置安装测试仪，卸载测试，文档测试，故障恢复测试，界面测 试，容量测试，兼容性测试，分布置式测试，可用性测试仪。 Alpha测试 验收测试 Beta测试 15、 测试模型 正式验收测试 V模型 验收测试 需求分析 系统测试 概要设计 详细分析 集成测试 编码 单元测试

W模型 用户需求V&V 用户需求 验收测试设计 需求分析与系统需求分析与 测试V&V确认与与系统设计 系统测试设计 概要设计 详细设计V&V单 元设计测试 详细设计 单元测试 编码

W模型有两种 需求测试 需求分析 概要设计 概要设计 详细设计 详细设计 编码实现 交付 验收测试 实施 确认测试 集成 集成测试 系统安装 验收测试 系统构建 系统测试 模块集成 集成测试 单元测试

W模型也有局限性，W模型和V模型都把软件的开发[视为需求，设计，编码等一系列的串行的活动，无法实现迭代，自发性，变更调整。 X模型

程序片段 测试设计 工具配置 编码完成 执行模型 工具配置 测试设计 程序片段 封版 执行测试 测试设计 工具配置 集成 探索性测试 执行测试

X模型是对V模型的改进，X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的效接，通过集成最终为可执行的程序。

X模型的左边描述的是针对单独程序片断进行编码和测试，此后将进行频繁的交接，通过集成是终成功可执行程序。然后对这些可执行程序进行测试，已通过集成测试的成员可以封装并提交给用户，也可以作为更大规模和范围内集成的部分。多根并行曲线的变更表示可以在各个部分发生，X模型还定位了探索性测试，这是不进行事先测试的特殊类型的测试。这一方式往往能帮助有经验的测试人员找出更多的软件错误，但这样可能对测试造成人力，物力财人的浪费，对测试人员的熟练度要求高。 H模型 测试流程 测试准备 测试执行 其它流程 H模型提示了一个原理，软件测试是一个独立的流和，贯穿于产品整个生命周期，与其它流程并发操作。软件测试过程模型V模型是软件开展瀑布的模型的变种，主要反映测试活动分析设计的关系，局限性：把编码作为最后一个活动，需求分析产生的错误直到后期的验收测试才能发现。W模型————增加了开发阶段的同步测试仪，形成W模型，测试与开发同步进行，有利用尽早发现问题。局限性：仍把开发活动看成需求开始到编码的串行活动。只有上一阶段完成才能进行一下一阶段的活动，不能支持迭代，自发性以及变更调整， H模型是完全独立的，某个测试点准备就绪时，就可以从准备阶段到测试执行阶段，软件测试可以尽早的进行软件测试可以根据被测试物的不同而分层次进行。

V模型强调了整个软件项目开发中需要经历的若干个级别，并与每一个开发并发对应，忽略了测试对象不应该仅仅包括程序，没有明确指出需求设计的测试。

W模型：补充了V模型中忽略的内容，强调了测试计划等工作的先行对系统需求和系统设计院的测试，与V模型要相同，测试软件测试进行流程的说明 H独立的，只要测试准备完成，就可以执行。 软件测试 ron patton张小松

16、 软件测试工程师应该具备的素质：

（1） 探索者（2）故障排除员（3）不放过任何蛛丝蚂迹难以重现的缺陷不会当

作偶然而放过。（4）追求完美，当无法企及时，不苛求，尽力接近目标。好的软件测试人员知道何时无法企及完美，何时时达到够好。 （5） 判断准确（6）注重策略和外交（7）善于说服（8）学习能力强

（9） 表达能力强、沟通能力 (10)耐心 (11)细心（12）信心（13）责任心 (14)能承受

抗压能力(15)软件测试是一项批判性工作，所以要具有批判性精神，软件测试是一项要坚持必要的原则的工作

(16)好的软件测试人员，要对软件的开发全过程有个总体的了解.

17、软件失败的术语：

缺点：dffect 偏差：variance 故障：fault 失败:failure 问题：problem 矛盾：inconsictency 错误:error 特殊：feaure 事件incient 缺陷：bug 异常：anomaly

术语的多样化由于公司文化和开发软件的过短。公司或开发小组用来称呼软件总理的意义不是很重要，但重要的是，讨论用什么词来描述软件问题意义在于：对软件测试员来说了与自己合作的产品开发小组的特点是很重要的，提及软件问题的方式反映出他们处理整个开发的过程的方式，可以看出他们是谨慎，小心还是简单生硬。

18、 产品说明书

辅助性术语：产品说明书有时称为说明(spec)或产品说明书(product spec)，是软件开发小组的一个协定，它对开发的产品进行了定义，给出细节，如何做，做什么，什么时候做。 19、 软件缺陷的修复费用

软件缺陷的费用是随着时间的推移而增加的，费用指数级的增长，随着时间的推移，费用呈十位增长。 1000 100 10 1

说明书设计编码发布 20、 软件测试员的目的

软件测试员的目的是尽可能找到软件缺陷并确保期限得以修复，但要记住，“修复”并非指软件一定要改正软件，可以在用户手册中加一段注释或为用户提供特殊的培训（这样也算处理发生一部分的缺陷的方式）

21、 几个臭名昭著的软件错误的研究

迪斯尼的狮子软件缺陷是由于兼容性测试没有做到位的著名案例，因为没有做好兼容性测试的工作，所以带来了昂贵的成本代价，如果早一点发现缺陷就不会产生后期如此大的影响。英特尔奔腾浮点除法说明是对软件缺陷的重视程序和处理方式会极大的影响企业。所以这里再次证明运用缺陷规则中第5点，要注意的事，无论什么不对劲的地方，都要定义为缺陷，即使不修改也要在用户手册中说明，因为处理缺陷的方式好坏，很大程度上会有后期影响。

美国航天局火灾星极登陆者探测器，这个软件缺陷从测试阶段上来看完全是因为没有按照测试阶段执行完成，不进行系统测试带来的问题。爱国者导弹防御系统这个软件缺陷要值得注意的地方是在测试的时候再小的问题也要引起重视，并分析后期带来的影响。

千年虫的问题，在1974千年虫的问题测试时一些预见的措施不足，危险的预见2004说明预见能为我们屏蔽很多潜在风险，降低或减少一些不必要的成本支出。千年虫的中，程序员应该对这个显疏忽疑问而不是仅仅将程序设计到

1999年，由于他没有这样做，软件测试人员就应该测试并发现该缺陷，然后由开发小组确定是否修正。

22、 软件行业中，用来描述制造并交付他人的软件产品组件术语是可交付部分

（deliverable），解释所有的可交付部分是最简便的方法是分门别类。 23、 一个软件产品的诞生要经历的步骤：

产品说明书产品审查设计文档

进度表以前版本竞争对手的信息

测试计划用户调查易用性数据外观说明 软件体系结构软件代码 最终产品

对客户的研究结果，其实只是原始材料，并没有描述要做的产品，只是确定是否需要（不需要）以及客户要求的功能，产品说明书上综上述信息以及没有提出必须要实现的需求，真正地定义产品是什么时候，有哪些功能，外观如何，产品说明书千差万别，有些非常严格，一旦定没有特殊理由是不作更改的，而有些开发小组可以直接在餐巾纸上写出产品说明书，这样做的好处是非常灵活，但是存在的风险并非所有人站在一起，而且最终的产吕在开发前是什么时候样的无从得知，其实这种就相当于开发模型中的大爆炸模型，软件产品的一个关键部分是进度表，必须要有某种机制来跟踪进行度，从简单的Ganntt图表到使用项目软件详细跟踪每一分钟的任务，各种机制不一而足，制定进度表的目的是了解哪项工作做了，还有多少工作要做，何进全部完成。软件设计文档，对于一个稍大一些的程序需要有1个设计过程来规划软件如何编写。

24、 常见的软件设计文档的清单，

结构文档，描述软件整体设计的文档，包括软件所有的主要部分的描述以及相互之间的交流的交互方式。

数据流图：表示数据在程序中如何流动的正规示意图，有时称为泡泡图，因为它是用圆圈和线画的。

状态转换图，把软件分解为基本的状态或条件的另一种正规示意图，表示不同的状态间转换的方式。

流程图：用图形描述程序逻辑的传统方式。流程图现在不流行了，但是一旦投入使用，根据详细的流程图编写程序代码是很简单的。。

代码注释：你写1次代码，别人至少得看10次，在软件代码中嵌入注释是极极其重要的。便于维护代码的程序员轻松掌握

25、 测试文档：

测试计划（测试计划前面有细展开），测试用例，缺陷报告，测试工具和自动化测试，度量统计总结，用户手册（用户手册是测试文档的重点），联机帮助/帮助文件，指南向导，样例、示例和模块，授权/注册登记表，最终用户许可协议，广告和宣传，错误信息，图票和标志，说明文件，标签和不干胶，产品支持信息。

26、 错误提示：

错误提示是软件产品最容易忽视的部分，通常是由程序员来写，他们很少计划这些信息。

27、

软件项目/程序经理/监制人员：驱动人员：驱动整个项目，他们通常负责编写产品说明书，管理进度，进行重大的决策，体系架构师/系统工程师/产品小组

技术专家，他们经验丰富，可以胜任设计整个系统架构和软件和程序员工作密切。程序员，开发人员，代码制作设计者，设计并编码软件，修复软件中的缺陷，他们和项目经理和设计师密切合作制作软件，然后和项目经理测试密切合作，进行测试并报告发现的问题，软件测试和质量保证是存在差别的。

技术作者，用户协调专员，用户培训专员，手册编写员，文案专员，编制软件产品附带文件，配置管理员，负责把程序员的代码和技术作者写的资料组合在一起，合起来成为一个软件包。 28、 开发模型

大爆炸模型，边写边改模型，瀑布模式，螺旋模式，四种模式是常用模式，但实际软件开发中不止四种，每个模式都有自己的优缺点。作为软件测试员，可能遇到以上所有模式，你需要采用当前的模式来制定测试技术，大爆炸的优点是简单，计划，进度安排与正规的过程几乎没有，所有精力花在开发软件和编写代码的基础上。这样的情况下，因为他们直到最后才知道会拿到什么软件。 边写边改模式是项目小组未有杉其他开工模式时采用的开发模型，这是大爆炸基础上更进一步至少考虑了产品需求。作为边写边改的项目软件测试员，需要和程序员一样清醒地认识到自己将陷入无休止的循环往复。几乎每一天都有可能拿到软件版本并着手测试，边写边改是最有可能遇到的。这种模式是软件开发的入门。 瀑布模型的步骤： 构思 分析 设计 开发 测试最 终产品端

采用瀑布模型的项目从最初的构思到最终的产品都要经过一系统步骤，每上步骤结束时，项目小组组织审查，并决定是否进行下一步，如果项目未准备好的放话，就停滞下来。

瀑布模式非常强调产品的定义。注意，开发或编码阶段，只是其中单独的一块，瀑布的分布步骤是分立的，没有交叉的。优点：对于拥有精确清晰的产品定义的训练有素的开发人员而言的项目，该模式的效果较好。该模式的目标是在编写代码之前解决所有的未知，并明确所有的细节都已确定并有文档记录。而且实现在软件之中，测试小组得以制订精确的进度和计划，测试对象非常明确，在分辨功能还是缺陷上一点问题也没有。缺点：因为测试仅在最后一次进行，所以在一些根本性的问题可能出现在早期，但是直到准备发布产品才有可能性发现。螺旋模式不太理想，但该模式确实经历了很工的路来解决其他模式中存在的问题，同时有一些好的突破。 螺旋模式于1986年barry boehm在美国计算机种工发的螺旋模式加强 螺旋模式每一闪循环包括六个步骤 一， 确定目标不，可选方案，限制条件，二明确并化解风

险，三评估可选方案，当前阶段开发和测试，计划下一阶段。六确定下一阶段的方法。

螺旋中包含了一点瀑布模式（分析，设计，开发，测试的步骤）边写边改模式（螺旋模式的每一次）和大爆炸模式（从外界观察），加上该模式发现问题早，成本低特点，可以说是非常好的开发模式。

软件测试喜欢该模式，因为通过参与最初的设计阶段，可以最早的影响产品，

可以把产品的整个来胧去脉弄得很清楚，并在项目末期，不至于最后一分钟还在匆匆忆忙的测试。软件测试的工作测试仪一直在进行以最后一步只是验证表面的部分没有问题。 敏捷软件开发：敏捷软件开发一目的通过过程和工具理解个人的交流，通过全面的文档，理解运行的软件，通过合是的谈判得到客户的协作，在计划的执行中做作用变更的响应。也主浊说，在某一方面，有的时候，更应评价在另一方面的价值，。敏捷软件一发很容易偏离主题而造成混乱。一种方法是观察，了解，再决定是否采用此方法，每一个公司，每一个项目，每一个小组都会选择适合自身的情况的模式，选择有对的，也可能是错的。软件测试的工作是所处的开发环境中最大努力的工作。 29、 造成软件无法完美有四点原因？

输入量破译多，输出结果太多，软件执行路径太多，软件说明书是主观的 30、 软件测试是有风险的

如果不去测试所有的不选择了冒险。如何把数据巨大的可能的测试减少到可以控制的范围，以及如何针对风险做出明智的选择，哪些测试重要，哪些不重要，测试量和发现缺陷之间是有关系的，我们的目标是找到最优的量，使测试不多不和，软件测试工作和防疫员的工极为相似，可以报告担缺陷的存在，你可以测试，并报告缺陷的存在，任何情况下都不能保证软件缺陷没有了。唯一的方法是继续测试，可能还会找到一些。 31、 找到的缺陷越多，说明软件缺陷越多

生活中的害虫和软件缺陷一样，两者成群出现。软件测试人员会在很长时间内找不到缺陷，接着找到一个，之后很快找到第2个。可能的原因：程序员也有心情不好的时候，程序员往往会犯同样的错误，某些软件缺陷是冰山一角，软件测试人员会发现某些缺陷开始似乎毫无关联，但是最后发现它们是属于同一逐步形成主要原因造成的。

软件缺陷一个接着一个，反过来，怎么也找不到缺陷，也是有可能的，就是软件真的经过精心设计，确实是真的存在极少的缺陷，所以很难找。 32、 杀虫剂怪事

用于描述软件测试越多，其对测试免疫力越强的现象（注：确实，这个现象自己也深有体会，一些前被经过提及的缺陷在后期的开发上，程序员也会有意识地避免掉发生一些问题。所以就重复的问题会变少。）每一圈都要重复测试过程，每一次循环都要接到软件进行测试，经过几个回合，能发现的软件缺陷都妇现了，再测试下去也不会有新的发现。

克服这种杀虫剂怪事的现象（就是对测试免疫力增加）：软件测试员必须不断编写不同的测试程序，对程序的不同部分进行测试（做测试到编写测试程序对测试人员更高的要求，编写用例弱爆了） 33、 不是所有的软件都要修复，不需要修复的软件缺陷有

这些原因

（一） 没有足够的时间（二）不算真正的软件缺陷（三）修复的风险太多（四）

不值得修复

决策过程通常由软件测试人员、项目经理和程序员共同参与。站在各自的立场上看待缺陷是否应该或不应该修复都有自己的看法和观点。

但是关于错误决策的后果：只有时间才能说明这样的决策是对的，还是错的。英特尔处理器的缺陷

34、 什么时候是缺陷难以说清楚?

软件中存在问题，程序员没有发现，测试员没有发现，用户没有发现，是否算缺陷？没有答案。 从另外的角度看，两个人对于同一个软件产品的质量持有完全不同的看法和见解。一个人会说，软件缺陷很多，一个人说软件很完美。那么一定是一个人以某种方式运行时显露了大量软件缺陷，而另一个没有这样做。 尚未发现和观察到的缺陷称为潜在缺陷。

记住一句话：一棵树倒在没有人听到的森林中，它发出声音了么？

而不能不能判定的是否为缺陷的情况下我们要进行确认和验证两个过程。 35、 产品说明书从没有最终版本

假定我们的产品有一份最后定版的且不得更改的产品说明书。有了竞争对手，发布了类似的产品，继续按照产品说明书开发，发布没有竞争力的产品和重整人马，重新讨论产品功能，重写说明书，弄好经过修订的产品，明智是选择是后者。

作为软件测试人员应该要想到产品说明书可能发生改变。未曾计划测试的功能会增加。所以灵活地制订测试计划和执行测试的技术。 36、 软件测试的目标？软件质量保证人员的目标？

测试：尽可能早地找出缺陷，确保其得以修复（testing），最理想的是在软件代码编写之前。 质量保证人员：主要职责是创建和执行改进软件开发过程并防止软件缺陷发生的标准和方法。(quality assurance QA) 测试和质量保证的工作会有交叉之处

37 、软件测试是检查和批评同事工作，挑毛病，公布发现的问题，普遍不会受欢迎。保持成员和睦的建议：早点找出缺陷，控制情绪，不是总是报告坏消息。

37、 软件开发过程和软件测试两个基础的概念？

两者是有区别的，不是一个意义，不能误用和混淆。软件行业很多看似乎相同的术语很少取得一致认识。软件测试员应该常常澄清小组中使用术语的含义，最好在术语定义上取得一致而不是在“正确性”上争论 38、 精确和准确？

软件测试人员必须要知道精确和准确之间的区别。最好的结果是准确和精确的完全结合。（注：个人感觉个人准确和精确在错误提示这一块也有明显的体现） 软件测试要精度还是要准度很大程序上取决于产品是什么，最终取决于开发小组的目标。 39、 确认和验证

确认和验证两个词常常互换使用，，但是他们的定义对于软件测试的区别是很重要的。确认是保证软件符合产品说明书的过程，验证是保证软件满足用户要求的过程（注：可以间确认的参照物是产品说明书，验证的参照物是需求本身。如果不通俗，再举这样一个例子可能形象一些，如果有一个功能是拿一杯水来，那么这个过程中看水看来没有是确认的过程，而拿水这个功能背后的真正需求是口溻，那么我们要验证的是解渴了么？在我们发现了一个问题后，无法判定它是不是一个缺陷的情况下，或者定义为缺陷没有那么直观，那么我们要进行确认和验证两个过程。先看产品说明书，进行合法性的检查，如果产品书上规

定这样做是不可以的。无疑是缺陷。如果说明书上，也表示可以这样做，没有表明是不被允许的，那么就对照用户需求进行验证。看大多数用户是否接受这一点还是认为会产生迷惑）

40、 质量和可靠性？

质量的含义：“满足客户要求”

质量和可靠性也不是同一个概念。可靠性是质量的一部分. 为了保证软件质量可靠性强，软件测试员必须在整个产品开发过程中进行确认和验证。 41、 假定无法对程序进行完全的测试，那么进行决定是否

应该停止测试要考虑的问题如下： （一） 仍然发现大量软件缺陷？ （二） 项目小组对执行的测试满意么

（三） 报告的软件缺陷是否经过评估定下来哪些修复，哪些不需要修复？ （四） 产品按照客户的要求验证了么 42、 检查产品说明书

测试产品说明书（注：属于静态黑盒测试），以便在产品开始之前找出更多缺陷。在项目早期介入，并有权修改初期限的产品说明书，找出软件缺陷有可能为项目节省大笔开销和时间。 四种开发模型下，除了大爆炸模式外，每一种模式中开发小组都需要根据需求文编写产品说明书，用以定义软件是什么样的。

产品说明书是得用文字和图形描述产品的书面文档。 对于小软件也要要求编写细致的文档的要求，而不让程序员直接按自己的想法编写程序的原因是因为，这样做，我们不知道最终会得到一个什么样的产品。程员和产品外观我，功能和使用方式的见解和测试员想得完全不一样。确保最终产品符合客户要求以及正确计划测试投入的唯一方法是在产品说明书中完整的描述产品。编写详细的产品说明书的另一个好处是软件测试员可以将其作为测试项目的书面材料。它利用各种资源而获得的数据，诸如易用性研究，焦点人群，销售收入等建立的。不必了解怎样为什么要获取这些信息，以及获取这些具体的途径，只需要知道它们最终构成产品说明书。利用它进行表态黑盒测试，认真查找其中的问题。

软件测试员的任务是尽早找出缺陷，最理想的是在代码编写之前，但是如果产品说明书都没有，虽然这不太可能，但是总有一个人知道产品是什么样的。可能是开发，项目经理，销售人员，走路，谈话都可以用同样的思考/技术对他们“大脑中”的产品说明书进行测试。所以通过和设计者，编制者交流甚至可以测试没有编制出来的产品说明书(注：所以是预估缺陷某种程度上怎么不可能呢？那天听谁说来着，怎么可能预估缺陷，怎么不可能呢)

产品说明书的高层次测试：测试产品说明书要站在一个高度上进行了审查，审查产品说明书是为了找出根本性的问题、疏忽或遗漏之处，这个过程像研究的一个过程，但是研究是为了更好的了解软件做什么，就可以更好的进行细节检查。高层次测试的方法一，假设自己是客户，研究客户是什么样的人，和市场人员交流，了解最终用户的认识，是内部使用的软件项目，找到使用它的人谈一谈。质量的含义是满足客户要求，了解一下，软件是否符合那些要求。（在假设自己是用户时不能忘记安全性的问题）。

方法玩弄，研究现在有标准和规范，现在的软件和硬件都有些标准化，符合为在人类工程学的设计。但是标准和规范的差别在于程序不同，标准比规范更加严格，则标准是遵守的，规范是可选的。有一些可以标准和规范的例子，公司惯用用语和约定，行来要求，政府标准，图形用户界面。安全标准。

方法三：审查测试类似软件，测试竞争产品软件要注意的问题包括：规模，软件的功能强大还是单一，代码量的大少，这些差别和测试的相关性，软件的复杂还是简单，软件的可测试性，质量和可靠性，安全性。动手实践是无可替代的，拿到类似的软件就要尽量试它，使用它，疯狂试验，是为了仔细审查产品说明书积累大量的经验（注：所以测试产品说明的几种技术，高中低都是在编码以后，积累大量的问题可以对说明书提出更好的问题，和更好的要求，和建设性意见。）

产品说明书的低级测试（注：其实高级更多的是从思想，内容，方向性的测试，所以才说需要一定的高度。）而低级的产品说明书测试技术是进行了一些文档的检查，属性、书写的检查。

优秀的产品书具有的8个重要属性： 完整 准确

精确、不含糊，清晰 一致 贴切 合理 代码无关 可测试性

产品说明书的检查清单：

总是，每一种，所有，没有，从不。等，看到表示绝对或肯定的描述，需要考虑所有违反这些情况的用例。

当然，因此，明显，显然，必然：表示说明你接受假定的情况

某些，有时，常常，通常，惯常，经常，大多，几乎：这些话过于模糊，有时作用的功能无法测试（注：可以建议文档撰写者书写文档不要出现某些，有时，常常，通常，惯常，经常，大多，几乎字样） 等等，诸如此类，依此类推，例如。（注：以这样的字样词结束的功能清单无法测试（注：可以建议文档撰写者书写文档不要出现某些，有时，常常，通常，惯常，经常，大多，几乎字样）

良好，迅速，廉价，高效，小稳定，这些是无法量化的词语。（注：以这样的字样词结束的功能清单无法测试（注：可以建议文档撰写者书写文档不要出现良好，迅速，廉价，高效，小稳定字样） 处理，，进行，拒绝，路过，排除，这些词可能会隐藏大量的需要说明的功能。（注：以这样的字样词结束的功能清单无法测试（注：注：可以建议文档撰写者书写文档不要出现注：可以建议文档撰写者书写文档不要出现处理，，进行，拒绝，路过，排除字样） 如果，那么，（可是他没有写否则），这些不写明否则的情况可能会有大量的需要说明的功能。（注：建议文档撰写者写明，一些如果那么等假定成立条件的搭配的反之的条件。）

如果在没有产品说明书的情况下我们可以进行探索性测试，就是了解软件，设

计测试，执行测试同时进行。

43、定义软件产品 定义软件产品是一个困难的过程，产品说明书必须处理许多不可预料的情况，接受众多的变化的输入，并高潮把汇集在一个描述新产品文档中。该过程是一门模糊学科。

44、 测试用例，

选择测试用例是软件测试员最重要的任务。不正确的选择可能导致测试蛳过大或者过小，甚至测试目标不，准确评估风险，把无穷尽的可能性减少到控制的范围是成功的诀窍。 编写和管理测试用例的技术： 45、 测试软件的两种基础的方法和一些发挥性思想：

通过性测试和失效性测试。通过性测试是确认软件至少能做什么，而不会考验其能力。软件测试员不需要想办法让软件崩溃，而是用最简单的，最直观的测试用例。在设计和执行测试用例时，总是进行通过性测试，在破坏性测试之前看看软件基本功能是否能实现是很重要的。软件测试员可能会吃惊发现仅仅正常使用软件就发现这么多缺陷。 在确认软件在普通情况下正确运行之后，就可以采用各种手段来搞垮软件缺陷，纯粹为了破坏软件而设计和执行的测试用例称为失效性测试或错误强制测试。

失效性测试：重复，压迫，重负。

重复测试：不断执行同样的操作。进行这种重复的目标是检查是否存在内存泄漏。如果一难点程序在开始启动状态时工作状态良好，但是随后变得越来越慢，原因是可能发生内存泄漏。

压迫测试：软件在不够理想的条件下运行，内存小，磁盘小，cpu速度慢调制解调器速率低。看软件对外部资源的要求和依赖的程度。

重负测试，尽量提供条件让其任意发挥，让其尽可能大的数据文件，如果软件对打印机或者通信端口之类的操作，那么都把它们连上，时间也是一种重负测试。

像笨拙的用户一样操作；

在找到缺陷多的地方，再找找，找到缺陷多的地方，说明那里的软件缺陷多。

像黑客一样思考问题；凭借经验和直觉，预感。 46、 正式审查（静态白盒测试）

正式审查是发现软件缺陷的第一网。正式审查有4个要求，确定问题，遵守规则，准备，编写报告。 正式审查又分三个部分。如下： 同事审查--走查-检验

同事审查:进行了初次正式审查的最简单的方法。 走查：编写代码的程序员向5人小组或者其他程序员和测试员组成的小组做正式陈述。陈述者逐行或者逐个功能地通读代码，解释什么且如何工作。审查人员聆听叙述，提出有疑义和问题的地方。审查之后，表述者要编写报告说明发现了哪些问题。

检验：是正式审查的审查类型，具有高度组织化，要求每一个参与者都要

接受训练，检验与同事审查和走走的不同之处在于表述代码的人-----表述者或者宣读者(reader)不是原来的程序员，其他参与的称为检验员，其职责是从不同的角度，（用户，测试人员，或者产品支持人员）审查代码。可以指出不同的软件缺陷。

编码标准和范围的三个重要原因： 一、可靠性

二、可读性/维护性 三、移植性

标准有4个主要部分组成：标题，标准，解释说明，示例。 有标准，有规范，然后才有风格。

47、通用代码审查清单（静态白盒测试） 数据引用错误：使用未经正确声明和初始化的变量 数据引用错误 是否引用了未初始化的变量？ 数组和字符串的下标是整数值？下标总是在数据和字符串长度范围之内吗 检索操作或者引用数据下标时是否包含“丢掉一个”这样的潜在错误 是否在应该使用常量的地方使用常量 变量是否被赋予不同类型的值 为引用指针分配内存了吗 一个数据结构是否在多个函数或者子程序中引用。 数据声明错误 所有的变量都赋予正确的长度，类型和存储类了吗 变量是滞否在声明的同时进行了初始化，是否初始化并其类型一致 变量有相似的名称和 存在声明过，但从未引用或者只引用过一次的变量吗 所有的变量在特定模块都显式声明了吗？ 计算错误 计算机是否使用了不同数据类型的变量。 计算机是否使用了类型相同但是长度不同的变量 计算机是否了解和考虑到编译器对类型或不一致的变量的转换规则 赋值的目睥变量是否小于赋值表达式 在数值计算过程中是否可能出现溢出 除数/模是否可能为零 对于整型算术运算，处理某些计处（特别是除法）的代码是否会导致精度丢失 变量的值是不超过有意义的范围 对于包含多个操作数的表达式，求值的次序是否混乱，运算优先级对吗？ 比较错误 比较得正确吗（小于还于小于等于，大于还是大于等于这一点容易混） 存在分数或者浮点值之间的比较吗？ 每一个逻辑表达式都正确表达了吗 每一个逻辑表达式的操作数是逻辑值吗？ 控制流程错误 如果程序包含begin end do„„while等语句组，end是否明确给出并与语句对应 子程程序参数错误 输入/输出错误 其他检查 47、配置测试：

程序、模块，子程序和循环能否终止，如果不能，可以接受吗 可能存在永远不停的循环吗？ 循环是否可能永不执行？如果是这样，可以接受吗 如果程序包含像switch„„case语句这样的多个分支，索引变量超出可能的分支目的？ 是否存在“丢掉一个”错误，导致循环意外的流程 子程序接受的参数和大小与调用代码发送的匹配吗？次序正确吗？ 如果子程序有多个入口点，引用参数是否与当前的入口点没有关联 常量是否当做形参传递，在子程序中被意外改动 子程序更改了驻作为输入值的参数吗？ 每一个参数的单位是否与相应的形参匹配 如果存在全局变量，在所有引用子程序中是否有盯贩定义和属性 软件是否严格遵守外部设备读写数据的专用格式 文件或外设不存在或者未准备好的错误情况有处理吗？ 软件是否处理外部设备未连接不可用，或者读写过程中存储空间占满等情况 软件以预期方式处理预计的错误吗 检查错误提示信息的准确性，正确性，语法，拼写 软件是否使用其他外语，是否处理扩展ascii字符，是否需要用统一编码取代ascii 软件是否要移植到其他编译器和cpu，具有这样做的许可吗？如果没有计划和测试，移植性可能成为一大难题 是否考虑了兼容性，以使软件能够运行于不同数量的可用内存，洋同的内部硬件（图形，声卡），不同的外设 程序编译是否产生“警告”和“提示”信息，