测试的方法及测试面试.doc

功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。3. 检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出,带出信息和添加的是否一致9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错.可编辑字段的检查和确认在所有可编辑字段中的有效、无效字符/字符串数据在字段中有效的最小/最大/中间范围的数据在必输字段中的空字符串（或没有数据）记录文本/备注字段的长度（字符数的限制）可能的情况下剪切/复制/粘贴从/到字段中不可编辑字段的检查检查所有的测试/警告和错误信息、对话框中的拼写调用/检查所有的菜单项和他们的选项应用程序的可用性一眼看上去的外观（屏幕上所有对象应该对齐）用户界面测试（打开所有的菜单，检查所有的项目）基本的功能检查（文件+打开+保存，等等）鼠标右键点击的灵敏性调整大小/最小化/最大化/恢复应用程序，窗口（检查最小化程序的大小）如果可以的话，测试滚动能力（滚动条，键盘，自动滚动）键盘和鼠标导航，突出显示，托拽，托/放用肖像方式水平打印检查F1键，“Whats This”和帮助菜单快捷键和加速键在所有对话框和菜单中Tab键的顺序和导航基本的兼容性16位操作系统（Win 3.x, Win95, OS/2, WinNT3.x）32位操作系统（Win95, Win98, Win200, WinNT4.x）UNIX1.软件测试分哪两种方法？分别适合什么情况？软件测试方法一般分为两种：白盒测试与黑盒测试。白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试，它着重于程序的内部结构及算法，通常不关心功能与性能指标；黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试，它实际上是站在最终用户的立场，检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。2.一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。计划阶段、设计阶段、白盒单元、白盒集成、黑盒单元、黑盒集成、系统测试、回归测试、验收测试一套完整的测试应该由五个阶段组成：1）。测试计划首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准。以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。2）测试设计将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响测试结果的有效性）。3）测试开发建立可重复使用的自动测试过程。4）测试执行执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理，测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。5）测试评估结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。 3.软件测试的类型有那些？分别比较这些不同的测试类型的区别与联系。BVT （Build Verification Test），主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确Scenario Tests（基于用户实际应用场景的测试），Scenario Tests优点是关注了用户的需求，缺点是有时候难以真正模仿用户真实的使用情况Smoke Test，修复Bug后，针对此次修复是否会对其他模块造成影响而进行的专门测试。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低此外，还有Application Compatibility Test（兼容性测试），主要目的是为了兼容第三方软件，确保第三方软件能正常运行，用户不受影响。Accessibility Test（软件适用性测试），是确保软件对于某些有残疾的人士也能正常的使用，但优先级比较低。其它的测试还有Functional Test（功能测试）、Security Test（安全性测试）、Stress Test（压力测试）、Performance Test（性能测试）、Regression Test（回归测试）、Setup/Upgrade Test（安装升级测试）等 4. 测试用例通常包括那些内容？着重阐述编制测试用例的具体做法不同结构的用例包括的不一样。（版本、编号、项目、设计人员、设计日期、输入、预期输出） 软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。 用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称测试阶段类型（系统测试阶段）编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” .重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。 7.描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程1、测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。 1） 经验证无误后，修改状态为VERIFIED.待整个产品发布后，修改为CLOSED. 2） 还有问题，REOPENED，状态重新变为“New，并发邮件通知。 2）项目组长根据具体情况，重新reassigned分配给bug所属的开发者。 3） 若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充说明） 4）开发者收到Email信息后，判断是否为自己的修改范围。 5） 若不是，重新reassigned分配给项目组长或应该分配的开发者。 6）测试人员查询开发者已修改的bug，进行重新测试。（可创建test case附件）操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。 7.描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程1、测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。 1） 经验证无误后，修改状态为VERIFIED.待整个产品发布后，修改为CLOSED. 2）