设计测试用例的方法，软件测试工程师面试自我介绍？
1.很多应聘者的自我介绍就是将简历的中内容复述一遍。如果面试官已经看过你的简历，那么，复述简历的内容是完全多余的步骤。甚至说是对面试官的侮辱（他们都是可以自己阅读的人）。
2.自我介绍到底需要介绍哪些内容呢？ 我觉得应该介绍和应聘的职位相关的经验、技能和特长。比如，招聘要求包括：掌握黑盒测试用例设计方法。 那么应聘者就应该介绍在实际工作中，有关使用黑盒测试用例设计方法的经验。包括使用的具体方法和具体的测试对象等。
3.另外，自我介绍也是一个展现应聘者口头表达能力的环节。所以，在做自我介绍时，必须用面试官能够理解的语言进行介绍。如果面试官是技术人员，就应该尽量使用标准的专业术语。如果面试官是人事人员，就应该减少技术性很强的术语，改为通俗易懂的词汇。
最后，自我介绍也是展现应聘者逻辑思维能力的环节。因此，在做自我介绍时，应按照一定的逻辑顺序介绍。比如，按照测试流程的顺序进行介绍，或者按照测试种类来进行介绍。切忌逻辑混乱。
os测试是什么？
MCU测试功能中，第一个需要测试的内容就是OS测试，其原理就是，通过在芯片的 GND pad 和 IO 引脚之间加上一个正向电压（弱驱动能力），此时在 GND 于 IO PAD之间会观测到 0.5~0.6V 的电压，即表征 OS 正常。
在CP阶段，我们对芯片进行OS测试时，都是只会连接芯片的两根引脚，即GND与IO_PAD，这样测试的结果就是GND与IO_PAD的压降，必然是准确的。
叙述修改实验数据有几种方法？
等价类划分： 是把所有可能的输入数据，即程序的输入域划分成若干部分(子集)，然后从每一个子集中选取少数具有代表性的数据作为测试用例。
该方法是一种重要的，常用的黑盒测试用例设计方法。1) 划分等价类： 等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据。取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。有效等价类：是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。无效等价类：与有效等价类的定义恰巧相反。设计测试用例时，要同时考虑这两种等价类。因为，不仅要能接收合理的数据，也要能经受意外的考验。这样的测试才能确保具有更高的可靠性。2)划分等价类的方法：下面给出六条确定等价类的原则。①在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。③在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。④在规定了输入数据的一组值(假定n个)，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。3)设计测试用例：在确立了等价类后，可建立等价类表，列出所有划分出的等价类： 输入条件 有效等价类 无效等价类 …… …… 然后从划分出的等价类中按以下三个原则设计测试用例： ①为每一个等价类规定一个唯一的编号。②设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步。直到所有的有效等价类都被覆盖为止。③设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步。直到所有的无效等价类都被覆盖为止。边界值分析法 边界值分析方法是对等价类划分方法的补充。(1)边界值分析方法的考虑： 长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。(2)基于边界值分析方法选择测试用例的原则： 1)如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。2)如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据。3)根据规格说明的每个输出条件，使用前面的原则1)。4)根据规格说明的每个输出条件，应用前面的原则2)。5)如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。6)如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。7)分析规格说明，找出其它可能的边界条件。错误推测法 错误推测法： 基于经验和直觉推测程序中所有可能存在的各种错误， 从而有针对性的设计测试用例的方法。错误推测方法的基本思想： 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。例如， 在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等， 这些就是经验的总结。还有， 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。因果图方法 前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系， 相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情， 即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图(逻辑模型)。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。利用因果图生成测试用例的基本步骤： (1) 分析规格说明描述中， 那些是原因(即输入条件或输入条件的等价类)，那些是结果(即输出条件)， 并给每个原因和结果赋予一个标识符。(2) 分析规格说明描述中的语义。找出原因与结果之间， 原因与原因之间对应的关系。根据这些关系，画出因果图。(3) 由于语法或环境限制， 有些原因与原因之间，原因与结果之间的组合情况不不可能出现。为表明这些特殊情况， 在因果图上用一些记号表明约束或限制条件。(4) 把因果图转换为判定表。(5) 把判定表的每一列拿出来作为依据，设计测试用例。从因果图生成的测试用例(局部，组合关系下的)包括了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而线性地增加。除了上述几种黑盒测试的测试用例设计方法之外其他方法还包括判定表驱动分析方法、正交实验设计方法、功能图分析方法等。自动化测试是怎样的流程？
下图是自动化测试的基本流程图，以及每个阶段的任务负责人，输出等。
1、制定测试计划
在展开自动化测试之前，最好做个测试计划，明确测试对象、测试目的、测试的项目内容、测试的方法、测试的进度要求，并确保测试所需的人力、硬件、数据等资源都准备充分。制定好测试计划后，下发给用例设计者。
2、分析测试需求
用例设计者根据测试计划和需求说明书，分析测试需求，设计测试需求树，以便用例设计时能够覆盖所有的需求点。一般来讲，基于Web功能测试需要覆盖一下几个方面：
1）页面链接测试，确保各个链接正常；
2）页面控件测试，确保各个控件可靠；
3）页面功能测试，确保各项操作正常；
4）数据处理测试，确保数据显示准确、处理精确可靠；
5）模块业务逻辑测试，确保各个业务流程畅通。
3、设计测试用例
通过分析测试需求，设计出能够覆盖所有需求点的测试用例，形成专门的测试用例文档。由于不是所有的测试用例都能用自动化来执行，所以需要将能够执行自动化测试的用例汇总成自动化测试用例。必要时，要将登陆系统的用户、密码、产品、客户等参数信息独立出来形成测试数据，便于脚本开发。
4、搭建测试环境
自动化测试人员在用例设计工作开展的同时即可着手搭建测试环境。因为自动化测试的脚本编写需要录制页面控件，添加对象。测试环境的搭建，包括被测系统的部署、测试硬件的调用、测试工具的安装盒设置、网络环境的布置等。
5、编写测试脚本
根据自动化测试用例和问题的难易程度，采取适当的脚本开发方法编写测试较薄。一般先通过录制的方式获取测试所需要的页面控件，然后再用结构化语句控制脚本的执行，插入检查点和异常判定反馈语句，将公共普遍的功能独立成共享脚本，必要时对数据惊醒参数化。当然还可以用其他高级功能编辑脚本。脚本编写好了之后，需要反复执行，不断调试，知道运行正常为止。脚本的编写和命名要符合管理规范，以便统一管理和维护。
6、分析测试结果、记录测试问题
应该及时分析自动化测试结果，建议测试人员每天抽出一定时间，对自动化测试结果进行分析，以便尽早地发现缺陷。如果采用开源自动化测试工具，建议对其进行二次开发，以便与测试部门选定的缺陷管理工具紧密结合。理想情况下，自动化测试案例运行失败后，自动化测试平台就会自动上报一个缺陷。测试人员只需每天抽出一地你该时间，确认这些自动上报的缺陷，是否是真实的系统缺陷。如果是系统缺陷就提交开发人员修复，如果不是系统缺陷，就检查自动化测试脚本或者测试环境。
7、跟踪测试BUG
测试记录的BUG要记录到缺陷管理工具中去，以便定期跟踪处理。开发人员修复后，需要对此问题执行回归测试，就是重复执行一次该问题对应的较薄，执行通过则关闭，否则继续修改。如果问题的修改方案与客户达成一致，但与原来的需求有所偏离，那么在回归测试前，还需要对脚本进行必要的修改和调试。
还没有评论，来说两句吧...