كيفية قياس القوة?

Question

أنا أعمل على أطروحة حول meassuring جودة المنتج.المنتج في هذه الحالة هو موقع على شبكة الانترنت.وقد حددت عدة سمات الجودة و meassurement التقنيات.

نوعية واحدة سمة "متانة".أريد أن meassure بطريقة أو بأخرى, ولكن أنا لا يمكن العثور على أي معلومات مفيدة كيفية القيام بذلك بطريقة موضوعية.

هل هناك أي ثابتة أو ديناميكية متري يمكن أن meassure متانة?أي مثل وحدة اختبار التغطية ، هل هناك طريقة meassure متانة مثل هذا ؟ إذا كان الأمر كذلك ، هل هناك أي (مجانا) أداة يمكن أن تفعل مثل هذا الشيء ؟

هل من أحد لديه أي خبرة مع مثل هذه الأدوات ؟

أخيرا وليس آخرا, ربما هناك طرق أخرى لتحديد متانة, إذا كان لديك أي أفكار عن ذلك أنا كل آذان.

شكرا جزيلا مقدما.

Answer 1

حسنا الإجابة هي "لا". قوية يمكن أن تعني الكثير من الأشياء, ولكن أفضل تعريف يمكن أن يأتي مع هو "المنفذ بشكل صحيح في كل حالة." إذا قمت بإرسال رسالة سيئة HTTP رأس قوية ملقم ويب, يجب أن لا تحطم.فإنه يجب أن تعود بالضبط الحق في نوع من الخطأ ، وينبغي تسجيل الحدث في مكان ما ربما في شكلي الطريق.إذا قوي يعمل ملقم ويب لفترة طويلة جدا ، أثر الذاكرة يجب أن تبقى نفسها.

الكثير من ما يجعل النظام القوي هو التعامل مع الحالات الحافة.جيدة وحدة الاختبارات هي جزء من ذلك ، ولكن من المحتمل جدا أن لا يكون هناك وحدة الاختبارات لأي من مشاكل النظام (إذا كانت معروفة ، المطورين ربما كانت ثابتة لهم فقط ثم أضاف الاختبار).

للأسف انه من المستحيل تقريبا قياس متانة التعسفي البرنامج لأنه من أجل القيام بذلك عليك أن تعرف ما هو هذا البرنامج هو من المفترض أن تفعل.إذا كان لديك مواصفات كتابة عدد كبير من الاختبارات ومن ثم تشغيلها ضد أي عميل بمثابة اختبار.على سبيل المثال, انظر Acid2 اختبار المتصفح.بعناية يقيس مدى أي متصفح ويب يتوافق مع معيار بطريقة سهلة للتكرار الموضة.هذا هو أقرب ما يمكنك الحصول على الناس وقد أشار العديد من العيوب مع هذا النهج (على سبيل المثال ، هو البرنامج الذي تعطل في كثير من الأحيان ولكن لا شيء إضافي واحد حسب المواصفات أكثر قوة?)

هناك ، على الرغم من العديد من الشيكات التي يمكن استخدامها كمادة الخام, العددي تقدير صحة النظام.وحدة اختبار تغطية جميلة معيار واحد ، وكذلك الأشقاء في فرع التغطية وظيفة التغطية بيان التغطية ، إلخ.خيار جيد آخر هو "لينت" برامج مثل FindBugs.هذه يمكن أن تشير إلى مشاكل محتملة.مشاريع مفتوحة المصدر غالبا ما يتم الحكم من قبل كيف في كثير من الأحيان في الآونة الأخيرة يرتكب أو يطلق سراحه.إذا كان المشروع يحتوي علة النظام ، يمكنك قياس كيف تم إصلاح العديد من البق و نسبة.إذا كان هناك نسخة معينة من البرنامج كنت قياس خاصة مع الكثير من النشاط ، MTBF (متوسط الوقت بين الإخفاقات) هو مقياس جيد من الشدة (انظر فيليب الإجابة)

هذه القياسات, رغم أن, لا أقول لكم مدى قوة البرنامج.انهم مجرد طرق تخمين ذلك.إذا كان من السهل معرفة إذا كان البرنامج قوي ربما تجعل مجرد مترجم التحقق من ذلك.

حظا سعيدا مع أطروحة الخاص بك!أتمنى أن تأتي مع بعض باردة جديدة القياسات!

Answer 2

يمكنك النظر في يعني الوقت بين الفشل كتدبير متانة. تكمن المشكلة في أنها كمية نظرية يصعب قياسها ، خاصة قبل أن تنشر منتجك في موقف حقيقي مع أحمال واقعية. جزء من السبب في ذلك هو أن الاختبار في كثير من الأحيان لا يغطي مشكلات قابلية التوسع في العالم الحقيقي.

Answer 3

