“温故而知新”，这句古训可以帮你给老板交差，对项目的进行过程作个分析，总结，最好再交个分析数据，老板绝对不会觉得你拿了钱不干活，而且自己也能有些收获。
开发阶段最好找的就是Bug记录，Bug管理系统已经记录下了所有的Bug的现象，分类，所处模块，发生原因。虽然几乎所有的Bug管理系统都提供报表，分类汇总功能。但是真正对这些信息作认真分析的项目恐怕不很多。
Bug出现的范围
对Bug的修正过程分析后，你可能发现绝大部分Bug都和少数几个关键的代码文件有关系，例如我有一个模块，共25个代码文件，还有三个外部文件，80%的bug在修正中都对两个代码文件有修改。也就是说，Bug的表现形式可能不同，但是追溯其发生原因，大部分都在很有限的代码范围内。但是，这些代码都不是关键部分，而在一些不怎么重要的地方。原因是关键代码（比如数据库操作）在程序员开发时就多次运行，验证过了，或者都已统一作了封装，包含在Fremework中，可靠性高，出现Bug的机率不大。非关键的部分常常是细节上的问题，比如焦点的移动，控件的对齐，特殊数据类型（时间，货币）的表示格式，字体，颜色等，某些值的计算或精确度有误。而在这些细节中，一个模块又会集中在其中的几项上，还是以我上面提到的模块，70％的Bug又都是焦点移动和表示格式的问题。
Bug出现的原因
对于Bug出现的原因，比较多的有几种：代码实现与设计不符；单纯的实现错误或遗漏；对某个点设计和实现同时遗漏，没有人提出，直到测试时才发现；没有遵守项目的规范，本不是Bug，但是测试人员和实现人员的理解不同。
以上Bug出现的原因中对于设计，代码，测试不一致的问题，常常是由于三者之间对与模块要实现什么和要测试什么没有一个统一的标准，所以我认为首先必须有一份文档（不管你把它叫什么），来作为参照，如果出现理解上的偏差或不一致，可以到这里找答案，如果找不到，把缺失的部分补上。
对于实现阶段出现的问题，除过上面说到的标准不一致外，主要是因为程序员自己单纯的错误或粗心，遗漏了某个细节，或者虽然实现了，但是不完全正确。对于后者，可以是因为一个模块自己的特殊功能，代码写的有问题，也可以是因为一个在多个模块中都要用到的功能，但是没有作统一的封装，大家各写各的，结果是实现方式上的差异和Bug出现机率的增高。对于第二种情况，应当首先考虑将这个功能封装起来，统一调用，并且写下文档。
对于测试，在保持和设计，实现一致的前提下，可以对测试点分为通用部分（焦点，字体，控件大小，日期，货币的显示格式），非通用部分（除通用部分外该模块自身要实现的功能），正常情况，异常情况四类，进行测试。
以上的分析都是基于单元测试的结果，并且只针对一个模块，有很大的局限性，但是相信对于后面项目的开发是很有帮助的，开发和测试会变得更有针对性，一方面可以减少Bug，一方面测试的效率也可以提高。
你可以应付老板，但是不能应付自己，“认真”只会让你更高效，更轻松。
希望大家分享更多的经验。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/