阅读 | Web测试囧事：一封邮件引发的血案

邮件发不出去了

最近，小蔡所在的项目由六位研发人员耗时5个月研发的手机版网站整体上线了，也就是说，这个项目开发的手机版网站是第一次被真实用户访问。

产品上线第二天，组内一位开发人员发现在测试环境中发送邮件会出现错误提示信息。发送邮件功能对这个房产网站非常重要，因为用户如果在网站上发现中意的房产，他需要通过电话或者邮件才能联系房产代理人。那就意味着如果邮件发送不出去，那整个业务流程就中断了。

小蔡作为组内的QA对此很疑惑。因为她确信没有漏测网站最基本的邮件发送功能。那这个Bug会不会只存在测试环境中，在产品环境反映是好的呢？通过验证，小蔡在产品环境上也重现了这个Bug！

那到底是什么原因导致邮件不能发送呢？研发人员很快定位了问题原因：发送邮件的URL最近被修改了，将HTTP改为HTTPS。研发人员通过最近代码库修改日志发现，这个修改是一周前由客户方（在另外一个城市）的技术负责人引入的此页面上的脚本造成，然后造成邮件不能发送。既然定位到了问题，研发人员快速修复了代码，及时部署到产品环境，邮件发送功能终于正常了。

对于这个Bug，大家可能会觉得是测试工作做得不到位，或者说代码被修改后，较长时间内没有做回归测试而引起的。听起来，责任在测试方！

其实不然，在敏捷团队，通常一个QA需要测试7～10个开发人员所开发的新功能，而这些新功能测试占据了QA大部分时间，只剩下一小部分时间用来做回归测试。况且，一个开发了近半年的产品，功能点会有很多，只依赖于QA每次做全面的回归测试基本上是不现实的，当然如果有一些自动化测试脚本来帮助QA做回归测试那确实有很大的帮助。

经过这次事件，小蔡更加明白老牛一直讲的预防Bug的重要性，那小蔡所在项目怎么做的呢？

（1）增加UI层的自动化测试

开发人员和测试人员结对给发送邮件功能增加了UI层的测试，也就是使用Selenium通过操控HTML界面元素的方式，模拟用户在页面上的点击和其他操作来实现自动化测试。那为什么之前没有给这个场景增加测试用例？参与过项目开发的人都有过这样的体验，对已有产品做修改的项目，由于产品已被用户使用此页面上的脚本造成，所以产品的质量和稳定性优先级很高，此时需要较好的自动化测试用例进行全面覆盖；而对一些全新产品，尤其在第一阶段，比起质量和稳定性，团队更关心用户的接受度和喜欢度，更希望能够快速实现关键用户使用场景并上线去获取用户反馈。因此，界面端的自动化测试在这个阶段上的优先级会降低一些。

（2）使用React.js框架

研发团队在项目中使用了React.js框架，它的单元测试框架可以测试界面元素的变动，因此单元测试可以涵盖一些之前只能在UI层自动化测试层才做的事情。例如React.js的单元测试可以判断页面某个CSS的改变状态，但有个问题是它更偏向于测试单个功能模块，缺少对页面上多个步骤的联调测试，而UI测试恰好可以弥补这个缺失（如测试类似发送邮件流程这样的场景是否正常）。

所以，研发团队在单元测试覆盖率上做到了大约80%，同时完善了UI层的自动化测试。这样，小蔡就被从枯燥乏味的机械性劳动中部分解放了出来，她再也不用为此拍着脑袋高呼“路漫漫其修远兮”了！

时区不一致造成邮件发送异常

小蔡一直对产品的后台系统测试比较感兴趣，但是自己并没有这方面的测试经验，所以一直不敢向老牛提出自己想去测试后台系统的想法。她虽然没有明说，但是老牛却看在眼里。刚巧最近产品新增了根据用户收藏的商品，定期向用户发送邮件的功能。老牛就指派小蔡去做新功能的测试，也借这个机会锻炼一下她。

小蔡首先根据自己的经验设计了正向测试用例。

1）在用户收藏商品之后，当达到指定条件，系统会向用户发送邮件。

2）她还设计了逆向测试用例，包括邮件系统本身出错时的一些场景，例如：

