软件测试面试题集合整理.docVIP

13.测试分析测试用例注意（事项）？ 1.为什么要写用例： 我们编写测试用例，有如下的好处： 便于团队交流：假如说一个测试团队有 10 个成员，大家测试的时候都各自为政，没有统一的标准，测试的效率无疑会大打折扣；如果大家都遵循统一的用例规范去写，就会解决这一问题。 便于重复测试 ：大家知道，软件在实际开发过程中是会有不同版本的，比如会从 1.0 升级到 10.0，那么如果不写测试用例的话，在测试 10.0 版本的时候，你能完全记得 1.0 版本时你做过哪些测试吗？测试用例就像一个备忘录一样，便于重复测试。 便于跟踪统计：这一点是针对测试经理或是项目经理来说的，项目负责人通过看测试用例的执行情况，就能了解到项目目前的概况，比如已经执行了哪些测试，还有哪些测试没有执行，测试没有通过的地方主要集中在哪些模块等。 便于用户自测：尤其是项目软件，有的时候用户希望自己测试一下软件产品，但是用户大都是非专业人士，他需要根据你写好的用例来更好的检验产品的质量说了这么多编写测试用例的优点，那它有没有缺点呢？有一个明显的缺点就是需要花费大量的时间，通常编写测试用例的时间比实际执行测试的时间还要长，这一点大家会在实际工作中有深刻的体会 11.需求测试注意事项有哪些？ 一个良好的需求应当具有一下特点： 完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。 正确性：每一项需求都必须准确地陈述其要开发的功能。 一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。 无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。 健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。 必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如 Use Case 或别的来源。 可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。 可修改性：每项需求只应在 S R S 中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。 可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（f i n e - g r a i n e d ）的方式编写并单独标明，而不是大段大段的叙述。 9.软件本地化测试比功能测试都有哪些方面需要注意？ 软件本地化测试的目的： 软件本地化测试的测试策略：1.本地化软件要在各种本地化操作系统上安装并测试。2.源语言软件安装在另一台相同源语言操作系统上，作为对比测试。3.重点测试因本地化引起的软件的功能和软件界面的错误。4.测试本地化软件的翻译质量。5.手工测试和自动测试相结合。 四款主流测试工具的测试流程主流测试工具的测试流程 ========winrunner 1 启动时选择要加载的插件 2 进行一些设置（如录制模式等） 3 识别应用程序的 GUI，即创建 map(就是学习被测试软件的界面） 4 建立测试脚本（录制及编写） 5 对脚本除错及调试（保证能够运行完） 6 插入各种检查点（图片，文字，控件等） 7 在新版应用程序中执行测试脚本 8 分析结果，回报缺陷 =========quicktestpro======== 1 准备录制 打开你要对其进行测试的应用程序，并检查 QuickTest 中的各项设置是否适合当前的要求。 2 进行录制 打开 QuickTest 的录制功能，按测试用例中的描述，操作被测试应用程序。 3 编辑测试脚本 通过加入检测点、参数化测试，以及添加分支、循环等控制语句，来增强测试脚本的功能，使将来的回归测试真正能够自动化。 4 调试脚本 调试脚本，检查脚本是否存在错误。 5 在回归测试中运行测试 在对应用程序的回归测试中，通过 QuickTest 回放对应用程序的操作，检验软件正确性，实现测试的自动化进行。 6 分析结果，报告问题 查看 QuickTest 记录的运行结果，记录问题，报告测试结果。 ＝＝＝＝TestDirect============ 安装好后，先进入站点管理 1 创建域及工程 2 添加用户 3 编辑 licenses 及本服务器 4 编辑数据库 －－TD 1 选择新建的工程进行定制(列表，用户，组，版本等) 2 在 require 中增加需求 3 把需求转化为 plan 4 在 testlab 中由计划新建测试具体用例与执行 5 发现 bug，在 defect 中提交