del

极客时间专栏/geek/软件工程之美/软件测试篇/31 | 软件测试要为产品质量负责吗？.md

@@ -0,0 +1,124 @@
+<audio id="audio" title="31 | 软件测试要为产品质量负责吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ef/44/ef0e27ecbf2e90837f21a89cf77c8644.mp3"></audio>
+
+你好，我是宝玉。从这一篇开始，我们将进入软件工程中的测试模块的学习。
+
+说到软件测试，你一定不会陌生，尤其是如果你做开发相关岗位的话，一定是对测试又爱又恨，一方面测试从你的程序找出Bug，然后你还要费心去修复；另一方面测试帮你发现Bug，修复后能很好的提升质量。
+
+正因为测试能发现软件中的质量问题，通过测试能有效提升软件质量，慢慢的大家就觉得软件测试能保障质量，所以测试要对质量负责。开发也会对测试产生依赖心理，很多功能模块实现后，就扔给测试人员去测试。
+
+上线后，如果因为有测试漏测导致的Bug，测试人员还要为质量问题背锅，受到责备。上面这样的场景到现在也还在很多软件项目中上演。但这对测试人员其实是不公平的。
+
+因为软件开发是多个环节组成的，从最开始的需求，到后面的设计、开发，每个环节都可能会导致质量问题，**而测试只能对已经开发完成的软件产品进行检测，并不能干预整个过程。**
+
+比如说测试是无法对开发写的代码直接测试的，只能基于软件功能去测试，也就是说对于代码的质量，测试人员其实是没有什么办法的。
+
+那到底谁应该为产品质量负责呢？在回答这个问题之前，你不妨先思考一个更本质的问题：什么是软件产品质量？
+
+## 什么是软件产品质量？
+
+我以前以为，软件质量就是由Bug数量、性能高低、安全性等指标决定的，现在看来这样划分其实并不全面。
+
+因为不同的人对软件质量好坏的评判角度是不同的。比如对用户来说，更看重产品是不是满足需求，是不是美观好用；对开发来说，看重的是代码质量是不是高，是不是好维护；对于软件测试人员而言，看重的是Bug数量、安全、性能等指标；对于项目负责人，看重的是整个开发过程的质量，是不是成本可控、如期完成。
+
+在这个问题上，我比较认同《The Three Aspects of Software Quality: Functional, Structural, and Process》这篇文章作者David Chappell的观点，他把软件质量分成了三个考量方面：功能、结构和流程。对于他提的“结构质量”，我认为定义为“代码质量”更贴切，也就是说，**功能质量、代码质量和过程质量这三个方面组合在一起，很好地概括了软件质量。**
+
+所有的软件开发都是从一个想法开始的，用户需要一个软件，有人出钱，然后开发团队实施，把想法变成需求，需求变成设计，设计变成代码，代码变成软件。
+
+- **功能质量**
+
+最终用户得到是软件，体验的是软件的功能，功能的质量直接决定了产品的质量。
+
+满足用户需求，是对功能质量最基础的要求。在这个基础上，Bug数量、性能、UI/UX都是很重要的质量指标。如果你的软件Bug太多、性能差，用户不会满意；界面难看，操作体验也很差，这些因素都决定了你产品的功能质量。
+
+- **代码质量**
+
+构成软件最重要的部分是代码，代码质量指的是实现软件功能的架构和代码的质量。代码的质量主要体现在以下这些方面：
+
+1. 代码的可维护性，也就是在不影响稳定性的前提下，是否能方便地添加或者修改现有的代码；
+1. 代码的可读性，代码是否容易理解，是否能快速上手；
+1. 代码的执行效率，代码执行效率直接影响了软件性能；
+1. 代码的安全性，是否有安全漏洞，安全性是代码质量很重要的一个指标；
+1. 代码的可测试性，代码是否能使用单元测试、集成测试进行测试验证。
+
+虽然用户不能直接感知到代码，但是代码质量高低会直接影响功能质量，同时代码质量低也会影响后续的维护升级。
+
+- **过程质量**
+
+软件的开发离不开软件工程，离不开项目管理。软件开发过程的质量决定了你的项目是否能如期完成，开发成本是否在预算之内。
+
+过程质量虽然也是用户不能直接感知的，但是过程质量会直接影响代码质量和功能质量，甚至是产品的成败。
+
+以上就是软件质量的三个方面，**软件质量从来不是单方面质量决定的，通常是几方面质量因素相互影响，共同决定的。**
+
+比如说改进流程，增加了自动化测试的覆盖，应用了持续集成，这样可以提高代码质量和功能质量。或者说对代码质量过于追求，又可能会影响过程质量，例如时间延期，成本超标。
+
+## 谁该为产品质量负责？
+
+在梳理清楚产品质量的问题后，我们就可以来讨论谁该为产品质量负责的话题了。
+
+**既然产品质量是由功能质量、代码质量和过程质量共同决定的，那么对产品质量负责，意味着要对这三方面共同负责。**
+
+在说到责任之前，我想补充一下权责对等的问题。责任和权力是需要对等的，比如说你让开发人员对软件开发过程负责，那么前提是他必须有权力去影响和控制开发过程，否则离开权力谈责任就是耍流氓了。
+
+然后，我们再一起看看项目中的主要角色，谁最应该为产品质量负责？
+
+软件测试，可以对功能质量负责，对软件产品进行测试验收，以确保产品满足功能需求，有好的功能质量。但是通常不能对代码质量和过程质量负责。
+
+开发人员，可以对代码质量负责，也可以写测试代码，通过自动化的方式做功能测试，虽然还不能完全替代手工测试的作用，所以也可以算得上对功能质量负责。但开发人员通常对过程质量影响有限。
+
+项目负责人，可以对过程质量负责，而且过程质量的水平高低，会间接影响代码质量和功能质量。但因为项目负责人不直接编码和测试，所以无法直接影响代码质量和功能质量。
+
+所以综上，我觉得如果要排序的话，软件质量的首要负责人是项目负责人，其次是开发人员，然后才是软件测试。
+
+虽然从权责的角度看，项目负责人是最应该对项目质量负责的，但是从效果来说，却是开发人员对项目质量负责最有利。
+
+首先，开发人员是唯一能直接影响代码质量、能对代码质量负责的人。开发人员能更容易地找到代码中的Bug，更容易通过架构设计、自动化测试代码等手段保证好代码质量，提升测试效率。
+
+现在软件开发的发展趋势也是如此，软件测试的很大一部分手工测试工作已经被自动化代替。
+
+所以很多公司就让开发负责产品质量，甚至都不设测试岗位，典型代表就是Facebook。开发人员自己写代码实现功能，然后写自动化测试代码对功能进行测试，最后上线。这样不仅自己测试能保证功能的质量，又能通过自己写单元测试、集成测试来保证代码的质量。
+
+当然，开发人员对功能质量负责，意味着必须在实现功能的同时，还要考虑如何去测试这个功能，这样让代码更具有可测试性，这就对开发人员的要求更高了。
+
+就像Facebook强调的“Be there from start to ship”，就是让每个工程师能自始至终地负责产品。从想法到原型设计、到产品开发、上线和维护，全部是工程师自己完成。
+
+我们不需要做到Facebook那样，从头到尾都一个人搞定，但至少，作为开发人员，我们可以对代码质量有更高要求，让项目有更多自动化代码的覆盖；可以在交付测试之前自己先测试一遍。
+
+这样的话，开发就可以真正做到对代码质量和功能质量负责。如果你还想对过程质量也能负责，那么敏捷开发中一些理念是有可取之处的。
+
+敏捷开发中强调的是：项目的所有人一起为产品质量负责，人人为产品质量负责。
+
+但人人为质量负责，很容易变成一句口号而很难落实。就像三个和尚没水喝的故事里面那样，当质量变成每个人的责任时，就没有人真正为质量负责了。所以我们不只是要学习敏捷开发中的理念，还要学习它一些具体的方法。
+
+## 如何做到“人人为产品质量负责”？
+
+只有真正在团队中建立了一种重视产品质量的文化，每个人才会确确实实地对质量负责。那么有哪些方法可以帮助团队建立这种“人人都重视产品质量”的文化呢？
+
+首先，可以参考敏捷开发中的扁平化管理。在敏捷开发中没有项目经理，只有产品负责人，而产品负责人更多是充当一种服务型的角色。大家都很平等，也就是说每个人都有权力去影响到项目过程，实现权责对等，大家才会为过程质量负责。
+
+其次，可以选择将团队拆小。敏捷开发中的团队规模都不大，大的开发团队拆分成了小的开发小组，每个组人数都不多。人数多的时候容易推诿扯皮，但如果人少，每个人就必须要承担更多的责任，这有助于形成人人重视产品质量的文化。
+
+另外，也可以鼓励工种之间的融合，例如开发人员多写自动化测试代码；测试人员在开发人员写自动化测试时，提供帮助，例如设计测试用例。这样不只是局限于各自负责的质量领域，也同时关注其他质量领域。
+
+最后就是制定相应的制度，鼓励大家重视质量。比如说：
+
+- 每个Sprint都有项目回顾会议，每个人都可以针对质量提出有效的建议，最终将这些建议落到实处；
+- 出现质量问题，不是推卸责任，而是分析原因，及时修复，避免以后出现类似问题。
+
+要做到“人人为产品质量负责”，还是要像上面提到的一样，要落到行动而不是口号上，组织上扁平化、小型化，分工上打破岗位墙，制度上鼓励大家重视质量，才能真正建立重视产品质量的文化，一起把产品的质量提升上去。
+
+## 总结
+
+今天我带你一起探讨了一个在软件项目中的常见问题：软件测试要为产品质量负责吗？
+
+保证软件高质量，并非只是测试人员的责任。软件质量体现在功能质量、代码质量和过程质量这三个方面，对产品质量负责，也意味着要对这三方面共同负责。
+
+软件测试，不能影响代码质量和过程质量，所以并不需要为产品质量负责，项目负责人能直接影响过程质量，也能间接影响代码质量和功能质量，应该为产品质量负责。对于开发人员而言，不应只是局限于对代码质量负责，还应该注意功能质量。
+
+对产品质量，最理想的状态还是能做到人人都为产品质量负责，而达到这样的目标，还是需要建立一种重视质量的文化，每个人才会确确实实地对质量负责。
+
+## 课后思考
+
+你所在项目组中，谁为产品质量负责？你觉得应该怎么样在团队中建立一种好的重视质量的文化？欢迎在留言区与我分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/geek/软件工程之美/软件测试篇/32 | 软件测试：什么样的公司需要专职测试？.md

