软件工程第三次作业——博文软件质量保障初探
关于软件质量保障的体会
怎样保障软件这碗面的质量
什么是软件质量？软件的质量是代码的好坏？还是功能是否完善？还是其他的什么，当我读到这些问题是我想了好多，软件的质量衡量是否跟其他的东西一样，比如评价一份牛肉面的质量的好坏，我们可以从他的面条是否筋道，汤头是否鲜美，牛肉的好坏，用的香菜是否新鲜，当然对于我这种普通的大学生，价格也是一份牛肉面质量好坏的重要标准，但其实价格跟牛肉面质量的好坏其实没多大关系(哈哈，扯远了)，当我通读了软件的质量保障这一章，软件的质量的好坏有许多因素，其中的有些道里其实保证一碗牛肉面的质量差不多，第14章的开篇就说了软件质量的定义，但看到一长串英文，我的脑袋瞬间就大了，一眼望去没几个认识的单词。
那两个长串的国际标准组织的定义最后都强调了软件应该符合用户以及利益相关者，这其实跟牛肉面质量的好坏差不多。牛肉面是否好吃，其实这个问题的答案带有很强的主观性，为什么这么说呢？举个例子吧，你给了一位喜欢吃辣的东北大汉一碗清汤寡水的牛肉面，给了一位从不吃辣的南方小姐姐一碗全是红油和辣椒的特辣牛肉面，你这生意多半是不久就要倒闭了。因为你没有事先问清楚食客的口味，不管你的面条多筋道，汤头多鲜美，香菜多新鲜，你给食客的直观感受是“真难吃”，软件质量的道理其实跟牛肉面质量的道理异曲同工，做软件在某些方面其实跟做一碗面差不多，你做一款软件，没有搞清楚用户到底需要什么，你只是知道用户要一碗面，没有搞清用户要不要香菜，面条是多煮一会还是少煮一会儿，面条过不过凉水,等等。。。。。，这都是问题，一碗面搞砸了可以重新煮，成本也不高，但一款耗资较大的软件搞砸了，对一家公司打击可不小，虽说软件需要维护，可以修修补补，像一碗面，淡了可以加盐，不喜欢吃香菜的可以挑出去，甚至可以从新煮一碗给用户，但仔细想想，做软件这碗面的成本多大啊，如果从一开始搞清楚用户的需求，基本的功能框架是正确的，那么后期的维护，功能的改进会减少多少成本啊。所以说软件的质量保障真的很重要。
书上给了一个公式
软件质量=程序质量+软件工程质量
这个公式其实挺不好理解的，换个角度，回到咱的牛肉面馆，咱的面馆通过改进，营业额一步一步提了上来，为了进一步扩大营业，咱换了新的店面，改名叫西北风味餐厅，有了专门的餐厅管理团队，有了专门的后厨团队，当你跟团队商量推出新菜的时候你发现新菜的标准跟牛肉面大不一样。
你推出一道新菜叫做文字处理，业界内的标准是它能否拷贝粘贴与其他软件传递信息，你没过几天又想推出一道新菜叫搜索引擎，你发现它的业界标准更复杂，软件这道菜的质量等于程序质量加软件工程质量，先说说程序质量，像每一道菜有它的色香味各方面都有不一样的需求，软件的程序的功能也有不一样的要求，用户的体验质量，国际化的质量，安全性的质量，还可以用其他的数值来表示软件质量。
再来说说软件工程的质量，软件开发的过程有三个主要特性，好，快，便宜，好就不用说了，相当于最后成菜的品质，就是前面提到的程序质量。那么软件工程方面的质量就跟便宜，快比较相关，软件的程序质量可能靠你的团队靠一些特殊方法来解决，比如说在推出新菜之前通宵加班，或者再发布菜品后听取用户意见来修改菜品的口味，食材之类的，而软件工程的质量却需要长期的过程来提高。
软件工程的质量体现在以下方面
1，软件开发过程的可见性
可以理解为做菜时，实时可以了解菜品的味道，进而可以控制成菜时品质，只有中间步骤可见，才能对每一步进行控制，所以说可见性是非常重要的。
2，软件开发过程的风险控制
这可以理解为当你的餐馆遇到突发情况下是否能够应对，比如主厨(chef,也可译为主管)离职，或者某道菜的某个步骤(程序的某个模块)的负责人员离职，后厨水电停了(服务器突发故障)，只能推迟软件的交付日期，做好风险控制，比如说培养在短时间能代替主厨的位置的人(尽量别是个二把刀)，把各个模块让主要人员了解，短时间内找到当前模块开发的替代人员。
3，软件内部模块，项目中间阶段的交付质量，项目管理工具的因素
相当于做一道复杂的菜，需要好几个厨师配合，需要煎炸烹煮烤，每一个环节都需要特定的人去完成，虽然这些处理下的半成品不会交给用户，但对整道菜的最后成菜起了很大的作用，其中有很多因素需要注意。
4，软件开发成本的控制
成本包括时间和金钱，相当于你的饭馆承包了一个婚宴，在具体时间之前要赶置好几十桌饭菜，团队效率低下，技术落后，导致无法在规定时间内完成，只好请专业的团队花费大量的金钱，这远远超出了本来的成本。
5，内部质量指标的完成情况
一个团队在项目启动时会制定一些列指标，粗略的比作后厨，比如面条所用的面需要和几分钟，所用的汤头需要炖几个小时，所需的蔬菜需要洗几遍。。。。等等，这些东西一旦多了，团队会顾不上，直接拉低的最后的产品质量。
以上就是我对软件质量的质量保障的体会，废话较多。个人理解可能有些偏差，不喜勿喷。
面来谈谈关于QA,Test的一些问题
如果我是一个QA,我觉得我的职责有以下方面
1，澄清需求
2，缺陷管理
3，设计测试
4，执行测试
5，质量反馈
是否需要QA
我觉得需要不需要QA,了解软件开发的人才能搞好软件测试，才能更好的把握软件的质量，因为，不懂开发的人必然做不好测试。就像不懂开发的研发经理必然管不好研发团队一样。开发人员应该测试自己的代码。没什么可说的。背后的道理并不重要。这包括单元测试，全覆盖的自动化测试或手工测试或组合测试。如果你的开发人员不能/不愿意或认为这“不归我管”，那你需要更好的程序员。如果出现问题，应该追溯的个人，因为当前模块的程序员最了解当前模块的问题，能更好的处理问题。
