软件测试的阶段性
bug的发现和管理
秘密武器：测试用例和测试计划
要想真正保证软件项目如期完成，不仅取决于开发人员，更取决于测试人员。
项目经理经常犯的错误之一，是以为只要雇用软件工程师就行，其他的人都不必要，或是让软件工程师占整个团队很高的比例。他们也许认为开发人员越多，写出来的程序也越多，这是错误的概念。项目的目的是为了完成软件，而不是完成更多的程序代码。在开发团队中，实际有一些工作是不适宜交给软件工程师做的。
要想真正保证软件项目如期完成，不仅取决于开发人员，更取决于测试人员。软件开发好像是在赶进度，而不是在演奏交响乐：交响乐是和谐有序而优雅的，而软件开发却更像是一堆排山倒海、蜂拥而至的工作。交响乐任何两个音符都不能相互抵触，整体表现出来的才是一段优美的音乐。在一切都不确定的软件开发过程中，让测试人员的“Bug指挥棒”来使大家知道什么时候该表现，知道什么时候该退后一点，正是微软将软件开发过程带向高潮的不二法则！
测试组不是开发组的助手
似乎没有谁比微软更重视测试的力量。在微软的产品组中，测试组是与产品规划组、产品管理组、开发组和用户教育组等并列的队伍。测试与软件成本的关系是，发现产品中存在的问题越早，开发费用越低，产品质量越高，软件发布后维护费用越低。在微软开发周期的四个阶段中，测试的目的在于保证软件质量，满足设计的要求和客户的需求；系统地揭示出不同类型的错误，并耗费最少时间和最小工作量；降低软件的开发成本和维护成本。
软件开发过程中开发人员很可能因为一些偶发的小事，或某种无关的灵感而不知不觉中偏离了实际的需要，暂时忘记了什么才是产品最该有的功能，把他们拉回原定轨道中的正是测试工程师。测试人员的职责是配合整个项目组保证按照预定的时间表完成达到预定设计目标的产品。测试人员的工作是具有整体性、持续性的软件开发活动中的一环，而不是偶尔拿出来点缀一下。软件产品的质量是由用于测试的资源、产品的功能和项目的时间表来决定的，是三者的平衡。对任何的一个产品组来说，无论是主观，还是客观上，都要重视测试工程师的存在，这是产品质量的重要保证。
罗马不是一天建成的。早期的微软开发队伍中也没有设立单独的测试组。那个时候的微软几百个人做几个项目，通常是程序员写完程序了，自己测试一下就算完事。后来微软的项目越来越大，软件越来越复杂，写代码和测试的工作要平行进行，渐渐产生了独立的测试组。一个重要的数字是，微软产品组中测试人员和开发人员的比例大约是1∶1。其实，要想真正保证软件项目如期完成，不仅取决于开发人员，更取决于测试人员。
测试组独立于开发组之外的好处在于，程序员总是倾向于认为自己设计的代码足够好，独立的测试组可以使测试人员在不带任何假设的情况下从不同的角度来测试软件，有利于保证软件的质量始终得到控制，并使测试资源得到重用和不断改进。但是，测试组独立于开发组之外，并不意味着程序员写完代码就扔过“墙壁”，等待测试工程师找到所有的bug，当测试人员认为他的工作就是测试程序，而开发人员认为他的工作就是写程序给测试人员测试时，如果你是项目经理，要小心了！开发人员的优越感会使测试人员感觉自己是被歧视的少数民族，这势必会影响到软件的品质。程序人员在写完代码、改正问题后必须完成基本的测试，比如代码的路径测试、单元测试和问题验证等。产品质量控制，存在于开发过程的每一个环节中。
有一个笑话，微软的测试人员工作时间长了，都有挑刺儿的习惯，下了班见了太太做的饭都要评价一番。对微软来说，那些聪明、细致、认真，有耐心，追求完美的产品，对用户有负责任的态度，思维方式独立又开放，既有足够的技术背景，但又愿意学习新的技术的测试工程师更容易得到“老板”的青睐。
软件测试的阶段性
软件开发的过程就像是一支队伍正在急行军，但跑着跑着这支队伍就会“散了架”，设立里程碑的作用就仿佛是到了某一个“点”，大家必须要重新整理步伐，实现同步。就测试组的工作模式而言，测试的阶段划分是与项目的进度相对应的。也就是说，测试人员应当与项目组的其他人员始终保持以相同的步伐“跑步”的状态，与整个项目的每一个里程碑配合，完成相应的测试工作。
把大项目划分成若干子项目的里程碑式的开发模式是微软软件开发管理的精髓做法，如上一期《微软研发方法（上）》所述，在微软的每一个产品开发周期中都有以下几个重要的里程碑：CC（Code complete:代码完成）；Beta测试；RC（Release Candidate：候选发布）；RTM（Release To Manufacture:投入生产），测试人员和产品组的其他人员一起，共同达到每一个里程碑。一个完整的测试循环应当包括运行所有的测试用例、Beta标准测试、bug校验和解所有的bug、随机测试。好的测试循环能够保证对软件质量有一个全面完整的评价，每个里程碑之前至少要有一个完整的测试循环。
在微软的产品开发周期中，在规划阶段当开发人员在做计划、编进度，进行功能实现的可行性研究，对计划的功能进行反馈时，测试人员应当研究规格说明，编写测试计划；在第二个阶段即开发阶段，当开发人员在编写代码、测试和调试的同时，测试人员应当开始设计测试用例，开发自动测试工具和程序，熟悉必需的环境、工具、软件和硬件，不断地丰富测试用例，直到达到CC（代码完成）里程碑——这个时候的软件可以进行一次整体测试，用户界面可能不完美但能够工作，可能有很多明显的bug。
进入开发周期的第三阶段，测试人员大显身手，展开大规模的测试，比如系统级整体测试，交互性和深层测试。测试之后，测试人员应当对新增的功能说“不”，直至达到Bate测试里程碑。达到这个里程碑，意味着所有的Beta致命问题已经被修正和关闭，所有计划的功能都已经在软件中并能工作，产品稳定，大部分界面还可以，尽管可能只是一部分，但已经有了在线帮助和用户手册，即使是发布了也不会引起负面的影响。
项目经理经常犯的错误之一，是以为只要雇用软件工程师就行，其他的人都不必要，或是让软件工程师占整个团队很高的比例。他们也许认为开发人员越多，写出来的程序也越多，这是错误的概念。项目的目的是为了完成软件，而不是完成更多的程序代码。在开发团队中，实际有一些工作是不适宜交给软件工程师做的。
要想真正保证软件项目如期完成，不仅取决于开发人员，更取决于测试人员。软件开发好像是在赶进度，而不是在演奏交响乐：交响乐是和谐有序而优雅的，而软件开发却更像是一堆排山倒海、蜂拥而至的工作。交响乐任何两个音符都不能相互抵触，整体表现出来的才是一段优美的音乐。在一切都不确定的软件开发过程中，让测试人员的“Bug指挥棒”来使大家知道什么时候该表现，知道什么时候该退后一点，正是微软将软件开发过程带向高潮的不二法则！
测试组不是开发组的助手
似乎没有谁比微软更重视测试的力量。在微软的产品组中，测试组是与产品规划组、产品管理组、开发组和用户教育组等并列的队伍。测试与软件成本的关系是，发现产品中存在的问题越早，开发费用越低，产品质量越高，软件发布后维护费用越低。在微软开发周期的四个阶段中，测试的目的在于保证软件质量，满足设计的要求和客户的需求；系统地揭示出不同类型的错误，并耗费最少时间和最小工作量；降低软件的开发成本和维护成本。
软件开发过程中开发人员很可能因为一些偶发的小事，或某种无关的灵感而不知不觉中偏离了实际的需要，暂时忘记了什么才是产品最该有的功能，把他们拉回原定轨道中的正是测试工程师。测试人员的职责是配合整个项目组保证按照预定的时间表完成达到预定设计目标的产品。测试人员的工作是具有整体性、持续性的软件开发活动中的一环，而不是偶尔拿出来点缀一下。软件产品的质量是由用于测试的资源、产品的功能和项目的时间表来决定的，是三者的平衡。对任何的一个产品组来说，无论是主观，还是客观上，都要重视测试工程师的存在，这是产品质量的重要保证。
罗马不是一天建成的。早期的微软开发队伍中也没有设立单独的测试组。那个时候的微软几百个人做几个项目，通常是程序员写完程序了，自己测试一下就算完事。后来微软的项目越来越大，软件越来越复杂，写代码和测试的工作要平行进行，渐渐产生了独立的测试组。一个重要的数字是，微软产品组中测试人员和开发人员的比例大约是1∶1。其实，要想真正保证软件项目如期完成，不仅取决于开发人员，更取决于测试人员。
测试组独立于开发组之外的好处在于，程序员总是倾向于认为自己设计的代码足够好，独立的测试组可以使测试人员在不带任何假设的情况下从不同的角度来测试软件，有利于保证软件的质量始终得到控制，并使测试资源得到重用和不断改进。但是，测试组独立于开发组之外，并不意味着程序员写完代码就扔过“墙壁”，等待测试工程师找到所有的bug，当测试人员认为他的工作就是测试程序，而开发人员认为他的工作就是写程序给测试人员测试时，如果你是项目经理，要小心了！开发人员的优越感会使测试人员感觉自己是被歧视的少数民族，这势必会影响到软件的品质。程序人员在写完代码、改正问题后必须完成基本的测试，比如代码的路径测试、单元测试和问题验证等。产品质量控制，存在于开发过程的每一个环节中。
有一个笑话，微软的测试人员工作时间长了，都有挑刺儿的习惯，下了班见了太太做的饭都要评价一番。对微软来说，那些聪明、细致、认真，有耐心，追求完美的产品，对用户有负责任的态度，思维方式独立又开放，既有足够的技术背景，但又愿意学习新的技术的测试工程师更容易得到“老板”的青睐。
软件测试的阶段性
软件开发的过程就像是一支队伍正在急行军，但跑着跑着这支队伍就会“散了架”，设立里程碑的作用就仿佛是到了某一个“点”，大家必须要重新整理步伐，实现同步。就测试组的工作模式而言，测试的阶段划分是与项目的进度相对应的。也就是说，测试人员应当与项目组的其他人员始终保持以相同的步伐“跑步”的状态，与整个项目的每一个里程碑配合，完成相应的测试工作。
把大项目划分成若干子项目的里程碑式的开发模式是微软软件开发管理的精髓做法，如上一期《微软研发方法（上）》所述，在微软的每一个产品开发周期中都有以下几个重要的里程碑：CC（Code complete:代码完成）；Beta测试；RC（Release Candidate：候选发布）；RTM（Release To Manufacture:投入生产），测试人员和产品组的其他人员一起，共同达到每一个里程碑。一个完整的测试循环应当包括运行所有的测试用例、Beta标准测试、bug校验和解所有的bug、随机测试。好的测试循环能够保证对软件质量有一个全面完整的评价，每个里程碑之前至少要有一个完整的测试循环。
在微软的产品开发周期中，在规划阶段当开发人员在做计划、编进度，进行功能实现的可行性研究，对计划的功能进行反馈时，测试人员应当研究规格说明，编写测试计划；在第二个阶段即开发阶段，当开发人员在编写代码、测试和调试的同时，测试人员应当开始设计测试用例，开发自动测试工具和程序，熟悉必需的环境、工具、软件和硬件，不断地丰富测试用例，直到达到CC（代码完成）里程碑——这个时候的软件可以进行一次整体测试，用户界面可能不完美但能够工作，可能有很多明显的bug。
进入开发周期的第三阶段，测试人员大显身手，展开大规模的测试，比如系统级整体测试，交互性和深层测试。测试之后，测试人员应当对新增的功能说“不”，直至达到Bate测试里程碑。达到这个里程碑，意味着所有的Beta致命问题已经被修正和关闭，所有计划的功能都已经在软件中并能工作，产品稳定，大部分界面还可以，尽管可能只是一部分，但已经有了在线帮助和用户手册，即使是发布了也不会引起负面的影响。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
领测软件测试网最新更新
