测试经验总结

本人做过两年的软件测试。现总结这两年的工作经验并分享给大家。希望对于想进入软件行业的朋友有所帮助。

如果您对本文档不满意，希望批评指正；本文档是随笔所写,没有顺序可言。；

本文档适合想进入软件测试行业的朋友，或进入软件行业时间不长的朋友，

如果您是多年的软件高级测试员或软件开发人员，则没有必要看这个文档（免得浪费您的时候，到最后看完没觉得有什么帮助，然后…狂骂）。

本文档是个人总结，难免有所错误，如发现错误，希望发邮件（laibayiqifengdou@163.com）指正。集体的智慧永远都是无穷的.

一．心态

软件测试员，首先要心态好。什么叫心态好。就是你要有耐心，有细心，有责任心。 不要三天打鱼两天晒网的。

经验是日常点点滴滴积累的。这是句实话，也是句屁话。时不时的想想这句所谓的屁话，你会受益匪浅的；

既然选择了，那就坚持。

但是：如果你有机会成为国家的人，那我就要告诉你的是：干什么软件测试啊，傻啊，哪有国家公务员爽呢，公务员是一辈子的。打工做测试哪年是个头啊。打工只是没有办法的办法，仅此而已！幻想着想创业，阿弥陀佛。哥们，现实点吧。那都是骗人的。就那么几个人成功了而已，而且社会环境也变了。不好混啊。

软件测试刚开始你会学一些东西，等到了一定阶段的时候，你会发现自己学的东西越来越少,工作总是重复（黑盒测试这种情况居多）。

二．要命的细节

做软件测试员，心细是肯定要有的，不然你就无法升级到高级软件测试员，无法拿更高的工资；

任何bug都是从点点滴滴的细节中发现的。特别是一些不容易发现的bug。

比如：

记得当时我测试一个软件的时候，在测试的过程中，突然发现软件居然变得很迟缓（就是软件反应速度慢），重新启动软件后，还是很迟缓，只有刚开机测试的时候，软件响应速度快，后来在测试的过程中发现，在重复登陆软件的时候，相应的进程并没有关闭，登陆次数越多，相应进程也就越多，可用内存越来越少，导致软件越来越慢。这就是我认为的细节之一；

我这么说不是让大家在测试软件的时候，没事就看进程。我只是说：在测试的过程中如发现软件突然出现异常情况，抓住这个细节，然后一点一点的分析，在什么样操作下出现的这个问题；一旦能够复现这个问题，那么及时的做好文档并与开发进行沟通；

再比如：上一版本的程序，某模块的功能是正常的，下个版本这个模块的功能却出现了bug。（这是很正常的），因为软件中关联的东西很多。开发人员改动了软件，可能影响到了相关联功能，导致新的bug出现；

再比如：几个相关软件进行测试的时候，有的时候软件之间是有影响的，即：如果出现bug的话，很难测试出来；必须一步一步的细心耐心的测试；当时我在测试两个想关联

的软件的时候，发现数据库中的某个表的字段数据突然不对了。当时我只是单独的去测试这个两个软件，没有把两个软件关联起来测试,怎么测试都没测试出来，后来我整理下思路发现，可能是第二个软件影响了第一个软件得数据。后来经过多次的验证，2确实如我所想的那样。所以细心是根本;你比别人细心那么你就有可能会比别人走的更远;

三．理论

软件测试理论没多少东西。买本书花一星期或者几天你就能搞定；什么黑盒测试。白盒测试。灰盒测试；功能测试，性能测试。有什么样的测试方法了，如何进行测试了。测试的目的等等；这些都很简单，面试的时候，肯定会问到，所以掌握软件基础知识，是灰常必要的。不然你都没法忽悠；工资的高低有的时候就靠你的忽悠能力。如果面试官懂软件测试，那么你就要注意了。你要把你确定100%的东西要肯定的回答，然后再加上自己的理解，然后开始忽悠。

四．软件测试的目的

如果有人问你：软件测试的目的是什么？如果你说:就是为了测试软件的bug，测试软件存在多少个bug。那么你要倒霉了。

软件测试的目的并不是测试软件的bug数量。而是测试软件是否能够满足客户的需要；切记这点。

本人认为：没有bug的软件是不存在的（客观也是如此）。只要软件的功能能够得到客户的认可，就ok

