持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第3天，点击查看活动详情
一：IT团队和IT工作
业务经理BA：
某公司想做一个产品，然后就会指定一个负责人，由他负责需求的产出，开发团队的对接，以及产品的打磨。
市场需求：
描述为什么要做这个软件，这个软件有些什么功能。
验收测试：
产品出来之后，还要经过业务经理的验收。
产品工程师SA：
IT公司方的需求人员，一种是业务经理写出他的期望，由产品经理来打磨需求（项目）。二种是产品经理自己研究一个系统，能够帮助公司赢利（产品）。
产品需求：
编写开发需求文档，研究需求/产品细节，做原型。
可用性测试：
验证开发的实现，与产品需求是否一致。更多站在用户角度/界面角度进行测试。A/B测试
项目经理PM：
核心工作是实现产品经理的需求，打造这款软件出来。包括：打造开发团队、测试团队；管理开发测试团队
（需要让团队按时、按质、按量完成工作）；对接前后工作（对接需求、第三方系统、运维）
开发工程师DEV：
前端工程师：
就是看得见的那一端，一般是做界面的。
前端工程师的主要工作职责：界面样式（HTML5，CSS）、交互设计（js，AJAX）前端工程师的分类：WEB前端，App开发，小程序开发（js）
后端工程师：
写逻辑代码，主要以算法为主。
数据库工程师：
数据库建表、语句编写，数据库优化，数据库安全
测试工程师tester：
主要分为功能测试、性能测试、安全性测试、单元集成测试（接口测试）
专业测试团队更多的立足于业务的正确性，即数据处理的正确性。
其次是性能测试和安全性测试
最后需要提到的是我们如何把测试变成自动化
运维工程师OPS：
就是把软件部署到生产环境，生产环境的系统非常多，需要专人维护。
需要对系统进行监控，系统可能会时不时爆掉。资源不够用，黑客攻击。
也会研究自动化运维（自动化部署，自动化资源维护）
运营工程师(客服)：
软件要推广，运营工程师的核心工作就是推广。软文、地推
二：软件生命周期
软件从构思到最终结束的整个过程
1.可行性分析
在有市场需求的时候，就会进行可行性分析，分析是否值得做。一般是公司商务、售前相关成员进行讨论。
一般可行性分析主要会关注于：技术可行性、商务可行性、资源可行性
一旦可行，项目就会立项。立项即会任命项目经理，由项目经理组建开发测试团队。
面试题：在项目立项前，测试团队不需要提供任何工件（工作产物）
可行性分析阶段，可以知道项目的大概。
2.需求分析
专门需求人员（产品经理）对业务需求进行全面分析，获取业务内容以及业务规则。会得到需求规格说明书。
现在有很多需求说明书，不再特别详细了。现在会像用户讲故事一样，把需求描述出来。把核心点描述出来，剩余
部分由开发进行发挥，这时候系统实现只要合理就行。
用户故事的写法规则：
我期望实现一个什么样的规则，以便我能够达到什么样的效果。
1.我期望输入用户名、密码和确认密码还有手机号就能够注册成功。
2.我期望用户名，密码和确认密码还有手机号不能为空，以便系统能够获取这些数据。
3.期望用户能够输入正确的手机号，以便实现实名注册。
4.手机号只能进行一次注册，不能重复注册。
3.系统设计
理论上的系统设计包含概要设计、详细设计。是指以前的系统非常大，就需要先做框架设计再做界面、功能设计。
在开发编码中，更多时候用接口这词来描述（指功能的名称）
3.1 系统设计有一些具体的方法：
Use Case用例法，站在用户使用角度，画出用户操作图（功能与功能之间的联系）流程图：以数据为导向，从哪里开始，到哪里结束。一般是针对于功能而言的。
数据流图：完全针对于数据而言的图。
ER图：数据库设计的范畴
系统设计活动在敏捷开发中被弱化了，因为都是小块实现，而小块实现的设计要求并不多。
4.编码
开发的代码实现，常见的开发代码是：Java语言、PHP语言。Python语言也有用于开发，但不多。Python语言比较多用于测试、运维、大数据、人工智能等领域。 常见的系统有：WEB系统和App系统。WEB系统是网页型的，用户只需要输入网址即可，即客户端不需要做开发，但是客户端仍然还是有界面。界面仍然是需要开发的，仍然属于前端开发。还有一部分后端代码，只是前后端 代码在一起。 App系统也有前端和后端，前端代码被压缩成了apk或ipa程序包。它有后端（服务器端）是用Java开发的，要连数据库。它的前端apk包是用java开发的，ipa包是用swift语言开发的。 客户端：android app WEB服务器：tomcat 数据库：Mysql WEB服务器和数据库服务器属于后台，一般放到阿里云上。
5.测试
单元测试：
对程序模块进行测试，对类、方法进行测试叫做单元测试。
集成测试：
因为开发是一个模块一个模块的累加的，所以模块累加之后的验证
系统测试：
针对于整个系统的测试，集成测试一般是针对于功能进行测试。而系统测试是将后台功能（接口）和界
面一起联测。其次是性能测试和其他非功能测试。
验收测试：
就是客户验收，或者是产品经理验收。
6.运行维护
三：软件测试流程
从大的角度：要做什么-->怎么做（策略）-->开始做
1.要做什么（需求）
需求人员确定要做一个什么样的系统，开发人员根据需求来实现这个功能/系统，测试人员去验证这个系统是否与需求所说的一致。 有了需求就能够知道怎么开发，就有了对应的实现。同时有了需求，也就知道了如何测。
1.1 测试需求
是针对于/满足于测试的需求，因为产品需求有一些关于测试的细节可能没涉及到，所以测试人员会在产品需求的基础上再做进一步的分析。 测试有一个特点：要将所有合法的用户行为（包含期望结果）和非法的用户行为（包含期望结果）都进行验证。
2.怎么做
会考虑两个问题：测试范围和测试方法（测试用例） 我们通常所说的测试策略就是测试方法，一般是针对于整个系统而言的测试方法。如果是针对于单个功能点而言， 就是测试用例设计方法。
3. 测试执行
具体来进行测试
四：软件测试过程
测试按照阶段划分，可以划分为四个过程：单元测试、集成测试、系统测试、验收测试
1.单元测试
针对于模块、类方法的测试，一般是代码层级的测试。由开发完成。 理论上严格的单元测试，可以发现80%的缺陷。开发人员做单元测试，效果并不好。
2.集成测试
集成是单元模块与单元模块集成起来，形成一个具体的业务功能。集成测试的目的是为了测试后台服务器端业务处理（数据处理）是否正确，并不需要界面才能完成测试。 集成测试可以认为是一种不需要界面的测试，就用一个工具直接传数据给到后台，通过后台的接口接收数据来验证后台业务功能是否正确。又把这种测试叫做接口测试。
3.系统测试
针对于整个系统的测试，集成测试一般是针对于功能进行测试。而系统测试是将后台功能（接口）和界面一起联测。其次是性能测试和其他非功能测试。 ### 系统功能测试：主要核心在用例设计。 性能测试：性能测试是验证多用户使用这个系统，响应时间是否满足。依托于功能的正确，如果用户不多，性能不受影响。
4.验收测试
系统测试完成之后，我们会要求UAT（产品经理团队成员）过来测试系统是否满足需求，以及是否用户使用舒适。
UAT的核心工作：
验证功能有无多或少，会用真实数据把他们平时所有的操作全部在系统演练一次。对于数据的准确性，UAT关注不多。UAT对界面关注会比较多，而且要引导UAT多关注界面使用。
SIT测试的核心：
所有的场景全部验证，更多关注特殊场景，UAT测不到的场景。数据验证要多花心思。验收测试包含：alpha测试和Beta测试，即内测与公测。 独立测试团队的优势：
- 专业的人做专业的事，因为测试自己的测试思维，可以发现更多的缺陷。
- 因为专业，做得久，所以速度快。专职测试人员的测试效率更高。
测试方法
1.黑盒测试
黑盒测试是把被测对象（功能）看成是一个黑色盒子，即看不到里面的实现（代码）。功能的特性是输入、处理、输出型。我们通过输入各种不同的数据，来检查输出结果是否正确。进而判断程序的处理是否OK我们绝大多数测试思维都是黑盒思维，黑盒测试的本质就是验证所有用户的所有操作，我们的操作行为（场景）主要是通过不同数据形成的不同场景，还可能会有重复操作也是一种场景，其他操作也可能成为新的场景。做不同的操作，检查输出结果是否正确。测试的核心汩检查结果，没有结果检查不叫测试。
2.白盒测试
把被测对象看成是透明盒子，即能够看到里面的代码，那么就是对代码进行测试。对代码进行覆盖，例如语句覆盖。
3.动态测试
运行程序的测试，主要目的是为了和静态测试做区分。
4.静态测试
静态测试是不运行程序的测试，以前认为测试只是对程序进行测试，但是被认为过于狭义。认为不运行程序也能测，就叫静态测试。静态测试是对文档进行测试，而我们工作中需要对文档进行检查的，对文档的检查我们叫做静态测试，又叫评审。
5.回归测试
回归测试是指把测试过的内容再测一遍，再此回归测试有三种情况：
- 测试人员提交一个Bug，开发人员修改了代码，修复了此Bug，需要验证Bug是否改好。这叫基本修改的回归
测试。 2. 但是Bug修复之后可能会引发新的Bug，我们要对这个修改以及周边功能进行测试。即扩大测试数据的范围和功能点，这种仍然是把测试过的东西再回归了一遍，但是回归的范围增加了。这种叫做基于周边影响的回归测试，是我们通常使用的回归测试。 3. 将所有的功能/用例全部回归一遍，这叫全量回归测试。与前一轮测试没有区别，所以我们会叫做第二轮测 试，很少会说回归测试这个词。一般第二轮测试的内容是相同的，但使用的数据是不相同的。
6.冒烟测试
开发提交代码的时候，需要先花抽个烟的功夫进行测试。验证开发代码的质量，如果OK则转测试，如果不OK则重新开发后再提交。 冒烟测试的策略是：对核心功能和核心场景进行测试。也就是把所有功能点跑一个正向用例。 冒烟测试不通过的原因是：代码有严重质量问题，或者部署时参数设置不正确。 开发提交版本的频率一般较高，而冒烟测试就会变得比较多了，所以这时候需要自动化测试。
7.手工测试和自动化测试
7.1 手工测试
狭义的手工测试：全程用手来完成（输入、操作、结果检查）
广义的手工测试：可以使用工具，但至少有一个环境是人肉完成。
7.2 自动化测试
自动化测试是指操作和结果检查自动化，数据输入部分人肉完成（仍然需要用到用例设计方法）
自动化测试一般应用于冒烟测试阶段，因为冒烟测试的频次比较高，冒烟测试的检查可以比较宽松。
