软件缺陷：
1）软件未实现产品说明书要求的功能
2）软件出现了产品说明书指明不应该出现的错误
3）软件实现了产品说明书未提到的功能
4）软件未实现产品说明书虽未明确提及但应该实现的目标
5）软件难以理解、不易使用、运行缓慢或者从测试员的角度看最终用户会认为不好。
软件测试：为了发现软件产品中的各种缺陷，而对软件产品进行验证和确认的活动过程，此过程贯穿整个软件开发生命周期。 简单的说，软件测试是以发现错误为目的而执行的一个程序或系统的过程。
软件测试的目的：
1.验证软件需求和功能是否得到完整实现
2.验证软件是否可以发布
3.尽可能多的发现软件中的bug
4.尽可能早的发现软件中的bug
5.对软件质量做出合理评估
6.预防下个版本可能出现的问题
7.预防用户使用可能出现的问题
8.发现开发过程中的问题和风险
软件测试的原则：
1、所有测试的标准都是建立在用户需求之上 。
2、合理控制测试深度与广度，完全测试不可能，测试的投入与产出要均衡。
3、80-20原则，软件中80%的bug可以在分析、设计与评审阶段就能被发现与修正，16%的缺陷在系统的软件测试中发现，最后剩下的4%是用户长期使用的过程中才能暴露出来。
4、尽可能早的开展测试，越早发现错误，修改的代价越小。
5、发现错误较多的程序段，应进行更深入的测试。
6、软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试 。
7、软件开发人员即程序员应当避免测试自己的程序
8、严格执行测试计划，排除测试的随意性，以避免发生疏漏或者重复无效的工作
软件测试的流程
web测试和APP测试的区别
仅仅从功能测试的层面上来讲的话，在流程和功能测试上是没有区别的。那么区别在哪里呢？
由于载体不一样，所以系统测试和一些细节可能会不一样。
那么我们就要先来了解，web和app的区别。
web项目，一般都是b/s架构，基于浏览器的，而app则是c/s的，必须要有客户端。那么在系统测试测试的时候就会产生区别了。
首先从系统架构来看的话，web测试只要更新了服务器端，客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是app端是不能够保证完全一致的，除非用户更新客户端。如果是app下修改了服务端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍。
接着是性能方面，web页面可能只会关注响应时间，而app则还需要关心流量、电量、CPU、GPU、Memory这些了。至于服务端的性能是没区别，这里就不谈。
相比较web测试，app更是多了一些专项测试：
健壮性测试：
一些异常场景的考虑以及弱网络测试。这里的异常场景就是中断，来电，短信，关机，重启等。
而弱网测试是app测试中必须执行的一项测试。包含弱网和网络切换测试。需要测试弱网所造成的用户体验，重点要考虑回退和刷新是否会造成二次提交。需要测试丢包，延时的处理机制。避免用户的流失。这些在前面的弱网测试那篇已经讲过，这里不再讲了。
安装、卸载、更新：
web测试是基于浏览器的所以不必考虑这些。而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件，更新的强制更新与非强制更新、增量包更新、断点续传、弱网，卸载后删除app相关的文件等等。
就自动化来讲，web大多用的selenium、webdriver，而app则是appium。
性能使用的工具web则是LR，app使用Jmeter要多一点
如何提交高质量的缺陷报告单
1、 缺陷的概要描述要清晰准确，要使相关开发负责人员能够一目了然问题是什么。
2、 一个完整的缺陷报告单，必须包含其必要的元素信息，例如：概要描述，缺陷发现人，测试环境，浏览器，缺陷重现步骤，严重等级，指派人，所属功能模块等等，必要元素信息必须描述全面清楚。
3、 缺陷的重现步骤必须描写清晰明了，使相关开发负责人能够根据重现步骤准确的重现所提交的缺陷，使其定位缺陷的原因所在。
4、测试数据，测试的数据作为重现缺陷的一个重要元素信息，一定要将测试时所使用的信息给描写清楚准确。让开发人员根据测试所提供的测试数据准确重现缺陷。
5、附件截图信息，附件或截图信息能让开发人员能够一目了然的清楚问题的所在。
如何对web系统进行全面测试？
一、 功能测试
1、链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面;其次，测试所链接的页面是否存在;最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。 链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。
2、表单测试
当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
3、Cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。 如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。
4、设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。
5、数据库测试
在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。 在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
二、 性能测试
1、连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟)，用户就会因没有耐心等待而离开。 另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2、负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线?如果超过了这个数量，会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?
3、压力测试
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。 进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。 压力测试的区域包括表单、登陆和其他信息传输页面等。
三、 可用性测试
1、导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助? 在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。 导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。 Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
2、图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。
图形测试的内容有：
(1)要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
(2)验证所有页面字体的风格是否一致。
(3)背景颜色应该与字体颜色和前景颜色相搭配。
(4)图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。
3、内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。 信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的拼音与语法检查功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓相关文章列表。
4、整体界面测试
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致? 对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。 对所有的可用性测试来说，都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与，最好是最终用户的参与。
四、 客户端兼容性测试
1、平台测试
市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。 因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。
2、浏览器测试
浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。 测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
五、 安全性测试
Web应用系统的安全性测试区域主要有：
(1)现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
(2)Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内(例如15分钟)没有点击任何页面，是否需要重新登陆才能正常使用。
(3)为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
(4)当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
(5)服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
测试用例设计经典面试题——电梯，杯子，笔，桌子，洗衣机
优秀测试人员应具备的素质：
1）沟通能力与表达能力
2）好奇心与怀疑精神
3）责任感与抗压能力
4）自信心，坚持自己的观点
5）耐心与细心
6）逆向思维的能力
7）善于学习与总结
8）团队协作精神
9）文档编写能力
优秀测试人员应具备的技能：
1）精通业务知识
2）具备软件编程能力，比如C,C++,JAVA等。
3）可以用脚本语言编写小测试工具
4）主流操作系统应用与网络知识，可以搭建测试环境
5）熟练掌握各种数据库知识
6）精通软件测试理论与方法
7）掌握常用测试与开发工具的使用
8）优秀的文档编写能力
软件测试的分类：
1）按照是否执行被测试软件来分：
静态测试：是指不运行软件，测试包括代码检查、静态结构分析、代码质量度量等，主要对软件需求说明书、设计说明书、软件源代码进行检查与分析。
动态测试：指通过运行被测程序，检查运行结果与预期结果的差异，分析差异原因，并分析软件运行效率、健壮性等性能。 动态测试是目前公司主要的测试方式
2）按照测试技术分为黑盒测试和白盒测试：
黑盒测试：黑盒测试又叫功能测试或数据驱动测试，在完全不考虑程序内部结构和内部特性的情况下，通过软件的外部表现来发现其缺陷和错误。
白盒测试：白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构进行测试程序，通过测试来检测产品内部逻辑是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。
3）按照测试手段来分，可以分为手工测试和自动化测试
4）按照过程阶段来分，可以分为单元测试、集成测试、系统测试和验收测试
单元测试：通过模块(类/方法/函数)测试，使代码达到设计要求 主要目的是针对编码过程中可能存在的各种错误，例如用户输入验证过程中的边界值的错误。
集成测试：将经过单元测试的模块逐步组装成完整的程序。 主要目的是检查各单元与其它程序部分之间的接口是否存在问题，各模块功能之间是否有影响。
系统测试：是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起进行测试。 系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方 ，进行改正。
验收测试：验收测试是在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的最后一次软件测试活动，也称为交付测试。 通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需要。
软件开发流程（软件生命周期）：
计划-》需求分析-》设计-》程序编写-》测试-》运行/维护
软件测试流程：
测试计划-》需求分析-》测试用例-》测试用例执行-》提交bug-》回归测试
软件开发模型：
软件测试模型：
V模型：反映了测试与开发阶段之间一一对应的特点，测试在开发之后，出错后回归测试量大。
W模型：测试伴随整个开发周期，测试与开发同步进行，有利于尽早发现问题
H模型：软件测试活动完全独立，与其他流程并行。
白盒测试方法
白盒测试方法有 语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
1.语句覆盖每条语句至少执行一次。
2.判定覆盖每个判定的每个分支至少执行一次。
3.条件覆盖每个判定的每个条件应取到各种可能的值。
4.判定/条件覆盖同时满足判定覆盖条件覆盖。
5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖使程序中每一条可能的路径至少执行一次。
设计用例的方法、依据有那些?
测试分为白盒测试和黑盒测试，回答时，要注意分开说。白盒测试用例设计有如下方法：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。依据就是代码结构。
黑盒测试用例设计方法：基于用户需求的测试、等价类划分方法、边界值分析方法、错误推测方法、因果图方法、判定表驱动分析方法、正交实验法、场景法。依据是用户需求规格说明书，详细设计说明书。
一个测试工程师应具备那些素质和技能?
一个好的测试工程师，不仅要基础扎实，对自身的性格、责任心都有非常高的要求。具体如下：(1)掌握基本的测试基础理论(2)本着找出软件存在的问题的态度进行测试,即客观吧,不要以挑刺形象出现(3)可熟练阅读需求规格说明书等文档(4)以用户的观点看待问题(5)有着强烈的质量意识(6)细心和责任心(7)良好的有效的沟通方式(与开发人员及客户)(8)具有以往的测试经验(9)能够及时准确地判断出高危险区在何处.
集成测试通常都有哪些策略?
大致说四点即可，当然说全更好。集成测试有十种策略:(1)大爆炸集成(2)自顶向下集成(3)自底向上集成(4)三明治集成(5)分层集成(6)基干集成(7)基于功能的集成(8)基于消息的集成(9)基于风险的集成(10)基于进度的集成.
什么是兼容性测试？兼容性测试侧重哪些方面？
兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。
兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。
兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。
我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？
1、检查系统是否有中毒的特征；
2、检查软件/硬件的配置是否符合软件的推荐标准；
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务；
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。
测试的策略有哪些？
黑盒/白盒，静态/动态，手工/自动，冒烟测试，回归测试，公测（Beta测试的策略）
正交表测试用例设计方法的特点是什么？
用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；
对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；
具体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。
描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程？
详见bugZilla使用指南
在Bugzilla中，Bug报告状态分为以下几种状态，
待确认的 unconfirmed
新提交的 new
已分配的 assigned
问题未解决的 reopened
待返测的 resolved
待归档的 verified
已归档的 closed
Bug处理意见（Resolution）
已修改的 fixed
不是问题 nvalid
无法修改 wontfix
以后版本解决 later
保留 remind
重复 duplicate
无法重现 workforme
你觉得bugzilla在使用的过程中，有什么问题？
界面不稳定；
根据需要配置它的不同的部分，过程很烦琐。
流程控制上，安全性不好界定，很容易对他人的Bug进行误操作；
没有综合的评分指标，不好确认修复的优先级别。
描述测试用例设计的完整过程？
需求分析 + 需求变更的维护工作；
根据需求 得出测试需求；
设计测试方案，评审测试方案；
方案评审通过后，设计测试用例，再对测试用例进行评审；
单元测试的策略有哪些？
单元的常见错误一般出现在以下五个方面，因此这五个方面是单元测试应该关注的重点。
1、单元接口。
2、局部数据结构。
3、独立路径。
4、出错处理。
5、边界条件
在单元测试时，由于单元本身不是一个独立的程序，一个完整的可运行的软件系统并没有构成，所以需要设置一些辅助测试单元，辅助测试单元有两种，一种是驱动单元，另外一种是桩单元。
1、驱动单元（Driver）:用来模拟被测单元的上层单元，相当于被测函数的主函数，如main函数。所以驱动单元主要完成以下4个步骤：
（1）接受测试数据，包含测试用例输入和预期输出；
（2）把测试用例输入传送给被测单元，驱动被测单元测试；
（3）将被测单元的实际输出和预期输出进行比较，得到测试结果；
（4）将测试结果输出到指定位置。
2、桩单元（Stub）：用来代替被测单元工作过程中调用的子单元。
桩单元模拟的单元可能是自定义函数：这些自定义函数可能尚未编写完成，为了测试被测单元，需要构造桩单元来代替它们，可能存在错误，会影响测试结果，所以需要构造正确无误的桩单元来达到隔离的目的。
驱动单元和桩单元都是额外的开销，虽然在单元测试的时候必须写，但是并不需要作为最终的产品提供给客户。
单元测试策略
一般的单元执行策略有三种：孤立的单元测试策略（Isolation Unit Testing），自顶向下的单元测试策略（Top Down Unit Testing）和自底向上的单元测试策略（Bottom Up Unit Testing）。需要注意的是：在集成测试中也有自顶向下和自底向上的测试策略，但是测试对象不同。
1、孤立的单元测试策略（Isolation Unit Testing）
方法：不考虑每个模块与其它模块之间的关系，为每个模块设计桩模块和驱动模块，每个模块进行独立的单元测试。
优点：这个方法比较简单，最容易操作，可以达到很高的结构覆盖率，可以并行开展，该方法是纯粹的单元测试。
缺点：桩函数和驱动函数工作量很大，效率低。
2、自顶向下的单元测试策略（Top Down Unit Testing）
方法：先对最顶层的单元进行测试，把顶层所调用的单元做成桩模块，其次对第二层进行测试，使用上面已经测试过的单元做驱动模块，以此类推，直到测试完所有模块。
优点：可以节省驱动函数的开发工作，效率高。
缺点：随着被测单元一个一个被加入，测试过程将变得越来越复杂，并且开发和维护的成本将增加。
3、自底向上的单元测试策略（Bottom Up Unit Testing）
方法：先对最底层的模块进行单元测试，将模拟调用该模块的模块设置为驱动模块，然后再对上面一层做单元测试，用下面已经测试好的模块做桩模块，以此类推，直到测试完所有模块。
优点：可以节省桩函数的开发工作量，测试效率较高。
缺点：不是纯粹的单元测试，底层函数的测试质量对上层函数的测试将产生很大影响。
LoadRunner分哪三部分？
脚本生成器；
场景控制器；
结果分析器。
LoadRunner进行测试的流程?
1、 测试设计
2、 创建虚拟用户脚本
3、 创建运行场景
4、 运行场景
5、 监视场景
6、 分析测试的结果
以上，最好是结合一个案例，根据以上流程来介绍。
什么是并发？在lordrunner中，如何进行并发的测试？集合点失败了会怎么样？
在同一时间点，支持多个不同的操作。
LoadRunner中提供IP伪装，集合点，配合虚拟用户的设计，以及在多台电脑上设置，可以比较好的模拟真实的并发。
集合点，即是多个用户在某个时刻，某个特定的环境下同时进行虚拟用户的操作的。集合点失败，则集合点的操作就会取消，测试就不能进行。
TestDirector有些什么功能，如何对软件测试过程进行管理？
需求管理
n 定义测试范围
n 定义需求树
n 描述需求树的功能点
测试计划
n 定义测试目标和测试策略。
n 分解应用程序，建立测试计划树。
n 确定每个功能点的测试方法。
n 将每个功能点连接到需求上，使测试计划覆盖全部的测试需求。
n 描述手工测试的测试步骤
n 指明需要进行自动测试的功能点
测试执行
n 定义测试集合。
n 为每个测试人员制定测试任务和测试日程安排。
n 运行自动测试。
缺陷跟踪
n 记录缺陷
n 查看新增缺陷，并确定哪些是需要修正的
n 相关技术人员修改缺陷
n 回归测试
n 分析缺陷统计图表，分析应用程序的开发质量。
你所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）？
Compatibility Testing（兼容性测试），也称“Configuration testing（配置测试）”，测试软件是否和系统的其它与之交互的元素之间兼容，如：浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。
Functional testing (功能测试)，也称为behavioral testing（行为测试），根据产品特征、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的一样。
Performance testing（性能测试），评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。
一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
1.和BUG对应的软件版本
2.开发的接口人员，测试人员
3.BUG的优先级
4.BUG的严重程度
5.BUG可能属于的模块
6.BUG的标题
7.BUG的描述
8.BUG的截图
9.BUG的状态
10.BUG的错误类型（数据，界面。。。。）
Beta测试与Alpha测试有什么区别？
Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场
Alpha testing (α测试),是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试
软件的评审一般由哪些人参加？其目的是什么？
在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷，并采取补救措施，以及找出在性能、安全性和经济方面的可能的改进。
人员：用户、客户或有关部门开发人员，测试人员，需求分析师都可以，就看处于评审那个阶段
阶段评审与项目评审有什么区别？
阶段评审对项目各阶段评审：对阶段成果和工作
项目评审对项目总体评审：对工作和产品
什么是扇入？什么是扇出？
参考答案：
扇入：被调次数，扇出：调其它模块数目
什么是桩模块？什么是驱动模块？
桩模块：被测模块调用模块
驱动模块：调用被测模块
你认为做好测试计划工作的关键是什么？
软件测试计划就是在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试；
做好测试计划工作的关键：目的，管理，规范
1、 明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
2．坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
3．采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
4、分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。
简述一下缺陷的生命周期？
提交->确认->分配->修复->验证->关闭
软件的安全性应从哪几个方面去测试？
(1)用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议
(2)加密机制
(3)安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描
(4)数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理
(5)防病毒系统
软件配置管理工作开展的情况和认识？
软件配置管理贯穿于软件开发、测试活动的始终，覆盖了开发、测试活动的各个环节，它的重要作用之一就是要全面的管理保存各个配置项，监控各配置项的状态，并向项目经理及相关的人员报告，从而实现对软件过程的控制。
软件测试配置管理包括4个最基本的活动：
配置项标识
配置项控制
配置项状态报告
配置审计
软件配置管理通常借助工具来辅助，主要有MS SourceSafe、Rational ClearCase等
你觉得软件测试通过的标准应该是什么样的？
缺陷密度值达到客户的要求
引入测试管理的含义？
风险分析，进度控制、角色分配、质量控制
一套完整的测试应该由哪些阶段组成？
参考答案：测试计划、测试设计与开发、测试实施、测试评审与测试结论
单元测试的主要内容？
模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
集成测试也叫组装测试或者联合测试，请简述集成测试的主要内容？
（1）在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
（2）一个模块的功能是否会对另一个模块的功能产生不利的影响；
（3）各个子功能组合起来，能否达到预期要求的父功能；
（4）全局数据结构是否有问题；
（5）单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
简述集成测试与系统测试关系？
（1）集成测试的主要依据概要设计说明书，系统测试的主要依据是需求设计说明书；
（2）集成测试是系统模块的测试，系统测试是对整个系统的测试，包括相关的软硬件平台、网络以及相关外设的测试。
软件测试的文档测试应当贯穿于软件生命周期的全过程，其中用户文档是文档测试的重点。那么软件系统的用户文档包括哪些？
用户手册
安装和设置指导
联机帮助
指南、向导
样例、示例和模板
授权/注册登记表
最终用户许可协议
软件系统中除用户文档之外，文档测试还应该关注哪些文档？
开发文档
软件需求说明书
数据库设计说明书
概要设计说明书
详细设计说明书
可行性研究报告
管理文档
项目开发计划
测试计划
测试报告
开发进度月报
开发总结报告
简述软件系统中用户文档的测试要点？
（1）读者群。文档面向的读者定位要明确。对于初级用户、中级用户以及高级用户应该有不同的定位
（2）术语。文档中用到的术语要适用与定位的读者群，用法一致，标准定义与业界规范相吻合。
（3）正确性。测试中需检查所有信息是否真实正确，查找由于过期产品说明书和销售人员夸大事实而导致的错误。检查所有的目录、索引和章节引用是否已更新，尝试链接是否准确，产品支持电话、地址和邮政编码是否正确。
（4）完整性。对照软件界面检查是否有重要的分支没有描述到，甚至是否有整个大模块没有描述到。
（5）一致性。按照文档描述的操作执行后，检查软件返回的结果是否与文档描述的相同。
（6）易用性。对关键步骤以粗体或背景色给用户以提示，合理的页面布局、适量的图表都可以给用户更高的易用性。需要注意的是文档要有助于用户排除错误。不但描述正确操作，也要描述错误处理办法。文档对于用户看到的错误信息应当有更详细的文档解释。
（7）图表与界面截图。检查所有图表与界面截图是否与发行版本相同。
（8）样例与示例。像用户一样载入和使用样例。如果是一段程序，就输入数据并执行它。以每一个模块制作文件，确认它们的正确性。
（9）语言。不出现错别字，不要出现有二义性的说法。特别要注意的是屏幕截图或绘制图形中的文字。
（10）印刷与包装。检查印刷质量；手册厚度与开本是否合适；包装盒的大小是否合适；有没有零碎易丢失的小部件等等。
单元测试主要内容是什么？
单元测试大多数由开发人员来完成，测试人员技术背景较好或者开发系统软件时可能会安排测试人员进行单元测试，大多数进行的单元测试都是开发人员调试程序或者开发组系统联合调试的过程。讨论这个问题主要是扩充一下读者的视野。
单元测试一般包括五个方面的测试：
（1）模块接口测试：模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。模块接口测试也是集成测试的重点，这里进行的测试主要是为后面打好基础。测试接口正确与否应该考虑下列因素：
-输入的实际参数与形式参数的个数是否相同；
-输入的实际参数与形式参数的属性是否匹配；
-输入的实际参数与形式参数的量纲是否一致；
-调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；
-调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；
-调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；
-调用预定义函数时所用参数的个数、属性和次序是否正确；
-是否存在与当前入口点无关的参数引用；
-是否修改了只读型参数；
-对全程变量的定义各模块是否一致；
-是否把某些约束作为参数传递。
如果模块功能包括外部输入输出，还应该考虑下列因素：
-文件属性是否正确；
-OPEN/CLOSE语句是否正确；
-格式说明与输入输出语句是否匹配；
-缓冲区大小与记录长度是否匹配；
-文件使用前是否已经打开；
-是否处理了文件尾；
-是否处理了输入/输出错误；
-输出信息中是否有文字性错误。
-局部数据结构测试；
-边界条件测试；
-模块中所有独立执行通路测试；
（2）局部数据结构测试：检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确，局部功能是整个功能运行的基础。重点是一些函数是否正确执行，内部是否运行正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：
-不合适或不相容的类型说明；
-变量无初值；
-变量初始化或省缺值有错；
-不正确的变量名（拼错或不正确地截断）；
-出现上溢、下溢和地址异常。
（3）边界条件测试：边界条件测试是单元测试中最重要的一项任务。众所周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。边界条件测试是一项基础测试，也是后面系统测试中的功能测试的重点，边界测试执行的较好，可以大大提高程序健壮性。
（4）模块中所有独立路径测试：在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。测试目的主要是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。具体做法就是程序员逐条调试语句。常见的错误包括：
-误解或用错了算符优先级；
-混合类型运算；
-变量初值错；
-精度不够；
-表达式符号错。
比较判断与控制流常常紧密相关，测试时注意下列错误：
-不同数据类型的对象之间进行比较；
-错误地使用逻辑运算符或优先级；
-因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；
-比较运算或变量出错；
-循环终止条件或不可能出现；
-迭代发散时不能退出；
-错误地修改了循环变量。
模块的各条错误处理通路测试：程序在遇到异常情况时不应该退出，好的程序应能预见各种出错条件，并预设各种出错处理通路。如果用户不按照正常操作，程序就退出或者停止工作，实际上也是一种缺陷，因此单元测试要测试各种错误处理路径。一般这种测试着重检查下列问题：
-输出的出错信息难以理解；
-记录的错误与实际遇到的错误不相符；
-在程序自定义的出错处理段运行之前，系统已介入；
-异常处理不当；
-错误陈述中未能提供足够的定位出错信息。
如何理解强度测试？
强度测试是为了确定系统在最差工作环境的工作能力,也可能是用于验证在标准工作压力下的各种资源的最下限指标。
它和压力测试的目标是不同的,压力测试是在标准工作环境下,不断增加系统负荷,最终测试出该系统能力达到的最大负荷(稳定和峰值),而强度测试则是在非标准工作环境下,甚至不断人为降低系统工作环境所需要的资源,如网络带宽,系统内存,数据锁等等,以测试系统在资源不足的情况下的工作状态,通过强度测试,可以确定本系统正常工作的最差环境.
强度测试和压力测试的测试指标相近,大多都是与时间相关的指标,如并发量(吞吐量),延迟(最大\最小\平均)以及顺序指标等
强度测试需要对系统的结构熟悉,针对系统的特征设计强度测试的方法
如何理解压力、负载、性能测试测试？
性能测试是一个较大的范围，实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。
压力测试是对服务器的稳定性以及负载能力等方面的测试，是一种很平常的测试。增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。而负载测试是压力相对较大的测试，主要是测试系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。100个用户对系统进行连续半个小时的访问可以看作压力测试，那么连续访问8个小时就可以认为负载测试，1000个用户连续访问系统1个小时也可以看作是负载测试。
实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行测试。
什么是系统瓶颈？
瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户的特定业务要求，“特定”是指瓶颈会在某些条件下会出现，因为毕竟大多数系统在投入前。
严格的从技术角度讲，所有的系统都会有瓶颈，因为大多数系统的资源配置不是协调的，例如CPU使用率刚好达到100％时，内存也正好耗尽的系统不是很多见。因此我们讨论系统瓶颈要从应用的角度讨论：关键是看系统能否满足用户需求。在用户极限使用系统的情况下，系统的响应仍然正常，我们可以认为改系统没有瓶颈或者瓶颈不会影响用户工作。
因此我们测试系统瓶颈主要是实现下面两个目的：
-发现“表面”的瓶颈。主要是模拟用户的操作，找出用户极限使用系统时的瓶颈，然后解决瓶颈，这是性能测试的基本目标。
-发现潜在的瓶颈并解决，保证系统的长期稳定性。主要是考虑用户在将来扩展系统或者业务发生变化时，系统能够适应变化。满足用户目前需求的系统不是最好的，我们设计系统的目标是在保证系统整个软件生命周期能够不断适应用户的变化，或者通过简单扩展系统就可以适应新的变化。
文档测试主要包含什么内容？
在国内软件开发管理中，文档管理几乎是最弱的一项，因而在测试工作中特别容易忽略文档测试也就不足为奇了。要想给用户提供完整的产品，文档测试是必不可少的。文档测试一般注重下面几个方面：
文档的完整性：主要是测试文档内容的全面性与完整性，从总体上把握文档的质量。例如用户手册应该包括软件的所有功能模块。
描述与软件实际情况的一致性：主要测试软件文档与软件实际的一致程度。例如用户手册基本完整后，我们还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速度。
易理解性：主要是检查文档对关键、重要的操作有无图文说明，文字、图表是否易于理解。对于关键、重要的操作仅仅只有文字说明肯定是不够的，应该附有图表使说明更为直观和明了。
文档中提供操作的实例：这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实例是否丰富，提供的实例描述是否详细。只有简单的图文说明，而无实例的用户手册看起来就像是软件界面的简单拷贝，对于用户来说，实际上没有什么帮助。
印刷与包装质量：主要是检查软件文档的商品化程度。有些用户手册是简单打印、装订而成，过于粗糙，不易于用户保存。优秀的文档例如用户手册和技术白皮书，应提供商品化包装，并且印刷精美。
配置和兼容性测试的区别是什么？
配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是测试软件能否与不同的软件正确协作。
配置测试的核心内容就是使用各种硬件来测试软件的运行情况，一般包括：
（1）软件在不同的主机上的运行情况，例如Dell和Apple；
（2）软件在不同的组件上的运行情况，例如开发的拨号程序要测试在不同厂商生产的Modem上的运行情况；
（3）不同的外设；
（4）不同的接口；
（5）不同的可选项，例如不同的内存大小；
兼容性测试的核心内容：
（1）测试软件是否能在不同的操作系统平台上兼容；
（2）测试软件是否能在同一操作系统平台的不同版本上兼容；
（3）软件本身能否向前或者向后兼容；
（4）测试软件能否与其它相关的软件兼容；
（5）数据兼容性测试，主要是指数据能否共享；
配置和兼容性测试通称对开发系统类软件比较重要，例如驱动程序、操作系统、数据库管理系统等。具体进行时仍然按照测试用例来执行。
软件文档测试主要包含什么？
随着软件文档系统日益庞大，文档测试已经成为软件测试的重要内容。文档测试对象主要如下：
-包装文字和图形；
-市场宣传材料、广告以及其它插页；
-授权、注册登记表；
-最终用户许可协议；
-安装和设置向导；
-用户手册；
-联机帮助；
-样例、示范例子和模板；
-……
文档测试的目的是提高易用性和可靠性，降低支持费用，因为用户通过文档就可以自己解决问题。因文档测试的检查内容主要如下：
-读者对象——主要是文档的内容是否能让该级别的读者理解；
-术语——主要是检查术语是否适合读者；
-内容和主题——检查主题是否合适、是否丢失、格式是否规范等；
-图标和屏幕抓图——检查图表的准确度和精确度；
-样例和示例——是否与软件功能一致；
-拼写和语法；
-文档的关联性——是否与其它相关文档的内容一致，例如与广告信息是否一致；
文档测试是相当重要的一项测试工作，不但要给予充分的重视，更要要认真的完成，象做功能测试一样来对待文档测试。
没有产品说明书和需求文档地情况下能够进行黑盒测试吗？
这个问题是国内测试工程师经常遇到的问题，根源就是国内软件开发文档管理不规范，对变更的管理方法就更不合理了。实际上没有任何文档的时候，测试人员是能够进行黑盒测试的，这种测试方式我们可以称之为探索测试，具体做法就是测试工程师根据自己的专业技能、领域知识等不断的深入了解测试对象、理解软件功能，进而发现缺陷。
在这种做法基本上把软件当成了产品说明书，测试过程中要和开发人员不断的进行交流。尤其在作项目的时候，进度压力比较大，可以作为加急测试方案。最大的风险是不知道有些特性是否被遗漏。
##3 测试中的“杀虫剂怪事”是指什么？
“杀虫剂怪事”一词由BorisBeizer在其编著的《软件测试技术》第二版中提出。用于描述测试人员对同一测试对象进行的测试次数越多，发现的缺陷就会越来越少的现象。就像老用一种农药，害虫就会有免疫力，农药发挥不了效力。这种现象的根本原因就是测试人员对测试软件过于熟悉，形成思维定势。
为了克服这种现象，测试人员需要不断编写新的测试程序或者测试用例，对程序的不同部分进行测试，以发现更多的缺陷。也可以引用新人来测试软件，刚刚进来的新手往往能发现一些意想不到的问题。
在配置测试中，如何判断发现的缺陷是普通问题还是特定的配置问题？
在进行配置测试时，测试工程师仍然会发现一些普通的缺陷，也就是与配置环境无关的缺陷。因此判断新发现的问题，需要在不同的配置中重新执行发现软件缺陷的步骤，如果软件缺陷不出现了，就可能是配置缺陷；如果在所有的配置中都出现，就可能是普通缺陷。
需要注意的是，配置问题可以在一大类配置中出现。例如，拨号程序可能在所有的外置Modem中都存在问题，而内置的Modem不会有任何问题。
完全测试程序是可能的吗？
软件测试初学者可能认为拿到软件后需要进行完全测试，找到全部的软件缺陷，使软件“零缺陷”发布。实际上完全测试是不可能的。主要有以下一个原因：
-完全测试比较耗时，时间上不允许；
-完全测试通常意味着较多资源投入，这在现实中往往是行不通的；
-输入量太大，不能一一进行测试；
-输出结果太多，只能分类进行验证；
-软件实现途径太多；
-软件产品说明书没有客观标准，从不同的角度看，软件缺陷的标准不同；
因此测试的程度要根据实际情况确定。
软件测试的风险主要体现在哪里？
我们没有对软件进行完全测试，实际就是选择了风险，因为缺陷极有可能存在没有进行测试的部分。举个例子，程序员为了方便，在调试程序时会弹出一些提示信息框，而这些提示只在某种条件下会弹出，碰巧程序发布前这些代码中的一些没有被注释掉。在测试时测试工程师又没有对其进行测试。如果客户碰到它，这将是代价昂贵的缺陷，因为交付后才被客户发现。
因此，我们要尽可能的选择最合适的测试量，把风险降低到最小。
发现的缺陷越多，说明软件缺陷越多吗？
这是一个比较常见的现象。测试工程师在没有找到缺陷前会绞尽脑汁的思考，但是找到一个后，会接二连三的发现很多缺陷，颇有个人成就感。其中的原因主要如下：
-代码复用、拷贝代码导致程序员容易犯相同的错误。类的继承导致所有的子类会包含基类的错误，反复拷贝同一代码意味可能也复制了缺陷。
-程序员比较劳累是可以导致某些连续编写的功能缺陷较多。程序员加班是一种司空见惯的现象，因此体力不只时容易编写一些缺陷较多的程序。而这些连续潜伏缺陷恰恰时测试工程师大显身手的地方。
“缺陷一个连着一个”不是一个客观规律，只是一个常见的现象。如果软件编写的比较好，这种现象就不常见了。测试人员只要严肃认真的测试程序就可以了。
所有的软件缺陷都能修复吗？所有的软件缺陷都要修复吗？
从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。测试人员要做的是能够正确判断什么时候不能追求软件的完美。对于整个项目团队，要做的是对每一个软件缺陷进行取舍，根据风险决定那些缺陷要修复。发生这种现象的主要原因如下：
-没有足够的时间资源。在任何一个项目中，通常情况下开发人员和测试人员都是不够用的，而且在项目中没有预算足够的回归测试时间，再加上修改缺陷可能引入新的缺陷，因此在交付期限的强大压力下，必须放弃某些缺陷的修改。
-有些缺陷只是特殊情况下出现，这种缺陷处于商业利益考虑，可以在以后升级中进行修复。
-不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理，这类问题可以以后有时间时考虑再处理。
最后要说的是，缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复，不同角色的人员从不同的角度来思考，以做出正确的决定。
软件测试人员就是QA吗？
软件测试人员的职责是尽可能早的找出软件缺陷，确保得以修复。而质量保证人员（QA）主要职责是创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。测试人员的主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是测试保证人员的工作对象。
软件测试和质量是相辅相成的关系，都是为了提高软件质量而工作。
如何减少测试人员跳槽带来的损失？
在IT行业里跳槽已经是一种司空见惯的现象，而且跳槽无论给公司还是给个人都会带来一定的损失。测试队伍也无疑会面临跳槽的威胁，作为测试经理管理者，只有从日常工作中开始做起，最能最大限度的减少损失。建议我们从以下两个方面做起：
-加强部门内员工之间的互相学习，互相学习是建立学习型组织的基本要求，是知识互相转移的过程。在此基础上，可以把个人拥有的技术以知识的形式沉积下来，也就完成了隐性知识到显性知识的转化。
-通常情况下，企业能为员工提供足够大的发展空间时，如果不是待遇特别低，员工都不会主动离开企业。因此我们要想留住员工，管理者就应该把员工的个人成长和企业的发展联系起来，为员工设定合理发展规划并付诸实现。不过这项要求做起来比较，要有比较好的企业文化为依托.
以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存储的其他功能是否有影响？比如播放本地的音频、视频、等同时复制文件是不是有影响。一边复制，一边粘贴是不是有影响。
粘贴的稳定性：粘贴完了大小会不会变化，内容格式会不会变化，粘贴不上，误操作以后还能不能找到复制的内容等
粘贴的安全性：粘贴的内容粘贴好了以后会不会存在别处泄露等
2.性能测试：（1）时间：复制粘贴的响应时间？页面的显示时间？（2）负载：多次重复进行复制粘贴是否有异常？复制粘贴容量很大的一个或多个文件是否能承受？（3）强度：保证容量足够的条件下，分别复制粘贴50GB，100GB，500GB，…大小的文件，看什么时候出现失败，失败后的表现，能否重新正常复制粘贴50G？（4）容量：在不同CPU资源条件下，持续复制粘贴5分钟，最多能复制粘贴多少容量的文件？
5.界面测试：复制粘贴时进度条的显示界面是否与系统的设计风格一致？显示界面是否有文字性错误？显示界面的布是否合理？界面上的按钮是否可用（如：是否可以选择中止？是否可用最小化？）
6.本地化测试：不同语言环境下的显示正常
7.辅助性测试：高对比度下能否显示正常
1 、复制粘贴方法
快捷键测试：测试 Ctrl+C ，是否正确执行复制、 Ctrl+v 是否支持粘贴功能
右键测试：查看复制粘贴功能是否正确执行；
在 cmd 命令行中使用复制粘贴命令；
2 、文件大小测试
源文件为空， 0 字节；
源文件正常大小；
源文件为超大文件： **G/ 等；
3 、文件格式
测试各种文件格式下是否正常复制粘贴：如：图片、声音、视频、压缩文件、办公文件： word\excel\ppt 等、二进制文件；
测试共享文件、隐藏文件
4 、复制和粘贴文件路径
在系统不同文件路径下复制粘贴，
测试相对路径和绝对路径下文件复制粘贴；
测试文件夹下和另一个不同文件夹复制粘贴；
测试不同 C\D\E 盘之间；
测试复制粘贴至：移动硬盘、 U 盘、读卡器以及其它外部存储设备；
5 、异常测试
测试被损坏文件、不完整文件名称、禁止复制和粘贴的文件、超出规定大小文件等；
同名称文件测试是否提醒替换或覆盖；
6 、兼容性
测试不同操作系统之间、不同应用程序（如： QQ ）；
7 、性能测试：
测试复制粘贴可支持最大文件大小；复制粘贴操作的相应速度、执行完毕时间；
一次支持不同格式的文件同时操作；
支持大量文件同时复制粘贴；
登录界面测试用例设计
一、界面测试点：
1、界面的设计风格是否与UI的设计风格统一；
2、界面中的文字简洁易懂；
3、界面中没有错别字；
二、用户名与密码在输入时，要考虑：
1、正确的用户名与正确的密码；
2、正确的用户名与错误的密码；
3、错误的用户名与正确的密码；
4、错误的用户名与错误的密码；
5、空的用户名和空的密码；
6、正确的用户名和空的密码；
7、空的用户名和正确的密码；
8、用户名的前/中/后含有空格；
9、密码的前/中/后含有空格；
10、用户名与密码使用的字符范围及位数限制的测试（等价类及边界值，会用到强制的复制与粘贴来实现不允许输入的字符，以及一些保留字的测试）；
11、牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用；
三、安全性测试：
1、密码是否隐蔽显示；
3、不能直接输入，就copy，是否数据检验出错；
还要准确定位每一个输入框的功能，每一种错误情况下，出现的错误提示要准确或者合适。
四、兼容性测试：
1.不同浏览器测试
2.浏览器不同版本测试
五、其他测试点：
1、输入框之间考虑tab键是否支持；
2、登录按钮要考虑回车键是否支持；
3、取消后的默认位置（一般为空白的用户名输入框）；
4、登录后的跳转页面是否正确（一般为首页）；
5、要考虑多次点击登录和取消按钮的界面反应；
6、考虑是否支持多用户在同一机器上登录；
7、考虑一用户在多台机器上登录；
8、登录页面中的注册等链接是否正确