1.对教材与参考资料阅读后关于软件质量保障你的体会是什么？
读了本书我知道，软件=程序+软件工程，通过套用公式，看看程序质量和软件工程质量如何影响软件的质量，公式：软件质量=程序质量+软件工程质量
软件在开发过程中通常有三个特性：“好”，“快”，“便宜”。
结合现实软件工程可理解为“在实现软件需求者需求的全部软件功能并将功能做到足够好后，在软件在正是运行时，存在最少的软件问题等的前提下，控制成本和时间达到最小的消耗，将这几项控制在一个相对最好的平衡的点上”。
软件工程的质量体现在以下方面：
软件开发过程的可见性（Visibility）
软件开发过程的风险控制（Risk Management）
软件内部模块，项目中间阶段的交付质量，项目管理工具的因素
软件开发成本的控制（Cost Control）
内部质量指标的完成情况（Internal Benchmarks）
软件工程的质量如何衡量：
书中306页提到了一套比较成熟的理论——CMMI（Capacity Maturity Model Integrated，能力成熟度模型集成）。
第一级：初始级。
第二级：管理级。
第三级：明确级。
第四级：量化管理级。
第五级：优化级。
实施CMMI的意义：能够提高企业的管理水平，降低企业的成本。
书中307页又提到了质量成本：SWEBOK特别定义了软件质量成本（Cost of Software Quality，CoSQQ）的组成部分。
预防（Prevention）
评审（Appraisal）
内部故障（Internal Failure）
外部故障（External Failure）
流程分析改进（Process Enhancement）
提高职业技能（Enhance Professional Skills）
技术投资（Invest in Technology）
2.如果你是一个项目的QA，那么你认为你的工作职责范围是什么？
首先必须懂开发，因为软件是由各种语言的代码编写而来，如果一个QA对软件开发甚至连基本软件开发工程的知识都不懂，其只能做黑盒测试，而有些BUG是黑盒测试所无法发现的，只能是内行人看门道，外行人看热闹，更无法与程序员很好的沟通。如果QA能够很好理解程序代码和工程，对测试中出现的问题，能够对症下药，就可以很快找到问题所在的大致位置，节省了时间成本，也能更好的与开发部门配合协调。
其次必须了解需求：如果一个QA不了解用户需求，很难理解软件每个功能的实现。如果真的这样，那就只剩瞎指挥，致使软件在偏离最初目标的道路上越走越远。了解用户需求，才能找到问题所在，又快又准确的处理问题。
最后善于总结和发现缺点：QA要善于找出团队中存在的问题，与团队队员交流，更好的改正缺点，避免更多错误的发生。必须了解项目的整体结构，为整个工程负责。
3.如果你是一个项目经理，那么你认为这你的项目中需要专职的QA么？还是只需有Test即可？如果一旦出现问题，你如何界定由谁担责？
如果我是项目经理，我支持陈皓的观点，我认为不需要专职的QA，只需有Test即可
正如材料中所说，因为，不懂开发的人必然做不好测试。就像不懂开发的研发经理必然管不好研发团队一样。
开发人员应该测试自己的代码。如果你的开发人员不能/不愿意或认为这“不归我管”，那你需要更好的程序员。
开发人员本来就要测试自己写的软件，如果开发人员不懂测试，或是对测试不专业，那么这就不是一个专业的开发人员
开发人员了解整个软件的设计和开发过程，开发人员是最清楚应该怎么测试的，这包括单元测试，功能测试，性能测试，回归测试，以及Soak Test 等
开发人员知道怎么测试是最有效的。开发人员的技术能力知道怎么才能更好的做测试
如果没有QA，能减少沟通，扯皮，和推诿，大大降低时间成本，每个Dev会更加负责的做好工作，如果一旦出现问题，由Dev担责,因为他会清楚知道问题出现在哪，承担自己的责任，减少公说公有理，婆说婆有理的现象。正如材料中所说，真的优秀的开发团队都是要吃自己狗食的。这句话的意思是——如果你不能切身体会到自己干的烂事，自己的痛苦，你就不会有想要去改进的动机。没有痛苦，就不会真正地去思考，没有真正的思考，就没有真正的进步。所以，我觉得一个项目中只需有Test即可。