软件测试——基础知识

软件测试的定义&软件的生命周期
软件测试工作流程&测试用例编写
bug相关知识
版本控制工具SVN的使用
计算机网络&Linux操作系统
项目笔记
数据库
抓包工具
接口测试Jmeter
APP测试项目笔记
Git&Java基础知识
Jmeter & Jenkins & Maven
性能测试

这段时间十分焦虑，最开始的求职目标是产品经理，但是发现在准备过程中自己一直不自信，仔细分析之后发现，这种不自信完全是来自于对自身能力的不认可，或者说就是能力不够，优秀的产品经理都是通过项目磨练出来的，可是我没有，怎样能改变呢，那就曲线救国吧，自己是工科学生，但是对于技术其实自己却没有真正踏踏实实去钻研，软件测试是给自己的一个挑战，从现在开始完全沉下心来为它做准备，确定方向之后便只顾风雨兼程！三个月之后我要看到一个不一样的我，加油！

软件测试的定义

1. 软件测试
   一个过程或者一系列过程，用来确认计算机代码完成了其应该完成的功能，不执行其不该有的操作。** 测试是为发现错误而执行程序的过程。**
   一次成功的测试是指：在对某段程序进行经过合理设计并得到有效执行的测试过程中，发现了错误并且这些错误是可修复的。如果本次测试可以最终确定再无其他可查出的错误，同样也被称作是成功的。
2. 软件测试的原则
   原则一：测试用例中一个必需部分是对预期输出或结果的定义
   一个测试用例必须包括两个部分：对程序的输入数据的描述；对程序在上述输入数据下的正确输出结果的精确描述。
   原则二：程序员应当避免测试自己编写的程序
   原则三：编写软件的组织不应当测试自己编写的软件
   原则四：应当彻底检查每个测试的执行结果
   原则五：测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入情况
   原则六：检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”
   原则七：应避免测试用例用后即弃，除非软件本身就是一个一次性的软件
   原则八：计划测试工作时不应默许假定不会发现错误
   原则九：程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比
   错误总倾向于聚集存在，为了使测试获得更大的成效，最好对这些容易存在错误的部分进行额外的测试。
   原则十：软件测试是一项极富创造性、极具挑战性的工作

一个好的测试用例具有较高的发现某个尚未发现的错误的可能性；一个成功的测试用例能够发现某个尚未发现的错误

软件测试一些分类

优点：
1）为项目提供按阶段划分的检查点。
2）当前一阶段完成后，你只需要关注后一阶段。
3）可在迭代模型中应用瀑布模型。
4）提供一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
缺点：
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化。

V模型
通过开发和测试同时进行的方式来缩短开发周期，提高开发效率。其形状像一个字母V，故称为V模型。

敏捷开发的流程
1）产品负责人将整个产品设计成产品代办列表。就是一个个需求列表。（可以理解为需求或者要做的事情）
2）召开产品迭代计划会议，确定哪些需求是需要在第一个迭代中完成的，评估迭代的时间（建议是2-4周），得到相应的迭代周期任务列表。
PS:提前发布功能需求列表，会议提倡所有团队人员参与。
3）把迭代的功能需求写在纸条上贴在任务墙，让大家（自主认领）认领分配。（任务墙就是把未完成、进行中、已完成的工作状态贴到一个墙上，这样大家都可以看到任务的状态）

举行每日站立会议，让大家在每日会议上总结昨天做的事情，遇到什么困难，今天开展什么任务。（每日站立会议，是在每天早上定时和大家在任务墙前站立讨论，时间控制在15分钟内）

绘制燃尽图，保证任务的概况能够清晰看到。（燃尽图把当前的任务总数和日期一起绘制，每天记录一下，可以看到每天还剩多少个任务，直到任务数为0，这个迭代就完成了)
PS:在开发人员开始开发一个任务时，需要找来对应的测试人员讲解该任务功能，以便测试人员有一致的理解，并且一开始就进行测试用例，自动化系统测试脚本的开发（若需要自动化测试的话）。
4）评审会议是在迭代完成时举行，要向客户演示自己完成的软件产品，并获得客户的反馈。
PS:很多用户对软件开发是没有概念的，他只知道自己有某种需求。所以就要通过不断的让用户看到产品的模型，这个过程用户才会逐步的对产品产生概念。
5）最后是总结会议，以轮流发言方式进行，每个人都要发言，总结好的实践和教训，并落实到后续的开发中。不要流于形式。
敏捷开发适用原则
1）个人与互动：重于流程与工具
—-强调人与人的沟通，所以尽可能要集中化办公。异地开发模式容易让人疲惫
—-个人技能要提高。尤其对于架构师要求很高。
—-管理者要多参与项目有关的事情。
—- 减少对开发人员的干扰，问题集中整理问。
2）可用的软件：重于详尽的文件
—-强调文档的作用。必要的文档是必须的，具有传承性。
3）与客户合作：重于合约协商
—-做好客户引导。客户都是想在尽可能短的时间内，交付尽可能多的功能。
4）回应变化：重于遵循计划
—-无理变化，举棋不定的结果，并不是说都需要及时响应，会导致很多浪费。

软件测试阅读书籍

• 《软件测试的艺术》 Glenford J.Myers （王峰 陈杰译版）

来源：Eve12345678