@@ -0,0 +1,176 @@
+<audio id="audio" title="32 | 软件测试：什么样的公司需要专职测试？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/0c/e7/0ca23031171817b35f2c832f4b32e3e7.mp3"></audio>
+
+你好，我是宝玉，我今天想与你讨论一下，什么样的公司需要专职测试这个问题。
+
+若干年前，网络上对于软件开发是否需要专职测试有过一次讨论，代表文章有：左耳朵耗子老师写的《[我们需要专职的QA吗？](http://coolshell.cn/articles/6994.html)》，然后邹欣老师对此回复《[测试QA的角色和分工](http://www.cnblogs.com/xinz/archive/2012/04/09/2439695.html)》。
+
+从这些年业界发展趋势来看，看起来很多公司都不需要专职测试了，只需要开发兼任测试工作就可以了。比如，Facebook号称自己没有专职测试工程师，Google和Amazon虽然有专职的测试工程师，但都是开发人员对质量负责，开发人员写大量的自动化测试代码。但这样真的可行吗？
+
+在回答这个问题之前，我们还是先来看看，软件测试的主要工作是什么？只有搞清楚软件测试的工作，才能搞清楚这部分工作是否可以由开发来替代，是否需要专职测试。
+
+## 软件测试的主要工作是什么？
+
+在前面开发篇内容的学习中，我们对开发的工作已经比较了解了：在需求确定后，开发人员开始针对需求进行架构设计，然后编码，最后对发现的Bug进行修复，保障线上稳定运行。
+
+而软件测试也类似，也是从需求开始，在需求确定后要去对需求进行分析，然后做测试设计。
+
+如果说架构设计是对业务需求在技术方面的抽象，那么测试设计更像是对业务需求的具象，把业务需求分解成一个个具体的用户操作步骤，也就是测试用例。然后在开发完成后，按照设计好的测试用例进行逐一的测试验证，将发现的Bug报告给开发人员，并跟踪Bug的修复。
+
+如果对软件测试的工作简单总结一下，就是发现Bug，报告Bug，跟踪Bug。
+
+#### 软件测试怎么发现Bug？
+
+这里面最难的就是发现Bug，尤其是如何尽早、尽可能全面地发现Bug。
+
+举个例子来说，如果现在你需要开发一个用户登录的功能，你在开发完成后会怎么测试？
+
+一个普通的程序员通常只会简单测试一下以下用例：
+
+- 输入正确的用户名、密码，能登录；
+- 输入错误的用户名密码，提示错误，不能登录。
+
+而一个有经验的程序员还会测试一下其他情况，例如：
+
+- 用户名或者密码为空，是否提示错误；
+- 没有注册的用户名和密码，是否会提示错误。
+
+但如果是一个专业的测试人员来测试，是不是只做上面的测试就够了呢？专业测试还会测试哪些内容呢？
+
+对于专业测试人员来说，上面这些肯定是不够的，还需要有以下这些情况的功能性测试：
+
+- 用户名密码是否大小写敏感；
+- 用户名或密码如果是用特殊字符，会不会导致程序异常；
+- 用户名或密码如果特别长，是不是会有异常；
+- 是不是所有主流浏览器和终端设备都能使用。
+
+这就完了吗？并没有。除了功能性的测试，还需要进行非功能性的测试，也就是像性能、安全性和用户体验等方面的测试。比如以下测试用例：
+
+- 是否可以通过发送数据包反复登录，暴力破解密码；
+- 会不会有Sql注入的风险；
+- 大量用户同时登录，页面会不会崩溃；
+- 用键盘tab、回车键是否可以操作。
+
+当然还会有其他测试用例，这里就不一一列举。为什么专业测试人员和开发人员的测试用例会差这么多？
+
+因为开发人员的重点，是放在如何实现功能上，就拿上面用户登录的例子，开发人员会想着如何能校验用户输入的用户名密码，并给出相应的提示，对于异常流程和场景会相对考虑较少。
+
+而对于测试人员来说，重点是在检测，也就是会考虑所有可能的用户使用场景，正常的、异常的，甚至各种极端情况，例如大量并发访问、黑客恶意破解，所以他们能想到更多、更全面的测试用例。
+
+测试人员设计测试用例，就是要尽可能做到覆盖所有用户操作的可能，但理论上来说这是不可能的，因为组合是有无限多个的。不过从测试的角度看，没有必要每一个可能都去测试，可以通过一些科学的方法来通过有限的测试用例，保证尽可能多的测试覆盖。
+
+有哪些方法呢？我给你举几个例子：
+
+- 等价类划分
+
+就是把所有用户可能输入的数据分类，如果一类数据对于发现Bug的效果是一样的，那么这类数据就是一个等价类，测试的时候只要从里面任意选取一个值就好了。比如一个输入框要求只能输入1-100之间的整数，那么1到100之间都是等价的，0和任意负数也是等价的，101和之上的整数也是等价的。
+
+因为分类是有限的，这样就可以用有限的测试用例实现尽可能多的测试覆盖。
+
+- 边界值分析
+
+边界值是对等价类的补充，因为输入输出的边界是非常容易出错的一个地方。比如说上面输入框的例子，0，1，100，101都是边界值，可以设计用例来测试是否会有可能出错。
+
+- 探索性测试
+
+探索性测试就是根据前面的测试结果，通过有效的策略进行测试。
+
+举例来说，如果你玩过RPG游戏的话，里面通常会有走迷宫的地图，各种分叉，不同的分叉可能有不用的宝箱，如果你想打开所有的宝箱，那么就可以在遇到分叉的时候，每次优先走右边的分叉，除非右边已经去过了。
+
+那么这里“右边的分叉是不是走过了”，就属于已经测试过的结果，策略就是优先走右边的分叉。关于探索性测试的介绍可以参考这篇文章《[探索性测试揭秘](http://blogs.msdn.microsoft.com/billliu/2012/05/25/103/)》。
+
+当然除了以上这几个主要的策略，还有很多其他的策略，比如说：
+
+- 场景设计；
+- 因果图；
+- 错误推测法。
+
+这里我就不一一介绍，推荐阅读《微软的软件测试之道》，这本书上有很多具体的测试方法的详细介绍。
+
+借助这些方法，测试人员就可以对需求功能设计出完整的、有较高覆盖率的测试用例。
+
+所以，有时候测试人员的工作看起来不过是用鼠标点点测试，但他们在拿到需求后，其实花了很多时间和精力分析需求，然后根据需求设计测试用例，准备测试数据。等到开发人员完成软件开发后，就按照设计好的测试用例逐一测试，这样就可以做到及时发现Bug。
+
+#### 软件测试怎么报告Bug？
+
+在测试的过程中，如果测试人员发现了Bug，就会通过Bug跟踪系统提交Bug给开发人员。Bug跟踪系统其实跟我们在《[14 | 项目管理工具：一切管理问题，都应思考能否通过工具解决](http://time.geekbang.org/column/article/87787)》中介绍的任务跟踪系统是一样的，它可以方便地提交和跟踪Bug。
+
+测试人员要做的就是创建一个新的Ticket，在Ticket的描述中，详细说明Bug是什么，具体的重现步骤，必要的话还要附上截图、日志等辅助信息。这样开发人员在收到Bug后就能快速定位问题，按照优先级对Bug进行修复。
+
+#### 软件测试怎么跟踪Bug？
+
+Bug的跟踪，并不仅仅是要跟踪开发人员什么时候修复了这个Bug，通常还包括对Bug修复的验证。
+
+开发人员修复完一个Bug后，测试人员首先会验证这个Bug是不是真的被修复了，然后还要对整体功能做一个回归测试，确保不会因为修复Bug而引起其他功能出现问题。
+
+回归测试是指修改了旧代码后重新进行测试，以确认修改没有引入新的错误或导致其他代码产生错误。
+
+回归测试这一步很重要，因为通常开发人员在修复完Bug后，只会验证其修复的Bug，而不会验证其他功能是不是会有影响。但实际上，软件项目中经常会出现修复一个Bug，而导致系统其他功能出现问题的情况。回归测试，则能有效、及时地发现修复Bug导致系统不稳定的情况。
+
+## 什么样的公司需要专职测试？
+
+了解了测试的主要工作内容之后，我们再回过头来看看今天要讨论的问题：什么样的公司需要专职测试。
+
+如果一个公司不需要专职测试，那么意味着专职测试的工作可以被其他工种替代，比如说由开发人员一起完成软件测试的工作。
+
+想象一下，如果你是一名开发工程师，然后你要兼职做测试，那么你需要额外做好哪些工作？
+
+首先，你在拿到需求后，除了做技术上的设计外，还需要做测试上的设计，借助测试方法设计测试用例。
+
+这样做好处很明显，可以在写程序时，让程序更易于测试，设计时会对需求考虑更全面。缺点也显而易见，你不止要学习编程知识、了解业务，还要学习测试方法。也许对你来说可以做到，但是对于绝大多数开发人员来说，这是一个很高的要求。
+
+然后在开发完成后，要对自己写的程序进行测试。这里可能存在一个问题，也就是如果你在程序实现的时候，漏掉了一个逻辑处理，比如说漏了检测Sql注入，那么你在测试的时候也不会想到要去测试这部分。
+
+测试自己的程序还要克服一个心理障碍，就是要对自己的程序进行破坏性测试，才可能找到潜在的问题，但去“破坏”自己完美的程序，对大多数开发人员来说也是很难接受的一件事。
+
+如果上面两个问题都能克服，你还得再考虑一个问题：如果项目进度比较吃紧，作为开发人员你会压缩哪部分时间？
+
+正常来讲，测试时间必然要被压缩的，因为你首先得保证代码实现。这可能就导致只要项目进度一紧张，测试就被严重压缩了，进而会严重影响质量。
+
+这样看来，完全由开发人员兼职测试，还是很有难度的，不仅对开发人员要求非常高，而且需要开发人员承担所有的开发和测试的压力。
+
+#### 为什么Facebook可以做到没有专职测试呢？
+
+首先Facebook的工程师水平确实是高于业界平均水平的，有能力同时做好开发和部分测试工作；
+
+其次，Facebook的产品周期相对宽松，可以有时间完成自动化测试代码；
+
+Facebook在功能发布之前，先发布新功能到内部环境，几千内部员工先测试，部分充当了测试人员角色；
+
+Facebook的发布和监控也比较完善，有问题能通过监控及时发现，并且可以随时快速回滚或者发布补丁；
+
+最后就是用户对这类社交产品的Bug相对容忍度比较高，想想看如果是波音飞机上的软件能这么做吗？
+
+至于Google和Amazon这些公司，他们也是类似的情况：
+
+- 大量优秀的工程师，可以同时兼任开发和测试；
+- 有大量的自动化测试代码覆盖；
+- 强大的发布和监控系统；
+- 时间进度比较宽松；
+- 用户对Bug容忍度较高。
+- 对于不能满足上面条件的公司，有专职的测试是更有利于软件项目开发和质量保障的。
+
+#### 大厂不设专职测试的启示
+
+虽然对于大部分公司来说，要做到完全没有专职测试还不现实，但这些大厂不设专职测试的实践还是有值得借鉴和思考的地方。
+
+首先，用自动化测试代替重复性的手工测试是必然趋势。随着自动化测试技术的成熟，写自动化测试代码的成本逐步降低，而自动化测试，可以极大提高测试效率，尤其是像回归测试这种需要频繁进行的。
+
+其次，测试设计是软件测试人员的核心竞争力。无论是自动化测试还是手工测试，测试用例是核心。无效的测试用例，用任何方法去测试，都不会达到良好的测试目的，只有测试用例设计好了，真正做到有效高覆盖，测试才是高质量的。
+
+最后，开发人员和测试人员的更多融合是一种双赢。比如说测试人员可以给开发人员提供测试用例作为测试参考，开发人员可以写更多自动化测试代码，这些方式都能有效保障产品质量。
+
+## 总结
+
+今天我带你一起分析了什么样的公司需要专职测试。同时也学习了软件测试的一些基本知识，简单来说软件测试的工作，就是发现Bug，报告Bug，跟踪Bug。
+
+要能及时发现Bug，需要针对需求进行分析和测试设计，把需求具象成一个个用户操作步骤的测试用例。通过一些科学的测试方法，像等价类划分、边界值分析、探索性测试，能有效提升测试的覆盖率。
+
+公司是否需要专职测试，还是取决于公司的具体情况，例如是否有大量优秀的工程师可以同时兼任开发和测试，有大量的自动化测试代码覆盖，有强大的发布和监控系统，时间进度宽松，用户对Bug容忍度较高。
+
+## 课后思考
+
+你们公司有专职测试吗？你觉得是否应该保留专职测试？为什么？欢迎在留言区与我分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。
+
+

极客时间专栏/geek/软件工程之美/软件测试篇/33 | 测试工具：为什么不应该通过QQ|微信|邮件报Bug？.md

@@ -0,0 +1,237 @@
+<audio id="audio" title="33 | 测试工具：为什么不应该通过QQ/微信/邮件报Bug？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ee/18/eef93fa56e6924da738e900b4113eb18.mp3"></audio>
+
+你好，我是宝玉。十多年前，当我还是个野路子程序员时，我在外面接私活做项目，客户在使用过程中遇到了Bug，直接就截个图，或者是用Word文档整理在一起，从QQ或者邮件上把Bug信息发送给我，我收到后再修复更新上线。
+
+而现在正规的软件项目已经不会再用这种原始的方式来报Bug了，而是会借助测试工具来帮助报告和跟踪Bug，即使你偶尔能看到有项目还在采用原始方式报Bug，你肯定也会觉得这样做不专业。
+
+但不知道你有没有仔细想过这个问题，为什么现在不通过QQ/微信/邮件报Bug，又有哪些测试工具可以帮助你更好地发现、报告和跟踪软件中的Bug呢？今天我们来展开讨论这个问题。
+
+## Bug跟踪工具
+
+我想你对于Bug这个词一定不陌生，它是我们软件中的缺陷或错误。这个词的诞生也很有意思。
+
+> 
+1947年9月9日，一只小飞蛾钻进了哈佛大学的一台计算机电路里，导致系统无法工作，操作员把飞蛾贴在计算机日志上，写下了“首个发现Bug的实际案例”。
+
+
+[<img src="https://static001.geekbang.org/resource/image/79/3c/796010fd083207b660547887bbc5893c.png" alt="" title="图片来源：WikiPedia">](http://en.wikipedia.org/wiki/Software_bug)
+
+虽然Bug的历史已经有60多年了，然而Bug跟踪工具却没有出现太久。软件项目中最早也是通过邮件、即时通讯等原始方式报告Bug，直到1992年才有第一个专业的Bug跟踪软件[GNATS](http://www.gnu.org/software/gnats/)。
+
+在这之后才逐步有了像Bugzilla、Jira、MantisBT等专业的Bug跟踪工具。而现在，Bug跟踪工具已经成为软件项目中必不可少的工具之一。
+
+那么，Bug跟踪工具是怎么逐步替代QQ、邮件等方式来处理Bug的呢？
+
+#### 为什么要使用Bug跟踪工具？
+
+我们在上一节学习了软件测试相关的理论知识，软件测试的主要工作就是发现Bug、报告Bug和跟踪Bug。测试人员发现Bug只是第一步，还需要报告Bug让开发人员可以知晓和定位，并且跟踪整个Bug修复的过程。
+
+用QQ或者邮件报Bug的这种方式，看起来快捷简单，但是问题很多：
+
+- Bug不能有效被跟踪，不知道一个Bug是不是已经被修复了；
+- 效率很低，开发人员频繁的被这样的报Bug的消息打断，不得不停下手头的工作去甄别Bug；
+- 不能直观的了解当前项目的Bug状态，比如说：修复了多少，还有多少没有修复，近期Bug数量是增加了还是减少了。
+
+不难看出，通过QQ等方式报告的Bug，都是文字配合图片等信息，很难检索和分类，**而Bug跟踪工具，采用结构化的数据来定义Bug，每一个Bug都有一些关键的信息可以对Bug进行分类和检索。**
+
+在Bug跟踪工具使用中，一个基本的Bug信息包括：
+
+- 标题；
+- 描述（包括期望结果、实际结果和重现步骤等关键信息）；
+- 优先级；
+- 指派人；
+- 状态（New、Open、 Rejected、Fixed等）；
+- 其他。
+
+那这样的话，就很容易的对Bug进行分类和检索，比如说：
+
+- 张三想查看所有分配给他的Bug，那只要列出所有指派人是张三的Bug；
+- 想列出所有未解决的Bug，只要列出所有状态不是Close或Rejected的Bug即可。
+
+这样对于开发人员来说，可以直观的看到自己有哪些Bug需要处理，Bug的描述信息也可以帮助重现Bug、快速定位到Bug的原因；对于项目经理或者测试人员来说，可以直观的看到哪些Bug还没解决，及时了解项目进展。
+
+另外，我在《[12 | 流程和规范：红绿灯不是约束，而是用来提高效率](http://time.geekbang.org/column/article/87129)》这篇文章中提到了项目中的流程和规范，**在软件项目中，要把好的实践流程化，把好的流程工具化。Bug跟踪工具则很好的贯彻了这一点，将Bug的解决过程流程化。**
+
+你平时在Bug跟踪系统中看到的Bug状态，看起来只是一个有限的状态列表，但背后其实是一套解决Bug的流程。就像下面这张图表示的这样，一个Bug从创建到最后结束，其实是有一个完整的流程的。
+
+<img src="https://static001.geekbang.org/resource/image/4f/dd/4f56bf4d43b652ab2b92318775a850dd.png" alt="">
+
+通过这样的流程，开发人员就可以集中对Bug进行分配、按照优先级分别解决，而测试人员则可以第一时间知道Bug处理的状态变化，及时验证，方便跟踪整个过程。
+
+#### 使用Bug跟踪工具的注意事项
+
+报告Bug的目的是为了能跟踪Bug，以及帮助开发人员重现直到解决问题。要想做到测试和开发高效协作，这里面有一些需要注意的事项。
+
+首先，所有的Bug都应该通过Bug跟踪系统管理和跟踪，不应该再通过QQ/微信/邮件的方式跟踪Bug。如果客户、同事通过Bug跟踪系统之外的其他途径反馈Bug，应该统一提交到Bug跟踪系统管理跟踪起来。
+
+然后，不能把多条Bug合并成一条，一个Bug创建一个独立的Ticket。我遇到过有些测试为了省事，把几条Bug合并成一个Ticket来报，导致的问题就是，必须这几条Bug都修复了，这个Ticket才能改变状态，如果其中一个Bug没有验证通过，需要Reopen整个Ticket。
+
+再有，描述清楚如何重现Bug非常重要。一个Bug如果无法重现，也没有日志、截图等辅助信息，那是非常难以定位的，会浪费很多开发人员定位Bug的时间。
+
+最后，不要把Bug跟踪系统当成讨论板用。在项目中一个常见的场景是，一个Ticket下面，跟讨论版一样添加了很多留言，开发认为不是Bug，测试认为是一个Bug，开发又觉得是产品设计没定义清楚，应该让产品经理来讲清楚，皮球踢来踢去，最后问题还没解决。
+
+Bug跟踪系统的主要功能是用来跟踪Bug的，不是用来讨论和扯皮的。遇到上面的情况，其中一方就应该主动一点，拉上相关人面对面讨论，当面确认清楚这个Bug到底是什么问题，然后马上解决掉。
+
+## 自动化测试工具
+
+除了Bug跟踪工具，软件测试中还有很重要的一个工具就是自动化测试工具，虽然我在《[29 | 自动化测试：如何把Bug杀死在摇篮里？](http://time.geekbang.org/column/article/93405)》中已经有了较多篇幅说明，但这里还是想继续提一下，因为我觉得，**未来自动化测试会占据越来越多的比例，很多手工测试的工作会逐步被自动化测试代替。**
+
+像美国Facebook、Google、Amazon这些大厂，单纯的手工测试职位在减少，一些手工执行测试用例检查的工作外包到了人力成本更低的像中国、印度、罗马尼亚等国家，而美国本土主要招聘的都是能写自动化测试的软件测试人员，或者直接就是开发人员来写这些自动化测试代码。
+
+这就意味着对于软件测试人员来说，要求越来越高了，不仅要会设计测试用例，还要能写自动化测试脚本。同时对于开发人员来说，不仅要写功能代码，还需要实现一定量的自动化测试代码。
+
+这些年自动化测试工具的快速发展，也降低了自动化测试的实现难度，可以方便地搭建自动化测试环境，通过简单的脚本语言就可以模拟人工操作。
+
+但很多团队还是不愿意投入在自动化测试的开发上面，宁可雇佣更多的初级测试人员手工测试。
+
+其实这个问题还是要整体来看，这就像修路，如果你从一个地方到另一个地方（类比测试所有用例），偶尔走几次，那么可以不修路（手动测试），如果你未来一段时间需要频繁的在两个地方通行（反复测试），那么最好现在就开始修建高速公路（自动化测试），这样可以节约你大量通行的时间(测试时间)。
+
+当然更多的情况其实是团队不知道该如何实施自动化测试，比如说测试人员不会写程序，开发人员太忙，或者开发人员不会写测试用例，或者不知道该选择什么样的自动化测试工具。
+
+对于这种情况，我的建议是：
+
+测试人员可以学习一些基本的编程知识，尝试自己实现自动化测试。自动化测试所需要的技术，主要是对API的调用，并不需要复杂的逻辑，其实学习门槛并不高，而且这种技术在工作效率、薪资、个人职业发展等方面的投资回报都是巨大的。
+
+从项目的角度，应该加大对自动化测试的投入，让开发人员参与到自动化测试代码的开发中。增加自动化测试代码的覆盖，对于提升软件质量是有明显好处的，通过自动化测试可以提升测试效率，及时发现软件质量问题。
+
+对于开发人员来说，如果已经有了测试用例，完成自动化测试并不复杂，这个投入其实比做一些重要性不高的功能回报更高。
+
+自动化测试工具的选择，需要根据你的软件的特点，去找出来适合你软件自动化测试的几款，然后自己搭建环境试用一下。在本文后面的附录中，我会列出一些自动化测试工具供参考。
+
+## 其他帮助发现Bug的测试工具
+
+软件测试的一个主要工作就是发现Bug，而要发现Bug，就需要对软件的各个领域进行测试，比如说有性能、安全性、兼容性等领域。
+
+这些不同领域的测试，要求也不一样，比如说性能测试要求能测试出软件是否有性能瓶颈，能达到多少用户的访问量，需要模拟大量用户并发访问；安全性测试则要求对软件可能存在的安全漏洞进行扫描、验证；兼容性测试则要针对不用环境不同设备，对软件进行测试，以确保不会因为环境不一致导致功能不正常。
+
+这些测试要么人工很难完成，例如模拟大量用户并发访问；要么需要很深的专业知识，例如安全性测试；要么需要大量的设备和巨大的工作量，比如做兼容性测试。所以这些领域的测试，就需要借助工具的帮助才能进行测试，从而发现问题。
+
+应用这些测试工具其实并不难，毕竟都有很成熟的API，网上也有很多教程，真正需要的是去执行。另外如果想要最大化工具的价值，及时发现问题，还要考虑将测试工具的应用自动化，加入到你的持续集成流程中去。
+
+以压力测试为例，你用Jmeter完成了压力测试脚本后，还可以考虑和CI集成，在每次构建时，运行一遍压力测试代码，可以在构建完成后看到直观的图表，还可以设置性能数据的阈值，如果性能指标低于阈值，会导致构建失败，这样就可以第一时间发现性能问题，缩小问题范围，并及时解决。
+
+在这里，我也帮助搜集了一些相关的测试工具供参考，具体可以查看附录。
+
+## 附录
+
+#### Bug跟踪工具
+
+在项目管理工具那一篇文章中，我已经给你介绍了一些任务跟踪系统，比如说[Jira](http://www.atlassian.com/software/jira)、[禅道](http://www.zentao.net)、[TAPD](http://www.tapd.cn)、[云效](http://cn.aliyun.com/product/yunxiao)等，都可以用来跟踪Bug。
+
+- Bugzilla
+
+[Bugzilla](http://www.bugzilla.org) 是由Mazilla公司提供的一款开源免费的bug跟踪系统。这是一款历史很悠久的产品。
+
+- MantisBT
+
+[MantisBT](http://mantisbt.org) 是一个简单但功能强大的开源bug跟踪系统，可以通过各种插件来扩展其功能。
+
+- Redmine
+
+[Redmine](http://www.redmine.org) 是一款开源的综合性的项目管理工具，不仅可以用于Bug跟踪，还可以用来跟踪项目进度。
+
+#### 自动化测试工具
+
+除了传统的桌面应用外，现在移动设备的普及，要测试的终端也越来越多。借助一些自动化测试工具，可以帮助简化多设备的测试。下面简单介绍几个自动化测试工具。
+
+- Selenium
+
+[Selenium](http://www.seleniumhq.org) 是一个 Web 端的自动化测试工具，直接运行在浏览器中，用来模拟用户操作。类似的还有[WebDriverIO](http://webdriver.io) 和 [Nightwatch.js](http://nightwatchjs.org) ，支持Javascript，API更简单更方便。
+
+- Appium
+
+[Appium](http://appium.io) 是一个开源、跨平台的自动化测试工具，用于测试移动原生应用，支持 iOS, Android系统。
+
+- Macaca
+
+[Macaca](http://macacajs.com/zh/) 是阿里巴巴开源的一款面向多端的自动化测试工具，支持桌面端、Web、移动端、真实设备和模拟器。
+
+更多自动化测试工具可以参考：《[Best Automation Testing Tools for 2019 (Top 10 reviews)](http://medium.com/@briananderson2209/best-automation-testing-tools-for-2018-top-10-reviews-8a4a19f664d2)》([中文版](http://segmentfault.com/a/1190000012016234))。
+
+#### 压力测试工具
+
+很多软件在上线后，需要面对巨大的用户访问量，但如果等到上线后才发现程序性能不行，访问量一大就会导致服务崩溃，那就太晚了。所以最好是在测试阶段，就能测试出来程序的性能如何，瓶颈在哪里，然后在发布前对程序进行优化，确保能满足性能要求。
+
+对程序性能的测试，就需要借助压力测试工具来模拟大量用户并发访问的场景。下面简单介绍一下几款常用的性能测试工具。
+
+- Apache JMeter
+
+[JMeter](http://jmeter.apache.org) 是一款开源的压力测试工具，纯Java应用程序。
+
+- LoadRunner
+
+[LoadRunner](http://www.microfocus.com/en-us/products/loadrunner-load-testing/overview) 是惠普旗下的一款商业自动负载测试工具，可以通过录制的方式制作测试脚本，上手容易功能强大，可以方便的监控和分析性能测试结果。
+
+- 阿里云性能测试 PTS
+
+阿里云性能测试[ PTS](http://cn.aliyun.com/product/pts) 是基于云端的压力测试服务，可以模拟从全国各地域运营商网络发起的流量，真实地反映使用情况，生成有价值的性能测试报告。
+
+- WebPageTest
+
+[WebPageTest](http://www.webpagetest.org) 是一个可以用来测试和分析网页性能的在线工具，支持不同浏览器，支持API。可参考《[WebPagetest H5性能测试工具入门详解](http://blog.csdn.net/qq_24373725/article/details/80091044)》。
+
+更多性能测试工具介绍可以参考：《[10大主流压力/负载/性能测试工具推荐](http://zhuanlan.zhihu.com/p/26671961)》。
+
+#### 安全性测试工具
+
+软件的安全性是非常重要的指标，有时候开发人员缺乏安全意识，就可能会导致程序存在安全漏洞。安全领域也是开发和测试之外的一个技术领域，中小公司一般不会有自己专业的安全团队，就需要借助一些安全性测试工具来帮助对软件进行安全性检测。
+
+- HP Fortify On Demand
+
+[Fortify On Demand](http://www.microfocus.com/en-us/products/application-security-testing/overview) 是惠普旗下的一款安全检测工具，可以通过分析源代码、二进制程序或者应用程序URL检测程序安全漏洞。
+
+- Sqlmap
+
+[Sqlmap](http://sqlmap.org)是一款开源免费的检测SQL注入的工具。
+
+- IBM Application Security APPScan
+
+[APPScan](http://www.ibm.com/us-en/marketplace/appscan-standard) 是IBM旗下的一款漏洞扫描工具，支持网站和移动App。
+
+更多安全性测试工具介绍可以参考：《 [11款常用的安全测试工具 ](http://blog.csdn.net/lb245557472/article/details/88572607)》《[安全测试工具篇（开源&amp;商业）](http://codeshold.me/2016/09/security_tolls.html)》《[最受欢迎的软件安全性测试工具有哪些？](http://mp.weixin.qq.com/s/OZp7Q8Jq_voTAkHj3CAMMQ)》。
+
+#### 浏览器兼容性测试工具
+
+网站开发最苦恼的问题之一就是浏览器兼容问题，不仅要兼容Chrome、IE/Edge、Firefox三大主流浏览器，还得考虑桌面设备和移动设备上的不同表现。如果人工对所有浏览器做兼容性测试，工作量比较大。好在也有一些不错的工具可以帮助做兼容性测试。
+
+- Browsera
+
+[Browsera](http://www.browsera.com) 可以对不同浏览器下的布局提供报告，包括截图和Javascript错误。
+
+- Browslering
+
+[Browslering](http:////www.browserling.com) 可以针对不同浏览器进行测试，它在虚拟机中运行真实桌面浏览器，还可以人工进行交互。
+
+更多浏览器兼容性测试工具可参考《[10个免费的顶级跨浏览器测试工具](http://blog.sae.sina.com.cn/archives/4515)》
+
+- 测试用例管理工具
+
+我们在上一篇里面已经学习了，设计测试用例是软件测试很重要的工作，有专业的工具帮助管理测试用例，也可以起到事半功倍的效果。
+
+- TestRail
+
+[TestRail](http://www.gurock.com/testrail) 是TestRail是一个专注于管理测试用例的工具，可以用它来创建测试用例和用例集，跟踪测试用例的执行和生成报告。
+
+- 飞蛾
+
+[飞蛾](http://feie.work/) 是Coding旗下的测试管理工具，对中文支持好，界面美观。
+
+更多测试用例管理工具可以参考：《[有哪些比较好的测试用例管理工具？](http://www.zhihu.com/question/26898212)》
+
+## 总结
+
+今天，我带你一起学习了软件测试工具的相关知识。软件测试，主要工作就是发现Bug、报告Bug和跟踪Bug。软件测试工具，也是围绕这三方面来帮助我们提高效率的。
+
+Bug跟踪工具，不仅可以方便的报告Bug和跟踪Bug，更可以帮助开发人员将Bug的解决过程流程化。
+
+自动化测试工具是发展趋势，未来自动化测试会占据越来越多的比例，很多手工测试的工作会逐步被自动化测试代替。
+
+除了Bug跟踪工具和自动化测试工具，软件测试中还有性能测试工具、安全性测试工具、兼容性测试工具等，这些工具都可以更好的帮我们发现软件中的质量问题。
+
+如果想要最大化工具的价值，及时发现问题，还要考虑将测试工具的应用自动化，加入到你的持续集成流程中去。
+
+## 课后思考
+
+你的项目中使用了哪些软件测试工具？看完本文，你觉得还可以在哪些方面加强对软件测试工具的应用？欢迎在留言区与我分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/geek/软件工程之美/软件测试篇/34 | 账号密码泄露成灾，应该怎样预防？.md

@@ -0,0 +1,176 @@
+<audio id="audio" title="34 | 账号密码泄露成灾，应该怎样预防？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a7/c0/a7bac620c5989d6853954855012837c0.mp3"></audio>
+
+你好，我是宝玉。我们日常总能看到各种与黑客和网络安全相关的新闻，而这其中大部分安全问题都和软件程序有关系。比如说像CSDN数据库泄露事件、携程泄露用户银行卡信息事件、有些电商网站用户可以篡改支付购买金额等等。
+
+在软件项目开发时，安全是一个很容易被忽略的问题，但又可能会造成严重损失。所以我们在软件开发时有必要对安全问题引起重视，防患未然，构建安全软件。
+
+今天，我将带你了解一下软件开发中的安全问题，学习如何构建安全的软件，以及出现了安全问题之后该怎么办。
+
+## 安全问题本质是技术风险
+
+如果你还记得《[15 | 风险管理：不能盲目乐观，凡事都应该有B计划](http://time.geekbang.org/column/article/88259)》这篇文章中的内容，我在其中提到，风险是指不确定的事件，一旦发生，将会造成消极的影响。
+
+**安全问题，本质上也是一种技术风险，没发生问题的时候一切都好，一旦发生就会有严重的影响。**在对安全问题的应对上，你也可以借鉴对风险管理的方法来改进软件的安全问题，也就是风险识别、风险量化、应对计划和风险监控。
+
+在做风险管理时，首先要做的就是识别风险和对风险量化，对于安全问题，你也可以先思考一下：软件项目中安全问题的主要来源是什么？搞清楚安全问题的来源，以及造成的后果，你就可以对软件中导致安全问题的情况有一个基本的识别和量化。
+
+软件中的安全问题来源主要可以分为以下三大类。
+
+- 第一类：恶意输入
+
+很多我们熟知的软件安全问题都属于此类型，就是黑客通过恶意输入，然后绕过软件限制对系统进行攻击和破坏。
+
+像SQL注入，就是黑客把SQL命令输入到软件的输入框或网页的URL查询参数，欺骗服务器，执行恶意的SQL命令。这样可以绕过密码验证，登录管理员账号，或者删除数据库数据，甚至控制服务器。
+
+还有像XSS攻击，将恶意代码通过外部参数或者用户输入的方式植入网页中，获取用户的Cookie等敏感信息、盗用管理员权限，甚至非法转账。
+
+这类问题都是由于恶意输入导致的，应对恶意输入的问题，最简单有效的方式就是对用户输入的数据，做严格的校验，格式化。
+
+- 第二类：假冒身份
+
+很多程序对于用户身份的校验比较弱，可能会导致黑客假冒用户身份做出超越权限的事情。
+
+比如说，我见过有的网站，把后台入口隐藏起来，而没有做权限控制，导致黑客猜到地址后就可以进入后台操作。
+
+还有的游戏后台不做验证，直接接收传入的数据，导致可以伪造游戏用户发送数据，破坏游戏平衡。
+
+如果对用户的身份不做严格的验证，很可能就会导致假冒身份的安全问题。应对策略就是要对用户的身份做验证，尤其是涉及敏感权限的操作，甚至要做两重验证。
+
+- 第三类：数据泄露
+
+很多软件都储存了用户的敏感信息，比如用户帐号密码信用卡记录，或者服务器的敏感信息，比如数据库连接字符串、登录帐号密码，而这些数据是有被泄露风险的。
+
+一些软件会把服务器上的敏感信息打包在程序中，而程序可能会被反编译导致敏感数据泄露。携程泄露用户银行卡信息事件中，就是因为把用户信用卡信息记录在日志中，日志泄露导致用户信用卡信息也被泄露，造成盗刷等严重问题。
+
+还有CSDN，对用户密码明文存储到数据库中，数据库泄露后，用户密码也跟着一起泄露了，而大多数用户习惯于在不同的网站也用相同的密码，导致在其他网站的密码也一起泄露了。
+
+对于软件来说，** 我们不能假设数据存储是安全的，而是要考虑到数据是有泄露的可能，提前做好预防措施，对敏感数据进行加密。**
+
+在了解了这些常见的安全问题来源和可能带来的后果之后，我们在软件开发时，就可以对薄弱环节、重点问题进行提前预防，在开发时就考虑到可能的安全漏洞，做出科学的应对方案。
+
+## 如何预防软件中的安全问题？
+
+预防软件中的安全问题，也可以参考对风险管理的策略。在风险管理中，对风险识别和量化后，接下来就是要制定应对计划了。
+
+很多开发人员觉得安全问题，只要在软件开发完成之后，测试阶段做一个安全测试就可以了，但这样做等于把安全问题留到了最后环节，是很难达到对安全问题进行高质量管控的。
+
+一方面，对于安全测试来说，很难覆盖到所有可能存在的场景，可能会出现疏漏，导致安全漏洞被利用。另一方面，如果测试阶段发现安全问题，可能需要修改大量代码，甚至于要重新设计，这时候成本就太高了。
+
+所以应对安全问题，最好的方式就是在整个生命周期中都做到重视安全问题，各个阶段都考虑到安全方面的问题，才能真正做到防患于未然，构建出安全的软件。
+
+那么在软件开发的各个阶段，都需要如何考虑好安全方面的问题呢？
+
+**需求阶段**
+
+需求是软件项目的源头，**在确定需求，做产品设计的时候，不仅要考虑到功能上的需求，还要同时考虑到安全方面的要求。**这样当你在架构设计的时候，就不会轻易遗漏安全方面的架构设计。
+
+尤其是对于一些外包项目，如果在需求中没有提出安全需求，大概率外包公司是不会帮你考虑这些需求的。
+
+需求阶段，涉及用户输入的内容，需要考虑到可能的恶意输入，做出针对性预防措施；对于涉及用户权限的，要求有身份的验证，一些对安全要求极高的，可以在需求上就要求做双重验证；对于有敏感数据的，可以在需求上就要求对数据进行加密。
+
+举个简单例子，比如说用户登录功能，如果让你提出安全方面的需求，你会考虑到哪些需求？这里我简单列几个功能参考：
+
+- 登录网页使用Https或者在传输密码时加密；
+- 增加图形校验码，避免恶意攻击；
+- 密码失败次数过多，应该锁定用户一段时间；
+- 记录用户登录IP。
+
+当你在需求阶段就提出了安全性的需求，设计、实现和测试时自然不会遗漏掉安全方面的内容，从源头上就让大家有了安全方面的意识。
+
+**设计阶段**<br>
+在做设计架构时，最重要的事就是要把安全加入到设计目标，有了安全方面的设计目标，自然能找到很多安全相关的解决方案。
+
+为了保障在设计时就考虑好安全方面的问题，在做架构设计方案的评审时，也需要增加安全方面的评审，确保有安全方面的考虑，确保技术方案切实可行。
+
+现在架构设计领域，也有了一些业界公认的好的安全相关的设计原则，比如说攻击面最小化、权限最小化、纵深防御等。
+
+- 攻击面最小化
+
+攻击面就是指程序被用户直接访问到的部分，比如API、网站等，这些暴露给用户的地方也是最可能被黑客攻击的地方。
+
+暴露的面越多则风险越高，攻击面最小化的设计原则，就是说尽量减少暴露黑客可能发现并试图利用的攻击面数量。
+
+举例来说，你的数据库应该关闭外网访问，避免黑客直接攻击数据库导致数据泄露。还有像对于一些复杂的多网站业务系统，实行单点认证，就可以让所有业务都在一个地方登录，你可以在这一个地方做到足够安全，这样所有网站的登录都是相对安全的。
+
+- 权限最小化
+
+权限最小化的设计原则就是对于系统的用户、文件访问、进程运行等，都只给予其能拥有的最小权限，这样可以保证一个应用程序或者网站被攻击、破解，能将损害降到最低。
+
+举例来说，以前在部署Asp.Net程序的时候，运行Asp.Net的程序是单独的一个用户，这个用户所拥有的权限是只能运行程序所在目录，不能超出其目录范围，这样即使用户上传了恶意木马文件，那么也只能控制这一个目录，避免了进一步的损失。
+
+- 纵深防御
+
+纵深防御的设计原则，指的是从不同的维度去实施安全保护措施，从而缓解被攻击的风险。纵深防御并不是同一个安全方案要做两遍或多遍，而是要从不同的层面、不同的角度对系统做出整体的解决方案。
+
+这里我给你举一个电商网站的例子（摘自：《[代码未写，漏洞已出—架构和设计的安全](http://shimo.im/docs/oNJvDIXQw3EgQGyn)》）。
+
+> 
+国内中小电商，一半以上在早年都犯过这个错误，现在基本都修复了。电商的交易和支付系统之间流程是这样，一个人过来说老板我要买一台冰箱，多少钱？两千。OK，你把钱付给支付系统。因为支付请求也是在用户侧的浏览器里提交的。这个过程对用户是不可见的，但攻击者实际上可以修改这个数据。攻击者可以修改浏览器提交的数据，本来交易系统让他提交2000元，攻击者改为提交1元，然后支付系统就返回OK，说我收到钱了。这个OK到交易系统那里，交易系统一看支付成功了，那就安排发货，1元钱就把冰箱买到了。
+
+
+你看，单独从支付系统和交易系统来看，设计上都没有问题，都对数据输入做了校验，但问题是没有站在一个系统的整体角度去考虑，没有考虑到不仅要校验交易有没有成功，还要校验交易的金额是不是匹配。
+
+当然解决方案其实也很简单：
+
+> 
+不要只反馈是否OK，同时也把支付的金额和OK一起返回过去。是支付2000元OK还是1元OK。这就解决了问题，现在的电商都改成这个设计了。
+
+
+通过这样一些好的安全设计原则，就可以在设计阶段把很多安全问题预防好。
+
+**开发阶段**<br>
+只是设计阶段做好安全相关的设计还不好，很多安全问题其实都是编码阶段时，没有好的编码习惯、没有良好的安全意识导致的。
+
+对于开发阶段的安全问题预防，需要从以下几个方面入手。
+
+- 编码规范中加入安全相关内容
+
+对于用户输入的数据，需要有校验，防止恶意输入；对于涉及权限的操作，要检查用户权限；对于敏感数据要进行加密处理；对于用户的操作，要有日志记录；不能在日志中记录敏感信息等等。
+
+- 要有代码审查
+
+代码审查其实在我们专栏提过很多次，这也是预防安全问题一个行之有效的手段，通过代码审查，及时发现代码中的安全问题。
+
+- 增加安全相关的自动化测试
+
+现在有些安全工具，可以帮助对代码做安全检查，甚至可以和CI集成，如果增加相应的自动化安全测试代码，也可以第一时间对代码中的安全问题进行反馈。
+
+## 测试阶段
+
+在测试阶段，除了功能测试以外，增加对安全性方面的测试。除了增加相应的测试用例，也可以借助一些安全测试工具（可参考上一篇“[软件测试工具](http://time.geekbang.org/column/article/95533)”这篇文章）来进行测试。
+
+## 上线维护
+
+上线部署时，不部署源代码，只对编译后程序部署；删除Debug文件。
+
+对服务器进行安全设置，比如说严格限制端口，只保留必须的端口；只对少数服务器开发外放服务；开启操作日志；对访问目录设置最小的权限。
+
+通过对整个软件生命周期都做好安全方面的考虑，并落实到位，才能真正保证好软件的安全。
+
+## 如果真的出现安全问题怎么办？
+
+是不是我们在整个软件生命周期都做好安全方面的考虑，也落实到位，就完全不会有安全问题了？
+
+安全问题就像程序的Bug一样，没有谁能保证绝对的安全，就像风险管理的最后一步风险监控那样，我们必须做好Plan B，万一出现安全问题，马上应对，将损失降到最低。
+
+首先，要设立应急的流程。当出现安全问题了，根据流程，知道该找谁，应该怎么去第一时间恢复生产，避免进一步损失。
+
+其次，要分析程序的漏洞在哪里。通过分析日志，找出漏洞在哪里，才能针对性去修补漏洞。
+
+最后，要总结原因。从错误中吸取教训，看问题是在哪个环节导致的，必要的话，就改进开发流程，避免类似的安全问题再次发生。
+
+## 总结
+
+今天我带你一起学习了如何构建安全的软件，软件的安全问题本质也是一种技术风险，可以借用风险管理的知识来帮助构建高安全性的软件。
+
+软件安全问题主要来源是：恶意输入、假冒身份和数据泄露，要注意对输入数据的校验、对用户身份的校验和对敏感数据的加密。
+
+构建高安全性软件，最好的方式就是在整个生命周期中都做到重视安全问题，各个阶段都考虑到安全方面的问题，才能真正做到防患于未然，构建出安全的软件。
+
+安全问题就像程序的Bug一样，不能绝对避免，同时也要做好应对措施，在出现安全问题后，将损失降到最低，并且避免以后发生类似问题。
+
+## 课后思考
+
+通过对这篇文章的学习，你觉得你所在项目中，在安全方面有哪些可以改进的地方？你有哪些提升安全性的经验可以和大家一起分享的？欢迎在留言区与我分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。