五．动手能力

没有很好的动手能力是不行的。测试软件的时候，不要怕把软件弄坏。大胆的干吧。但是也不能随便的没有目的的进行测试。测试软件都是有目的的。你要明白要测试的这部分功能是什么，相关联的功能是什么。然后想想如何进行测试，然后开始测试；

六．文档

在测试的过程中如果公司有bug管理工具，那么就可以省了不少文档。

测试的需要很多文档：测试用例，测试结果文档，测试总结文档等等；

七．描述bug

描述bug一定要把每一步详细操作都要说明，然后再说明在哪一步出现的bug，最好有截图。当然了如果需要，你要写好软件的版本，和你电脑的环境（什么系统）

在不同的操作系统下，bug不一定都能出现；也就是说：操作系统会影响到测试的结果。一定要按照客户的环境来进行测试；这样可靠;

八．思路

测试的时候，要明白整体的测试流程。思路要清晰。如果思路不清晰的话，软件的很多bug你根本测试不出来，这也就是为什么客户现场出现的bug，测试部为什么测试不出来的原因之一。测试部的人有的时候不是站在客户的立场上进行测试的，这一点很要命；

九．测试特殊业务

如果是给银行项目测试的话，你要规范你的测试文档。比如：文档行间距，字体大小,文档说明.错别字等等。因为银行的人不懂业务，他们就懂得看文档，对文档要求特别的高。谁让人家是客户呢，客户就是上帝。

十．没事翻翻测试书籍，在网上查查测试资料。时不时的总结下自己的测试经验。跟同事，

同行交流测试经验，这样进步更快，就好比：和尚坐火箭，突飞猛进

十一． 好的测试员，肯定是要学会用loadrunner，QTP这些测试工具的。这些工具是测试

项目的时候用的。这些工具很重要的，想学习这些工具,则在百度上下载个破解 版的。没事学习下。其实也没那么难。一个星期基本操作完全可以搞定。深入的功能需要日常慢慢积累。将来的工资跟会不会这些工具有很大关系；

十二． 数据库要求

做测试员的话，对数据库的CRUD（创建，查询，更新，删除操作的sql脚本）也得会，这是最基本的了。没什么难的。灰常的easy。心态，要注意你的心态。渺视测试这个工作吧。没什么的难度的。不要因为一次的失误而灰心，完全没那个必要。这次的失误仅仅是为了下次成功做的准备而已。没什么大不了的。如果你在一个地方跌倒多次，要么说明你不够心细，要么就说明你倒霉，前者居多；

十三． 沟通

说了半天了。团队中灰常重要的一个概念就是沟通。跟同事的沟通，跟领导的沟通。 为什么要够沟通？在通常情况下，测试风险很小。但是如果是软件有关金额的模块让你来测试。你 必须做好跟研发沟通的准备，比如软件最后计算出的金额与你多次计算的金额不等（哪怕是几块钱，几毛钱，几分钱都要当回事。因为软件用的越多。这些差额就越大），你确定是软件计算错误的情况下。那么你一定要与研发人员进行沟通。如果研发认为不是bug，那么你要及时的与你的上级沟通。这种情况很常见；只有让你的领导知道了这个事情了。领导会去与研发再次沟通。如果客户现场真的出现因为软件计算错误，造成了损失，也没你的责任；经理就替你扛了(一般情况下,特殊另算,呵呵)。前提是你必须让替你扛事的人知道是什么问题。否则搞不好要扣你钱的，不要吃这哑巴亏;

也就这么点经验了,在写露馅了.虽然有点扯淡,基本上都是我经历过的.让后来的测试人员少走一些弯路.

以后我会陆续的，更细致的总结自己的测试经验的.你也可以提供更好的经验,咱们共享下,我会不断地努力的.目前本人干的是开发，我也会把开发的经验分享给大家，如果有赞助的哥们，也可跟我联系。10块20块，不嫌少，感觉有点像要饭的。呵呵。玩笑而已！大家出来混都不容易。如果真有那我就不客气了.呵呵。文件中的邮箱联系（laibayiqifengdou@163.com）；

想结婚却没房的木子海涛 20xx-08-13

 

第二篇：软件测试总结

