读书笔记

1. 测试是为了发现错误而执行程序的过程。

2. 软件测试的原则
    （1）测试用例中必须包含对预期输出或结果的定义。
    （2）程序员或组织应避免测试自己编写的程序。
    （3）应仔细检查每个测试的执行结果。
    （4）测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入情况。
    （5）检查程序是否“未做其应该做的”仅是成功的一半，测试的另一半是检查程序是否“做了其不应该做的”。
    （6）应避免测试用例用后即弃。
    （7）进行测试工作时不应事先假定不会发现错误。
    （8）程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。

3. 测试策略
    （1）如果规格说明中包含输入条件组合的情况，应首先使用因果图分析法。
    （2）在任何情况下都应该使用边界值分析方法，对输入和输出边界进行分析。
    （3）为输入和输出确定有效和无效等价类，补充测试用例。
    （4）使用错误猜测技术补充测试用例。
    （5）使用多重条件覆盖准则检查程序的逻辑结构

4. 多重条件覆盖准则：将每个判定中的所有可能的条件的组合，以及所有的分支入口点都至少执行一次（不能保证对所有可能的路径都走一次）。

5. 测试结束的准则
    第一类
        模块测试的结束准则：
        （1）满足多重条件覆盖准则。
        （2）对模块接口规格说明进行边界值分析的所有测试用例都通过。
        功能测试的结束准则：
        （1）因果图分析，（2）边界值分析，（3）错误猜测的所有测试用例都通过。
    第二类：以确切的数量来描述结束测试的条件。
    第三类：记录单位时间内发现的错误数量，通过检查统计曲线的形状来判定测试是否应结束。

6. 调试的原则
    （1）动脑筋
    （2）如果遇到僵局，就留到稍后解决
    （3）把问题描述给别人听
    （4）仅将调试工具作为头脑思考的辅助手段
    （5）避免使用试验法
    （6）改正错误时增加的代码比程序中原有的代码更易发生错误
    （7）应修改源代码，而不是目标代码

7.极限编程的12个实践
    （1）市场和业务开发人员在一起以场景的形式编写软件需求并确定优先级
    （2）小规模地、递增地发布
    （3）系统隐喻
    （4）简要设计
    （5）连续测试
    （6）重构
    （7）结对编程
    （8）代码的集体所有权
    （9）持续集成
    （10）每周40小时工作
    （11）客户在现场
    （12）按标准编码
    归纳为4个概念：
    （1）聆听客户和其他程序员的谈话
    （2）与客户合作，开发应用程序的规格说明和测试用例
    （3）结对编程
    （4）测试代码库