不得不说，这次有点标题党。其实我们也一直在寻求一整套的解决方案来达到提高团队的自验证能力的目的，但是目前使用的方式也只是屈指可数。下面我就说说我目前学习到的，希望和大家一起讨论并修改。（先写个大概，这两天发烧拉肚子，没力气）
1. 静态代码分析
这个要靠静态代码分析工具来实现。目前有很多的静态代码扫描工具，可以进行词法分析，语法分析，语意分析等。还可以自定义各种各样的复杂的规则去对代码进行分析。
静态代码分析是编写代码时可谓最靠前的一种质量保障了，它可以帮助我们在编写完代码后第一时间就得到代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面的分析结果；可以发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。
2. 单元测试覆盖率
这个也要靠工具来解决。目前的静态代码分析工具也有可以提供检查单元测试覆盖率的功能。单元测试覆盖率分为代码行覆盖率和代码分支覆盖率两种，只有两种都达到足够的比例才能说明我们的代码在单测上已经有了足够的覆盖。这在回归的工作中显得尤为重要。在有些公司，单元测试代码会由开发人员和测试人员共同完成。
3. 规范开发人员自测
这个要靠测试人员在开发人员提测前提供自测case给开发人员。自测case需要测试人员对需求绝对的熟悉，内容应该涵盖本次迭代的所有功能点及流程点。但是要注意的是，不要将所有的细节都写入自测case，比如UI的细节等，要不开发人员会占用大量的时间来测试细节而影响开发，导致收效甚微。
4. 持续集成+自动化测试
这个也是测试人员的主要工作。试想一下，每次开发人员部署完代码就会自动跑一遍回归测试，接下来我们要做的只是等待测试的结果，有问题就解决，没问题就ok了，爽不爽？
自动化测试可分为UI测试，接口测试等。可以靠很多工具实现。
5. 手工回归+功能测试
这点就逃不了了，很多有关用户体验等目前只能通过人来验证，这要靠我们测试人员的测试用例来覆盖。
网友评论