【编者按】软件测试是软件产品开发过程中质量控制的重要一环。本文作者刘丽晶，系未名信息技术公司的软件测试主管，曾在中软件国际、招商局国际等大公司担任软件测试工作有五年之久，积累了丰富的专业知识与技能，现将多年从事软件测试工作的实践与体会，陆续汇总出《刘丽晶谈软件测试》的系列文章。

今天发表了第二篇文章《软件测试之我知--“刘丽晶谈软件测试”系列文章之二》，邓宗煌总经理说：“原本写给测试新人学习的基础知识。但是，小刘总结的实战内容（特别是其中的一些实际案例）对于开发人员和需求人员来时，也会有所启发的。”

《刘丽晶谈软件测试”系列文章之三》，也将于近期发布，相信也会很精彩，敬请期待。

软件测试之我知（基础篇）

--“刘丽晶谈软件测试”系列文章之二

 

从初入职场到现在，一晃过去了6个年头。这些年我主要从事软件测试的工作，逐步加深了对软件测试的认识和理解。在此，总结我多年从事软件测试工作的心得体会，梳理出我对软件测试的认知和大家共同交流、探讨。

百度一下“软件测试目的”，搜索出来的结果是：软件测试的真正意义在于发现错误，而不在于验证软件是正确的。

我认为初入职场的测试新人，需要培养具备：

一、耐心、细心，耐得住寂寞。

很多人觉得软件测试是枯燥的、重复操作的一项工作。于是乎，在招聘测试岗位时，都会要求具有耐心、细心、责任心。我个人觉得测试是一项细活，不是所有的bug都存在于表面，只有深入测试，才能发现深层次的bug。当你找到一个深层次的bug，发现了其他人未发现的问题，就会觉得蛮有成就感的，就不会觉得测试工作是枯燥的。培养起对软件测试的兴趣和敏感度，你就会觉得软件测试其实还蛮有意思的。

二、怀疑的精神，勿存侥幸心理。

测试每一个模块，都要以怀疑的眼光去看待，才能挖掘出更多的问题。切勿抱有侥幸心理，觉得这个模块应该没有问题。我曾经在测试一个功能点时，由于以前测过几次没出现过问题，然后新版本过来就抱着不用测、肯定没问题的心态，当就要放弃测该功能点时，心里开始嘀咕，要不还是过一下保险，结果一测真测出了问题。当时就很庆幸还好测了，不然该版本部署到生产环境上影响就大了，从此不敢存侥幸心态。

三、坚持的精神。

对于偶然出现（或偶尔一次）的bug，一定要坚持找出原因，可以找开发人员帮忙查看日志来分析重现路径。有时发现不确认的缺陷，开发人员很多时候会说“这种情况不可能发生”来回复你，这个时候我们应该做到能够说服开发人员：其实不是这样的，任何一种缺陷的产生，都有可能影响到客户的体验效果。

四、善于沟通。

与项目团队建立顺畅良好的沟通氛围。遇到问题及时找需求、开发等多方确认，最好是需求、开发、测试一起面对面确认，有利于问题的快速、合理解决。在我自己的测试经历中，测试很多时候充当着需求与开发间的沟通桥梁。通常开发与需求在项目前期较少深入沟通的，只有版本转测试后，测试人员发现需求文档的描述与开发人员的实现存在出入。于是测试人员会去找需求先确认，然后确认是开发问题时找开发说明，当开发觉得自己的实现方式没有错，这个时候就要把需求和开发都叫一起当面确认。

五、难点问题及时上报。

发现自己解决不了的问题时，记得一定要及时上报，不要把问题累积在自己身上永远得不到解决，还总有压力。比如：当你发现一个问题，开发人员觉得不是问题，而你就是觉得是问题，这个时候就不要自己纠结要怎么办，到底是顺应开发，还是坚持自己的观点。把这种问题上报给你的上级，由你的上级与开发的上级进行讨论确认，总会有解决的方法。

接下来，我来谈谈软件测试的一些方法供测试新人参考。

关于测试方法，百度一下，又会出现非常多的答案。这里列出几个常用的方法，对于大多数项目只要运用这些基本方法就可以完成功能测试（用例设计同样适用）。当具有了一定的测试经验之后，你就可以逐步掌握其他的测试方法。

⑴　等价类划分测试：

把测试的场景划分为有效等价类和无效等价类，在有效等价类中选择一些代表性的数据作为正确路径的测试输入数据，在无效等价类中同样选择一些代表性的数据作为异常路径的测试输入数据。因为测试不可能使用无限穷举的方式来测试。

⑵　边界值测试：

测试极端的数据，输入某个字段规定范围内的最大值和最小值，以及超出范围的临近值。例如：数据库定义A字段的允许输入长度为10，这个时候就要输入最大的10或11个长度的字符进行保存，和最小的1和空值进行保存验证。

⑶　错误推断法测试：

输入字段定义不允许的类型进行测试。例如字段A定义只允许输入数值。这个时候就要输入非数值类型作为测试的输入条件，如字母、汉字、特殊字符等非数值类型。又如，字段B定义仅允许输入正整数，这个时候就要输入除上述的非数值类型外，还需要测试负数、0、小数的路径。

了解了以上的一些基本测试方式之后，对于测试新人该如何开始测试呢？

⑴　初验、流程测试：

当开发发布一个新版本到测试部，首先需要对整个流程进行简单验证，即初验。验证主要流程功能是否存在阻塞性问题，若存在，则打回给开发人员，不允许转测试。

