1、用例
在UML的文档中，Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。其实UseCase就是对系统功能的描述而已，不过一个UseCase描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。在使用UML的开发过程中，需求是用UseCase来表达的，界面是在Use Case的辅助下设计的，很多类是根据Use Case来发现的，测试实例是根据UseCase来生成的，包括整个开发的管理和任务分配，也是依据Use Case来组织的。
2、什么是软件测试？测试和调试有何区别？
软件测试，在规定条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
测试只是运行并发现软件的错误，调试则是不仅要发现错误，还要修改错误的过程！‘
3、什么是黑盒测试？黑盒测试主要采用的技术有哪些？
黑盒测试是在不知道内部程序的情况下进行的测试，是针对软件的功能进行测试。有：等价类划分法、因果图法、边界值法、正交表法、错误检测法等。
4、某软件的登录功能描述，选择用户名。输入密码，单击登录。如果密码正确。显示主界面。如果密码错误，提示密码错误。如果连续三次登录失败，提示用户并退出登录界面，在登录界面可以单击“取消”退出登录界面。
请根据以上的功能描述，写出需要测试的点。
1.测试用户名与密码不对应能否登录
2.测试输入错误密码并单击登录后是否弹出错误提示
3.测试三次输入错误密码后能否正确弹出提示并退出
4.测试在登录界面单击“取消”是否能推出登录界面。
5.测试在未达到三次错误输入的情况下单击取消登录按钮再进入登录界面能否正确计算密码输入次数
6.测试输入正确密码时单击登录是否可以正常登录
5、概念解释：黑盒测试和白盒测试
黑盒测试：见2
白盒测试：又称逻辑驱动测试,结构测试,它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序。
代码检查法、静态结构分析法、逻辑覆盖法、基本路径测试法。
6、列出你所知道的一个或者多个自动化测试框架，并简要介绍他们的特点？
1. 数据驱动测试框架
优点：测试数据可以单独维护
缺点：任何被测试程序的变更所导致的工作量是所有架构中最多的，因此维护成本非常高
2.测试脚本模块化框架
优点：控件和业务逻辑一旦发生变化，要进行修改和维护的是底层的测试脚本（比无任何抽象封装的自动化测试程序稍好一些）
缺点： 几乎所有大的变更引起的工作量都由自动化测试开发工程师完成，
控件识别和业务逻辑本身属于不同的领域，没有很好进行抽象封装
3. 测试库构架框架
优点： 被测试系统无论是哪层发生变化，只需要相应的人员进行变更维护即可，完成了控件识别操作和业务逻辑的抽象分离
缺点：
变更引起的工作量还是附加在自动化测试开发工程师身上
4. 关键字驱动或表驱动测试框架
优点：极大的减少了自动化开发工程师维护量，毕竟在测试团队中，自动化开发工程师占的比较少普通测试工程师，可以很好的维护自身负责的模块中涉及的测试case和测试数据
缺点：框架的抽象程度比较高，对自动化测试工程师的开发能力比较高
7、怎样测试APP
APP交叉事件测试
针对智能终端应用的服务等级划分方式及实时特性所提出的测试方法。交叉测试又叫事件或冲突测试，是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰的测试。如；App在前/后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。交叉事件测试非常重要，能发现很多应用中潜在的性能问题。
1） 多个App同时运行是否影响正常功能
2）App运行时前/后台切换是否影响正常功能
3）App运行时拨打/接听电话
4）App运行时发送/接收信息
5）App运行时发送/收取邮件
6）App运行时切换网络（2G、3G、wifi）
7）App运行时浏览网络
8）App运行时使用蓝牙传送/接收数据
9）App运行时使用相机、计算器等手机自带设备
8、三角形问题
9、软件测试的基本流程
一：单元测试、集成测试、系统测试和验收测试（确认测试）；
二：测试需求分析，测试计划编写，测试用例编写，测试，缺陷记录，回归测试，判断测试结束，测试报告提交。
三：
测试流程依次如下：
1.需求：阅读需求，理解需求，与客户、开发、架构多方交流，深入了解需求。--testing team
2.测试计划: 根据需求估算测试所需资源（人力、设备等）、所需时间、功能点划分、如何合理分配安排资源等。---testing leader or testing manager
3.用例设计：根据测试计划、任务分配、功能点划分，设计合理的测试用例。---testing leader, senior tester
4.执行测试：根据测试用例的详细步骤，执行测试用例。--every tester(主要是初级测试人员)
5.执行结果记录和bug记录：对每个case记录测试的结果，有bug的在测试管理工具中编写bug记录。--every tester(主要是初级测试人员)
6.defect tracking：追踪leader分配给你追踪的bug.直到 bug fixed。--every tester
7.测试报告：通过不断测试、追踪，直到被测软件达到测试需求要求，并没有重大bug.
8.用户体验、软件发布等……
10、开发和测试流程
测试需求分析，测试计划编写，测试用例编写，测试，缺陷记录，回归测试，判断测试结束，测试报告提交。
11、回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
与一般测试的区别：
测试计划的可获性：回归测试面临的可能更改的规格说明书、修改过的程序和一个需要更新的旧的测试计划。
测试范围：一般测试过程目标是要检测整个程序的正确性，而回归测试目标是要检测被修改的相关部分正确性
时间分配：回归测试所需的时间、资源需要根据开发具体情况进行。
完成时间：通常比一般测试所需时间少，因为回归测试只需测试程序的一部分，且采用测试脚本自动化执行。
执行频率：一个系统的生命周期内往往要多次进行，一旦系统经过修改就需要回归测试。
组测试：
假设一个程序有5个组件，分别是A，B，C，D，E，现在ABC被修改了，而DE没有被修改
12、自动化测试优缺点
自动化测试的优点：
1、对回归测试更方便：进行回归测试，要测试系统的所有功能模块，周期较长的回归测试工作量大，测试比较频繁，适合自动化测试。由于测试的脚本和用例都是设计好的，测试期望的结果也可以预料，将回归测试自动化可以极大的提高效率缩短回归时间。
2、模拟真实情况：可以执行手工测试无法执行的测试，比如同时并发上千用户测试系统的负载量，测试人员无法达到测试目的，而使用自动化测试工具可以模拟多用户的并发过程。
3、有效的利用人力物力资源：频繁地机器化的动作可以用自动化测试执行，减少错误的发生，更好的利用人力资源。
4、测试的重复利用：由于自动测试通常使用的是自动化脚本技术，这样就可以只需要做较少的甚至是不修改就可以实现在不同的测试过程中使用相同的用例。
5、减少人为的错误：自动化测试是机器完成，不存在执行过程中人为的疏忽和错误，测试设计完全决定了测试的质量，可以降低减少人为造成的错误。
自动化测试的缺点：
1、自动化测试是工具执行，没有思维，无法进行主观判断，对界面色彩、布局和系统的奔溃现象无法发现，这些错误通过人眼很容易发现。
2、自动化测试工具本身是一个产品，在不同的系统平台或硬件平台可能会受影响，在运行时可能影响被测程序的测试结果。
3、对于需求更改频繁的软件，测试脚本的维护和设计比较空难。
4、自动化测试是机器执行，发现的问题比手工测试要少很多，通过测试工具没有发现缺陷，并不能说明系统不存在缺陷，只能通过工具评判测试结果和预期效果之间的差距。
5、自动化测试要编写测试脚本，设计场景，这些对测试人员的要求比较高，测试的设计直接影响测试的结果。
对手机可以施加的压力测试类型主要有：
● 存储压力：由于手机采用的是栈式存储，所以当一个存储块满了之后，如果程序员不做相应处理或者处理不好的话，很容易造成其他存储区被擦除，从而在UI上出现问题（比如其他功能无法正常使用，出现异常）。
● 边界压力：边界处理一直是程序员最容易忽略的地方。
● 响应能力压力：有时候某个操作可能处理的时间很长，在处理期间如果测试者再不断地进行其他操作的话，很容易出现问题。
● 网络流量压力：执行较大数据流量的功能的同时，再进行其他功能操作，使得网络流量始终处于很高的状态（如视频通话时再进行短信等其他功能操作），验证各功能是否依然能正常工作，是否存在因网络流量瓶颈而引起某功能异常。
压力测试用手工测试可能很繁锁，可以考虑自动化测试。遗憾的是，目前还没有较为大量使用的工具，一般都是由开发人员配合开发出的工具，或者高级的测试人员编写出的脚本。
14、测试bug等级划分标准
15、测试驱动开发，英文全称Test-Driven Development，简称 TDD ，是一种不同于传统 软件开发流程 的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。
16、验收测试：在系统测试之后，以用户测试为主，或有测试人员等质量保障人员共同参与的测试，是检验软件产品质量的最后一道工序
实施验收测试的常用策略有三种，它们分别是：
· 正式验收
· 非正式验收或 Alpha 测试
>>软件开发公司内部人员模拟各类用户对即将面世的软件产品（称为α版本）进行测试，试图发现错误。由用户、测试人员、开发人员等共同参与的内部测试
>>关键：尽可能逼真模拟实际运行环境和用户对软件产品的操作、尽最大努力涵盖所有用户操作
· Beta 测试
>> 内侧之后的公测，即完全交给最终用户测试。软件开发公司组织各方面的典型用户在日常生活中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善
17、性能测试：压力测试、负载测试、并发测试、强度测试及容量测试之间的区别
强度测试：在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。
容量测试：容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。
容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。
18、测试工具
LoadRunner-负载压力测试：预测系统性能。
JMeter+Badboy：基于JAVA的压力测试工具，Badboy用来进行脚本的录制
功能测试：通过自动录制、检测和回放用户的应用操作。将输出记录同预先给定的记录比较。
Junit：白盒测试工具：针对代码测试
测试管理工具：对测试需求、计划、用例、实施进行管理
测试辅助工具：本身不执行，可以生成测试数据，为测试提供数据准备
负载压力测试：LoadRunner:预测系统行为和性能的工业标准级负载测试工具。模拟上千万用户同时实施并发操作，来实时监控可能发生的问题。
功能测试： QTP(quicktest professional):自动测试工具
白盒测试：C++ TEST（做C和C++的白盒测试）、JUnit（Java白盒测试）
缺陷管理工具：Mantis、BugFree、QC、TD
用例管理工具：TestLink、QC
测试辅助工具：SVN
19、windows文件复制功能测试
1. 基本功能测试：
文件的复制粘贴功能，首先关键字“文件”，文件有不同的分类（图片、视频、音频、文档等），每个分类又有不同的类型（文档类型：txt doc execl pdf等），每个文件又有不同的大小，而且文件还有很多权限，是不是隐藏，是不是只是管理员可执行。选择不同分类的不同类型，不同大小的文件做测试资源。比如：文档类型里面txt文件可以分为 1.KB的txt文件、1MB的txt文件、1GB的txt文件。。。。
下一个关键字 复制粘贴 复制有多种方式 右击选择、Ctrl+C、 拖动复制，对应粘贴也有各种方式。
然后从哪复制，粘贴到哪，比如 可以有本机硬盘、移动硬盘、优盘、内存卡、软盘、光盘、连接手机存储，复制到网络地址等等。
复制粘贴后文件是不是可用，文件权限是不是有变化。复制过去容量不够怎么处理？复制过后有重名文件怎么处理？复制过程中取消、关机、拔优盘怎么处理？复制过程能不能执行文件？
2.性能测试：复制粘贴功能性能怎么样？复制文件的速度可不可以接受？同时复制多个文件是不是可以完成?复制文件过程中占用CPU资源大不大，耗电量大不大？
3.兼容性测试 Windows XP, Windows 7, Windows 8 , Windows 8.1, Windows 10等各种windos版本是不是都支持这个功能。
4.交互测试; 复制粘贴文件时，使用windows存储的其他功能是否有影响？比如播放本地的音频、视频、等同时复制文件是不是有影响。一边复制，一边粘贴是不是有影响。
20、已知String convert(String page)作用是将WEB页转码为方便移动设备查看的页面，为了确保转码的正确性，请设计相应测试策略。
【基本功能测试】
功能：
输入正确的网址，进行转码，检查内容是否正确；
边界：
输入信息量非常大的网址
输入没有信息的网址
负值：
输入错误的网址，进行转码，系统是否有相应的提示；
输入的 web 的 page 为空，是否抛出异常；
【兼容测试】
使用不同操作系统的移动设备查看转换后的页面，检查内容是否正确；
使用不同分辨率的移动设备查看转换后的页面，检查内容是否正确；
使用不同浏览器查看转换后的页面，检查内容是否正确；
【性能测试】
测试转码的速度，或者系统的响应时间；
【易用性 / 用户体验测试】
测试转码后，页面显示是否美观；
2273
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