في كتابنا الغامض (بواسطة Takanen ، Demott ، Miller) ، لدينا العديد من الفصول المخصصة للمقاييس والتغطية في الاختبار السلبي (المتانة ، والموثوقية ، واختبار القواعد ، والغموض ، والعديد من الأسماء لنفس الشيء). كما حاولت تلخيص أهم الجوانب في شركتنا البيضاء هنا:

http://www.codenomicon.com/products/coverage.shtml

مقتطف من هناك:

---

يمكن رؤية التغطية على أنها مجموع ميزتين ، الدقة والدقة. الدقة تهتم بتغطية البروتوكول. يتم تحديد دقة الاختبار من خلال مدى تغطي الاختبارات لرسائل البروتوكول المختلفة وهياكل الرسائل والعلامات وتعريفات البيانات. الدقة ، من ناحية أخرى ، تقيس مدى دقة الاختبارات في العثور على الأخطاء داخل مناطق بروتوكول مختلفة. لذلك ، يمكن اعتبار الدقة شكلاً من أشكال تغطية الشذوذ. ومع ذلك ، فإن الدقة والدقة هي مصطلحات مجردة إلى حد ما ، وبالتالي ، سنحتاج إلى النظر في مقاييس أكثر تحديدًا لتقييم التغطية.

يرتبط جانب تحليل التغطية الأول بسطح الهجوم. يبدأ تحليل متطلبات الاختبار دائمًا من خلال تحديد الواجهات التي تحتاج إلى اختبار. يحدد عدد الواجهات المختلفة والبروتوكولات التي ينفذونها في طبقات مختلفة متطلبات Fuzzers. قد يتطلب كل بروتوكول أو تنسيق ملف أو واجهة برمجة التطبيقات نوعه الخاص من fuzzer ، اعتمادًا على متطلبات الأمان.

يرتبط مقياس التغطية الثاني بالمواصفات التي يدعمها Fuzzer. هذا النوع من المقياس سهل الاستخدام مع الزوارق المستندة إلى النماذج ، حيث يتم تشكيل أساس الأداة من خلال المواصفات المستخدمة لإنشاء fuzzer ، وبالتالي فهي سهلة القائمة. يجب أن يغطي Fuzzer المستند إلى النموذج المواصفات بأكملها. في حين أن الضارب القائم على الطفرة لا يغطي بالضرورة المواصفات بالكامل ، لأن تنفيذ أو تضمين عينة تبادل الرسائل من المواصفات لا يضمن تغطية المواصفات بأكملها. عادةً ما يكون دعم مواصفات Fuzzer المستند إلى طفرة ، فهذا يعني أنه يمكن تشغيله مع أهداف الاختبار التي تنفذ المواصفات.

خاصة فيما يتعلق بتضخمة البروتوكول ، فإن المقياس الحرج الثالث هو مستوى الدولة لنهج الغموض المختار. عادةً ما لا يختبر Fuzzer عشوائيًا فقط الرسائل الأولى في بروتوكولات الحالة المعقدة. كلما كان الأمر الأكثر وضوحًا للدولة ، هو نهج الغموض الذي تستخدمه هو ، كلما كان أعمق في تبادل البروتوكولات المعقدة. تعتبر الدولة شرطًا صعبًا لتحديد أدوات الغموض ، حيث إنها أكثر مقياسًا لتحديد جودة نموذج البروتوكول المستخدم ، وبالتالي لا يمكن التحقق منها فقط عن طريق إجراء الاختبارات.

---

اتمنى ان يكون ذلك مفيدا. لدينا أيضًا دراسات في مقاييس أخرى مثل النظر إلى تغطية الكود وغيرها من البيانات غير المجدية إلى حد ما. ؛) المقاييس موضوع رائع للأطروحة. أرسل لي بريدًا إلكترونيًا على ari.takanen@codenomicon.com إذا كنت مهتمًا بالوصول إلى أبحاثنا المكثفة حول هذا الموضوع.

Answer 4

المتانة ذاتية للغاية ولكن يمكنك إلقاء نظرة على fingbugs, Cobertura و هدسون والتي عندما يتم دمجك بشكل صحيح معًا يمكن أن تمنحك شعوراً بالأمان بمرور الوقت أن البرنامج قوي.

Answer 5

هل يمكن أن ننظر إلى متوسط الوقت بين فشل متانة التدبير.

المشكلة مع "MTBF" هو أنه عادة ما تقاس إيجابية في حركة المرور في حين أن الفشل في كثير من الأحيان يحدث في حالات غير متوقعة.أنها لا تعطي أي مؤشر على المتانة والاعتمادية.لا يهم إذا كان موقع على شبكة الإنترنت يبقى دائما في مختبر البيئة ، فإنه سوف لا يزال يتم اختراق في الثانية في الإنترنت إذا كان لديه ضعف.