软件测试流程独立于开发之外的流程。在执行测试时,与开发有交集。
牢记该流程!!!
软件开发模型可以指导软件测试过程模型。
如同软件开发过程一样,软件测试也有自己的过程模型。软件测试过程是一种抽象的模型,用于定义软件测试的流程和方法。
测试过程的质量将直接影响测试结果的准确性和有效性。软件测试过程和软件开发过程一样,都遵循软件工程原理,遵循管理学原理。
一个标准的软件测试过程中,应当包含但不仅限包含以下测试活动
需求分析、测试计划、测试设计、测试执行、测试总结…
V模型(线性的工作方式)
揭示了开发过程与测试过程中各阶段的对应关系
V模型缺点与不足
V模型仅仅把测试过程作为在需求分析、系统设计
及编码之后的一个阶段,忽视了测试对需求分析、系统设计的验证;
需求的满足情况一直到后期的验收测试才被验证;·没有体现出“尽早地和不断地进行软件测试”的原则。
牢记该V模型的图和优缺点
由两个V字型模型组成,分别代表测试与开发过程,明确表示出了测试与开发的并行关系。
优点:
测试的活动与软件开发同步进行
测试对象不仅仅是程序,包括需求和设计
尽早发现软件缺陷可降低软件开发的成本
局限性:
在W模型中,需求、设计、编码等活动被视为串行的(一条线下来的),这样就无法支持灵活的迭代。
H模型将测试活动完全独立出来,形成了一个完全独立的流程,将测试准备活动和测试执行活动清晰地体现出来。
H模型揭示了一个原理:软件测试是一个独立的流程!
H模型指出软件测试要尽早准备,尽早执行;
只要某个测试达到准备就绪点,测试执行活动就可以开展,并且不同的测试活动可按照某个次序先后进行,也可以反复进行。
X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。
X模型还定位了探索性测试,这是不进行事先计划的特殊类型的测试,这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
尽早测试
测试人员早期参与软件项目。
尽早的开展测试执行工作。
全面测试
对软件的所有产品进行全面的测试。
软件开发及测试人员(有时包括用户)全面的参与到测试工作中。
全过程测试
测试人员要充分关注开发过程。
测试人员要对测试的全过程进行全程的跟踪。
独立的、迭代的测试
测试活动是独立的。
测试活动应该是循环往复、不断的进行。
单元测试是针对软件设计的最小单元——程序模块进行正确性检验的测试工作。单元测试需要从程序的内部结构触发设计参数用例。
一般要读程序和代码。大多数时候,单元测试都是由开发人员自行完成(但是一般不认为是在做测试)。
测试人员为什么不做单元测试?
测试人员不懂代码和算法
对单一个页面测试
测试账号,密码,登录按钮。
通常在单元测试的基础上,将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系,逐步集成符合概要设计要求的程序部件或整个系统。
集成测试比较多的涉及到接口测试(接口测试工具和方法)。
集成测试是一个持续不断的过程。
测试增删改查功能是否能正常使用。
确认功能是否实现。一般都是正向的测试。
通过确认测试之后的软件,才具备进入系统测试阶段的资质。
有些时候也把确认测试称为(冒烟测试)。
确认测试不作为证实的测试环节。
全面的:所有功能的测试;模拟所有的软件用户的操作。
全方位的:和硬件系统的联系;和系统软件的联系(操作系统32位/64位);和其他软件的关系(360,腾讯管家)。
供求双方达成成果。三种验收测试的主体。
α测试:软件开发商进行的交付前的测试。
β测试:软件的需求方进行的测试。
γ测试:第三方的软件测试。
通过软件的外部表现来发现其缺陷和错误。
黑盒测试法把测试对象看成一个黑盒子完全不考虑程序内部结构和处理过程。
黑盒测试是在程序界面处进行测试,它只是检查程序是否按照需求规格说明书的规定正常实现。
读懂代码和算法,提高算法的性能。
通过对程序内部结构的分析、检测来寻找问题。
白盒测试可以把程序看成装在一个透明的盒子里,检查是否所有的结构及路径都是正确的,检查软件内部动作是否按照设计说明的规定正常进行。白盒测试又称结构测试。
介于白盒测试与黑盒测试之间的测试。
灰盒测试关注输出对于输入的正确性;同时也关注内部表现,但这种关注不像白盒测试那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态。
指不实际运行被测对象,而只是静态地检查程序代码、界面或文档中可能存在错误的过程。
代码测试:主要测试代码是否符合相应的标准和规范。
界面测试:主要测试软件的实际界面与需求中的说明是否相符。
文档测试:主要测试用户手册和需求说明是否真正符合用户的实际需求。
指实际运行被测对象,输入相应的测试数据,检查实际输出结果和预期结果是否相符的过程。所以我们判断一个测试属于动态测试还是静态测试,唯一的标准就是看是否运行程序。
黑盒测试的一方面,它检查实际软件的功能是否符合用户的需求。
逻辑功能测试。
界面测试
易用性测试
安装/卸载测试
兼容性测试(兼容硬件和操作系统)
功能的另一个指标,主要关注软件中的某一功能在指定的时间、空间条件下,是否使用正常。
软件的性能包括很多方面,主要有时间性能和空间性能两种。
验证安装在系统内的保护机制能否在实际应用中对系统进行保护,使之不被非法入侵,不受各种因素的干扰。
在新版本测试时,重复执行之前版本的所有测试用例。
目的:
1 验证之前版本产生的所有缺陷已全部被修复;
⒉确认修复这些缺陷没有引发新的缺陷
·是指在对一个新版本进行系统大规模的测试之前,先验证一下软件的基本功能是否实现,是否具备可测性。也叫可测性测试。
是指测试人员基于经验和直觉的测试,发现一些边缘性的错误。
把自己当成不懂产品的笨蛋或者小动物,随便乱点,没有任何的主观意识和想法参与进来,让一些意想不到的操作造成错误的结果。
就是功能测试:(点点点)
利用工具软件,或者编写代码的方式,测试被测试软件系统。
测试阶段用什么测试技术(黑盒,白盒)没有关系。
在单元测试阶段采用白盒测试技术,使用动态测试,注重软件的性能测试。
在集成测试阶段采用灰盒测试技术,使用动态测试,注重软件的安全测试。
在确认测试阶段采用黑盒测试技术,使用动态测试,注重软件的功能测试,采取冒烟测试。
在系统测试阶段采用黑盒测试技术,使用动态测试,注重软件的功能测试、性能测试和安全测试,采取回归测试。
在验收测试阶段采用黑盒测试技术,使用动态测试,注重软件的功能测试、性能测试和安全测试,采取随机测试和猴子测试。
所有测试的标准都是建立在用户需求之上。
软件测试必须基于“质量第一”的思想去开展各项工作,当时间和质量冲突时,时间要服从质量。事先定义好产品的质量标准,只有有了质量标准,才能根据测试的结果,对产品的质量进行分析和评估。
软件项目一启动,软件测试也就是开始,而不是等程序写完,才开始进行测试。
穷举测试是不可能的。
**第三方进行测试会更客观,更有效。**测试团队的工作独立性越高,测试越有效。
软件测试计划是做好软件测试工作的前提。
测试用例是设计出来的,不是写出来的,所以要根据测试的目的,采用相应的方法去设计测试用例,从而提高测试的效率,更多地发现错误,提高程序的可靠性。
对发现错误较多的程序段,应进行更深入的测试。一般来说,一段程序中已发现的错误数越多,其中存在的错误概率也就越大。
重视文档,妥善保存一切测试过程文档(测试计划、测试用例、测试报告等)。
应当把“尽早和不断地测试”作为测试人员的座右铭。
回归测试的关联性一定要引起充分的注意,修改一个错误而引起更多错误出现的现象并不少见测试应从“小规模”开始,逐步转向“大规模”。
不可将测试用例置之度外,排除随意性。
必须彻底检查每一个测试结果。
一定要注意测试中的错误集中发生现象,这和程序员的编程水平和习惯有很大的关系。
对测试错误结果一定要有一个确认的过程。
面试时遇到的问题
1 测试时间不够的情况下,还有大量的内容没有测试,软件能不能上线/发布/发版?
答:不能,一定要保证质量。如果上线,会给企业带来负收益。
2 有的严重的bug没有修复,但是赶着上线,能不能通融/放任?
答:坚决不能!
3 需求重要吗?错误的需求对测试有什么影响?
答:所有测试的标准都是建立在用户需求之上。
4 你觉得软件测试在什么阶段介入比较好?为什么?
答:软件项目一启动,软件测试也就是开始,而不是等程序写完,才开始进行测试。问题早发现,早解决。
5 软件发布了,但是有缺陷,是测试人员的错吗?
答:并不是,在有限的时间内,不可能将每一个每一种缺陷都进行测试和验证。测试人员能保证有更少的缺陷,但不能保证没有缺陷。
6 你写过测试计划吗?包含什么内容?测试计划可以被修改吗?
答:有写过。软件测试计划是做好软件测试工作的前提。可以的。
7 设计和编写测试用例有什么区别?
设计是一项脑力活动,编写是一项体力活动,将设计好的内容通过文字的形式表现出来。
8 针对已经发现了缺陷的模块,如何进行深入测试?
答:对发现缺陷的模块使劲测试,另外关联的模块也要进行测试。(缺陷有一种集群效应)
9 软件项目不着急的时候,测试人物完成,你会干什么?
答:反复继续测试,写测试报告和测试用例。
10 软件项目上线了/发布了,还要进行测试吗?
答:尽可能多测试,发现缺陷。
11 你觉得有什么样的缺点?
绝对不能说的:粗心,耐心不能、不善与人沟通、语言表达能力不行。
应该说:自己极端,倔,斤斤计较,穷追不舍。