软件工程第三次作业——关于软件质量保障初探
问：对教材与参考资料阅读后关于软件质量保障你的体会是什么？
软件测试在整个软件生命周期中的重要性使其存在于整个项目周期，这个环节在整个项目中占了很大的比重，能主导整个软件项目的走向。质量这个关键词对于企业来说究竟有多重要自然不必多说，轻则关乎到软件的最终运行状态和结果，重则直接影响到企业形象，不会有任何人相信一家质量不过关的企业，那样做无异于自寻死路。
软件测试如果能存在软件开发的整个周期中，可对软件开发过程中存在的风险作出及时规避，减少工程在时间和金钱上的消耗，还能让团队认识自己身的不足之处，并加以改进，避免在同一个坑中掉进去两次，更能挽回不少企业的损失。
引用书中关于软件质量的一句话：
Capability of software product to satisfy stated and implied needs under specified conditions.
谷歌翻译为：
软件产品在指定条件下满足陈述和隐含需求的能力。
而“程序的质量”和“软件工程的质量”如何影响软件的质量，就像这样一条公式：
软件质量 = 程序质量 + 软件工程质量
1） 软件在开发过程中通常有三个特性：“好”，“快”，“便宜”。
结合现时软件工程可理解为“在实现软件需求者需求的全部软件功能并将功能做到足够好后，在软件在正是运行时，存在最少的软件问题等的前提下，控制成本和时间达到最小的消耗，将这几项控制在一个相对最好的平衡的点上”。
以上这些就引出来一个问题——软件质量：
什么是质量，如何来衡量？
比如衡量一个搜索引擎的质量，业界通用准确度和覆盖率的综合指标来表示。网站查询结果的速率，订票网站能并发处理业务的吞吐量，支持同时在线人数的数量。等等许多衡量标准。
2） 软件工程的质量体现在以下方面：
- 软件开发过程的可见性（Visibility）
- 软件开发过程的风险控制（Risk Management）
- 软件内部模块，项目中间阶段的交付质量，项目管理工具的因素
- 软件开发成本的控制（Cost Control）
- 内部质量指标的完成情况（Internal Benchmarks）
3） 软件工程的质量如何衡量：
这里引入一套比较成熟的理论——CMMI（Capacity Maturity Model Integrated，能力成熟度模型集成）。
- 第一级：初始级。
- 第二级：管理级。
- 第三级：明确级。
- 第四级：量化管理级。
- 第五级：优化级。
4）软件质量的成本：
SWEBOK特别定义了软件质量成本（Cost of Software Quality，CoSQQ）的组成部分。
- 预防（Prevention）
- 评审（Appraisal）
- 内部故障（Internal Failure）
- 外部故障（External Failure）
- 流程分析改进（Process Enhancement）
- 提高职业技能（Enhance Professional Skills）
- 技术投资（Invest in Technology）
问：如果你是一个项目的QA，那么你认为你的工作职责范围是什么？
1）什么是QA：
QA（QUALITY ASSURANCE，中文意思是“质量保证”），其在ISO8402：1994中的定义是“为了提供足够的信任表明实体能够满足质量要求，而在质量管理体系中实施并根据需要进行证实的全部有计划和有系统的活动”。有些推行ISO9000的组织会设置这样的部门或岗位，负责ISO9000标准所要求的有关质量保证的职能，担任这类工作的人员就叫做QA人员 。（来自百度百科词条解释）
2）工作职责范围：
QA的重要工作是预防、检查与改进来保证软件质量。QA的工作是软件生命周期的管理以及验证软件是否满足规定的质量和用户的需求。
综上如此，QA需要很多对应其专业的能力，这也是成为一名合格QA所要做的职责范围，不然绝不是一个合格的专业人员。
- 必须懂开发：软件是由各种语言的代码编写而来，如果一个对软件开发甚至连基本软件开发工程的知识都不懂的QA，其只能做黑盒测试，而有些BUG是黑盒测试所无法发现的，只能是内行人看门道，外行人看热闹，更无法与程序员很好的沟通。如果QA能够很好理解程序代码和工程，在测试过程中能够针对某一点制定测试方法，对症下药。而测试中一旦出现质量问题，可以很快找到问题所在的大致位置，减少盲目寻找问题所在而浪费的时间，更好的与开发部门配合协调。
- 必须了解需求：有用户需求，才出现对应的软件，如果一个QA不了解用户需求，很难理解软件每个功能的实现。如果真的这样，那就只剩瞎指挥，致使软件在偏离最初目标的道路上越走越远。了解用户需求，可在测试时更准确的收集数据，寻找缺点和问题所在，最快最准确的处理问题。对项目需求文档进行评估，规则文档，设计文档测试用例，
- 善于总结和发现缺点：任何开发团队都不可能不存在问题，在开发工程中和完成后，QA要善于找出团队中存在的问题，与团队队员交流，更好的改正缺点，避免更多错误的发生。
- 必须了解项目的上下游的结构：不了解上游，必然无法确定dev对上游的调用是否可靠。不了解下游，必然无法确定项目的实现是否符合下游的调用场景，接口的QPS是否满足要求，项目对下游影响的范围有多大。
- 为整个工程负责：在项目中QA不是为找bug而存在，项目中找到的bug越多，说名项目的质量越接近需求的质量，但也并不代表是真正的质量。QA需要监督和保证从需求一直到项目上线的质量。也就是说，QA不是证明项目实现的错误性，而是确认实现的正确性。
- 监督：在开发过程中，各小组按组内规范进行工作，有组间交互的任务需按组间交互规范去完成。检查设计文档是否与程序源码一致，这些期间QA按工作流程规范监督各项工作任务的进行。及时沟通共同推动项目的进行。
问：如果你是一个项目经理，那么你认为这你的项目中需要专职的QA么？还是只需有Test即可？如果一旦出现问题，你如何界定由谁担责？
需要根据企业实际情况出发分析QA是否需要，而相应的技术人才又从何而来。
有这么一说，测试团队是否真的有存在的必要，这要看情况。如果从事的工程太小，可能就是自己给自己做的。无知，对软件工程几乎一窍不通的团队，采用一窝蜂的开发方式。人手不够，一人干两件事情甚至更过事情，恨不得长出来三头六臂。
还有其他一种与上面相对立的情况出现，前面时比较弱的小企业，甚至是不到十人的小工作室。但是如果是大神或者是拥有强大雄厚资金的帝国企业，那么情况就另一种情况。
人太牛：高德纳认为排班软件不如他意，所以自己动手写一款自己的专属软件，他对其中的代码和原理了如指掌，哪里出错会第一时间更改。然而有多少这样的神级人物存在？即使存在，他们在大型团队中也能运筹帷幄，不用担心大问题的出现。
工程太小：前前后后代码加起来不超过千行，而且和前面大神相同，我只自己私用，管理起来更加轻松。但有局限性，软件只能自己这一个小圈子使用，出不去。
还有类似于Facebook的成熟经验
公司的员工都在频繁使用他们自己开发的软件，相当于我们每个人都是测试人员，每一次操作之后还有LOG日志文件作为记录。平台还提供BUG反馈入口，千万亿用户自动成为了测试一员。
Facebook作为一个平台，自然后又第三方厂家想要以此为基础开发自己的程序，他们更加专业，更容易找到问题。
群众力量的作用之下更容易找到问题所在，这样一来，测试部门的作用自然减少了。
可这仅仅只针对特殊企业，这种成功是很难被复制的。那么针对普通的企业或是团队，他们还是需要QA的。可不能谁都能当这个QA，门外汉自然是首先拒之门外的，让一个不懂软件工程的人测试，最高也就黑盒测试，可这又是没有多少技术含量的职业。
最好是从本团队中提拔，在团队中工作有段时间的员工最好。他们更容易理解团队代码风格，能第一时间找到问题所在，与开发团队有很强的默契性。然而团队还需要一个并不是本团队提拔上来的专业QA，这名QA对代码自然有一定基础和经验。因为当代码风格确定后，团队内部的人员会产生我这样写是正确的的迷惑性想法，造成错误不断累加。
这个时候团队分工体现出来，细分每个团队下每个部门的职责，在保持自身独立运行不受外界干扰的前提下，与周围团队密切交流，不断取长补短，实现一个统一的流水线一样的开发环境。一旦哪里出错，可以很快找到问题根源，及时作出更改。
