内容简介:本书系统地总结了过去十年中软件测试发生的变化,浓缩了作者许多宝贵的软件测试经验。本书首先介绍对于软件测试的不同看法,全程软件测试的思想,软件测试的基础设施与TA框架、团队能力建设;然后逐步深入到测试的计划、设计、执行、持续反馈和改进;接着,讨论全程测试的思想,包括全程静态测试、全程性能测试、全程安全性、全程建模、全程可视化。本书最后展望了软件测试的未来。 本书适合软件测试人员阅读,也可作为相关专业人士的参考指南。
单元测试不是测试,而是开发的辅助工具,最好不当成测试。单元测试追求业务逻辑的覆盖率,最好不要追求代码覆盖率,否则就不方便重构了。,
全栈工程师诚如作者所说。但拿开发者来说,也需要他关注业务,包括用户,价值,场景,满意条件,能就开放性问题进行交流,否则如何开发出切合业务的软件。再者说,开发人员也要有功能测试的能力,否则,如何知道一个功能开发完成了,难道真要等测试人员测出问题才知道这个功能其实没有做完?
单元测试应该在设计出一个接口时就设计单元测试用例,若发现用例数过多,则按单一职责原则重构接口,这个角度说,单元测试让重构提前了。要是完成一个类后再写测试用例,稍微有点晚。
单元测试不是测试,而是开发的辅助工具,最好不当成测试。单元测试追求业务逻辑的覆盖率,最好不要追求代码覆盖率,否则就不方便重构了。,
全栈工程师诚如作者所说。但拿开发者来说,也需要他关注业务,包括用户,价值,场景,满意条件,能就开放性问题进行交流,否则如何开发出切合业务的软件。再者说,开发人员也要有功能测试的能力,否则,如何知道一个功能开发完成了,难道真要等测试人员测出问题才知道这个功能其实没有做完?
单元测试应该在设计出一个接口时就设计单元测试用例,若发现用例数过多,则按单一职责原则重构接口,这个角度说,单元测试让重构提前了。要是完成一个类后再写测试用例,稍微有点晚。