·用户取消收藏商品后，即使达到指定条件，用户也不会收到邮件；

·用户收藏了商品，但是没有达到指定条件，用户也不会收到邮件；

·当邮件系统在发送邮件时出错，已发送的邮件不会重复发送，未发送的邮件会再次尝试发送。

小蔡觉得自己这次设计的测试用例很全面，应该会得到老牛的表扬，就带着这些测试用例去找老牛确认。

老牛首先表扬了小蔡思考的全面性，也夸奖了她这段时间的成长。此外，他告诉小蔡还可以从邮件发送的机制本身考虑是否存在测试点：发送邮件的脚本会每天定时从数据库里找到需要在当天发送的数据，然后根据指定的邮件格式进行发送，并在发送结束后在数据库里进行标记。这里面是否会存在问题呢？

小蔡马上想到可以使用之前学到的5个Why的方式进行追根溯源。

·第1个Why：脚本是如何确定判断哪些数据是需要“当天”发送的呢？原来是通过脚本自身执行的时间以及数据库里数据的时间字段。

·第2个Why：脚本自身执行的时间和数据库里数据的时间字段都来自哪里呢？脚本执行的时间是根据执行脚本的服务器时间确定的，数据的时间字段是用户收藏时前台服务器存储到数据库的。

·第3个Why：这两个时间有可能不一致吗？之前听开发人员说，前台服务器为了确保各国用户的体验，使用的是世界标准时间UTC，但是不清楚执行脚本的服务器设置的是什么时区。

·第4个Why：在数据库里标记邮件已发送是以哪台服务器的时间做标准呢？之前数据库服务器为了配合前台程序设定的也是UTC。

·第5个Why：那会不会脚本运行的时间和数据库服务器的时间存在差别，从而导致邮件发送异常呢？

带着疑问，小蔡登录到执行邮件脚本的服务器，通过使用Linux的date命令，发现服务器使用的是中国标准时间CST（UTC + 8），和UTC可是差着8小时啊！

在脚本执行时，那些UTC～UTC + 8时间之内的数据都会被忽略，这些邮件用户当天接收不到，但是在数据库存储发送标记的时候，却会把这些数据标记成已发送，从而导致用户永远接收不到这些邮件。

小蔡马上把这一发现汇报给老牛，老牛很认可她的这一发现，并带着这个问题和开发人员以及项目经理进行协调，最后决定修改执行邮件脚本的服务器的时区设置。而为了避免以后出现类似问题，通用的服务器配置脚本里，也会增加对于时区的统一设置。

此外小蔡还了解到，有些国家和地区的时区有DST（Daylight Saving Time，也就是俗称的夏令时），而如果产品代码和某些特定时间相关，例如用户设置早上9点接收邮件报告等，就需要考虑到DST。还有如果某些国家或地区修改了自己的默认时区，比如时常变换时区的委内瑞拉，也是需要及时把修改后的时区反映到产品中的。

正面测试和负面测试

正向测试是按照功能描述，测试系统是否完成了相应的功能；而逆向测试是测试系统不应该执行不该完成的功能或者出现异常。通常来说正向测试的范围和用例是很好设计的，因为只要按照功能描述转换成测试用例就可以了，但是逆向测试需要测试人员结合自己的测试经验和测试理论，扩散出各种异常场景。同时逆向测试还需要关注各种提示信息，包括各种输入的限制条件和出错时的提示等。

通常进行逆向测试设计时我们会考虑以下方面。

1）特殊字符。尤其是单引号这种字符，有可能造成SQL注入。

2）必填项的验证。如果必填项不填写，是否能够成功提交，以及是否会出现错误提示。

3）字段类型的测试。例如针对日期格式，如果输入格式不正确程序如何处理；如果只能输入正整数，那么输入0、负数或者非常大的整数以及小数，程序如何

处理。

4）字段长度的测试。例如，限制输入100个字符，能否通过复制等手段输入超过100个字符。

5）边界值的测试。例如，只允许输入100以内的整数，那么输入99、100和101都应该出现什么现象，都需要测试。

6）对于提交等功能，如果快速点击是否会出现多次提交。

一般测试人员随着自己的经验增长，都会形成自己的一套测试方法，也就是这种使用逆向测试思维的检查列表。