软件测试的原则与步骤

原则
从用户出发:
通过测试过程充分暴露软件的bug,进而判定该产品是否合格。
从开发者出发:
通过测试证明软件达到了用户需求,确立用户对软件质量的信心。
注:
1.应当把“尽早和不断的测试”作为开发者的座右铭

2.程序员应该避免检查自己的程序,测试工作应该由独立的专业的软件测试机构来完

成。

3.设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件,特殊情况

下要制造极端状态和意外状态,比如网络异常中断、电源断电等情况。

4.一定要注意测试中的错误集中发生现象,这和程序员的编程水平和习惯有很大的关

系。

5.对测试错误结果一定要有一个确认的过程,一般有A测试出来的错误,一定要有一个B

来确认,严重的错误可以召开评审会进行讨论和分析。

6.制定严格的测试计划,并把测试时间安排的尽量宽松,不要希望在极短的时间内完成

一个高水平的测试。

7.回归测试的关联性一定要引起充分的注意,修改一个错误而引起更多的错误出现的现

象并不少见。

8.妥善保存一切测试过程文档,意义是不言而喻的,测试的重现性往往要靠测试文档。

步骤
需求分析
需求分析(Requirment Analyzing)应该说是软件测试的一个重要环节,测试开发人员对这一环节的理解程度如何将直接影响到接下来有关测试工作的开展。
可能有些人认为测试需求分析无关紧要,这种想法是很不对的。需求分析不但重要,而且至关重要。
一般而言,需求分析包括软件功能需求分析、测试环境需求分析、测试资源需求分析等。
其中最基本的是软件功能需求分析,测一款软件首先要知道软件能实现哪些功能以及是怎样实现的。比如一款Smartphone包括VoIP、Wi-Fi以及Bluetooth等功能。那我们就应该知道软件是怎样来实现这些功能的,为了实现这些功能需要哪些测试设备以及如何搭建相应测试环境等,否则测试就无从谈起!

既然谈了需求分析,那么我们根据什么来分析呢?总不能凭空设想吧。
总得说来,做测试需求分析的依据有软件需求文档、软件规格书以及开发人员的设计文档等,相信管理一些规范的公司在软件开发过程中都有这些文档。
测试计划
测试计划(Test Plan)一般由测试负责人来编写。
测试计划的依据主要是项目开发计划和测试需求分析结果而制定。测试计划一般包括以下一些方面:
1. 测试背景
a. 软件项目介绍;
b. 项目涉及人员(如软硬件项目负责人等)介绍以及相应联系方式等。
2. 测试依据
a. 软件需求文档;
b. 软件规格书;
c. 软件设计文档;
d. 其他,如参考产品等。
3. 测试资源
a. 测试设备需求;
b. 测试人员需求;
c. 测试环境需求;
d. 其他。
4. 测试策略
a. 采取测试方法;
b. 搭建哪些测试环境;
c. 采取哪些测试工具以测试管理工具;
d. 对测试人员进行培训等。
5. 测试日程
a. 测试需求分析;
b. 测试用例编写;
c. 测试实施,根据项目计划,测试分成哪些测试阶段(如单元测试、集成测试、系统测试阶段,α、β测试阶段等),每个阶段的工作重点以及投入资源等。
6. 其他。
测试计划还要包括测试计划编写的日期、作者等信息,计划越详细越好了。
计划赶不上变化,一份计划做的再好,当实际实施的时候就会发现往往很难按照原有计划开展。如在软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。所以,这些就要求测试负责人能够从宏观上来调控了。在变化面前能够做到应对自如、处乱不惊那是最好不过了。
测试设计

测试设计主要包括测试用例编写和测试场景设计两方面。
一份好的测试用例对测试有很好的指导作用,能够发现很多软件问题。关于测试用例编写,请参见前面写的《也谈测试用例》一文,里面有详细阐述。
测试场景设计主要也就是测试环境问题了。
测试环境搭建

不同软件产品对测试环境有着不同的要求。如C/S及B/S架构相关的软件产品,那么对不同操作系统,如Windows系列、unix、linux甚至苹果OS等,这些测试环境都是必须的。而对于一些嵌入式软件,如手机软件,如果我们想测试一下有关功能模块的耗电情况,手机待机时间等,那么我们可能就需要搭建相应的电流测试环境了。当然测试中对于如手机网络等环境都有所要求。
测试环境很重要,符合要求的测试环境能够帮助我们准确的测出软件问题,并且做出正确的断。
为了测试一款软件,我们可能根据不同的需求点要使用很多不同的测试环境。有些测试环境我们是可以搭建的,有些环境我们无法搭建或者搭建成本很高。不管如何,我们的目标是测试软件问题,保证软件质量。测试环境问题,还是根据具体产品以及开发者的实际情况而采取最经济的方式吧。
测试执行
测试执行过程又可以分为以下阶段:
单元测试→集成测试→系统测试→出厂测试,其中每个阶段还有回归测试等。
从测试的角度而言,测试执行包括一个量和度的问题。也就是测试范围和测试程度的问题。 比如一个版本需要测试哪些方面?每个方面要测试到什么程度?
从管理的角度而言,在有限的时间内,在人员有限甚至短缺的情况下,要考虑如何分工,如何合理地利用资源来开展测试。当然还要考虑以下问题:
1. 当测试人员测试的执行不到位、敷衍了事时该如何解决?
2. 测试效率问题,怎样提高测试效率?
3. 根据版本的不同特点是只做验证测试还是采取冒烟测试亦或是系统全面测试?
4. 当测试过程中遇到一些偶然性随机问题该怎样处理?
5. 当版本中出现很多新问题时该怎样对待?测试停止标准?

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值