笔记:Microsoft.net和windows应用程序调试(第一部分:调试概述)

 

第一章：错误来源和排错方法

(P4)错误定义：

 a、用户界面不一致。

 b、功能与用户需求不符。

 c、程序性能差。

 d、程序崩溃或者数据破坏。

 

(p4)参考"Microsoft Windows User Experience"一书设界面。

 

(p7)错误产生的原因：

 a、过于紧张的工期。

 b、“先编码后思考”的开发方法(Code Fist, Think Later)

 c、没有正确理解客户需求。

 d、工程师只是的欠缺或培训不当。

 e、缺乏质量意识。

 

(p8)解决CFTL的方法很简单：为项目指定计划。

 

(p12)代码复查方式：

 a、一对一：复查者与代码编写者一起一行一行阅读代码。

 b、让初级程序员复查高级程序员的代码。

 

(p13)真正的重视质量的公司和个人具备的共同特征：

 a、周密的前期规划。

 b、高度的责任心。

 c、严格的质量控制。

 d、良好的沟通能力。

 

(p13)汇总开发人员发现及记录错误的数量，作为评审的一项标准。

 

(p13)在产品开发的每一个里程碑，所有的开发人员必须统一产品的确没有问题。

 

(p14)规划调试：应该从最初的需求阶段就要考虑调试。预先计划的越周密，以后花在调试上的时间和资金就越少。

 

(p14)更改代码之前，一定要十分清楚需要进行什么改动，而且制定明确的计划。一定要记住，添加一项功能不只会影响代码，而且会因想到测试，产品文档，有时甚至会影响到产品的销售宣传语。

 

(p15)code complete 中提到的修正错误的代价。

 

(p16)规划调试与规划测试应该同时进行。

 

(p18)阅读书籍和杂志、编写一些实用程序、阅读他人的代码，以及进行一些逆向工程，这些都是提高调试技能的极佳途径。(当然这些不仅仅能够提高调试技能)

 

(p18)推荐的调试方法中包含的步骤。

 1、重现错诉。

 2、描述错误。

 3、总是假设是自己造成的错误。(这点很重要)

 4、分而治之。

 5、创造性的思考。

 6、借助于工具。

 7、开始大规模调试。

 8、验证错误已经修正。

 9、学习和与人分享。(好主意)

 

(p19)有一种悠闲级别最高的中断开发工作的阶段称为“错误讨论(Bug Talk)”    

 

 

第二章：开始调试

(p26)版本控制系统和错误跟踪系统

 

(p27)错误跟踪系统可捕获所有可能导致主源码更改的事件，而版本控制系统可以捕获所有更改。

 

(p27)当我们在版本控制系统中检查修改后的文件时，也应该在该文件的注释中指出对应的错误编号。

 

(p27)版本控制系统不仅可用于维护项目中的主源码库，任何与项目相关的内容---包括所有的测试计划、自动化测试、帮助系统，以及设计文档---都需要利用版本控制系统进行管理。(包括项目所依赖的其他资源和工具)

 

(p27)单元测试一定要纳入版本控制系统。

 

(p28)单元测试可以简化维护工作(简化维护后的测试工作)，同时可以简化QA部门的普通测试工作，让他们可以集中测试一些更重要的方面。

 

(p28)单元测试代码必须要与主程序代码保持一致。

 

(p28)控制变化：在项目的特定阶段限制对主源码库的某些类型的操作。作者推荐的方法:

a、绿色时期：项目的早期。任何人都可以主源码库中加入任何东西。

b、 黄色时期：当产品处于错误更改阶段或者接近代码冻结时期。唯一允许的代码更改就是修改错误，不能加入新的功能。对每一次修改都需要认真复查。

c、 红色时期：在代码冻结或者接近一个关键的里程碑的时候。所有修改都需要经过产品经理的批准，任何一个小的改动都有可能会使整个团队重新进行测试。

 

(p28)红色时期的代码修改：崩溃和数据破坏。同时参考以下问题：

 a、这个错误会影响到多少人？

 b、这一更改发生在产品的核心部分还是外围部分？

 c、如果进行了更改，应用程序的哪些部分需要重新测试？

 

(p28)label规则：

a、标注所有内部里程碑。

b、标注”绿色时期“、”黄色时期“、”红色时期“之间的任何转换。

c、标注发送到不属于项目团队的人的版本。

d、在版本控制系统中进行版本分支时加以标注。

e、在每日声称(daily build)和冒烟测试(smoke test)正确完成后加以标注。

 

(p30)错误跟踪系统除了用来跟踪错误，还可以帮助我们纪录一些备忘提示、待办事项清单。

 

(p31)应该保证所有需要的人都能有访问错误跟踪系统。(任何人都可以提交错误)

 

(p32)在进度表中安排时间建立调试系统，必须一开始就决定实现崩溃处理程序、文件数据转储程序，以及其他帮助重现错误的工具。(错误收集程序)

 

(p32)在规划调试系统时，需要决定如何在项目中返回错误条件。

 

(p33)调试符号(debugging symbol)是一种数据，能够让调试器显示出程序中的二进制可执行模块对应的元代买和行信息、变量名，以及其他数据类型信息。

 

(p34)对于本机代码将大多数变异警告视为错误(trade warnning as error)

 

(p43)参考："Escape From DLL Hell with Custon Debugging and Instrumentation Toos and Uilities"

 

