下载掌阅APP，畅读海量书库
立即打开
软件测试是软件质量保证的一种诉求，是质量保证过程中所依赖的主要活动之一。质量保证的结果，在很大程度上依赖于软件测试的开展以及执行的结果。所以要做好测试工作，必须清楚地了解软件的质量需求。或者说，只有正确地理解了软件质量的含义、质量需求之后，测试人员才能有效地分析测试需求，准确地定义测试的目标、把握测试的要点，才有可能将软件测试工作做得尽善尽美。
软件的质量需求，从根本上说是为了引导和满足客户的需求，而软件质量具体表现在软件产品（或服务）固有的特性之上，如适用性、功能性、有效性、可靠性和性能等。在软件质量管理中，常常将软件质量特性分为功能特性和非功能特性。软件质量不仅要满足外部客户需求，如功能、易用性、稳定性等，还要考虑企业自身的利益，如是否容易维护、是否易于扩充或迁移等，满足软件组织内部的质量需求。
1983年，ANSI/IEEE STD729给出了软件质量的定义：软件产品满足规定的和隐含的与需求能力有关的全部特征和特性，它包括：
（1）软件产品质量满足用户要求的程度；
（2）软件各种属性的组合程度；
（3）用户对软件产品的综合反映程度；
（4）软件在使用过程中满足用户要求的程度。
关于软件质量，还有如下的其他一些定义，体现了软件质量属性的不同视点。
● 客户满意度 是指使最终的软件产品能最大限度地满足客户需求的程度。
● 一致性准则 是指在生命周期的每个阶段中，其工作产品总能与上一阶段的工作产品保持一致，最终可追溯到分配需求。
● 软件质量度量 是指设立软件质量度量指标体系（例如：ISO－9126），并以此来度量软件产品的质量。
● 过程质量观 是指软件的质量就是其开发过程的质量。因此，对软件质量的量度转化成了对软件过程的度量。要定义一套良好的软件“过程”，并严格控制软件的开发照此过程进行。
一些软件质量专家对软件质量有自己的定义。
● SEI的Watts Humphrey倾向于把质量说成“在实用性、需求、可靠性和可维护性一致上，达到优秀的水准”，以及“软件系统的质量取决于开发和维护它的过程的质量”。
● James Martin声称，软件质量意味着在预算内按时发布产品，并满足用户需求。
● 软件复杂性领域内的专家Tom McCabe定义，质量是“用户满意度的高水准、低缺陷率，而且伴随着低复杂性”。
● 贝尔实验室的John Musa认为，质量是“低缺陷率、软件功能忠实于用户需求、高可靠性”的组合。
● 质量保证研究所（QAI）的Bill Perry定义，质量是用户满意度的高水准、忠实于用户需求。
软件质量的功能需求比较容易理解，就是通过人机交互界面来完成用户所需要的各项操作，包括数据的输入和结果输出。一般会在如下一些有关的产品文档中定义软件的功能特性。
● 市场需求文档（Marketing Requirement Document，MRD）。
● 产品需求文档（Production Requirement Document，PRD）。
● 用户界面模拟（模型）文档（User Interface Mock-up，UI Mock-up）。
● 产品规格说明书（Functional Specification，Spec）。
功能需求，也可被称为可说明性（accountability），用户可以基于产品或服务的描述和定义进行使用，即产品可以满足上述文档对功能的说明。
易用性（usability）可以视为非功能性需求，但更倾向于功能性需求。对于一个软件来说，易用性被视为用户学习、操作和理解软件所做出努力的程度，它和功能联系比较多。易用性好，常表现为“安装简单方便、容易使用、界面友好、逻辑清晰”等，并能适用于不同特点的用户，包括能给残疾人、有缺陷的人提供产品使用的有效途径或手段。
软件的非功能需求内涵更为丰富，虽然建议在MRD和PRD中将其描述清楚，但在多数情况下，做到这点会比较困难。它往往需要根据软件设计阶段的工作和测试验证的结果才能最终确定。
软件的非功能需求主要体现在性能、安全性、可靠性等方面。
（1） 性能 （performance）：是指在指定条件下，用软件实现某种功能所需计算机资源（包括内存大小、CPU占用时间等）的有效程度，以及系统响应、表现的状态。如果系统用完了所有可用的资源，那么系统性能就会下降。性能的操作特征包括与作业负载相关的特征，如响应时间、负载容量等。
（2） 安全性 （security）：根据ISO 8402的定义，安全性是“使伤害或损害的风险限制在可接受的水平内”，也就意味着安全性是相对的。因为从理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是：使非法侵入的代价超过被保护信息的价值，此时非法侵入者已无利可图。安全性分为如下两方面。
● 系统级别的安全性，包括网络、硬件环境和软件构成的系统整体的安全性。
● 应用程序级别的安全性，从应用软件本身来讨论其安全性，本书讨论的安全性就局限在这个范围，包括用户口令、用户功能权限设置、数据输入验证、敏感数据加密、数据存储安全性以及防范非法入侵的能力、数据备份和恢复能力等等。
（3） 可靠性 （reliability）：是指在规定的时间和条件下，软件维持其正常的功能操作、性能水平的程度，如软件坚固性和可靠性（防故障能力，即防止崩溃、内存泄漏等能力）、资源利用率、代码完整性及技术兼容性等。衡量软件可靠性的方法，包括正确执行操作所占的比例，在发现新缺陷之前系统运行的时间长度和缺陷出现的密度。通常用“系统平均无故障时间（Mean Time To Failure，MTTF）除以总的运行时间（MTTF与故障修复时间之和）”来计算可靠性，一般以多少个9来表示，如可靠性是5个9，即99.999%。可靠性对一些软件系统要求特别高，要求有很强的容错能力，并能保证长时间稳定运行，比如航空、铁路交通管制系统、全国联合售票系统等。
（1）可维护性 ：是指在一个运行软件中，当环境改变或软件发生错误时，进行相应修改所做努力的难易程度。可维护性取决于理解软件、更改软件和测试软件的难易程度，可维护性与灵活性密切相关。高可维护性对于那些经历周期性更改的产品或快速开发的产品很重要。
（2）兼容性 ：是指软件从一个计算机系统或环境移植到另一个系统或环境的难易程度，或者是一个系统和外部条件共同工作的难易程度。兼容性表现在多个方面，如系统的软件和硬件的兼容性、软件不同版本的系统、数据的兼容性。兼容性，一定程度上也决定了或包含了可移植性。
（3）可扩展性 ：是指将来功能增加、系统扩充的难易程度或能力。
（4）可移植性 ：是指软件从一个计算机系统或环境移植到另一个系统或环境的难易程度。可维护性和可扩展性，对提高可移植性有很大的帮助。
软件质量存在着对立面，即存在着不符合质量需求或违背软件用户、客户、企业意愿的问题，这就是常说的软件缺陷（Defect），常常又被叫做“Bug（臭虫）”。在现实中，软件很难做得完美无缺，总会存在这样那样的问题，不能很好地满足客户和企业的需求，这些问题也被称为软件缺陷。换句话说，任何和软件质量特性对立的问题，都可以被看做软件缺陷。而由于软件属于无形产品，软件系统具有复杂性和社会性，软件缺陷的产生，在一定程度上又是很难避免的。
通过“软件缺陷第一次被叫做臭虫”的有趣故事——Grace Hopper曾在计算机的继电器中发现一只“飞蛾”，它导致计算机死机，我们就更容易理解什么是软件缺陷，以及软件缺陷的危害了。
故事发生在1945年9月的一天，那是一个炎热的下午。机房是一间在第一次世界大战时建造的老建筑，没有空调，所有窗户都敞开着。Hopper正领着她的研究小组夜以继日地工作，研制一台称为“MARK II”的计算机，它使用了大量的继电器（电子机械装置，那时还没有使用晶体管），这是一台不是纯粹的电子计算机。突然，MARK II死机了。研究人员试了很多次还是无法启动，然后就开始用各种方法来查找问题究竟出在哪里，最后定位到板子F第70号继电器出错。Hopper观察这个出错的继电器，惊奇地发现一只飞蛾躺在中间，已经被继电器打死。她小心地用镊子将蛾子夹出来，用透明胶布粘贴到“事件记录本”中，并注明“第一个发现虫子的实例”，然后计算机又恢复了正常。从此以后，人们将计算机错误戏称为臭虫（Bug），而把找寻错误的工作称为“找臭虫”（Debug）。Grace Hopper的事件记录本，连同那个飞蛾，现在都陈列在美国历史博物馆中。
实际上，在日常使用软件的经历中，也有类似的一些体验。如当使用一个新软件时，弹出错误提示窗口；在使用浏览器时，打开了几个网页之后，结果浏览器崩溃了；访问某个网站时，速度很慢，但同时访问其他网站时，速度却还正常，这说明不是网络连接问题，而是那个网站性能有问题。所有这些，都是软件缺陷的例子。
软件缺陷表现的形式有多种，不仅仅体现在功能的失效方面，还体现在其他方面。软件缺陷的表现形式主要如下。
● 功能、特性没有实现或部分实现。
● 设计不合理，功能特性不明确，逻辑不清楚或存在矛盾。
● 产品实际结果和所期望的结果不一致。
● 没有达到产品规格说明书所规定的特性、性能指标等。
● 运行出错，包括运行中断、系统崩溃、界面混乱等。
● 数据结果不正确、精度不够、不完整或格式不统一。
● 用户不能接受的其他问题，如存取时间过长、界面不美观。
● 硬件或系统软件上存在的其他问题。
在IEEE 1983 of IEEE Standard 729中给软件缺陷下了一个标准的定义：
（1）从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；
（2）从外部看，软件缺陷是系统需要实现的某种功能的失效或违背。
软件缺陷就是软件产品中存在的问题，是计算机系统或程序中存在的任何一种破坏正常运行能力的问题或错误，或者隐藏的功能缺陷或瑕疵。缺陷会导致软件产品在某种程度上不能满足用户的需要，或者表现为用户所需要的功能没有得到实现。
不要将“软件缺陷”和“软件错误（error）”两个概念混淆起来。软件缺陷范围更广，它涵盖了软件错误，还涵盖不一致性问题、功能需求定义缺陷和产品设计缺陷等。软件错误属于软件缺陷的一种类型——程序或系统的内部缺陷，往往是软件代码本身的问题，如程序的算法错误、语法错误或数据计算不正确、数据溢出等。软件错误表现如下。
● 数组和变量初始化错误或赋值错误。
● 算法错误，是指在给定条件下没能给出正确或准确的结果。
● 语法错误，在一般情况下，对应的编程语言编译器可以发现这类问题；对于解释性语言，往往在运行时才会发现。
● 计算和精度问题，是指计算的结果没有达到所需要的精度，如小数点后的位数。
● 程序结构不合理、算法没有被优化，造成系统性能低下、系统资源浪费。
● 接口参数传递不匹配，导致模块不能成功地集成在一起。
● 文字显示内容不正确或拼写错误。
● 输出格式不对或不美观等。
但软件错误往往会导致系统的某项功能失效，或者成为系统使用的故障，即软件内部缺陷最终表现为外部缺陷。外部缺陷主要表现为软件故障或功能失效，即软件提供给用户的功能或服务，不能达到用户的要求或没有达到事先设计的指标。如在使用时突然中断，导致不能获得最终结果，或者获得的结果是不正确的。
软件缺陷的产生主要是由软件产品的特点和开发过程决定的，如软件的需求经常不够明确，而且需求变化频繁，开发人员不太了解软件需求，不清楚应该“做什么”和“不做什么”，常常做一些不合需求的事情，这时产生的问题最多。同时，软件竞争非常激烈，技术日新月异，使用新的技术，也容易产生问题。对于不少软件企业来说，“争取在时间上取胜”常常是其主要的市场竞争策略之一；实现新功能、很酷的功能，被认为比质量更为重要，这会导致日程安排很紧；需求分析、设计等投入的时间和精力远远不够，这也是产生软件错误的主要原因之一。
产生软件错误可能还有其他一些原因，例如，软件设计文档描述不清楚，文档本身存在错误，这会导致使用者产生更多的错误；还有沟通上的问题、开发人员的态度问题及项目管理问题等。《微软开发者成功之路（之一）》概括了以下7项主要原因。
● 项目期限的压力。
● 产品的复杂度。
● 沟通不良。
● 开发人员疲劳、压力过大或受到干扰。
● 缺乏足够的知识、技能和经验。
● 不了解客户的需求。
● 缺乏动力。
我们可以从软件自身特点、团队工作和项目管理等多个方面进行分析，找出导致软件缺陷更多的一些原因，这可以归纳为如下3个方面。
● 软件需求定义难以做到清清楚楚，导致设计目标偏离客户的需求，从而引起功能或产品特性上的缺陷。
● 软件系统结构非常复杂，而又无法构造成一个完美的层次结构或组件结构，结果将导致意想不到的问题。例如系统中对象、类太多，在众多的对象、类之间相互调用、引用时容易出现问题。
● 新技术的采用，可能涉及技术或系统兼容性问题，而事先没有考虑到。
● 对程序逻辑路径或数据范围的边界考虑不够周全，容易在边界条件上出错，或者超过边界条件后又缺少保护导致出错。
● 系统运行环境复杂，用户使用的计算机环境千变万化，测试环境很难完全模拟用户的各种实际环境和操作习惯，不可避免在一些特定的用户环境下系统出问题。
● 系统实际运行中的数据量要比开发、测试环境的数据量大得多，而且系统实际运行中由于各种意外可能会产生一些垃圾数据，从而引起系统负载和数据不兼容等问题。
● 对于一些实时应用系统来说，如果没有精心的设计和技术处理，容易造成时间上无法保持精确同步，使系统行为在时间上出现不协调、不一致从而出错。
● 没有考虑或处理好系统崩溃后的自我恢复、故障转移或数据的异地备份等情况，从而存在系统安全性、可靠性的隐患。
● 通信端口多、存取和加密手段矛盾等会造成系统的安全、性能等存在问题。
● 受质量文化的影响，不重视质量计划，对质量、资源、任务、成本等的平衡性把握不好，容易挤掉需求分析、评审、测试等的时间，于是遗留的缺陷也会比较多。
● 开发周期短，需求分析、设计、编程、测试等各项工作不能完全按照定义好的流程来进行，工作不够充分，结果也就不完整、不准确，错误较多；周期短，还给各类开发人员造成太大压力，从而引起一些人为的错误。
● 开发流程不够完善，存在较多的随机性和缺乏严谨的内审或评审机制，容易产生问题。
● 文档不完善、风险估计不足等。
● 沟通不够、不流畅，导致不同阶段、不同团队的开发人员对问题的理解不一致。
● 项目组成员技术水平参差不齐，或者新员工较多或培训不够等，也容易引起问题。
软件测试的目标，概括地说，就是为了更快、更早地将软件产品或软件系统中所存在的问题找出来，并促进系统分析人员、设计人员和程序员尽快地解决这些问题。软件测试是质量保证过程中不可缺少的一部分，测试人员和整个软件开发团队共同努力，确保及时地向客户或用户提供一个高质量的软件产品，包括在正确性、效率、适用性、可维护性、可扩充性、可伸缩性、安全性、可靠性、系统性能、系统容量、服务可管理性、兼容性等各方面满足事先设计或定义的要求，使软件系统最终能满足用户的需求和软件企业自身的需求。
测试人员没有发现缺陷并不能说明软件中就不存在缺陷，因为要证明没有缺陷不是一件容易的事。不管已做测试工作的量多大，缺陷仍可能就存在于那些没有被测到的地方，而这个地方可能很小。实际上，测试人员能说的就是，所发现的缺陷肯定是缺陷，随着经验的积累，测试人员肯定的信心就越强。所以说，软件测试标目标是找到至今还未发现的缺陷，而不是确保没有缺陷。为什么这样说呢？主要是有以下几个原因。
（1）测试的覆盖率几乎不可能达到100%。也就是说，软件测试不能穷举所有的测试用例，不能将程序中所有的路径都测试一遍，因为对于多数软件系统来说，由于其复杂性和规模，测试用例数或程序路径数会是一个非常大的数据。不能完成100%的测试，也就不可能将所有的缺陷发现出来，因此测试总是存在风险的。如果有充足的时间不断地进行测试，总是可以找到更多的缺陷。
（2）发现缺陷越多的地方，往往漏掉缺陷的可能性越大。缺陷多的地方，意味着这一区域的代码质量差，但并不意味着测试效率和能力得到了很大的提高，因为测试效率和能力的提高不是一朝一夕的事。缺陷越多的地方，其风险越大。
（3）修正过去的缺陷会产生新的缺陷，而且需求总是在变化着的，系统不是一成不变的，“变”是永恒的。这种“变”会带来新的缺陷、新的风险。
（4）测试人员对产品的理解不能完全代表实际用户的理解，在两者之间肯定存在差异。这种差异的存在，也就意味着会存在开发人员和测试人员没有发现的缺陷，因为他们认为这些不是缺陷，但对用户来说，这些是缺陷。
（5）软件测试的环境难以和实际运行或用户的环境完全吻合。他们存在着差异，这种差异也蕴含着风险。只在用户环境下才存在的一些缺陷，或者是在运行一段时间以后，由过多的数据或一些脏数据（特殊原因产生的无效数据）而引起的一些缺陷，不会或不容易被测试人员发现。
（6）质量不是靠测试来保证的，而是靠软件过程的各个环节保证的。任何一个缺陷都是在软件构建的过程中产生的，即在需求定义、软件设计和编程过程中会引入各种各样的缺陷，在测试活动中并没有引入任何一个缺陷，不是吗？
软件测试是质量保证的重要活动之一。 其间接目的是验证所有功能可以按照事先设计或定义的那样实现，但其直接目的并不是验证每个功能都能正常实现，而是设法找到每个功能不能正常实现的地方，即尽量去促使软件故障的产生。这就是软件测试的反向思维，它和软件开发构建系统的正向思维相呼应。这和上面所说的“软件测试的目的是找到至今还未发现的缺陷，而不是确保没有缺陷”是一致的，也和软件测试的风险观点归为静态测试的范畴是一致的，这样才可以保证测试的效率。
基于测试的反向思维，我们可以说，一个成功的测试就是测试用例没有通过——测试的实际结果没有达到所期望的正确结果。通过测试使软件系统出现故障，说明这次测试是成功的。所以在测试时，应尽量发挥自己的创造力，采用一些看似“不正当”的手法，去发现软件系统薄弱的环节或漏洞，从而迫使软件缺陷暴露出来。如果将软件测试目标定义为“验证应用程序能够正常工作”，测试人员的思路就会受到限制，测试可能会过于循规蹈矩，测试数据、配置和测试用例的设计就往往处在一些正常范围内，测试通过率会很高，测试看上去很顺利，但不容易发现软件缺陷，潜在的风险（遗漏缺陷的可能性）会很大。
当测试人员采用一些“不正当”的方法、数据或配置等进行测试时，开发人员可能会反对，于是对测试人员说，“没有人会那样做！”但作为测试人员还是要坚持这样去做，因为用户的操作或使用也完全可能会是各种各样的、有意或无意的行为。有时用户的确不会有意那么去做，但无意中会有如下的许多不规范的操作。
● 可能无意中会做一些非常规的操作，如快速地用鼠标将某个对象来回拖拽几次、对着某个按钮连击好几次等。
● 用户也会犯错误，如不小心做了删除操作、不小心碰了电源开关或给出一个错误的配置等。
● 用户的计算机资源达到或接近其上限值，如内存、磁盘空间、数据库记录等；或者同时有很多并发用户在访问系统。
● 用户的运行环境不匹配，如没有光驱、软驱，没有安装打印机，代理服务器设置的特定方式等。
即使在这样不规范的操作下，我们的程序、系统也应该经得起考验，具有应有的抗冲击、抗异常的能力。