摘要: [在从word 拷贝到blog 中出现不少排版问题，特此致歉. 所有内容均属个人意见，没有任何担保或授权，以"现状"提供。 版权所有] 1        软件测试和VSTS 测试工具 本部分介绍各种测试类型，以及它们在VSTS 2005中的应用。   在学习讨论之前，阿彪问大家：我有一个闷在心里好久的问题 – bug到底翻译成什么最好？ 杂曰：     臭虫，缺陷，错误，地雷，应用程序异常，     就用bug好了，大家都理解！   小强！小强！   大家回头一看，阿毛红着脸说：我们宿舍里有不少小强，每晚自习回去都要打小强。。。 众大笑。 阿彪：我倒是不反对用“小强”。 阿超：好是好，VSTS也支持改工作项的名字。就怕我们以后招进来名字中有“强”的同学。 阿彪：我觉得我可以为“小强”花一颗银弹，我们以后就把“小强” 当作bug的同义词. 小飞：那我们怎么翻译“bug fix”?  翻译成“针对缺陷的修改”也太绕口了。 阿毛：我们是用拖鞋来打小强，所以不妨称之为“拖鞋”。 （大笑） 国栋：我反对把软件工程的术语生活化。。。     阿超：说到测试，大家肯定有不少了解，也保不准有一些误解，我们这个讨论就是要去伪存真，把大家的理解统一到一个水平上。大家知道的“测试方法”有多少？   杂曰：            Black box Test, White box Test            Code Coverage, Test Unit Test            Functional Test, Structural Test            System Test, Performance Test            Stress Test, Load Test            Acceptance Test, Regression Test            Ad hoc Test, Integration Test            Alpha/beta Test, Localization/Globalization Test            Security Test, Accessibility Test, Scenario Test,            Usability Test,Smoke Test   二柱：这么多！把我都忽悠得有点晕了。看来我国软件测试人才真是大有用武之地了。 小飞：这么多名词，是得学几年的，写程序的方法怎么没有这么多花头？   阿超：咱们还是一个一个来吧。 这么多名词只不过是从各个方面描述了软件测试，并不是说有这么多独立的测试方法，我们把它们分类处理就不难了。 1.1     从测试设计的方法分类 从测试设计的方法来看，我们知道有两类方法： Black box (黑箱) White box (白箱) 这是每个接触过软件测试的人都会给出的答案。但是这只是整个软件测试的入门。我们可以跳过去，直接讨论下面的内容。。。   问：我在网上看到有人争论黑箱测试和白箱测试哪一个是另一个的基础，还有那一个更难，那一个更有前途，等等。据说李村数码在搞“灰箱测试”，是不是更高级？能不能简单讲一讲？ 阿超：大家都有这些问题么？ 杂曰：[略去对此问题热烈的争论500 字] 阿超：听了大家的争论，看来我们的确得花不少时间统一认识.   第一个要注意的问题是，所谓黑箱/白箱，是软件测试设计的方法，不是软件测试的方法！注意“设计”二字。   黑箱：在设计测试的过程中，把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是“Behavioral Test Design”, 从软件的行为，而不是内部结构出发来设计测试。 白箱：在设计测试的过程中，设计者可以“看到”软件系统的的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择。“白箱”并不是一个精确的说法，因为把箱子涂成白色，同样也看不见箱子里的东西。有人建议用“玻璃箱”来表示。   在实际工作中，我们不应画地为牢，严格只用某一种方法来设计测试方法。在实际的测试中，当然是对系统了解的越多越好。所谓“灰箱”的提法，正是这一反映。有些人甚至希望我们全部忘记“箱子”和它们的颜色。   我们并不是要禁止懂得内部构造的人员来进行黑箱测试设计，只不过我们在设计时有意不考虑软件的内部结构。例如：在测试程序内部基本模块的时候（单元测试），我们通常是要求对程序结构非常了解的程序员来设计，这是因为内部模块的“行为”和程序的外部功能并没有直接的关系，而且内部基本模块的“行为”通常没有明确的定义。另一个例子是“可用性测试”，在设计此类测试的时候，我们没必要纠缠于程序的内部结构，而是着重于软件的界面和行为。但是软件可用性测试也需要很多专业知识。这也从一个侧面表明“黑箱”和 “白箱”没有简单的高低之分。   一旦测试用例写出来之后，我们大可以忘了它们是从那种颜色的箱子里出来的，用它就可以了。 1.2     功能测试 以下的测试术语都是主要测试软件的功能。在下表所列的测试中，测试的范围有小到大，测试者也由内到外 – 从程序开发人员（单元测试）到 测试人员，到一般用户（Alpha/Beta 测试）。   测试名称 测试内容 Unit Test 单元测试 – 在最低的功能/参数上验证程序的正确性 Functional Test 功能测试 – 验证模块的功能 Integration Test 集成测试 – 验证几个互相有依赖关系的模块的功能 Scenario Test 场景测试 – 验证几个模块是否能够完成一个用户场景 System Test 系统测试 – 对于整个系统功能的测试 Alpha/Beta Test 外部软件测试人员（Alpha/Beta 测试员）在实际用户环境中对软件进行全面的测试。                 1.3     非功能测试 一个软件除了基本功能之外，还有很多功能之外的特性，这些叫“non-functional requirement”, 或者“quality of service requirement”- 服务质量需求。没有软件的功能，这些特性都无从表现出来，我们要在软件开发的适当阶段做这些测试。 比如： 测试名称 测试内容 Stress/load test 测试软件在负载情况下能否正常工作 Performance test 测试软件的效能 Accessibility test 测试软件辅助功能测试 – 测试软件是否向残疾用户提供足够的辅助功能 Localization/Globalization Test 本地化/全球化测试 Compatibility......[阅读全文]

