一、什么是软件测试及软件测试基本原则
软件测试:
测试是对软件产品质量的检验和评价。它一方面检查软件产品质量中存在的质量问题,另一方面对产品质量进行客观的评价。
测试目的:简单地说,就是替用户受过,测试的最终目的是确保最终交给用户的产品的功能符合用户的需求,把尽可能多的问题在产品交给用户之前发现并改正。
具体地讲,测试一般要达到下列目标:
(1)确保产品完成了它所承诺或公布的功能,并且所有用户可以访问到的功能都有明确的书面说明
(2)确保产品满足性能和效率上的要求。
(3)确保产品是健壮的和适应用户环境的。健壮性即稳定性,是产品质量的基本要求,尤其对于一个用于事务关键或时间关键的工作环境中。另外就是不能假设用户的环境
二、测试的原则--Good Enough
在软件测试过程中,应注意和遵循的具体原则,可以概括为十大项:
1.所有测试的标准都是建立在用户需求之上。
2.软件测试必须基于“质量第一”的思想去开展各项工作,当时间和质量冲突时,时间要服从质量。
3.事先定义好产品的质量标准。
4.软件项目一启动,软件测试也就是开始,而不是等程序写完,才开始进行测试。
在代码完成之前,测试人员要参与需求分析、系统或程序设计的审查工作,而且要准备测试计划、测试用例、测试脚本和测试环境,测试计划可以在需求模型一完成就开始,详细的
测试用例定义可以在设计模型被确定后开始。应当把“尽早和不断地测试”作为测试人员的座右铭。
5.穷举测试是不可能的。
甚至一个大小适度的程序,其路径排列的数量也非常大,因此,在测试中不可能运行路径的每一种组合,然而,充分覆盖程序逻辑,并确保程序设计中使用的所有条件是有可能的。
6.第三方进行测试会更客观,更有效。
7.软件测试计划是做好软件测试工作的前提。
所以在进行实际测试之前,应制定良好的、切实可行的测试计划并严格执行,特别要确定测试策略和测试目标。
8.测试用例是设计出来的,不是写出来的,所以要根据测试的目的,采用相应的方法去设计测试用例,从而提高测试的效率,更多地发现错误,提高程序的可靠性。除了检查程序是否做了应该做的事,还要看程序是否做了不该做的事;不仅应选用合理的输入数据,对于非法的输入也要设计测试用例进行测试。
9.不可将测试用例置之度外,排除随意性。
特别是对于做了修改之后的程序进行重新测试时,如不严格执行测试用例,将有可能忽略由修改错误而引起的大量的新错误。所以,回归测试的关联性也应引起充分的注意,有相当一部分最终发现的错误是在早期测试结果中遗漏的。
10.对发现错误较多的程序段,应进行更深入的测试。
二、如何提高Bug的质量
1、唯一性。一个bug说明一个问题,如果有能力的话,一个bug说明一类问题,这一类问题一定要能判断出是一条代码错误引起。 2、可重现。提供这个bug的精确步骤,使开发人员容易看懂。 3、一致性。bug描述及所有信息要前后一致,不可有歧义。 4、完整性。最好能抓图,一目了然;测试环境和特定条件一定要描述清楚,许多软件功能在通常情况下没有问题,而是在某种特定条件下会存在缺陷,所以软件缺陷描述不要忽视这些看似细节但又必要的特定条件。 5、简洁性。通过使用关键词,可以使软件缺陷的标题描述短小简练,又能准确解释产生缺陷的现象。 6、跟踪性。也许随着版本的变化,或者测试的深入,对bug有了新的认识或者新的判断,及时补充相关信息,能够提供给开发更有用的信息。 7、客观性。软件缺陷描述不要带有个人观点,不要对开发人员进行评价,软件缺陷报告是针对产品的。 其实在平时测试中,经常会遇到不能重现的bug,这些问题有不能提交bug,如果放过往往上线后出现的概率很大,问题也一般比较不可接受。所以我觉得对于重现不可重现的bug是做好测试很重要的能力。 1、保留信息。遇到问题,最好抓图,搜集错误日志,保留测试现场环境,一旦发现此问题不可重现,这些数据和信息将很重要。 2、提高意识。很多人在遇到这类问题时,往往觉得后来操作不可重现了,因此就忽视了。这样往往会把此类bug遗留到产品发布后。欠的帐总要还得。 3、自我分析。对于自己分析这类问题,其实对自己的提高是最大的。分析思路:环境问题和操作顺序。 4、寻求帮助。如果研发可以帮忙,并且研发是负责任的话,只有信息全,研发分析往往是最快的途径。如果研发忙或者不乐意做,也是不可厚非的。但就要寻求组内能力强的人员或者组内讨论分析,集中大家的力量往往可以事半功倍。 在我的经历中,通过上面的方法,几乎能把所有的不可重现的问题变成可重现的并且提交bug。
三、软件测试活动完整的过程。
1. 项目经理通过和客户的交流,完成需求文档,由开发人员和测试人员共同完成需求文档的评审,评审的内容包括:需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员,测试人员以及客户的意见,完成项目计划。然后sqa进入项目,开始进行统计和跟踪
2. 开发人员根据需求文档完成需求分析文档,测试人员进行评审,评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档,测试计划包括的内容上面有描述。
3. 测试人员根据修改好的需求分析文档开始写测试用例,同时开发人员完成概要设计文档,详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。
4. 测试用例完成后,测试和开发需要进行评审。
5. 测试人员搭建环境
6. 开发人员提交第一个版本,可能存在未完成功能,需要说明。测试人员进行测试,发现bug后提交给td。
7. 开发提交第二个版本,包括bug fix以及增加了部分功能,测试人员进行测试。
8. 重复上面的工作,一般是3-4个版本后bug数量减少,达到出货的要求。
9. 如果有客户反馈的问题,需要测试人员协助重现以及回归测试。
四、优秀测试人员所应具备的素质
1、保持怀疑
对产品的质量持有一颗敢于怀疑的心,质量不是开发人员说"我做完了而且也测过了"就可以保证的。直到你测完最后一轮,最后一个用例之前,你都应该对产品的质量持怀疑态度。这个态度是混口饭吃的最基本技能。
2、永不妥协
不要对产品质量妥协,哪怕开发口口声声说这个问题不好改,改不了,一改就要延期之类的话。
3、让用户满意
产品或项目成功的标志之一是能够让用户满意,很显然用户是不会对一个bug频出的系统/产品满意的。
4、从用户角度思考
很多测试同学不知道测试用例应该怎么去写,不知道怎么写才能写得出比较健全的用例。
当你在苦恼用例从哪里来的时候,不妨试试下面两个办法
从用户角度去思考,如果你是一个特定的用户(年龄,身份,职业)你应该会怎么使用这个产品
从场景的角度去思考,在哪些场景下会使用到这个产品
写不出用例可能就意味着你对产品的功能不够熟悉,不如让熟悉这个产品的同事给你介绍一下主要功能
5、分清主次
要分清楚任务的优先级,优先级高的先做,依此类推。
在没有分清优先级的情况下不要盲目的开始测试。
6、从不承诺100%的覆盖率
不要把话说满,这个中国人都很理解。
不要保证太高的目标,给自己留点后路。
7、倾听建议
别人的建议有些是金玉良言,有些则可以忽略不计。
做测试的时候你不是一个人在战斗,多听听别的的有效建议是没有坏处的。
8、尽早开始
尽早开始重要的模块的测试工作。
因为问题发现的越早解决的成本就越低。另外早点开始测试重要的模块或功能可以尽可能多的增加测试时间,拿时间换质量一般来说是效果的。
这个建议的另一个说法就是想办法让重要的模块可以尽早的开始测试。
9、确定并管理风险
在做项目测试的时候,一个好的测试同学需要有发现项目质量上可能出现的风险的能力。
另外当发现了项目风险的时候,我们还需要能够将风险管理起来,让风险可以被控制,可以被解决。
10、做市场调研
看看友商的产品做的怎么样,有什么好的地方,有什么不好地方。
好的地方我们的产品可以学习,不好的地方我们可以预防和改进。
这是站在产品人员的角度去看待自己的项目或产品,因为好的测试在某些时候需要具备好的产品人员的素质。
11、培养BA技能
BA就是业务分析师的意思,在某些项目里,这类同学被称为产品狗。
这要求测试人员有分析需求的能力,哪些需求是真需求,哪些需求是伪需求。真需求就玩命的测,伪需求在时间允许的情况下尽量的测。
这也是产品视角,这也是为什么有很多测试同学转去做产品的原因。
12、不要忘了异常情况
只测试正常的流程往往是不太够的,一些异常的情况我们也需要进行测试。
另外不出意外的话异常情况的测试用例数量是要多于正常情况的。
测试异常情况有助于我们发现bug,也有助于我们换个角度看待产品和项目的业务行为。
13、Be a Good Judge of Your Product
那个对项目/产品最有发言权的人。
14、学会交涉
在保证项目质量的前提下我们要尽可能多的通过交涉和协商保障自己的利益。
交涉意味着在某些情况下我们需要做出让步,退一步海阔天空,但前提是,退的这一步不影响项目或产品的质量。
15、停止指责
出问题的时候第一要务是先把问题解决掉,而不是指责相关责任人。
16、最后,做一个好的观察者
观察项目,观察开发的流程,观察测试的流程,发现问题,提出问题,引导团队去解决问题。
五:功能测试与性能测试
从对软件的不同测试点可以划分为功能测试与性能测试
功能测试:检查实际的功能是否符合用户的需求。测试的大部分工作也是围绕软件的功能进行,设计软件的目的也就是满足客户对其功能的需求。如果偏离这个目的任何测试工作都是没有意义的。功能测试又可以细分为很多种:逻辑功能测试,界面测试,易用性测试,安装测试,兼容性测试等。
性能测试:是通过自动化测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。软件的性能包括很多方面,主要有时间性能和空间性能两种。时间性能主要是指软件的一个具体的响应时间。比如一个登录所需要的时间,一个交易所需要的时间等。当然,抛开具体的测试环境,来分析一次事务的响应时间是没有任何意义的。需要搭建一个具体且独立的测试环境。空间性能主要指软件运行时所消耗的系统资源,比如硬件资源,CPU、内存、网络带宽消耗等。