版本前的软件测试

1、单元测试和代码覆盖率
系统测试出现Bug数量超过预计一般是自测或集成测试不充分。而集成测试出现大量问题则重点都是单元测试不充分，单元测试一般是要进行白盒测试，其中一个重要目标就是条件分支的覆盖和代码语句的覆盖。如果要完全做到最全面的语句+条件+分支覆盖则事先必须进行测试用例的准备，分析究竟要准备多少组测试数据才能够达到这个要求。单元测试最基本首先要做到语句的完全覆盖，这个是最基本的要求，如程序中的ifelse，switchcase的语句必须要完全覆盖到，而exception语句一般不要求能够覆盖到，因为要认为对每个操作制造异常并不是容易的事情。而这里认为强调条件分支覆盖的一个重要考虑是如果这块开发不自我测试全面，很可能问题到系统测试阶段也很难完全发掘出来，成为系统隐含很深的Bug.
2、顺序问题
对一个功能点的开发仍然需要遵循数据层->逻辑层->界面层的开发顺序，因为这样可以使单元测试过程更加的简洁，也不用去设置过多的测试桩。数据层写完了首先要对数据层进行数据获取或构造数据的准确性的测试，如果这块完全通过数据库存储过程实现的，则测试过程应该是很简单的，直接通过在数据库中调存储过程进行测试就可以了。测试目的重点还是保证数据获取或构造的准确性，这块的测试操作如果习惯性的遗留到开发完UI后在进行测试，则存在较大问题，到了UI层开发结束后已经是对一个单一功能点的集成测试了，这个时候如果功能测试存在问题就很难去分析究竟是数据构造问题还是UI或逻辑层引起的问题了。
3、快速定位到Bug
改Bug可能只需要5分钟，但你定位出Bug可能需要半天或者更长的时间。所以如果快速定位Bug是一个很重要的技能改进点。这里面主要有一些几点：
（1）是对系统整体框架和架构要熟悉，对系统中相关的公用模块和公用类要熟悉，熟悉了这个就熟悉了系统的运行机理。
（2）是在编码阶段整个编码的可读性和可维护性就要好，因为你改Bug过程其实就已经是一个程序的维护过程了。程序的可维护性好，类和方法子函数的划分合理，就很容易去跟踪程序和定位异常点。
（3）是对IDE环境的Debug相关工具要熟悉，要能够熟练的使用调试，跟踪，堆栈变量观察等相关的工具和方法。
4、连锁反应
Bug在系统测试阶段不能很快的收敛的一个重要原因就是连锁翻译，开发在修复一个Bug过程中往往引入一个或多个新的Bug，所以程序很难稳定下来。所以对于Bug的修改开发自己除了考虑Bug的修改方法外还要进行Bug的影响分析，特别是修改到一些公用函数和公用类的时候。在整个解决方案或项目中进行函数或方法名的搜索往往是一个快捷的方法，方便你很快定位出修改某个方法对其他功能造成的影响。
5、待办事情TODO
编码阶段重要的一个记录就是待办事情，代码中的//TODO或记事本是记录待处理的事情做佳的方案。在编码过程由于需要他人协助提供一个接口，或其他某个单元需要提供数据才能够进行集成，或现在暂时无数据为单元测试只能手工给一些假设数据，而后续需要改回使用真实数据地方。这些都是重要的TODO的地方，一定要记录清楚，否则后续随着编写代码量和功能点的增多很总有在后续遗忘掉，而将这些问题遗留到了后续系统测试才发现，或者由于自己某块没有做好影响了他人的集成和联调。