摘要: MSF 团队模型定义了小组同级成员的一些角色和职责，如下图： MSF 团队模型的建立是基于这样一种前提，即任何技术项目都必须达到特定的关键质量目标才能够被认为是成功的项目。如果任何一个角色无法实现其目标，这都会将危及整个项目。因此，每个角色都被认为是同等重要的，重要的决定都要共同作出。相关的目标和角色见下面的表格。   表 1：MSF 团队模型和关键质量目标 关键质量目标 MSF 小组角色 出口条件 按约束条件内交付产品 程序管理 我们的项目是在时间/资源的条件内交付的么？ 按产品规格说明交付产品 开发 我们是否按照功能说明完成了各项功能？ 保证所有问题都得到处理 测试 我们发现了所有的问题，而且都有处理方案？ 产品部署和后续管理 发布管理 客户是否能快速方便地部署产品和进行后续管理？ 让产品更好用 用户体验 产品是否适应用户的使用习惯？易学易用？ 让客户满意 产品管理 客户是否（在总体上）满意我们的项目？ 说白了，一个项目要到达的目标很多，MSF 团队模型 把这些目标让不同的角色去实现。在一个项目结束的时候，每个角色都问自己这样的问题 – 我是否达到了我的质量目标？ 最后比如 – 测试团队（角色：测试）要保证“我发现的所有问题都得到解决”，那么测试团队就会做以下的两件事： 1．发现产品的问题 2．保证这些问题都得到处理   要注意的是，保证这些问题都得到“处理”和得到“解决”是不一样的，有些问题目前不能得到完美的解决，但是可以有让用户满意的处理方案，项目团队不能回避这些问题。   问：我们发现了问题，但是我们目前的“处理”不能让用户满意，怎么办？ 答：测试团队就要和别的角色（如: 产品管理/程序管理/开发）一起研究用户需求，在可能的方案中选出一个：   1． 按照目前的状态交付，向用户说明（如：在某个操作系统/浏览器版本下，某个功能不能正常工作） 2． 推迟交付时间，让团队有足够的时间来解决问题。 3． 修改产品的约束条件（如要求客户的操作系统/浏览器必须是某一个版本以上，或者增加一个附加条件，产品发布后半年会出新的插件解决问题）。 在讨论处理方案的时候，每个角色从自己的质量目标出发，对自己的质量目标负责。   问：那有冲突怎么办？ 答：那就吵呗 （众笑）。各个角色的利益是有一定的冲突的，MSF 没有掩饰这一点。MSF 团队模型的核心是，成功的技术项目必须符合各种利益相关人完全不同的，且常常对立的质量观点。   问：这么说在团队中有矛盾是正常的了？ 答：对！例如，用户代表觉得新增加一个功能很酷，因为新功能“让产品更好用”，但是程序管理角色觉得会影响“按约束条件内交付产品”的目标，测试会觉得“保证所有问题都得到处理”的目标受到威胁，用大白话说，就是“我没有时间测试你的新功能，因此不能加这个功能！”。这就要各方在整个项目的共同利益之下，协商解决。   问：我原来认为测试人员说“我没有时间测试你的新功能，因此不能加这个功能！”是态度问题，会被开发人员鄙视的。 答：这是对产品质量负责的态度，你要代表你角色的利益，如果你有充分的授权和信任，你就要直言不讳。   除了项目的各个角色之外，MSF 团队模型还可以推广到包括操作、业务和用户等外部因素。在对立中寻找共同利益，在冲突中达到平衡。MSF 团队模型推动了不同利益代表在追求共同利益过程中的融合。   MSF 过程模型 每个项目都要经过一个生命周期，下面是 MSF 过程模型生命周期的一个简图。     MSF 过程模型是从传统的软件开发瀑布模型和螺旋模型发展而来的，它把瀑布模型中基于里程碑的规划的优势与螺旋模型中增量迭代的长处结合了起来。   MSF 过程模型的基本元素是阶段和里程碑。所谓“阶段”，就是在这一段时间里团队集中精力做某一类事情，每个阶段的结束都代表了项目的进展和团队工作重心的变化。比如在“开发阶段”结束后，团队就不再允许设计/实现新的功能，除非有充分理由的“变更请求”。   问：我觉得这样也太理想化了，一个十多人的团队，不可能在某月某日同时完成某一阶段，然后第二天进入下一阶段。 答：对，各个阶段之间会有缓冲区，团队中各个功能组的进度是各有区别的，不必强求一律。   团队用里程碑来检查工作是否结束和同步各个角色的进度，以此来确定当前阶段的目标是否已经实现。   此外，里程碑标志着每个阶段的结束，团队在此时应该引导成员转移工作的重心，并鼓励队员以新的视角来看待下一阶段的目标。在上一个阶段产生的各种交付内容，将成为下一阶段的起始点。   MSF敏捷开发模式 在Visual Studio 2005中，MSF演化为以下两个分支： MSF 敏捷开发模式 MSF CMMI 开发模式   我的感觉是，MSF敏捷开发模式吸收了近几年来在软件业界流行的各种“敏捷”开发模式的优点，认识到目前大部分软件是以网络应用相联系，强调和用户更紧密地交流，快速叠代，避免不必要的过程。   在继承MSF3.0 基本原则的基础上，MSF 敏捷开发模式和以前有什么不同？有以下几点： 更强调与用户的交流 项目的商业价值要由用户说了算，那些“我觉得用户会喜欢”的东西要及早和用户交流。因为“我觉得”和“用户觉得”是两码事。   小飞：我说一句可能不太中听的话，我觉得有时用户好像很，嗯，很蠢。和他们交流有时好像对牛弹琴。 二柱：那就派大牛去弹好了。。。 大牛：有这么几种情况： 用户也不懂他想要什么     有些用户只有一个模糊的需求，他们说：我们企业要上ERP！你给我整出来。这种情况下，我们得和用户一起做需求分析。 用户想要的和商业价值无关     比如有些用户说，我想让每个按钮都是半透明的，还要有三维效果，就像一些网络聊天软件一样酷！这些要求和他的企业管理项目的价值没有直接联系。也许这个用户代表是一头牛，而不是用户代表，我们要找管牛的人。 用户想要的我们还不懂      这种情况下，我们是牛，用户是对我们弹琴。 重视防患于未然 防止缺陷的发生成为团队质量控制的首要任务，所有的角色都对防止缺陷的发生，和确保缺陷被修复负责。   有一些团队把开发和测试有意无意地对立起来，好像二者是矛盾的，一个典型的例子是，有时开发人员不想给测试人员足够的信息，好像不想“帮”测试人员找到缺陷；测试人员一旦找到缺陷，会有一些得意的表示 – “看，你写的代码那么臭，我又发现了N 个bug”。   一个大公司内部作过统计，在一个中大规模的团队中，一个“缺陷”从发生到被改正，中间经过了10个人，平均花费的时间是60 分钟。 有时我们吹嘘 “我改正了 N多的bug”， 也许要自省一下为什么会出现这么多。 最好的事情，是可能的缺陷在设计阶段之前就讨论过，并且在代码中已经避免了，因此在“缺陷跟踪系统”中，并且没有出现很多缺陷记录在案。但是软件的质量仍然很高。 重视在实战条件下的质量 保持随时可以发布的高质量       如果用户说：时间到了，网站要上马，我们应该很快地交给用户一个可用的版本，也许有不少功能没有加入，但是版本中包括的功能都可用。  这就要求我们必须保证项目的质量是“随时可用”   重视产品的安装和发布 – 产品要尽早能够达到随时安装，发布。我们以前的项目中，安装和发布都是最后阶段才作，这就导致下列问题 -   1．在开发过程中，测试团队很难安装产品，阻碍了测试团队的进展。很多情况下，测试人员不得不从多个源头拷贝不同的文件到测试环境中，才能测试 2．很多关于安装的缺陷得不到重视 – 用户拿到一个Beta 版，意见最大的就是 - 安装不上！或者好不容易装好了，却卸载不了，不得不重新安装系统。 二柱：好像这个VSTS 早期的版本就有这个问题，真是具有讽刺意义呀。   鼓励团队在实战条件下使用产品，就是“吃自己的狗食”，或者叫“自作自受”。大栓说：所谓“dogfooding”，也不难理解，比如我们小学食堂的伙食都很差 – 可以和“狗食”媲美。 （众人大笑），但是食堂职工无动于衷，因为食堂的领导和职工都是吃自己的小灶。如果食堂的领导实行“dogfood”，身体力行，和食堂员工一起吃给学生做的大锅饭，大锅菜。我想这个问题应该很快得到解决。 小飞：我们要做的项目，怎么dogfood? 大栓: 那我们就自己