软通动力软件测试面试题.doc

软通动力软件测试面试题1.白箱测试和黑箱测试是什么?什么是回归测试?回归测试是指软件系统被修改或补充后重新进行的测试，是为了保证对软件所做的修改没有引入新的错误而重新进行的测试。2.单元测试、集成测试、系统测试的侧重点是什么？单元测试的重点是系统的模块，包括子程序的正确性验证等。集成测试的重点是模块间的衔接以及参数的传递等。系统测试的重点是整个系统的运行以及与其他软件的兼容性。 3.设计用例的方法、依据有那些？在测试的不同阶段运用不用的测试方法设计用例的方法依据不同:白盒测试用例设计有如下方法:基本路径测试等价类划分边界值分析覆盖测试循环测试数据流测试程序插桩测试变异测试.这时候依据就是详细设计说明书及其代码结构黑盒测试用例设计方法:基于用户需求的测试功能图分析方法等价类划分方法边界值分析方法错误推测方法因果图方法判定表驱动分析方法正交实验设计方法.依据是用户需求规格说明书,详细设计说明书不同阶段测试用例的设计主要是根据情况选取以上两种测试方法中的一些.4.一个测试工程师应具备那些素质和技能？技能计算机专业技能测试专业技能软件编程技能素质（1）沟通能力 测试人员需要与很多人员进行沟通，项目经理、开发人员、客户、市场人员等都是测试人员经常吵架的对象，而且在面对不同人员，你需要不同的语气、不同的态度，与客户要谈得来，处处为客户着想，客户就是上帝，与上帝说话要和颜悦色，与开发人员交往就需要技巧了，测试人员与开发人员往往是不共戴天的，双方在心理上经常较劲，因此在说话的语气或讲述一个问题的出发点时特别要注意了。（2）要有严谨、敢于承担责任、稳重的做事风格 其实学数学的人最适合做测试作，他们思惟严密，什么问题都被他们考虑到，当然除了做事认真仔细，也要有承担责任的勇气，在漫长的项目实施过程中，或大或小的错误在所难免，我们可以原谅错误，但不喜欢狡辩，要敢于承认错误。（3）具有怀疑与破坏的精神 测试人员不能总是以常规的思路来测试软件，要设计一些非常规的、相反的测试用例来不断地折磨软件产品，要破坏性地测试，并且不要停止你的怀疑。（4）善于自我总结、自我督促 应该说软件测试是一种即繁琐又枯燥无味的工作，做多了你会觉得似乎一成不变，对自已的能力没有提高，这时候就需要你作自我督促，并经常作一些阶段性的总结，新的技术新的方法新的工具层出不穷，要让自已跟上技术发展的脚步，善于将新技术新方法新工具应用到测试工作当中。暂时想到这么多了，其实也已经够多了，其中有些东东可能对做任何事都适合，笔者经验有限，有想不到的地方，希望朋友们多多指教，最后用培根老人家的话来收个尾：注意你的思想，它会变成你的行动；注意你的行动，它会变成你的习惯；注意你的习惯，它会变成你的性格，而性格将决定你的命运。5.集成测试通常都有那些策略？非增量式集成:这种方法容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。 增量式集成：比较有顺序1. 增量式测试方法的两种方式。增量式集成：自顶向下:它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。优点：宏观控制性比较强。自底向上:自底向上测试是从原子模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。 自顶向下：广度优先、深度优先自顶向下1 以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；2 依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块；3 每集成一个模块立即测试一遍；4 只有每组测试完成后，才着手替换下一个桩模块；5 为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。自底向上1 把低层模块组织成实现某个子功能的模块群（cluster）;2 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；3 对每个模块群进行测试；4 删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。从第一步开始循环执行上述各步骤，直至整个程序构造完毕。6.你用过的测试工具的主要功能、性能及其他？7.一个缺陷测试报告的组成l 引言部分1) 编写目的2) 项目背景3) 系统简介4) 术语和缩写词5) 参考资料l 测试使用的国家标准、行业指标、公司规范和质量手册等等。1) 测试用例设计2) 测试环境与配置3) 测试方法(和工具)l 测试结果及缺陷分析1) 测试执行情况与记录2) 覆盖分析3) 缺陷的统计与分析l 测试结论与建议8.基于WEB信息管理系统测试时应考虑的因素有哪些？9.软件本地化测试比功能测试都有哪些方面需要注意？软件国际化测试的对象是采用国际化方法进行设计的软件，例如英文的Word 2003。测试的环境是各种不同语言的操作系统，例如简体中文、繁体中文、德语、日语等的Windows 操作系统。国际化测试的内容包括产品的安装和卸载，是否支持不同区域设置的数据格式（日期、时间、度量衡、地址、电话号码、纸张格式），是否支持不同字符集的编码和输入、编辑、显示和保存。软件本地化的对象是经过本地化后的软件，例如，简体中文的Word 2003。对于简体中文的Word 2003的本地化测试的环境是简体中文的Windows，对于德语Word 2003而言测试环境是德语的Windows。软件本地化测试的内容包括：软件的本地化内容是否准确，软件经过本地化后功能是否失效，软件控件（例如按钮的大小和按钮上的文字）的大小和位置是否适当。10.软件测试项目从什么时候开始，？为什么？软件测试项目从什么时候开始，？为什么？软件测试应该在需求分析阶段就介入,发现越早损失越少因为测试的对象不仅仅是程序编码,应该对软件开发过程中产生的所有产品都测试,并且软件缺陷存在放大趋势.缺陷发现的越晚,修复它所花费的成本就越大.产品发布后修复软件却小比项目开发早期发现修改费用高出10-100倍11.需求测试注意事项有哪些？一个良好的需求应当具有一下特点：完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。 正确性：每一项需求都必须准确地陈述其要开发的功能。一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。可修改性：每项需求只应在系统需求分析中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（f i n e - g r a i n e d ）的方式编写并单独标明，而不是大段大段的叙述。13.测试分析测试用例注意（事项）？1.为什么要写用例：我们编写测试用例，有如下的好处：便于团队交流：假如说一个测试团队有10个成员，大家测试的时候都各自为政，没有统一的标准，测试的效率无疑会大打折扣；如果大家都遵循统一的用例规范去写，就会解决这一问题。便于重复测试 ：大家知道，软件在实际开发过程中是会有不同版本的，比如会从1.0升级到10.0，那么如果不写测试用例的话，在测试10.0版本的时候，你能完全记得1.0版本时你做过哪些测试吗？测试用例就像一个备忘录一样，便于重复测试。便于跟踪统计：这一点是针对测试经理或是项目经理来说的，项目负责人通过看测试用例的执行情况，就能了解到项目目前的概况，比如已经执行了哪些测试，还有哪些测试没有执行，测试没有通过的地方主要集中在哪些模块等。便于用户自测：尤其是项目软件，有的时候用户希望自己测试一下软件产品，但是用户大都是非专业人士，他需要根据你写好的用例来更好的检验产品的质量说了这么多编写测试用例的优点，那它有没有缺点呢？有一个明显的缺点就是需要花费大量的时间，通常编写测试用例的时间比实际执行测试的时间还要长，这一点大家会在实际工作中有深刻的体会2.什么时候写用例：什么时候写用例？这个问题没有统一的标准答案，但有一点可以肯定，就是测试用例要尽早编写。 大家认为在哪个阶段开始写用例比较好呢？通常，我们都会在测试设计阶段来写用例，即需求规格说明书和测试计划都已完成之后3.由谁来写测试用例有的读者会说，当然是测试人员来写用例了！可是测试人员又会有不同的角色，一般分为测试经理，测试设计人员，测试执行人员和测试工具开发人员等，一般测试用例是由测试设计人员来编写，由测试执行人员来执行，这就要求测试设计人员有一定的用例设计经验，并对被测试的系统有深入的了解。但是在很多小公司里面，区分的不是这么明显，一个测试人员往往会身兼数职，既是测试组长，又是测试设计人员，又是测试执行人员。项目组里就你一个测试工程师，你不写用例谁写啊！4.根据什么写测试用例我们编写测试用例的唯一标准就