当前位置: 首页> 多测师动态> 关于软件存在的意义和价值

关于软件存在的意义和价值

件测试的目的与其测试存在意义和价值,众云纷纷,教科书式的回答:1.尽可能发现更多缺陷2.提高开发效率,降低开发成本3.提高用户体验。软件测试最初只是验证其系统是否可正确运行,发展至今,软件测试的最终维度已经上升到了产品质量的本身,而不仅仅只局限于是否正常运行、或是否存在缺陷。关于缺陷,我们(项目组各个成员,企业上至老版,技术总监,下至新萌开发)都应该对缺陷有一个正确的认知:测试人员不可能发现系统中所有的缺陷,每个版本发布前也不可能所有已知的缺陷都会得到修复。所以——测试,是为了发现更多缺陷、预防风险。

为什么测试人员无法发现系统中所有的缺陷?

在用例设计环节中,测试人员为了尽可能实现高覆盖率的测试,测试用例设计涉及多种方法和技术,如:等价划分、正交试验、判定表、状态迁移、因果图等等,有些时候需要方法与方法之间组合进行使用,以保证更多的覆盖系统的每一行代码、每一个逻辑判断的运行,每一个可操作的功能分支都得以覆盖。听起来是没错的,似乎也应该这样。但是这样完全进行下去的结果就是“穷举测试”。

所以在庞大的工作量面前,老板们是不允许的,所以测试的最终目的,是尽可能在有限的时间内发现更多有效的,容易被用户认知的,复现几率较大的缺陷。那低级别的缺陷我们就不应该去发现么?

从原则上来说,系统的完整性、统一性是很有必要的,倘若缺陷级别较低,解决与否都不影响用户使用,且缺陷存在本身用户也不会有感知,需求文档中也没有细致到可以证明是否为缺陷时,这时候,就需要我们测试人员从用户体验角度去甄别,此是否需要定义为缺陷。所以——测试,是为了提高用户体验。关于提高开发效率,降低开发成本,这个外行人看起来很理解不了的问题,内行人其实一眼就看明白了。测试跟踪需求、验证质量;提交缺陷,也促进开发人员技术提升,这个里边牵扯到项目流程管理的问题,此处不在多言,但需明确一点:软件的质量不仅只能依靠测试人员,最终的质量如何是是整个团队的最终结果。

测试人员会告诉你他们的主要工作是发现bug。但我们知道测试永远不能发现所有的bug,而且不可能去测试软件质量。许多领域内专家也极力主张软件测试的目的主要是在于发现软件错误,希望在软件开发生命周期内尽可能早的发现尽可能多得bug。这种认识源于我们没有办法对软件进行完全测试,即对程序的正确性进行完全证明,但遗憾的是,我们至今还没有使用的技术做到这一点。包括E.W.Dijkstra指出“测试只能证明程序有错, 不能保证程序无错”。所以,人们认为能够发现程序缺陷的测试是成功的测试,测试的根本目的就是为了发现尽可能多地缺陷。然而不幸的是,这种对软件测试过分单一的阐述和解释会带来两个原则性的问题。 

首先,尽可能早的发现尽可能多的bug,会使软件测试成为一个数字游戏。大量的bug数量的统计会意味着软件测试的工作做的特好?大量的bug数量并不一定意味着测试的结果是最重要的关键问题被越早被发现, 另一个潜在的方面,简单的尽可能早的发现尽可能多的bug将导致貌似bug统计数量的爆炸,这是因为许多虚报或者重复的bug也被统计在内了。缺陷表现在许多方面。如果一个测试这部花费时间对导致bug的原因作认真的调查研究,那就有可能导致对同一个错误根源引起的若干个bug作若干个bug报告。不幸的是,许多测试人员(不一定是新手)经常坚信他们越早发现越多的bug可以改善软件质量。请记住,我们并不能测试软件质量! 

其次, 当测试工程师集中精力寻找更多的错误,他们往往跳过一些不容易发现错误的地方或者想当然认为一些地方没有错误,从而使软件测试覆盖率降低。有证据表明,许多测试人员由于太过专注于发现重大或者重要的错误,往往忽略过一些极易发现错误的所谓简单地方。比如,在测试边界条件的时候,测试人员会简单的在边界条件有效值范围内指定最小值、最大值和中间值来做测试,如果通过则认为没有问题;但这样则错过了超出边界条件的无效值的验证。比如,最小值减一(Min-1)和最大值加一(Max+1),这恰恰是最容易出现错误的地方。 

软件测试工程师的角色应体现在质量度量,质量控制和缺陷预防等方面,遵循应用系统的质量标准,有效的计量和评估系统的功能,性能和其他属性是否达到或满足质量标准;确保软件开发过程中,开发流程和处理过程以及职责定义符合软件质量标准要求;通过开发过程中各个环节的正式检查,程序代码审查以及可测性的检查等预防缺陷发生;作为客户代表,建立客户档案,准备产品支持服务数据等。 

