软件测试中如何保证软件质量
由此看来每一个阶段的质量都起着决定性的作用。
以上提及的四个阶段的质量将引出以下几个软件质量保证的关键要素。
完备的需求分析 需求分析的目的是让项目组明白要做什么,是决定所开发出来的软件应当是“长什么样的”,显然完备的需求分析是高质量软件的前提。
如果所开发出来的软件与用户所希望的并不一致,那不可能让用户说“这个软件的质量很好” 。
如果方向不对,软件开发得再“好”也没有意义。
需求分析失误所带来的开发成本是高昂的,这一点在《软件工程》这类书籍中都会提及,因此,整个行业对于需求分析的重要性都具有足够的认识。
当然,知道其重要性与如何获得完备的需求分析又是两回事,至于如何做好需求分析请读者参考相关书籍。
需求分析如果出现失误的话有一个特点—— 它一定会暴露!只不过存在是暴露在软件开发过程中还是在用户手中之别。
因此,需求分析所造成的问题尽管严重,但它能被发现进而能得到项目组的重视,从而也一定能被修复,只是不同阶段发现这类问题所花费的成本将有所不同。
设计 设计阶段是通过设计方法找出软件实现更好的方法,注意这里是“更好”两个字,而不是强调最好。
不良设计并不会象需求分析失误那样很容易暴露出其本质,相反,它所暴露出的更多是表象,比如逻辑复杂、维护时举步为艰等等。
如果参与者不具备一定的洞察力以发现隐藏在现象背后的不良设计本质,则很有可能身受其害却不能自拔,还以为“本来就有那么复杂”。
项目的开发是一个逐步演进的过程,项目组成员对于需求的理解也是逐步加深的,一开始合适的设计到后面看来很有可能就不够全面或显得力不从心,如果仍沿用以前的设计则自然将暴露出它的不足,进而会出现需要更高的维护成本。
重构思想的提出,就是用于帮助项目演进设计的,当然,在运用重构方法时,应尽可能保证项目有足够的单元测试用例,以预防重构时又引入新的缺陷。
重构不只是一个词,其核心应当是一个方法论,一个用于优化设计的方法论。
编程好习惯 设计阶段输出的结果就是蓝图,但好的蓝图并不能保证最后的质量一定就好。
拿造房子打个比方,图纸设计得再好,如果建造时用的材料不过关,那最终的房子一定好不了。
那软件开发中的“建筑材料”又是什么呢?就是程序员所编写的代码。
如何保证其质量呢?这需要通过良好的编程习惯去保证。
在现实的项目中,设计有可能与编码会有一定的揉合,即通过进行一定的编码来辅助设计。
这种实践方式并不影响这里将设计与编码分为两个质量保证关键要素。
验证 验证很容易让人想到质量保证的常用方法之一,即测试。
但验证应当包含更多的内涵,比如求证软件需求是用户所希望的就是其中的一种。
对于验证的理解仍需要拿房屋的建造作为一个比方,以便加深理解。
在房屋的建造过程中,当建筑材料到了工地以后,需要对其进行检验,以保证它的质量是合格的,否则不能用于建造。
对应于软件开发,这个阶段就是单元测试。
当软件工程师编写了代码以后如何保证代码的行为是其所希望的呢?那只能通过单元测试去验证。
房子建造好了以后,还得对房子进行整体的验收以确保其最终是合格的。
比如抽查墙壁所使用的水泥与沙的配比是合适的。
虽然水泥和沙在进入工地时都经过了质检且是合格的,但在建造的过程中需要按一定的比例混合它们以作建筑粘合剂,而混合比例将确定粘合强度。
在软件开发过程中,软件集成测试就如同房子在建造好了以后的验收。
从上面的比方能得出几个结论。
第一,在软件开发过程中单元测试是必不可少的。
它的缺少如同将没有检验过的建筑材料用于建造一样。
第二,单元测试应当在集成测试之前完成。
有的项目在一开始时并没有单元测试流程,但后来发现需要增加这个环节,于是出现了集成测试完成了以后,再进行单元测试这种情形。
这种情形还是有点怪怪的,这如同房子已造好了,再将墙打掉去检查里面的砖是否是好的一样。
“将墙打掉检查砖”这种行为的勇气虽然可佳,但是如果尽早地在项目中部署单元测试就能避免这种怪现象的发生。
集成(包括开发集成和系统集成)测试在软件行业被广泛采用以保证软件质量,但单元测试对于软件质量保证的重要性在整个行业还缺乏广泛的、深刻的认识,其更多地被当作是负担而不是一种有效的质量保证手段。
什么样的需求算是可测试性需求?
写好一个软件的测试用例的建议有:1、测试用例名称,也叫测试用例标题,一定要写得简洁、明了,需要用概括的语言描述该用例的出发点和关注点,使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。
用例名称中一般要求不能存在假设性的语句,并且原则上每个用例的名称不能重复。
2、预置条件要明确,包括测试环境、测试数据、测试场景。
因为许多BUG只有在特定的环境、特定的场景下才可以重现。
没有正确的前提条件,就无法进行后面的测试步骤或无法得到预期的结果。
3、测试步骤描述要简单、清晰,并且要清楚每一个步骤的描述,比如:第一步,输入用户姓名;第二步,输入登录密码;第三步,用户点击登录。
步骤写的明确时就利于提高用例的可操作性。
4、用例的预期结果要完整而且清晰,并且要将各个输出的结果写出来,包括:返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则符合度、日志的检查和对其它业务影响的检查。
5、测试用例级别要划分清楚,这样在测试执行时有主次之分。
6、测试用例的划分也要单一,一个测试用例只检查功能点的一种情况。
一个用例检查的情况太多,会导致用例的目的不明确。
而且这样组织用例,有利于需求覆盖率的统计。
一个功能点我们测试了哪些情况,以及哪些功能点我们在重点测试,一目了然。
软件测试能否保证软件的正确性?如果能,为什么?如果不能,为什么...
展开全部 一旦当前阶段测试工作的范围确定下来,我们就可以开始考虑测试需求的整理——也就是明确的定义现阶段要“测什么”。
测试需求的确定将为我们制定进度时间表、分配资源以及如何确定某个阶段测试工作是否完成提供一个可供衡量的标准。
当然,还有更重要的一点,已被确定的测试需求是我们进行测试用例设计和考虑测试覆盖的依据。
整理测试需求的第一步,就是要“测试需求”。
测试需求?对,不知道您是否想到,这里的“测试需求”中的“测试”是一个动词,指的是对软件需求本身的检查。
对于软件缺陷都会有一段定义:缺陷发现的越早,则修复这个缺陷的代价就越小,在需求、设计、编码、测试、发布等不同的阶段,发现缺陷后修复的代价都会比在前一个阶段修复的代价提高10倍。
注意,笔者这里的观点并不是说可以取消团队中的“需求评审会议”,这里并不存在冲突。
笔者所希望讲述的,是测试人员应该如何看待软件需求,而并不是把“需求评审会议”所承担的责任揽到自己身上。
?在论坛上也偶尔看到有的朋友问:如何测试需求呢?每次看到这样的提问,笔者内心就禁不住的一阵激动,因为一直以来,讨论这方面问题的朋友的确少之又少。
在笔者的实际工作中,对软件需求的检查包括两个方面的内容。
一是对软件需求正确性的检查,也就是要保证需求文档中所描述的内容是真实可靠的。
在进行这部分工作时,不要迷信所谓的“都是用户提出的真实的需求”,因为我们必须考虑,提出这些需求的涉众,是否真的可以正确的描述自己的需求?我们的需求人员是否真的可以正确的理解用户的需求?有没有一些被用户认为在业务处理上是理所当然、极其平常的事情,而没有作为需求提出来?有没有一些被用户认为他们过去使用的软件已经提供了相应的功能,所以认为我们也应当提供,而没有提出来的?关于这个问题,也曾经有朋友提过不同的看法,认为这样对测试人员的要求太高了——既要熟悉需求人员的工作,又要熟悉软件所涉及的行业的业务。
但笔者还是固执的认为,作为测试人员,还是需要对软件产品所涉及的行业的业务有一个全面的、深入的了解——当然,这不是对一个刚刚入门的测试者的要求,但是如果想称为一个优秀的测试者,是难免要付出这部分努力的。
二是要保证软件需求的可测试性。
对于“可测试性”,笔者的概念是:对于一条软件需求或者一个需要实现的特性,必须存在一个可以明确预知的结果,并且可以通过设计一个可以重复的过程来对这个明确的结果进行验证。
说的具体一点,就是要保证所有的需要实现的需求都是可以用某种方法来明确的判断是否符合需求文档中的描述。
如果对于某条需求或某个特性,无法通过一个明确的方法来进行验证,或者无法预知它的结果,那么就意味着这条需求的描述存在缺陷,应该请需求人员对需求文档进行修改或补充——我们有理由相信,如果作为测试人员对需求无法产生准确的理解,那么开发人员也同样无法对同一条需求产生准确的理解。
对于一条确定的软件需求理解的二义性,是在不规范的开发过程中导致返工的一个主要原因。
如果认为有必要,那应该在“需求评审会议”上确认所有涉众对需求的理解是一致的。
当然,对于如何提高软件需求的质量,在网络上或者已经出版的书刊中都已经有了很多更加具体、实用的方法,如果有兴趣,大家也可以找来参考。
不过,如果您是一位测试者,那么上面这部分内容对您仍然是非常有用的。
相信您只要在工作中进行尝试,慢慢的体会,一定会发现这种方法给您带来的好处。
?现在当前的测试工作范围已经确定,相应版本的软件需求也通过了评审,我们就可以在这个已经确定的范围内进行测试需求的整理。
我们手头上可以参考的东西,通常会有软件需求规约(以下简称SRS)和用例(以下简称UC)——当然,也可能是一份包含UC的SRS。
通过对SRS和UC的阅读,我们可以从文档对特性和业务流程的描述中获得对软件所涉及的业务的一个基本的认识。
比如用户在处理实际业务时都要作些什么,多个业务之间的先后顺序是怎样的,用户在处理业务是对于哪些地方有特别的要求,等等。
这部分规则,将成为我们的测试需求中最基本的一部分。
至于测试需求的表现形式,笔者认为大家都可以根据自己的需要进行设计,而没有必要把思路限制在到底使用表格方式还是使用文本方式,只要把握一个原则就行了:在一条测试需求中,用容易理解的自然语言,明确的描述一项需要测试的内容。
对于多项测试内容,应尽可能的剥离开来,保证一条测试需求只包含一项测试内容。
另外,大家也可能注意到了,在软件开发过程的这个阶段,通常是没有用户界面(以下简称UI)可供参考的——虽然RUP中对于需求阶段的工作描述包括了UI设计的部分,但很多时候在这个阶段还是无法提供一个确定的UI的——也就是说我们这时获得的测试需求,将是完全基于业务的,而并不包括基于UI的那部分规则,是同软件的最终具体实现相独立的。
随着开发工作的继续,开发部门的架构设计文档和详细设计文档也将陆续提交,这时候,我们可以根据设计文档来对已有的测...
测试会计软件 主要测试什么? 尽量详细点!
展开全部 测试范围 测试范围具体包括以下测试内容:安装测试、功能测试、界面测试、性能测试、文档测试、负载压力测试、恢复测试、安全性测试、兼容性测试等。
1.安装测试。
安装测试的目的在于验证软件能否在不同的配置环境下完成安装,并确认能否正常运行。
财务软件安装测试要注意以下几点:第一,根据财务的可移植性,选择不同操作系统。
第二,选择不同层次的硬件配置和软件配置,一般选用最低、中等和最高三种配置进行测试,验证系统对软硬件环境的依懒性。
第三,观察财务软件安装程序在软硬件资源充足的情况下能否正常安装,安装过程中是否给予充足的提示,是否存在流氓软件的一些弊病,安装完成后能否正常运行,能否彻底删除。
第四,在资源不充沛的情况下,如磁盘空间不够、内存不足等,系统能否完成安装,能否给予各种提示。
2.功能测试。
功能测试是财务软件测试中的主要内容。
财务软件功能测试主要包含以下项目:个个模块中的查询、增加、删除、修改、保存等操作;数据的输入与输出;数据处理操作,如导入、结转等;基础数据中定义的精度;计算的准确性等等。
财务软件功能测试注意以下几点: 第一,测试项目的输入域要全面。
要有合法数据的输入,也要有非法数据的输入。
如,在测试基础数据的定义时,若规定是数字,则既要输入数字进行测试,也要输入字母、空格等非数字进行测试。
数字包含整数、负数、小数,还要输入一些不同的数字验证数字的精度。
第二,划分等价类,提高测试效率。
在考虑测试域全面性的基础上,要划分等价类,选择有代表意义的少数数据进行测试,提高测试效率。
第三,要适时利用边界值进行测试。
第四,重复递交相同的事务。
第五,不按照常规的顺序执行功能操作。
第六,执行正常操作,观察输出结果的异常性。
如,删除某条记录对排序的影响;执行审核后,单据的状态是否改变。
3.界面测试。
财务软件界面要符合现行标准和用户习惯。
软件企业可以形成自己的特色,但要确保整个软件风格一致。
界面测试要从友好性、易操作性、美观性、布局合理、分类科学、标题描述准确等方面入手。
主要体现在以下几个方面:第一,背景和前景的颜色是否协调,颜色反差是否用得恰当。
第二,软件得图标、按钮、对话框等外观风格是否一致,美观效果所要求的屏幕分辨率。
第三,窗口元素的布局是否合理,并保持一致。
第四,各种字段标题的信息描述是否准确。
第五,快捷键、按钮、鼠标等操作在软件中是否一致。
第六,窗口及报表的显示比例和格式是否能适应用户的预期需求。
第七,误操作引起的错误提示是否友好。
第八,活动窗口和被选中的记录是否高亮显示。
第九,是否有帮助信息,菜单导航能否正常执行。
第十,检查一些特殊域和特殊控件能否运行。
4.性能测试。
性能测试主要测试软件的运行速度和对资源的消耗。
通过调整财务软件所依赖的软硬件配置、网络拓扑结构、工作站点数、数据量和服务请求数来测试软件的移植性、运行速率、稳定性和可靠性。
一般借助自动化测试工具来辅助测试,通过极限测试来分析评估软件性能。
5.文档测试。
文档是软件的重要组成部分,也是软件质量保证和软件配置管理的重要内容。
文档测试主要通过评审的方式检查文档的完整性、准确性、一致性、可追溯性和可理解性。
财务软件作为一个大规模软件,覆盖了企业的各种业务。
它至少要具备需求定义、开发设计、测试评估、项目管理、用户应用这五类文档。
在文档测试时,要特别注意以下几点:第一,检验文档完整性,主要是文档的种类和内容的完整性。
第二,检验文档的一致性和可追溯性,主要是:软件的设计描述是否按照需求定义进行展开的;应用程序是否与设计文档的描述一致;用户文档是否客观描述应用程序的实际操作;关于同一问题的描述是否存在不同的说法。
第三,检验文档的准确性,主要是文档的描述是否准确,有无歧义,文字表达是否存在错误。
第四,检验文档的可理解性,主要审核文档是否针对特定的读者群体,表达是否详细。
如,财务软件操作手册,除了描述每个模块的操作,应该还提供关联性岗位业务、部门业务和跨部门业务的操作说明。
6.其他测试。
除了上述的测试外,还有必要对系统的其他特性和需求加以测试。
如检测软件遇突发性故障后对数据的恢复能力,软件的安全保密性和对硬件、软件、数据的兼容性,系统所能承担的最大数据量和健壮性等。
其他测试一般包含以下几种:第一,负载压力测试。
它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试。
一般采用自动化技术分别在客户端、服务器端和网络上进行测试。
要以真实的业务为依据,选择有代表性的、关键的业务操作作为测试对象。
第二,恢复测试。
通过模拟硬件故障或故意造成软件出错,检测系统对数据的破坏程度和可恢复的程度。
第三,安全性测试。
通过非法登陆、漏洞扫描、模拟攻击等方式检测系统的认证机制、加密机制、防病毒功能等安全防护策略的健壮性。
第四,兼容性测试。
通过硬件兼容性测试、软件兼容性测试和数据兼容性测试来考察软件的跨平台、可移植的特性。
...
如何提高软件测试水平
首当其冲要解决软件测试队伍的问题。
某著名国际软件企业的软件测试人员与软件开发人员的比率达到了3:5左右,并且在实践过程已经证明了这种人员结构的合理性。
但国内公司显然一时很难达到,但更重要的是重视程度,在这个基础上壮大软件测试队伍,提高测试人员的素质。
其次是要学习借鉴国外完善的测试机制,包括丰富的软件测试经验,强大的测试工具,优秀的测试管理水平。
真正解决测试手段落后、测试方法单一和测试工具欠缺的问题,在企业内部形成一个严密有效的纠错系统,使国内的测试工作流程、 技术水平接近国外先进水平,这样才能提高国内软件开发与测试的整体管理水平,增加软件产品的竞争力。
此外,要重视第三方的测试力量。
第三方的专业测试企业是靠技术与服务来赢得客户信任的,也因此更加注重测试方法与质量。
对于软件企业来说,从无到有地去建立测试部门,并完善测试体系,需要较大投入,将研发出来的软件产品交给实力强劲的第三方专业测试公司,在提高软件产品的质量问题同时,还节约了产品测试成本。
软件测试的目标和准则是什么?有哪些测试方法?测试步骤有哪些
展开全部 具体地讲,测试一般要达到下列目标: 1、确保产品完成了它所承诺或公布的功能,并且所有用户可以访问到的功能都有明确的书面说明------在某种意义上与ISO9001是同一种思想。
产品缺少明确的书面文档,是厂商一种短期行为的表现,也是一种不负责任的表现。
所谓短期行为,是指缺少明确的书面文档既不利于产品最后的顺利交付,容易与用户发生矛盾,影响厂商的声誉和将来与用户的合作关系;同时也不利于产品的后期维护,也使厂商支出超额的用户培训和技术支持费用。
从长期利益看,这是很不划算的。
领测认为接触过的软件产品,很少有向方正这样大大的产品、薄薄的文档。
当然,书面文档的编写和维护工作对于使用快速原型法(RAD)开发的项目是最为重要的、最为困难,也是最容易被忽略的。
最后,书面文档的不健全甚至不正确,也是测试工作中遇到的最大和最头痛的问题,它的直接后果是测试效率低下、测试目标不明确、测试范围不充分,从而导致最终测试的作用不能充分发挥、测试效果不理想。
2、 确保产品满足性能和效率的要求 使用起来系统运行效率低(性能低)、或用户界面不友好、用户操作不方便(效率低)的产品不能说是一个有竞争力的产品。
用户最关心的不是你的技术有多先进、功能有多强大,而是他能从这些技术、这些功能中得到多少好处。
也就是说,用户关心的是他能从中取出多少,而不是你已经放进去多少。
3、 确保产品是健壮的和适应用户环境的 健壮性即稳定性,是产品质量的基本要求,尤其对于一个用于事务关键或时间关键的工作环境中。
另外就是不能假设用户的环境(某些项目可能除外),如:报业用户许多配置是比较低的,而且是和某些第三方产品同时使用的。
测试的原则---Good Enough 对于相对复杂的产品或系统来说,zero-bug是一种理想,good-enough是我们的原则。
Good-enough原则就是一种权衡投入/产出比的原则:不充分的测试是不负责任的;过分的测试是一种资源的浪费,同样也是一种不负责任的表现。
我们的操作困难在于:如何界定什么样的测试是不充分的, 什么样的测试是过分的。
目前状况唯一可用的答案是:制定最低测试通过标准和测试内容,然后具体问题具体分析。
最明显的例子就是FIT3.0中文报版的产品测试。
测试的规律----木桶原理和80-20原则 1、木桶原理。
在软件产品生产方面就是全面质量管理(TQM)的概念。
产品质量的关键因素是分析、设计和实现,测试应该是融于其中的补充检查手段,其他管理、支持、甚至文化因素也会影响最终产品的质量。
应该说,测试是提高产品质量的必要条件,也是提高产品质量最直接、最快捷的手段,但决不是一种根本手段。
反过来说,如果将提高产品质量的砝码全部押在测试上,那将是一个恐怖而漫长的灾难。
2、 Bug的80-20原则。
一般情况下,在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug,而系统测试又能找出其余Bug中的80%,最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。
因为测试只能够保证尽可能多地发现错误,无法保证能够发现所有的错误。
软件测试的方法:1、按是否查看程序内部结构分为:(1)黑盒测试(black-box testing):只关心输入和输出的结果(2)白盒测试(white-box testing):去研究里面的源代码和程序结构2、按是否运行程序分为:(1)静态测试(static testing):是指不实际运行被测软件,而只是静态地检查程序代码、界面或文档可能存在的错误的过程。
静态测试包括:对于代码测试,主要是测试代码是否符合相应的标准和规范。
对于界面测试,主要测试软件的实际界面与需求中的说明是否相符。
对于文档测试,主要测试用户手册和需求说明是否真正符合用户的实际需求。
(5)动态测试(dynamic testing),是指实际运行被测程序,输入相应的测试数据,检查输出结果和预期结果是否相符的过程3、按阶段划分:(1)单元测试(unit testing),是指对软件中的最小可测试单元进行检查和验证。
桩模块(stud)是指模拟被测模块所调用的模块,驱动模块(driver)是指模拟被测模块的上级模块,驱动模块用来接收测试数据,启动被测模块并输出结果。
(2)集成测试(integration testing),是单元测试的下一阶段,是指将通过测试的单元模块组装成系统或子系统,再进行测试,重点测试不同模块的接口部门。
集成测试就是用来检查各个单元模块结合到一起能否协同配合,正常运行。
(3)系统测试(system testing),指的是将整个软件系统看做一个整体进行测试,包括对功能、性能,以及软件所运行的软硬件环境进行测试。
系统测试的主要依据是《系统需求规格说明书》文档。
(4)验收测试(acceptance testing),指的是在系统测试的后期,以用户测试为主,或有测试人员等质量保障人员共同参与的测试,它也是软件正式交给用户使用的最后一道工序。
验收测试又分为a测试和beta测试,其中a测试指的是由用户、 测试人员、开发人员等共同参与的内部测试,而beta测试指的是内测后的公测,即完全交给最终用户测试。
4、黑盒测试分为功能测试和性...
如何成为一名优秀的软件质量保证工程师
具有软件开发,测试实施经验 软件质量保证牵扯到软件开发的方方面面,包括从启动到需求,到设计,到开发,到测试,到发布,到后期维护的整个过程。
在启动阶段,你要理解如何制定项目章程,如何书写项目范围说明书,如何制定项目计划;在需求阶段,你需要理解如何与用户确认需求,如何进行需求分析,如何与用户确认用户需求;在设计方面你要大体理解当前设计前沿技术,了解数据库知识,如何进行概要设计和详细设计;在构造阶段,您需要了解编码规范,编程技巧,集成技术;在测试阶段你需要理解如何进行单元测试,集成测试,系统测试;在验收阶段您需要理解如何进行验收测试,如何培训用户,如何替用户搭建环境;在维护阶段您需要理解如何理解代码,如何进行再工程技术。
在这里你好像是一位多面手,但是了解得越多,对你从事质量保证工作越有好处。
由于现代分工比较细致,往往一个质量小组需要各个方面的人才组合在一起,才能发挥更大的效能,才能达到1+1>2的结果。
具有一定的数学基础 对于从事软件质量保证工作,您需要一定的数学知识,尤其是概率统计知识。
无论你是否采用6Sigma,你需要对你的软件质量进行度量活动,需要收集数据,分析数据从而解决问题。
你要理解如何使用直方图,散点图,鱼刺图,饼图等工具。
这样你才能展示问题的原因,寻找解决问题的原因。
强大的沟通能力 对于从事软件质量保证工作,沟通能力非常重要。
质量工作做得好坏,关键在于领导的支持和员工的参与。
由于目前中国软件的实际工作,公司领导往往忽视软件质量的重要性和优先性,你就需要与领导讲清楚质量管理的优势,如何可以提高公司产品的质量,减少客户的投诉率从而节约公司的成本,提高劳动生产率。
有了领导强有力的支持,你的工作就好像添加了一把利剑,可以运行得得心应手。
但是仅仅有领导的支持时往往不够的,还需要员工的支持,你需要了解当前问题有什么,阻碍这些问题的要数是是什么,大家需要解决什么样的问题…这些都需要靠你的沟通技巧来解决。
专业的管理和质量知识 专业的技术是你软件质量工作成功的有用的武器。
复制链接收藏
转载请注明出处51数据库 » 如何保证软件 可测试性