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

今天发表了第一篇文章《软件测试之我见--“刘丽晶谈软件测试”系列文章之一》，邓宗煌总经理评价说：“刘丽晶的实战'干货'，很有专业价值，给更多的同事、同行分享，不仅对于我们软件测试的新人，有很好的指导意义，而且对于软件开发人员，也有重要参考价值。”

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

 

软件测试之我见

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

 

最近五年来，我一直在中软国际、招商国际等大公司从事软件测试的工作，对于软件测试工作有很多的体会与感悟。现从软件测试的角度，来总结开发人员在程序开发过程中较易出现的一些缺陷和大家分享，希望对于提高软件开发的效率与质量有所帮助。主要有几点：

①    程序中的拼写错误。

这类错误与开发人员的编程习惯有关，有时候一个单词在键盘上敲打快了就会发生此现象。

② 修复一个缺陷引发更多缺陷。

很多时候开发人员只对针对测试人员提交的bug中的描述进行修复，而此修改往往会连带影响其他模块的正常功能，可开发人员却没有考虑进去。例如司机宝，当开发人员在修改新用户绑定车辆问题，实现绑定成功后直接跳转到求货页面。但认真查看下会发现车辆绑定页面上的“绑定车辆”按钮，什么时候已经变成显示“求货”，另外在点击“切换/绑定车辆”弹出的菜单的“添加”按钮也显示为“求货”。

③    字段类型的校验。

在页面上对于有些特定的字段，应校验字段允许输入的类型。例如电话号码字段，应该定义为数值型，不应该允许输入汉字、字母或特殊字符。

④    字段长度的校验。

在页面上应该控制字段，允许输入的长度应小于等于数据库中该字段定义的长度。目前字段长度的校验在多个项目的很多页面上均没有控制，导致当有意输入超长的字符长度，保存提交时就会直接显示一连串的异常。

⑤    关联模块的校验。

存在数据引用或有数据传递的模块，有时开发人员会忽略此部分的数据校验。如司机宝，当用户绑定车辆后，通过求货接口发布了一条运力，这个时候用户操作取消绑定车辆，解绑成功后，车辆关联的求货信息却依然显示在页面上。预期应是解绑车辆成功的同时，把车辆关联的求货信息也一并删除。

⑥    便捷性。

如当打开一个登录窗口，光标自动定位到用户输入框，这样就给用户带来很好的体验，用户只要直接输入用户名即可，不需要用鼠标再去定位。此处特别要留心当用户输入的用户名或密码不正确时，光标是否会自动定位到相应的输入框中。又如web页面上的按钮，可以适当的增加一些快捷键，特别是当用户在一个模块中重复操作时，快捷键会带来很多的便利性，节省了很多时间，那些操作熟练的用户，绝对是操作键盘多于用鼠标。就像我们平常在电脑上想要直接切换到桌面，往往都是直接使用Window+D的快捷键，而比较少在任务栏上使用鼠标右键，弹出菜单然后选择“显示桌面”，整个操作下来步骤繁琐了很多。

⑦    重视自测。

当一个版本转测试后，测试人员才开始测试就发现严重阻塞流程的bug，或者打开页面就报错。这种缺陷要尽可能在开发自测过程中发现并解决，避免因为这样的缺陷，导致测试计划的推延。如司机宝，登陆后，点击“求货”，进入求货页面，输入出发地、目的地、有效期后，点击“确认发布运力”提示求货失败，这种重点模块的核心功能缺陷是不应该在测试时才被发现。

⑧    交流与沟通。

当开发人员拿到需求文档，直接根据需求文档上功能描述进行开发，遇到不太清楚的地方，没有及时提出来交流。于是转测试后，测试人员在测试该部分功能时就会觉得需求描述与开发实现不符，会导致返工率非常高，而开发的代价也非常大，需要重复的修复。其实只要碰到疑点，果断找需求沟通确认清楚，然后再开发，省心又省力，同时也大大降低了bug的Reopen率。当开发、测试、需求三方在沟通交流中意见一致时，整个团队会形成很强的战斗力，大家都可以少走很多弯路，同时也可以互相间学到很多东西。以前经常听到在软件项目中，开发与测试是死对头，互相间水火不容。个人觉得其实不然，开发与测试应成为好朋友，大家都是为了同一个目标，积极努力提高软件质量，以达成预期的成果。

针对上述经常出现的开发缺陷，我提出项目管理流程上的改进建议：

①  制定项目计划。

这个面有点广，建议可以先从制定版本计划开始，每一个项目，每次发布一个版本都应有一个版本计划。需求、开发、测试、运维、实施等各环节都能准确了解各自的工作分工与时间点，以方便安排各自的详细任务。

②  制定版本号。

每一个项目，每一个阶段，都应有可追溯的版本号，方便跟踪版本进度。目前除了物流管家项目的司机宝有版本号外，物流管家的其他模块和其他项目均没有版本号这一说法。这种现象会导致测试提交的问题，当开发人员修复完成后发布到测试，我们比较难整理出来哪些bug是在开发发布的版本中解决的。而且在后台的统计图表上，也很难统计出每个阶段的数据。建议每个主流项目都应建立版本号。

③  重要问题习惯于邮件沟通。

与项目相关的所有人都应养成通过发邮件的方式来跟踪版本情况的工作习惯。如需求确认、开发发布新版本等节点。到目前为止，大家还没有养成这个习惯，每次都是直接喊一下或者在qq上说明，当过一段时间要翻出记录来看时，就会比较麻烦些或就是找不到了。建议重要问题必须通过邮件来传递，然后可以在qq上提醒一下查收邮件。

④  开发环境与测试环境独立。

由于目前很多项目都是开发与测试共用一套环境，近两月的测试中经常能够遇到，突然间无预警的好好的功能就不能正常操作使用了，询问一下开发人员才获知他们在服务端改了代码（或者他们重启服务）等，因为我们在测试的过程中，开发人员也一样用这个环境在修复bug。这样真的很容易导致一些不可预测的问题，同时测试人员也困惑，心里没谱，无法保证测试过的功能是否还完好可用。（PS：2014-7-3，物流管家项目已实现测试环境与开发环境独立）

⑤  重视测试成果。

当测试人员还在测试某一个版本时，只有当该版本结束测试，且符合发布条件（一、二级bug均已解决）才能发布到正式环境供用户体验，以免出现低级错误，影响用户的体验好感度。