阅读教材第14章及课后参考文献 写一篇关于软件质量保障的博文
参考文献：
两种不同的声音（1）https://coolshell.cn/articles/6994.html
（2）https://www.cnblogs.com/leoncfor/p/5044515.html
邹老师关于质量保障问题的介绍 （3）https://www.cnblogs.com/xinz/p/3857368.html
博文要求：
1.博文名称：软件工程第三次作业——关于软件质量保障初探
2.至少要包括这几个部分
************************************************************************************************************
（1）对教材与参考资料阅读后关于软件质量保障你的体会是什么？（40分）
首先我详细读完参考文献与课文第十四章之后并不清楚问题所描述的软件的质量保障是什么意思，对于我自己而言在公司的实习经历告诉我大部分公司都不会经行两个人编一个代码的现象，
对于程序员而言：
1）有些人可能不善于言辞。
2）有些人可能长篇大论但反而重点并没有覆盖到多少。
3）甚至在某些相同的问题上会有不同的见解，所以在问题的讨论上就会浪费大量的时间，在公司甚至会看见在不同问题上进行激烈讨论的现象，更何况是两个人完成相同问题上。
4）并且对于公司而言两个契合度程序员并不好找，同时在原来基础上只需要留住核心人员的基础上，公司开始要留住两个人，从待遇到权力的提供上就出现了并不一定平均的现象，从而产生摩擦。
5）上一点提到的毕竟是两个相互独立的个体，并且还会发生一系列利益关系，谁又能保证两个人的完全无私的向公司奉献一生呢。
6）作为程序员的我自己来说，好不愧疚的说，我就决定自己的代码就是天下第一的，无论说其他的优化代码确实会提高一部分的时间与空间复杂度，那我也会认为自己的软件是无可替代的，别人的最多也就是和我“平分秋色”。
至此以上所有问题我并不觉得程序员携带“assistance”是一件会提高工作效率或者提高代码质量的事情，毕竟大多数优秀的程序员都是那些能坐的住板凳，默默的研究算法的人，所以反而我认为对于大部分程序员来说如果软件需求如果给的足够完善，那就不存在什么没有质量保障的程序。反而是需求提供的时候给了部分“懒”程序员可乘之机（比如我自己）所以才会出现没有质量保证这一概念。
下面是我对于提供材料的几点比较支持的观点
那么所有的开发时间比上所有的测试时间应该 >20:1的（摘自材料）
个人见解：在数学中如果说证明一个论点确实是真实的那就要有相应的数据作为支持材料，对于我实习的公司来说（分享通讯）我仅仅是参与了一个小小的微信支付小程序的测试，对于整个研发组来说整个小程序历经需求下发直至程序，上线历经了一个月，很有意思的一点是在最后的测试阶段，所有手机均能支付，但单单我们测试部主管的小米手机迟迟不能运行此小程序，就是这么一个bug整个参与此项目的程序员经行了一周的讨论，最终都没能解决问题，但最终还是被本来负责此需求的开发人员在回家的路上完善。
由此可见并不一定说人多程序的质量就会变高。想到一个故事盖一栋房子10个人需要30天，那么如果有足够的人数，那么就可以说这房子一秒就可以完成。这明显就是不成立的
- 给了QA全部测试的权力，但是没有给相应的责任（摘自材料）
这是我在实习时遇到过的最大的问题了，一个互联网公司都会有自己的内网，对于一个新人来说公司没办法给你过多的权力，毕竟有些权限触及到了核心代码，公司的信息泄露还是要做出防范的，这就衍生了一系列问题：我在做这个测试时候发现自己并没有权限访问或对此功能做出操作，我就需要去找测试主管，主管在向经理递交申请表，最后等权限下发时候，剩余的工作时间远远不够完成今天的测试任务了。反而并没有我们测试主管一个人完成的效率高。
2.QA没有体会过软件质量出问题后的痛苦（解决线上问题的压力），导致QA不会主动思考和改进。（摘自材料）
有些人并没有参与到这个程序的编辑之中，他并不能体会你的程序哪里时精华，哪里是糟粕，连这个都不知道，他怎么对于你的程序进行改进，更不要说加以完善了
3.QA对Dev的开发过程和技术完全不了解，增加了很多QA和Dev的沟通。（摘自材料）
对于两个的沟通我最想说的就是无论两个人是相同的技术水平还是档次有差距的两个程序员之间对于一个问题的讨论，只要开始那就将停不下来，对于档次差距很大的人来说那将更为致命，档次高的不屑于听低的人评价，档次低的听不懂高的在说什么，最后将不了了之，讨论了还不如不讨论，对于档次相同的也都差不多大同小异，各自发表各自的意见。
4.QA对软件项目的设计和实现要点不了解，导致了很多不有效的测试。（摘自材料）
对于需求不同的人会有不同的看法，甚至语文水平都会有高有低，所以在有些需求的实现上有些人会对于某些不必要的需求上钻牛角尖，从而浪费了不必要的时间。
以下也是个人比较支持的观点
1） 开发人员做测试更有效---自己的孩子哪里有优点、哪里有缺点只有自己才最了解
2）吃自己的狗食---如果你不能切身体会到自己干的烂事，自己的痛苦，你就不会有想要去改进的动机。没有痛苦，就不会真正地去思考，没有真正的思考，就没有真正的进步。
************************************************************************************************************
（2）如果你是一个项目的QA，那么你认为你的工作职责范围是什么？（30分）
在开发项目组完成需求时，把代码发给你的时候第一时间完成对于代码的读取，并且巧妙理解开发人员对于需求满足时的思维于想法从而找出一些衍生的隐藏的未被满足的额外需求，从而反馈给开发人员（所以我觉得不是人干的活，典型的费力不讨好的工作）
（3）如果你是一个项目经理，那么你认为这你的项目中需要专职的QA么？还是只需有Test即可？如果一旦出现问题，你如何界定由谁担责？（30分）
如果我是一个项目经理，我并不认为我需要QA，相反还不如将请QA的钱用来给开发人员，鼓励他们自己检查自己的程序，相反测试组的存在的必要性是相当大的，毕竟有些细小逻辑错误单单凭借个人思路是无法发现的，并且无论是什么都需要经过层层筛选才能推出的啊。
如果出现了问题首先责问的当然是开发人员，毕竟是开发人员自己的代码出现可bug，但同时测试人员的测试不严格同样也有不可逃避的责任的