现代软件工程第十四章【质量保障】练习与讨论

15.3.1 有些成功人士或公司认为不需要独立的测试角色（Test），你怎么看？

我猜想和踢足球类似，还是那几个原因：

创新互联公司专注于忻府网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供忻府营销型网站建设，忻府网站制作、忻府网页设计、忻府网站官网定制、微信平台小程序开发服务，打造忻府网络公司原创品牌,更为您提供忻府网站排名全网营销落地服务。

人太牛： 不世出的天才，例如高德纳写书时发现排版软件不好用，就自己写了一个。也没听说他为这个软件项目请了什么独立测试人员。对了，他不读Email，有秘书帮他处理这些事——这也是一种分工！

有些软件工程师是在后台钻研和开发高难度的算法，或者做某种后台的处理工作，这个工作本身的难度较高，测试主要是自己通过工具完成。如果一定要找一个测试人员，这个测试人员的水平要相当高才行，如果水平那么高，那就不如也一起参与开发就好了。

事太小：“我写了个小类库，全部自己测试”，这当然不错。

但是如果由此论点出发，大力顺水推舟，推广到所有情况，从而得出“程序员就应该自己测试，专职测试不需要”这样的结论，明显不合适。

人不够： 那就自己动手多做一些事情，也挺好。就像前面提到的，一个人可以扮演多个角色。

无知：      这就不好说什么了。

15.3.2 为什么一些成功的公司不用测试人员

引起网上讨论的两篇文章在这里：

http://sriramk.com/blog/2012/01/testing.html中文翻译在：http://www.aqee.net/on-testers-and-testing/。

http://www.quora.com/Is-it-true-that-Facebook-has-no-testers

其中打分最高的回答来自前雇员（Evan Priestley），他总结了Facebook这个公司为什么貌似没有全职测试人员：

a)         全公司人员经常使用自己的软件产品！（如果你开发的软件是航天飞行某控制模块，你怎么能经常使用呢？）

b)         使用log来分析问题可能出在哪里。（我们的一些程序员写程序都没有log，那大家看什么呢？）

c)         利用用户的反馈和实时状态分析（比较过去一小时和上周同一时间的数据来判断是否有bug。）

d)         应用开发商给Facebook报bug。（开发商其实比较不爽，但是FB有时就是无预警地修改API，你除了赶紧报bug，还能怎么着？）

e)         很多人自愿给Facebook报bug，这位贴主自称每月给他的前雇主报13,000个问题。（没错，是每月一万三千个！）

f)          最后这位前雇员还加了一句：还有一个原因是，Facebook大体上也不需要搞出太高水平的软件。

当你的公司也能有a）到e）这样的文化、流程、开发商和给力的前员工，而且你的软件“大体上也不要太高质量”，你的确不需要什么全职测试人员！

15.3.3 微软是怎么做的呢？

就像MSF原则讲的那样，有分工，有合作。微软开发测试主要有三种角色[i]：

• SDE：Software Design Engineer，简称dev。

• SDE/T：Software Design Engineer in Test，也写代码，但是重点在测试。

• STE：Software Test Engineer。

对于如何更有效地开发互联网应用，微软很多团队都做过不少探索。微软公司在创业之初也没有多少专门的测试人员，在1984年的时候，开发：测试的比例是20:1.  后来随着产品线的变化，有些项目的测试人员比例几乎和开发人员一样多。最近，一些团队，是做互联网业务相关的，尝试把SDE和SDE/T合成一体。每个人都负责开发/测试/发布这一整套流程。这种做法，根据我的观察，有好处，也有额外的成本。

15.3.4 团队应该如何安排QA 和测试工作

测试、质量保障、软件工程的质量，团队和个人到底应该怎么办呢？我认为，

• 在初始阶段（新项目，团队进入一个新领域，人员刚进入一个项目），每个团队成员都要尽量打通各个环节，多负责，把所有事情都搞懂，培养通才。

• 当项目/产业发展到一定阶段（进入阵地战的时候），要大力提倡分工合作，培养专才。同时，要把好的工具和流程集成起来，从每日构建，到基本功能的自动化，都要尽快实现。

• 把自己项目的架构和流程做好，让所有人都能比较容易地进行QA工作，这样，团队的“软件工程质量”才会有提高。

• 培养“大家都要做QA，专人负责量化的Test，有条件多做测试自动化”的文化。

• 要明白自己项目的特点，避免照搬别人的做法。不要听说某某伟大的项目的开发/测试比例是多少，因此就哭着喊着也要同样的比例。

• 如果一个团队是认真严肃地做软件，那他们一定要考虑如何保证程序的质量/软件工程的质量，以及达到这些质量，需要多少成本。

15.3.5  测试人员的职业发展

分工之后，每人负责一小块东西，怎么才能体现出个人的独特而巨大的价值呢？例如，你刚到一家出版社，领导让你做“二审”这份工作，或者你刚到一个软件公司，领导让你做“测试”这份工作，你怎么才能展现出你独特的价值呢？

请找到几个软件测试工程师（例如，软件学院的测试专业早几年毕业的师兄师姐，测试论坛上活跃的用户，软件公司的测试人员），和他们了解并探讨测试这门专业。

15.4 如何衡量软件工程的质量

在本书开头我们讲了如何证明自己做好了软件工程：

• 研发出符合用户需求的软件

• 通过一定的软件流程，在预计的时间内发布 “足够好” 的软件

• 并通过数据和其他方式展现所开发的软件是可以维护和继续发展的

我们能否量化上面提到的这些要点呢？ 小组的同学可以想出一些指标，也可以从文献中查到学术界的论述，还可以通过实践来总结。

下面是一些常用的量化指标,  软件发布后发现的bug 的数量

1. 软件 CC 后 DCR 的数量

2. 用户的好评/差评 （例如AppStore 的5星级评价）

3. 在CC 后发现的bug 的数量

4. 文档的完备性和准确性 （用百分率表示）

5. 修复 bug 所需的平均时间

6. 单位开发量（人*月）出现的重大 bug 的数量

7. 测试用例的覆盖率

8. 模块的复杂程度 （用工具检测并有量化结果）

9. 代码的行数

10. 文档的数量和复杂程度

11. 有多少代码被重用了

12. 平均每天构建失败的次数

13. 软件实现了多少功能点

14. 软件能运行多久， 平均初次错误时间 （mean time to failure)  平均无故障时间 (mean time between failure)...

团队可以选取 7 个指标 （包括自己想出的指标），然后在项目中计算这些指标并跟踪。

[i] 这本书讲了不少微软公司各种角色的故事： How To Move Mount Fuji, 作者: William Poundstone, ISBN 0316778494