(p44)DLL重定位不仅会启动慢，运行也会慢（我认为）

 

(p54)生成系统(build system)用来编译和连接程序，冒烟测试套件(smoke test suite)包含一系列能够运行程序并验证程序是否工作的测试

 

(p55)“冒烟测试”指的是简单执行一般软件的各主要功能，看看程序是否工作以及是否可以进行正规测试。“冒烟测试”是衡量程序代码是否“健康”的底线。

 

(p55)冒烟测试中一个至关重要的组成部分就是性能基准。

 

(p56)冒烟测试的理想情形是程序自动化。能够自动化输入和运行的工具称为回归测试工具(regression testing tool)

 

(p57)QA必须测试调试版本。但是调试版要有功能能够屏蔽断言，从而不干扰自动测试。

 

(p57)2.6 安装操作系统调试符号和建立符号库。

 

 

第三章：边编码边调试

(p67)主动式编程。

 

(p68)“充分信任，但是必须进行验证”：

 a、验证其他人传入自己代码中的所有参数。

 b、验证自己代码内部的操作和运算。

 c、验证在自己代码中所作的所有假设。

 d、验证对自己的代码传给他人的参数。

 e、验证调用有返回的数据。

 

(p68)保证代码质量完全是开发工程师的职责，而不是测试工程师、技术文档编写人员或者管理者的责任。

 

(p68)开发人员投入在测试代码上的时间应该至少占总开发时间的40%~50%，否则他就不是在作开发。

 

(p68)测试人员的工作应该主要集中在诸如产品功能性，压力测试，以及性能测试上。(p68)测试人员如果在测试的时候遇到程序的崩溃,就直接说明开发人员的能力和责任心有问题。

 

(p68)单元测试能够保障测试工程师可以集中精力测试集成问题和系统级测试问题。

 

(p69)判断是否使用了足够的断言的原则：当经验不是很丰富的程序以无效的信息调用和这假设条件来调用我的代码时，总会弹出很多断言失败。

 

(p71)使用断言的原则。

 a、一次只检查一项内容。

 b、对条件进行全面检测。

 c、显示检查可接受的值，可以确保断言是自描述的，可以以确保能够捕获错误数据。

 

(p73)断言的对象：

 a、传递给方法的参数。

 b、方法的返回值。

 c、对自己的假设进行检查。

 

(p73)断言绝对不能带起常规的错误处理代码。

 

(p80)工具：DebugView查看OutputDebugString和DbgPrint的输出。

 

(p97)用于提高c和c++断言的描述性的辅助函数：GetObjectType、IsBadCodePtr、IsBadReadPtr、IsBadStringPtr、IsBadWritePtr、IsWindow。

 

(p103)3.1.6 SUPPERASSERT的功能、用法、实现。

 

(p124)跟踪(TRACE)合适的信息。一般分两个层次：

 a、反应程序的基本执行流程。(分析程序流)

 b、在记录文件中添加关键的顺序。(分析数据流)

 

(p125)日志系统需要考虑的因素：

 a、信息的格式。

 b、信息的级别。最好不要使用条件编译实现，以使得可以很方便的改变跟踪基本。

 

(p127).Net中TraceSwitch的级别。关闭、错误、警告、信息、详细。

 

(p130)Code as if whoever maintains your code is a violent psychopath who knows where you live.

 

(p130)开发人员工作的两个重要目的：为用户提供一个解决方案，并让该方案可以维护。

 

(p130)注释的方法：

 1、每个函数或方法都需要一两句注释来说明以下信息：

    a、函数的功能。

    b、函数作了哪些假设。

    c、每个输入参数的合法值。

    d、每个输出参数在成功和失败的情况下的合法值。

    e、所有可能的返回值。

    f、所有可能引发的异常。

 2、函数中不能一目了然的部分都需要注释。

 3、任何一个有序的算法都应该先洗注释。

 4、所有重大错误修改都应该加以注释，说明错误的编号以及修改内容。

 5、使用恰当的跟踪语句、断言以及良好的命名规范。

 6、加注释时想象自己5年后会再对该代码进行维护。

 7、尽可能避免在代码中保留注释掉的代码、

 8、如果注释用饱含“此处很蹩脚”或者“此处很复杂”等句子，可能就需要重写这个函数。

 

(p130)推荐参考:Code Complete。

 

(p131)验证自己代码的第一个方法是,在开始写程序代码的时候就开始写单元测试，二者同步进行。如果是在完成主要的功能代码以后才开始做这些常规开发，通常会没有足够的时间开发配套测试程序，从而无法深入进行有效测试。

 

(p131)第二个方法:在写代码之前就考虑怎样对代码进行测试。

 

(p131)在编码时应该一直运行单眼测试。

 

(p131)check-in测试，将代码check-in之前必须进行的测试。

 

(p131)大多数有效单元测试的关键之处在于：代码覆盖率(code coverage)。

 

(p132)用工具检查代码覆盖率：DevPartner.TrueCoverage。

 

(p132)对我自己来说，我只有在代码覆盖率达到85%到95%的时候才会check-in到主源码库中。

 

(p132)以我的观点看来，在单元测试阶段，提高代码覆盖率是获得高质量代码的唯一途径。

 

(p132)QA人员的工作是将产品作为一个整体来测试，而且保证不同的子系统可以协同工作。而我们的责任是测试一个功能单元，并保证该单元的质量。