4

测试计划：
1.我们的目的是让时间变得更加紧张，让设置时间的人在没有做完这件事会有一种紧迫感。
2.我们的使用对象主要在考研学生和其他需要计时器来提醒他要在规定时间内做完一些事情的所有人
3.我们软件主要是采用html5 来实现的主要是文本框和引用系统时间的操作。
4.我们的测试范围主要是针对对象自己能不能设置自己想要的时间，能不能在到时间的时候有闹铃的提示，打开软件是否可以引用系统时间，对象可不可以在文本框中填写自己想要的激励语。
5.测试环境我们使用的是谷歌浏览器，测试工具是sublime。

我们不需要把软件测试到完善，因为bug是针对不同人群的，如果要到完善的地步会造成大量的时间浪费，所以不需要。

1. 容易运行

　　什么样的单元测试是容易运行？答案很简单，自动化的单元测试就是容易运行的测试。如果一批测试在运行之前每次都需要重装系统然后还要找一大堆需要依赖的软件来装上，最后还要输入奇怪的命令才能运行，那么就不是一个好的测试（本人真的见过这样的测试，囧）。个人认为，配置好的持续集成系统，可以实现很好的自动化测试；如果没有一个完善的CI，那么一个one click的自动化测试运行也是一个较好的选择。

　　2. 自动检查结果

　　一句话：没有自动检查结果，再好的自动化也是白搭。

　　3. 可重复

　　一句话：只能运行一次的单元测试也是白搭。

　　4. 独立

　　其实测试的独立，也有利于实现可重复。刚做单元测试的时候，曾经犯过这样的错误，我在写A测试的时候，给数据库插入了一条记录，然后我在写B测试的时候，就觉得我为什么要在两个测试中分别创建两条数据？直接用上一个测试的数据就可以了。不过结果还好，我很快就发现这样做是有问题。单元测试的独立，就是运行测试的人可以先运行A测试，也可以先运行B测试，也可以单独运行A或者B测试，甚至可以A和B测试同时运行。

　　5. 简单

　　有时候，测试的代码写的有点复杂，嵌套的语句有点多，可能有些人会觉得写出复杂的单元测试代码才能体现自己的水平，但是，我觉得对于单元测试代码来说，应该越简单越好。最好就是顺序执行下来了，不要有什么分支。因为测试代码本身就是也是代码，那么怎么去验证测试代码写的正确呢？答案可能是再写一个测试代码去验证第一个测试代码。这样就会有死循环了。一个简单的假设就是，如果测试代码足够简单，那么就可以认为测试代码是正确的，无需其他代码对之进行测试。

　　6. 专注

　　一个测试应该只测试一个点。如果在一个测试里面验证多个测试点，看起来是比较高效的一种做法，但是当测试中有Assert语句抛出异常的时候，很有可能需要花大量的时间才能找到真正错误的代码，这样不利于实现前面提及到的“定位BUG”。

　　7. 注释

　　注释其实就是把代码抽取成可阅读的测试用例，如果别人看自己的程序，可以快速理解测试代码；同时注释还能唤醒自己沉睡的记忆和当时的测试思路。

　　国内做单元测试的测试工程师少，做集成测试、接口测试的也不多，埋头做事,别忘抬头看路。时常总结，提高自我。