从长远考虑,测试人员需要很强的软件测试技能和对软件工程的深刻理解,要知道测试存在于软件开发生命周期的每一个阶段。测试工作应在软件开发周期的每一个阶段都要展开。软件测试应贯穿于软件定义与开发的整个期间。因此,需求分析、概要设计、详细设计程序编码等个阶段所得到的文档,包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序,都应当成为软件测试的对象。测试的目的主要有下列用途  

应用于关键应用中的计算机和软件系统出现问题的后果是十分严重的。软件错误将引起巨大的损失。比如软件错误可以导致飞机失事,火箭失去控制,股市交易中断等。更糟糕的是,比如计算机2000年问题,产生于家庭手工作坊式的计算机工具系统差一点导致现代社会中止在21世纪来临的第一天。在嵌入式应用系统中, 软件质量和可靠性更是生死攸关。质量意味着产品符合设计的要求规范。正确性是软件质量的最低要求,正确性是指软件符合特定环境下可运行的要求。调试是软件测试中的一个重要方法,是程序员定位和修复软件错误的一个过程。发现和修复错误是程序调试的主要目的。 

软件质量是客观的,能被精确地度量和比较。质量属性包括功能性,可用性,安全性,可靠性和可测性等;而价值是主观的,价值的判断包括满意度,足够好,幸福感,喜好性,憎恶感等。软件测试的一个重要目的是验证和确认软件质量。测试作为一个度量尺度,是一个验证和确认软件质量的过程。测试人员对产品质量的评测主要基于对测试结果的解释,比如软件是否在特定条件下能够正常工作。软件质量依赖于对软件需求的正确分析和设计以及实现, 测试有助于提高软件的质量,但是提高软件的质量不能依赖于测试。测试与质量的关系很象在考试中“检查”与“成绩”的关系。学习好的学生,在考试时通过认真检查能减少因疏忽而造成的答题错误,从而“提高” 了考试成绩(取得他本来就该得的好成绩)。而学习差的学生,他原本就不会做题目,无论检查多么细心,也不能提高成绩。可见,软件的高质量是设计出来的,而不是靠测试修补出来的。所以,我们不能直接对质量进行测试,但我们可以通过测试质量相关的因素对软件质量进行度量。 

质量因素表现在三个典型方面:功能性,工程性和适应性。这三个方面的因素可视为软件质量的三维空间。Verification and Validation 

功能性(外在质量)Functionality (exterior quality) 

正确性,可靠性,可用性,完整性 

工程性(内在质量)Engineering (interior quality) 

有效性,可测性,文档化 

适应性(未来质量)Adaptability (future quality) 

可扩展性,可重用性,可维护性 

良好的测试会对所有质量相关的因素做度量。而对于软件质量维度,则其特殊因素的重要程度因应用不同而不同。对人们生活息息相关的应用系统尤其强调可靠性和完整性,而可用性和可维护性则是典型商务应用系统的两个关键因素,一个适时的科学计算程序则更强调正确性和可靠性。我们的测试,要充分发挥作用,就必须面向衡量各相关因素,使质量度量成为有形的可见的。 

以有效性和正确性验证为目的的软件测试称之为正面测试。即验证软件是工作的。这种测试缺点在于它只能验证软件在特定用例情况下能正常工作。有限次数的测试不能确认软件能在各种条件下都能正常工作,反之,如果有一个测试失败,则足以确认该软件是不能正常工作。负面测试,指按规范注入错误,旨在破坏软件的正常工作,以检验软件处理错误的能力。即验证软件是不工作的。一个好的软件,必须有足够的例外处理能力去接受破坏性测试的考验。 

好的可测的软件设计是能够容易被验证,更新和维护的设计。由于测试是一项严格的工作,需要花费大量的时间和费用, 可测性设计,也是软件开发设计规范一个重要的因素。 

软件可靠性有着重要的关系,表现在软件的许多方面,主要包括软件结构以及受制于它的大量测试。基于软件使用操作描述,可以通过对各种相关输入使用频率进行估计,作为统计抽样的方法得到软件使用可靠性量化的评估。 

软件测试远远没有成熟,它仍然是一门艺术,而不能使它成为一门成熟的学科。虽然软件测试及其技术在近些年有了飞速发展,但仍然没有本质上的改善和提高,我们仍然使用与1020年前相同的技术和方法,其中有些仍属于炮制性或启发式的方法而非良好的工程方法。软件测试的花费的代价可能很昂贵,但没有经过测试的软件在投入使用后将会带来更大更昂贵的代价付出。 解决软件测试的问题并不比解决图林的停止问题Turing halting problem更容易。我们甚至不能完全确认即使很小的软件是正确的,也不能完全确认软件规格描述是正确的。使用没有经过认证的系统来验证某一程序或系统的正确性,我们当然不能确信这一系统或程序的正确性。

 


上一篇: fiddler抓取安卓APP的https请求

下一篇: Jenkins详细教程

QQ技术交流群

多测师官方学习交流
556733550

加入群聊