标签：
质量保障
首先， 两个公式
软件 = 程序 + 软件工程
软件质量 = 程序质量 + 软件工程质量
程序的质量：
程序的质量体现在软件外在功能的质量。衡量软件的功能，基本的判断可以用“是|否”来判断，例如，一个字处理软件能否通过拷贝/粘贴与其他软件传递信息。进一步，可以用复杂的多维度特征的综合指标来衡量，例如，衡量一个搜索引擎的质量，业界通常用精准度和覆盖率的中和指标来表示。各种功能还有很多特征需要衡量，例如，网站显示查询结果的速度；订票网站能并发处理业务的吞吐量；支持同时在线用户的数量。程序的质量还有其他方面，例如用户体验的质量、国际化的质量和安全性的质量。
软件工程的质量
软件的开发过程由三个主要的特征：“好”、“便宜”、“快”。通俗的理解是“软件在功能、成本、时间三方面满足利益相关者的需求”。前面提到功能方面的质量与具体程序相关，那么软件工程的质量就与“快”、“便宜”比较相关。一个团队也许可以靠一些特殊的方法来提高程序的质量，但软件工程的质量需要长期的过程来提高。
在此，引用一篇书上的链接推荐的文章
本文的作者Sriram Krishnan是一名程序员，曾在Yahoo和微软工作过，开发过很多软件，曾被纽约时报报道，写过一本书，本文是他的一篇博客。
这些年来，我对测试工作、测试人员，以及整个软件质量管理体系形成了一些明确的观点。受一篇关于Facebook的测试的帖子的启发，我想把这些写下来，用以拿给人看。有些观点是有争议的。事实上，即使在交谈中稍微表现出这样的看法，都会招致人们的鄙视。
- 大多数的开发团队并不需要一个独立的测试角色。即使有一个，他的所有的开发时间比上所有的测试时间应该 >20:1。证据吗？光看看一些从古至今最成功的软件开发团队就知道了。不论是当今的Facebook，还是30年前最初的NT团队，很多伟大的产 品都是出自没有或很少测试人员的团队。
- 开发人员应该测试自己的代码。没什么可说的。背后的道理并不重要。这包括单元测试，全覆盖的自动化测试或手工测试或组合测试。如果你的开发人员不能/不愿意或认为这“不归我管”，那你需要更好的程序员。
- 我有一些政治上不正确的话要说。一些大型的软件开发公司会从一些不能胜任开发工作的程序员中选择测试人员。我经历/听说过很多在面试开发人员过程 中有人说“他/她做开发不行。也许可以做测试？”这导致了一个被广泛默认，但很少公开宣称的认识：做测试的不如做开发的聪明。正是由于这普遍的偏见，少数 一些对质量和测试工作极具热情和天赋的人受到了不公平的待遇。我知道他们，因为我曾经和一些这样的人一起工作过。
- 追求代码测试覆盖率是危险的。因为它很容易测量，它经常会变成真正目标的替代品——开发有质量的软件。如果你的开发团队把功夫都用在写愚蠢的测 试，来覆盖每一个罕有能用到的代码路径——因为这些数据会出现在一些报告里——你有问题了。测试覆盖率只是我们用的的很多指标中的一个，你需要使用它，但 并不是因为它以自然的数字呈现，它就能压倒其它指标。它成了古德哈特定律的牺牲品。
- 我也曾看到有些公司里有独立的测试人员，他们写出非常好的测试代码。不幸的是，这被人们当成了一种常识，即使是在根本不需要这样的时候。
- 正像测试覆盖率被过度使用，有些质量指标是被忽略轻视了。比如：过程中产生了多少技术支持邮件？自己是否在任何时候都在真正的使用自己的产品，检测里面的问题？分析从生产环境和客户安装那里产生的日志文件。所有的这些策略都在上面的Facebook的帖子里有提到过。
- 技术领导的一个常见的减少测试队伍的体积的办法是做自动化测试。这是个巨大的错误。如果你有一个用户直接接触的产品，你绝对需要用人眼去测试它。 如果你和微软Windows团队的人坐下来一起和咖啡，你会听到他们抱怨过度依赖自动化测试导致了Windows Vista大量的bug。这个错误说明的问题就是：你需要一个全职的测试人员来使用你的产品。
总结
分工是社会和行业进化的结果。开发和测试其实是软件工程的两个分支。不同的软件和服务需要不同方式和程度的测试。独立专业的测试角色等同于第三方代表队产品质量进行测试和验证。那么一个团队应该如何培养和安排每个角色呢？
标签：
原文地址：http://www.cnblogs.com/xiaoxt/p/5528524.html
