先週、私はあなたの中で、ソフトウェアエンジニアリングの美しさを共有合計与えた記事をコーディングする開発者に、今週は共有していきますソフトウェアテストの記事の内容：
31 |ソフトウェアテストは、それへの製品の品質に責任がありますか？
すべての問題の最初の製品の品質に責任があるとテストソフトウェアのが、それはソフトウェア工学では、我々のようないくつかの側面を含んでいるので、ソフトウェアのテストは、すべての責任を負わなければならないことを意味するものではありません。
- 需要リンク
- デザイン面
- リンクの開発
- テストセッション
各リンクは、品質上の問題を引き起こすが、最終的な受け入れテストのための唯一の責任があることができ、それは、フリーソフトウェアが完全に問題を保証することはできません。
私たちはしばしば、と言うソフトウェア製品の品質は何ですか？
- 官能品質（バグ量、性能、UI / UXおよびその他の指標）
- コードの品質（保守性、可読性、効率性、安全性、クラステスト容易性）
- プロセス品質（スケジュール上、開発が制御可能なコストかどうか）
上記の定義に関連する影響は、共同でソフトウェアの品質を決定します。
誰が製品の品質に責任がありますか？
異なる役割が異なる責任を取る必要があります。
- ソフトウェアテスト：その出会いに機能要件を確保するためにテストする機能の品質を担当し、製品の受け入れ
- 開発者：自動化された様式で行わコードの品質、書き込みテストコード、機能テストを担当します
- プロジェクトリーダー：プロセスの品質を担当し、主な責任
理想的な状態：誰もが製品の品質に責任があります。
32 |ソフトウェアテスト：会社はどのようなフルタイムのテストを必要ですか？
ソフトウェアテストの主な仕事
- バグFOUND
- バグレポート
- バグ追跡
どのようにバグを見つけるには？
設計・テスト・ケースのニーズに応じて、可能な限りすべての可能なユーザーアクションをカバーします。パフォーマンス、セキュリティ、およびユーザーエクスペリエンスなど、基本的な機能テスト、だけでなく、非機能テストに加えて。完全な、高カバレッジのテストケースを設計することにより、テスターを使用して、タイムリーな検出のバグを達成することができそうという、一つのテストずつ持っています。
バグを報告するには？
チケットを開発者が作成したバグ、バグ追跡システムの発見後、次のセクションを含むコンテンツのバグの詳細な説明：
- 期待と実際の結果
- 再現する手順
- 必要に応じて、スクリーンショット、ログやその他の補助情報
バグを追跡するには？
報告に加えて、検証のためにすべきでもバグ修正修正バグテスターに開発を可能にします。通常、私たちはしばしばことを言う回帰テストが修理バグ、他の問題を導入しているため、開発者を避けるために。
一部のメーカーは、フルタイムのテストの話題を設定しないでください
このようなFacebookやGoogleやAmazonはこれらの企業がフルタイムのテストを設定していない行うことができますように、彼らは次のような共通の特徴があります。
- 優秀な技術者の多くは、同時に開発とテストを提供することができます。
- 自動テストコードカバレッジの大多数あります
- 強力なパブリッシングおよび監視システム
- よりリラックスしたスケジュール
- バグユーザーが高い容認します
ただ、最初に、国内の多くの企業が、私は個人的にその才能は自動化されたテストコードを書くと、それ自体で技術者の不足のカバレッジを確保するだけでなく、完全なリリースおよび監視システムに依存することが最も重要な一部であると考えていません。から調性時間、KPI、激しい製品競争に国内の重点は、時間が非常にタイトな圧力となりますので、圧力は時間の最初のエンジニア試験であり、単独の書き込み自動テストをしましょう。
しかし、将来の動向、開発と核融合のテストは、エンジニアのための要件はますます高くなり、より規範であり、私は人間から公式になるかもしれないいくつかの機能テストと類似の試験サイトをセットアップするために、完全に非現実的だと思いますアウトソーシングの形ではなく、よりフォーマルな人間開発は、テスト効率を向上させ、プラットフォームを構築できるツールを開発する能力を必要となります。
33 |テストツール：なぜQQ /マイクロチャネル/メール新聞のバグを渡すべきではないのですか？
基本的な情報は、バグが含まれて
- タイトル;
- （鍵情報所望の結果、実際の結果と再生工程を含む）説明
- 優先;
- 指名。
- ステータス（新、オープン、拒否された、固定、など）。
- その他。
なぜQQ、電子メールやその他の方法バグ？
- 簡単に検索および追跡
- 効率は、開発者が簡単にニュースによって中断することができ、低すぎます
- こうしたさまざまな状態の統計など、直感的ではありません
主な機能バグ追跡システムがない議論と論争のために、バグを追跡するために使用されます。
自動テストのいくつかのトレンド
- 手動テストの仕事を減らし、一部の外国のメーカーは、ジョブが自動テストソフトウェアテスターを書くことができます変更します
- ソフトウェア開発者機能コードを書くことができるようにするだけでなく、自動化されたテストコードの一定量を達成するために必要
私は投稿繰り返すことはしませんいくつかのソフトウェアのテストツールの宝石の教師のコラムについて、見に自分の興味に加入。
34 |アカウントのパスワードの漏洩災害は、予防するためにどのようにすべきですか？
タイトルからこのレッスンでは、安全性の話題について知ることができるようになり、セキュリティソースのソフトウェアは、次の3つのカテゴリに分かれています。
- 最初のカテゴリ：（SQLインジェクション、XSS攻撃など）悪意のある入力
- 第二のカテゴリー：偽のアイデンティティ（バックグラウンドは、制御権限がありません）
- 第三のカテゴリー：データ漏洩（クリアテキストレコード内のアカウントのパスワードは、漏れをログに記録します）
セキュリティ問題に対処するには？
-
本人確認を必要とし、そのようなユーザー権限など;機密情報、データ暗号化などの要件フェーズが明確に目標と予防措置を行うために、セキュリティニーズを必要とします
-
設計段階では、アーキテクチャレベルから安全性評価を高めるために
- 攻撃面を最小限に抑えます
- 権限が最小限に抑え
- 深さの防衛
-
開発段階では、適切なコーディングプラクティスとセキュリティ意識を確保します
- コーディング規約では、セキュリティ関連のコンテンツを追加しました
- コードレビューを持っています
- セキュリティの強化に関連したテストの自動化
-
テスト段階、テスト安全面を向上させます
-
オンライン維持相
- ソースコードのみコンパイルされたプログラムの展開を展開するわけではありません。デバッグファイルの削除を
- 唯一必要なポートを残して、そのような制限されたポートなどのサーバーのセキュリティ設定、、、開発者のほんの数は、サーバー上のサービスを入れて、オープン操作ログは、ディレクトリにアクセスするための最低限のアクセス許可を設定します。
セキュリティ上の問題はどのように行うには？
- 緊急時の手順の確立が、問題は、にさらに損失を避けるために、生産を復元する最初の時間を有効にするかを知ります
- ソースの脆弱性分析は、あなたが存在する抜け穴を見つけるためにログを分析することができ、修復を目的と
- 要約し、再発を防ぐために、プロセスを改善し、教訓、その理由を分析します
遂に
テストは、ソフトウェアエンジニアリングの側面ですが、それはまた、製品の品質と最終的には受け入れを担当する製品の品質のハードルを、確実にするために非常に重要な部分であり、ヘルプは、製品がより多くのことが判明したが、今週の主な学習内容は、ソフトウェア関連のテストですそしてより多くのバグを修正しました。これまで私たちはしばしば開発し、オープンな独立した部門をテストしたが、R＆Dモデルの進化と、テストはまた、自動テストによって手動テストを減らすR＆Dの効率を改善するために考慮に入れる必要がある開発者の役割になってきています。また、製品に改善された効率性をもたらすことができ、テスト作業の将来の役割は、境界線の開発は、もはやこの役割のためにコードを書くに限定され、変わりません、私たちにいくつかのインスピレーションをもたらし、我々は境界を設定しないでください。誰もが製品の品質に対して責任を負わなければならない、誰もがプロダクトマネージャーです。
