开始--运行--cmd 进入命令提示符 输入netstat -ano 即可看到所有连接的PID 之后在任务管理器中找到这个PID所对应的程序如果任务管理器中没有PID这一项,可以在任务管理器中选"查看"-"选择列"
经常，我们在启动应用的时候发现系统需要的端口被别的程序占用，如何知道谁占有了我们需要的端口，很多人都比较头疼，下面就介绍一种非常简单的方法，希望对大家有用
假如我们需要确定谁占用了我们的9050端口
1、Windows平台
在windows命令行窗口下执行：
1.查看所有的端口占用情况
C:\>netstat -ano
协议 本地地址 外部地址 状态 PID
TCP 127.0.0.1:1434 0.0.0.0:0 LISTENING 3236
TCP 127.0.0.1:5679 0.0.0.0:0 LISTENING 4168
TCP 127.0.0.1:7438 0.0.0.0:0 LISTENING 4168
TCP 127.0.0.1:8015 0.0.0.0:0 LISTENING 1456
TCP 192.168.3.230:139 0.0.0.0:0 LISTENING 4
TCP 192.168.3.230:1957 220.181.31.225:443 ESTABLISHED 3068
TCP 192.168.3.230:2020 183.62.96.189:1522 ESTABLISHED 1456
TCP 192.168.3.230:2927 117.79.91.18:80 ESTABLISHED 4732
TCP 192.168.3.230:2929 117.79.91.18:80 ESTABLISHED 4732
TCP 192.168.3.230:2930 117.79.91.18:80 ESTABLISHED 4732
TCP 192.168.3.230:2931 117.79.91.18:80 ESTABLISHED 4732
2.查看指定端口的占用情况
C:\>netstat -aon|findstr "9050"
协议 本地地址 外部地址 状态 PID
TCP 127.0.0.1:9050 0.0.0.0:0 LISTENING 2016
P: 看到了吗，端口被进程号为2016的进程占用，继续执行下面命令： （也可以去任务管理器中查看pid对应的进程）
3.查看PID对应的进程
C:\>tasklist|findstr "2016"
映像名称 PID 会话名 会话# 内存使用
========================= ======== ================
tor.exe 2016 Console 0 16,064 K
P:很清楚吧，tor占用了你的端口。
4.结束该进程
C:\>taskkill /f /t /im tor.exe
其他不懂的用 help吧~
摘要：作者以自己多年在测试领域尤其是在自动化测试中的经验，从管理层面讲述了自动化测试相对于手动测试的优势；并且从不同的方面论述了目前大家对于自动化测试的错误认识，同时让大家充分意识到推行自动化过程中会面临的困难。
关健词：自动化测试；手动测试；
如今自动化测试以其执行速度快，结果反馈迅速的最大优点获得了业界的广泛认可，尤其在如今需求快速变化的今天，大家对于自动化测试的需求和渴望更是到了一个空前的地步。诚然，自动化测试受到大家的追捧是有充分的理由，因为相对于人工测试，它有着不少的优势。我们且来看看。
1、自动化测试的优势
1.1 对程序的回归测试更方便
回归测试可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。
1.2 可运行更多更繁琐的测试
自动化的一个明显的好处是可以在较少的时间内运行更多的测试。而且人工测试在面对多轮重复执行时，测试人员往往会趋于倦怠，而这将对产品的测试质量带来其他的损害
1.3 可以执行一些手工测试困难或不可能进行的测试
比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的。
1.4 更好地利用资源
将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。
1.5 测试具有一致性和可重复性
由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，这样使测试结果具有可对比性，并且达到测试的可重复的效果。
1.6 测试的复用性
由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。
1.7 增加软件信任度
由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。
因为自动化测试现在如旋风之势席卷而上，特别是全球风靡于敏捷开发之后，更是把自动化测试提高到了一个史无前例的高度。而且人工测试具有更敏锐的观察力，能从一个稍纵即逝的小异常中挖掘出大问题。
另外有些测试是必然需要人工干预的，如冷启动机器，如需要人的感官去体验的。那么如果真的需要追求100%的自动化测试覆盖率，我们唯一的选择就是牺牲这部分的测试案例来成全100%，这对于测试覆盖率也是很大的一个损失。
而从投入产出比的角度来看，以目前对各组织的统计而言，60%是一个比较合理的值，如果要高于这个值，那么付出的人力将是成倍增长的。在我们的组织中一度自动化测试覆盖率的要求是95%，曾经我们也勉强达到，但是投入的代价是不可维续的。所以我们过后调整了我们的合理期望值。比如说在比较简单的功能性测试中自动化测试是比较容易的，但如果是涉及模块和网元很多的系统测试或互通性测试中就显得相当的力不从心了。
2、自动化测试是适用于任何情况的
2.1 自动化测试是适用于任何产品的
并不是所有的产品都适用于自动化测试的，如果这个产品只会做有限的几轮测试，接着就不会再有持续的开发。那么就没必要使用自动化测试，因为这样的投入产出比比较低。毕竟在开发自动化测试阶段需要耗费大量的人力物力。对于决定自动化一个测试用例的一般规则是这个测试用例必须被运行 4 次以上。这个数字是基于用户对测试工具有良好的技能并且有一个良好的测试框架的。如果情况不是这样的话，整个数字能够是 10-20次或者更高。
再者如果变化比较大的话也不适用自动化测试。国内多数软件公司是针对最终用户进行项目开发—工程性质的软件，而不是产品开发。项目开发周期短，不同的用户需求不一样，而且在整个开发过程中需求和用户界面变动较大，这种情况下就不适合自动化测试，对于不停变化的需求和界面，可能修改和录制脚本的工作量大大超过测试实施的工作量，运用测试工具不但不能减轻工作量，反而加重了测试人员的负担。
2.2 自动化测试是适用于任何测试阶段的
版本经理通常认为自动化测试能运用于任何阶段的万能钥匙，但事实上从本人的经验来看，自动化测试适用于回归测试，但不适用于新功能的测试。首先因为新功能刚递交之时稳定性是不可保证的。而自动化测试对于其不稳定性是相当敏感的，所以通常都无法正常的运行完测试，也无法达到我们尽快得到结果的预期。其次在新功能刚递交时其期望结果是不可预知的，这对于自动化测试脚本的编写带来了极大的不确定性。最后在新功能递交阶段是需要我们发现大量问题的时候，而自动化测试无法担此重任。
2.3 自动化测试是适用于任何组织的
在最初尝试自动化测试的时候，是需要投入相当的人力和物力去选择自动化工具，构建自动化测试的框架，做必要的技能培训，摸索编写自动化测试的脚本，如果一个组织无力承负这样的代价，那么是不适合自动化的，否则只能是半途而废的下场。
即使我们澄清了这些误区，我们对于自动化测试有了一个比较清晰的认识，也对其有了一个正确的期望，但实际在推行的过程中我们还是会遇到不少的困难，而困难主要来自于以下几个方面。
3、自动化测试推广中的困难
3.1 来自于测试人员的不接受
因为测试人员是自动化测试的主体，他们承担着转型的重要职责，所以他们的接受与否对于工作的展开是尤为重要的。但作为一个新生事物，通常是不太容易被接受的，尤其是在大家觉得原有的模式很舒服很习惯的情况下。所以在最初的阶段完全是强推。而经过一年的努力，当作年终总结时，所有的测试人员都说那年最艰难的是自动化测试，感触最深的是自动化测试，从中学到最多是是自动化测试，而且发现自动化测试的确帮了很大的忙。
3.2 来自于测试人员技术上的不足
测试人员很多都不具有编程的经验，但自动化测试脚本的编写还是需要一定的编程功底，如果组织中专门有一个具有编程功底的团队能开发自动化测试的工具，并且根据手动的测试案例编写自动化测试的脚本，那状况可能会好些。但目前更多的组织是需要人人能编写自动化脚本的。而在我们的转型中我们经历了三个阶段，基本完成了能力的建设。第一阶段以能用为目的，专门有人提供所需的函数，测试人员只需调用这些函数完成自动化测试的目的，不需要考虑程序的可移植性，可复用性。第二个阶段每个人会写一些自己所需要的函数，并且具有良好的移植性和灵活性。第三个阶段每个人会写能为他人复用的函数并且遵循制定的规范。这样的转型虽然慢但却是比较稳妥的方式。
3.3 来自于组织内其他人员的阻挠
在自动化测试的初期阶段，必然是会耗费相当多额外的精力去构建环境等等，而且我们也需要时间完成技术上的积累。所以这时候不得不像项目经理去索要更多的人力。这是一个长期受益的举措，但对于当前而言似乎是利大于弊的。所以会遭受各方各面的压力，尤其是来自于项目经理的压力。我们很幸运我们走过来了，而现在当所有的人尝到了甜头之后，对于自动化测试的支持程度也大大的提高了。
以上是笔者在经历自动化测试转型过程中的一点体会，希望能对其他正在转型或者准备转型的组织能有一些帮助。
问题描述：
ericzhangali：
用三个角色来描述：开发部门，测试部门，客户。
公司和客户合作的方式是根据客户一个模糊的需求做出原型，由客户使用后一次次提出修改意见，一次次修改后由客户决定何时可以量产。
目前的流程是：
1）开发人员有新版本直接release给客户，以改动大小和多少决定是否送测试部门测试。
2）客户收到版本后评测，把修改意见反馈给开发人员。
3）测试部门收到测试需求后测试，并把测试结果反馈给开发人员。
出现的问题是：
1）如果开发人员决定需要送测，往往也是在送测的同时已经release给客户。测试是否失去了部分意义。
2）开发人员只关注客户反馈的需求和bug，并不关心测试部门反馈的bug。测试是否失去了部分意义。
3）测试人员不了解客户需求，测试工作无法把握重点。
4）如果流程管理认为测试部门应该把握release产品的质量，要求每次release前都要送测，是否合理。（背景是经常客户要求很急，上午的电话或mail，下午就要新版本。）
希望讨论的问题除了上面的之外还有，
1）项目经理/产品经理如何协调这三者的关系？
2）与客户打交道的窗口是在开发部门合适还是在质量部门（测试部门）合适？
（虽然与测试紧密相关，但揣测一下，觉得还是发在项目管理区。）
精彩回复：
AlexLJM：
1）如果开发人员决定需要送测，往往也是在送测的同时已经release给客户。测试是否失去了部分意义。
这种是Alpha和Beta测试同时进行。其实关注点不同，不能就说就没意义。
2）开发人员只关注客户反馈的需求和bug，并不关心测试部门反馈的bug。测试是否失去了部分意义。
如果开发不关心测试的意见，那按照我们这里的话来说就是瞎忙活。测试最终的目的是为了更好的为产品质量服务。其实我们有时候的角色也有点Client。把1）和2）和起来看。这产品就根本不需要测试跟进。
3）测试人员不了解客户需求，测试工作无法把握重点。
没有需求的测试是盲目的。盲目的测试有时候不仅提高不了产品质量还会给整个产品带来副作用。不过很多公司都没有书面需求的习惯。这个时候就要测试人员具有需求分析的能力甚至要亲自收集客户的意见。
4）如果流程管理认为测试部门应该把握release产品的质量，要求每次release前都要送测，是否合理。（背景是经常客户要求很急，上午的电话或mail，下午就要新版本。）
按照我公司的流程。这个版本是不可能出去的，除非研发自己承担后果。（我公司产品release一般需要QA部门的签字）
1）项目经理/产品经理如何协调这三者的关系？
项目经理更多的是要对产品负责，产品经理则要对客户负责。项目经理负责研发/测试的梳理和协调工作。产品经理负责客户的说服/说明以及协调工作。这里面其实就是项目经理和产品经理之间沟通问题。
2）与客户打交道的窗口是在开发部门合适还是在质量部门（测试部门）合适？
不知道其他公司怎么处理。我公司基本上研发/测试都有与客户打交道的机会。测试部门甚至以后会成半个客服部门。我觉得无论研发还是测试，都应该多了解市场，多了解客户的想法。具体到打交道，一个项目的研发/测试主要负责人一起出发。呵呵。
鹿鸣：
按照标准的开发流程，任何不经过测试的产品，都不能发给客户。
没有测试部门的确认，软件产品的质量问题由项目组负责，测试部门不承担任何的责任。
如果开发部门不支持测试部门的工作，测试部门有权利不测试产品。
“测试人员不了解客户需求，测试工作无法把握重点。”这个问题问的很好，每一个测试人员对此都会迷茫，主要是时间和经验的关系，小软件好把握，但大的系统，如果没有经过系统的培训是很难了解软件过程的。所以真正测试行业软件的时候，都需要有相关行业经验的参加测试小组或做为顾问。测试小组也需要进行一定 的培训。（我测试过很多比较大的家伙，了解那些东西就要花费很长的时间，实际很多的项目，测试3、4次才知道里面的东西具体是怎么运作的）。
上面是测试部门的一些事情。下面说说管理方面的。
在实际过程中，测试部门一般都比较的弱势，除非公司特别重视产品的质量。很多的时候，留给测试的时间都不够，在软件行业的都知道，项目很少有按时完成的， 基本都会拖期，这个时候影响最大的其实就是测试。如果客户急着要，即使产品没有经过严格的检验一般也都发出去了。
项目经理的责任就是严格的掌握开发时间，了解客户的需求，和测试部门进行协调，准备好一切测试部门的相关资料。（现在程序员都在赶进度，基本没有文档，所以在测试前写测试用例是基本不可能的，反正至少在我工作过的公司，无论是程序员的设计还是测试人员的用例等，都是事后补的，这是没有办法的事情）。
在很多的时候，测试部门可以说是代表客户利益的，但真正成熟的软件公司，分工都很详细，比如有专门的需求设计人员，负责和客户打交道；还有专门的售后服务技术支持人员；通常测试部门只负责产品的质量，不会和客户发生关系。
AlexLJM：
在很多的时候，测试部门可以说是代表客户利益的，但真正成熟的软件公司，分工都很详细，比如有专门的需求设计人员，负责和客户打交道；还有专门的售后服务技术支持人员；通常测试部门只负责产品的质量，不会和客户发生关系。
我们公司以前就是这样做的。可惜在定位一些问题要不要改善的时候，经常要经过一个流程才能反馈回结果，有时候这个结果根本就不符合我们的需要。后来痛定思痛，决定减少这个流程。
鹿鸣：
测试部门测试完毕签字确认后，实际就已经和项目没有什么关系了。除非有太大的质量问题出现，表明是测试部门的责任，这个时候会由公司给予测试部门相应的处罚，与客户或项目组无关。
至于客户的问题，应该有技术支持人员（通常由开发人员兼职或转职）解决。
技术支持人员解决不了的问题，如果原项目组还存在，反馈给项目组；项目组解决不了的，就告诉客户下一版本解决，能拖则拖，拖到客户忘了为止。
如果项目组不存在，而问题真的很多，客户还必须使用这个软件。那真是太好了，赶紧重新组织项目组，开发2.0，又能挣一笔钱，哈哈。
AlexLJM：
技术支持人员解决不了的问题，如果原项目组还存在，反馈给项目组；项目组解决不了的，就告诉客户下一版本解决，能拖则拖，拖到客户忘了为止。
如果项目组不存在，而问题真的很多，客户还必须使用这个软件。那真是太好了，赶紧重新组织项目组，开发2.0，又能挣一笔钱，哈哈。
ericzhangali：
同意楼上两位说的流程。但是感觉目前的情况是把测试工作划分一部分到客户的相关部门。客户认同的方式似乎就是发版本给他，他测试，提交bug list和修改意见，修改后再发给他，他再测试。。。直到他满意，这里面的一次次release我个人觉得不是很正式。在时间压力大的时候或改动很微小的 时候，这种不是很正式的release是不是一定要送测，在VSS上打label，然后得到一份不是很关注的测试报告呢？因为同时版本也已发给了客户，也 许很快，客户也反馈了报告。
往往有一个现象就是客户提交的bug list和测试部门提交的差别很大。倒不认为这是alpha和beta同时进行。
这种方式确实测试部门不承担责任。由开发部门/人员承担。
至于测试人员了解需求的问题，情况是，对每个客户，产品的功能大致是相同的，测试人员也是比较了解的，也有老手写好的full test用例和simple test用例。但每个具体的客户可能外观要求不同，有的功能细节有不一致，甚至不同客户关注的问题点也不同。我是指这个情况测试人员不了解，这个情况只有 直接和客户联系的开发人员了解。但开发人员又没有太多时间跟测试人员详细说。
如果把窗口转移到测试部门，不知道客户会不会有意见。他们可能更希望和直接的开发人员联系，提出需求。
ericzhangali：
两位可能不太了解我的情况，我口才有限，觉得有些表达不清楚。呵呵。
我觉得可以理解成原型法的一个挖掘需求阶段，但又不完全是挖掘需求。
大致的过程是：
当接到一个新的客户时，我们按照他们要求的功能和UI大致做一个实现，砍到我们认为我们的solution暂时做不到的，或行为和我们的solution差别比较大的就劝说按我们的方式做。得到这个实现后，客户就不断地测试，递交bug list和需要修改的需求，我们就不断地给他新版本。
这个过程可能超过一个月，频率可能一两天或两三天就发出一个新版。同时我们自己的测试部门也做测试，发现的问题，优先处理严重的。直到客户觉得基本达到其要求，他才会量产、小批的给他的客户试用。然后反馈试用出的问题和需求，我们再做修改。这个频率一般不高。再然后，他才正式量产。
我觉得，小批生产前的是不是属于正式的发布？是否一样地需要严格按流程管理？
AlexLJM：
我觉得，小批生产前的是不是属于正式的发布？是否一样地需要严格按流程管理？
当然不算正式发布，顶多算个验收测试。看你说的情况，严格按照流程管理只会增加管理成本，导致项目延期。
鹿鸣：
现在规模软件开发，重视的是开发流程，努力找到一种适普和容易控制的开发方法。但理论和实践是有差别的，所以才有一个不断调整的过程。这样，根据不同的实际情况，可以对软件开发流程有自己的理解和方法。
现在流行的剪裁rup就是为了适应各种不同的情况而实施的。所以很难说哪个好或不好。但通常情况下，流行的方法都是经过理论和大量实践，所以一般都适合于各种情况。
至于你们公司，是否有修改的可能和必要？如果没有，那么当前这种开发情况就是最合适的。否则可以找咨询公司，为你们公司的实际情况设计一套开发方案，这涉及大量的细节，这里简略的讨论实在不是很合适。
ericzhangali：
呵呵。质量流程部门坚持要每次release前都送测，他们好象不在乎送测的意义有多少。看你说的情况，严格按照流程管理只会增加管理成本，导致项目延期，说服不了测试部门。
我觉得对release的定义模糊。
客户工程师一个电话打来说改一个bug，马上发个新版，是不是一次release。
如果只要有送出就要经过测试的话，我觉得还是由测试部门和客户打交道吧，接收需求，研发修改，提交测试，再送出。至于时间，由测试部门去和客户协调。
wbsndts：
按照这样的现实情况，谈需求的窗口不应该是研发部门了。
ericzhangali：
唉，规则都是人制定的，也都是人执行的，混吧。
由于测试的人远离客户，他们不清楚客户的需求的关注的权重，往往他们报来的bug和客户提出的bug相差很远。我们只能优先考虑客户的bug，而渐渐疏远公司流程中测试活动的产物。
这日子只能先这样过了。。。
摘要：随着计算机技术的普及，软件系统已经深入到生活的各个方面，从普通的计算机软件，到银行或超市的终端系统，甚至到手机的软件系统。对软件的质量要求也在不断提高，软件测试及其技术也有了飞速发展。在对软件测试技术相关基本概念研究解析的基础上，分析软件测试起源与发展，保证软件产品的质量、提高产品的可靠性。对于嵌入式软件系统，因其多样性，基于操作系统，使用的开发环境，微控制器都是日益繁多的，所以嵌入式软件测试与普通软件测试相比有其自身的特点。
关键字：软件测试；嵌入式测试；软件质量
1、引言
嵌入式软件的开发和测试也就与普通软件的开发和测试策略有了很大的不同，嵌入式软件系统是一种针对特殊任务、特殊环境而进行特殊设计的定制产品，有其专门的开发环境、软硬件紧密结合、严格的实时要求等特点。使得嵌入式软件测试与普通软件测试虽有相似之处，但有也有其自身独特的特点。
2、软件测试和嵌入式软件测试
2.1 软件测试的定义及目的
软件测试，即Software Testing。软件测试的定义有很多，在1979年出版的一本经典著作《软件测试艺术》（The art of software testing）中，GLEMFORD
J.MYERS曾经对软件测试下过如下定义：软件测试就是为了发现错误而执行程序或系统的过程。虽然它不太完善，但放在当时的情况下是可以说的通的。
随着计算机和软件技术的发展，软件应用的复杂性和规模的不断扩大，软件测试技术的研究也取得了很大的突破。早期的定义已经不适用了，许多专家对软件测试提出了各种各样的定义。综合起来，我们可以定义“软件测试是由一个程序的行为在有限测试用例集合上，针对期望的行为的动态验证组成，测试用例是从通常的无限执行域中适当选取的”。
长期以来对软件测试存在着两种不同的认识。一种观点认为，软件软件测试的目的是证明 软件的正确性；而另一种观点则认为，软件测试的目的是尽可能寻找软件中隐藏的错误和缺陷。
2.2 软件测试的特点
1）大多数硬件实验失败的方式和方法是固定的，而软件测试失败则是毫无规律的，探索所有软件测试失败的模式是不可能的。
2）软件方面的许多缺陷都源于设计和实现上的错误，而不是源于生产制造方面的缺陷。
3）软件质量保证的关键在于我们如何让避免产生错误和消除已经产生的错误，是程序中的错误密度达到尽可能低的程度。
4）软件测试是一个动态的执行过程，体现在输入、行为和行为的输出结果上。
5）软件测试是一个有限的集合。
2.3 嵌入式软件测试的定义及目的
嵌入式软件是一种比较特出的软件，软件经过分析，设计，编码后只有烧入硬件环境中才可以看见，比如数字电视的中间件软件，洗衣机的自动控制软件，手机游戏软件等等。嵌入式软件测试/嵌入式测试或叫交叉测试（cross-test）的目的与普通软件测试是相同的，都是为了发现软件缺陷，而后修正缺陷以提高软件的可靠性。嵌入式系统安全性的失效可能会导致灾难性的后果，即使非安全性失效，由于其应用场合特殊也会导致重大经济损失。因此，往往嵌入式软件对可靠性的要求比普通软件高。这就要求对嵌入式软件进行严格的测试、确认和验证，以提高产品的可靠性。
2.4 嵌入式软件测试的特点
嵌入式软件测试与普通软件测试相比，有其自身的特点：
嵌入式软件测试是在特定的硬件环境下才能运行的软件。
嵌入式软件测试除了要保证嵌入式软件在特定环境下运行的高可靠性，还要保证嵌入式软件系统的实时性。
嵌入式软件产品为了满足高可靠性的要求，不允许内存在运行时有泄漏等情况发生，因此嵌入式软件测试除了对软件进行性能测试、GUI测试、覆盖分析测试是同普通软件测试一样都不可或缺之外，还要对内存进行测试。
嵌入式产品不同于一般软件产品，在嵌入式软件和硬件集成测试完成之后，并不代表测试全部完成，在第一件嵌入式产品生产出来之后，还需对其进行产品测试。
嵌入式软件测试的最终目的是使嵌入式产品在能够满足所有功能的同时安全可靠的进行。
3、嵌入式软件测试与普通软件测试的异同点
3.1 嵌入式软件测试与普通软件测试的相同点
嵌入式软件测试作为一种特殊的软件测试，它的目的和原则与普通软件测试是相同的，都是为了发现软件缺陷，而后修正缺陷以提高软件的可靠性。它们的中心任务都是验证和确认其实际实现是否符合需求要求，在验证过程中发现系统缺陷。
嵌入式软件测试与普通软件测试具有相同的信息流，如图3-1。
图3-1 软件测试信息流
嵌入式软件测和普通软件测试对象相同，包括软件中所有内容，贯穿软件定义与开发的整个过程。也就是说，需求分析、概要设计、详细设计、程序编码等各阶段所得到的文档及源程序，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应当称为软件测试的对象。
3.2 嵌入式软件测试与普通软件测试的区别
由于嵌入式系统的自身特点，如实时性(Real-timing)，内存不丰富，I/O通道少，开发工具昂贵，并且与硬件紧密相关CPU种类繁多，等等。嵌入式软件的开发和测试也就与一般商用软件的开发和测试策略有了很大的不同，可以说嵌入式软件是最难测试的一种软件。
嵌入式系统由于自己本身的特点，如实时性强、内存不丰富、I/O通道少、开发工具昂贵并且与硬件紧密相关、CPU种类繁多等等，决定了不同的嵌入式系统必须有不同的测试方法。
3.2.1 嵌入式软件测试的各个阶段测试的环境是不一样的
嵌入式软件开发和运行的环境是分开的，嵌入式软件开发环境往往是交叉开发环境。因此，各个阶段测试的环境是不一样的。
单元测试阶段：所有的单元测试都可以在宿主机环境下进行，只有个别情况下会特别指定单元测试要直接在目标机环境下进行。应该最大化在宿主机环境下进行软件测试的比例，通过尽可能小的目标单元访问其指定的目标单元界面，提高单元的有效性和针对性。
在宿主机平台上运行测试的速度比在目标机平台上快得多，当在宿主机平台上完成测试后可以在目标机环境下重复做一次简单的确认测试，确认测试结果在宿主机和目标机上没有不同。在目标机环境下进行确认测试将确定一些未知的、未预料到的、未说明的宿主机与目标机的不同之处，例如，目标机编译器可能有缺陷，但在宿主机编译器上没有。
集成测试阶段：软件集成也可在宿主机环境下完成，在宿主句平台上模拟目标环境运行，在此级别上的确认测试可以确定一些与环境有关的问题，比如内存定位和分配方面的一些错误。
在宿主机环境上的集成测试的使用，依赖于目标系统的具体功能有多少。有些嵌入式系统与目标机环境耦合的非常紧密，这种情况下就不适合在宿主机环境下进行集成。对于一个大型的软件开发而言，集成可以分几个级别。低级别的软件集成在宿主机平台上完成有很大优势，级别越高，集成越依赖于目标环境。
系统测试和确认测试：所有的系统测试和确认测试必须在目标机环境下执行。当然在宿主机上开发和执行系统测试，然后移植到目标机环境重复执行是很方便的。对目标系统的依赖性会妨碍将宿主机上的系统测试移植到目标系统上，况且只有少数开发者会卷入系统测试，所以有时放弃在宿主机上执行系统测试可能更方便。
确认测试最终必须在目标机环境中进行，因为系统的确认必须在真实系统下完成，而不能在宿主机环境下模拟，这关系到嵌入式软件的最终使用。
3.2.2 嵌入式软件测试的复杂多样
因为嵌入式系统的一个突出的特点，是其专用性，即一个嵌入式系统只进行特定的一项或几项工作，嵌入式软件运行的平台都是为进行这些工作而开发出来的专用硬件电路，他们的体系结构、硬件电路，甚至所用的元器件都是不一样的，所以嵌入式软件运行的平台也是复杂多样的。
由于开发平台的复杂多样性，使的嵌入式软件的测试从测试环境的建立到测试用例的编写也是复杂多样的。与不同的开发平台对应的嵌入式软件是肯定不相同的。嵌入式软件测试在一定程度的上并不只是对嵌入式软件的测试，很多情况下是对嵌入式软件在开发平台中同硬件的兼容性测试。因此，对于任何一套嵌入式软件系统，都需要有其自己的测试、创建其自己的测试环境、编写其自己的测试用例。
3.2.3 嵌入式软件测试中对实时性有严格要求
由于嵌入式系统的实时性，决定了嵌入式系统的运行时间也是受严格限制的。嵌入式软件在测试时应当充分考虑系统实时响应的问题，很多嵌入式系统会要求系统的响应时间应在多少毫秒之内。在测试有严格响应时间要求的嵌入式系统时要做负载测试。
3.2.4 嵌入式软件测试需要进行插桩测试
嵌入式软件最终的测试需要在目标机平台上进行，在对目标机进行测试时，我们需要对在宿主机上编译通过的代码进行插桩处理。插桩完成之后，需要重新对代码进行编译，如果编译通过，就可以将编译好的代码下载到目标机上执行。在目标机执行程序的时候，需要将插桩时预测好的数据返回到宿主机上，因此，宿主机和目标机上要有能够相互传递数据的网线或者串口线，宿主机上同时要有能够处理返回的数据的处理程序或软件
3.2.5 嵌入式软件对系统的可靠性和安全性要求比一般的软件系统高
因为嵌入式软件对系统的可靠性和安全性要求比一般的软件系统高，所以还需要进行系统的可靠性测试。对于不同的嵌入式系统，需要制定相应的符合系统需求的可靠级别，在进行可靠性测试时应该将系统的可靠性级别考虑进去。
一些嵌入式系统，比如工厂车间的某些控制系统，他们要在电磁很强的恶劣的环境下可靠的工作，而且要保证操作人员的安全。但是对于手机软件来说，他的可靠性和安全性就不如工厂车间的车床控制系统要求的高。
首先，项目开发初期计划阶段的项目计划评价，计划执行过程中及计划完成报告的评价，并将评价、评审工作在工程实施之前就列入整个开发工程的工程计划中，同时提高软件开发项目管理的精确度。
然后，做好质量保证与检验。其一是切实搞好开发阶段的管理，检查各开发阶段的质量保证活动开展得如何；其二是预先防止软件差错给用户造成损失。为了确保每个开发过程的质量，防止把软件差错传递到下一个过程，必须进行质量检验。质量检验的原则，一、用户要求的是产品所具有的功能，这是“真质量”。靠质量检验，一般检查的是“真质量”的质量特性。二、能靠质量检验的质量特性，即使全数检验，也只是代表产品的部分质量特性。三、必须在各开发阶段对影响产品质量的因素进行切实的管理，认真检查实施落实情况。
当开发阶段出现异常时，要从质量特性方面进行检验，看是否会给后续阶段带来影响。虽然各开发阶段进展稳定，但由于工程能力不足，软件产品不能满足用户要求的质量。这时可通过检验对该产品做出评价，判断是否能向用户提供该产品。要以一定的标准检验产品，根据产品的质量特性，检查各个过程的管理状态。
另外，就是建立软件质量保证体系。软件的质量保证活动，是涉及各个部门的部门间的活动。例如，如果在用户处发现了软件故障，产品服务部门就应听取用户的意见，再由检查部门调查该产品的检验结果，进而还要调查软件实现过程的状况，并根据情况检查设计是否有误，不当之处加以改进，防止再次发生问题。为了顺利开展以上活动，事先明确部门间的质量保证业务，确立部门间的联合与协作的机构十分重要，这个机构就是质量保证体系。必须明确反馈途径。必须明确各部门的职责。必须确定保证系统运行的方法、工具、有关文档资料，以及系统管理的规程和标准。必须明确决定是否可向下一阶段进展的评价项目和评价准则。必须不断地总结系统管理的经验教训，能够修改系统。
质量保证活动的实施步骤
Target：以用户要求和开发方针为依据，对质量需求准则、质量设计准则的各质量特性设定质量目标。
Plan：设定适合于被开发软件的评测检查项目(质量评价准则)。研讨实现质量目标的方法或手段。
Do：制作高质量的规格说明和程序。在接受质量检查前先做自我检查。
Check：以Plan阶段设定的质量评价准则进行评价。计算结果用质量图的形式表示出来。比较评价结果的质量得分和质量目标，看其是否合格。
Action：对评价发现的问题进行改进活动，如果实现并达到了质量目标就转入下一个工程阶段。这样重复“Plan”到“Action”的过程，直到整个开发项目完成。
版权声明：本文出自 cmriqa 的51Testing软件测试博客：http://www.51testing.com/?489136
本文是最近为公司所做的两篇总计之一。主旨是为公司的测试新人指明一些方向，如何融入公司，做好项目，以及提升的一些方向。
公司项目模式
我们是离岸外包公司，通常来讲我们的客户拿项目给我们做，会在我们公司建立一个团队，开发人员和测试人员都在一个团队里面。客户提他的需求，由我们这个团队完全负责分析，设计，开发，测试。
总得来说每个项目的情况都会有些不同，所以各个项目中测试人员的职责也存在不同，比如，有些项目里，测试人员是parttime的；有些项目里，测试人员需要和开发人员一起Review文档。所以具体的所负责的事情需要和具体项目一起来考虑。
一般项目的流程是：
● 需求理解：项目绝大多数都是迭代式开发，在每次迭代初期，在真正编码实现前，开发人员和测试人员会一起对这次迭代的任务项进行一个比较深入沟通，沟通需求，争取做之前双方对即将实现的功能有个一致的理解。
● 开发编码/用例设计：当开发开始编码时，测试人员就需要开始设计测试用例，需要注意的是，在功能没有开发出来的时候，就需要考虑用例，而不是看到具体效果，再设计。
● 测试阶段：执行用例，反馈BUG，验收BUG。
● 提交阶段：系统测试项目，保证质量，避免直接的明显的BUG。
● 收尾阶段：总结、反思。BUG分析报告，迭代回顾会议。
基本要求
由此流程，可以看出测试人员需要做到的事情的一个大致轮廓。
如果是新人，基础不太好，可以看看培训大纲中测试章节，里面有些资源、一些知识点要求和一些常见问题。下面在简单地提下具体的几个方面的要求。
英语要求
能看懂需求，能书写BUG、相关的邮件交流。
测试基本思想
理解边界值，等价类划分，基本流、备选流，场景划分。
需求理解
能够理解文档上功能的描述，知道功能具体是怎么工作起来。放在系统里面通盘考虑。
BUG
对BUG系统的使用熟悉。报告的BUG是符合规范，简洁易懂，不失必要的步骤。
Test Case
跟着模板来写，覆盖到文档里面的所有功能，正常情况，异常情况也需要包含。
Bug 分析报告
根据指导文档，对BUG的数据进行一些统计和分析、思考。最好是日常收集相关的数据。
进阶方向
当加入团队后，上述能力有一个样子，较为稳定的时，一样还需要根据自身的情况进行反思、改进、提升。着眼点需要更加开阔，怎么才能使自己能贡献得更多。下面做一个思路上简单分析，只做抛砖引玉。
提高测试水平
效率更高，发现问题更快：测试数据复用，测试思路总结分享，测试用例模版更新，测试用例、数据设计的总结，经验分享传递等等。
更少的BUG遗漏。
经常了解业界的测试技术、理论、方法论并尝试引入我们的项目当中。
本文是最近为公司所做的两篇总计之一。主旨是为公司的测试新人指明一些方向，如何融入公司，做好项目，以及提升的一些方向。
公司项目模式
我们是离岸外包公司，通常来讲我们的客户拿项目给我们做，会在我们公司建立一个团队，开发人员和测试人员都在一个团队里面。客户提他的需求，由我们这个团队完全负责分析，设计，开发，测试。
总得来说每个项目的情况都会有些不同，所以各个项目中测试人员的职责也存在不同，比如，有些项目里，测试人员是parttime的；有些项目里，测试人员需要和开发人员一起Review文档。所以具体的所负责的事情需要和具体项目一起来考虑。
一般项目的流程是：
● 需求理解：项目绝大多数都是迭代式开发，在每次迭代初期，在真正编码实现前，开发人员和测试人员会一起对这次迭代的任务项进行一个比较深入沟通，沟通需求，争取做之前双方对即将实现的功能有个一致的理解。
● 开发编码/用例设计：当开发开始编码时，测试人员就需要开始设计测试用例，需要注意的是，在功能没有开发出来的时候，就需要考虑用例，而不是看到具体效果，再设计。
● 测试阶段：执行用例，反馈BUG，验收BUG。
● 提交阶段：系统测试项目，保证质量，避免直接的明显的BUG。
● 收尾阶段：总结、反思。BUG分析报告，迭代回顾会议。
基本要求
由此流程，可以看出测试人员需要做到的事情的一个大致轮廓。
如果是新人，基础不太好，可以看看培训大纲中测试章节，里面有些资源、一些知识点要求和一些常见问题。下面在简单地提下具体的几个方面的要求。
英语要求
能看懂需求，能书写BUG、相关的邮件交流。
测试基本思想
理解边界值，等价类划分，基本流、备选流，场景划分。
需求理解
能够理解文档上功能的描述，知道功能具体是怎么工作起来。放在系统里面通盘考虑。
BUG
对BUG系统的使用熟悉。报告的BUG是符合规范，简洁易懂，不失必要的步骤。
Test Case
跟着模板来写，覆盖到文档里面的所有功能，正常情况，异常情况也需要包含。
Bug 分析报告
根据指导文档，对BUG的数据进行一些统计和分析、思考。最好是日常收集相关的数据。
进阶方向
当加入团队后，上述能力有一个样子，较为稳定的时，一样还需要根据自身的情况进行反思、改进、提升。着眼点需要更加开阔，怎么才能使自己能贡献得更多。下面做一个思路上简单分析，只做抛砖引玉。
提高测试水平
效率更高，发现问题更快：测试数据复用，测试思路总结分享，测试用例模版更新，测试用例、数据设计的总结，经验分享传递等等。
更少的BUG遗漏。
经常了解业界的测试技术、理论、方法论并尝试引入我们的项目当中。
什么是公理？在百度百科中可以查到：
所谓公理，就是经过人们长期实践检验、不需要证明同时也无法去证明的客观规律，释义如下：
1）经过人类长期反复的实践检验是真实的，不需要由其他判断加以证明的命题和原理。
2）某个演绎系统的初始命题。这样的命题在该系统内是不需要其他命题加以证明的，并且它们是推出该系统内其他命题的基本命题。
那么在测试领域是否也存在这样的客观规律呢？
我们看到，在不同项目的测试过程中，测试行为的差异如此巨大。在软件测试的七项基本原则中有一条“测试活动依赖于测试的Context”，也就是基于不同版本的应用目标、复杂程度、质量要求以及人员成熟度等等因素，每个测试过程都会有所区别，但不是质量上的差别，而是方法。
因此应该有一些客观规律，它们并不依赖于所测试的对象（路由器还是手机），所采用的开发模型（瀑布还是迭代），TPI模型正是基于这一认识来建立的，不过在TPI模型中有157个非常详细的Checkpoint，它们更像由公理推导出来的“定理”。
公理应该是简洁的，作为测试域的初始命题，从2008年Paul Gerrard （2010年EuroSTAR测试杰出贡献奖获得者）第一次提出“测试公理”概念，目前已发展了16条公理，大家来看看Paul所提出下面这些公理是否可以反驳或证伪吧：
首先是测试第一等式，究竟哪些东西影响了测试的过程和方法：
AXIOMS + CONTEXT + VALUES + THINKING = APPROACH
公理 + 环境 + 价值 + 思想 = 方法
Paul按照3个方面来组织测试公理：利益干系人、测试设计、测试执行与交付。
利益干系人
公理1：测试需要利益干系人
公理2：测试的价值是为利益干系人提供决策依据
公理3：如果我们不约束测试的范围，我们永远无法符合利益干系人的期望
公理4：测试和验收的范围始终是妥协的结果
测试设计
公理5：测试设计基于模型（注：这一模型可能是正式的，由形式化来描述；也可能是非正式的，在测试人员的脑中）
公理6：测试人员需要知识来源（Sources of Knowledge）来选择测试内容
公理7：测试人员需要知识来源（Sources of Knowledge）来评价被测对象的实际产出或行为
公理8：测试需要一个或多个覆盖模型
公理9：测试需要一种机制来排序测试优先级
公理10：测试的知识来源（Sources of Knowledge）是模糊且不完整的
测试执行与交付
公理11：通过利益干系人做决策时的信心来衡量测试的价值高低
公理12：一些重复测试是不可避免的
公理13：先执行最有价值的测试——否则可能没有时间执行它们
公理14：测试执行需要明确、可控的测试环境
公理15：测试永远不会按计划进展，测试所得到的证据按照离散量子化的模式出现
公理16： 测试永远不会结束，只会停止
如果认可这些公理，那么根据它们也就可以推导出哪些实践是正确的，哪些是不那么正确的。
例如公理10：测试的知识来源（Sources of Knowledge）是模糊且不完整的。在绝大多数开发项目中，都存在这样的问题：需求质量很差，测试设计所依赖的许多知识：如应用场景，如系统在异常下的行为和结果，都是不明确的，这也是我们一直希望测试能够尽早投入，通过详细的测试设计来提升需求质量，达到预防缺陷的根本原因。
再例如公理16： 测试永远不会结束，只会停止。无论何时，只要你进行测试，就一定会发现更多缺陷。因此，测试是“Stop”而不是“Finish”，停止的原因是因为我们提供了足够的证据，使得决策者认为剩余的产品风险已经可以承担，已经满足客户的应用期望，因此测试不是“盖章放行”，不是质量的“看门人”。
我很欣赏2009年EuroSTAR中的一个演讲“董事会中的测试人员”，其中Martin Kooij提出随着软件产品对人类的生活变得越来越重要，测试人员的终极职位将是“CRO”——首席风险官，负责监控和管理产品风险（注意，不是项目或金融风险），不过Martin也认为这是在2018年才会发生的事儿了！
本文是最近为公司所做的两篇总计之一。主旨是为公司的开发人员提供一些做自测，界面设计时的思路。
关于开发人员自测
开发人员做好自测，是非常必要和也是大趋势。Google公司里面，纯粹的测试人员是很少的，前期都是开发自测（包含必要的测试），后期才是用户体验方面的测试；从成本上分析，BUG越晚发现修复成本越高；从修改的效率来讲，越早处理会越快。另外，写出高质量的代码，是能力的体现，专业的体现，自身价值的体现。
开发人员自测的困难
就我自己接触到开发人员来看，一般会遇到下面这些困难：时间、进度太紧（也许是由于潜意识里任务完成后满足感驱使的）；对自己的代码过于自信；认为测试是测试人员的责任；不知道如何有效的自测。
思维上
从上面的困难看来，思维上应该先需要转变下。
● 代码质量、项目质量都是自己的责任，提交代码到代码库里，提交版本给测试给客户，都应是经过自己测试的。否则拿出去东西影响其他人的工作，影响客户眼中的印象和满意度，这样带来的危害更大。
● 代码达没有达到效果，健不健壮，不试试，那怎么知道？凭感觉那是不靠谱，实践是检验真理的唯一标准。
为什么开发人员不忍尝试破坏自己的成果了？为什么不能让自己的成果更加健壮？否则就相当于在溺爱自己的孩子。
测试世界的基本思想
● 测试与开发人员思考角度最大不同就是一个破坏软件，一个建造软件。所以想要测试，就应该是考虑怎样才使软件出了点问题？
● 对于任何功能都有基本流和备选流，或者说正面情况和反面情况。这些情况都应该是要需要去测试的。那如何选择测试的数据和路径？
● 有一个重要的概念叫做“等价类划分”，大致可以这样理解，由于测试数据和测试路径理论上讲是无穷尽的，那么就需要对这些数据和路径进行分类，哪些能走到正常情况，哪些能走到异常情况。再从各个分类里面选一些出来完成测试即可，这样覆盖率就会更高，同时测试起来更快。
● 数据选择，选一组正常数据（符合规定，用户可能真正会用到的）；选几组异常数据（特殊符号，不支持，长度大，空的，会触发特殊逻辑的）。
● 路径/场景选择，选一两组最普通的、最直接的、用户最有可能的完成功能的；选几组复杂一点、多次操作、间接完成功能的。
习惯上
改变习惯是非常困难的，坚持完成一个功能就测一个功能（真正带点测试思路去测）；公司推行的规范，Checklist，Code Analysis或者自己总结出来的自测列表等等，也要坚持定期自己检查检查，再认真对待、改进结果。
多总结、反思自己的所犯的问题，这样才能有所提高。测试会帮助你的思维变得更加全面和周到。
关于用户体验
界面设计、动作交互设计、用户体验，这块的重要性应该不需要进一步阐述了吧。
这里也是从思路上简单讲讲怎么考虑用户体验：
● 首先是学习。一般来讲，我们做的东西都不是全球第一，全球首款。那么我们在做东西前，可以学习下模仿下前人已经做出来的效果（切忌只关心功能）。
比如，界面布局；页面 margin，页面中主体的对齐、留白；字体大小、粗细的使用；
其实看到的一切都是可以关注的。
● 平时还可以对自己使用软件和网站进行观察和体会，看看他们做得好的是在具体怎么做。
比如，操作成功、失败的提示怎么表现；注册流程、购物车流程、是怎么进行的；日历控件、向导控件是怎么在用；图片库、视频库怎么放置的，怎么播放的。
● 当我们真正要做的时候，还可以看看那些规范、指南。看看其他人都建议怎么做，建议避免那些效果。
● 最后，我们做的时间，在界面设计上尽量风格统一（按钮大小、颜色，边距，Grid，表单设计等），动作交互设计上尽量和主流的效果一致（如何给出提示信息，如何弹出层，如何做表单的验证）。
关于持续学习和追求精益求精
也是就我自己接触到开发人员来看，很少人会在做之前或者做的过程中，跳出来暂别任务，看看工作任务的技术有没有什么最佳实践有没有其他方案，或者和能力更强的开发人员进行讨论和交流。很多人都喜欢过分独立的解决问题，但问题就来了，一个方面是时间的消耗，另一个方面是容易闭门造车。
另一现象是很多人对其他的人建议反馈或者提出的问题，比较随便，怀着防备的心情，戴着有色眼镜，没有认真考虑和对待，没有考虑是不是自己真的没有做好，真的有问题。
当然这些不是完成任务的必需品，但是我以为这些方面却是一个人成长或者成就的基础。
想要提高，这是你自己的责任，就该想想怎么去解决。态度决定一切，追求卓越。
版权声明：本文出自 omg 的51Testing软件测试博客：http://www.51testing.com/?166582
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
一、介绍
这是一篇英文的文献，昨天把他翻译出来了。觉得还是比较有用，所以决定在这里把它贴出来。原文在：
http://www.stickyminds.com/sitewide.asp?ObjectId=10094&Function=DETAILBROWSE&ObjectType=ART&sqry=%2AZ%28SM%29%2AJ%28MIXED%29%2AR%28relevance%29%2AK%28simplesite%29%2AF%28Test%2Dbased+Project+Progress+Reporting%29%2A&sidx=0&sopp=10&sitewide.asp?sid=1&sqry=%2AZ%28SM%29%2AJ%28MIXED%29%2AR%28relevance%29%2AK%28simplesite%29%2AF%28Test%2Dbased+Project+Progress+Reporting%29%2A&sidx=0&sopp=10
二、摘要
面向交付的项目管理和测试驱动开发能够结合在一起，能够为客户、开发成员和管理者提供客观的更容易理解的方法来测量项目的进度。在这篇文章里，john ferguson smart提供了一个学习用例来说明如何通过这种途径进行工作。
三、名词解析（自己添加的）
3.1 面向交付的项目管理是一种项目管理方法，测试驱动开发是一种开发方法。
3.2 面向交付的项目管理：就是本文说的，把任务分下去，总体任务代表一个总的交付，然后各个子任务代表子交付。项目根据各个交付任务来进行管理。
3.3 迭代的开发方法：就是先完成部分主要的功能，形成一个版本。然后再逐渐添加新的功能，形成新的版本。
3.4 测试用例（test case）：可以理解为就是测试用的程序和方法。每个测试用例对程序的某个功能进行测试，看是否实现了这个功能，有没有bug。完备的测试用例就是对程序的各个功能和稳定性进行全面的测试。设计好的测试用例，才能全面而且尽可能快的完成程序的测试。
3.5 测试驱动开发：表示总的程序需要什么功能，各个子模块需要什么功能。指定好测试用例，程序完成了测试用例的功能，就表示开发完成了。将测试用例用于开发过程中，而不是说先把程序写好了，最后再测试。
3.6 可交付性（deliverable）：可以理解为可以交付的工作产品，就是具备独立功能的一段代码。
3.7 beta版本：beta版本就是软件开发的一个阶段，一般这个阶段，程序已经可以完成大部分的功能，也比较稳定了。一般beta版本开发出来以后，就会提供给用户或者内部人员免费使用，然后根据使用发现的bug，进行修正。
四、可交付性的定义
所有的工程项目，原则上都具有可交付性。如果采用迭代的开发途径，为了制定一个迭代的、基于里程碑节点的交付方案，需要将主交付性可以分成多个小的子交付性。（比如一个应用程序可以分成多个模块、函数或者用户开发实现）。
五、WBS和项目计划
工作分解结构（WBS）是一个大家熟悉的而且非常有用的工具，用来将一个项目分解成容易管理的（也有人说可以消化的，或者可以咀嚼的）多个任务。在一定程度上，你分配WBS任务给单独的开发组成员，（某些时候，是一小群开发成员），然后要求他们产生一个具体的可交付产品。
工作分解结构（WBS）往往是跟项目计划紧密相连。这里，对于工作分解结构（WBS），工作需要细化到每个任务对应一个可交付性的条款，然后分配到具体的小组成员。将具体的交付工作分给具体的小组成员，可以让开发者将开发活动上聚焦在具体的、短期的目标上，同时也可以培养开发者的buy-in能力和责任感。
六、测试用例
自然，我们也为每个交付要写一组测试用例。这些测试用例代表了每个模块可以被接受的标准。可以有很多方法来做测试计划和测试用例。大部分会包含某种形式的，一系列的执行动作和步骤，伴随着特定的结果。在我们的用例中，对于每一个可交付的模块，我们将对应的测试用例填到Excel电子表格中，并加注额外的信息以便容易使用。下面就是Excel表格的表项。
● 一个独一无二的测试用例号
● 显示ID
● 显示区域
● 执行的动作
● 期望的结果
● 得到的结果
→ 结果：通过，失败，还没有测试
→ 描述任何非期望的行为
→ 相关的缺陷追踪问题
根据我们的经验，一组好的测试用例能够很完美的指示产品是否准备好交付。理想的情况，是测试用例和产品的功能定义一同交给开发者，尽管在实际中，测试用例一般要晚一点点。分析文档和测试用例为每一个模块提供了具体的有形的目标，使得开发者能够关注于代码的编写。
七、用测试来衡量进度
7.1 衡量测试结果
基于测试的进度报告能够用一种容易理解的、客观的观点来审视项目进度。在我们的项目中，对每个模块需要报告下面的测试状态：
● 全部的测试用例
● 通过的测试
● 失败的测试
● 还未进行的测试
我们从下面三个主要方面来进行度量：
● 一个模块当所有的测试用例都由QA执行过，并测试成功，这个模块就算完成了。QA包括内部测试组和用户测试人员。
● 测试一个模块需要的测试用例的数目反映了模块的复杂度。虽然不总是这样，但常常如此。
● 开发是迭代的：新版本被频繁的交付，测试也需要不停的进行，而不是仅仅在项目的最后才进行测试。
在这些条件下，各个模块的全部进度都可以通过各个模块的测试用例通过的数目来衡量。如果你能可靠的在特定的时间点（里程碑节点），获得各个模块通过的测试用例数、失败的测试用例数和未测试的用例数，就可以把它制成如图一所示的表格。
图一：测试状态表
7.2 模块进度状态
我从不相信一个开发者说他的一个模块快要完成了。在我的书中，只有所有的测试用例都通过了，一个模块才算完成了。然而，有些被普遍接受的原则认为，如果一个程序，85%的测试用例通过了，就可以进行beta版测试了。尽管你理论上认为必须100%的测试用例通过，才能说产品准备好了，但是我们的用户通常会接受产品，尽管产品还存在一些不严重的问题，并且这些问题在将来能够被修补。因此，我们把模块的“预产品”状态定义为至少95%的测试用例通过并且没有严重的问题。最后，我把模块开发过程的阶段划分原则制定出来。
我们划分成五个状态来表示五个开发阶段，通过测试成功的测试用例的数目来客观的衡量。
● 计划阶段：还没有开始编码
● 开发阶段：开始编码
● beta版本阶段：85%测试用例通过。
● 预产品阶段：95%的测试用例通过，没有发现严重的问题
● 产品准备好阶段：100%的测试用例通过
一旦你有了测试用例通过的百分数，你就对模块的开发进度和稳定性有了一个很好的评价。我们将这些数据用图形来表示，写在每周的进度报告中。
可以将进度表示成紫色的条图，用来指示模块的工作进展。这能够鼓励开发者自发主动的清楚工作的进度。如图2所示。
图2 进度颜色条码图
八、基于测试的进度总览
我们从更高的层次上，通过测试用过的数据来看项目的进度。如图四所示。这图对外行人很容易看懂，在项目的进展报告中，放在在执行总结情况这部分特别有用。
图3 基于测试的项目进展总览图
九、缺陷数据
我们使用的迭代的开发周期，提供了方便的追踪缺陷数据的基础。（译者注：因为迭代是周期性的提交版本，可以周期性的对每个版本测试，发现版本的缺陷）。我们一般一到两周会提交一个面向用户交付的版本，每周或者几天就会提交一个内部版本。新版本的整洁性比增加的模块数目或者修正的bug数目更重要。然而，QA人员在接受一个新版本之前，必须对上一个版本进行一个合理长的时间测试。交付的日期就必须一起商量决定。在期望的交付日期前，我们要考虑交付是否可行（能否修正严重的问题），要考虑哪些新模块以及哪些bug能够对用户声明。
为了实现这个，我们把缺陷数据放在缺陷数据库，从数据库中提取出缺陷数据来衡量产品的质量可可靠性。全局缺陷状态图表示了各个缺陷状态（open, to-be-deployed,pending validation等）的缺陷数目。
我们对每次交付，都要衡量缺陷的状态——记录公开的问题数目和总的问题数。这对于交付规划是非常重要的。
十、历史数据
对于跟踪随时间变化的测试的结果也是很重要。它能告诉你软件的可交付性和稳定性的速度（多长时间可以产生一个交付版本，多长时间可以达到某种稳定程度）。如图6和图7所示。
图6 历史数据：随时间的测试完整性
图7 历史数据：随时间的测试完整性
十一、这个方法不能做的
（译者注：这个方法指基于测试的项目进度管理）
这种方法不完备，也不是要取代传统的项目进度跟踪和汇报。这种方法的特别之处在于它是纯粹面向交付的。因此它能够幸运的忽略哪些诸如延时、开销、资源消耗、关键途径等等术语。这些术语能够而且应该被诸如Gantt图，PERT图等代替。实际上，这种方法能够给上层管理人员、小组成员和项目投资人等一个项目进度的直观表示方法。基于测试的交付状态是一个重要的而且容易理解的项目汇报方式。但是延迟、花费和面向任务的观点同样重要。
十二、对这种方法的评价（自己添加的评论）
测试用例的设计非常重要，要完备，系统。要有机制对测试用例的优先级进行设定，哪些优先级高，先实现；哪些没那么重要，后实现。 对各个测试用例要归属各个版本，哪个版本应该实现哪些测试用例。要设计好。
敏捷开发（Agile Development） 随着“敏捷”一词出现在越来越多的项目中，于是，敏捷开发本身也被赋与了越来越多的意义，而敏捷的真正内涵反而变得越来越模糊。如何迈出敏捷开发第一步？是按照敏捷宝典、操作指南或是教父语录，还是因地制宜、因项目定方法？完成所有这些工作后，我们就真的“敏捷”了吗？
一、前言
Agile是指企业能够对外部环境做出速捷、有效的反应，是未来企业的必备素质。21世纪企业面临的竞争环境将是一个不断变化、不可预测的环境。由于高新技术的出现和更迭越来越快，产品的生命周期日益缩短，企业要面对这样的新的竞争环境，抓住市场机遇，迅速开发出用户所需要的产品，就必须实现敏捷反应。
狭义地讲，敏捷企业就是将柔性的先进制造技术、熟练掌握生产技能、有知识的劳动力以及促进企业内部和企业之间的灵活管理三者集成在一起，对千变万化的市场机会做出快速、有效的响应。敏捷企业强调人、组织和技术的有机结合。通过这三者的紧密结合，敏捷企业可以发挥最佳的整体效益。评价一个企业敏捷性的具体指标是时间、成本、稳健性（Robustness）和适应范围。对敏捷企业的广义理解，可以认为敏捷企业是一个CIMS（计算机集成制造系统）、动态联盟、并行工程、仿真制造、高素质员工等多方面的系统集成，是一个基于CIMS、在CMS基础上发展起来的一个更高层次的集成大系统。
二、变味的敏捷
敏捷是大家在一起高效率地工作，清除所有沟通上的障碍，关注于增值的活动，从而使得开发更加成功。敏捷是大家肩并肩地工作，而不是什么都通过文档。敏捷是管理者积极地参加到项目管理中而不是整天去写状况报告，用那个来监督到底发生了什么事情。敏捷是开发人员和涉众（项目开发中涉及的从需求到最后交付的各种人员）在一起制定实际的计划，而不是用复杂的微软Project去制定一些几乎没人看的进度表。
公平地说，很难设想敏捷术能如何发挥作用，尤其是在一些软件开发本身都问题重重的传统组织中，被误导过的敏捷更是难以帮上什么忙。
敏捷开发，看到过这个词时，很多人一直没有什么深刻的体会，也没有仔细去研究到底什么才是敏捷开发。而一直在很多人的思想里，敏捷开发的印象就是，开发速度比较快。没错，做互联网的，快确实是一个制胜的法宝，那么敏捷开发似乎也就是在互联网应用的开发中最适合的方法了。那么敏捷开发中的参与者应该是什么状态？这似乎成了一直以来困扰很多管理者的严重问题。可以说，在敏捷开发中，并没有觉得有多敏捷，进度一拖再拖，问题一个接着一个，让我觉得我们是在进行慌乱开发。为什么会这样？
另外，关于实施敏捷的效果也是充满置疑之声。我们经常看到一些号称Agile的国内项目，按照菜谱、操作指南和教父语录的提示，采用了许多花哨的技巧和实践（做法），是啊，表面上确实Agile了，那么结果呢？项目还是不能按时完成，甚至严重超支和超时，这能叫“敏捷”吗？
三、敏捷十戒
1、天报制度
就算是进行远程开发或是两地使用开发，项目组的成员每天至少碰一次，不管是当面的，还是通过其它方式，如通过电话、email、Skype或其它。进行敏捷开发的时间，任何团队都不能以任何理由进行孤立的开发。
2、例会制度
即使每天通过Email给主管汇报工作，但有时主管还是无法及时准确的掌握项目组成员的状况及工作量。此时，通过每周一小时左右的例会将会有效的解决此问题。通过例会，大家面对面的就某些问题进行共同的探讨与讨论，找到共同的解决方案。
3、版本控制
如果没有一台干净的电脑来进行团队代码管理的话，则很有可能导致代码的混乱。而每天只须花很少的时间，哪怕一天一次，进行及时的数据提交与代码提交，则可以有效的保证团队之前代码的同步及代码的备份。
4、需求失灵
即使手里拿着30页且客户进行了签字的需求说明，有可能仍然不知所措。相对起那些良好的设计、精确的分析等，与客户持续的沟通、及时的反馈、不断的演示这些工作显得更加的有效果。可以有效的获得需求变化，减少误解，更加准确的把握用户的需求。
5、单元测试是QA的工作
很多开发人员，甚至一些高级的软件开发人员，对于单元测试没有足够的认识，在行动上也没有足够的注意。大家都一致的认为那是QA的事情。就开发人员来讲，单元测试应该是一种白箱测试，能从功能上充分的测试软件的功能性。而对QA来说，只能是一种黑箱测试，无法深入的去分析代码的优势，只是从用户的角度进行功能上的测试而已。
6、质量保证是QA的责任
自从有了质量管理这个词以及后来产生的质量管理部门后，很多开发人员就理所当然的认为质量保证是QA的责任了。其实每一个人都需要对软件的质量负责，特别是开发人员。Bug越最早发现，那么解决它的成本就越低。
7、项目进度风险控制
也许一个项目需要18个月左右才能完成，但在没完成之前，谁也无法进行比较准确的时间估计。无法确定需要多长的时间进行设计、编码及软件组件的组合。但进行项目设计、实现及融合的人应该相对比较准确的掌握与估计项目的时间。因此，需要进行项目进度的风险控制，风险总是存在的，但要进行有力与及时的控制。充分意识到项目中可能会存在的风险因素，在制定计划时预留一定的时间，如果在项目进行中出现了没有想到的问题，根据其重要性，考虑压后解决，要在计划的时间内把计划的事情完成好，并为后续解决问题争取更多的时间。
8、架构师身体力行
很多软件架构师基本上不写代码，这也许是好事。软件架构师嘛，当然是比较高级的，他们对环境、语言、类库方面都可能比软件开发人员要更加在行，但他们一般不编码。这样的架构师是危险的，特别是那些基本上不与首席开发人员进行沟通或咨询的架构师，离项目失败可能已经不远了。
9、牵一发而动全身
很多时间，在功能上做了一个很小的变动，往往导致花费好几天的功夫来进行软件的集成与整合。如果没有持续的整合、及时的回归测试、可靠的整体设计，一些看起来非常微小的修改都有可能导致很大的麻烦。
10、加大管理执行力
目前项目中，开发者或者说参与人的状态是混乱的，或者说是慌乱的。那问题在哪里呢？是工作流程出了问题？不应该啊！在项目启动前已经定了一个看似美好的流程，而且是经过参与人讨论一致通过的。那么问题在哪里呢？原来是沟通、传达出了问题，执行力不够。那么，就必须加大执行力，今日事今日毕，这是必须的。
另外，在一些产品级的软件开发中，觉得要实施敏捷式开发，我觉得也有一个不好解决的问题：没有具体的客户！没有具体的客户，那你的沟通去哪里寻找呢？一般的做法也是给一些有兴趣的用户发布Alpha版本，或者是beta版本的软件。可是当软件都到了Alpha/beta版本的时候，软件还有迭代的余地吗？未必！从我个人理解的角度来看，敏捷开发的适用范围还是很有局限性的。个人认为最适合使用敏捷开发的软件必须要有非常明确的客户才能进行，而有明确客户的情况以定制型软件为主。所以，我觉得最适合用敏捷方式开发的软件应该是——定制软件！
四、小结
记得Jim Highsmith在他的《敏捷项目管理》一书中这样写道：敏捷是指在动荡的业务环境中，适应变化并创造变化，从而获得价值的一种能力。同时敏捷是平衡灵活性和稳定性的一种能力。由此可见，望文生义地把“敏捷”理解为“做得快”也颇可商榷。如果缺乏有效的实施指导、忽视严格的敏捷实践，单凭着高层面的理解甚至“文化”就开始盲目前行，往往会因为缺乏对质量的有力保障而失去平衡，最终欲速则不达。
版权声明：本文出自 jessegao 的51Testing软件测试博客：http://www.51testing.com/?369515
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。