为什么要测试？
[img]C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/f755cc4f539d410ba44d658df187435f/q%24_j%7B@nuk%2918jr%7Bnvec@y2p.jpg[/img]
1.软件的非正常运行 或者自身的缺陷也会引发很多问题.
非正常运行状态：是指软件的一些逆向操作导致软件失效或缺陷（bug）.
自身的缺陷：软件在开发完成之后是没有被执行测试的，所以会存在许多问题。
2.软件是由代码和文档组成的，而这些都是由“人”来设计和编写的，人都有可能犯错。
文档：需求文档；开发是依据需求的文档的说明执行代码的开发。
代码：开发所编写的项目代码
3.环境也会影响软件，以致出现软件“失效”现象
每个环境的配置情况不一样，这些环境的配置也会导致软件无法使用。
开发环境，测试环境，预发布环境，生产环境
不同的环境，服务器的配置，以及其他硬件上的配置都存在差异
4.软件测试活动只是关键的质量保证活动之一
产品经理：尽可能将用户需求梳理正确，保证文档正确性
开发人员：开发代码的质量，软件的质量。
测试人员：最后一道关卡，来进行测试保证产品的质量。
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/d8c19be40ed94384807918871c72a226/clipboard.png
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/8f0853f1c86648cea006b3401829effb/kvmta%25x%5B%7D%25bh%24w5%29%28p%7Dplcw.jpg
测试用例：是我们测试人员执行测试的依据
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/16bc8ff357bc499aab6479b002c69fb9/%60%25o_%28d%28%28h%7B%5D%60w9%5Dwol9kn8p.jpg
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/0a497e7003a846999606e6726fdf2e0b/61m5980k%7D@%7Eza5%602x3fakn6.jpg
软件生命周期的阶段？
1.客户的问题引入或定义：
产品经理引入客户的需求
2.可行性分析：
技术：我当前项目组的开发技术可不可以支持项目开发工作
经济：我当前项目组的资金能不能支持项目组的运作。
当前开发出来的产品是否具有一定经济价值
政治：符合政治要求，不能出现政治敏感话题。
法律：不能涉及黄赌毒
3.项目招投标
项目组拟建发布公告，吸引有资质的公司（承包商）来承担我们公司当中一部分的开发工作。
示例：微信视频，朋友圈，支付，聊天，小程序
将支付交给其他公司来做。 4.项目立项
1.成立项目组
2.招人，制定计划，分配任务，制定项目周期。
5.需求分析
当前功能具体的需求文档/原型图精选分析
1.开发分析完成之后也执行开发工作
2.测试分析了解需求，方便后续更加全面执行测试。
项目组所有组成员，针对产品经理他输出的需求文档进行分析了解
6.开发阶段
设计：设计我们当前系统的开发框架
开发：编码，实现需求当中的功能，开发设计开发逻辑，编写编码。
测试：针对开发完成的产品，进行检查测试，测试人员执行测试，找出产品bug进行修复。
7.维护
1.正式推送用户使用
2.维护工作，对接客户，解决客户问题，
3.准备下一阶段的开发工作。
典型的软件生命周期模型有哪些？
什么是软件生命周期模型？
就是当前软件开发具体实施内容的阶段。
H/V/W/瀑布模型，增量开发模型，迭代开发模型，敏捷开发模型。
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/86ba1775882b400db200baf8723fd895/bmja_%25%5Bvc%7Eh%25u%24eesstl%287l.jpg
瀑布模型：
瀑布模型是在1970年提出，他的开发模型是由上到下按阶梯进行，每一个阶段任务的完成代表下一阶段的任务开始，适用于项目管理。
缺点：测试行为在末尾阶段，很难在前期引入一些问题，一旦后期出现需求方面的变动，会导致返工的工作量较大。一旦后期出现问题也会引起返工工作量增加
显示场景当中都是按照用户的需求不断完善当前的工作。
优点：1.适用于大型的项目管理；2.他清晰的表达了软件开发的全过程
使用瀑布模型的要求：
1.需求稳定，不会出现频繁的需求变更。
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/d97f0e16df6a4fda91bf437c4f409c23/%29tj%5Bw3%29%29di%25%60rd_y%24jt1awt.jpg
1.用户需求：产品经理对接客户收集客户需求，整理输出成需求文档/原型图
2.需求分析：
分析的对象：分析当前的需求文档，需求原型图，分析当前的业务逻辑以及功能实现是否正确，以及当前的技术是否可以支持相对应的开发工作。
产品经理会召开需求评审会议，在会议当中产品经理讲述他需求文档当中的一些功能点，以及具体的业务逻辑，以及当前开展专业名词讲解。
测试开发人员，进行需求了解，针对产品经理讲述的功能进行评审，看他讲述的过程当中是否存在需求模糊的地方，以及需求矛盾的地方，以及当前是否可以实现该功能
目的：达到项目组需求理解一致，没有任何需求上的歧义
3.概要设计：HLD
概要设计是由谁设计的？ 是由开发人员进行设计
概要设计主要设计系统的开发框架，以及服务器，数据库等等相关的设计工作，然后输出相关的文档。
4.详细设计：LLD
详细设计也是由开发人员进行设计的
主要设计：项目当中一些细节功能点的设计工作，业务功能逻辑的设计
5.编码阶段：
开发人员根据概设详设文档进行开发代码的工作
6.单元测试（白盒子测试）
开发完成代码之后，进入单元测试，检查所写的代码，以及运行代码看有没有出现问题
7.集成测试：IT
集成测试也叫做：组装测试，把所有开发开发好的功能集中在一起进行测试
第一种：模块与模块组装对接
例：支付模块，聊天模块，朋友圈模块，小程序模块 集中在一起进行对接测试，来看有没有产生的问题
第二种：系统与系统进行组装对接
例：美团系统对接 微信系统/支付宝系统/银联系统 的支付功能
8.系统测试：ST
系统测试内容：针对我当前系统的所有功能进行详细的检查，包含我功能下面所有子节点，以及相关的细节进行全面检查。
包含的测试行为：需求测试，界面测试，功能测试，兼容性测试，安全性测试，可靠/可用性测试，移植性测试，性能测试，易用性测试。
9.验收测试：UAT
阿尔法 α：由公司项目组员工进行验收测试。开发，产品，测试都会在场，进行验收这个产品到底合不合格，有没有达到用户的使用标准，还有没有bug。
贝塔 β：由客户进行验收，测试完成之后，将产品交付给客户进行验收，后续再跟进用户反馈的问题做一些整改
V模型的输入与输出关系；
输入：用户需求 输出：需求分析
输入：需求分析 输出：概要设计
输入：概要设计 输出：详细设计
输入：详细设计 输出：开发编码
输入：开发编码 输出：单元测试
输入：单元测试 输出：集成测试
输入：集成测试 输出：系统测试
输入：系统测试 输出：验收测试
先阶段系统测试以及集成测试以及合拼：
简称SIT 系统集成测试，在这个阶段所有集成测试的内容，系统测试的内容在同一个阶段进行执行。
V 模型虽然他概括了所有的测试阶段的流程，但是他的测试流程阶段依旧在开发编码之后，对于前面的问题在我执行测试的阶段才引入，导致我需求理解不透彻，测试覆盖不全面，导致增加测试市场。
V模型：其实也是瀑布模型的衍生，测试阶段还是在开发编码之后，这个模式，还是会导致一旦出现需求变更，或是重大问题的时候，返工的工作量较大，他是第一个注重测试行为的开发模型，将测试行为划分为4个阶段（单元测试，集成测试，系统测试，验收测试）
优点：1.清晰表达了全部的开发过程，便于控制每一个开发过程的任务进度
2.将测试行为具体细化（单元测试，集成测试，系统测试，验收测试）
3.每个阶段的行为都有了参考的依据，同时他还是一个单元结构的模型，每个测试节点，都可以参与对应串行节点的内容
缺点：1.测试行为依然在开发编码结束之后，前面很难在需求分析就引入一些问题。
2.后期如果出现需求变更，或是重大问题，导致返工的工作量增加。
W模型：
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/1454e628dc93451384004eab03ad5d25/x_7m%28j8_7%5B%7Bw0%7Bg%24uv%7Btjoc.jpg
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/4ae647a7fbe54b8db07e1f05be406a58/41eubb0010jh2ex86mdqpmo.jpg
他是把测试阶段提到需求分析进行同步进入介入工作
W模型，每一个对应的阶段执行对应的测试。
优点：1.测试行为伴随着整个开发周期
2.开发和测试进行并行，可以很好的掌握开发测试进度
缺点：1.1.对测试人员的技能要求比较高
2.有些项目根本不会
H模型（重点，应用较多）
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/9e83f9c3ed5546298a9c3b417267b802/xo@x7cx0rd1nqrv%29%60zc%5Bmvk.jpg
项目和产品的区别：目一项般会以产品进行命名.
项目和版本的区别：一个项目包含多个版本
SRS全称Software Requirement Specification 软件需求规格说明书
testlink(BUG用例管理工具)
test case TC（测试用例）
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/5abc0dd7256e4b77b05c0c325acb3971/_82cy%28we7e5phtvxy5%7E9%7Dz0.jpg
[img]C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/1a9959cbde5e404584862416141683b3/2thn2y9q%24%60u%28@g8q%2535d@kf.jpg[/img]
coding编码阶段
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/34cd64257bd140129c37b4fd7df5f3b0/2%7B6%291gm%5Bcj%7B_%5B7aj_%28zgh3v.jpg
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/5df5dbed59fe44ce88000ab4d51fc713/ee%7Eet%28ltnfkekx6fi2hm%7D%25c.jpg
电商的主题业务流程
商品添加--进行支付--下单成功--待发货
如果支付功能出现问题，就造成了堵塞。后续的功能测试人员无法进行。
只有主题的流程通畅，才能针对每个节点的子功能进行检查。
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/48292e9c599e41b5b8f892ec579cc9fe/%286%7E7b%60cw%25u1udsr_%60yv%7Evao.jpg
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/4a0364f79d484d99ae612b2003e3ee7b/9gxk99%5D%7B8g_mn%291vg%24%248ftt.jpg
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/91f804d424774e3d88931e71d5bb41b4/%7E_npivvej%7Dkk%5D5pxqn%7D%5B%5B%25c.jpg
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/a864c8304d8e4357b5bf0809b63009fb/9@%28%254i8mf4ejzski193k6jy.jpg
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/feaf46e14842498b9554b46808ca84ac/clipboard.png
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/863190b246cd40a9b695cb5cdf0bbb4e/clipboard.png
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/e19f71cb05cb488ebbfa11cf82cdd271/clipboard.png
敏捷开发模型
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/e3c73b24f5634331a78a51300db8f995/clipboard.png
没有具体的模型展示图，他在1990年提出敏捷开发模式，开发周期短，能够快速适应市面上的需求变动
敏捷开发模式-->1-2周一个版本功能.
开发周期短，它能够快速适应市场，项目紧急就是1个礼拜一个版本，不紧急可能1-2周左右时间完成一个版本的开发。
注入的理念就是：1.快 2.强调研发部门一个沟通协作的能力，在敏捷开发模式当中不会产生一些实质的文档，强调的是人与人之间的沟通.
缺点：1.虽然敏捷开发周期短，也预示着测试覆盖的功能不全面，会导致线上产生一些问题.
2.对开发/测试要求比较高，敏捷开发模式一般很少会有实质性的文档产生，强调的是人与人之间的沟通。
增量开发模型
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/fb3003be5d2f43b6a8cc2675b1abdbc9/clipboard.png
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/a3920b184dce49ffa05d6a7455eed5ca/3qk3jmcnb_dbr0%29t%25idjh3n.jpg
增量开发模型优点：1.将所有已知的功能模块化，可以分批次的交付给用户，客户也可以了解到我们当前软件开发的进度.
2.开发顺序灵活，能够自由调整开发顺序，也可以快速的适应市场，能够先开发一些稳定的模块
迭代开发模型：
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/cb1b4e4e4c554237882a30b9f5b67b0a/clipboard.png
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/d7f8a70ee85b46558722a8ad1285ca1f/r0sy@p%28%24r42z%7Dohtw9%7E9d2f.jpg
先做成一个项目交给用户使用，在用户使用的过程当中，我在进行频繁的迭代，增加一些性的功能，这些功能都是未知的，根据市场的需求进行迭代功能。
迭代开发模型不像瀑布模型一样非常庞大/完美，他是一个阶段一个阶段实现部分功能.最终迭代完成之后交付给用户一个完善的产品.
1.开发周期短，每个阶段的成果都可以快速的交付给用户
2.降低产品风险，制定工作计划进行推进，在推进的过程中可以结合上一个阶段用户反馈的问题进行细化和优化产品。
迭代开发模型和增量开发模型的区别：
迭代的过程阶段，我是未知的，我是根据用户不断反馈来完善产品
增量是我已知的功能，按模块划分交付给用户
测试的基本原则？
[img]C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/38abf862802d4a15a269eec34c2ba521/%28@xlp%25d%7E%5D%7D%25h_@f721msyqa.jpg[/img]
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/bc146b4a1f5c412a93700971f2f4a025/4%7Danry6pf_%24tusdid%5D%609uzi.jpg
测试的基本原则：
1。测试标准是用户需求：
但前测试的软件是否达到了用户使用标准。
测试不单单是软件本身的测试.
网络
硬件配置
环境
兼容
服务器
数据是否正确
app手机物理硬件配置
网络情况
软件外在没有失效，并不代表软件是可用的.
穷尽测试不可能的.
针对条件组合情况，只是挑选几条测试组合情况进行测试
二八原则：针对出现问题比较多的模块，我们测试人员应该更加仔细的检测，一个问题的出现会导致新的问题出现.
杀虫剂效应：当前新开发好的功能模块，执行以前的测试用例去排查问题，找到问题的几率为零.我们需要根据新的版本去更新新的测试用例。
测试活动依赖测试对象：关注界面 关注功能 关注性能 关注兼容性
关注的点不一样，发现的问题也是不一样的，我们应该在早期测试计划当中就制定好所有的测试测试策略，来保证全方位的测试覆盖度。
在项目开始时，就应该制定好软件质量标准
有了质量的标准，那么我们所测试出来的结果，才能够正确的分析产品的质量，进行评估。
C:/Users/Administrator/AppData/Local/YNote/data/weixinobU7Vjk0vRu3ZwlneWb3huf9dyLc/759f42defc544e1eb0fa3edb29ba6f5d/eo%7D2%7Eg@rc%25%29%25sehuud0%2827s.jpg
测试的准入阶段：（介入测试条件）
1.开发完成编码，完成单元测试
2.需求当中规定所有功能都已经实现
3.基本的主体功能流程畅通，界面上的功能都已经实现
4.开发组向测试组提交（测试申请单），以及相关的服务，数据配置好之后，测试人员介入测试
测试分析与设计：
分析：分析需求文档以及对应的生产的开发文档
设计：设计的是测试用例
测试的实现与执行：
执行测试用例--->提交测试出来的问题--->修复bug--->验证bug ---->关闭bug
测试报告（测试的准出）：
1.开发完成编码，完成单元测试
2.需求当中规定所有功能都已经实现
3.所有的测试用例都已经执行通过
4.输出测试报告
测试过程当中的资产归档（测试总结）
1.辅助测试工具进行归档
2.此次测试过程当中所有测试用例
3.此次测试所产生的bug
4.测试总结 此次测试过程当中所产生的问题（bug），项目组流程问题
|
|
142
0
多测师社区 
