软件测试工程师面试.docx

软件测试工程师面试.docx

《软件测试工程师面试.docx》由会员分享，可在线阅读，更多相关《软件测试工程师面试.docx（9页珍藏版）》请在冰点文库上搜索。

软件测试工程师面试

其实再这后面还有一轮面试，面试官只问了我三个问题：

1.软件测试的流程。

2.软件测试的常规方法。

3.关于黑盒和白盒测试。

当时出于抵触情绪，我都没有好好回答就离开了。

     后来胡星期一去面试了，笔试和面试的结果应该和我一样，但是他主动提出自己会as，晓得air开发。

面试官对这个技术也有兴趣，就交个他一个题目让他回去做。

经过几天的努力，那个程序写出来来了，他也获得了复试的机会。

在有些方面，我确实比不上他：

主动、自信、有实力。

我与面试官沟通的时候，只是问他们公司招什么样的职位，发现没有适合我的，就放弃了，而没有充分的展示自己的能力来勾起面试官的兴趣。

当然，这也存在一定的运气成分，但是如果自己不尝试，又何来的机会呢？

      卢老师后来又再次帮我与那边沟通，让我也去复试一下。

叮嘱我这几天熟悉下测试相关知识。

但是我一直拖到今天这个时候才开始，我真的很想做开发，做自己感兴趣的事，但怎么也不能辜负他的好意啊！

也许测试也适合我呢?

当然，我是不会放弃做开发的。

      随便上网了解了下作测试人员的基本要求：

计算机专业技能（包括测试专业技能、软件编程技能和网络、操作系统、数据库、中间件等知识）。

      发现我每个方面都懂一点点，但又不精通，也没有相关的经验。

但我想，计算机专业技能对我来说应该不难。

我相信自己会上手很快的：

）

      除了基本要求，还有就是做软件测试的素质，我发现这个要求很搞。

我打算一条条分析：

①、沟通能力--我乐于与人沟通，也善于跟人打交道。

②、移情能力--我是个感情丰富，又有同情心的人。

③、技术能力--这个差点，我对常规的测试工具都较少使用。

④、自信心-- 这个比较缺乏，我总认为自己不够好，不够专业。

⑤、外交能力--这个经验得学习，也得注意，我说话比较直。

⑥、幽默感--朋友一致认可的。

⑦、很强的记忆力--上心的事记得很牢，一般的事过了就忘。

⑧、耐心--长期耐心可能不行，但是短期耐心很强。

从自己平常调试程序可以看出。

⑨、怀疑精神--缺乏。

总相信牛人是对的。

⑩、自我督促--缺乏。

能为自己制定计划，但是长期实施有困难。

 11、洞察力-- 平常粗心大意，但是能留心到别人不注意的地方。

     通过分析，我还是能成为测试工程师吧~对于薄弱的技术环节，我想现在赶快抱一抱佛脚吧。

searching......好吧，我承认以前小看测试了，以为就是测试下程序能不能正确运行，会不会出bug就ok了。

    先来说说第一个问题，软件测试的流程是什么。

测试的流程：

需求阶段流程图：

单元/集成测试阶段流程图

系统测试阶段流程图

压力测试流程图

性能测试流程图

 仅仅了解就够复杂的了，实际操作过程中的问题肯定更多。

像压力测试、性能测试，一般的情况下我哪里用得上啊。

虽然也知道些什么分布式应用、海量存储之类的，但是我连1T的数据都没见过。

光说说那是是空话=。

=

第二个问题：

软件测试的常规方法。

不看不知道，原来比我想象中的还要多啊。

第三个问题：

黑盒测试和白盒测试

    白盒测试（White-boxtesting）是通过程序的源代码进行测试而不使用用户界面。

这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。

　　黑盒测试（Black-boxtesting）是通过使用整个软件或某种软件功能来严格地测试,而并没有通过检查程序的源代码或者很清楚地了解该软件或某种软件功能的源代码程序具体是怎样设计的。

测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。

通常测试人员在进行测试时不仅使用肯定出正确结果的输入数据，而且还会使用有挑战性的输入数据以及可能结果会出错的输入数据以便了解软件怎样处理各种类型的数据。

顺便补充一下软件工程课上，我们学到的其他测试方法介绍：

     灰箱测试或灰盒测试（Gray-boxtesting）:

灰箱测试就像黑箱测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。

甚至于还读过部分源代码。

因此测试人员可以有的放矢地进行某种确定的条件/功能的测试。

这样做的意义在于:

如果你知道产品内部的设计和对产品有透过用户界面的深入了解，你就能够更有效和深入地从用户界面来测试它的各项性能。

　　有效用例（Validcase）或者叫合法输入用例:

是那些已知软件程序能正确地处理的测试用例。

一般是指软件输入的测试用例。

比如说，在MicrosoftExcel中，用键盘输入“=1+1”,看到的结果是“2”。

这里输入的有效用例是“=1+1”。

无效用例（Invalidcase有人叫不合法输入用例）或者出错用例（errorcase）:

是那些事先就知道软件程序不支持处理的测试用例。

比如说在MicrosoftExcel中，用键盘输入“=a+1”,看到的结果是“#NAME?

”。

这里输入的“=a+1”既是无效用例同时也是出错用例。

　　边界条件（BoundaryCases）:

环绕边界值的测试。

通常意味着最大值，最小值或者所设计软件能够处理的最长的字符串等等。

比如说某软件字体的字号支持范围是:

从8到72。

那么边界测试用例应该包括:

小于8,等于8,等于72和大于72。

　　等价类（equivalentclasses）:

等价类测试用例指的是如果有很多测试用例执行再多也不会找到新的中的缺陷。

因为虽然输入和输出结果有所不同，但是它们都通过同样的软件的源代码路径。

通常只要一个源代码程序的路径是用于处理一定数值范围内的所有数值，那么除了边界值以外，在边界值范围以内的所有数值一般都属于等价类。

因为如果软件程序能正确处理一个值，也就意味着该程序能正确处理在这个范围内的除了边界值以外的其他任何有效输入值。

我们来用以上软件字体的字号来举例说明。

软件支持的字号范围是:

从8到72。

那么8和72之间的所有支持的字号都可以被认为是等价类的测试用例。

再比如:

测试超链接时两个用例和也是等价类的测试用例。