自动化测试：http://robotframework.org/
HTTP接口测试：POSTMAN
测试：
- 单元测试（unit testing）
- 组件测试 （component tetsing）
- 集成测试 （integration testing）
- 回归测试 （regression Testing）：重复执行以前的测试用例
- 系统测试 （System testing）：终！
两大类：
- 黑盒
- 白盒：开发者关注
错误类型：
核对表（测试用例）
- 类和子程序所对应的的每一项需求是否都有相应的测试用例
- 类和子程序所对应的每一个设计元素是否都有相应的测试用例？
- 每行代码是否被至少一个测试用例所测试？你是否通过计算测试到每行代码所需的最少测试用例数量来验证这一点
- 所有已定义-已使用路径是否至少被一个测试用例测试过了？
- 是否测试过那些不太可能正确的数据流模式，例如已定义--已定义、已定义-已退出以及已定义-已销毁？
- 是否有一张常见错误列表，并据此编写测试用例以检测过去经常出现的错误？
- 所有的简单便捷是否已经测试过了：最大、最小以及off-one
- 是否测试了组合便捷——即，多个输入数据的组合导致输出数据过小或者过大
- 测试用例是否检查了数据类型错误，例如一个薪水记账程序里的雇员数量是负数
- 是否测试了那些中规中矩的典型数值
- 是否测试了最小正常形式
- 是否测试了最大正常形式
- 是否检查了与旧数据的兼容性？以及是否对旧硬件、旧操作系统版本以及其他旧版软件的接口进行了测试
- 测试用例是否容易手工检验？
要点
- 开发人员测试是完整测试策略的一个关键部分。独立测试也很重要
- 同编码之后写测试用例相比较，编码开始之前编写测试用例,工作量和花费的时间差不多，但是后者可以缩短缺陷-侦测-调试-修正这一周期
- 及时考虑到了各种可用的测试手段，测试仍然只是良好软件质量计划的一部分。高质量的开发方法至少和测试一样重要，这包括尽可能减少需求和设计阶段的缺陷。在检测错误方面，协同开发的成效至少与测试相当。这些方法所检测错误的类型也各不相同
- 你可以根据各种不同的思路来产生很多测试用例，这些思路包括基础测试、数据流分析、便捷分析、错误数据类型以及正确数据类型等。你还可以通过猜测错误的方式得到更多的测试用例。
- 错误往往集中在少数几个容易出错的类和子程序上。找出这部分代码，重新设计和编写他们。
- 测试数据本身出错的密度往往比被测试的代码还高。查找这种错误完全是浪费时间，又不能对代码有所改善，因此测试数据里面的错误更加让人烦恼。要像修改代码一样小心地开发测试用例，这样才能避免产生这种问题。
- 自动化测试总体来说是有用的，也是进行回归测试的基础
- 从长远来看，改善测试过程的最好办法就是将其规范化，并对其进行评估，然后用从评估中获得的经验来改善这个过程。