持续集成实验个人总结

在测试公众号平台上做完最后一个功能测试后，为期十天的作业终于告一段落了。

在小学期的django实验中，我对前端网页、后端逻辑、数据库操作有了一定的认识，这次实验做起来不至于太蒙。事实上，由于是在写好的框架下进行开发，只需要完成各个接口，编程相对容易一些。最大的收获是对github、travisCI的使用经验，现在总算是成为一个合格的github使用者了。对于一个需要长期迭代的项目，自动测试几乎是必不可少的，但编写测试脚本的工作就够繁重的了。 另外，管理项目进度，监督自动测试流程，也让我第一次有了一种“做一个项目”的感觉，这对大作业项目也是莫大的助力。
这次实验中遇到的主要问题如下：

1. 微信接口
   第一次在微信平台上进行开发，试着弄清楚后台的逻辑着实费了不少时间，结合开发指南逐一解决。主要原因是不熟悉微信的收发和XML格式的解析。
2. 测试
   一开始在时区上很是迷惑，使用Asia/Shanghai后会有8小时的差距，遂决定全部采用UTC时间。 handlers部分的测试是最后完成的，模拟post时加上了signature和openid，以及时间戳。第10个api需要调用微信的接口，在travis上的测试很麻烦，遂放弃自动测试，改为本地测试。测试代码有很多重复，写起来十分顺手，而且借助前后端接口文档，我们可以很容易的地提前写出测试脚本，做到测试驱动编程，可见细致化、接口化需求的重要性。
3. MySQL
   django对于MySQL的封装很方便，但是这次项目中用到的表项和传来的参数不一致，转换写起来很烦，另外我用过Activity(**dict).save()方式实现了映射字典建立数据库项。
4. 锁
   我们使用类似于信号量的概念测试了数据库加锁，避免高并发下数据库remain_ticket的错误，但是和已有的代码起了冲突，最终只得放弃，具体可见w_branch。 后来发现这些已经被django实现了，改用使用with transaction.atomic()解决抢票并发。
5. 性能测试
   使用Jmeter分别模拟了100，200，400，500个用户发送抢票请求，确定最高并发在350-400之间（未检验数据库访问的正确性），更高的话会造成500错误。借用了wechat/test.py中的XML报文：

<xml>
    <ToUserName><![CDATA[toUser]]></ToUserName>
    <FromUserName><![CDATA[0247]]></FromUserName>
    <CreateTime>1540012625</CreateTime>
    <MsgType>text</MsgType>
    <MsgId>1293081923923912</MsgId>
    <Content><![CDATA[抢票 %s]]></Content>
</xml>

（突然发现自己主要的感悟都是在编写测试中实现的，测试代码编写起来的工作量一点也不逊色于工作代码......）
我们完成了基础接口，单元测试，虽然最终结果远远称不上完美，但是每一个成员都有很高的热情，尝试TDD的开发模式。开发过程中遇到了问题，我们通过讨论、请教、Google逐一解决，交流能力有了很大提升，准确定位和复现bug，深入思考系统架构，编写全面的单元测试，实现测试和功能代码分离，都是之前偏向算法的大作业不能给我们带来的，软件工程毕竟重在实践。