在完成了程序的编写工作后,接下来将进行软件的测试,这里说的软件,并不单单是指程序本身,还包括其他方面.测试和开发一样,也是一项技术性很强的工作,有着很多的技巧. 软件测试是软件质量保证的主要活动之一,因此,测试的质量直接影响软件的质量.
软件测试就是在软件投入运行前,对软件的需求分析,设计规格说明和编码的最终复审,是保证软件质量的关键步骤.如果要给软件测试下定义,可以这样将,软件测试是为了发现错误而执行程序的过程.
测试的目的在于将软件设计时设计者与程序开发者之间理解不一致的地方,功能与需求不一致的地方,不符合逻辑思文的情况都反映给质量控制部门,由质量控制部门调配需求部门统一作出一个明确解答,再由开发人员进行修改和补充.
测试的目标是以最少的时间和人力找出软件中潜在的各种错误和缺陷.
对于相对复杂的产品或系统来说,Zero-Bug是一种理想,Good-Enough是我们的原则.Good-Enough原则就是一种权衡投入/产出比的原则;不充分的测试是不负责任的;过分的测试是一种资源的浪费,同样也是一种不负责任的表现.我们操作的困难在于,如何界定什么样的测试是不充分的,什么样的测试是过分的.目前状况唯一可用的答案是:制定最低通过标准和测试内容,然后具体问题具体分析.
依据前面所说的测试对象,我们把测试划分为几个方面来进行测试.
界面测试是测试过程中比较简单直观的一种测试方法,只要细心地按界面要求核对就行了.可这快往往是程序开发人员容易忽视和遗漏的地方,也是常常出Bug的地方.下面是界面测试中经常出现的几种Bug:
① 错别字,即界面中的标题或者文本内容中出现了错别字.这种Bug如果测试人员不细心,和难找出来,可能会出现在提示信息或界面中.
② 出现了一些根本读不懂的内容,一般多出现在程序的提示信息和一些较长的文本中.这种情况基本上出现在拼起来显示的提示中,页面的简单陈述是通过变量拼组起来的,通过程序将字一个一个地输出出来.通常是因为程序中的控制错误或是程序开发人员对程序没有进行认真的自测,导致出现这种Bug.
③ 程序员自创的词语,,虽然意思对,但不符合界面的标准及需求.这种情况基本上是由于开发人员使用一些专业术语,并且混杂着自己的理解出现Bug,主要是由于开发过程中团队合作没又明确的分工,没有统一的规范用语.
④ 页面类似的内容中,明显有字体,字号不同的情况,使界面整体风格看上去不一致,这种情况只出现在没有CSS定义的情况下,或是已经定义的CSS,开发人员在开发过程中没有调用.
⑤ 标题相近的程序及模块,把标题弄混.这种情况多是因为业务方面的定义名称很相似或很类似,并且业务实体方面也很类似,开发人员在开发过程中忽略了开发名称和模块,只单独地实现其功能.
顾名思义,功能测试主要是测试程序模块是否实现了设计中所有要求的功能.功能测试中需要注意的有:
① 查询功能中,有按单一查询条件进行查询的,也有按多个查询条件组合查询的,这里要注意多个查询条件之间的关系,还有一些常识性的问题,比如按月查询,闰年中二月的天数.
② 录入功能中,需要注意的是前台设置的数值长度是否大于后台数值长度,以及前台与后台的数据结构是否相符,很多时候录入功能无法实现是由于这些原因.还有就是必须录入的字段的设置是否有误.
③ 测试删除功能中需要注意的是单击”删除”按钮后,一般会出现提示信息,询问是否确定删除.通常情况下,我们单击”确认”按钮查看信息是否被删除掉了,而忽略了单击”取消”按钮后程序的反应,这时有可能的是没有删除,还有一种可能是即便单击了”取消”按钮,也一样删除了数据.另外,在删除多条记录的时候,要注意连续选中的几条记录是否真正都被删除了,即如果再按照这种查询方式查询,是否还能查询出来.有的时候需要在数据库中设一个标志位,而不是真正的物理删除.所以在下一次查询中,可能还会被查询出来,这主要是因为在查询条件中没有将标志位考虑在内.
④ 关于修改功能的测试,主要是看修改确认后是否数据真正已被修改了.这是最基本的功能,需要注意的是看是否能把不应该修改的数据也修改成功了.
针对需求测试,是测试中很重要的一个环节.因为需求是在软件设计,开发乃至软件测试中重要的依据.要针对需求测试,首先就要对项目的需求和业务有一定的了解.这些需求很多时候是在实现增,删,查,改这些基本功能之上,针对项目和相关业务所作的一些逻辑上的控制.这就要求程序员在设计和编码的时候要去充分理解考虑需求.
性能测试在软件的质量保证中起着重要的作用..通常我们把性能指标全部归结到硬件,操作系统和开发环境上,而忽略了代码本身性能上的考虑.性能需求指标中,稳定性,并访支撑能力以及安全性都很重要,作为程序员需要评估该模块在系统运营中所处的环境,将要受到的负荷压力以及各种潜在的危险和恶意攻击的可能性.
· 时常有这样的情况发生,每个模块都能单独工作,但这些模块集成在一起之后却不能正常工作.其主要原因是,模块相互调用时接口会引入许多新问题.这就要求在进行程序设计和编码的时候要尽可能地从整体考虑.
· 引用某些控件,实现了程序中未实现的功能的同时,也容易引发新的Bug.
· 错误本身出现在程序设计阶段,并非由于程序员编码造成的问题.这就要求我们无论是在开发还是测试阶段,对需求或程序设计存在疑问,应及时提出,及时解决.
· 由于一些模块被修改了,对其他模块造成了影响而出现了新的Bug.发现这些Bug要求我们对程序整体的结构有基本的了解,清楚模块之间的一些联系.
在完成编码的工作以后,根据以上的方法和步骤进行了如下的测试:
· 界面测试:在不开启Web服务器的情况下,反复点击网页上的超链接,测试其连接情况,直到所有的链接都达到预期的效果.
· 功能测试:对网站的几大功能模块逐一测试,尽最大可能发现起潜在的错误,比如邮箱的格式,电话号码是否全为数字.
· 性能测试:将程序以局域网的形式发布,查看其是否满足多用户的要求.
· 需求测试:根据需求分析的内容,测试网站是否和当初的设计一样.
通过这几方面的测试，我及时修正了系统中存在的问题，很好的提高了系统的性能，达到了预期目标。
<< 上一页 [11] [12] [13] [14] 下一页