软件缺陷即计算机系统或程序中存在的任何一种破坏正常运行能力的问题、错误或者隐藏的功能缺陷、瑕疵。

软件测试的目的包括以下三点：

(1) 测试是程序的执行过程，目的在于发现错误，不能证明程序的正确性，仅限于处理有限种的情况。

(2) 检查系统是否满足需求，这也是测试的期望目标。

(3) 一个好的测试用例在于发现还未曾发现的错误；成功的测试是发现了错误的测试。 软件测试的原则：

1.尽早地和不断地进行软件测试

2.测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。

3.程序员应避免检查自己的程序。

4.在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

5. 测试中的群集现象。

6. 严格执行测试计划

7. 对每一个测试结果做全面检查。这是一条最明显的原则，但常常被忽视。

8. 保存测试计划，测试用例，出错统计和最终分析报告

软件测试按照是否执行被测软件的角度分为静态测试和动态测试，动态测试又分为黑盒测试和白盒测试

按照软件测试的策略和过程分类，软件测试可分为单元测试，集成测试,确认测试,系统测试和验收测试.

软件测试阶段的输入信息包括两类：

软件配置：指测试对象。通常包括需求说明书、设计说明书和被测试的源程序等；

测试配置：通常包括测试计划、测试步骤、测试用例以及具体实施测试的测试程序、测试工具等。

单元测试是对软件基本组成单元进行的测试。单元测试的对象是模块。

单元测试的主要内容有：模块接口测试；局部数据结构测试；独立路径测试；错误处理测试；

边界条件测试。

辅助模块可分为两种：

(1) 驱动模块（driver）：相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块，最后输出实测结果。

(2) 桩模块（stub）：用以代替被测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。

集成测试的定义是根据实际情况对程序模块采用适当的集成测试策略组装起来，对系统的接口以及集成后的功能进行正确校验的测试工作。

集成测试三个层次：模块内集成测试；子系统内集成测试；子系统间集成测试。 确认测试是检验所开发的软件是否能按用户提出的要求运行。（合格性测试）

系统测试是将已经集成好的软件系统，作为整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。

系统测试的流程：制定测试计划、设计测试用例、执行系统测试、缺陷管理与改错

验收测试是软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动，是技术测试的最后一个阶段，通过了验收测试，产品正式进入发布阶段。

黑盒测试的具体技术方法主要包括边界值分析法、等价类划分法、比较测试法、因果图法、决策表法等。

白盒测试是基于被测程序的源代码设计测试用例的测试方法。常见的白盒测试方法有逻辑覆盖测试和路径分析测试两大类。

在逻辑覆盖测试中，按照覆盖策略由弱到强的严格程度，介绍了语句覆盖、判断覆盖、条件覆盖、判断/条件覆盖、条件组合覆盖和路径覆盖六种覆盖测策略。

? 语句覆盖：每个语句至少执行一次。

? 判定覆盖：在语句覆盖的基础上，每个判定的每个分支至少执行一次。

? 条件覆盖：在语句覆盖的基础上，使每个判定表达式的每个条件都取到各种可能的

结果。

? 判定/条件覆盖：即判定覆盖和条件覆盖的交集。

? 条件组合覆盖：每个判定表达式中条件的各种可能组合都至少出现一次。

? 路径覆盖：每条可能的路径都至少执行一次，若图中有环，则每个环至少经过一次。 在路径分析测试中，介绍了独立路径测试和Z路径覆盖测试两种常用方法。

? 独立路径测试方法把覆盖的路径数压缩到一定限度内，程序中的循环体最多只执行

一次，对程序中所有独立路径进行测试。它是在程序控制流图的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，设计测试用例的方法。设计出的测试用例要保证程序的每一个可执行语句至少要执行一次。

? Z路径覆盖测试是指采用简化循环的方法进行路径覆盖测试。被测源程序中的循环

体执行零次或一次。

测试用例（Test Case）是为了高效率地发现软件缺陷而精心设计的少量测试数据。

自动化测试就是希望通过自动化测试工具或其他手段，按照测试工程师的预定计划进行自动地测试，目的是减轻手工测试的工作量，从而达到提高软件质量的目的。

CMM（Capability Maturity Model）即软件能力成熟度模型,划分为5个等级:初始级 可重复级 已定义级 已管理级 优化级