明天就是微信抢票的ddl了，总算快熬出头了！
本次软工三大作业，自己花了不少于150小时，可以这是我耗时最多的一个大作业。其实原本我是不打算在一门课的大作业上面花那么多时间的，但是由于刘强老师对我们组期望比较高，群主大腿又实力超群，自己不能拖太多后腿，于是只能用时间去拼成果。最后的结果还算满意。提交的PR节省了全班许多人的宝贵的时间，1800的并发应该是全班最高了（并发提高过程详见群主博客），邮箱验证的安全性的确比info账号密码高很多，功能测试最终也达到了很高的覆盖率（adminpage/views:90%，userpage/views:100%， wechat/handlers:97%）。
根据课程要求，总结主要收获如下：
- 框架
- 体会到了一个好的框架有多么重要
- 体会到在一个别人开发的有不少bug的框架下调试有多闹心
- 功能测试
- 学习了selenium，包括phantomjs、expected_conditions、WebDriverWait、By，Keys等。
- 学习了Django的LiveServerTestCase进行功能测试。
- 了解功能测试和单元测试的联系和区别，学习了mock和fixture的运用
- 了解了测试覆盖率
- 团队协作
- 性能优化
- 了解JMeter的运用
- Linux系统参数
- uWsgi参数
- nginx参数
- mysql参数
- 尝试了Docker部署
- 尝试了搭建二维码服务器
- 尝试了使用celery实现异步定时任务
不过，在这次作业中让我感到很遗憾的是我有三个预期的功能没有实现。
第一个没有实现的功能是搭建二维码服务器。最初，我们想的是为了使用户能在不点进电子票详情页的情况下检票，因此需要将电子票二维码显示在我的电子票列表中。这就需要一个一个二维码的url，我总共想了4种方法。
- 最简单的就是利用python的相关库如PyQRCode（此处手动感谢王永赫同学），直接生成一张图保存在抢票服务器上，并返回该图片的链接。但是这会导致服务器里存储大量的二维码图片，对内存消耗较大。因此我并没有去实现这种做法。
- 另一个是采用现有的二维码服务器，如清华大学图书馆采用的二维码服务器。这样只需要将需要电子票的unique_id使用get方法的参数传过去便能获得一张二维码图片。但是这样会导致电子票的unique_id泄露，不安全，因此我们也没有使用这种方法。（此处手动感谢群主）
- 第三种方法是使用dataurl，这样能解决上诉两个方法存在的所有问题，可是，悲伤的消息是微信不支持dataurl，于是只能放弃。
- 最后一种方法是自己搭建一个二维码服务器。该二维码服务器收到get请求时根据参数返回一张二维码图片。我们采用的正是这种方法。经过遴选，我最后决定使用PHP Qr Code。可是，由于对nginx和apache都很不熟悉，配置apache的过程中我遇到了很多问题。最后的结果是我花了一天的时间还是没有配好，由于时间紧张就放弃了这项功能。
这次失败给我的教训是配环境时尽可能一步一步的来，每一步都最好能确认确实配置成功了在进行下一项配置，否则最后出现了问题也不知道具体哪一步错了，就很耽误时间了。
第二个没有实现的是docker部署。由于助教给的ppt中讲得比较简略，其中还不少拼写错误，因此我在按照助教给的ppt中的教程一步一步往下配置的过程中遇见了很多问题。折腾了一天之后决定先自己好好学习一下docker在进行部署，于是第二天自己看了一遍docker的教程并重新开始配置。这一次，我解决了前一天没有解决的许多问题，当然也遇到了很多新的问题，最后卡在了mysql密码错误无法登陆，无论我们设置MYSQL_ROOT_PASSWORD也好，设置USER_PASSWORD也罢，甚至进入进入容器内尝试各种密码，最终都无法登陆mysql。为此我和群主连续两天调到深夜，还是没有解决。最后由于时间紧张不得不放弃使用docker部署。（此处手动感谢璠神在我配置docker过程中给予的帮助，感谢群主坚持到深夜仍不放弃我和我的bug）
这次失败让我明白一个靠谱的教程有多么重要。当然，自己轻视docker配置的难度，在不了解docker的情况下草草动工，以至于浪费了较多时间，这才是这次失败的主要原因。
第三个没有实现的功能是抢票前30分钟提醒用户功能。抢票提醒是一个异步任务，我采用了celery来实现。最终由于在测试过程中微信的access_token调用次数达到上限而无法继续调试。比较不合理的是access_token的有效时间是两小时，每天可调用的次数是两千次，因此按理说不可能不够用。最终发现框架果然实现得有问题，于是我修改了框架并提交了PR。但是，这时已经到星期三晚上了，第二天就得展示，虽然功能已经实现但是还有bug，我只能选择放弃该抢票提醒功能。
这次失败，可以说主要原因是因为我的调试方法不太好，应该先测试异步任务，确保其实现正确后再测试完整的功能，导致测试效率较低，甚至触发access_token上限。当然，由此发现了框架中的bug也算一点补偿吧。
当然，使用selenium进行自动化测试的过程中我们也遇到了一些问题，这里做一个简略的记录。
| 遇到的问题 | 解决方案 |
| 测试过程中无法直观的看到效果。 |
输出截图：self.browser.get_screenshot_as_file("pic.png")
|
| phantomjs默认分辨率太低，导致部分按钮被响应式布局藏起来。 |
设置浏览器分辨率：self.browser.set_window_size(1024, 768) |
| 页面跳转需要时间，不能立即响应 |
使用WebDriverWait和expected_conditions |
| send_keys只能在文本框的原有文本后添加keys |
send_keys之前先调用clear清楚文本框中的当前内容 |
| 文本框会有回调函数，导致每次修改文本框内容之后都不能立刻见效 |
每次修改文本框内容之后都调用sleep |
| 不同测试函数之间存在数据干扰 |
在测试函数开始之间删除可能会产生干扰的数据并重新生成一遍所需数据 |
| 在测试与微信交互的过程中，从xml中解析出来的url和测试环境中的url不一致 |
将解析出来的url中的相关参数解析出来，并结合self.live_server_url手动生成正确的url |
最后，在这次项目开发过程中，像群主学习到了很多，在此表示感谢。