⑵　功能测试：

流程初验通过后，开始具体的功能测试，根据需求文档或测试用例开始详细测试。软件测试有一个二八原则，就是80%的bug出现在20%的模块中，故当测试的模块问题较多时，说明模块比较脆弱，就要多放心力去测。

⑶　回归测试：

功能测试结束后，开发修改bug，会发布回归测试版本。这个时候除了验证之前提的bug外，还需要留心修改bug外其他的关联模块，往往开发人员只修复测试人员提交的bug中描述的问题，而没有考虑别的功能在修改时可能会重新造成缺陷。例如：在司机宝中，提交一个bug是关于货源搜索，查询出来的结果不正确，这时开发人员修复了此bug。但是当进去货源详细页面，然后再返回，结果发现列表中的数据又不正确了，已经不是之前查询出来的那些信息了。这种情况，目前发生的几率蛮高的。

⑷   重复测试：

对于同一个功能点，需要重复测试几遍，有时开发出来的功能具有假象，第一次使用OK，再次使用就出现问题。例如司机宝中，当应用在新设备中第一次登录时，需要短信验证，第一次测试发现功能实现了，然后退出再次登录，结果发现怎么还是提示需要短信验证，这个时候就不正确了，同样一个设备多次登录是不需要每次都验证的。

⑸　关联模块测试：

模块与模块之前的连接，是很容易发现缺陷的地方。以货运枢纽为例，有一个停车场管理组件和一个停车位管理组件，在停车场管理中新增一个停车场区域A，然后在车位管理组件中引用A来创建几个停车位A1，A2，A3。这个时候删除停车场A，停车场区域A直接被删除成功了，然后去停车位管理组件上查询，结果问题出现了，A1关联的停车场区域字段内容显示一串乱码（停车场区域没有了，但停车位还在，这些已经成无效的垃圾数据了）。原来是开发人员没有对这两个模块之间做校验，当需要删除停车区域时，需要判断这个区域是否已经被引用，如被引用则需要提示给用户该停车场区域已被引用不允许删除，或者给予提示删除后关联的停车位也会相应删除。这个就要根据实际的需求来定了。

⑹　兼容性测试：

一个应用软件，需要测试在不同环境中的适用情况。例如售货机web服务端，只能适用google和火狐浏览器，在IE9、10上是无法正常使用的，这个时候就要测试浏览器的兼容性，对于兼容和不兼容的主流浏览器要列出来，后续在用户操作手册上就需要注明推荐在哪些浏览器上使用，以免用户在不兼容的浏览器上使用发现问题，形成不好的用户体验，从而产生客诉，影响客户的满意度。

⑺　易用性测试：

站在用户的角度，测试功能是否可简单易用。如司机宝，用户体验发现当新注册一个用户登录司机宝，点击“求货”时给予提示“请先绑定车辆”，提示信息又比较靠手机底部显示，不易看清楚。没有看清，就得多次点击“求货”，然后用户才晃过神来意识到是要先绑定车辆，于是才去点击“绑定车辆”的按钮。这样的操作流程用户会觉得很繁琐，费时费神，于是我们果断向需求人员提出，更改为新用户登录，点击“求货”，直接跳转到“绑定车辆”页面，车辆绑定后又直接跳转到求货页面，这个时候就容易理解，易于操作很多了。

⑻　美观性测试：

页面上排版布局不恰当等问题。这方面的问题，测试人员都可以提出改进的建议。如物流管家web服务端，列表的字段标题与字段内容错位，没有对其排列等等。

⑼　测试记录跟踪：

每天测试完成后要做好当天的测试小结，是否有遗留问题，方便第二天或下个版本再跟踪测试。

⑽　缺陷跟踪：

当我们在测试过程中，发现bug，首先需要确认bug，即重现bug。然后在缺陷跟踪系统上提交此bug，一个好的bug描述应满足：

①bug标题：应遵循简明扼要，写出问题的重点，标题不宜过长，如“某某页面，列表缺少字段A，字段B，字段C，字段D……Z”，这样穷举列表所有缺少字段的标题就显示冗余，可以描述为：“某某页面，列表缺少A等字段”，然后再详细描述中写出所有字段，这样开发一看到标题就知道是缺少字段的问题；另外标题也不宜过于简单粗略，如“某某页面，查询问题”，这样的bug描述开发人员无法直接看出bug的本质问题。

②bug描述：在描述中，语言要表达准确、无歧义。对于复杂的bug，需要详细写出bug的重现步骤，以便开发人员可以快速的重现定位问题。描述中也需要包含测试的预期结果。

③测试环境：需要描述清楚当前的测试版本，使用的具体环境。

④版本号：每一个开发转测试的版本，需要开发提供一个版本号，在bug中注明此bug出现的版本号。

⑤截图：保留当时的数据，截图上传到bug中，方便开发查阅。

软件测试只是保证软件质量的一个手段，只是尽可能减少软件风险的一个措施，并不能完全控制软件质量。所以，我们只有在项目周期的各个环节中不断的总结经验，不断的改善流程，防范于未然才能开发出满足用户需求的好产品。

最后，我要特别说明一下，本文主要是写给测试新人的测试总结（基础篇），我想到哪就写到哪，可能会有不少的遗漏，敬请大家谅解。对于存在的不足或有遗漏的地方，将来有机会我再给大家写一篇《软件测试之我知（提高篇）》，届时再补充、再完善。