自动化单元测试要点 单元测试方法
用单元测试的框架MSTEST，做单元测试，集成测试快1年了，总结一下义务中学到都东西。
单元测试，集成测试有什么用?
1。 改善产品质量
软件测试，很多时候萦绕着两个问题：
Verification和Validation，常说的双V。前面的Verification就是Is the software built correctly?。前面的Validation就是Have we built the right software?
单元测试，更多的是Verification。所以有时候经过我单元测试和集成测试以后的功能模块，在交给其他同事做功能测试的时候，依然会有一些 BUG，这时离开发可以会埋怨我测试得不够完全，诸如此类。但是其实很多时候，我的关注点是单个方法的功能、行为，没有站到更高的位置来测试这个模块。关于这样的问题，开发和测试应该互相原谅，我自己也会提高自身的水平。欲望在单元测试和集成测试中也加入更多关于Validation的思考。
有一个提法叫Tests as Specification，单元测试自身其实就是模拟某个模块的应用者(其他的顺序)来进行测试。很多时候我写的测试代码也是其他开发人员的参考，尤其在一些事实上或者只是号称自己是敏捷开发的组织里面，测试代码有可以成为详细设计的替代品，因为有可以基础没有详细设计文档。
单元测试的另一个义务就是发现并且定位BUG。关于BUG的定位和重现，在单元测试代码的编写过程中，每个Assert语句前面都要加上尽可以详细的信息，例如导致这个Assert语句失败的每个参数值，期望效果，实际效果等，这些信息可以资助开发和测试快速定位问题，增加不必要的DEBUG时间。
2。 降落项宗旨风险
软件测试，其实是用有限来验证无限的一个过程，很多时候做什么样的测试，做到什么样的水平，很多时候都跟风险有关系。
作为产品的安全网，各种测试在项目中都扮演着重要的角色。例如，中美交互的几十个Web Service接口的回归测试，现在有若干个测试，每天定时做回归测试，因为没人知道在美国的服务器会发生什么事情;关于中国的Web Service，在上线前都会通过回归测试，才支配上线。还有全站的Platform Service接口，每次上线前都需要在做回归测试。软件测试的另一个有趣的结论就是：测试只能证明软件有BUG，但是无论什么样的测试，都不能证明被测软件是没有BUG的。问题出来了，我做完回归测试，都通过了，但是我却不能证明这个软件是没有BUG的。其实每次上线，团队都承担着风险，只不过这样的风险在完成回归测试之后，大家上线的自自负心增加，风险明显地减小。
文章来源于领测软件测试网 https://www.ltesting.net/
